Community, At the bottom of this lengthy RFC is a patch to livecd-tools mayflower script which adds the interesting ability to install the livecd system to hard disk, in a way that doesn't require a reboot after installation. Given the proof-of-concept nature of this small patch/hack, I just want to get some feedback from the community before really going all out, and adding support to anaconda to be the installation front-end. For now, you would have to perform the installation steps (outlined below) manually. Concept: Rebootless Installer via LiveCD(/DVD/USB/PXE/...) ---------------------------------------------------------- The basic 'trick' is to use raid1 style mechanisms to live-migrate the root filesystem from the install media, to the desitination drive. Note, that I'm not looking for a debate as to whether or not this would be a useful default installer for fedora. Rather I think that it would *definitely* be a nice checkbox option for people to add to their own customized fedora-derived spins. History ------- In 2001 I created an unpublished livecd spin tool for Mandrake. The resulting images (optionally) possessed the interesting feature that during the initrd boot sequence, all hard drives would be scanned for mountable partitions. If a partition was found with suitable free space (e.g. windows C drive(vfat)), the initrd would copy the livecd to an image file there, and use it instead of the cd drive. (and optionally setting up loadlin/lilo for future usage sans livecd). But this wasn't as useful as what I'm currently talking about, because the installed system would still be a mix of read-only and tmpfs filesystems, and you would have to wait for the cd to copy before seeing anything. (of course I did have X+mozilla+xmms in 135MB...) Then, as I discovered a couple days ago, in 2003, Goswin Brederlow more or less outlined the attached method. http://www.mail-archive.com/debian-boot@lists.debian.org/msg28182.html I haven't yet pinged him, so I don't know if debix is the 'modern' version of the proof of concept iso he referred to there. http://debix.alioth.debian.org/ (stale since 2004?) Then, when I first started getting involved with fedora-livecd-list, someone, I think a redhat employee, mentioned that I might be able to do that iso-caching-to-disk thing mentioned above using raid1 mirror tricks. I.e. in initrd, set up the image from iso as a 1-disk raid1 array, and use it as the root fs. Then after boot, use space on hard disk as a hot-added 2nd disk for the array, and after the raid sync finishes, hot-remove the cdrom based device, so that the cd can be ejected. It wasn't long after this that I managed to re-outline what Goswin had outlined years earlier http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html Current Mechanism ----------------- The mechanism I've implemented in the attached patch is really dirt simple. - mdadm is added to the initramfs - after normal creation of the device mapper root filesystem, /dev/md7 is created as a raid1 with a single device- the normal /dev/mapper/live-rw root device. Note, I opted with a metadataless device, so that on subsequent boots there is no raid1 involved (? I may have an incomplete understanding of my options that led to this choice ?) - the root filesystem (sysroot) is then mounted from /dev/md7 instead of /dev/mapper/live-rw Current Rebootless Installation Procedure ----------------------------------------- - once booted into the live environment, choose your destination device. (for this exampe, I'll assume /dev/sda1) - add the device to the raid. mdadm /dev/md7 --add /dev/sda1 mdadm /dev/md7 --grow --raid-disks=2 - wait for the resync to finish (watch /proc/mdstat) - remove the original devices from the raid mdadm /dev/md7 --fail /dev/mapper/live-rw mdadm /dev/md7 --remove /dev/mapper/live-rw mdadm /dev/md7 --grow --raid-disks=1 // (perhaps redundant) dmsetup remove live-rw losetup -d /dev/loop121 losetup -d /dev/loop120 losetup -d /dev/loop119 - now you should be able to eject the livecd - install and configure grub in the usual way, with the assumption that the root device on subsquent boots will be /dev/sda1 as normal, and not the current /dev/md7. - now grow the filesystem - CRASH/BURN/DIE... segway to... Current Problem With Less Than Fully Satisfying Workaround ---------------------------------------------------------- The current problem with the attached patch is that it is not possible to resize the small livecd ext3 filesystem to the maximum size of the destination partition _before_ rebooting. (after reboot, no sweat, as the raid1 layer is gone) Specifically, when I tried mdadm /dev/md7 --grow --size=max /proc/mdstat showed the number of blocks go from 3.5G to 0, though strangely the system did not fall over dead. And when I tried mdadm /dev/md7 --grow --size=[ just a bit bigger than mdstat reports ] I get mdadm: Cannot set device size for /dev/md7: No space left on device Now, googling yielded someone with a similar message for raid5 which turned out to be a legitimate bug. My next step will be to post to the linux-raid mailinglist and see what they say. From my perusing of the userspace and kernel code, I have a hunch that I may just be trying for a feature that hasn't been implemented, and hasn't been adequetly documented as such. Perhaps my choice of raid1 options is at issue. But, there are of course many different ways to try and accomplish the same thing, so... Workaround #1 ------------- Create the original livecd ext3 fsimage on a huge (say 777G) sparse file, but only make the filesytem size be the normal container size (~3G). (or alternately, in initramfs, create a device mapper device that is a linear addition of the original fsimage, and a huge device mapper zero device) Then, instead of setting /dev/sda1 as the other half of the mirror, create another devicemapper device which is the linear addition of it and a huge device mapper zero device. Because there is now no need to grow the raid1, you are golden, and can resize the ext3 fs to the max size of sda1. CONS: The main con here is that the installation process will require the zero-ing out of all the unused parts of sda1, AND a whole lot of null work as the raid syncs the tailing imaginary parts of the devices. Admittedly the latter is pretty fast, though if you want to support installing to a 750G disk, you'll need to make the containers 777G and suffer quite a bit of time waiting for the md driver to finish doing a whole lot of nothing. Theoritical Workaround #2 ------------------------- Like WA#1, but instead of the other half of the raid1 being a linear addition of the _entire_ destination device and a big zero device, make it a linear addition of the _beggining_(size of livecd fsimage) of the destination device, and a big zero device. But, to make it work, make that be a multipath md device. Then after the faster raid1 sync finishes, create a new fake device that includes all of the destination device, and add it to the multipath, take out the other, and bingo. I haven't tried this yet to see if it will work. Theoretical Workaround #3 ------------------------- Hack the md raid1 driver so that you can force the sync to believe it is done after reaching a certain point. Together with WA#1, this would achieve relatively best-case overall performance. I've looked into the md sysfs interface, and there doesn't yet appear to be a way to accomplish this. Theoretical Workaround #4 ------------------------- Understand the device mapper mirror target, which lacks Documentation/device-mapper/mirror.txt http://web.glandium.org/blog/?p=141 is the best documentation I've found so far. Though I did run accross a Goswin post somewhere where he claimed that it was really simple (cough cough). Or perhaps redo everything with pvmove (which I haven't researched much), and/or logical volumes as requirements. Or perhaps this request for comments will yield some other sort of answer. Anybody? Anybody? Patch ----- Note, this is against mayflower from livecd-tools-009-1.fc7, and you will also need to add raid1 to the MODULES list in livecd-creator where it generates mayflower.conf on the fly. 80a81,82 568c570,589 < ln -s /dev/mapper/live-rw /dev/root --- o sleep 7; done; /sbin/mdadm /dev/md7 --fail /dev/mapper/live-rw ; /sbin/mdadm\ /dev/md7 --remove /dev/mapper/live-rw 570d590 < mount -n -t ext3 /dev/mapper/live-rw /sysroot 682a703