Zachary Kotlarek wrote: > On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote: > >> UGH. FWIW I really don't like this "feature". >> >> It causes the booted-with-initramfs case to require different >> handling from the booted-without-initramfs case, once the >> bootscripts are running, and therefore requires changes to the >> bootscripts if you use an initramfs. > > > Why? Can't you mount the devtmpfs both with and without the > initramfs?
Not if it's already mounted, unless you want to undo the modifications
that udev has made (by putting a new mount on top), or make changes to
the bootscripts (which is exactly what we're trying to avoid with this
setup). :-)
> And an atomic filesystem move is as simple as `mount --rebind /dev
> /new_root/dev`, or `mount --bind` if you want to leave it available
> both places.
Then do what with udevd? That's the hard part.
You can't just have it chroot on its own, because it doesn't do that.
You can't kill it, switch the rootfs, and restart it, or kill it, then
chroot and restart it, because you'll lose uevents that happen in
between those two steps. The kernel will happily send them to a netlink
socket that nobody is listening on. Plus, whatever you do in userspace
has to be atomic *with* the "mount --move", otherwise some process will
eventually wake up and find a udevd that doesn't agree with its view of
/dev.
You can't leave the bind mount in place permanently, because it'll be
confusing in /proc/mounts.
And you can't just leave udevd running in the initramfs environment,
because users expect to be able to edit /{lib,etc}/udev/rules.d and have
them take effect in the running daemon. (Not to mention what will
happen when the switch_root program deletes all the rules files, along
with all the support binaries, before chroot()ing and exec()ing
/sbin/init.)
At this point, you're going through insane contortions to buffer uevents
and do all kinds of other crazy, which I don't think is at all worth it.
Bite the bullet, make the bootup take another two seconds out of ten,
and redo the trigger. It's way more clean.
(Plus the lfs-bootscripts need to change to avoid starting udevd if it's
already running. More changes to them.)
What you're describing is possible, maybe. (Depends on that whole
atomic move-udevd-and-the-/dev-mount thing.) I really don't agree that
it's a good idea, however, given the upside (2 seconds less waiting)
compared to the downside (screwy contortions in userspace to get
everything to work properly).
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
