M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Oliver Fromme <[EMAIL PROTECTED]> writes: > : 1- Why does the kernel try to mount /dev at all? Why not > : simply let init mount it in all cases, with ot without > : init_chroot? Would make things simpler. There doesn't > : seem to be a clear reason why the kernel needs to mount > : it. (Or maybe there _are_ reasons, byt they don't > : appear during my testing.) > > The kernel needs to mount /, and to do that it needs to have a /dev to > look things up in. Well, it actually mounts devfs on / before > looking up and mounting the real /. After it does that, it pivots the > devfs mounted on / into /dev, which is the source of the warning that > you see.
OK, it's clear to me now. Also thanks to Robert Watson for the detailed explanation. So the warning is caused by the inability of the "fixup" code to move the devfs mount from / to /dev. This is to be expected in the init_chroot case (because there's no /dev outside of the chroot), so the warning can be safely ignored. Just a small question: What happens with the devfs mount previously mounted on /? Does the kernel silently discard it when the fixup fails, or is it still "hanging around" somehow? I don't see it in mount(8) or df(1) output, so I assume it is discarded. > : 2- Another solution would be to let init(8) autodetect > : whether /dev needs to be mounted. However, that might > : not be as trivial as it sounds. > > Indeed. As far as I can tell, the -d fallback in init is totally > unused these days. Since the kernel doesn't have a general list of > args passed to init, but instead has to construct them one at time > from flags set by the boot loader, I'm pretty sure that it can't be > easily specified. Yes, that seems to be right. An idea that just came to my mind: init could call stat() on / and on /dev (_after_ calling chroot() if applicable), and if the devices (st_dev) are the same, then devfs isn't mounted yet, so the devfs flag must be set for init to proceed successfully. That kind of autodetection should work reliably in all cases. What do you think? Any way, the latest patch that you mailed works perfectly, as I wrote earlier. Should I submit a PR with that patch, or would that be unneccessary? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
