Bug 133775 - Upgrading hal and dbus resulting in removable media mountpoints removed
Upgrading hal and dbus resulting in removable media mountpoints removed
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-27 08:12 EDT by Kyrre Ness Sjøbæk
Modified: 2013-03-05 22:41 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-14 18:46:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The file mentioned in my verbal work-log (30.88 KB, text/plain)
2004-09-27 14:11 EDT, Kyrre Ness Sjøbæk
no flags Details
The interesting part of /var/log/messages (contained by root logins/logouts) (2.42 KB, text/plain)
2004-09-27 14:15 EDT, Kyrre Ness Sjøbæk
no flags Details
the output from hal the secound attempt in comment #8 (34.34 KB, text/plain)
2004-09-27 14:46 EDT, Kyrre Ness Sjøbæk
no flags Details

  None (edit)
Description Kyrre Ness Sjøbæk 2004-09-27 08:12:14 EDT
Description of problem:
After installing fc3t2, removable media worked fine - including
mountpoint creation when usb mass storage device was plugged in.

What didn't work right, was that when i unplugged the mass storage
device (both with and without umounting first), the mountpoints did
not go away (mountpoints where created for both /dev/sda and sda1 -
even if only sda1 was used), and they where named floppy1 and floppy2.

After upgrading hal and dbus, all removable media mounpoints is gone,
and plugging in a mass storage device does not result in a new one
created (but the module are loaded).

Version-Release number of selected component (if applicable):
hal-0.2.98.cvs20040923-1
dbus-0.22-9

How reproducible:
Every time

Steps to Reproduce:
1. Upgrade hal and dbus
2. take a look at "my computer" in gnome desktop
3. No mountpoints for removable media
  
Actual results:
No mountpoints for removable media

Expected results:
CDrom and floppy entries should be there, usb should be removed but
added on plugin (and removed on plugout), and usb should not be named
floppy unless there is a floppy

Additional info:

This is the fstab:
/dev/VolGroup00/LogVol00 /            ext3    defaults        1 1
LABEL=/boot              /boot        ext3    defaults        1 2
none                     /dev/pts     devpts  gid=5,mode=620  0 0
none                     /dev/shm     tmpfs   defaults        0 0
none                     /proc        proc    defaults        0 0
none                     /sys         sysfs   defaults        0 0
/dev/VolGroup00/LogVol01 swap         swap    defaults        0 0

I also tried upgrading kudzu, gamin, and gnome-volume manager after
consulting the fedora-devel mailing list, but no luck.
Comment 1 Jef Spaleta 2004-09-27 09:58:10 EDT
Is the hald process running? is the dbus process running?
ps aux|grep dbus
ifnot
service messagebus start
ps aux|grep hald
ifnot
service haldaemon start

and check fstab again.

I'm seeing pretty much the opposite of everything you describe on my
system:
my digital camera and other usb-storage devices like my flash card
reader and my usb keychain driver show up as usbdisk#
my cdrw shows up as /media/cdrw. 

This bugreport is also problematic becuase it lists a number of
potential different problems all together, and the report leaves out
significant details that were communicated in the mailinglist.
For starters you didn't give any specific information about the type
of usb device that create the floppy1 and floppy2 entries in the bug
report. It's important to say that the device is a digital camera and
the make and model number. The fact that digital camera is getting a
floppy desgination on your system already seems strange, but it could
potentially be a bug specific to that make and model of camera.
Considering the number of issues you raise in this report, the
behavior of that specific usb device is probably worth its own bugreport. 

Second... you suggest 'the mountpoints did not go away'... but this is
a half-truth. From the thread in the mailinglist we know you saw the
devices listed in Gnome's My Computer, but you did not check to see if
the mountpoints actually existed, nor if the fstab was correct while
you were still seeing the bogus mountpoints in Gnome's My Computer. As
of now we have no idea if your system actually had those mountpoints
or if Gnome was just confused.

-jef 


Comment 2 Kyrre Ness Sjøbæk 2004-09-27 12:29:47 EDT
Forget about the extra mountpoints - that is another bug altogether
which i shall do anything i can in order to repruduce as soon as the
mass storage mountpoints acctually comes back. And then that will be
another bugzilla report. I was just trying to sum up the background of
it all.

But, yes, both hald and dbus is definitively running:

[root@localhost ~]# ps aux | grep dbus
dbus      2398  0.0  0.5  3964  704 ?        Ss   10:53   0:00
dbus-daemon-1 --system
kyrre     4276  0.0  0.5  3648  704 ?        Ss   13:58   0:00
dbus-daemon-1 --fork --print-pid 8 --print-address 6 --session
kyrre     7485  0.0  0.4  4332  600 ?        Ss   17:49   0:00
/usr/bin/ssh-agent /usr/bin/dbus-launch /etc/X11/xinit/Xclients
kyrre     7489  0.0  0.5  2880  704 ?        Ss   17:49   0:00
dbus-daemon-1 --fork --print-pid 8 --print-address 6 --session
root      8433  0.0  0.5  4212  704 pts/1    S+   18:21   0:00 grep dbus
[root@localhost ~]# ps aux | grep hald
root      2422  0.0  1.1  5540 1440 ?        Ss   10:53   0:02 hald
root      8438  0.0  0.5  4084  684 pts/1    R+   18:21   0:00 grep hald
[root@localhost ~]#

Just for the record - the camera is a Fujifilm FinePix 6900.
Comment 3 David Zeuthen 2004-09-27 14:03:51 EDT
Kyrre,

Please submit the information mentioned here

 http://freedesktop.org/Software/HalTraces

so we can work out what the bug is. Debug output from hald and the
lshal and /etc/fstab debug information is crucial in determining what
the problem is. 

As mentioned in comment 1 it's a pretty complicated setup so I need
specific information about what the problem is. If you have problems
with several of your devices I suggest we take them one at a time.

Thanks,
David
Comment 4 Kyrre Ness Sjøbæk 2004-09-27 14:07:59 EDT
Folowing the instructions on this website:
http://hal.freedesktop.org/Software/HalTraces
i tried to do some more debugging.

0: log out of gnome. vt7 now shows the gdm loginscreen

First i stoped hal with
/etc/init.d/haldaemon stop

The fstab file is now identical to the one in the original report
(exept it contains a manually entered line to allow user to mount an
nfs drive - i like listening to music while working)

I then startet hal again (on vt1) with 
hald --daemon=no --verbose=yes 2> /root/haldebuglog

(i had tail -f /root/haldebuglog running in vt2 and tail -f
/var/log/messages in vt3)

cat /etc/fstab showed no differences

I then try logging into gnome on vt7, using my ordinary user (kyrre),
and "my computer" shows nothing of interest.

I then connect my camera, the disk makes some reading noise, and the
cpu-meter in gnome shows some activity.

Still no difference in either gnomes "my computer" or fstab.

I then switch of the camera - again the hd makes some noise, and the
cpu-meter has another, smaller peak.

No difference to fstab or my computer.

Just before stopping hal, i check ps aux | grep hald, and (besides my
tail of haldebuglog and grep) it gives me the process, with arguments
and everything.

I swich to vt1 and control-c hald

i then restart hald with service haldaemon start. It gives a green "ok".

Versions according to rpm:
hal-0.2.98.cvs20040923-1
udev-030-26
hotplug-2004_04_01_4
And the kernel according to uname -a is 2.6.8-1.541
Comment 5 Kyrre Ness Sjøbæk 2004-09-27 14:11:34 EDT
Created attachment 104389 [details]
The file mentioned in my verbal work-log
Comment 6 Kyrre Ness Sjøbæk 2004-09-27 14:15:17 EDT
Created attachment 104390 [details]
The interesting part of /var/log/messages (contained by root logins/logouts)
Comment 7 David Zeuthen 2004-09-27 14:25:00 EDT
Thanks, this is very useful; I think I know what the bug may be. 

If you can confirm that starting the hal daemon right about 10 seconds
after turning on your camera gives you a single /etc/fstab entry it
would be great. In either case please attach this hald output as well
(no need to provide /var/log/messages output).

Thanks,
David
Comment 8 Kyrre Ness Sjøbæk 2004-09-27 14:38:34 EDT
okay... is timing VITAL? or is it "start hald AFTER the module has
loaded" (cpu usage meter PAST peak, no/low hd-activity)

I shall try:

first i stop hald:
sevice haldaemon stop
*green OK*

I plug in my camera (or switch on power - it is plugged in):
*lots of spew on my console*

then i start hald, putting the errors into haldebuglog2
hald --daemon=no --verbose=yes 2> /root/haldebuglog2
this happened a little later than all the spew on my console

but no, no difference to /etc/fstab. Sorry!

*stop hald*
*switch of camera*

Hmm... tries again, with a litle more time between camera switchon to
hald start:

*camera switchon*
*hald start*

no difference. Sorry!

But it it always fun with quick responces
i am on fedora-devel and fedora-bugweek on irc now.
Comment 9 Kyrre Ness Sjøbæk 2004-09-27 14:46:50 EDT
Created attachment 104394 [details]
the output from hal the secound attempt in comment #8
Comment 10 David Zeuthen 2004-09-27 15:01:37 EDT
OK, it seems we're looking at two things 

1. SELinux support in fstab-sync is a bit broken since fstab-sync
crashes; hal correctly detects the /dev/sda1 partition. I think this
is because you need to upgrade to a newer libselinux. Actually I
explicitly disabled selinux support in the build (to wait for a new
libselinux package with the features for removable storage) since
0.2.98-2 but it seems that fstab-sync is picking it up in the build
process anyway. Manually upgrading to a newer libselinux and policy
might solve this

2. Hotplugging the camera doesn't work. However with the debug output
from comment 4 this seems fixable. The reason for this is probably the
specific make of the camera and some delays that stems from that.

The reason for timings was that I wanted to see that hal could detect
the device at startup at not at hotplug.

I hope to have a new package by tomorrow or wednesday with these fixes.

Thanks,
David
Comment 11 Kyrre Ness Sjøbæk 2004-09-27 15:40:41 EDT
yup, yum upgrade libselinux (and a reboot just to be sure) fixed it.
Now , if i plug in my camera, it pops up, and when i switch it back
off, it disapears.

GREAT WORK!

Now i go off to complain about it calling my camera a floppy...
Comment 12 David Zeuthen 2004-09-27 16:15:40 EDT
Does this even work with hotplugging the camera?
Comment 13 Kyrre Ness Sjøbæk 2004-09-27 16:35:50 EDT
Yes. Everything works. Plugging in camera creates mountpoints (and
show me them in gnome), plugging out removes them and unmounts. So -
it works. But it still thinks my camera is a floppy...

It seems like the package should have required a new libselinux.
Comment 14 David Zeuthen 2004-09-27 16:50:07 EDT
Sounds good. I'll leave this bug open until that is resolved. The
floppy problem we deal with in bug 133834.

Thanks,
David
Comment 15 David Zeuthen 2004-10-14 18:46:21 EDT
This is already fixed so I'm closing this bug.

Thanks,
David

Note You need to log in before you can comment on or make changes to this bug.