Considering repo re-structuring
On 12/01/2010 07:33 PM, Karanbir Singh wrote:
> On 11/30/2010 01:42 AM, Douglas McClendon wrote:
>>> thats not true. A bare metal install will finish before your livecd has
>>> finished booting.
>> Sure, pedantically you are no doubt correct even though I have no idea
>> what a 'bare metal install' means in this context.
> to me, 'a bare metal' install is where its just the bios, pxe into a
> pre-established install set ( via a ks.cfg ) - Also, rebooting before a
> machine gets deployed in a 'role' is actually very highly recommended.
> Install images and run-time images are never guaranteed to be identical.
Yeah, later I realized you brought up 'bare metal' as opposed to virt,
in relation to your comment about installation-running-os fighting for
io traffic from the cd/usb with the installation data itself. But no, I
was talking bare metal installs as well. And I think I can beat your
270s time. Also, while I'll grant that there are some valid points for
rebooting (though I have ways to mitigate/counter those), your point
about install-images and run-time(installation-os?) images not being
guaranteed to be identical is actually I think exactly wrong for the
case of how fedora's livecd installation works. Fedora's livecd
installation works by literally copying the same rootfs image that was
used to boot the livecd, to the destination partition. Thus they are in
that case, always guaranteed to be identical. Also note, that your
point about livecd/usb boots being slow, had I believe a lot to do with
your perspective of watching particular livecd/usb boots, and how much
work they actually do compared to the installation-os that boots from
the traditional install media. I.e. if you build a custom livecd that
isn't trying to boot up to a full gnome desktop, and instead just boots
up to what we think of as runlevel1, or to runlevel3 of a minimal style
install (just ssh server and yum groupinstallable), you'll find that a
livecd/liveusb can boot up nearly as fast as the traditional install
media. Then, the time savings you get from performing an fs-image copy
style install versus a fs-create+rpm-i*.rpm+otherstuff, more than make
up for the few extra seconds upon boot. In other words, I definitely
think I can make a liveusb minimal sshable-yumable installer that
finishes faster than the same usb booting the traditional installer
doing a traditional equivalent minimal install. And then also a version
that makes the reboot after install completes entirely optional (in
other words, if you want to do it to test the bootloader, you can, but
you don't have to).
>>> .. and you lose any/all management ability from the standard
>>> distro-aware tools. Ofcourse, that does not matter if you don't need
>>> those tools anyway.
>> Also here I don't really know what you mean. Though yes, LiveCD
>> installations are presently still less flexible in several ways than the
> management tooling like cobbler/spacewalk/theforeman/existing and
> established install -> deployment tools etc.
Yes, you just got the wrong impression that I was talking about a
replacement installer, not an additional optional/experimental method.
CentOS-devel mailing list