<Md> fjp: I am uploading a new udev package still without persistent.rules in
the initramfs. Do you think you can fix (or explain ) the ide-generic
issue before the end of the week?
<fjp> Mithrandir: There've been a lit of them. Basic issue is that some IDE
drivers currently need ide-generic loaded to make the devices visible and
the kernel does not take care of loading it.
<Md> Mithrandir: short summary: if persistent.rules (which reads from the block
devices) is used in the initramfs then ide-generic will not be loaded by
some later hook in the initramfs-package
<Md> this has not been explained, but removing persistent.rules "fixed" the
problem
<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
<Mithrandir> so if you touch the block devices, ide-generic is not loaded,
otherwise it is?
<fjp> It is loaded by a hack in initramfs-tools.
<Md> Mithrandir: I do not know which exact effect reading the devices has,
actually. I just reported the only effect I know about
<Md> *unconditionally* loaded, so I can't see how something in udev could
prevent this
<fjp> My feeling is that hack is some disabled by persistent.rules, although it
is unclear why that should be
<Md> fjp: the hack is nothing more than "modprobe -q ide-generic". how can
something interfere with it?
<fjp> Md: That's what puzzles me too :-)
<Md> Mithrandir: BTW, this "hack" exists in initramfs-tools because I refused
to add it to my package since nobody could explain how it works and why
it's needed
<Mithrandir> Md: is it not _loaded_ or doesn't just ide-generic do anything?
<Md> Mithrandir: I don't know, reports are unclear and I do not own such a
system
<Md> fjp: BTW, it would be useful if you could get an events trace for the
failure and the working cases. you can do it by adding
/lib/udev/logger.agent to the initramfs and uncommenting the last line in
hotplug.rules
<Md> this way we could verify which modules are loaded and when
<fjp> Mithrandir: You really don't want ide-generic alone. The real issue is
that the proper driver somehow does not work on its own.
<Mithrandir> fjp: I know you don't want ide-generic alone. You also don't want
to load ide-generic unless you have to.
<Mithrandir> (since it'll kill all useful features from modern controllers)
<Md> also, currently ide-generic may be loaded by ide.agent (but I do not know
*how*, it would only happen if something weird were in
/proc/ide/$name/media), but ide.agent will not be used anybody by 2.6.16
kernels since they implement $MODALIAS for the IDE driver too
--
ciao,
Marco
Attachment:
signature.asc
Description: Digital signature