Re: iso9660 vs udf
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 vs udf
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 *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
