Red Hat Bugzilla – Bug 207715
Last modified: 2007-11-30 17:11:44 EST
Description of problem:
This is only a guess that gnome-vfs2 changes are responsible
and this guess is based on a time coincidence when updates happened,
changes were noticed, and speculations about what may be involved.
After recent updates when "Computer" window in Nautilus is opened
a floppy is nowhere to be seen. A CD icon is still there. This
despite that floppy is stil recognized by a kernel and udev creates
a _working_ /dev/fd0 ("working" means that 'mount' can be used with
it if priviledges are sufficient).
This makes floppies unmountable by "deskop means"; not only with a
help of that missing icon but 'gnome-mount -d /dev/fd0' just returns
after printing a version string and adding '-v' does not change much.
If trying that from a root account one gets also
(gnome-mount:7073): Bonobo-CRITICAL **: bonobo_object_unref:
assertion `BONOBO_IS_OBJECT (object)' failed
In 'lshal' output "floppy" does shows up but a block device /dev/fd0
is not there.
Version-Release number of selected component (if applicable):
David, any ideas?
Hi, please try with hal-0.5.8 and gnome-mount 0.5 available from here
> please try with hal-0.5.8 and gnome-mount 0.5
Thanks. I did. A floppy icon in "Computer" came back, and I can
indeed mount and unmount floppy with its help. Also
'gnome-mount -d /dev/fd0' works again (adding '-v' does not provide
any extra information). It takes a while to mount but eventually it
does. BUT after these updates I ended up with the situation like
in the original report but for a change with CD this time.
I.e. no icon, no desktop mounts, and 'gnome-mount -d /dev/cdrom'
just returns right away (with a mountable, iso9660, CD in a drive).
There is another issue. I have x86_64 installation and I had to
rebuild binary packages for it. To get hal to recompile I had to
install 'libvolume_id' package (and some "-devel" packages but this
is not likely affect results). That package is not mentioned anywhere
in requirements and nothing appeared to complain that it was not
installed before. OTOH when I tried to remove it afterwards, just
to see what will happen, yum wanted to remove over 130 packages; most
likely due to direct or indirect dependencies on hal. Would
ready new binary packages pulled in 'libvolume_id' too? I wonder
if its absence before was a reason for an observed behaviour
(but why now CDs?).
Also earlier updates happened on my test system
August 31st - hal.x86_64 0.5.7.1-3.fc6
July 26 - gnome-mount.x86_64 0.4.0.2006.07.24-1.fc6
and I am pretty sure that I was looking at floppies after that.
Definitely with the previous version of gnome-mount. Hence I suspected
that other components are really involved here.
> BUT after these updates I ended up with the situation like
> in the original report but for a change with CD this time.
> I.e. no icon, no desktop mounts, and 'gnome-mount -d /dev/cdrom'
> just returns right away (with a mountable, iso9660, CD in a drive).
Very weird, I get that too one a box. Have never seen this before,
am debugging it right now. Will follow up with newer packages.
> To get hal to recompile I had to
> install 'libvolume_id' package
Yea, I missed the BR on libvolume_id-devel and the R on libvolume_id. Only
realized that when going over the spec file.
(for 0.5.7 and earlier we were carrying a copy of the code in the udev tree, now
udev provides this as a shared library).
Thanks for the testing so far.
OK, this was an easy fix. A helper spawned by hald to investigate the storage
device crashes on a code path for CD-ROM drives without write capabilities.
I guess these are just rare these days. Not part of my testing setup the past 8
months as I've been working from another location than the Westford office.
Patch is here
Will build new packages in a bit; just scanning other bugs I've put in NEEDINFO.
Here's a src RPM with the patch
> Here's a src RPM with the patch
Thanks. After replacing hal with that one I do have back both floppy
and CD; and a filesystem on a USB memory stick mounts as well.
OTOH my particular device identifies itsels as:
"ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)" so I am not
"crashes on a code path for CD-ROM drives without write capabilities"
diagnosis is really correct but your patch appears to prevent a crash
in this case too.
OK, thanks for testing.
Actually, looking through it again, the code path is when we can't get the write
speeds from the device - I was making the wrong assumption. Perhaps your drive
don't support that MMC command (MMC-3 Current Write Speed).
Should be fixed with hal 0.5.8.1-2 / gnome-mount 0.5-2 otherwise please reopen.