On Tuesday 22 February 2011 19:44:24 al...@verizon.net wrote: > Notes: 1. "cp ... console /dev" in 'udev' script doesn't work. > (apparently, too late in the boot sequence.) > > 2. For reasons unknown, even if I start with the > "metal" /dev empty, I end up with both "null" > and "console" nodes in /dev at the end of boot. > Go figure. > > The Udev police may get me one day but in the meantime I can > have my full, CLEAN console log _and_ still use the excellent > scripts Mr. Beekmans and all the other collaborators worked > hard to design for our use and enjoyment. Thank you all.
Having integrated udev almost from scratch for my advanced version of Smoothwall (I stole Debian's udev scripts), I've learned most of the ins and outs of udev, devtmpfs and what the kernel offers. If the option is enabled, the kernel has the ability to pre-populate /dev with all devices it knows about. Mounting devtmpfs on /dev triggers the action. The kernel will maintain its entries until something else touches them. Without this kernel facility, /dev must be pre-populated with a few (yes, 'few') nodes; /dev/pts usually needs to be made before mounting depts on it. Once devtmpfs is mounted and either prepopulated by the kernel or the booting system, udev can be started and triggered. It then walks the BIOS tree ins'ing modules for all devices it finds. When it replaces a kernel-made node, the kernel forgets about maintaining that node. It ain't easy figgerin' this stuff out. I upgraded my dev version to 2.6.35 weeks ago, and only Sunday did I find the last piece of the puzzle to get devtmpfs and udev working smoothly. The install bootup has no timing delays or pauses. Just create a single lock file, a single spin waiting for udev to start, a single wait for the lockfile to be erased, and a single wait for udev to settle. The rest of startup goes like grass through a goose. Booting to HD is even easier because USB isn't needed right off. I haven't checked to see if the kernel will populate /dev without using devtmpfs; it's working as-is: no sense in continuing the search for a solution. :) But that's the reward: figuring it out relying on partial documentation and improbable web search matches. Put simply, *something* creates nodes in /dev: - the build - the installer - the kernel - the initramfs/initrd init script - early userspace udev - the rootfs boot script - HD udev My media builder no longer pre-populates /dev with anything. And if I haven't already, I need to remove the stuff in /lib/udev used to prepopulate /dev. The kernel now takes care of all that when devtmpfs is mounted. I know my modernization of Smoothwall isn't LFS; I did borrow heavily from LFS during the early efforts to get 2.6.26 and 2.6.32 working, just as Smoothwall originally borrowed heavily from LFS when it was created years ago. But maybe my perspective will help someone else learn a little more about early user space, /dev and udev. N Speaking of the udev police... [rant] Digressing a little, I have a bone to pick with Kay Seivers and Greg K- H. Their attitude is that only symlinks should be used in /dev and created from udev rules (for the most part), and those symlinks may only be named with character sequences that are incomprehensible to ordinary humans. I believe they've overlooked the human factors aspect: that people cannot quickly pattern-match 50-byte filenames, that the kernel does not use symlink names in its reports (only the actual /dev node name), your primary hard drive may be hda today, sda tomorrow, sde the day after, and a couple other points. (Maybe I mispeak a little; Squebian Deeze uses partition names; now I cannot find *anywhere* the device associated with a FS! Aaaarrrgggh!) My bootup system works, but I may well enhance the udev scripts to create additional disk names (NAME+="..."), because hdX and sdX are now meaningless. I'll create /dev/dsk[a-z] nodes based on the drive's short ID; the kernel is free to use any name it wants to, and the admin will have a short, constant, neurally- friendly name to use. In fact, kernel device names should be put in a /dev/kernel tree, hidden from normal users. Human Factors needs to be brought back to Linux in this respect, because humans (admins) need to be able to quickly match node names against something their brains readily recognize as much as the OS itself needs to be able to unambiguously recognize node names. Don't get me wrong. Udev is great work; I really like it: it's eliminated a couple hundred lines of startup script. It's just that now is the time to start working human factors back into that equation to make Linux friendly again.[/rant] -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
