Mounting UDF should be preferred over ISO9660

this might be a bug in 'mount' rather than gnome-volume-manager, or maybe both? not sure how it works

If i run mount -t udf /dev/scd0 /media/cdrom0 it happily mounts UDF

I guess this is because hal only checks whether the device is in fstab and thus the user *could* use mount to mount it manually. However, gnome-mount/hal do their own mount options assembling, so it's very likely that they just have the wrong preference order.

Fixing source package again.

That bug still persists in Feisty (kernel 2.6.20-16-generic):

in /etc/fstab:
'/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0'
automount mounts as 'iso9660' despite it is a pure udf-dvd (iso-level 4, no Joliet, no Rockridge extensions):

cat /proc/mounts =>
'/dev/scd0 /media/cdrom0 iso9660 ro,nosuid,nodev,noexec 0 0'

manual umount and mounting with option '-t udf' does it correctly:

cat /proc/mounts =>
'/dev/sr0 /media/cdrom0 udf ro 0 0'

So to me it is not the mount command, but either hal or the GNOME automount feature.
(a related bug is that the fstab option 'noauto' is ignored as soon as also the option 'users' is present: a device, i.e. harddisk, is than mounted automatically at boot-up)

I forgot to mention that this bug is really annoying:

if you have files larger than 4 GB on such a disk, then mounting it as iso9660, displays the filesize modulo 4 GB and it cannot be read out.

ingo is wright. In my case (7.04 feisty) the DVD with 4GB file on it doesn't even mount displaying only an error message "Can't mount...." and something like that. With -t udf option - everything goes OK. Must fix it...

gnome-volume-manager uses gnome-mount to mount volume.
and if an entry is present in /etc/fstab, gnome-mount will launch the mount command on the correspond mount point so the fstab options are used.

For the cdrom, gnome-mount will just do:
   mount /media/cdrom0

Could you check type that command to see if you reproduce the bug with the mount command ?

Found an udf cdrom and I wasn't able to reproduce this bug under gutsy, the cdrom was mounted with the udf filesystem.

The bug is only partly solved with Gusty. In Feisty it persists completely.
I now report 2 different experiments:

1. using a commercial 9GB-DVD-ROM here which definitely contains UDF-extensions
    Gusty correctly automounts with udf.

    Feisty automounts with iso9660, here output from
    'cat /proc/mounts' -> /dev/scd0 /media/cdrom0 iso9660 ro,nosuid,nodev,noexec 0 0

    executing your proposed command 'mount /media/cdrom0' mounts iso9660:
    'cat /proc/mounts' -> /dev/scd0 /media/cdrom0 iso9660 ro,nosuid,nodev,noexec 0 0

    Manually I can mount the DVD-ROM as udf:
    root@pp:/home/ingo# mount -t udf /dev/sr0 /media/cdrom0
       mount: block device /dev/sr0 is write-protected, mounting read-only
    'cat /proc/mounts' -> /dev/sr0 /media/cdrom0 udf ro 0 0

2. I have got a DVD-R here, which contains files > 2GB, so it must use udf:
    This DVD-R does not automount at all, neither under Feisty, nor under Gusty
    It spins up twice after inserting, keeps spinning for a while, then stops without beeing mounted.
    No Icon showing up on the Desktop, device not listed in /proc/mounts

    executing your proposed command 'mount /media/cdrom0' mounts iso9660 without icon on desktop:
       mount: block device /dev/scd0 is write-protected, mounting read-only
    'cat /proc/mounts' -> /dev/scd0 /media/cdrom0 iso9660 ro,nosuid,nodev,noexec 0 0
    which definitely is wrong!

    Manually mounting using the '-t' option works fine:
    mount -t udf /dev/sr0 /media/cdrom0
       mount: block device /dev/sr0 is write-protected, mounting read-only
    'cat /proc/mounts' -> /dev/sr0 /media/cdrom0 udf ro 0 0
    and DVD-ROM is completely readable.

So, conclusion:
partly solved in Gusty (probably as long as filesize stays below 2GB), but still present in Feisty.
With filesize > 2GB (up to 4GB should be ok for UDF anyway), bug persists in Gusty and Feisty.

Ingo

On Gutsy, could you do the following:

sudo strace mount /media/cdrom0 2>/tmp/mount.strace1.txt
sudo umount /media/cdrom0
sudo strace mount -t udf /dev/scd0 /media/cdrom0 2> /tmp/mount.strace2.txt
sudo umount /media/cdrom0

and attach the /tmp/mount.strace1.txt and /tmp/mount.strace2.txt files.

Here the output comes. I did suppose, you wanted it with the UDF-DVD-R, which is NOT automounted due to whatever reason under both, Feisty and Gusty. Output was obtained under Gusty.

Will a potential fix also be applied to Feisty?

Addition:
no automounting under Gusty, but at least both commands resulted in mounting as udf:
mount.strace1.txt
mount.strace2.txt

--------------------------
And here as an addition the same for Feisty, which results in iso9660 mounting:
strace mount /media/cdrom0 2>/tmp/mount.strace3.txt

I really would appreciate to get Feisty fixed as well, because currently it is more reliable here than Gusty.

Strange, the first strace log tells me that the cdrom was mounted with the udf filesystem.

You confirm that after having done: strace mount /media/cdrom0
the UDF-DVD-R was mounted with the iso9660 filesystem ?
Can you do a "cat /etc/mtab" after the mount ?

You are mixing up some things:

Gusty:
mount /media/cdrom0 2>/tmp/mount.strace1.txt -> mounts udf
mount -t udf /dev/scd0 /media/cdrom0 2> /tmp/mount.strace2.txt -> mounts udf

Feisty:
mount /media/cdrom0 2>/tmp/mount.strace3.txt -> mounts iso9660!!!
mount -t udf /dev/scd0 /media/cdrom0 2> /tmp/mount.strace4.txt -> mounts udf

Neither Gusty nor Feisty mount automatically!

(In my long posting '3 hours ago' paragraph 2 was obtained with Feisty!)

yes, I first thought that your DVD-R was mounted iso9660 under feisty and gutsy.

Concerning the first problem under feisty, indeed there is a bug with the mount command, here is what happens:
     - it tries mount with udf, it fails because it can't mount it read-write
     - it tries mount with iso9660, it fails because it can't mount it read-write

then it tries to mount it readonly, but it didn't reinitialize the fs types list and retry with iso9660 instead of udf, so:
      - it tries to mount directly with iso9660 and succeeds.

This bug has been fixed in gutsy, I don't know how to have bug fixed in feisty, maybe you can request a backport.
However there is an easy workaround, just add the ro option for the cdrom in /etc/fstab:
    /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,ro 0 0

Then mount will directly succeed to mount the dvd with udf even under feisty (with the mount command).

Concerning your second problem, that's a different bug, but can you do this ?
   hal-device | egrep " udi|scd0" | grep -B 1 scd0
and retrieve the udi of the cdrom device (take the first one)

then do:
   gnome-mount --hal-udi <the_udi_found>

does it mount the DVD ?

If it doesn't work, do:
    sudo strace -f gnome-mount --hal-udi <the_udi_found> 2> gnome-mount.strace.txt

and attach the trace file.

Yann,

thanks for the workaround in Feisty - added 'ro' to the mount options and it works!
(I do hope it does not matter with DVD-RAM or DVD-RW in that drive, it is a recorder!)

With this fix applied I did the requested tests in Gusty and Feisty - it does not mount of course ;-)
GNOME reports a pop-up saying: "Unable to mount media - probably no disk in the drive"
(the UDI was: udi = '/org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H30N')

and the debug output is attached for both, Feisty (with ro-fix) and Gusty.

Good luck!

You should have had two udi, the first one should be used and rather look like: /org/freedesktop/Hal/devices/volume_...
did you type:
   hal-device | egrep " udi|scd0" | grep -B 1 scd0
while the DVD-R was in the drive ?

If even with the dvd in the drive, you do not have the good udi, then hal should be the problem.
Do:
    - eject the dvd if present in the drive
    - stop hal: sudo /etc/init.d/hal stop
    - launch in verbose mode: sudo su -s /bin/sh haldaemon -c "hald --daemon=no --verbose=yes" >/tmp/hal.debug.txt 2>&1
    - wait several seconds that hal finished its startup
    - insert the dvd
    - wait several seconds
    - type ctrl+c
    - relaunch hal: sudo /etc/init.d/hal start

and attach the hal.debug.txt file

> You should have had two udi

Here the full output with DVD in the drive:

root@pp:/home/ingo# hal-device | egrep " udi|scd0" | grep -B 1 scd0
7: udi = '/org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H30N'
  block.device = '/dev/scd0' (string)
root@pp:/home/ingo#

and I did use the string following '7:udi =' for yesterday's reports.
It does not refer to the volume, but to the type/brand of the drive/recorder. So I followed your further instructions:
All under Feisty (I will try with Gusty after finishing here).
Unfortunately your commands do not work:

root@pp:/home/ingo# /etc/init.d/hal stop
bash: /etc/init.d/hal: No such file or directory

So I searched the filetree for hal and found it under /etc/default:

root@pp:/home/ingo# /etc/default/hal stop
bash: /etc/default/hal: Permission denied

That is absolutely strange that, even as root (with sudo exactly the same) I do not have permission .
So I checked the directory entry for hal:

root@pp:/home/ingo# ls -l /etc/default/ha*
-rw-r--r-- 1 root root 13 2007-03-30 19:52 /etc/default/hal
-rw-r--r-- 1 root root 86 2007-04-10 23:45 /etc/default/halt

So hal is not executable and the content of that file is:

root@pp:/home/ingo# cat /etc/default/hal
DAEMON_OPTS=

So please help further, I do not know what to perform else.

now I rebooted and started Gusty.
Here your commands work fine and I do attach the debug output obtained.

root@pp:/home/ingo# /etc/init.d/hal stop
 * Stopping Hardware abstraction layer hald [ OK ]
root@pp:/home/ingo# su -s /bin/sh haldaemon -c "hald --daemon=no --verbose=yes" >/tmp/hal.debug.txt 2>&1
root@pp:/home/ingo# /etc/init.d/hal start
 * Starting Hardware abstraction layer hald [ OK ]
root@pp:/home/ingo#

The DVD is not mounted, instead I get a pop-up telling me:
"Cannot mount volume.
You are not privileged to mount this volume."

Mysterious, because I performed all the commands as root

Do you have a process named hald-addon-storage ?
    ps -Af | grep hald-addon-storage

You should have something like:
   hald-addon-storage: polling /dev/scd0 (every 2 sec)

> Do you have a process named hald-addon-storage ?

Checked under Gusty:

ingo@pp:~$ ps -Af | grep hald-addon-storage
107 7447 7317 0 13:00 ? 00:00:00 hald-addon-storage: polling /dev/sdb (every 2 sec)
107 7474 7317 0 13:00 ? 00:00:00 hald-addon-storage: polling /dev/scd0 (every 2 sec)
107 7481 7317 0 13:00 ? 00:00:01 hald-addon-storage: polling /dev/scd1 (every 2 sec)
ingo 7800 7795 0 16:28 pts/0 00:00:00 grep hald-addon-storage

Do you need the output under Feisty as well?

No need for feisty.

Do:
   - eject the dvd
   - sudo strace -f -p <pid of the hald-addon-storage polling your drive device> -o /tmp/addon-storage.strace.txt
   - insert the cd
   - wait
   - ctrl+c
   - send the /tmp/addon-storage.strace.txt file.

Done, here it comes (have choosen PID 7474 for sdc0)

BTW, could you also open another bug report for that (something like: "DVD-R not auto-mounted by Gnome").
We are adding comments not linked to the original bug and the original bug could be closed for gutsy.

I did open a new bug report for this issue. It is:

https://bugs.launchpad.net/ubuntu/+source/hal/+bug/157775

Please consider, that I do not have time to do more tests right now, will be available tomorrow about noon CEST.

So the original bug has been fixed for Gusty, but closing it would not be quite fair:
It was opened im May for Feisty, so I still do hope to get it also fixed for Feisty ;-)

Ingo

I nominated this bug for feisty (and for gutsy, to mark it fixed).

I don't yet know how things work in ubuntu but from I understood, this is how you request a fix in feisty.
Maintainers will reject it if they don't think it's necessary.

Many Thanks,
Ingo

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - the Intrepid Ibex. It won't be fixed in previous versions of Ubuntu because the package doesn't fit the requirements for backporting. See https://help.ubuntu.com/community/UbuntuBackports for more information.