On Sunday 17 April 2011 01:26:59 DJ Lucas wrote:
> Ahh...lightbulb. This is why we currently have the udev-retry in our
> bootscripts.
This is probably getting outside of the 'LFS Support' realm.
Mayhap the next version of LFS will not need 'udev-retry' because either udev
works, or the system has not been programmed correctly.
I can't imagine why they'd get rid of 'settle' without providing a suitable
replacement. The booting system *must* know when the devices have been
created; it *must* wait until it knows that all necessary device nodes are
ready.
- devtmpfs is auto-populated with all devices the kernel knows; early
userspace contortions to provide a usable environment are no longer
needed
- udev fills in the rest of the devices, loading modules as needed
- "udevadm settle" 'pauses' booting until all device nodes are ready:
a second or two
- bootup continues
This scheme works for initramfs and for booting to disk. It works on bare
metal and in VMs. It works on single-core and multi-core CPUs.
Maybe some day in the future all startup scripts will check for the existence
of all device nodes they need and wait until they exist before proceeding. But
for now, bootup must pause until nodes are all created.
Honestly, if there's a rational for requiring a 'udev-retry', I've not seen
it; once I got the one optimal 'lock' set up, it all works without retries and
without failures, in RAM only or with hard/flash drive. Either all nodes are
ready before initramfs/initrd proceeds with its startup tasks or all nodes are
ready shortly after operation is pivoted to the final root's FS, depending on
when udev is run. If ya'll have seen reasons for 'udev-retry', please share
them.
I'm not saying this to belittle anyone or anyone's efforts. I'm saying it
because LFS *can* be improved. Udev may be *very* poorly documented, but it
does work.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
