Device automounts does not work with 2.6.10-2 (Hoary)

Bug #12339 reported by Juan Jose Amor Iglesias
8
Affects Status Importance Assigned to Milestone
hal (Ubuntu)
Fix Released
Medium
Martin Pitt

Bug Description

Device automounts does not work when I insert a USB flash disk, for example.
With old 2.6.9 kernel it works ok. With 2.6.10-2 package, kernel detects device
and udev create device nodes on /dev. However, nobody tries to mount it
automatically. I can mount manually by using "pmount /dev/sda1".

Revision history for this message
Martin Pitt (pitti) wrote :

Hmm, I also have the very latest Hoary kernel, works fine for me. Can you please do

  ps aux| grep hald

and paste the output here? Also, please do

  lshal > lshal.txt

and attach the file lshal.txt to this bug report. Thanks!

Revision history for this message
Juan Jose Amor Iglesias (jjamor) wrote :

Requested info:

$ ps axu|grep hald
hal 7583 0.0 0.4 5140 3700 ? Ss 08:52 0:00 /usr/sbin/hald
--drop-privileges

Revision history for this message
Juan Jose Amor Iglesias (jjamor) wrote :

Created an attachment (id=1225)
lshal output

Revision history for this message
Martin Pitt (pitti) wrote :

Thanks for the feedback so far. It seems that your hald does not detect any
volumes on the USB disk.

Can you please post the output of

  dmesg | tail -n 20

directly after plugging in the device? Also, can you please do

  ls -l /dev/sd*

and put the output here?

Thanks!

Revision history for this message
Juan Jose Amor Iglesias (jjamor) wrote :

$ dmesg | tail -30

usb 2-1: new full speed USB device using uhci_hcd and address 2
SCSI subsystem initialized
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
  Vendor: Model: Rev:
  Type: Direct-Access ANSI SCSI revision: 02
usb-storage: device scan complete
SCSI device sda: 256000 512-byte hdwr sectors (131 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
SCSI device sda: 256000 512-byte hdwr sectors (131 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
 /dev/scsi/host0/bus0/target0/lun0: p1
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0

ls -l /dev/sd*

brw-rw---- 1 root plugdev 8, 0 2005-01-31 11:21 /dev/sda
brw-rw---- 1 root plugdev 8, 1 2005-01-31 11:21 /dev/sda1

(note that USB disk is detected and can be used, however it is not automounted)

Revision history for this message
Martin Pitt (pitti) wrote :

Hmm, this output looks fine. So, the next step: Please remove the device, then do

  sudo /etc/dbus-1/event.d/20hal stop
  sudo hald --drop-privileges --verbose=yes --daemon=no 2>&1 | tee hal.out

then please wait until the flood of messages has settled. Insert your USB
device, wait until the output is finished.

Then press Control-C to stop the debugging hal, do

  sudo /etc/init.d/dbus-1 restart

to properly restart hal again and attach the hal.log file here.

Thanks!

Revision history for this message
Juan Jose Amor Iglesias (jjamor) wrote :

Created an attachment (id=1226)
HAL output (debug mode)

Revision history for this message
L.Lopez (ldotlopez) wrote :

I have been stracing hald while I insert a USB disk.
I cant attach the trace because the file is too big (2Mb).

In that log I can see one or more attempts to open a temporal file on /etc.
Those attempts come from the fstab-sync process which is called by hal.
hald/fstab-sync have no privileges to create files in /etc.

Doing a "chmod 777 /etc" enables fstab-sync to create that file and update the
fstab.

The problem now comes from gnome-vfs-daemon. I have to manually kill it to force
nautilus
to show the new devices.

At this point I can mount devices from nautilus but I cant umount them, nautilus
thinks that
they are not mounted.

I agree the rest of the comments of the bug: hal creates the device nodes, I can
use pmount to
mount them, etc...

May be gamin be involved in this bug?

I'm using Hoary up-to-date.
kernel version: 2.6.10-2
hal version is 0.4.7-1ubuntu1
gamin version: 0.0.21-0ubuntu2

Pd. Excuse my poor english.

Revision history for this message
Matt Zimmerman (mdz) wrote :

(In reply to comment #8)
> I have been stracing hald while I insert a USB disk.
> I cant attach the trace because the file is too big (2Mb).
>
> In that log I can see one or more attempts to open a temporal file on /etc.
> Those attempts come from the fstab-sync process which is called by hal.
> hald/fstab-sync have no privileges to create files in /etc.
>
> Doing a "chmod 777 /etc" enables fstab-sync to create that file and update the
> fstab.

This is not a bug (and by changing the permissions you have created a serious
security vulnerability on your system). We don't use fstab-sync in Ubuntu.

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #7)
> Created an attachment (id=1226) [edit]
> HAL output (debug mode)

Thanks for this. However, this is still not enough for me to localize the bug,
so I need some further debugging.

I prepared a logging-enriched version of hald (compiled for i386) and put it to

  http://people.ubuntu.com/~pitti/hald

Can you please download this and do similar steps with the downloaded hal
version again?

Please remove the device, then do

  sudo /etc/dbus-1/event.d/20hal stop
  sudo /path/to/downloaded/hald --drop-privileges --verbose=yes --daemon=no 2>&1
| tee hal.out

(use the downloaded version here, not the one in /usr/sbin)

then please wait until the flood of messages has settled. Insert your USB
device, wait until the output is finished.

Then press Control-C to stop the debugging hal, do

  sudo /etc/init.d/dbus-1 restart

to properly restart hal again and attach the hal.log file here.

Thanks!

Revision history for this message
Juan Jose Amor Iglesias (jjamor) wrote :

Created an attachment (id=1331)
(Alternative) hald output -- debugging mode

This is requested hal.out. Note that this version of HAL has another behavior:

- It has mounted my VFAT partition /dev/hda2, however it is not desired (I wish
mount it on demand, by clicking on appropiate icon in Nautilus, Disks view)

- When inserted USB disk, the device has been correctly mounted and Nautilus
displayed it.

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #11)
> Created an attachment (id=1331) [edit]
> (Alternative) hald output -- debugging mode
>
> This is requested hal.out. Note that this version of HAL has another behavior:

That is really odd since the only thing I changed are some debug output
messages, nothing else. Which version of hal did you use before?

> - It has mounted my VFAT partition /dev/hda2, however it is not desired (I wish
> mount it on demand, by clicking on appropiate icon in Nautilus, Disks view)

Hal does not mount _anything_ on its own (this is g-v-m's and pmount's job). Do
you still have fstab-sync enabled? If so, please disable it, fstab-sync is madness.

> - When inserted USB disk, the device has been correctly mounted and Nautilus
> displayed it.

Cool! But I really don't see why this hal version should work and Hoary's
shouldn't, because it's really exactly the same code. Can you please upgrade to
the latest Hoary hal and try again?

Thanks!

Revision history for this message
Juan Jose Amor Iglesias (jjamor) wrote :

I've upgraded again. The bug disappeared with new hal packages provided (0.4.7).
With 0.2.98 the problem persists (using kernel packages 2.6.10).

Shall we close the bug?

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #13)
> I've upgraded again. The bug disappeared with new hal packages provided (0.4.7).
> With 0.2.98 the problem persists (using kernel packages 2.6.10).

Ah, you used the Warty version before, that explains it :-) If it's fixed in
Hoary, we can close the bug (since Warty cannot be fixed anyway).

Thanks for your extensive testing!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.