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