[Fedora-livecd-list] [RFC/PATCH] livecd rebootless installer

Douglas McClendon dmc.fedora at filteredperception.org
Sun Jul 8 04:58:49 UTC 2007 

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
 > # dmc/jdog-ri-poch
 > cp /sbin/mdadm sbin
568c570,589
<     ln -s /dev/mapper/live-rw /dev/root
---
 >     ## dmc/jdog-ri-poch
 >     #ln -s /dev/mapper/live-rw /dev/root
 >     # create broken mirror
 >     # and hope it doesn't cause another 7 years of bush in the whitehouse :(
 >     modprobe raid1
 >     mdadm --build /dev/md7 --level=1 --raid-devices=1 /dev/mapper/live-rw
 >
 >     ln -s /dev/md7 /dev/root
 >
 >     ## dmc/jdog-ri-poch
 >     # mount the broken mirror instead of the live-rw
 >     #mount -n -t ext3 /dev/mapper/live-rw /sysroot
 >     mount -n -t ext3 /dev/md7 /sysroot
 >
 > cat<<JDRIEOF> /sysroot/usr/sbin/rliveinst
 > #!/bin/bash
 > /sbin/mdadm /dev/md7 --add \\\$1 ; while ( grep -q recovery /proc/mdstat ); d\
o sleep 7; done; /sbin/mdadm /dev/md7 --fail /dev/mapper/live-rw ; /sbin/mdadm\
/dev/md7 --remove /dev/mapper/live-rw
 > # todo: configure and install grub and run mkinitrd, and free loop devices
 > JDRIEOF
 > chmod +x /sysroot/usr/sbin/rliveinst
570d590
<     mount -n -t ext3 /dev/mapper/live-rw /sysroot
682a703
 >

More information about the Fedora-livecd-list mailing list