Bug 130746 (udev-autoloading)

Summary: udev prevents autoloading of modules
Product: [Fedora] Fedora Reporter: Harald Hoyer <harald>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: andy, anvil, bobgus, byte, davej, djr, djuran, gajownik, goeran, greg, hdegoede, isam, john_hull, jspaleta, jturner, katzj, kjblack, knutjbj, laroche, leon, michel.salim, nalin, notting, sdenham, tjarls, twaugh, umar, us_linux_engineering, volatile451
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-10 07:47:59 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 118861, 136451, 140583    
Description Flags
list of devices which trigger autoloading of modules (kernel 2.6.7-1.494smp) i386
list of devices which trigger autoloading of modules (kernel 2.6.7-1.494smp) i386
the device list
the perl script itsself
the modules one can autoload (arch=i386) none

Description Harald Hoyer 2004-08-24 04:30:44 EDT
If you use udev with an empty /dev the concept of autoloading is broken.

- load the needed modules manually (job of kudzu, hal for the hardware)
- create the most used devices manually (for e.g. tun, loop, etc.)
Comment 1 Harald Hoyer 2004-08-24 05:01:32 EDT
*** Bug 130658 has been marked as a duplicate of this bug. ***
Comment 2 Harald Hoyer 2004-08-24 05:03:42 EDT
*** Bug 130570 has been marked as a duplicate of this bug. ***
Comment 3 Harald Hoyer 2004-08-24 05:03:56 EDT
*** Bug 129916 has been marked as a duplicate of this bug. ***
Comment 4 Harald Hoyer 2004-08-24 05:04:09 EDT
*** Bug 130503 has been marked as a duplicate of this bug. ***
Comment 5 Harald Hoyer 2004-08-24 05:04:27 EDT
*** Bug 130669 has been marked as a duplicate of this bug. ***
Comment 6 Harald Hoyer 2004-08-24 05:08:56 EDT
further solutions:
- we could cp/tar from the original /dev (after stripping down the
original /dev package) (hint mount --bind / /dev/origroot;cp -a
/dev/origroot/dev/* /dev)
- drop the ramfs /dev we used in the initfs
Comment 7 Harald Hoyer 2004-08-24 10:36:32 EDT
quickfix for all who have been bitten by this:
update to udev-030-7 and rerun mkinitrd
Comment 8 Jeremy Katz 2004-08-24 14:35:06 EDT
If we do anything involving the dev package, it's going to break. 
Think errata of the dev package when your ramfs/tmpfs is mounted :-) 

Possibly having an /etc/static.devs or something like that which
depends on using makedev to create the device nodes could work.

Adding Nalin to the cc list as the owner of dev/MAKEDEV to see if he
has any better ideas.
Comment 9 Bill Nottingham 2004-08-25 00:19:02 EDT
*** Bug 130831 has been marked as a duplicate of this bug. ***
Comment 10 Harald Hoyer 2004-08-25 09:39:49 EDT
Ok, this is the list that could be autoloaded with kernel-2.6.7-1.494smp

alias block-major-113-* viocd
alias block-major-11-* sr_mod
alias block-major-13-* xd
alias block-major-15-* cdu31a
alias block-major-16-* gscd
alias block-major-17-* optcd
alias block-major-18-* sjcd
alias block-major-1-* rd
alias block-major-20-* mcdx
alias block-major-22-* ide-probe-mod
alias block-major-23-* mcd
alias block-major-24-* sonycd535
alias block-major-25-* sbpcd
alias block-major-26-* sbpcd
alias block-major-27-* sbpcd
alias block-major-29-* aztcd
alias block-major-2-* floppy
alias block-major-32-* cm206
alias block-major-33-* ide-probe-mod
alias block-major-34-* ide-probe-mod
alias block-major-37-* ide-tape
alias block-major-3-* ide-probe-mod
alias block-major-44-* ftl
alias block-major-46-* pcd
alias block-major-47-* pf
alias block-major-56-* ide-probe-mod
alias block-major-57-* ide-probe-mod
alias block-major-7-* loop
alias block-major-88-* ide-probe-mod
alias block-major-89-* ide-probe-mod
alias block-major-8-* sd_mod
alias block-major-90-* ide-probe-mod
alias block-major-91-* ide-probe-mod
alias block-major-93-* nftl
alias block-major-9-* md
alias char-major-10-130 acquirewdt advantechwdt alim1535_wdt ...
alias char-major-10-131 pcwd pcwd_pci ....
alias char-major-10-135 rtc
alias char-major-10-139 openprom
alias char-major-10-144 nvram
alias char-major-10-157 applicom
alias char-major-10-175 agpgart
alias char-major-10-184 microcode
alias char-major-10-200 tun
alias char-major-10-250 hci_vhci
alias char-major-10-2 msbusmouse
alias char-major-10-3 atixlmouse
alias char-major-107-* 3dfx
alias char-major-108-* ppp_generic
alias char-major-109-* lvm-mod
alias char-major-116-* snd
alias char-major-13-0 joydev
alias char-major-13-32 mousedev
alias char-major-13-* input
alias char-major-14-* soundcore
alias char-major-161-* ircomm_tty
alias char-major-171-0 * 16 raw1394
alias char-major-171-1 * 16 video1394
alias char-major-171-2 * 16 dv1394
alias char-major-171-3 * 16 amdtp
alias char-major-188-* usbserial
alias char-major-195* nvidia
alias char-major-19-* cyclades
alias char-major-200-* vxspec
alias char-major-206-* osst
alias char-major-20-* cyclades
alias char-major-216-* rfcomm
alias char-major-21-* sg
alias char-major-22-* pcxx
alias char-major-23-* pcxx
alias char-major-27-* zftape
alias char-major-34-* scc
alias char-major-35-* tclmidi
alias char-major-36-* netlink
alias char-major-37-* ide_tape
alias char-major-48-* riscom8
alias char-major-49-* riscom8
alias char-major-4-* serial
alias char-major-57-* esp
alias char-major-58-* esp
alias char-major-5-* serial
alias char-major-63-* kdebug
alias char-major-6-* lp
alias char-major-81 bttv
alias char-major-90-* mtdchar
alias char-major-96-* pt
alias char-major-97-* pg
alias char-major-99-* ppdev
alias char-major-9-* st
Comment 11 Harald Hoyer 2004-08-25 11:00:48 EDT
Created attachment 103070 [details]
list of devices which trigger autoloading of modules (kernel 2.6.7-1.494smp) i386

this is i386 only
Comment 12 Jeremy Katz 2004-08-25 11:27:03 EDT
Not all of these make sense.  eg, anything storage related should
definitely only have its devices created by udev if they're there. 
It's mostly things like loop, tun, etc which don't correlate to some
hardware that I think we should pre-create.
Comment 13 Harald Hoyer 2004-08-25 11:28:26 EDT
Created attachment 103071 [details]
list of devices which trigger autoloading of modules (kernel 2.6.7-1.494smp) i386

oops... had a bug in my perl script... this is the correct list
Comment 14 Harald Hoyer 2004-08-25 11:50:57 EDT
Created attachment 103072 [details]
the device list

ok, another small regexp bug in the script, reveals
2344 device nodes...
Comment 15 Harald Hoyer 2004-08-25 11:52:40 EDT
Created attachment 103073 [details]
the perl script itsself
Comment 16 Harald Hoyer 2004-08-25 12:20:20 EDT
Created attachment 103077 [details]
the modules one can autoload (arch=i386)

These are the 18 modules, which are not compiled in the kernel, which may be
Comment 17 Jeremy Katz 2004-08-25 12:35:09 EDT
So looking through the list:
* floppy: Exports the right sysfs bits, kudzu can probe for it
* ide_tape: Should be probable
* ircomm_tty: Should be probable I think
* loop: We want to add these devs
* lp: Not sure
* microcode: I guess we could go ahead and create the devs for this,
although I'd rather just have the microcode initscript load the module
(and udev knows how to create the device node on the hotplug event)
* osst: Should be probable
* ppdev: Not sure
* ppp: I guess we probably want to just have this device there
* rfcomm: Should be probable
* sd_mod, sg, sr_mod, st: Loading of the scsi adapters creates the devices
* snd,soundcore: Questionable on whether or not we should have the
devices or just auto-load the modules
* tun: We need to create the device
* usbserial: Should get the device created when the user logs in
Comment 18 Greg Kroah-Hartman 2004-08-25 12:49:20 EDT
usbserial will get automatically pulled in if the device is present.
scsi modules (sd_mod, etc) will get automatically loaded by the
hotplug code
snd, soundcore will get automatically loaded when the sound card
driver is loaded (when the device is found)

What about raw?
Comment 19 Bill Nottingham 2004-08-25 12:56:08 EDT
* floppy: Exports the right sysfs bits, kudzu can probe for it

I'll bite - where do you see this?
Comment 20 Bill Nottingham 2004-08-25 16:02:04 EDT
*** Bug 130544 has been marked as a duplicate of this bug. ***
Comment 21 Nalin Dahyabhai 2004-08-25 21:00:31 EDT
Per bug #116009, MAKEDEV should soon be available to create those
devices if rc.sysinit (or udevstart, or whatever) wants to work around
this sort of thing by calling MAKEDEV.

If you're looking for dumb ideas, here's one:  maybe autofs could
manage /dev.  Sure, the autofs filesystem doesn't appear to support
device special files, but that's a kernel problem just waiting to be
Comment 22 Harald Hoyer 2004-08-26 05:39:52 EDT
$ /sbin/modinfo  raw1394
license:        GPL
alias:          char-major-171-0 * 16
vermagic:       2.6.8-1.526smp SMP 686 REGPARM 4KSTACKS gcc-3.4
depends:        ieee1394
alias:          ieee1394:ven*mo*sp0000A02Dver00010001*
alias:          ieee1394:ven*mo*sp0000A02Dver00000100*

Hmm, what does that mean????
alias:          char-major-171-0 * 16
Comment 23 Harald Hoyer 2004-08-26 05:45:24 EDT
Ok, I would build the devices for the following modules:
floppy, loop, lp, microcode, ppdev, ppp, tun

We should really load the sound modules in a defined order manually.

Comment 24 Harald Hoyer 2004-08-26 06:24:31 EDT
ok, this should work, if MAKEDEV is reachable... 
we could mount --bind / /mnt and access /mnt/dev/MAKEDEV, but this is
obscure.. :)
one thing I noticed is that MAKEDEV could not create the loop devices.


for i in 0 1 2 3 4 5 6 7;do echo fd$i;done;
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15;do
    echo cpu/$i/microcode;
echo lp par net/tun loop;
Comment 25 Bill Nottingham 2004-08-26 13:42:30 EDT
initscripts-7.70 does load the hardware modules.
Comment 26 Nalin Dahyabhai 2004-08-26 16:42:12 EDT
MAKEDEV (even with the -n flag) won't print any output for devices
which you already have in /dev; a test run with the -d flag pointing
to some other directory will work better as a spot-check.  Version 3.9
moves the binary to /sbin, but leaves a symlink in /dev for compatibility.
Comment 27 Hans de Goede 2004-09-02 16:03:18 EDT
initscripts-7.70 does correctly load the modules for my soundcard.
But I still have 2 issues with it:
-my mixer settings are always set to 0, I've tried using alsactl
restore, but they keep being set to 0 which meant that the alsactl save
in the halt scripts seem to have mucked up. I've tried setting them
back and then rebooting but they keep going back to 0
-the oss compat modules don't get loaded and I still have apps which
need this, please also auto load snd_pcm_oss when a soundcard is present.

Comment 28 Bill Nottingham 2004-09-02 16:07:49 EDT
OSS loading is handled with a newer module-init-tools.
(Note: don't use 3.1-0.pre5.1. :) )
Comment 29 Ralf Ertzinger 2004-09-03 05:56:34 EDT
Automatic creation of SCSI-CDROM nodes seems to be broken. The SCSI
adapter is loaded by mkinitrd, the CDROM devices show up in /sys/, but
sr_mod is not loaded (and thus, no device nodes are created).
Comment 30 Harald Hoyer 2004-09-22 08:39:05 EDT
sr_mod is loaded for me automatically
Comment 31 Ivan Gyurdiev 2004-09-24 22:06:43 EDT
The nvidia module will not autoload - is that something the nvidia
people need to fix? It's really annoying, and it also locks up the
system when rhgb attempts to start (should I file a bug for that?)

Also, alsactl restore is never executed for me anymore.
I must call it manually every single time. The correct modules
are loaded. I'm not sure that's related, but it seems like it should
get executed given this in modprobe.conf:

alias snd-card-0 snd-via82xx
install snd-via82xx /sbin/modprobe --ignore-install snd-via82xx &&
/usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-via82xx { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-via82xx

Comment 32 Knut J BJuland 2004-09-25 07:49:55 EDT
BY using mkinitr --preload I am able to preload nvidia and seq.

/sbin/mkinitrd -v -f --preload=nvidia --preload=snd-emu10k1
--preload=snd-emu10k1-synth --preload=snd-seq-oss
/boot/initrd-2.6.8-1.541custom.img 2.6.8-1.541custom
Comment 33 Harald Hoyer 2004-09-27 04:05:29 EDT
*** Bug 133372 has been marked as a duplicate of this bug. ***
Comment 34 Harald Hoyer 2004-09-27 04:05:42 EDT
*** Bug 133171 has been marked as a duplicate of this bug. ***
Comment 35 Harald Hoyer 2004-09-27 09:25:43 EDT
What happened to:
* ircomm_tty: Should be probable I think
Comment 36 Harald Hoyer 2004-10-01 05:09:54 EDT
*** Bug 133841 has been marked as a duplicate of this bug. ***
Comment 37 Piergiorgio Sartor 2004-10-01 15:25:09 EDT
About the mixer settings always zero (I had the same problem),
I think there is a race condition.
While loading the modules, the command to re-load the mixer setting
is executed, but the device /dev/mixer is not yet present, so it fails.
Solution: copy /dev/mixer (once available) to /etc/udev/devices so it
will be created at boot and everything will be fine.
About the /etc/udev/devices, it would be really cool if the modules
related to these devices will NOT be autoloaded by rc.sysinit.
I mean, if I have /etc/udev/devices/fd0 (and "floppy" as link), the
floppy module should not be loaded (it is not needed).
Comment 38 Bill Nottingham 2004-10-01 15:55:59 EDT
/dev/mixer isn't needed for sound restoration.
Comment 39 Piergiorgio Sartor 2004-10-02 16:35:20 EDT
Sound restoration is done using aumix-minimal, which fails if
/dev/mixer is not available.
So /dev/mixer is for sure needed.
Comment 40 Bill Nottingham 2004-10-03 23:14:16 EDT
Sound restoration is done via alsactl; unfortunately, the migrator for
old settings wasn't fully fleshed out at FC2 release.
Comment 41 Harald Hoyer 2004-10-07 09:37:55 EDT
added a basic scsi hotplug event replay to start_udev
scsi cdroms, tapes, etc. should be present now.

Comment 42 Ralf Ertzinger 2004-10-09 10:40:12 EDT
Works for me, kernel-2.6.8-1.603, udev-034-2.
Comment 43 Sammy 2004-10-09 12:06:09 EDT
scsi tape stuff is now working...creating /dev/nst? devices. Is it possible to 
get a logical link /dev/nst0 ---> /dev/tape ? or should we put this into the 
devices directory? 
Comment 44 Harald Hoyer 2004-10-11 04:41:14 EDT
I will make nst? -> tape? symlinks..
Comment 45 Pekka Pietikäinen 2004-10-11 10:34:46 EDT
Another missing thing is DVB, the same approach as with ISDN works
fine (/sbin/MAKEDEV -d /etc/udev/devices dvb) . Add to the Fine Manual
(tm) if nowhere else.
Comment 46 Harald Hoyer 2004-10-18 11:34:54 EDT
*** Bug 135932 has been marked as a duplicate of this bug. ***
Comment 47 Harald Hoyer 2004-10-18 11:37:04 EDT
*** Bug 136078 has been marked as a duplicate of this bug. ***
Comment 48 Mike A. Harris 2004-11-18 10:55:31 EST
*** Bug 139852 has been marked as a duplicate of this bug. ***
Comment 52 Susan Denham 2004-11-19 12:08:51 EST
At this point for RHEL 4, all major supported devices work ok. We've
also added workarounds or things like ISDN to work ok. 

Can you please provide us with more detail on which items
(devices) you consider blockers for RHEL4?  Please open up new
bugzillas for these items; this bugzilla is getting pretty unwieldy!

Comment 53 Jay Turner 2005-02-10 07:47:59 EST
I'm closing this out since everything appears to have landed and Dell didn't
complain stuff was missing.  If other devices pop up, we'll reopen.