Date: Mon, 23 Aug 2010 14:30:16 -0700 From: Marcel Moolenaar <marcelm@juniper.net> To: FreeBSD Arch <freebsd-arch@freebsd.org> Subject: RFC: enhancing the root mount logic Message-ID: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net>
next in thread | raw e-mail | index | archive | help
All,
In embedded products, software is possibly installed as an image onto
an actual storage device. This means that mounting the storage device
as root is not enough to have a usable root file system. The rough
draft below is an idea to enhance the root mount from having ad-hoc
quirks to a well-defined and recursive mechanism to allow a wide-
range of use cases.
The root mount logic is recursive as follows:
1. The kernel mounts devfs as root (is it is now).
2. The kernel will re-mount root by virtue of reading a file, called
/.mount.conf, in the current root file system and following the
directives is it. devfs synthesizes the contents of this file.
At each iteration, the kernel will:
1. move the devfs mount from /dev in the old file system to /dev in
the new file system.
2. As per the directives or unconditionally, the kernel will re-mount
the old root file system under /.mount (or some other name) within
the new file system.
devfs will synthesize the contents of /.mount.conf as per the kernel
configuration and tunables. The administrator (or install process)
will create and populate /.mount.conf for all other cases.
Directives in /.mount.conf are envisioned to be something like:
{FS}:{MOUNTPOINT} e.g. ufs:/dev/da0
a root mount alternative. The order of the alternatives in
the file determines the priority.
.ask
a root mount alternative that asks the operator to specify
what the root mount should be.
.wait N .e.g. .wait 5
wait at most N seconds for a root mount alternative to
succeed. If an alternative does not succeed within that
time, move on to the next alternative.
.onfail {panic|reboot|retry|continue}
Tells the kernel what to do in case it can't successfully
complete the root mount as directed to.
The .wait directive works better (probably) if we have events that
signify the arrival of a file system or device special file, so that
we can wait for at most N seconds after the last event. This also
allows us to wait for a separate interval between events.
As an example, consider:
[devfs] /.mount.conf:
ufs:/dev/da0
.ask
.wait 5
.onfail panic
[ufs:/dev/da0] /.mount.conf
md0:/images/OS-image-1.0.iso
unionfs:/jail/freebsd-8-stable
.wait 0
.onfail continue
In the example, the kernel will mount devfs, read /.mount.conf and
wait at most 5 seconds to mount the UFS on /dev/da0. If that fails,
the kernel will ask (once) and panic in case of failure.
If the UFS root mount succeeded, the kernel will re-mount devfs
underneath /dev. Since this is the first non-devfs root file system,
the kernel will not re-mount the old root under /.mount.
Since there's a /.mount.conf on the UFS, the kernel will read it
and repeat the process. First it'll try and mount the OS image
in /images/OS-image-1.0.iso and if it's not present will try to
mount some -stable 8 chroot using unionfs (not necessarily a
real-world example here :-) If either fails, the kernel will
continue booting using the current root file system. Assuming that
the image is present, the kernel will re-mount root, move devfs
underneath /dev in the MD root and remount ufs:/dev/da0 under
/.mount in the MD root. This gives the following picture:
/ md0:[ufs:/dev/da0]/images/OS-image-1.0.iso
/.mount ufs:/dev/da0
/dev devfs
Things to not explicitly touched upon:
o root mount options
o directives to instruct the kernel what to run as the initial
process to eliminate the rather ad-hoc hardcoding. E.g:
.init /sbin/init
.init /sbin/init.old
Is this something that people feel is worth fleshing out and
prototyping?
--=20
Marcel Moolenaar
marcelm@juniper.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB>