Hide Forgot
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.
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
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.
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
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
Created attachment 104389 [details] The file mentioned in my verbal work-log
Created attachment 104390 [details] The interesting part of /var/log/messages (contained by root logins/logouts)
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
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.
Created attachment 104394 [details] the output from hal the secound attempt in comment #8
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
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...
Does this even work with hotplugging the camera?
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.
Sounds good. I'll leave this bug open until that is resolved. The floppy problem we deal with in bug 133834. Thanks, David
This is already fixed so I'm closing this bug. Thanks, David