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