I have a DVD ROM (It's DeLorme Topo USA), which works fine booted in Windows.
Under Linux it mounts fine, but shows no files. Everything looks normal, like
it should just work.
What's up? And ideas?
[root@HardHat bryce]# df
...
/dev/scd0 326028 326028 0 100% /mnt/cdrom
/dev/hdc 3277426 3277426 0 100% /mnt/dvdrom
[root@HardHat bryce]# uname -a
Linux HardHat 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
[root@HardHat bryce]# cat /proc/filesystems
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
nodev proc
ext2
iso9660
nodev devpts
nodev usbdevfs
vfat
nodev autofs
[root@HardHat bryce]# dd if=/dev/hdc of=/tmp/A bs=1024 count=200
200+0 records in
200+0 records out
[root@HardHat bryce]# strings /tmp/A
CD001
T3DVD
DELORME ADJ 1999111712541000
2001022814540400
2001022814540400
CD001
9%/E
1999111712541000
2001022814540400
2001022814540400
CD001
BEA01
NSR02
TEA01
T3DVD
00026f70 MTC ForDVD 5.9, March 2000
OSTA Compressed Unicode
OSTA Compressed Unicode
*Multimedia Tech. Cntr.
*UDF LV Info
# grep ATAPI /var/log/messages
Dec 30 17:53:40 hardhat kernel: hdc: DVD-ROM SD-M1402, ATAPI CD/DVD-ROM
drive
Hello Bryce :)
>What's up? And ideas?
Have you 'UDF' support in your kernel? This may be the problem.
Ra?l
Vitaly Lipatov:
> On my system it do not work. :(
So, if either mount is broken or its documentation
is outdated, why not write to the maintainer ([email protected])
and tell what is wrong? Empty complaints are useless.
Andries
[email protected] wrote on 31.12.01 in <[email protected]>:
> Vitaly Lipatov:
>
> > On my system it do not work. :(
>
> So, if either mount is broken or its documentation
> is outdated, why not write to the maintainer ([email protected])
> and tell what is wrong? Empty complaints are useless.
Well, it seems to me that the behaviour described matches the description:
the list mount claims to try *first*, before looking at user-supplied
filesystem lists, includes iso9660 but not UDF. So ...
MfG Kai
> Here are the first 2048 1024 byte blocks.
Hmm. I am a bit slow, but just looked at this image.
It looks fine in iso9660 style, provided you give the
nojoliet option. I get:
# mount DeLorme_TopoUSA_DVD.head /mnt -t iso9660 -o loop,nojoliet
# ls -l /mnt
total 12
dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
-r-xr-xr-x 1 root root 2763 Feb 28 2001 cd.txt
dr-xr-xr-x 1 root root 2048 Feb 28 2001 data
-r-xr-xr-x 1 root root 196 Feb 28 2001 pdataset.txt
and
# mount DeLorme_TopoUSA_DVD.head /mnt -t udf -o loop
# ls -l /mnt
total 14
dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 .
drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
-r--r--r-- 1 4294967295 4294967295 2763 Feb 28 2001 CD.TXT
dr-xr-xr-x 2 4294967295 4294967295 380 Feb 28 2001 DATA
-r--r--r-- 1 4294967295 4294967295 196 Feb 28 2001 PDATASET.TXT
so the iso9660 version looks a bit better than the udf version.
(But I cannot look at the actual contents because the initial
fragment is not large enough. You can check for yourself
whether the nojoliet mount is OK.)
Thus, there do not seem reasons to change mount(2) or mount(8)
in the way you suggested. There is no "empty iso9660 filesystem" here.
Andries
Confirmed. The DVD in question (DeLorme Topo USA) shows files when mounted
with "nojoliet". But when the application is run, the maps are scrambled.
It must be mounted as udf to work.
The original bug report incorrectly asserted that the iso9660 filesystem
was empty, sorry about that.
But this does seem to be an example (which
has been widely reported elsewhere) of a DVD with a differing udf and iso9660
filesystems. Lots of people have reported that, since Windows no longer
uses the "iso9660 udf bridge", lots of mastered DVDs have unintentionally
corrupt versions of it. Others have hinted this is done deliberately for
copy protection reasons.
-Bryce
Solving the problem by documentation
------------------------------------
The patches already supplied to mount(8) and fstab (5) give give a sysadmin
the tools to learn about and solve the problem, thanks for applying them!
It just seems like there's a bit more to say about potentially differing udf
and iso9660 filesytems on the same disc... that's the thiking behind the extra
paragraph in the patch.
Solving the problem automatically (keeping the issue out of the users face)
---------------------------------------------------------------------------
Mastering houses will test their discs on Windows. While in general emulating Windows
is something I hate, here it makes sense. The more
closely the mount automounter emulates how windows automounts, the more likely
this type of discussion will never need to come up.
According to Alan Windows tries udf first, blindly, then falls back to iso9660.
As many people pointed out, this is not a kernel issue, it's a automount
isuse.
[email protected] wrote:
>
> > Here are the first 2048 1024 byte blocks.
>
> Hmm. I am a bit slow, but just looked at this image.
> It looks fine in iso9660 style, provided you give the
> nojoliet option. I get:
>
> # mount DeLorme_TopoUSA_DVD.head /mnt -t iso9660 -o loop,nojoliet
> # ls -l /mnt
> total 12
> dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
> drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
> -r-xr-xr-x 1 root root 2763 Feb 28 2001 cd.txt
> dr-xr-xr-x 1 root root 2048 Feb 28 2001 data
> -r-xr-xr-x 1 root root 196 Feb 28 2001 pdataset.txt
>
> and
>
> # mount DeLorme_TopoUSA_DVD.head /mnt -t udf -o loop
> # ls -l /mnt
> total 14
> dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 .
> drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
> -r--r--r-- 1 4294967295 4294967295 2763 Feb 28 2001 CD.TXT
> dr-xr-xr-x 2 4294967295 4294967295 380 Feb 28 2001 DATA
> -r--r--r-- 1 4294967295 4294967295 196 Feb 28 2001 PDATASET.TXT
>
> so the iso9660 version looks a bit better than the udf version.
> (But I cannot look at the actual contents because the initial
> fragment is not large enough. You can check for yourself
> whether the nojoliet mount is OK.)
>
> Thus, there do not seem reasons to change mount(2) or mount(8)
> in the way you suggested. There is no "empty iso9660 filesystem" here.
>
> Andries
Here is the table of contents mounted three ways. First udf, then
iso9660, then iso9660 nojoliet. Only the udf version works with the
application. Note that the huge udf filesizes are not a mistake -
this DVD is also offered as 7 CD set.
/mnt/cdrom1/:
total 14
dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 .
drwxr-xr-x 24 root root 4096 Jan 5 10:27 ..
-r--r--r-- 1 4294967295 4294967295 2763 Feb 28 2001 CD.TXT
dr-xr-xr-x 2 4294967295 4294967295 380 Feb 28 2001 DATA
-r--r--r-- 1 4294967295 4294967295 196 Feb 28 2001 PDATASET.TXT
/mnt/cdrom1/DATA:
total 3266832
dr-xr-xr-x 2 4294967295 4294967295 380 Feb 28 2001 .
dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 ..
-r--r--r-- 1 4294967295 4294967295 34735660 Feb 28 2001 GRIDAK.DAT
-r--r--r-- 1 4294967295 4294967295 1921298 Feb 28 2001 GRIDAK.IND
-r--r--r-- 1 4294967295 4294967295 1832319997 Feb 28 2001 GRID.DAT
-r--r--r-- 1 4294967295 4294967295 51128921 Feb 28 2001 GRID.IND
-r--r--r-- 1 4294967295 4294967295 34839 Feb 28 2001 VEC.COV
-r--r--r-- 1 4294967295 4294967295 1424439251 Feb 28 2001 VEC.V
-r--r--r-- 1 4294967295 4294967295 643405 Feb 28 2001 VEC.VI
/mnt/cdrom1/:
total 1
dr-xr-xr-x 1 root root 1 Feb 28 2001 .
/mnt/cdrom1/:
total 12
dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
drwxr-xr-x 24 root root 4096 Jan 5 10:27 ..
-r-xr-xr-x 1 root root 2763 Feb 28 2001 cd.txt
dr-xr-xr-x 1 root root 2048 Feb 28 2001 data
-r-xr-xr-x 1 root root 196 Feb 28 2001 pdataset.txt
/mnt/cdrom1/data:
total 22849
dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
dr-xr-xr-x 1 root root 2048 Feb 28 2001 ..
-r-xr-xr-x 1 root root 1181228 Feb 28 2001 gridak.dat
-r-xr-xr-x 1 root root 1921298 Feb 28 2001 gridak.ind
-r-xr-xr-x 1 root root 3603453 Feb 28 2001 grid.dat
-r-xr-xr-x 1 root root 797273 Feb 28 2001 grid.ind
-r-xr-xr-x 1 root root 34839 Feb 28 2001 vec.cov
-r-xr-xr-x 1 root root 15153107 Feb 28 2001 vec.v
-r-xr-xr-x 1 root root 643405 Feb 28 2001 vec.vi
As this is one clear example of differing iso9660 and udf views
of the same disc, I propose to change mount(8) and fstab(5) to warn the
two can be different (either intentionally, accidentally, or because
of iso9660 limitations).
I also propose to change "mount -t auto" to try udf first, and fall back to
iso9660. This, of course, requires more discussion first. But based
on serching other lists, reading the udf "iso9660 bridge" spec,
and email conversations, it seems to be the right long term answer.
Since udf is used on CD's, I propose that udf be tried first for
all meda, not just DVD's.
The kernel, of course, remains unchanged, and because you're using Linux,
you would still be able force mount anything you want.
-Bryce
[email protected] wrote:
>
> > Here are the first 2048 1024 byte blocks.
>
> Hmm. I am a bit slow, but just looked at this image.
> It looks fine in iso9660 style, provided you give the
> nojoliet option. I get:
>
> # mount DeLorme_TopoUSA_DVD.head /mnt -t iso9660 -o loop,nojoliet
> # ls -l /mnt
> total 12
> dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
> drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
> -r-xr-xr-x 1 root root 2763 Feb 28 2001 cd.txt
> dr-xr-xr-x 1 root root 2048 Feb 28 2001 data
> -r-xr-xr-x 1 root root 196 Feb 28 2001 pdataset.txt
>
> and
>
> # mount DeLorme_TopoUSA_DVD.head /mnt -t udf -o loop
> # ls -l /mnt
> total 14
> dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 .
> drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
> -r--r--r-- 1 4294967295 4294967295 2763 Feb 28 2001 CD.TXT
> dr-xr-xr-x 2 4294967295 4294967295 380 Feb 28 2001 DATA
> -r--r--r-- 1 4294967295 4294967295 196 Feb 28 2001 PDATASET.TXT
>
> so the iso9660 version looks a bit better than the udf version.
> (But I cannot look at the actual contents because the initial
> fragment is not large enough. You can check for yourself
> whether the nojoliet mount is OK.)
>
> Thus, there do not seem reasons to change mount(2) or mount(8)
> in the way you suggested. There is no "empty iso9660 filesystem" here.
>
> Andries
From [email protected] Sat Jan 5 17:14:28 2002
Here is the table of contents mounted three ways. First udf, then
iso9660, then iso9660 nojoliet. Only the udf version works with the
application. Note that the huge udf filesizes are not a mistake -
this DVD is also offered as 7 CD set.
[iso9660 nojoliet:]
/mnt/cdrom1/data:
total 22849
dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
dr-xr-xr-x 1 root root 2048 Feb 28 2001 ..
-r-xr-xr-x 1 root root 1181228 Feb 28 2001 gridak.dat
-r-xr-xr-x 1 root root 1921298 Feb 28 2001 gridak.ind
-r-xr-xr-x 1 root root 3603453 Feb 28 2001 grid.dat
-r-xr-xr-x 1 root root 797273 Feb 28 2001 grid.ind
-r-xr-xr-x 1 root root 34839 Feb 28 2001 vec.cov
-r-xr-xr-x 1 root root 15153107 Feb 28 2001 vec.v
-r-xr-xr-x 1 root root 643405 Feb 28 2001 vec.vi
Hmm. I find
total 3266826
dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
dr-xr-xr-x 1 root root 2048 Feb 28 2001 ..
-r-xr-xr-x 1 root root 1832319997 Feb 28 2001 grid.dat
-r-xr-xr-x 1 root root 51128921 Feb 28 2001 grid.ind
-r-xr-xr-x 1 root root 34735660 Feb 28 2001 gridak.dat
-r-xr-xr-x 1 root root 1921298 Feb 28 2001 gridak.ind
-r-xr-xr-x 1 root root 34839 Feb 28 2001 vec.cov
-r-xr-xr-x 1 root root 1424439251 Feb 28 2001 vec.v
-r-xr-xr-x 1 root root 643405 Feb 28 2001 vec.vi
Could it be that you are using some old kernel, say, older than
2.4.13, that enables the "cruft" option when it sees a big file?
(You should see the corresponding messages in the logs.)
Andries