[Cc'd to inistcripts and devfsd maintainers]
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0112.0/0133.html > parport0: assign_addrs: aa5500ff(80) > parport_pc: Via 686A parallel port: io=0x378 > devfs: devfs_mk_dir(printers): could not append to dir: dffe45c0 "", err: -17 > lp0: using parport0 (polling). Something other than drivers/char/lp.c is creating (implicitly or explicitly) the "printers" directory in the devfs root dir. ... BTW: if it is something in user-space creating these entries (say some vendor-provided boot script which populates devfs with "persistent" entries), then I suggest you rip out whatever is doing it. And later: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0112.0/0368.html > I found the reason for these messages. It has a boot-script source. > Mandrake stores the attributes of device nodes in /lib/dev-state. > This directory is copied into /dev directly before devfsd is started. OK, clean out stuff you don't need in /lib/dev-state. Check your devfsd configuation to see if /lib/dev-state is being repopulated automatically. If so, grab devfsd-v1.3.20 and use the new RESTORE directive. This is the correct way to handle persistence. Remove the boot-script code which populates from /lib/dev-state. > If there is a device file in /lib/dev-state it is created in /dev > even before the driver is loaded. When the driver is loaded it > tries again to create the node and the message appears. OK, I suspected as much. Good. Thanks for tracking this down. Attempting to create the same entry twice *should* yield EEXIST on the second try. The new devfs is strict about this, the old one wasn't. I consider this issue closed. I'd suggest you contact Mandrake and get them to upgrade to devfsd-v1.3.20, remove the boot script code and use the RESTORE directive instead. This requires v1.2 of the devfs core (found in 2.4.17-pre1).
