Description of problem: After recent series of updates, and kudzu seems to be the most likely candidate unless avahi update to 0.6.1-3 has something to with it but I cannot see how, my floppy drive does not show up anymore and is absent from /etc/fstab rewritten by fstab-sync. CD drive is still there for some reason. If I will do an explicit modprobe floppy' then hal will notice it, /etc/fstab is updated accordingly and floppy is mountable again. No such workarounds were required previously. This does not depend on which of few kernels I am booting. I have hal-0.5.5.1-2.1 installed on "11 Dec 2005 11:38:46 AM MST" and I believe that I would observe if that update would be responsible for what is happening. Version-Release number of selected component (if applicable): kudzu-1.2.16-1 How reproducible: always
Does it correspond with a udev update, out of curiousity?
> Does it correspond with a udev update, out of curiousity? I cannot exclude that. Things do change very fast. An update to udev-078-2 happended on 2005-12-22 but it is possible that I did not notice that floppy is gone until the next day. In the meantime udev went up to 078-3 on 2005-12-26 and kudzu to 1.2.17-1 on 2006-01-04 but this did not change anything. Recent changes to hal-0.5.5.1.cvs20060105-2 mean that floppy is not mountable anymore even after 'modprobe floppy'. Although a floppy icon shows up in a "Computer" window there is no floppy entry in /etc/fstab anymore, as fstab-sync is gone, so clicking on that icon only generates error messages.
What do you have in /proc/driver/nvram, if anything? (you may need toload the nvram module)
> What do you have in /proc/driver/nvram, if anything? There is no /proc/driver/nvram. > you may need to load the nvram module Such module does not exist in rawhide kernels (although it shows up on FC4). cat /usr/src/kernels/$(uname -r)/include/config/nvram.h produces '#undef CONFIG_NVRAM' - so it looks like that this is on purpose.
x86_64, I presume? udev bases loading the floppy driver off of the contents of /proc/driver/nvram, which expects the nvram module to be around. Punting to kernel for the moment, although I suppose this could end up in udev's court.
> x86_64, I presume? Yes, indeed. So udev works or does not depending on an architecture? Nice!
x86_64 has no nvram module ATM.
fixed in current builds