Re: Ruminations on Udev, null and console
Simon Geard wrote:
Not meaning to start an argument on that basis. But by 'modern'
desktops, I meant recent versions of Gnome or KDE, compared to more
lightweight setups.
As to the relevance to the thread, I know I didn't make that clear, but
my thinking was that device names really aren't very important to
someone using one of those desktops. My DVD drive may be called 'sr0',
Erm?
but more importantly, it's called CD/DVD drive on my desktop. And if I
plug in a USB drive, I really have no idea what the device node is
called - all that matters is that it's automatically mounted to
somewhere under /media and a file manager window opened on it.
I have a cordial dislike for such interfaces, and never use them.
I always open up a terminal window, and then cd to the relevant
mount point and browse around with a CLI. I really don't like
to use those GUI things. So, actually knowing where the mount
took place means quite a bit more to me than to you, I suspect.
Frankly, I dislike having things automatically mount. How does
the system know what I want to do with a rewritable CD-ROM I
just stuck in? Hmm?
For the same reason, recent kernel announcements about changing the
network device naming don't exactly bother me - as far as I'm concerned,
I have two network devices, called Wired and Wireless in Network
Manager. The kernel calls them eth0 and wlan0, but if a patch were to
rename them 'frog' and 'fish', I'd be unlikely to notice.
See, that's a significant difference in what one might call user
style. If you grew up with Windows 95, and love using a GUI interface,
then that may suit you. I don't know. I grew up with CP/M and really
do not like that style at all. So, it's useful to be able to know
what's going on.
Also, when things fail to work, it's hard to figure out what went
wrong with your GUI if you don't know where anything is.
As to the rest, it may be I've misunderstood your original post - the
confusion was over the claim that people are unaware they they have
those nodes on the metal /dev. Given these nodes are explicitly
created with a clear explanation as to why, it seemed to me that you
must have overlooked this section in the book.
I installed udev on my main machine several years back, and found that
I didn't like it much, if at all, and removed it. However, since that's
the way of all future Linux progress (if one may characterize it
thusly) I've just accepted it as something my LFS machines have on them.
Unfortunately, My Machine, My Rules only goes so far.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
As promised, I ran a number of tests to clarify Udev interaction with '/lib/udev/devices/' and the creation of some essential nodes during a boot-up. PRELIMINARIES A. [/sbin]$ strings udevd | grep devices /lib/udev/devices /devices/ So, 'udevd' is aware of '/lib/udev/devices/' directory and, as we will see later, has a keen interest in its contents. B. Excerpt of '/etc/rc.d/init.d/udev' script used during the tests. I inserted six Sample lines in the original script (their position in the udev script code is shown preceded by a +++ string, so as to stand out. start) +++ /dev content Sample No 1. boot_mesg Populating /dev with device nodes... ... if ! mountpoint /dev /dev/null; then mount -n -t tmpfs tmpfs /dev -o mode=755 ... +++ /dev content Sample No 2. ... echo /proc/sys/kernel/hotplug +++ /dev content Sample No 3. ... cp -a /lib/udev/devices/null /dev ... /sbin/udevd --daemon +++ /dev content Sample No 4. ... /sbin/udevadm trigger --action=add +++ /dev content Sample No 5. ... /sbin/udevadm settle evaluate_retval +++ /dev content Sample No 6. ;; C. The cp -a ...null /dev line above was commented out at all times. Actually, nothing ever changed in B. D. In Sample No 1. (i.e., the metal /dev) the 'null' node is always the same. Example (shown here in full), crw-rw-rw- 1 root root 1, 3 2011-02-23 06:28:02.0 null crw--w--w- 1 root root 5, 1 2011-03-04 13:14:57.0 console Consequently, Sample No 1. will not be covered further. Note: As already mentioned, I think 'console' is handled by the kernel itself (somehow). BTW, unlike 'null', the 'console' time and date always change. E. The Samples have been edited for conciseness, so only the node time is shown in what follows (i.e., no type, permissions, ownership, or major/minor numbers). F. System (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... FWIW, an excerpt of my 'fstab': devpts /dev/pts devpts gid=4,mode=620 0 0 shm /dev/shm tmpfs defaults0 0 Obviously, other people's mileage may vary. TEST RESULTS Test No 1. Missing (no) '/lib/udev/devices/' directory ~ Excerpt from console log: Remounting root file system in read-write mode... [ OK ] Recording existing mounts in /etc/mtab...[ OK ] Mounting remaining file systems... mount: mount point /dev/pts does not exist mount: mount point /dev/shm does not exist [ FAIL ] -- 'null' and 'console' presence: 'null': Sample No 5.: 2011-03-04 13:14:57.413999850 Sample No 6.: 2011-03-04 13:14:57.413999850 'console': Sample No 5.: 2011-03-04 13:14:57.416999850 Sample No 6.: 2011-03-04 13:14:57.416999850 Test No 2. '/lib/udev/devices/' with 'pts', 'shm' and 'null (no console) ~~~ NO console log problems. --- 'null' and 'console' presence: 'null': Sample No 4.: 2011-03-04 13:45:14.343999850 Sample No 5.: 2011-03-04 13:45:14.417999850 Sample No 6.: 2011-03-04 13:45:14.417999850 'console': Sample No 6.: 2011-03-04 13:45:14.431999850 Note: In '/lib/udev/devices/', 'pts' and 'shm' directories are empty. Test No 3. '/lib/udev/devices/' with 'pts', 'shm' and 'console' (no null) ~~ Excerpt from console log: Populating /dev with device nodes... cannot open /dev/null udevd[513]: cannot open /dev/null udevd-work[518]: open /dev/null failed: No such file or directory ... same for udevd-work[537], [538],[539],[540],[542],[545],[550],[575],[578],[588] and [605] ... FATAL: Module acpi:LNXSYSTM: not found. FATAL: Module pci:v8086d2983sv... not found. FATAL: Module pci:v8086d2930sv... not found. FATAL: Module pci:v8086d2940sv... not found. FATAL: Module pci:v8086d244Esv... not found. insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/agpgart.ko Linux agpgart interface v0.103 insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/intel-gtt.ko insmod /lib/modules/2.6.37.1/kernel/drivers/char/agp/intel-agp.ko agpgart-intel :00:00.0: Intel G35 Chipset agpgart-intel :00:00.0: detected gtt size: 524288K total, ... Notes: our mutual friend, LNXSYSTM, is being sorely missed here :). lines like insmod ... driver.ko, out in the open, look a little unusual to me, but what do I know ... -- 'null' and 'console' presence: Sample No 4: 2011-03-05 06:51:01.344999850 console Sample No 5: 2011-03-05 06:51:01.405999850 console Sample No 6: 2011-03-05 06:51:01.417999850 null 2011-03-05 06:51:01.420999850 console Note: 'null' makes its re-entrance after all (a little tardy, though). --
Re: Ruminations on Udev, null and console
Bruce Dubbs wrote: When I rebooted, I got the following messages: cannot open /dev/null ... FATAL: Module LNXSYTEM: not found ... When I added null back to /lib/udev/devices/ and reenabled the copy in the bootscripts, I got none of these messages. ... I don't have any modules to load. No console to update either. I agree that the /dev/null entries in mountkernfs could be removed by using the -q option for mountpoint. I suspect that option was added after the bootscript was written. Actually, on my system, those errors appeared to come up before any bootscripts were started. They came about 4 seconds into the boot. It takes about 8 or 9 seconds to get to the boot prompt. I think those 'module' errors are being generated by drivers built into the kernel. Note that LNXSYTEM is an ACPI device. Since the instruction to copy null to /dev occurs after the error message, I have no idea why they are coming up. Hi Bruce, 1. One thing at a time. To RE-recap the conclusions about null/console situation from my OP and the time-line post: 1.1. The null and console nodes MUST exist in the metal /dev directory before start-up. 1.2 If one follows the LFS script order, the null/console coverage is practically perfect. No gaps. 1.2.1. The metal null disappears after the line if ! mountpoint /dev while heroically taking the last direct hit: /dev/null 1.2.2. null reappears (practically reborn), through some mysterious machinations (more about that later) while still in udev (time-line, sections 5-7), which makes it impossible to be missed by anybody else: The udev script, what with 'udevadm settle' and all, makes sure that unless and until it is done, no other script, program, bash construct, etc. can start and potentially miss null. A corollary of this whole 1.2. is that no scripts ahead of udev can fail, be it the much maligned (by me) rc, or the others, even in their original form (without the -q, _with_ /dev/null). In other words, null (here, in the metal avatar) will always be there, for example to gracefully absorb any blows of the form ... /dev/null. 2. I wish I could help/explain your problem(s) including your suspicion that the udev null copy (or rather the lack of it) has something to do with the errors. I've been wrong before (so many times!). In the beginning of my tests/ruminations, as I mentioned, I made sure I use copies of the latest scripts in their exact sequence: LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... Note: I always boot to INIT level 3. (id:3:initdefault:) That may matter. If you find any similarities, I'd be more than willing to compare notes on this subject. It's definitely an intriguing project. 3. As a general comment, we are all aware that Udev has been a moving target, ever since its inception. No problem with that. It's just that you have to aim more carefully, but there's the risk of being hit right in the face when you become complacent and not continuously on the ball. My parents always told me to be careful with people who say 'if SoAndSo==?* then ...' instead of 'if SoAndSo!= then ...', which _is_ the the same thing, true, but shows those people might not talk straight. 3.1. I have NO idea how all those devices (null, etc.) appear in my main-line section 5, as if out of thin air. Does udevd take a peak in my forgotten directory '/lib/udev/devices' (we _know_ Udev _knows_ about '/lib/udev/', for the rules)? Does it have its own internal rules? On a personal level, this is to me the last missing piece of my otherwise pretty airtight (I think) coverage of Udev activities on _my_ system and _my_ hardware. I'll be away from the test machine for a couple of days. As soon as I'm back, you can be sure I'll start looking hard into this quandary and the copy implications. By way of an example, if you do 'strings udevd | egrep console|null' you get only /dev/null cannot open /dev/null open /dev/null failed: %m and no console, although the console node is there (in Sec. 5). Nor if you grep for console among the rules. Best regards, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
SYSTEM ~~ ASUS P5E-VM HDMI with Intel G35/ICH9R. Intel Core2 Duo CPU E8400 @ 3.00GHz, 4GB (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 PROBLEM ~~~ No problems. I'm just trying to recap and maybe bring this thread to a merciful end. In the following, I'm trying to present a time-line on my system showing the console and null activities. (i.e., back to the OP, but hopefully in a cleaner, logical fashion.:) So I ran a boot-up test with a few strategically placed time stamps in setclock, moutkernfs and udev scripts, a summary of the results shown below. The text can also serve as preparatory course for beginning students in 101 Udev :). Prerequisites: /sys and tmpfs. NOTES ~ No 'cp -a /lib/udev/devices/ ...' _whatsoever_ in udev script. The dates/times are shown in sequence (when applicable). The times are node/file _modification_ time. The creation and/or access times would just clutter up the text without bringing anything interesting to the table (IMHO). TIME STAMPS ~~~ 1. metal /dev: 2011-02-22 13:26:28.0 + console 2011-02-23 11:28:02.0 + null 2. Machine booting up. At start of mountkernfs (before the /proc and /sys mounts): 2011-02-28 14:43:58.0 -0500 console 2011-02-23 06:28:02.0 -0500 null 3. udev script (before 'mount ... tmpfs /dev ...'): 2011-02-28 14:43:58.0 -0500 console 2011-02-23 06:28:02.0 -0500 null 4. udev (after 'mount ... tmpfs /dev ...'): Nothing. The two metal /dev nodes are hidden now. 5. udev (after '/sbin/udevd --daemon'). All existing /dev nodes: 2011-02-28 14:43:58.285999850 -0500 stdout - /proc/self/fd/1 2011-02-28 14:43:58.285999850 -0500 stdin - /proc/self/fd/0 2011-02-28 14:43:58.285999850 -0500 stderr - /proc/self/fd/2 2011-02-28 14:43:58.295999850 -0500 shm 2011-02-28 14:43:58.295999850 -0500 pts 2011-02-28 14:43:58.295999850 -0500 null 2011-02-28 14:43:58.331999850 -0500 kmsg 2011-02-28 14:43:58.285999850 -0500 fd - /proc/self/fd 2011-02-28 14:43:58.285999850 -0500 core - /proc/kcore 2011-02-28 14:43:58.295999850 -0500 console 6. udev (after '/sbin/udevadm trigger --action=add') Same as 5. above (i.e., no time changes, no new devices) 7. udev (after '/sbin/udevadm settle') Note: Practically most /dev nodes are now in place. Only our important friends, console and null, are shown: 2011-02-28 14:43:58.374999850 -0500 console 2011-02-28 14:43:58.375999850 -0500 null 8. For reference only: 8.1. After INIT: version 2.86 booting Before mountkernfs:2011-02-28 14:43:58.039068843 8.2. setclock, after Setting system clock... 2011-02-28 19:44:01.000687543 8.3. Just before the prompt (last line in rc.local): 2011-02-28 19:44:03.472291634 8.4. Last reboot: Mon Feb 28 19:44:01 FINAL WORDS ~~~ A. Please notice that the date of console changes between (1) and (2) above to boot date and time. My only explanation (a little weak) is that happens when the kernel creates the console. - Excerpt from console log: ... NR_IRQS:320 Console: colour VGA+ 80x25 console [tty0] enabled Fast TSC calibration using PIT Detected 3005.093 MHz processor. ... - This seems to be confirmed by 'sys.log' and 'kernel.log' Feb 28 19:44:01 localhost kernel: NR_IRQS:320 Feb 28 19:44:01 localhost kernel: CPU 0 irqstacks, ... Feb 28 19:44:01 localhost kernel: Console: colour VGA+ 80x25 Feb 28 19:44:01 localhost kernel: console [tty0] enabled Feb 28 19:44:01 localhost kernel: hpet clockevent registered Feb 28 19:44:01 localhost kernel: Fast TSC calibration using PIT Feb 28 19:44:01 localhost kernel: Detected 3005.251 MHz processor. B. According to my tests, the metal console is needed. Without it, for reasons unknown, there's no LFS console display (NO boot_mesg() output, OK, etc) at boot. After that, the display mysteriously becomes active. Say, /etc/rc.d/init.d/gpm restart Stopping gpm... [ OK ] Starting gpm... [ OK ] This one I cannot explain, even weakly. C. As nit-pickings (no urgency, we know how long it takes to change will with must in the next (almost) daily revision of the book:) C.1. 6.2.21 should say must instead of will C.2. The whole Create some devices and directories ... in udev-1xx should go. Misleading, outdated and nonsensical. C.3. Instead, users should be urged to boot their /dev partition for somewhere else (another partition, LiveCD) and make sure they have these two, and preferably only these two nodes set up. Thanks you all for your contributions, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
al...@verizon.net wrote: C. As nit-pickings (no urgency, we know how long it takes to change will with must in the next (almost) daily revision of the book:) C.1. 6.2.21 should say must instead of will OK, we can do this. It's in section 6.2.1, not 6.2.21. C.2. The whole Create some devices and directories ... in udev-1xx should go. Misleading, outdated and nonsensical. No, it really can't go. I went into my sandbox, deleted /lib/udev/devices/null, and commented out the copy to /dev in the udev bootscript. When I rebooted, I got the following messages: cannot open /dev/null FATAL: Module platform: regulatory not set FATAL: Module LNXSYSTEM: not found FATAL: Module doc not found FATAL: pci:v... not found This last was repeated about 20 times for various pci values. When I added null back to /lib/udev/devices/ and reenabled the copy in the bootscripts, I got none of these messages. The system did boot in both cases, but we can't advocate a system that produces these errors. Unfortunately, the error messages did not show up in dmesg. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Bruce Dubbs wrote,
It's in section 6.2.1, not 6.2.21
Hi Bruce,
Typo. Sorry.
C.2. The whole Create some devices and directories ... in
udev-1xx should go. Misleading, outdated and nonsensical.
No, it really can't go. I went into my sandbox, deleted
/lib/udev/devices/null, and commented out the copy to /dev in the udev
bootscript.
When I rebooted, I got the following messages:
cannot open /dev/null
FATAL: Module platform: regulatory not set
FATAL: Module LNXSYSTEM: not found
FATAL: Module doc not found
FATAL: pci:v... not found
This last was repeated about 20 times for various pci values.
When I added null back to /lib/udev/devices/ and reenabled the copy in
the bootscripts, I got none of these messages.
Awful. A few thoughts.
As I said in my OP:
LFS book: Version SVN-20110218
Script activation order in '... rcsysinit.d/':
mountkernfs
consolelog
modules (no modules to install, in my case)
udev
...
iN MY PREvious post, sections 5-7, null (and console) is already fully
represented. Unfortunately, modules comes before udev:
In modules,
modprobe ${module} ${args} /dev/null
# Print the module name if successful,
# otherwise take note.
if [ $? -eq 0 ]; then
boot_mesg -n ${module} ${NORMAL}
else
...
the construct /dev/null could be avoided, I think.
'modprobe' offers -q (like 'mountpoint', previously) without
any apparent loss of functionality (if [ $? -eq 0 ] ...).
If you use -q in mountkernfs and udev, the only null's left
are in rc, in the two 'for' loops:
for i ... 2 /dev/null
I just removed the 2 /dev/null and I haven't encountered
any problems as yet (nor extra messages on the console log).
I'm definitely uneasy for situations like,
ls -v /etc/rc.d/rc4.d/K*
ls: cannot access /etc/rc.d/rc4.d/K*: No such file or directory
for level 4 and also for 5.
Obviously, there are a gazillion of systems out there
and this is just one of the myriad ways to skin a cat.
(I do with compassion:)
Thank you for your comments,
-- Alex
For reference, an extract from my OP:
[udev]
The irony here is that 'mountpoint' offers a -q option.
2. mountkernfs script coming before udev in the boot
sequence (_has_ to mount 'sys') has two offending lines
with /dev/null. Can be corrected with a -q.
A bigger problem is presented by rc.
rc is the first in line, so to speak, so it can get ugly.
Has two for lines with 2 /dev/null.
My system hangs, with two error lines around INIT:
... init.d/rc: ... /dev/null: Read-only file system
I deleted the two 2 /dev/null's, and damn the torpedoes.
So far, I've lived to tell this story here.
Please note that (2) rc above was happening when
I was experimenting with NO metal null.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
al...@verizon.net wrote: Bruce Dubbs wrote, When I rebooted, I got the following messages: cannot open /dev/null FATAL: Module platform: regulatory not set FATAL: Module LNXSYTEM: not found FATAL: Module doc not found FATAL: pci:v... not found This last was repeated about 20 times for various pci values. When I added null back to /lib/udev/devices/ and reenabled the copy in the bootscripts, I got none of these messages. Awful. A few thoughts. As I said in my OP: LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... iN MY PREvious post, sections 5-7, null (and console) is already fully represented. Unfortunately, modules comes before udev: I don't have any modules to load. No console to update either. I agree that the /dev/null entries in mountkernfs could be removed by using the -q option for mountpoint. I suspect that option was added after the bootscript was written. Actually, on my system, those errors appeared to come up before any bootscripts were started. They came about 4 seconds into the boot. It takes about 8 or 9 seconds to get to the boot prompt. I think those 'module' errors are being generated by drivers built into the kernel. Note that LNXSYTEM is an ACPI device. Since the instruction to copy null to /dev occurs after the error message, I have no idea why they are coming up. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On 02/25/2011 04:38 PM, Bruce Dubbs wrote: Neal Murphy wrote: On Friday 25 February 2011 15:02:23 Bruce Dubbs wrote: It looks like the process is: 1. Use null and console at the start. 2. Mount a tmpfs on /dev hiding the original null and console devices. 3. Create all new devices, including null, on the tmpfs via udev and the boot script. Newer versions of udev or the kernel may make some of these procedures unnecessary, but they don't hurt anything. A device node takes up 1 directory entry and no additional space. I don't understand what appears to be a sense of urgency in your post. What are the drawbacks of the procedure as is? You are quite right. Your three steps work fine and hurt nothing. The drawback is slightly elevated code complexity in building and preparing the system, booting it, as well as the effort to keep and maintain that code. Enabling CONFIG_DEVTMPFS_MOUNT in the kernel (2.6.32+, I believe) reduces the steps to: 1. Mount devtmpfs on /dev; the kernel populates it with devices it knows 2. Run udev to 'take over' those nodes and populate it with everything else Interesting. I hadn't noticed these changes. I had seen the extra configuration item, but didn't put two and two together and simply ignored it as unnecessary baggage (fortunately it actually is with our current boot scripts). Guess I'm getting a little slow. I still haven't looked at it yet, just working from Neal's comments. I don't understand your comment about effort to keep and maintain the code. There were a couple of minor text changes about 7 months ago and prior to that, basically no changes for four years. The comment was only to say that it is now unnecessary. The biggest problem I see for your methodology is that it requires a specific kernel configuration. We don't do that anywhere in the book. We do mention some optional configurations in Chapter 8. Actually, we do. The kernel must be built with tmpfs support as required by udev. Why not extend that and require that devtmpfs support be built-in as well? Assuming it works, and I've no reason to doubt that it does (only that I haven't tested myself), we remove a few lines from the udev script, the mountkernfs script gets a change, a new recommendation is added to the book where the current one is, and a small section of the book is rendered unnecessary - yes the information gets locked away in a little black box, but IMO, that happened 5 years ago when the makedev script went away. The concept of device nodes (and even the devices.txt included with the kernel) is probably already lost to the younger users until it becomes necessary to create one that udev knows nothing about (and those are few and far between). Nothing really lost here, and a small gain in efficiency. The old race car bit fits nicely here: don't look for 1 place to loose 100 pounds; look for 100 places to loose 1 pound. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Fri, 2011-02-25 at 22:12 -0600, Bruce Dubbs wrote: I suspect you have to add -L volume-label to mke2fs (or other partition formatting tool) for at least one partition for by-label to be created. Ah, yes, that makes sense - if the directory is created by the presence of symlinks within it, then it won't be present unless you have labeled volumes present. My root partitions don't have labels, for example, and so aren't listed... For interest, the directory looks something like: $ ll /dev/disk/by-label/ total 0 lrwxrwxrwx 1 root root 10 Feb 28 18:07 boot - ../../sda1 lrwxrwxrwx 1 root root 10 Feb 28 18:07 home - ../../sda6 lrwxrwxrwx 1 root root 10 Feb 28 18:07 oldboot - ../../sdb1 lrwxrwxrwx 1 root root 10 Feb 28 18:07 oldhome - ../../sdb7 lrwxrwxrwx 1 root root 10 Feb 28 18:07 swap - ../../sda2 Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Wed, 2011-02-23 at 14:41 -0500, Neal Murphy wrote: On Wednesday 23 February 2011 04:54:10 Simon Geard wrote: Are you unaware then, that udev provides the /dev/disks/by-label directory, which contains volume labels as symlinks to the kernel-named devices? For example, my fstab file doesn't reference /dev/sda6 for the /home partition - it uses /dev/disk/by-label/home instead. Likewise, /boot is mounted as /dev/disk/by-label/boot and the swap partition as /dev/disk/by-label/swap. You must be superhuman, able to memorize names like 485cc6bb- ef7f-44ca-91c4-55d884c4083e, 4e23b7e0-af66-45b3-b0c2-a5af31c14c1b, 5e34b5db-1fa8-49e7-9250-fb95ea301579, 73B115E331E98B57, 74fbc4cd-784e-49fc-8d24-ca51623ba15c, 965800A05800816B, bbde5991- c72e-424f-97eb-00acfba10aff, f3ab5997-5ecd-4486-ab86-4fd172d714ea, which parritions they are and which HDs they belong to. Huh? Who said anything about names like that? Sure, you can mount by uuid if you really want, but I said by *label*. It doesn't seem particularly superhuman to remember that /home is found at /dev/disks/by-label/home. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Wed, 2011-02-23 at 11:24 -0600, Bruce Dubbs wrote: What am I missing? My latest only has $ ls /dev/disk by-id by-path by-uuid Odd - I see those, and by-label too. My main desktop is a little old now (about ten months old, running udev 151), but I can't see them dropping that feature. I'll have to try on an SVN build... What do you get when you do something like 'df -h'? That shows the real device, /dev/sda1, so I admit the symlink approach isn't perfect. I mention it mostly in reply to Neal's assertion that symlinks may only be named with character sequences that are incomprehensible to ordinary humans. Using the human-assigned volume labels seems fairly friendly to me... Also, I like to see how my disk is organized. I will do 'fdisk -l /dev/sda' How would you do something like this? Given that I only have the one disk, it's not too hard to remember that it's /dev/sda. That said, Gnome Disk Utility provides a very good GUI for that sort of thing - browse all storage devices, show partitioning, format voumes, etc... Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Wed, 2011-02-23 at 12:24 -0600, al...@verizon.net wrote: BTW, there is a [rant][/rant] I'm skipping, although the idea is not the first time to come up, where people grow from LFS to BLFS and become confused and/or _misunderstood_ about falling behind on the latest and greatest developments in LFS (my LFS system was built early 2005). I'm guessing you don't run a 'modern' desktop then? It's pretty much impossible to build and run a modern Gnome desktop without using udev - mostly because udev these days isn't just about populating /dev nodes, it's also how you identify what hardware is present. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Feb 25, 2011 04:26:29 AM, Simon Geard wrote: On Wed, 2011-02-23 at 12:24 -0600, al...@verizon.net wrote: BTW, there is a [rant][/rant] I'm skipping, although the idea is not the first time to come up, where people grow from LFS to BLFS and become confused and/or _misunderstood_ about falling behind on the latest and greatest developments in LFS (my LFS system was built early 2005). I'm guessing you don't run a 'modern' desktop then? It's pretty much impossible to build and run a modern Gnome desktop without using udev - mostly because udev these days isn't just about populating /dev nodes, it's also how you identify what hardware is present. Hi Simon, There's a very unfortunate misunderstanding here. Maybe in debating with Neil and Bruce lately on my thread you forgot who started the thread, _why_ and how. However, it may be mostly my fault here, what with my rambling and incoherent style of mine; whatever, I'll try my level best to restate the situation as clearly as I can, and to avoid redundancy, to use mostly cut-and-paste sections from my original statements (made in my only _two_ posts). Enclosed in double angle brackets. 1. The _very first_ paragraph of my OP: SYSTEM (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 LFS book: Version SVN-20110218 Does it look like I don't run a 'modern' desktop? It's for you to decide. :) without using udev?: Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... INTRODUCTION While my system has worked well for a long time, a few lines (actually, two commands) in the 'udev' script like ... started to puzzle me more and more as time passed ... It's for you to decide :) 2. _Strictly_ for the record and completeness: I do no use Gnome. Never have. I use KDE (3.5.10) and Fluxbox (1.1.1). However, IMHO this is absolutely irrelevant as far as the thread subject is concerned. Unfortunately, the above admission might trigger another unrelated debate :( I'm resigned to it, though; you win a few lose a few. 3. Now, for my main subject, restated and summarized differently, in desperate hopes of making it clearer. 3.1. Don't remember exactly what Udev I started with and when. I came across some e-mails to Kay Sievers (of April, 2007): ... 686-pc-linux-gnu (B)LFS 2.6.20 UDEV upgrade from 105 (OK) to 108. ... I also don't remember if 6.2.21 was in the exact, clear form you cited to me (excerpt here), When the kernel boots the system, it requires the presence of a few device nodes, in particular the console and null devices. The device nodes will be created on the hard disk so that they are available before udevd has been started, and additionally when Linux is started with init=/bin/bash. Create the devices by running the following commands: ... (while we're talking about clarity here, a little nitpick: will be created should be replaced with must be created) It wouldn't matter anyway, because as I said I had had those two nodes [on the metal /dev] all along (instinctively) I set up my metal /dev with ... crw--- ... 5, 1 ... /dev/console and also ... crw-rw-rw- ... 1, 3 ... /dev/null 3.2. The PROBLEM (the actual object of the OP) has been my worries started recently when _finally_ a [light] bulb went [off] in my head on reading # Create some devices and directories that Udev cannot handle # due to them being required very early in the boot process, # or by Udev itself: ... mknod -m0666 /lib/udev/devices/null c 1 3 in the LFS udev-166 procedure AND # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev in the latest udev script. In other words, the above two commands are in contradiction to 6.2.21 (as cited by you), and redundant (and _misleading_) . I.e., in yet some other words, the author(s) of the udev script and udev installation procedure (this fallacy goes back quite a few iterations from 166) should re-read 6.2.21 even harder than me. In delicate terms, there should be a co-ordination somewhere. So I ... started testing (and ruminating) hard. 3.3. Speaking of co-ordination, and my [rant][/rant] ... skipping in a few words, it appears that for some reason, in some quarters it can be incomprehensible the fact that one can simply graduate from LFS to BLFS (_on the same system_, no less!) while being forced to keep up with Udev, Kernel versions and latest scripts, and/or electing to partake of some other goodies that LFS offers. The post I'm responding to seems to be an example of that. Thanks, -- Alex PS Could it be I write (B)LFS and there's another shortcut more accepted and better conveying the fact that I'm talking about a system that started as LFS (in 2005, as I said) and grew to BLFS ? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ:
Re: Ruminations on Udev, null and console
al...@verizon.net wrote: 3.2. The PROBLEM (the actual object of the OP) has been my worries started recently when _finally_ a [light] bulb went [off] in my head on reading # Create some devices and directories that Udev cannot handle # due to them being required very early in the boot process, # or by Udev itself: ... mknod -m0666 /lib/udev/devices/null c 1 3 in the LFS udev-166 procedure AND # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev in the latest udev script. In other words, the above two commands are in contradiction to 6.2.21 (as cited by you), and redundant (and _misleading_) . I.e., in yet some other words, the author(s) of the udev script and udev installation procedure (this fallacy goes back quite a few iterations from 166) should re-read 6.2.21 even harder than me. In delicate terms, there should be a co-ordination somewhere. I haven't looked at this code in quite a while, but I don't see these instructions as contradictory. It looks like the process is: 1. Use null and console at the start. 2. Mount a tmpfs on /dev hiding the original null and console devices. 3. Create all new devices, including null, on the tmpfs via udev and the boot script. Newer versions of udev or the kernel may make some of these procedures unnecessary, but they don't hurt anything. A device node takes up 1 directory entry and no additional space. I don't understand what appears to be a sense of urgency in your post. What are the drawbacks of the procedure as is? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Neal Murphy wrote: On Friday 25 February 2011 15:02:23 Bruce Dubbs wrote: It looks like the process is: 1. Use null and console at the start. 2. Mount a tmpfs on /dev hiding the original null and console devices. 3. Create all new devices, including null, on the tmpfs via udev and the boot script. Newer versions of udev or the kernel may make some of these procedures unnecessary, but they don't hurt anything. A device node takes up 1 directory entry and no additional space. I don't understand what appears to be a sense of urgency in your post. What are the drawbacks of the procedure as is? You are quite right. Your three steps work fine and hurt nothing. The drawback is slightly elevated code complexity in building and preparing the system, booting it, as well as the effort to keep and maintain that code. Enabling CONFIG_DEVTMPFS_MOUNT in the kernel (2.6.32+, I believe) reduces the steps to: 1. Mount devtmpfs on /dev; the kernel populates it with devices it knows 2. Run udev to 'take over' those nodes and populate it with everything else I don't understand your comment about effort to keep and maintain the code. There were a couple of minor text changes about 7 months ago and prior to that, basically no changes for four years. The biggest problem I see for your methodology is that it requires a specific kernel configuration. We don't do that anywhere in the book. We do mention some optional configurations in Chapter 8. Your methodology is significantly different from LFS. You mention using klibc and initramfs, neither of which are mentioned in the book. Your modifications are great. After all, it's your distro, and you get to make your rules. I just don't think your methods are appropriate for LFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Feb 25, 2011 03:11:51 PM, Bruce Dobbs wrote: I haven't looked at this code in quite a while, but I don't see these instructions as contradictory. Hi Bruce, I commented out 'cp -a /lib/udev/devices/null /dev' in udev script. and did a reboot. _I_ didn't notice any changes (messages, etc.) in the console log on boot. Nor in dmesg. However, it's possible that my basic system differs somehow, somewhere on LFS boot. Newer versions of udev or the kernel may make some of these procedures unnecessary, but they don't hurt anything. A device node takes up 1 directory entry and no additional space. Agreed. BTW, I didn't say they are contradictory. Just redundant (and _misleading_). Misleading (IMHO) because either use both copies (i.e., _and_ console) or none at all. Let's not forget, though, I started with ruminations, not complaints (or some such). I don't understand what appears to be a sense of urgency in your post. No urgency (or sense of it) at all: _finally_ ... this fallacy goes back quite a few iterations from 166. However, I apologize for the word fallacy. Way too strong and misleading:). What are the drawbacks of the procedure as is? None. It works. I did express my gratitude to all involved for their hard work to make our life easier. --- I do have a confusion underlying this thread. I have claimed (possibly wrongly), the Udev philosophy assumes a /dev absolutely empty. Are the initial (metal) null and console nodes an LFS specific requirement (based on its particular boot/log sequence I tested and confirmed by 2.6.21), is it sanctioned by Udev developers, and/or a pure Udev is supposed to start with /dev really empty? Thank you very much, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
al...@verizon.net wrote: I do have a confusion underlying this thread. I have claimed (possibly wrongly), the Udev philosophy assumes a /dev absolutely empty. Are the initial (metal) null and console nodes an LFS specific requirement (based on its particular boot/log sequence I tested and confirmed by 2.6.21), is it sanctioned by Udev developers, and/or a pure Udev is supposed to start with /dev really empty? I really don't know. I didn't get involved with this directly when it was being developed four or five years ago. At the time, I think it was needed or we wouldn't have put it in. Since that time, it may well have changed, but (IMO) it's not important enough to change. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Fri, 2011-02-25 at 22:11 +1300, Simon Geard wrote: On Wed, 2011-02-23 at 11:24 -0600, Bruce Dubbs wrote: What am I missing? My latest only has $ ls /dev/disk by-id by-path by-uuid Odd - I see those, and by-label too. My main desktop is a little old now (about ten months old, running udev 151), but I can't see them dropping that feature. I'll have to try on an SVN build... Just checked, the by-label directory is also present on my SVN build running udev 166. I wonder if this is provided by the 'extras' which we disable in LFS due to dependencies, but which are present on my system due to reinstalling udev during BLFS. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Fri, 2011-02-25 at 13:21 -0600, al...@verizon.net wrote: 2. _Strictly_ for the record and completeness: I do no use Gnome. Never have. I use KDE (3.5.10) and Fluxbox (1.1.1). However, IMHO this is absolutely irrelevant as far as the thread subject is concerned. Unfortunately, the above admission might trigger another unrelated debate :( I'm resigned to it, though; you win a few lose a few. Not meaning to start an argument on that basis. But by 'modern' desktops, I meant recent versions of Gnome or KDE, compared to more lightweight setups. As to the relevance to the thread, I know I didn't make that clear, but my thinking was that device names really aren't very important to someone using one of those desktops. My DVD drive may be called 'sr0', but more importantly, it's called CD/DVD drive on my desktop. And if I plug in a USB drive, I really have no idea what the device node is called - all that matters is that it's automatically mounted to somewhere under /media and a file manager window opened on it. For the same reason, recent kernel announcements about changing the network device naming don't exactly bother me - as far as I'm concerned, I have two network devices, called Wired and Wireless in Network Manager. The kernel calls them eth0 and wlan0, but if a patch were to rename them 'frog' and 'fish', I'd be unlikely to notice. As to the rest, it may be I've misunderstood your original post - the confusion was over the claim that people are unaware they they have those nodes on the metal /dev. Given these nodes are explicitly created with a clear explanation as to why, it seemed to me that you must have overlooked this section in the book. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Simon Geard wrote:
On Fri, 2011-02-25 at 22:11 +1300, Simon Geard wrote:
On Wed, 2011-02-23 at 11:24 -0600, Bruce Dubbs wrote:
What am I missing? My latest only has
$ ls /dev/disk
by-id by-path by-uuid
Odd - I see those, and by-label too. My main desktop is a little old
now (about ten months old, running udev 151), but I can't see them
dropping that feature. I'll have to try on an SVN build...
Just checked, the by-label directory is also present on my SVN build
running udev 166. I wonder if this is provided by the 'extras' which we
disable in LFS due to dependencies, but which are present on my system
due to reinstalling udev during BLFS.
I don't think 'extras' has anything to do with it. It appears to be
done in rules/rules.d/60-persistent-storage.rules
ENV{ID_FS_USAGE}==filesystem|other, ENV{ID_FS_LABEL_ENC}==?*,
SYMLINK+=disk/by-label/$env{ID_FS_LABEL_ENC}
When I do dumpe2ds /dev/sda1, I get:
Filesystem volume name: none
I suspect you have to add -L volume-label to mke2fs (or other partition
formatting tool) for at least one partition for by-label to be created.
tune2fs can also be used to add a label to a partition, but I don't know
if the udev would pick that up right away or if a reboot would be needed.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Simon Geard wrote: As to the rest, it may be I've misunderstood your original post - the confusion was over the claim that people are unaware they they have those nodes on the metal /dev. Given these nodes are explicitly created with a clear explanation as to why, it seemed to me that you must have overlooked this section in the book. Also note what it says in the udev README: Setup: - At bootup, the /dev directory should get the 'devtmpfs' filesystem mounted. Udev will manage permissions and ownership of the kernel-created device nodes, and possibly create additional symlinks. If needed, udev also works on an empty 'tmpfs' filesystem, but some static device nodes like /dev/null, /dev/console, /dev/kmsg are needed to be able to start udev itself. Even this appears to be a bit outdated because we don't need /dev/kmsg. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Tue, 2011-02-22 at 22:38 -0500, Neal Murphy wrote: [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.[/rant] Are you unaware then, that udev provides the /dev/disks/by-label directory, which contains volume labels as symlinks to the kernel-named devices? For example, my fstab file doesn't reference /dev/sda6 for the /home partition - it uses /dev/disk/by-label/home instead. Likewise, /boot is mounted as /dev/disk/by-label/boot and the swap partition as /dev/disk/by-label/swap. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Tue, 2011-02-22 at 18:44 -0600, al...@verizon.net wrote: Unaware, many people still carry a lot of old stuff (including console and null) on their metal /dev. Not accidental. You should re-read Preparing Virtual Kernel File Systems in the LFS book, specifically section 6.2.1 in the current development version, which I quote here for reference: 6.2.1. Creating Initial Device Nodes When the kernel boots the system, it requires the presence of a few device nodes, in particular the console and null devices. The device nodes will be created on the hard disk so that they are available before udevd has been started, and additionally when Linux is started with init=/bin/bash. Create the devices by running the following commands: mknod -m 600 $LFS/dev/console c 5 1 mknod -m 666 $LFS/dev/null c 1 3 In short, those nodes are supposed to be there in /dev on the root partition. If you don't have them, you've missed a step in the build. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Simon Geard wrote: On Tue, 2011-02-22 at 22:38 -0500, Neal Murphy wrote: [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.[/rant] Are you unaware then, that udev provides the /dev/disks/by-label directory, which contains volume labels as symlinks to the kernel-named devices? For example, my fstab file doesn't reference /dev/sda6 for the /home partition - it uses /dev/disk/by-label/home instead. Likewise, /boot is mounted as /dev/disk/by-label/boot and the swap partition as /dev/disk/by-label/swap. What am I missing? My latest only has $ ls /dev/disk by-id by-path by-uuid What do you get when you do something like 'df -h'? Also, I like to see how my disk is organized. I will do 'fdisk -l /dev/sda' How would you do something like this? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
Feb 23, 2011 04:58:10 AM, Simon Geard wrote: ... those nodes [null and console] are supposed to be there in /dev on the root partition. If you don't have them, you've missed a step in the build. Hi Simon, We're totally in sync here (if you take a look at the grand finale of my OP :) I had had those two nodes all along (instinctively) and everything had been fine. To clarify: my worries started recently when _finally_ a bulb went on in my head on reading Create some devices and directories that Udev cannot handle due to them being required very early in the boot process, or by Udev itself: ... mknod -m0666 /lib/udev/devices/null c 1 3 in the LFS udev-166 procedure AND followed by # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev in the latest udev script. So I said (to myself), something must be different now i.e., there's no way somebody would've added (or retained) the redundant (and _misleading_) null copy above unless something changed (from 6.2.1 - or, come to think of it, from common sense). It is not unknown, even in the heavily computerized world of ours, for things to be changed (updated, as they say) in only _some_ of the related places. So I went back to the LFS scripts, made sure I was using the most recent ones and started testing (and ruminating) hard. BTW, there is a [rant][/rant] I'm skipping, although the idea is not the first time to come up, where people grow from LFS to BLFS and become confused and/or _misunderstood_ about falling behind on the latest and greatest developments in LFS (my LFS system was built early 2005). Thank you for your (as always) insightful comments, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ruminations on Udev, null and console
On Wednesday 23 February 2011 04:54:10 Simon Geard wrote: Are you unaware then, that udev provides the /dev/disks/by-label directory, which contains volume labels as symlinks to the kernel-named devices? For example, my fstab file doesn't reference /dev/sda6 for the /home partition - it uses /dev/disk/by-label/home instead. Likewise, /boot is mounted as /dev/disk/by-label/boot and the swap partition as /dev/disk/by-label/swap. You must be superhuman, able to memorize names like 485cc6bb- ef7f-44ca-91c4-55d884c4083e, 4e23b7e0-af66-45b3-b0c2-a5af31c14c1b, 5e34b5db-1fa8-49e7-9250-fb95ea301579, 73B115E331E98B57, 74fbc4cd-784e-49fc-8d24-ca51623ba15c, 965800A05800816B, bbde5991- c72e-424f-97eb-00acfba10aff, f3ab5997-5ecd-4486-ab86-4fd172d714ea, which parritions they are and which HDs they belong to. Most ordinary humans really want to know that *this* hard drive is 'dska' and *that* hard drive is 'dskb', and want to see and use those names. They don't want to be mistyping ridiculously long, obscure, patternless, hexadecimal file names the few times they need to admin their systems. They don't want to be spelunking through their filesystems painstakingly matching random hex digits to be sure they are pulling the failed drive and not a good one. They want to fix the system and get back to using it. That I've been spelunking through systems from TOPS-10, through the various PDP-11 OSen, VMS, UNIX, Linux, Solaris, SCO, OS/9, BeOS, Haiku, et al and can find what I need to know is beside the point. I just remember that there are folks who are not experts in the subject but who still need to learn how to work with it. I'm not saying they should be molly-coddled; rather, I'm saying their level of knowledge and expertise should be taken into consideration. In the case of udev and its present 'status', Human Factors has been discarded. I'm also cognizant that LFS is a 'teaching' system that doesn't just ape what other distributions do. It might be useful to do more teaching in the fields of early userspace and udev. To return to the topic, without using the specific kernel feature, DEVTMPFS, one must manually create certain nodes in /dev in order to boot the system, even if one is using udev. If you mount a devtmpfs, the kernel will prepopulate it with the basic nodes it knows about; even here, a few nodes must exist in /dev in the initramfs. But if one enables the related kernel feature, DEVTMPFS_MOUNT, the kernel will automount a devtmpfs on the rootfs' /dev and populate it; with this feature, one can boot with 'init=/bin/sh' into a fully working shell with a minimal initramfs/initrd. These are the only cases that I know of in which nodes are automagically created in /dev. All others depend on user-space programs to create such nodes. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Ruminations on Udev, null and console
Hello, SYSTEM (B)LFS i686-pc-linux-gnu, 2.6.37.1, Udev-166 LFS book: Version SVN-20110218 Script activation order in '... rcsysinit.d/': mountkernfs consolelog modules (no modules to install, in my case) udev ... INTRODUCTION While my system has worked well for a long time, a few lines (actually, two commands) in the 'udev' script like # Mount a temporary file system over /dev, so that any devices # made or removed during this boot don't affect the next one. if ! mountpoint /dev /dev/null; then mount -n -t tmpfs tmpfs /dev -o mode=755 and later on # Copy the only static device node that Udev = 155 doesn't # handle to /dev cp -a /lib/udev/devices/null /dev started to puzzle me more and more as time passed. The results of my reflections and relatively extensive testing are presented in the following SUBJECT. Of course, I can be totally or partially wrong in my conclusions (no surprise here:). However, maybe there's something for some of us to learn if a gentle, knowledgeable soul (or two) will take the time to look at my words and make some useful comments and/or straighten me out if need be. SUBJECT 1. Based on the basic UDEV philosophy (and reiterated in the 'udev' script comments (above, the # lines)), /dev should be populated with only nodes for devices existing on or strictly needed by the particular system when active. While not specifically stated, one can assume that before booting, the machine's metal /dev should be totally empty. By metal /dev, I mean the main '/dev' directory as it sits passively on the pure metal, as seen from, say, a booted LiveCD. As an example, for my Linux system on /dev/sda3: mount ... /dev/sda3 /mnt ls -l /mnt/dev The output should show an empty '/mnt/dev' (again, if one reads the main Udev concept correctly). In this case the construct /dev/null in the mount is wrong, especially as the second command confirms we do need a '/dev/null' node, not present as yet. (the smoking gun is a console message complaining that ... rcsysinit.d/S10udev: ... /dev/null: Read-only file system More about console later) The irony here is that 'mountpoint' offers a -q option. 2. mountkernfs script coming before udev in the boot sequence (_has_ to mount 'sys') has two offending lines with /dev/null. Can be corrected with a -q. A bigger problem is presented by rc. rc is the first in line, so to speak, so it can get ugly. Has two for lines with 2 /dev/null. My system hangs, with two error lines around INIT: ... init.d/rc: ... /dev/null: Read-only file system I deleted the two 2 /dev/null's, and damn the torpedoes. So far, I've lived to tell this story here. 3. However, two questions I agonized the most over: 3.1. How come, despite all these problems I found on my machine people reboot their systems day in and day out without any reported complaints? If they had any grievances on this subject, they'd be out in the streets like anybody else these days. Am I the only confused fella here ?! 3.2. How come people are not missing the beautiful (and useful) console boot displays [boot_mesg() in functions] which, on my system would not appear unless my metal /dev contained the console node. A partial explanation, I said (to myself) would be the introduction of KMS on all modern Linux releases. We've already seen some of the benefits of this invention; the first section of the boot console log vanishes forever (with all the juicy stuff) at the point the KLM module is loaded (late), so if the machine comes up good, who cares!? (based on the old adage, what you don't see can't hurt you) Note: dmesg and other logs do not show these pesky Read-only file... lines, and who in his right mind checks the dmesg on a good start-up anyway?. But how about the rc hangs, the console logs and the like? Here I think I finally came to the big, all-encompassing answer:) Unaware, many people still carry a lot of old stuff (including console and null) on their metal /dev. So they don't see (even if they'd want to) those nasty messages. All the dev/null errors are gone, the console log messages look as pretty as ever (in color too), etc. As I implied in the beginning, I also feel good and the reason for that is I set up my metal /dev with the good, old crw--- ... 5, 1 ... /dev/console and also swallowed my pride and added a nice crw-rw-rw- ... 1, 3 ... /dev/null for good measure. 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
Re: Ruminations on Udev, null and console
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
