pivot_root on boot

[Dan Williams]

On Sat, 2007-07-07 at 00:12 -0400, C. Scott Ananian wrote:
> Quick recap of early boot:
>  a) open firmware checks the status of the <foo> key, and
> signature-checks and boots either the primary or the backup kernel,
> passing "fs=primary" or "fs=backup" on the kernel command-line.
>  b) an initramfs script looks for an activation record in /, and
> initiates activation if not found.  If it is found, then we pivot_root
> to root:/primary or root:/backup, depending on the value of the 'fs'
> command-line parameter.
> 
> I've prototyped this process on a hacked build 488.  All the "real"
> filesystem (except boot) is moved down one level to /a, and we
> pivot_root to /a during startup.  Some things I found out:
> 
> a) we actually already have an initrd for our kernel, which is built
> with klibc and is mostly useless: it loads a few modules and invokes
> klibc's "run-init" to deallocate the initramfs and pivot to the new
> root.
> b) pivoting to a directory which is not a mount point (ie, not the
> root directory of the mounted fs) is problematic.  The --move option
> to mount only works on mount points.  We can --move to the real root
> and then chroot to the subdirectory, but then this causes problems
> when we want to remount the real root rw after fsck: mount -o
> remount,rw / doesn't work, because / isn't actually the mount point.
> In fact, we can't see the actual mount point anymore.
> 
> Suggestions:
> a) get rid of the existing initrd.  Un-module the necessary IDE and
> olpc_nand drivers.
> b) Create new initrd with activation and "pivot" code.
> c) Don't try to pivot_root to the 'real' filesystem.  Instead use symlinks:
>    /boot -> /current/boot
>    /bin -> /current/bin
> Then we can swing the /current symlink from /a to /b to select either
> the primary or the backup filesystem.

My gut feeling is, let's get the bits to actually generate/support two
filesystems into the machine and working before we land something that
lets us choose between two filesystems.  Boot process is already
complicated enough that adding another level to it that may/may not be
actually _used_ depending on whether or not we get all the other
necessary bits in, doesn't sound like a good idea to me at the moment...
I'm basically just worried that if the other stuff doesn't land, we have
a bunch of other (unused) pieces that were intended to support the
pieces that didn't land, and then we have to spend effort to rip them
out.

Dan