On Monday 20 February 2006 18:00, Marco d'Itri wrote:
> <Md> why ide-generic needs to be manually loaded is still unexplained,
> and probably part of the problem. also, not all chipsets need it and
> somebody claimed that it needs to be loaded in a specific order wrt the
> IDE low level driver
Additional detailed testing for my system has shown that ide-generic is
not actually needed for _my_ system. Not sure if that is also the case
for all others though.
Tested boots using initrds for the following situations:
1 successful boot with udev 0.084-5 (without persistent.rules)
2 failed boot with udev 0.084-4 [1]
3 failed boot with udev 0.084-4 with 'modprobe ide-generic' commented out
in /usr/share/initramfs-tools/scripts/init-premount/ide
4 failed boot with udev 0.084-4 with the init-premount/ide script
completely disabled
hotplug.log files [2] are attached for all of these.
For 2, 3 and 4 I was dropped into a shell because the / fs device node was
not present. I've marked the point I was dropped into shell with
**** DROPPED INTO SHELL ****
in the log files and added output of 'cat /proc/modules' and 'ls /devhd*'.
After 2 and 3 it turns out that the device nodes actually _were_ there,
but must have been created too late. A simple 'exit' allowed the boot to
continue.
After 4, the device nodes were _not_ created. Only after manually
modprobing ide-disk did /dev/hda* appear. The end of the hotplug events
the modprobe created are marked with "**** AFTER MODPROBE IDE-DISK ****".
Some discussion from this on #d-boot:
[20:06:03] <fjp> Md: It's definitely a timing issue.
[20:07:40] <fjp> If I set -x in the premount script, I see console message
for IDE0 just before the start of the loop; HDC, IDE1, e100 during the
1st iteration
[20:08:00] <fjp> After the 1st iteration the queue is empty
[20:08:36] <fjp> Only after that I see hda and cdrom driver console
messages.
[20:09:12] <fjp> INIT starts after that and it seems that creation of the
device nodes must take just a little bit too long...
[20:09:59] <fjp> Could it be that events are taken off the queue when
processing for them starts and that the actual processing can continue to
run for a while after that?
[20:19:55] <Md> no, this means that it's happening what I supposed
[20:20:16] <Md> when an event is removed from the queue you are
*guaranteed* that everything udevd needed to do has been done
[20:22:19] <Md> maybe (maybe) the IDE devices appear only after the high
level (ide-disk, etc) drivers are loaded. since they are loaded when the
low level driver sends the uevents for them and not because of
coldplugging then the events are processed asyncronously
[20:23:16] <fjp> That is definitely true. The devices only appear after
ide-disk is loaded.
[20:23:27] <fjp> I can show that with the logs.
I guess this shows why ide.agent is needed (to load ide-disk, ide-cd,
...) , although my case does _not_ show why that script should need to
include ide-generic. Guess we need other people testing to show the need
for this.
[20:23:35] <Md> but still I can't see exactly how this would be related to
permissions.rules
[20:24:21] <fjp> I can't either. I'll post a full report of my tests to
the BR.
This is still a mystery... Why does the same problem not manifest itself
when persistent.rules are not used?
[1] This can also be tested by commenting out the line
rm -f $DESTDIR/etc/udev/rules.d/z20_persistent.rules # XXX #352753
in /usr/share/initramfs-tools/hooks/udev
[2] These can be created by adding a line
copy_exec /lib/udev/logger.agent /lib/udev/
in /usr/share/initramfs-tools/hooks/udev and uncommenting the line
#RUN+="logger.agent" in
in /etc/udev/hotplug.rules before creating the initrd.
The logfile will be /dev/hotplug.log so don't forget to copy before
rebooting...
Attachment:
hotplug_bad.log.gz
Description: GNU Zip compressed data
Attachment:
hotplug_bad_no-ide-script.log.gz
Description: GNU Zip compressed data
Attachment:
hotplug_bad_no-ide-generic.log.gz
Description: GNU Zip compressed data
Attachment:
hotplug_good.log.gz
Description: GNU Zip compressed data
Attachment:
pgpyKAizSrnnk.pgp
Description: PGP signature