[CentOS-devel] Considering repo re-structuring

Thu Dec 2 03:34:36 UTC 2010
Douglas McClendon <dmc.centos at filteredperception.org>

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.

-dmc