Red Hat Bugzilla – Bug 176517
kudzu appears to "forget" about my floppy drive
Last modified: 2015-01-04 17:23:55 EST
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
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):
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
> 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
> 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