libhal fails to dbus-activate hal

The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Lucid Lynx. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

I confirm this issue on both XUbuntu 10.04 beta 32-bit and 64-bit with the live CD on two laptops - Acer Aspire 5920 and Acer Aspire One d250 (32-bit only).

I boot from xubuntu live cd. Get xfce and the "gtk-jockey crashed" message (already fixed). Then I plug in my flash stick - nothing happens, just as i described. "gksu thunar" still sees it. Also tested with other usb stick and an external HDD. The things are just the same as I described.

I have tried to reproduce this issue using Xubuntu Lucid up to date as of 2010-03-28, and can not do so. After auto-login, I plugged the drive in. It mounted the same way as before the auto-login was turned on. Leaving open to see if someone else can reproduce it.

Have the issue on Xubuntu 10.04 Beta 1 (updated) on Compaq Evo N610c. Thanks Markhor for solution :)

Thanks for confirming this issue. Now, if we could have one or both of you attach your ~/.xsession-error log file. I will then forward this report upstream to Xfce developers.

~/.xsession-errors log

Confirming this bug here too: Fresh Xubuntu install and no auto-mount of USB with auto-login. Logging out and back in makes everything work fine.

Ben Crosse@: could you reproduce the issue and attach your ~/.xsession.errors log file also? This appears to be an error in polkit-gnome-authentication-agent, but I need to verify that.

Thank you for the attachment. Both logs show the same errors:

(polkit-gnome-authentication-agent-1:1754): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'

(polkit-gnome-authentication-agent-1:1754): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

This does seem to be a thunar bug afterall.

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in policykit1.
(With many applications, you can report a future bug directly on the appropriate package by opening the application's "Help" menu and choosing "Report a Problem". https://wiki.ubuntu.com/ReportingBugs)

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

It seems that the bug is fixed

This bug has been fixed in lucid, but I don't know what fixed it. Marking invalid to show it is no longer active.

Oh what are you talking about !? I just updated my system and this bug IS NOT FIXED. Marked this as new.

This bug drives me crazy after all

Markhor:
Please attach you ~/.xsession-errors log file. It would also be helpful to attach the /var/log/dmesg.log after the error.

I can confirm this bug still exists. I just updated a couple of hours ago. I'm running Ubuntu Lucid i386 with Gnome. I have a Fat32 USB HDD, an NTFS USB HDD, and 2 thumb drives that won't auto-mount if I use auto-login. I also discovered that they will auto-mount if I log in as a guest.

If I login with a password, my usb keys show up on the xubuntu desktop normally. If I use auto-login, the drives don't show up. They appear as normal in dmesg, and I can access them using 'mount' at the command line. Affects my laptop and desktop, running xubuntu 32 and 64, updated today.

Here's mine. Hope it helps.

I discovered that auto-login has nothing to do with it in my case. USB drives will not mount on the first login, even if auto-login is disabled. I have to log out, then back in for drives to auto-mount. I created a new user to test and the same holds true for the new user. So what is reset when a user logs out and back in?

The problem still exists on the xubuntu RC iso. If i boot into the live cd, usb keys don't auto mount. If I log out and log in again, usb keys work.

I confirm this, too

I can confirm this, too, 3 different systems, 32 and 64 bit.

Just an additional observation:
You can mount USB drives implicitly e.g. using the Firefox save-as dialog. This dialog shows all USB drives and selecting one in the dialog mounts the drive. After that it is fully accessible but still not visible in Thunar bookmarks or on the desktop (as it is after logging in a second time).

I just made a huge breakthrough in this bug. Keep in mind, I may have a different bug than the others since I am using Ubuntu not Xubuntu. Checking the log files I see:

kern.log
Apr 26 22:01:33 chris-vaio580 kernel: [ 178.360607] end_request: I/O error, dev fd0, sector 0
Apr 26 22:01:33 chris-vaio580 kernel: [ 178.360630] Buffer I/O error on device fd0, logical block 0
Apr 26 22:01:46 chris-vaio580 kernel: [ 191.364631] end_request: I/O error, dev fd0, sector 0
Apr 26 22:01:46 chris-vaio580 kernel: [ 191.364655] Buffer I/O error on device fd0, logical block 0
Apr 26 22:01:59 chris-vaio580 kernel: [ 204.384347] end_request: I/O error, dev fd0, sector 0
Apr 26 22:01:59 chris-vaio580 kernel: [ 204.384370] Buffer I/O error on device fd0, logical block 0

This was occuring every 15 seconds or so. I have a removable floppy drive that was not attached because the bay is also used for an optional second battery. When I boot with the floppy drive in the bay, all my USB's and discs will mount and operate normally. I use my second battery most of the time but may occasionally need the floppy drive so can this be solved? I believe the floppy drive must be inserted or removed with the power off if this helps.

I also found that forcing Nautilus to restart by running "killall nautilus" in a terminal will temporarily fix the problem. I don't know if Thunar works the same way but those of you with Xubuntu may want to try this.

Another (hopefully helpful) observation:
Looking for a solution / workaround for the annoying Thunar double-click problem (#Bug #520118 ) I installed pcmanfm2 from the Lubuntu repos. And voilà - it does not just solve the double-click bug, but perfectly handles USB drives, too.

My xsession-errors

I Have the same insue in ubuntu and i find the solution.
1º Open synaptic and check to remove complete :usbmount , hal ,and pmount
2º after that install again only :pmount and hal (usbmount conflict and not neded)
And Automount working again 100%

Strange. I don't have usbmount or pmount installed.

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

I have IBM Thinkpad T41 laptop, and I can workaround this problem by disabling floppy support in bios. After this my usb disk mounts fine automatically.

Ok, upgraded my Ubuntu desktop 9.10 to 10.04 on my Toshiba NB100. Same problem, no pen-drives, usb disks or SD cards (internal reader, usb bus) show in thunar anymore. Packages pmount and usbmount not installed, hal is installed. Usbmount allows using everything in /media/usbX directories, but won't show in thunar.

Strange, as main goal for 10.04 was complete HAL removal (from boot), and in 9.10 there are lot of dependencies (in my system) for package hal, but in 10.04 only one: thunar-volman. And what is thunar-volman for? Ah, automatic management of removable drives and media...

Can this be solved?

It seems that while Firefox or Abiword can see my USB keys when plugged, Thunar or the "Places" applet can't. Also, my desktop is set up to show removable devices, but my plugged USB devices don't appear on it.

Ok, solved. Thunar REQUIRES hald to be running, for thunar-volman to work. Needs "sudo /usr/sbin/hald &" to be executed. Now pen-drives, SD cards and others automount and show fine in thunar.

Now, how to automate this? Easiest would be to grant rights for user to sudo hald without password prompt and run it for example in fluxbox startup script? Or do we have better ideas? Some cron trick?

And, wrong, need to go through "sudo -i" first and as root type "hald &" for this to work.

I think that I need cron for this. Until then, only manual option.

I can confirm that USB sticks do not mount in Thunar under normal login in Xubuntu 10.04, and that the fix "sudo /usr/sbin/hald &" does fix the problem. Now to find the way to run hald on boot. No doubt in the init scripts somewhere but has anything changed in how this operates in Lucid?

Here is the fix:

sudo nano /etc/rc.local

add this above the exit 0, like so:

~~~~~~~~~~
/usr/bin/hald

exit 0

~~~~~~~~~~

Save

Ensure the execution bit is set:

sudo chmod u+x /etc/rc.local

reboot.

Inserting a USB stick should now work and appear in Thunar left hand pane

I believe we are dealing with 2 different bugs here. One in Ubuntu and one in Xubuntu. In Ubuntu I already have hald running at boot. The problem that Rami Autiomäki and I have occurs when there is a floppy controller but no floppy drive. Is it possible to split this off to a separate bug?

There is this report https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/539515 that could be related to this problem in Ubuntu and Gnome.

/usr/sbin/hald in rc.local has finally solved my problem. Thank you very much, guys!

regarding workaround #39: you're definitely missing an "s" there, the path should read "/usr/sbin/hald" (ok, just saw that in the bug description that is already fixed).
also this workaround doesn't work for me.

can confirm the bug with xubuntu lucid (proposed).
"gksu thunar" actually shows my sd-card. (regarding workaround #30: neither pmount nor usbmount are installed.)

edit: workaround #39 works.

This bug also prevents auto-mounting of CDs and DVDs in Mythbuntu 10.04 (Mythbuntu is a cut down version of Ubuntu with Xfce and MythTV). Auto-mounting worked as expected in Mythbuntu 9.10.

Auto-login is turned on.
Logoff and manually login fixes it.
Editing /etc/rc.local to add hald does not seem to work.
Running "sudo -i" first and then as root typing "hald &" does not seem to work.

I've attached the logs requested.
auto-login.xsession-errors is directly after booting, exiting MythTV, and loading a CD into sr0.
manual-login.xsession-errors is after doing the above, logging off, login manually, and load the same CD.
dmesg.log.txt is a copy of /var/log/dmesg. I don't have /var/log/dmesg.log, so I guess this it.
dmesg.txt is a copy of the output of dmesg command. It seems to have a bit more than /var/log/dmesg.

I realise there are 3 lines of errors in dmesg.txt:
[ 70.039275] sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01 00 00 08 00
[ 70.039297] sr: Sense Key : Medium Error [current]
[ 70.039304] sr: Add. Sense: Unable to recover table-of-contents
but these errors still occur even when auto-mounting is successful:
[ 217.900802] sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01 00 00 08 00
[ 217.900825] sr: Sense Key : Medium Error [current]
[ 217.900832] sr: Add. Sense: Unable to recover table-of-contents
[ 219.347596] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 219.384511] ISO 9660 Extensions: RRIP_1991A

There is probably a race condition somewhere in thunar or libhal (since hal startup is delayed until something explicitely requests it). I don't think the bug is in policykit-1 anyway.

I could reproduce this on my 3 Xubuntu boxes I just upgraded. I do not use auto-login, so that is not a factor. What I notice is that in the first login session (xubuntu session) started after a reboot, hal is not started. If you that logout and log back in again, hal is started. All three had the latest updates as of May 2nd, when I tested this. One is a AMD64, the other two are i386 machines. I have put /usr/sbin/hald in rc.local on all three to work around this issue. I have tested with 1 USB stick, one iPod in disk-mode (=USB mass storage) and a phone connected via a USB cable as USB mass storage (+ttyACM0). Attached dmesg.log, .xsession-errors are from one of the i386 machines. Two versions: .first-login from the first login after a reboot, .second-login from the second login.

Erik, in my case automount didn't work only if I autologin-ed. If I used a normal login instead, then everything was ok. Your bug seems to have a different flavor.

When this bug happens, if you kill (or quit) all thunar instances (e.g. with Thunar --quit or ps + kill $pid), and restart it (Thunar --daemon), does automounting work with the new instance?

I tested both Lionel's suggestion in #57, and Dennis suggestion in #7 of 572042. First the results for Lionel's suggestion in #57 of this bug:
- rebooted without hald in rc.local
- inserted USB stick
- Killed 1 Thunar instance (Thunar --sm-cliend-id <long-string> --daemon
- started Thunar --daemon.
- This did not return to the prompt, so I pressed CTRL-Z, and type bg to put it in the background
- Nothing happens. Just as before /dev/sdb1 is created (/dev/sdb too) , no hal proces is started, /media/disk is not created.
- Eject USB stick (forcefully).
- /dev/sdb and /dev/sdb1 are deleted
- Insert USB stick again: /dev/sdb & sdb1 are created, /media/disk is not, no hald proces started.
Logs: xsession-errors.kill-Thunar and dmes.kill-Thunar

Now for the Dennis suggestion in #& of 572042: inserting the USB stick on reboot. This does make a slight difference in my case. The devices /dev/sdb and /dev/sdb1 are created, no hal proces is stated, but an entry in /media/ is created with root as owner. Result is I cannot read from it or write to it. I have not tested with autologin at all. All just plain logins. Logs: xsession-errors.mounted-before-reboot and dmes.mounted-before-reboot

I've put some thunar packages in my PPA (https://launchpad.net/~mrpouit/+archive/ppa/+sourcepub/1124104/+listing-archive-extra). It's just a small patch to init hal the same way lshal does (it works in lshal, so maybe there's a race condition somewhere in Thunar).

Could affected people remove any workaround, try to install them (thunar, thunar-data and libthunar-vfs-1-2 at least), and see if there's an improvement? I've an encrypted home partition, so I can't test autologin myself unfortunately...

Thanks for the patch. I can only test it in 9 days because I am leaving for a holiday in 2 hours. Will test when I return.

Lionel,
I am very new to Linux, so I am not sure what I should be doing with your PPA. I have been to https://launchpad.net/~mrpouit/+archive/ppa/+sourcepub/1124104/+listing-archive-extra and clicked on libthunar-vfs-1-2_1.0.1-3ubuntu1.1~ppa1_i386.deb, then chose to open it with the default option of GDebi Package Installer. This prompted about there being a more trusted package (already installed or something? I forget the exact message), but I chose to continue installing and it seemed to be successful. Synaptic Package Manager shows it as the installed version. When I click on thunar-data_1.0.1-3ubuntu1.1~ppa1_all.deb it seems to run through an installation very quickly, but I don't get a message about it having installed successfully, and Synaptic Package Manager shows the installed version as 1.0.1-3ubuntu1. However when I click on thunar_1.0.1-3ubuntu1.1~ppa1_i386.deb and it starts installing it stops with a Status: Error: Dependency is not satisfiable: thunar-data (= 1.0.1-3ubuntu1.1~ppa1).

Can someone please tell me if I am doing something wrong? I'm happy to test this patch, but I am guessing my way along at the moment.

The simplest way is to add my ppa to your sources.list (using the info given on https://launchpad.net/~mrpouit/+archive/ppa). Or you can also download the deb packages separately in a folder, open a terminal, go into this folder, and run "dpkg -i <put here all the deb filenames>".

Lionel,
I added your PPA to my Software Sources and installed them successfully. They show the right versions in Synaptic Package Manager.

Unfortunately it does not make a difference in either Mythbuntu 10.04 or Xubuntu 10.04. Both of these were fresh builds to remove any previous modifications. Note however that I have not installed any other available updates. I will have to try that tonight after work and see if it makes any difference.

Thanks for the feedback. I supposed lshal works, but I'm not so sure now (here it failed to start hal when requested). Could affected people try to run 'lshal' or/and 'sudo lshal' in a terminal (with all workarounds disabled)? If this does not work (i.e. it displays a "could not contact hald" error), then the bug is in hal…

Hmpf, I was finally able to test myself, and indeed, the first thunar instance doesn't detect removable devices, but if I kill it and restart it, it works. And lshal works without problem, so no issue in hal.

(and fwiw, the bug is probably in libthunar-vfs and not thunar, since the places panel plugin has the same issue...)

Hi Martin,

I think that the bug lies in hal finally. :p

I added fprintfs in libthunar-vfs, and the init code fails with libhal_ctx_init(). So I added also some printfs in libhal_ctx_init(), and it fails at:

hald_exists = dbus_bus_name_has_owner (ctx->connection, "org.freedesktop.Hal", &_error);
[...]
if (!hald_exists) {
                return FALSE;
        }

Because hal doesn't exist on the dbus at this time apparently. But it works fine if I restart Thunar later, so there might be a race condition somewhere? Anyway, dbus api doc clearly states that using this function can easily result in a race condition, so I don't really understand why libhal.c uses it...

Any idea, thoughts, tests to do? Thanks!

Ah, indeed.

With the dbus activation setup that we now have I think we should just patch out this check. Can you verifiy that it works then? (I'm on a conference this week and don't have time for hacking, sorry)

Yes, I just tried with the following patch, and it works fine here.

This bug is not only for autologin or automount. I don't use either. However the workaround with rc.local works

Thanks Lionel! I committed that to the packaging bzr (http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/376).

I suppose you want this SRUed for lucid? I added a lucid task for this. If you could upload it to lucid-proposed (well, I can sponsor if neccessary), I can review and SRU-approve it.

Actually, I'll upload my current hal straight to lucid-proposed. We can push it to maverick later on.

So, SRU ack for Lionel's patch in comment 72. Regression potential is very low, since it only removes a now unnecessary check. Running "lshal" on a system which does not have the hal daemon running works properly now, too.

Accepted hal into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

removed the workaround, installed the upgrade from proposed and rebooted -> issue resolved, bug fixed.

thanks a lot lionel!

This bug was fixed in the package hal - 0.5.14-0ubuntu6

---------------
hal (0.5.14-0ubuntu6) lucid-proposed; urgency=low

  * Add 02_libhal_dont_check_running.patch: In libhal_ctx_init(), do not check
    if hal is already running, since it will get D-Bus activated. Thanks to
    Lionel Le Folgoc for the patch! (LP: #546992)
  * Add 00git_bigger_path_size.patch: Bump HAL_PATH_MAX to 4096. Patch taken
    from upstream git head. (LP: #525245)
 -- Martin Pitt <email address hidden> Sun, 09 May 2010 12:00:16 +0200

Copied lucid-proposed to maverick.

Rebuilt Mythbuntu 10.04 and Xubuntu 10.04 from scratch and installed only updated hal, libhal1 & libhal-storage1 (all version 0.5.14-0ubuntu6) from lucid-proposed, rebooted -> bug fixed.

Thanks Lionel and Martin.

This bug was fixed in the package hal - 0.5.14-0ubuntu6

---------------
hal (0.5.14-0ubuntu6) lucid-proposed; urgency=low

  * Add 02_libhal_dont_check_running.patch: In libhal_ctx_init(), do not check
    if hal is already running, since it will get D-Bus activated. Thanks to
    Lionel Le Folgoc for the patch! (LP: #546992)
  * Add 00git_bigger_path_size.patch: Bump HAL_PATH_MAX to 4096. Patch taken
    from upstream git head. (LP: #525245)
 -- Martin Pitt <email address hidden> Sun, 09 May 2010 12:00:16 +0200