I have a use for something like this. On Sun, 2007-07-08 at 21:51 -0500, Douglas McClendon wrote: > Normal Fedora 7 Installed On Hard Disk System > (assume just 1 non lvm partition /dev/sda1) > ---------------------------------------------- > -The bios loads the grub boot loader from the MBR of /dev/sda > -grub knows how to read it's config from /dev/sda1:/boot/grub/grub.conf > -grub is configured to boot a specific kernel+ramdisk+appendstring, namely > /dev/sda1:/boot/vmlinuz-someversion, /dev/sda1:/boot/initrd-someversion, > someargs... > -control is thusly passed to the kernel, and the kernel then gunzips and > extracts the cpio of the specified initrd (which I think grub copied to a > well > known place in ram. Only reason I might know this is because qemu's crafty > -initrd feature screwed it up for larger initrds recently, though it has been > fixed) > -the kernel having then extracted the contents into a ram based filesystem, > passes control to /init (or maybe /sbin/init, or maybe whatever init= was > specified on the cmdline). > -now the fun starts. This init is a nash or a bash script, whose job it is > to > mount the real root filesystem (e.g. the ext3fs on /dev/sda1) and then > pivot_root to it. > -finally, control is passed to /sbin/init on the real disk-based root > filesystem, at which point the contents of the well known /etc/inittab start > to > matter. > > Now then, what the Fedora-7 livecd does is along these lines > ------------------------------------------------------------ > -instead of the bios booting grub loaded on the mbr of a disk, it boots > grub(or > perhaps isolinux) from the bootsector of the cdrom.
- We boot from a local flash, (random example: http://www.pcengines.ch/cf2g.htm) > -this bootloader behaves much like above, but pulling a > kernel+initrd+append_args from some place on the cdrom. s/cdrom/flash/ > -now the fun begins after the initrd is extracted and mounted in a ram based > fs > as normal. An entirely different /init script within the initrd will go > about > the business of mounting the 'real root filesystem'. In this case, first the > cdrom's iso9660 fs is mounted. Then a squashfs image file is loopback > mounted > from within the iso9660 fs. Then a sparse ext3fs image file is loopback > mounted > from within the squashfs. s/iso9660/whatever/ Before the squashfs is loop mounted, we do some checks on it... most likely a checksum of sorts. At this point we test if this is the latest image. If not, we pull the latest image to a ram drive and loop mount that instead of the local squashfs image. I have assumed we would be able to have some sort of network access at this stage. > - now the REAL fun begins. A ram based filesystem is created. A sparse file > overlay is created within it. Now a device mapper snapshot is created using > the > read-only ext3fs image, and the read-write overlay file. (I'm skipping some > loopback device associations, and in general probably misnaming a few things, > as > this is unashamedly from the hip, and not suitable to be published). Now, > this > magic devicemapper snapshotted device appears as /dev/mapper/live-rw, and > appears to be a read-write ext3 filesystem, except the writes really get > tucked > away in ram (which is going to eat away at your ram). > - That /dev/mapper/live-rw gets mounted as the 'real root filesystem', and > pivot_root is called, and then things progress as normal. If the squashfs image has not changed, we pivot_root right away. > > Now then- what the rebootless installer patch does differently > -------------------------------------------------------------- > -Just after the /dev/mapper/live-rw gets set up in the initrd, instead of > mounting it as the real root filesystem, it gets used to create a raid1 > 'mirror'. quotes because in this case the 'mirror' only has 1 device, rather > than the usual 2. The mirror is visible as /dev/md7, and THAT gets mounted > as > the real root filesystem, before pivot_root is called, and everything > progresses > as normal. Neat. Could we create the raid1 from a new loop mounted squashfs that has just been loaded into ram? > > But because of /dev/md7 being the 'real root filesystem', long after boot, > you > can hot-add another device to the mirror, in this case, the target volume > that > you want to install the system on (e.g. /dev/sda1). After you hot-add, the > raid/md driver starts synchronizing the data from /dev/mapper/live-rw to > /dev/sda1. I would want to sync back to the flash at this point. > When this finishes, you can hot-remove /dev/mapper/live-rw, at which > point the system is running from /dev/sda1, just as if you had installed > there > and rebooted (with the caviat that there is this /dev/md7 layer sitting there > until the next reboot). And once /dev/mapper/live-rw is removed from the > /dev/md7 array, the resources that constructed it (i.e. the files on the > cdrom, > and that overlay file in a ram-based fs) can be released/deleted/unmounted. > Thus you stop suffering the penalty of that overlay eating up your ram, and > you > are free to eject the cdrom. > > Now, for the sake of simplicity, we will assume that "mdadm /dev/md7 --grow > --size=max" will actually work, and the 3.5G ext3fs that got migrated to your > 100G /dev/sda1 partition, can be grown with resize2fs's ability to online > expand > a live ext3 filesystem. (technically this does not yet work, so refer to all > those nasty workarounds). > There is my incomplete 2am reply ;-) Jonathan Steffan daMaestro -- Fedora-livecd-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-livecd-list
