On Feb 14, Frans Pop <aragorn@tiscali.nl> wrote: > We've done a debugging session today involving Otavio Salvadore (who also > saw the issue), maks and myself. > > There are two possible solutions, both involving modifications in > /usr/share/initramfs-tools/hooks/udev. > > 1) revert inclusion of *_id scripts > Commenting out the three lines at the end of the current file lets the > system boot again. > 2) add 'copy_exec /lib/udev/ide.agent /lib/udev' at the end of the file > Apparently some _id script calls ide.agent and this makes sure > ide-generic is loaded at the correct time. So far there has not been a relevant progress then. The first solution is obviously unacceptable because supporting persistent disk names in the initramfs has been a planned feature since they were designed. The second solution means that I would need to add to my package code whose purpose I do not understand (which systems do need ide-generic, when and why?). Also, I cannot see any way for the *_id programs called by persistent.rules to prevent init-premount/ide, which contains an unconditional "modprobe -q ide-generic", to load the module. This is too much close to cargo cult programming for my taste. > Basically ide.agent does the same as what's currently in > /usr/share/initramfs-tools/scripts/init-premount/ide (which could probably > be cleaned now). What happens if you rearrange your initramfs to run this script before the udev script instead of later? If you are right and ide-generic needs to be loaded before other drivers (which is totally broken and is not something udev would support) then this would be the correct fix. > The comment at the top of the ide.agent seems to imply that this whole > ide-generic issue will be fixed in 2.6.16 kernels, which would be great. No. It means that in 2.6.16 the ide subsystem will generate requests for the high level drivers and that they will provide proper module aliases to allow autoloading them with $MODALIAS, but I doubt that the ide-generic module will. And if all uevents will have a $MODALIAS variable then ide.agent will never be run and ide-generic will not be loaded again. BTW, I would really really like to see the content of an uevent which causes ide-generic to be loaded. > With my d-i release manager hat on, I would suggest uploading -5 with this > fix at MEDIUM urgency. I would be very unhappy with -4 in testing in the > middle of preparing for D-I Beta2. I will make sure that udev gets into > testing before the final build for Beta2. When is the deadline for entering testing for Beta2? > One other thing. > With the patch applied, most errors that are shown with -3 are gone (there > were screens full of them!), but I still get 2 times the following error > on the console during a boot: > (...) exec of program /etc/initd.d/hdparm failed > > IMO it would be good to suppress such messages as, in my experience, they > will only lead to unnecessary installation and bug reports. I fully agree, but I need to find a clever way to do it. Can you suggest ways for udevd to detect if it's running in an initramfs? Like checking for a specific environment variable or a file. > maks suggested to re-add the "silence_exec_error" patch for Beta2 and > maybe come back to this issue after that? Maybe, but I'd rather to fix this once for good instead of hiding all errors again. -- ciao, Marco
Attachment:
signature.asc
Description: Digital signature