Today I got a CD. MacOS does not mount it and Linux does not
mount it without an explicit filesystemtype option.
That is,
# mount /dev/hdc /dir -t iso9660
works fine, but
# mount /dev/hdc /dir
mount: you didn't specify a filesystem type for /dev/hdc
I will try type udf
mount: wrong fs type, bad option, bad superblock on /dev/hdc,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# dmesg | tail
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
udf: udf_read_inode(ino 547) failed !bh
UDF-fs: Error in udf_iget, block=1, partition=1
Google gave me half a dozen other people that mentioned the same
problem (with the same inode 547). Clearly some CD mastering software
produces a format that Linux and MacOS do not handle easily.
One result of this letter will be that people with the same problem
learn via Google that using the "-t iso9660" option may help.
What goes wrong on the mount side is that when it hesitates between
iso9660 and udf it decides for udf when seeing "NSR02".
Maybe the heuristics in mount should be tuned.
On the other hand, this filesystem announces itself as UDF
("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
perhaps the kernel code should be more robust.
If anybody feels responsible for mount and/or this kernel area
we might discuss.
Andries
> Today I got a CD. MacOS does not mount it and Linux does not
> mount it without an explicit filesystemtype option.
> That is,
> # mount /dev/hdc /dir -t iso9660
> works fine, but
> # mount /dev/hdc /dir
> mount: you didn't specify a filesystem type for /dev/hdc
> I will try type udf
> mount: wrong fs type, bad option, bad superblock on /dev/hdc,
> missing codepage or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
> # dmesg | tail
> UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
> udf: udf_read_inode(ino 547) failed !bh
> UDF-fs: Error in udf_iget, block=1, partition=1
>
> Google gave me half a dozen other people that mentioned the same
> problem (with the same inode 547). Clearly some CD mastering software
> produces a format that Linux and MacOS do not handle easily.
>
> One result of this letter will be that people with the same problem
> learn via Google that using the "-t iso9660" option may help.
>
> What goes wrong on the mount side is that when it hesitates between
> iso9660 and udf it decides for udf when seeing "NSR02".
> Maybe the heuristics in mount should be tuned.
Yes, this seems like a mount problem but you should contact mount
maintainer for that... I guess hardly anyone will help you with this on
this list.
> On the other hand, this filesystem announces itself as UDF
> ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> perhaps the kernel code should be more robust.
>
> If anybody feels responsible for mount and/or this kernel area
> we might discuss.
I'm kind of taking care about UDF in kernel. What do you find
inappropriate on the kernel reaction? You mean we should produce some
better error message into the log?
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Hi,
On Tue, 18 Sep 2007, Jan Kara wrote:
>
> > Today I got a CD. MacOS does not mount it and Linux does not
> > mount it without an explicit filesystemtype option.
> > That is,
> > # mount /dev/hdc /dir -t iso9660
> > works fine, but
> > # mount /dev/hdc /dir
> > mount: you didn't specify a filesystem type for /dev/hdc
> > I will try type udf
> > mount: wrong fs type, bad option, bad superblock on /dev/hdc,
> > missing codepage or other error
> > In some cases useful info is found in syslog - try
> > dmesg | tail or so
> > # dmesg | tail
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
> > udf: udf_read_inode(ino 547) failed !bh
> > UDF-fs: Error in udf_iget, block=1, partition=1
That comes from udf_fill_super() but which shouldn't have been called
in the first place ...
> > Google gave me half a dozen other people that mentioned the same
> > problem (with the same inode 547). Clearly some CD mastering software
> > produces a format that Linux and MacOS do not handle easily.
> >
> > One result of this letter will be that people with the same problem
> > learn via Google that using the "-t iso9660" option may help.
> >
> > What goes wrong on the mount side is that when it hesitates between
> > iso9660 and udf it decides for udf when seeing "NSR02".
> > Maybe the heuristics in mount should be tuned.
> Yes, this seems like a mount problem but you should contact mount
> maintainer for that... I guess hardly anyone will help you with this on
> this list.
>
> > On the other hand, this filesystem announces itself as UDF
> > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> > perhaps the kernel code should be more robust.
Could you send the complete dmesg log, and what you mean with filesystem/
kernel (incorrectly?) announcing it as UDF here ... I agree with Jan,
this sounds like an issue with mount(8) to me.
> > If anybody feels responsible for mount and/or this kernel area
> > we might discuss.
> I'm kind of taking care about UDF in kernel. What do you find
> inappropriate on the kernel reaction? You mean we should produce some
> better error message into the log?
On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
> > > On the other hand, this filesystem announces itself as UDF
> > > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> > > perhaps the kernel code should be more robust.
>
> Could you send the complete dmesg log, and what you mean with filesystem/
> kernel (incorrectly?) announcing it as UDF here ... I agree with Jan,
> this sounds like an issue with mount(8) to me.
You already got the relevant part of the dmesg log. Slightly more below.
I think the filesystem can be treated both as iso9660 and as udf,
at least that is what I seem to recall CD-BRIDGE means. Thus,
if the kernel cannot mount it as udf, I think it is a kernel flaw.
Given that kernel flaw, and the fact that mounting as iso9660 works,
mount(8) could work around the kernel problem by guessing iso9660.
But maybe we should first try to fix the kernel.
Andries
Failed mount:
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
udf: udf_read_inode(ino 547) failed !bh
UDF-fs: Error in udf_iget, block=1, partition=1
Success:
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
Hi Andries,
On Wed, 19 Sep 2007, Andries E. Brouwer wrote:
>
> On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
>
> > > > On the other hand, this filesystem announces itself as UDF
> > > > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> > > > perhaps the kernel code should be more robust.
> >
> > Could you send the complete dmesg log, and what you mean with filesystem/
> > kernel (incorrectly?) announcing it as UDF here ... I agree with Jan,
> > this sounds like an issue with mount(8) to me.
>
> You already got the relevant part of the dmesg log. Slightly more below.
> Failed mount:
> UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
> udf: udf_read_inode(ino 547) failed !bh
> UDF-fs: Error in udf_iget, block=1, partition=1
Ok, like said, this comes from udf_fill_super(), but which shouldn't
have been called for this CD in the first place -- i.e. mount(8) shouldn't
have tried to mount a non-UDF filesystem as UDF (unless explicitly asked
as such). I was actually asking for the logs explaining why you thought
the _kernel_ incorrectly "announced" it as an UDF filesystem.
Hmm ... those "CD-RTOS", "CD-BRIDGE" and "CDUDF File System - Adaptec Inc"
bits are not dmesg output, are they? Looks like "hwinfo --cdrom" or
"isoinfo" or some such.
> I think the filesystem can be treated both as iso9660 and as udf,
> at least that is what I seem to recall CD-BRIDGE means. Thus,
> if the kernel cannot mount it as udf, I think it is a kernel flaw.
> Given that kernel flaw, and the fact that mounting as iso9660 works,
> mount(8) could work around the kernel problem by guessing iso9660.
> But maybe we should first try to fix the kernel.
I don't think that is what CD-BRIDGE means -- so no kernel flaw :-)
What happened here is simply that in the absence of a "-t" option,
mount(8) defaulted (probably due to incorrect heuristics?) to UDF for
some reason, thereby obviously failing. I don't know who maintains
mount(8) / util-linux package, or do distributions have their own
maintainers these days (?)
Satyam
On Wed, 19 Sep 2007 08:05:32 +0530 (IST) Satyam Sharma wrote:
> Hi Andries,
>
>
> On Wed, 19 Sep 2007, Andries E. Brouwer wrote:
> >
> > On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
> >
> > > > > On the other hand, this filesystem announces itself as UDF
> > > > > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> > > > > perhaps the kernel code should be more robust.
> > >
> > > Could you send the complete dmesg log, and what you mean with filesystem/
> > > kernel (incorrectly?) announcing it as UDF here ... I agree with Jan,
> > > this sounds like an issue with mount(8) to me.
> >
> > You already got the relevant part of the dmesg log. Slightly more below.
>
> > Failed mount:
> > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
> > udf: udf_read_inode(ino 547) failed !bh
> > UDF-fs: Error in udf_iget, block=1, partition=1
>
> Ok, like said, this comes from udf_fill_super(), but which shouldn't
> have been called for this CD in the first place -- i.e. mount(8) shouldn't
> have tried to mount a non-UDF filesystem as UDF (unless explicitly asked
> as such). I was actually asking for the logs explaining why you thought
> the _kernel_ incorrectly "announced" it as an UDF filesystem.
>
> Hmm ... those "CD-RTOS", "CD-BRIDGE" and "CDUDF File System - Adaptec Inc"
> bits are not dmesg output, are they? Looks like "hwinfo --cdrom" or
> "isoinfo" or some such.
>
> > I think the filesystem can be treated both as iso9660 and as udf,
> > at least that is what I seem to recall CD-BRIDGE means. Thus,
> > if the kernel cannot mount it as udf, I think it is a kernel flaw.
> > Given that kernel flaw, and the fact that mounting as iso9660 works,
> > mount(8) could work around the kernel problem by guessing iso9660.
> > But maybe we should first try to fix the kernel.
>
> I don't think that is what CD-BRIDGE means -- so no kernel flaw :-)
> What happened here is simply that in the absence of a "-t" option,
> mount(8) defaulted (probably due to incorrect heuristics?) to UDF for
> some reason, thereby obviously failing. I don't know who maintains
> mount(8) / util-linux package, or do distributions have their own
> maintainers these days (?)
Hi,
Adrian took over util-linux, but hasn't made any releases lately,
so one of the RHAT developers is maintaining util-linux-ng:
http://userweb.kernel.org/~kzak/util-linux-ng/
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Wed, Sep 19, 2007 at 08:05:32AM +0530, Satyam Sharma wrote:
> I was actually asking for the logs explaining why you thought
> the _kernel_ incorrectly "announced" it as an UDF filesystem.
No, the CDROM announces itself as an UDF filesystem.
> Hmm ... those "CD-RTOS", "CD-BRIDGE" and "CDUDF File System - Adaptec Inc"
> bits are not dmesg output, are they?
No, hexdump of the CDROM.
Andries
Satyam Sharma <[email protected]> writes:
> What happened here is simply that in the absence of a "-t" option,
> mount(8) defaulted (probably due to incorrect heuristics?) to UDF for
> some reason, thereby obviously failing.
I think the CD contains both ISO-9660 and UDF filesystems, but the
latter is just faulty.
The disc would need to be analyzed.
--
Krzysztof Halasa
On 9/19/07, Andries E. Brouwer <[email protected]> wrote:
> On Wed, Sep 19, 2007 at 08:05:32AM +0530, Satyam Sharma wrote:
>
> > I was actually asking for the logs explaining why you thought
> > the _kernel_ incorrectly "announced" it as an UDF filesystem.
>
> No, the CDROM announces itself as an UDF filesystem.
>
> > Hmm ... those "CD-RTOS", "CD-BRIDGE" and "CDUDF File System - Adaptec Inc"
> > bits are not dmesg output, are they?
>
> No, hexdump of the CDROM.
Care to provide:
/lib/udev/vol_id /dev/...
and:
blkid /dev/...
Or "dd" the start of the disk to a file, and send it to me, if there
is nothing confidential on it.
Thanks,
Kay
On Sat, Sep 15, 2007 at 11:49:31PM +0200, Andries E. Brouwer wrote:
> What goes wrong on the mount side is that when it hesitates between
> iso9660 and udf it decides for udf when seeing "NSR02".
> Maybe the heuristics in mount should be tuned.
I'd like to see the CD image (or at least first 2Mb). Also try:
# blkid -c /dev/null /dev/cdrom
# /lib/udev/vol_id /dev/cdrom
Maybe vol_id provides better information -- the udf/iso code in
libblkid seems poorer that in libvolume_id.
> If anybody feels responsible for mount and/or this kernel area
> we might discuss.
mount(8) --> [email protected]
Karel
--
Karel Zak <[email protected]>
On Wed, Sep 19, 2007 at 03:23:27PM +0200, Karel Zak wrote:
> On Sat, Sep 15, 2007 at 11:49:31PM +0200, Andries E. Brouwer wrote:
> > What goes wrong on the mount side is that when it hesitates between
> > iso9660 and udf it decides for udf when seeing "NSR02".
> > Maybe the heuristics in mount should be tuned.
>
> Also try:
> # blkid -c /dev/null /dev/cdrom
# blkid -c /dev/null /dev/hdc
/dev/hdc: TYPE="udf"
> # /lib/udev/vol_id /dev/cdrom
# /sbin/vol_id /dev/hdc
ID_FS_USAGE=filesystem
ID_FS_TYPE=udf
ID_FS_VERSION=
ID_FS_UUID=
ID_FS_LABEL=Wisk1956-82
ID_FS_LABEL_SAFE=Wisk1956-82
> Maybe vol_id provides better information -- the udf/iso code in
> libblkid seems poorer that in libvolume_id.
I think the blkid code started out as a copy of the code in mount(8),
but since then they may have developed independently.
Anyway, mount, blkid, vol_id all think that they see udf.
But the kernel cannot handle this type of udf.
> I'd like to see the CD image (or at least first 2Mb).
Ha, I hoped that someone would say that.
(But do you still want it if I say that it is mostly
a kernel problem?)
By the way, unfortunately a CD image does not work quite the same
as the real thing.
In udf/lowlevel.c you can read
unsigned int
udf_get_last_session(struct super_block *sb) {
...
i = ioctl_by_bdev(bdev, CDROMMULTISESSION, ...
and this ioctl will succeed on a CDROM, but fail on a loop device. Ach.
Now what goes wrong? In udf/inode.c/udf_current_aext there is support
for allocation types ICBTAG_FLAG_AD_SHORT (0) and ICBTAG_FLAG_AD_LONG (1)
and for no other types. However, ECMA 167 writes (in 14.6.8):
0-2 Shall be interpreted as a 3-bit unsigned binary number as follows.
The value 0 shall mean that Short Allocation Descriptors are used.
The value 1 shall mean that Long Allocation Descriptors are used.
The value 2 shall mean that Extended Allocation Descriptors are used.
The value 3 shall mean that the file shall be treated as though
it had exactly one allocation descriptor describing an extent
which starts with the first byte of the Allocation Descriptors field
and has a length, in bytes, recorded in the Length of Allocation
Descriptors field.
The values of 4-7 are reserved for future standardisation.
and this particular CD-ROM uses type 3.
So, I guess udf_current_aext() must be updated a bit.
Andries
[will send you a bzip2'd copy of the start of the CD-ROM separately]
> Karel Zak <[email protected]>
Andries E. Brouwer wrote:
> Today I got a CD. MacOS does not mount it and Linux does not
> mount it without an explicit filesystemtype option.
> That is,
> # mount /dev/hdc /dir -t iso9660
> works fine, but
> # mount /dev/hdc /dir
> mount: you didn't specify a filesystem type for /dev/hdc
> I will try type udf
> mount: wrong fs type, bad option, bad superblock on /dev/hdc,
> missing codepage or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
> # dmesg | tail
> UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
> udf: udf_read_inode(ino 547) failed !bh
> UDF-fs: Error in udf_iget, block=1, partition=1
What does the line for hdc show in /etc/fstab? Mount tries whichever
filesystem(s) is/are listed there if you omit -t. My guess is that it
only lists udf and this is a cd so it contains iso9660, not udf.