pivot_root on boot

C. Scott Ananian cscott at cscott.net
Sat Jul 7 00:12:17 EDT 2007


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.
  --scott
-- 
                         ( http://cscott.net/ )



More information about the Devel mailing list