[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#352753: udev: ide-generic no longer loaded on boot

<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 
<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 
<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 
<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


Attachment: signature.asc
Description: Digital signature

Reply to: