* Can not read UDF CD
@ 2004-07-29 8:48 David Balazic
2004-07-29 14:44 ` Pat LaVarre
0 siblings, 1 reply; 17+ messages in thread
From: David Balazic @ 2004-07-29 8:48 UTC (permalink / raw)
To: 'linux_udf@hpesjro.fc.hp.com'
Cc: 'linux-kernel@vger.kernel.org'
Hi!
I created a multisession UDF CD under windows with Ahead Nero 6.x ( two
sessions )
and it does not mount under linux 2.6.8-rc1.
Here are the messages :
UDF-fs DEBUG fs/udf/lowlevel.c:57:udf_get_last_session: XA disk: yes,
vol_desc_start=30622
UDF-fs DEBUG fs/udf/super.c:1552:udf_fill_super: Multi-session=30622
UDF-fs DEBUG fs/udf/super.c:540:udf_vrs: Starting at sector 30638 (2048 byte
sectors)
UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block
30878, tag 30878 != 256
UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor block found
UDF-fs: No partition found (1)
The CD works in windows 2000 pro and Windows 2003 ( has Nero UDF fs
installed ).
Ideas ?
Regards,
David Balažic
----------------------------------------------------------------------------
-----------
http://noepatents.org/ Innovation, not litigation !
---
David Balazic mailto:david.balazic@hermes.si
HERMES Softlab http://www.hermes-softlab.com
Zagrebska cesta 104 Phone: +386 2 450 8851
SI-2000 Maribor
Slovenija
----------------------------------------------------------------------------
-----------
"Be excellent to each other." -
Bill S. Preston, Esq. & "Ted" Theodore Logan
----------------------------------------------------------------------------
-----------
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can not read UDF CD
2004-07-29 8:48 David Balazic
@ 2004-07-29 14:44 ` Pat LaVarre
0 siblings, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-07-29 14:44 UTC (permalink / raw)
To: David Balazic
Cc: 'linux_udf@hpesjro.fc.hp.com',
'linux-kernel@vger.kernel.org'
David B:
/// In short,
I suggest quickly trying the mount -o lastblock= and anchor= udf.ko
options described at:
http://lxr.linux.no/source/Documentation/filesystems/udf.txt?v=2.6.5
else working thru til able to try the phgfsck described at my page:
http://udfko.blog-city.com/read/577369.htm
If you do post the phgfsck report on the web, I'll gladly link to it.
/// At length, in Seven parts ...
/// 1) Similarly
> UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block 30878, tag 30878 != 256
> UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor block found
> UDF-fs: No partition found (1)
In the merely private archives of linux_udf, just this week we see me
suffering thru something highly similar, specifically:
kernel: UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block 256, tag 0 != 256
kernel: UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor block found
kernel: UDF-fs: No partition found (1)
Note, since 2.6.7, by default these messages will grow more cryptic, we will see only:
kernel: UDF-fs: No partition found (1)
> > > UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block 30878, tag 30878 != 256
> > UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block 256, tag 0 != 256
I'm guessing these messages mean the try to mount halted over garbage
found at LBA x100 (256), but Ben wrote this code, not me.
/// 2) Where
What kind of cable do you use, what is your device name, what is your
mount point?
Til I know, I will cover both USB and PATAPI and pretend you want to
mount /dev/scd0 at /mnt/scd0.
/// 3) -o lastblock="$n"
Up in user land, my workaround was:
n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
sudo mount -r -o lastblock="$n" /dev/scd0 /mnt/scd0
/// 4) patch -p1 ...
To recover the feature:
sudo mount -r /dev/scd0 /mnt/scd0
for such unfriendly discs, I web-published the patch quoted below to the
patches-udf.lastblock package of http://iomrrdtools.sourceforge.net/
/// 5) -o anchor=...
If -o lastblock="$n" doesn't work for you, then one more blind try is -o
anchor="$n" i.e.
n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
Please note -o anchor is arguably reckless except when combined with -r.
/// 6) phgfsck
If neither blind try works for you, then to make sense of the disc you
can try phgfsck. For example, here, I see:
$ sudo phgfsck -scsi /dev/sg0 | grep 'AVDPs at'
Number of AVDPs: 2, AVDPs at N-256, N
$
Seeing "AVDP ... at ... N" tells me to try what I mentioned above:
n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
/// 7) reconfiguring Linux to permit phgfsck
http://www.extra.research.philips.com/udf/
is the Philips page that offers the phgfsck, aka the "Philips UDF
Verifier".
My clarification of that page is:
http://udfko.blog-city.com/read/577369.htm
Philips deserves nothing but kudos for donating the phgfsck to improve
UDF interoperability worldwide ... except the fact remains they haven't
chosen to release their copyright under a license approved as open
source by such authorities as sourceforge.net.
Consequently, the phgfsck can be unusually hard to use in Linux.
Specifically, it does Not incorporate any of the better SCSI pass thru
libraries. Privately, as yet I've heard from Two employees of different
corporations who privately requested and privately were denied
permission to donate code into the phgfsck, because its source is partly
closed.
First, as yet with the phgfsck, you have to substitute an sg name for
the regular dev name, even when running 2.6.
To discover your sg name, you can try each of /dev/sg* to see what
happens, or you can download yet another tool, such as sg_scan -i or my
own plscsi -w, found at http://members.aol.com/plscsi/linux/
In theory `phgfsck -showscsi` will give you device names, but for me
that query doesn't work reliably. Trying here just now in
2.6.8-rc2-bk7, it hangs. In the past, I've seen it miss names.
Often you need root privilege to discover the sg name.
You will probably have an sg name to find only if your kernel has a
drivers/scsi/sg.ko and your device name was among the /dev/scd*
Else you might have to get into substituting ide-scsi.ko for ide-cd.ko,
especially if your device name was among the /dev/hd*. linux-scsi
speaks occasionally of the issues such substitutions raise.
Pat LaVarre
http://iomrrdtools.sourceforge.net/
http://udfko.blog-city.com/
--- From: http://sourceforge.net/project/showfiles.php?group_id=101444&package_id=125426
See also: Readme.txt
... Copyright (c) 2004 Iomega Corp
... free software ...
... GNU General Public License as ... either ... or ...
...
diff -urp linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c
--- linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c 2004-06-15 23:19:36.000000000 -0600
+++ linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c 2004-07-28 14:46:02.373806296 -0600
@@ -73,9 +73,9 @@ udf_get_last_block(struct super_block *s
struct block_device *bdev = sb->s_bdev;
unsigned long lblock = 0;
- if (ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long) &lblock))
- lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
-
+ if (!ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long) &lblock))
+ return lblock;
+ lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
if (lblock)
return lblock - 1;
else
diff -urp linux-2.6.8-rc2-bk7/fs/udf/super.c linux-2.6.8-rc2-bk7-pel/fs/udf/super.c
--- linux-2.6.8-rc2-bk7/fs/udf/super.c 2004-07-28 10:36:35.928051888 -0600
+++ linux-2.6.8-rc2-bk7-pel/fs/udf/super.c 2004-07-28 14:45:45.356393336 -0600
@@ -1562,6 +1562,9 @@ static int udf_fill_super(struct super_b
goto error_out;
}
+ if (!UDF_SB_LASTBLOCK(sb)) {
+ UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
+ }
udf_find_anchor(sb);
/* Fill in the rest of the superblock */
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-07-29 15:32 David Balazic
2004-07-29 16:23 ` David Burg
0 siblings, 1 reply; 17+ messages in thread
From: David Balazic @ 2004-07-29 15:32 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'
Cc: 'linux_udf@hpesjro.fc.hp.com',
'linux-kernel@vger.kernel.org'
[-- Attachment #1: Type: text/plain, Size: 5560 bytes --]
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
>
> David B:
>
> /// In short,
>
> I suggest quickly trying the mount -o lastblock= and anchor= udf.ko
> options described at:
>
> http://lxr.linux.no/source/Documentation/filesystems/udf.txt?v=2.6.5
>
> else working thru til able to try the phgfsck described at my page:
>
> http://udfko.blog-city.com/read/577369.htm
>
> If you do post the phgfsck report on the web, I'll gladly link to it.
>
I attach the "udf_test -scsi 1:0" output.
> /// At length, in Seven parts ...
>
> /// 1) Similarly
snip
> /// 2) Where
>
> What kind of cable do you use, what is your device name, what is your
> mount point?
>
cable is 80 wire ATA-66
dev is /dev/cdrom2 -> /dev/hdc
/mnt/cdrom2
> Til I know, I will cover both USB and PATAPI and pretend you want to
> mount /dev/scd0 at /mnt/scd0.
>
> /// 3) -o lastblock="$n"
>
> Up in user land, my workaround was:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
> sudo mount -r -o lastblock="$n" /dev/scd0 /mnt/scd0
>
Will try...
> /// 4) patch -p1 ...
>
> To recover the feature:
>
> sudo mount -r /dev/scd0 /mnt/scd0
>
> for such unfriendly discs, I web-published the patch quoted below to the
> patches-udf.lastblock package of http://iomrrdtools.sourceforge.net/
Wil try ...
> /// 5) -o anchor=...
>
> If -o lastblock="$n" doesn't work for you, then one more blind try is -o
> anchor="$n" i.e.
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
> sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> Please note -o anchor is arguably reckless except when combined with -r.
>
> /// 6) phgfsck
>
> If neither blind try works for you, then to make sense of the disc you
> can try phgfsck. For example, here, I see:
>
> $ sudo phgfsck -scsi /dev/sg0 | grep 'AVDPs at'
> Number of AVDPs: 2, AVDPs at N-256, N
> $
>
> Seeing "AVDP ... at ... N" tells me to try what I mentioned above:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
> sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> /// 7) reconfiguring Linux to permit phgfsck
>
> http://www.extra.research.philips.com/udf/
> is the Philips page that offers the phgfsck, aka the "Philips UDF
> Verifier".
>
> My clarification of that page is:
>
> http://udfko.blog-city.com/read/577369.htm
>
> Philips deserves nothing but kudos for donating the phgfsck to improve
> UDF interoperability worldwide ... except the fact remains they haven't
> chosen to release their copyright under a license approved as open
> source by such authorities as sourceforge.net.
>
> Consequently, the phgfsck can be unusually hard to use in Linux.
> Specifically, it does Not incorporate any of the better SCSI pass thru
> libraries. Privately, as yet I've heard from Two employees of different
> corporations who privately requested and privately were denied
> permission to donate code into the phgfsck, because its source is partly
> closed.
>
> First, as yet with the phgfsck, you have to substitute an sg name for
> the regular dev name, even when running 2.6.
>
> To discover your sg name, you can try each of /dev/sg* to see what
> happens, or you can download yet another tool, such as sg_scan -i or my
> own plscsi -w, found at http://members.aol.com/plscsi/linux/
>
> In theory `phgfsck -showscsi` will give you device names, but for me
> that query doesn't work reliably. Trying here just now in
> 2.6.8-rc2-bk7, it hangs. In the past, I've seen it miss names.
>
> Often you need root privilege to discover the sg name.
>
> You will probably have an sg name to find only if your kernel has a
> drivers/scsi/sg.ko and your device name was among the /dev/scd*
>
> Else you might have to get into substituting ide-scsi.ko for ide-cd.ko,
> especially if your device name was among the /dev/hd*. linux-scsi
> speaks occasionally of the issues such substitutions raise.
>
> Pat LaVarre
> http://iomrrdtools.sourceforge.net/
> http://udfko.blog-city.com/
>
> --- From:
> http://sourceforge.net/project/showfiles.php?group_id=101444&package_id=12
> 5426
>
> See also: Readme.txt
> ... Copyright (c) 2004 Iomega Corp
> ... free software ...
> ... GNU General Public License as ... either ... or ...
> ...
>
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c
> --- linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c 2004-06-15
> 23:19:36.000000000 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c 2004-07-28
> 14:46:02.373806296 -0600
> @@ -73,9 +73,9 @@ udf_get_last_block(struct super_block *s
> struct block_device *bdev = sb->s_bdev;
> unsigned long lblock = 0;
>
> - if (ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> - lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> -
> + if (!ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> + return lblock;
> + lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> if (lblock)
> return lblock - 1;
> else
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/super.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/super.c
> --- linux-2.6.8-rc2-bk7/fs/udf/super.c 2004-07-28
> 10:36:35.928051888 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/super.c 2004-07-28
> 14:45:45.356393336 -0600
> @@ -1562,6 +1562,9 @@ static int udf_fill_super(struct super_b
> goto error_out;
> }
>
> + if (!UDF_SB_LASTBLOCK(sb)) {
> + UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
> + }
> udf_find_anchor(sb);
>
> /* Fill in the rest of the superblock */
>
> <<report_1_stein.txt>>
[-- Attachment #2: report_1_stein.txt --]
[-- Type: text/plain, Size: 14042 bytes --]
UDF Conformance Testing Application
(c) Koninklijke Philips Electronics N.V. 1999-2004
Application version: 1.1r0
UCT Core version : 1.1r0
Command:
udf_test
Generic options parsing:
Medium info options parsing:
Device options parsing:
-scsi 1:0
host adapter: 1
SCSI Id. : 0
INQUIRY command:
Vendor identification : TEAC
Product identification: CD-540E
Product revision level: 3.0A
INQUIRY/ANSI Version : 0
Version Descriptors : 0x2E00 0x3100 0x7200 0x3000 0x5C00 0x6200 0x6900 0x6E00
Peripheral Device Type: CD/DVD Device
TEST UNIT READY command:
Device ready
READ CAPACITY command:
Highest valid block number in last complete session: 60071
Block Size : 2048
GET CONFIGURATION command: ..
fails
MODE SENSE command:
Medium Type: 36 (= 0x24) - overwritable
READ DISC INFORMATION command: .....
fails, skip read track info
Created SCSI device
host adapter id : 1
scsi id : 0
last valid block : 60071
block size : 2048
packet length : 0
nmb of sessions : 1
verify session : 1
session starts : 0
medium WR type : overwritable
medium SE type : unknown
=> ignore device medium WR type: overwritable
Inspect 1 block for presence of VAT or AVDP
starting at block: 60071
==> read cache: max 16 buffers of 64 sectors, total 2048 Kb
err: .
60071 1 error block read
Inspect 456 blocks for presence of VAT or AVDP
starting at block: 59615
59615 455 ok blocks read
59815 AVDP (255 times at 59815 thru 60069)
err: .
60070 1 error block read
last AVDP at 60069 (N-2), AVDP at 59815 (N-256)
Verification start medium info
last valid block : 60071
block size : 2048
packet length : 0
nmb of sessions : 1
verify session : 1
session starts : 0
medium WR type : unknown
medium SE type : unknown
====> Start verification
Start time : 2004-07-29 17:26:54 +02:00 (east of UTC)
Verbose level: 100
Message limit: 20
Fake read enabled
Read cache enabled
Initial UDF Revision range: 1.02 thru 2.50
====> Volume Structure verification
Read Volume Recognition Sequence
16 read block
BEA01
Start of Extended Area
17 read block
NSR02
18 read block
TEA01
19 read block
End of Extended Area
End of Volume Recognition Sequence
==> Changed UDF Revision range from: 1.02 thru 2.50 to: 1.02 thru 1.50
- because of "NSR descriptor"
Reading Volume Information
256 read block
AVDP at 256
First Tag Serial Number: 1
59815 read block
AVDP at N-256
AVDP error: Volume Descriptor Sequence Extent not equal to
- the one read in first AVDP
- Main: length,location: 32768, 30654 expected: 32768, 32
- Reserve: length,location: 32768, 30670 expected: 32768, 48
- Using first AVDP
60071 read block
60071 Note: READ ERROR
No AVDP at N
Number of AVDPs: 2, AVDPs at 256, N-256
====> Read Main VDS extent: 32, length: 32768
32 read block
PVD VDS Number: 0
PVD Recording Time: 2004-07-27 17:14:49 +01:00
PVD Volume Identifier : "VNC"
PVD Volume Set Identifier: "41067169"
==> PVD 344 New Entity Identifier (regid):
Application Entity Identifier
<empty>
==> PVD 388 New Entity Identifier (regid):
Implementation Entity Identifier
Identifier : "*AHEAD Nero"
OS Class : #00 Undefined
OS Identifier : #00 Undefined
Implementation Use : #05 #00 #00 #00 #00 #00
==> Add PVD to VDS info
33 read block
IUVD VDS Number: 1
IUVD EntityID Identifier: "*UDF LV Info"
==> IUVD 20 New Entity Identifier (regid):
UDF Entity Identifier
Identifier : "*UDF LV Info"
UDF revision : 1.02
==> Changed UDF Revision range from: 1.02 thru 1.50 to: 1.02 only
- because of "UDF EntityID UDF revision"
OS Class : #05 Windows 9x
OS Identifier : #00 Windows 9x - Generic
Warning: OS Class Windows 9x was introduced in UDF 1.50
- Current UDF revision range: 1.02 only
UDF IUVD Logical Volume Identifier : "VNC"
UDF IUVD LVInfo1: <undefined>
UDF IUVD LVInfo2: <undefined>
UDF IUVD LVInfo3: <undefined>
==> Add IUVD to VDS info
34 read block
PD VDS Number: 2, Partition Number: 0
==> PD 24 New Entity Identifier (regid):
Application Entity Identifier
Identifier : "+NSR02"
PD: No Unallocated/Freed Space Set in Partition Header Descriptor
==> PD 196 New Entity Identifier (regid):
Implementation Entity Identifier
Identifier : "*AHEAD Nero"
OS Class : #05 Windows 9x
OS Identifier : #00 Windows 9x - Generic
Warning: OS Class Windows 9x was introduced in UDF 1.50
- Current UDF revision range: 1.02 only
==> Add PD to VDS info, partition number: 0
35 read block
LVD VDS Number: 3
LVD Logical Volume Identifier: "VNC"
==> LVD 216 New Entity Identifier (regid):
Domain Entity Identifier
Identifier : "*OSTA UDF Compliant"
UDF revision : 1.02
Domain flags : #03 Hard and Soft Write-Protect
==> Add LVD to VDS info
36 read block
USD VDS Number: 4, nmb of ADs: 0
==> Add USD to VDS info
37 read block
TD
====> Read Reserve VDS extent: 48, length: 32768
48 read block
PVD VDS Number: 0
PVD Recording Time: 2004-07-27 17:14:49 +01:00
PVD Volume Identifier : "VNC"
PVD Volume Set Identifier: "41067169"
==> Add PVD to VDS info
49 read block
IUVD VDS Number: 1
IUVD EntityID Identifier: "*UDF LV Info"
UDF IUVD Logical Volume Identifier : "VNC"
UDF IUVD LVInfo1: <undefined>
UDF IUVD LVInfo2: <undefined>
UDF IUVD LVInfo3: <undefined>
==> Add IUVD to VDS info
50 read block
PD VDS Number: 2, Partition Number: 0
PD: No Unallocated/Freed Space Set in Partition Header Descriptor
==> Add PD to VDS info, partition number: 0
51 read block
LVD VDS Number: 3
LVD Logical Volume Identifier: "VNC"
==> Add LVD to VDS info
52 read block
USD VDS Number: 4, nmb of ADs: 0
==> Add USD to VDS info
53 read block
TD
====> Check equivalence of Main VDS and Reserve VDS
==> Main and Reserve VDS are equivalent
====> Check Main VDS. Summary:
PVD VDS Number 0
LVD VDS Number 3
USD VDS Number 4
PD VDS Number 2
IUVD VDS Number 1 ID: "*UDF LV Info"
5 prevailing VDS descriptors found
==> Using Main VDS
====> Checking Logical Volume: "VNC"
Prevailing Partition Descriptors:
pNmb: 0, start: 257, length: 18708, access: read-only
LVD Partition Maps:
p0: Physical Partition Map (Type 1), pNmb: 0
==> Changed medium WR type from unknown to read-only
- because of partition access type
==> Changed medium SE type from unknown to nonsequential
- because of no Virtual Partition found
Mounted Partitions:
- p0: Physical, pNmb: 0, blocks: 257 thru 18964, access: read-only
- logical blocks: 0 thru 18707
Read LVID sequence extent: 64, length: 4096
64 read block
LVID - Close
LVID Recording Time: 2004-07-27 17:14:49 +01:00
65 read block
TD
Next UniqueID: #0000000000000102,
from LVID Logical Volume Header Descriptor.
==> p0: read Unallocated or Freed Partition Space Sets
p0: No partition Space set found
--
Read FSD sequence extent: (0,p0), length: 2048
257 read block
FSD FSN: 0, FSDN: 0
FSD Logical Volume Identifier: "VNC"
FSD File Set Identifier : "VNC"
FSD Copyright File Identifier: <undefined>
FSD Abstract File Identifier : <undefined>
====> Volume identifiers summary:
PVD: Volume Identifier [32]: "VNC"
PVD: Volume Set Identifier [128]: "41067169"
LVD: Logical Volume Identifier [128]: "VNC"
IUVD: Logical Volume Identifier [128]: "VNC"
FSD: Logical Volume Identifier [128]: "VNC"
FSD: File Set Identifier [32]: "VNC"
====> File Structure verification
read Root Directory
258 read block
FE file type DIR name: <root>
cnt: extent type, size, location,part, body, total alloc
1: long_ad 0 288 2 0 288 2048
==> (max) depth: 1 1 Expand directory: <root>
Read FIDs
259 read block
Verify FIDs
FID cid: name: /<parent FID>, refers to: <root>
FID cid: 16 name: "patch-2.6.8-rc1-rc2.bz2"
FID cid: 16 name: "patch-2.6.8-rc1.bz2"
FID cid: 16 name: "linux-2.6.7.tar.bz2"
Add FIDs to directory hierarchy and read FEs
260 read block
FE file type FILE name: "patch-2.6.8-rc1-rc2.bz2"
cnt: extent type, size, location,part, body, total alloc
1: long_ad 0 543778 7 0 543778 544768
261 read block
FE file type FILE name: "patch-2.6.8-rc1.bz2"
cnt: extent type, size, location,part, body, total alloc
1: long_ad 0 2662225 273 0 2662225 2662400
262 read block
FE file type FILE name: "linux-2.6.7.tar.bz2"
cnt: extent type, size, location,part, body, total alloc
1: long_ad 0 35092228 1573 0 35092228 35092480
Directory: <root>
.d.p......:..r.x:..r.x:..r.x DIR 1 2004-07-27 16:14 288 /<parent FID>, refers to: <root>
..........:..r.x:..r.x:..r.x FILE 1 2004-07-27 10:09 543778 "patch-2.6.8-rc1-rc2.bz2"
..........:..r.x:..r.x:..r.x FILE 1 2004-07-27 10:08 2662225 "patch-2.6.8-rc1.bz2"
..........:..r.x:..r.x:..r.x FILE 1 2004-07-27 10:10 35092228 "linux-2.6.7.tar.bz2"
file body read: "patch-2.6.8-rc1-rc2.bz2"
264 fake read 266 blocks
file body read: "patch-2.6.8-rc1.bz2"
530 fake read 1300 blocks
file body read: "linux-2.6.7.tar.bz2"
1830 fake read 17135 blocks
Expand complete, max depth 1 for directory: <root>
- 3 files 0 directories
- overall total: 3 files 1 directory
Maximum directory depth: 1
End of directory tree expansion
Excluding deleted FIDs with cleared ICB
====> Testing File Link Count by cross reference of 5 paths.
File Link Count errors will be identified here by the
physical address of the File Entry as well as all
paths identifying the File Entry.
The physical address of the File Entry is also shown in
the informational read block messages above.
Note that errors found here may have been reported before
or may be caused by other previously reported errors.
====> Testing free Volume Space in USD Allocation Descriptors
No free Volume Space defined in USD
====> Build Partition Space Bitmaps.
Also check structures that overlap with partition space.
====> Partition Allocation summary :
===> Physical Partition p0: size 18708 blocks, read-only
blocks 257 thru 18964
==> Compare partition p0 calculated bitmap to recorded Space Set
No Space Set found for partition p0
====> Final LVID verification
Close LVID
==> read-only Physical Partition p0 Space summary:
Partition Length : 18708
LVID Partition Size : 18708
LVID Partition Free Space: 0
Verifier expected free space: 0
==> LVID status summary:
Last modification Time : 2004-07-27 17:14:49 +01:00 (east of UTC)
Last written Developer Id : "*AHEAD Nero"
Next UniqueID : #0000000000000102 => from LVID
max used FE UniqueID : #0000000000000016
Number of Files : 3
Number of Directories : 1
Min UDF Read Revision : UDF 1.02
Min UDF Write Revision : UDF 1.02
Max UDF Write Revision : UDF 1.02
Medium UDF Revision : UDF 1.02
====> Testing uniqueness of relevant UniqueIDs.
Test complete
Elapsed time : 00:03
====> Volume identifiers summary:
PVD: Volume Identifier [32]: "VNC"
PVD: Volume Set Identifier [128]: "41067169"
LVD: Logical Volume Identifier [128]: "VNC"
IUVD: Logical Volume Identifier [128]: "VNC"
FSD: Logical Volume Identifier [128]: "VNC"
FSD: File Set Identifier [32]: "VNC"
====> Encountered EntityID (regid) summary:
count EntityID
3 Domain Entity Identifier
Identifier : "*OSTA UDF Compliant"
UDF revision : 1.02
Domain flags : #03 Hard and Soft Write-Protect
2 UDF Entity Identifier
Identifier : "*UDF LV Info"
UDF revision : 1.02
OS Class : #05 Windows 9x
OS Identifier : #00 Windows 9x - Generic
Warning: OS Class Windows 9x was introduced in UDF 1.50
- Current UDF revision range: 1.02 only
6 Implementation Entity Identifier
Identifier : "*AHEAD Nero"
OS Class : #00 Undefined
OS Identifier : #00 Undefined
Implementation Use : #05 #00 #00 #00 #00 #00
7 Implementation Entity Identifier
Identifier : "*AHEAD Nero"
OS Class : #05 Windows 9x
OS Identifier : #00 Windows 9x - Generic
Warning: OS Class Windows 9x was introduced in UDF 1.50
- Current UDF revision range: 1.02 only
2 Application Entity Identifier
<empty>
2 Application Entity Identifier
Identifier : "+NSR02"
These EntityIDs are also shown above when read for the first time
====> Final verify status report
Final UDF Revision range: 1.02 only
File System info
last valid block : 60071
block size : 2048
packet length : 0
nmb of sessions : 1
verify session : 1
session starts : 0
medium WR type : read-only
medium SE type : nonsequential
Summed file body sizes: 38298231 bytes (36.523 Mbyte)
Error count: 1 total occurrences: 1
Warning count: 2 total occurrences: 9
Disclaimer:
- The number of errors and warnings is an indication only.
- There is no guarantee that the number of errors shown
- by the verifier is correct.
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
2004-07-29 15:32 David Balazic
@ 2004-07-29 16:23 ` David Burg
0 siblings, 0 replies; 17+ messages in thread
From: David Burg @ 2004-07-29 16:23 UTC (permalink / raw)
To: 'David Balazic', 'Pat LaVarre'; +Cc: linux_udf, linux-kernel
Hello Pat,
Could it be that Nero is to be blamed? I see in the verifier log:
AVDP at N-256
AVDP error: Volume Descriptor Sequence Extent not equal to
- the one read in first AVDP
- Main: length,location: 32768, 30654 expected: 32768, 32
- Reserve: length,location: 32768, 30670 expected: 32768, 48
Let me know if you also think the medium produced by Nero has a mistake and
our Nero UDF engineers have a bug to fix.
Best regards,
David Burg
----------------------------------------------------------------
David Burg
Software Development,
InCD Project Leader
Ahead Software AG
Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
76307 Karlsbad email: dburg@nero.com
Germany http://www.nero.com
----------------------------------------------------------------
-----Original Message-----
From: linux_udf-owner@hpesjro.ipf.fc.hp.com
[mailto:linux_udf-owner@hpesjro.ipf.fc.hp.com] On Behalf Of David Balazic
Sent: Thursday, July 29, 2004 5:33 PM
To: David Balazic; 'Pat LaVarre'
Cc: 'linux_udf@hpesjro.fc.hp.com'; 'linux-kernel@vger.kernel.org'
Subject: RE: Can not read UDF CD
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
>
> David B:
>
> /// In short,
>
> I suggest quickly trying the mount -o lastblock= and anchor= udf.ko
> options described at:
>
> http://lxr.linux.no/source/Documentation/filesystems/udf.txt?v=2.6.5
>
> else working thru til able to try the phgfsck described at my page:
>
> http://udfko.blog-city.com/read/577369.htm
>
> If you do post the phgfsck report on the web, I'll gladly link to it.
I attach the "udf_test -scsi 1:0" output.
> /// At length, in Seven parts ...
>
> /// 1) Similarly
snip
> /// 2) Where
>
> What kind of cable do you use, what is your device name, what is your
> mount point?
cable is 80 wire ATA-66
dev is /dev/cdrom2 -> /dev/hdc
/mnt/cdrom2
> Til I know, I will cover both USB and PATAPI and pretend you want to
> mount /dev/scd0 at /mnt/scd0.
>
> /// 3) -o lastblock="$n"
>
> Up in user land, my workaround was:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> p\"`" sudo mount -r -o lastblock="$n" /dev/scd0 /mnt/scd0
Will try...
> /// 4) patch -p1 ...
>
> To recover the feature:
>
> sudo mount -r /dev/scd0 /mnt/scd0
>
> for such unfriendly discs, I web-published the patch quoted below to
> the patches-udf.lastblock package of
> http://iomrrdtools.sourceforge.net/
Wil try ...
> /// 5) -o anchor=...
>
> If -o lastblock="$n" doesn't work for you, then one more blind try is
> -o anchor="$n" i.e.
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> p\"`" sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> Please note -o anchor is arguably reckless except when combined with
> -r.
>
> /// 6) phgfsck
>
> If neither blind try works for you, then to make sense of the disc
> you can try phgfsck. For example, here, I see:
>
> $ sudo phgfsck -scsi /dev/sg0 | grep 'AVDPs at'
> Number of AVDPs: 2, AVDPs at N-256, N
> $
>
> Seeing "AVDP ... at ... N" tells me to try what I mentioned above:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> p\"`" sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> /// 7) reconfiguring Linux to permit phgfsck
>
> http://www.extra.research.philips.com/udf/
> is the Philips page that offers the phgfsck, aka the "Philips UDF
> Verifier".
>
> My clarification of that page is:
>
> http://udfko.blog-city.com/read/577369.htm
>
> Philips deserves nothing but kudos for donating the phgfsck to
> improve UDF interoperability worldwide ... except the fact remains
> they haven't chosen to release their copyright under a license
> approved as open source by such authorities as sourceforge.net.
>
> Consequently, the phgfsck can be unusually hard to use in Linux.
> Specifically, it does Not incorporate any of the better SCSI pass
> thru libraries. Privately, as yet I've heard from Two employees of
> different corporations who privately requested and privately were
> denied permission to donate code into the phgfsck, because its source
> is partly closed.
>
> First, as yet with the phgfsck, you have to substitute an sg name for
> the regular dev name, even when running 2.6.
>
> To discover your sg name, you can try each of /dev/sg* to see what
> happens, or you can download yet another tool, such as sg_scan -i or
> my own plscsi -w, found at http://members.aol.com/plscsi/linux/
>
> In theory `phgfsck -showscsi` will give you device names, but for me
> that query doesn't work reliably. Trying here just now in
> 2.6.8-rc2-bk7, it hangs. In the past, I've seen it miss names.
>
> Often you need root privilege to discover the sg name.
>
> You will probably have an sg name to find only if your kernel has a
> drivers/scsi/sg.ko and your device name was among the /dev/scd*
>
> Else you might have to get into substituting ide-scsi.ko for
> ide-cd.ko, especially if your device name was among the /dev/hd*.
> linux-scsi speaks occasionally of the issues such substitutions
> raise.
>
> Pat LaVarre
> http://iomrrdtools.sourceforge.net/
> http://udfko.blog-city.com/
>
> --- From:
> http://sourceforge.net/project/showfiles.php?group_id=101444&package_
>id=12 5426
>
> See also: Readme.txt
> ... Copyright (c) 2004 Iomega Corp
> ... free software ...
> ... GNU General Public License as ... either ... or ...
> ...
>
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c
> --- linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c 2004-06-15
> 23:19:36.000000000 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c 2004-07-28
> 14:46:02.373806296 -0600
> @@ -73,9 +73,9 @@ udf_get_last_block(struct super_block *s
> struct block_device *bdev = sb->s_bdev;
> unsigned long lblock = 0;
>
> - if (ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> - lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> -
> + if (!ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> + return lblock;
> + lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> if (lblock)
> return lblock - 1;
> else
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/super.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/super.c
> --- linux-2.6.8-rc2-bk7/fs/udf/super.c 2004-07-28
> 10:36:35.928051888 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/super.c 2004-07-28
> 14:45:45.356393336 -0600
> @@ -1562,6 +1562,9 @@ static int udf_fill_super(struct super_b
> goto error_out;
> }
>
> + if (!UDF_SB_LASTBLOCK(sb)) {
> + UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
> + }
> udf_find_anchor(sb);
>
> /* Fill in the rest of the superblock */
>
> <<report_1_stein.txt>>
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-07-29 16:32 David Balazic
2004-07-29 17:06 ` Pat LaVarre
2004-07-29 17:33 ` Ben Fennema
0 siblings, 2 replies; 17+ messages in thread
From: David Balazic @ 2004-07-29 16:32 UTC (permalink / raw)
To: 'David Balazic', 'Pat LaVarre',
'David Burg'
Cc: linux_udf, linux-kernel
Just ask if you need any more info.
I will try to see if the problem is reproducable with burning
more UDF CDs... ( I guess the UDF part of Nero is not
as widely used as ISO9660 )
Regards,
David
> ----------
> From: David Burg[SMTP:dburg@nero.com]
> Sent: 29. julij 2004 18:23
> To: 'David Balazic'; 'Pat LaVarre'
> Cc: linux_udf@hpesjro.fc.hp.com; linux-kernel@vger.kernel.org
> Subject: RE: Can not read UDF CD
>
> Hello Pat,
>
> Could it be that Nero is to be blamed? I see in the verifier log:
>
> AVDP at N-256
> AVDP error: Volume Descriptor Sequence Extent not equal to
> - the one read in first AVDP
> - Main: length,location: 32768, 30654 expected: 32768, 32
> - Reserve: length,location: 32768, 30670 expected: 32768, 48
>
> Let me know if you also think the medium produced by Nero has a mistake
> and
> our Nero UDF engineers have a bug to fix.
>
> Best regards,
>
> David Burg
>
> ----------------------------------------------------------------
> David Burg
> Software Development,
> InCD Project Leader
>
> Ahead Software AG
> Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
> 76307 Karlsbad email: dburg@nero.com
> Germany http://www.nero.com
> ----------------------------------------------------------------
>
>
>
> -----Original Message-----
> From: linux_udf-owner@hpesjro.ipf.fc.hp.com
> [mailto:linux_udf-owner@hpesjro.ipf.fc.hp.com] On Behalf Of David Balazic
> Sent: Thursday, July 29, 2004 5:33 PM
> To: David Balazic; 'Pat LaVarre'
> Cc: 'linux_udf@hpesjro.fc.hp.com'; 'linux-kernel@vger.kernel.org'
> Subject: RE: Can not read UDF CD
>
>
> > From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> >
> > David B:
> >
> > /// In short,
> >
> > I suggest quickly trying the mount -o lastblock= and anchor= udf.ko
> > options described at:
> >
> > http://lxr.linux.no/source/Documentation/filesystems/udf.txt?v=2.6.5
> >
> > else working thru til able to try the phgfsck described at my page:
> >
> > http://udfko.blog-city.com/read/577369.htm
> >
> > If you do post the phgfsck report on the web, I'll gladly link to it.
>
> I attach the "udf_test -scsi 1:0" output.
>
> > /// At length, in Seven parts ...
> >
> > /// 1) Similarly
>
> snip
>
> > /// 2) Where
> >
> > What kind of cable do you use, what is your device name, what is your
> > mount point?
>
> cable is 80 wire ATA-66
> dev is /dev/cdrom2 -> /dev/hdc
> /mnt/cdrom2
>
> > Til I know, I will cover both USB and PATAPI and pretend you want to
> > mount /dev/scd0 at /mnt/scd0.
> >
> > /// 3) -o lastblock="$n"
> >
> > Up in user land, my workaround was:
> >
> > n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> > p\"`" sudo mount -r -o lastblock="$n" /dev/scd0 /mnt/scd0
>
> Will try...
>
> > /// 4) patch -p1 ...
> >
> > To recover the feature:
> >
> > sudo mount -r /dev/scd0 /mnt/scd0
> >
> > for such unfriendly discs, I web-published the patch quoted below to
> > the patches-udf.lastblock package of
> > http://iomrrdtools.sourceforge.net/
>
> Wil try ...
>
> > /// 5) -o anchor=...
> >
> > If -o lastblock="$n" doesn't work for you, then one more blind try is
> > -o anchor="$n" i.e.
> >
> > n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> > p\"`" sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
> >
> > Please note -o anchor is arguably reckless except when combined with
> > -r.
> >
> > /// 6) phgfsck
> >
> > If neither blind try works for you, then to make sense of the disc
> > you can try phgfsck. For example, here, I see:
> >
> > $ sudo phgfsck -scsi /dev/sg0 | grep 'AVDPs at'
> > Number of AVDPs: 2, AVDPs at N-256, N
> > $
> >
> > Seeing "AVDP ... at ... N" tells me to try what I mentioned above:
> >
> > n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> > p\"`" sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
> >
> > /// 7) reconfiguring Linux to permit phgfsck
> >
> > http://www.extra.research.philips.com/udf/
> > is the Philips page that offers the phgfsck, aka the "Philips UDF
> > Verifier".
> >
> > My clarification of that page is:
> >
> > http://udfko.blog-city.com/read/577369.htm
> >
> > Philips deserves nothing but kudos for donating the phgfsck to
> > improve UDF interoperability worldwide ... except the fact remains
> > they haven't chosen to release their copyright under a license
> > approved as open source by such authorities as sourceforge.net.
> >
> > Consequently, the phgfsck can be unusually hard to use in Linux.
> > Specifically, it does Not incorporate any of the better SCSI pass
> > thru libraries. Privately, as yet I've heard from Two employees of
> > different corporations who privately requested and privately were
> > denied permission to donate code into the phgfsck, because its source
> > is partly closed.
> >
> > First, as yet with the phgfsck, you have to substitute an sg name for
> > the regular dev name, even when running 2.6.
> >
> > To discover your sg name, you can try each of /dev/sg* to see what
> > happens, or you can download yet another tool, such as sg_scan -i or
> > my own plscsi -w, found at http://members.aol.com/plscsi/linux/
> >
> > In theory `phgfsck -showscsi` will give you device names, but for me
> > that query doesn't work reliably. Trying here just now in
> > 2.6.8-rc2-bk7, it hangs. In the past, I've seen it miss names.
> >
> > Often you need root privilege to discover the sg name.
> >
> > You will probably have an sg name to find only if your kernel has a
> > drivers/scsi/sg.ko and your device name was among the /dev/scd*
> >
> > Else you might have to get into substituting ide-scsi.ko for
> > ide-cd.ko, especially if your device name was among the /dev/hd*.
> > linux-scsi speaks occasionally of the issues such substitutions
> > raise.
> >
> > Pat LaVarre
> > http://iomrrdtools.sourceforge.net/
> > http://udfko.blog-city.com/
> >
> > --- From:
> > http://sourceforge.net/project/showfiles.php?group_id=101444&package_
> >id=12 5426
> >
> > See also: Readme.txt
> > ... Copyright (c) 2004 Iomega Corp
> > ... free software ...
> > ... GNU General Public License as ... either ... or ...
> > ...
> >
> > diff -urp linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c
> > linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c
> > --- linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c 2004-06-15
> > 23:19:36.000000000 -0600
> > +++ linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c 2004-07-28
> > 14:46:02.373806296 -0600
> > @@ -73,9 +73,9 @@ udf_get_last_block(struct super_block *s
> > struct block_device *bdev = sb->s_bdev;
> > unsigned long lblock = 0;
> >
> > - if (ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> > &lblock))
> > - lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> > -
> > + if (!ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> > &lblock))
> > + return lblock;
> > + lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> > if (lblock)
> > return lblock - 1;
> > else
> > diff -urp linux-2.6.8-rc2-bk7/fs/udf/super.c
> > linux-2.6.8-rc2-bk7-pel/fs/udf/super.c
> > --- linux-2.6.8-rc2-bk7/fs/udf/super.c 2004-07-28
> > 10:36:35.928051888 -0600
> > +++ linux-2.6.8-rc2-bk7-pel/fs/udf/super.c 2004-07-28
> > 14:45:45.356393336 -0600
> > @@ -1562,6 +1562,9 @@ static int udf_fill_super(struct super_b
> > goto error_out;
> > }
> >
> > + if (!UDF_SB_LASTBLOCK(sb)) {
> > + UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
> > + }
> > udf_find_anchor(sb);
> >
> > /* Fill in the rest of the superblock */
> >
> > <<report_1_stein.txt>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can not read UDF CD
2004-07-29 16:32 David Balazic
@ 2004-07-29 17:06 ` Pat LaVarre
2004-07-29 17:33 ` Ben Fennema
1 sibling, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-07-29 17:06 UTC (permalink / raw)
To: David Balazic; +Cc: 'David Burg', linux_udf, linux-kernel
// David Balazic:
> I will try to see if the problem is reproducable with burning
> more UDF CDs...
Yes please thank you.
>> I attach the "udf_test -scsi 1:0" output.
Attach did Not arrive here, sorry, please retry attach, at least to me,
else publish on web.
Also please say if you can easily share a .iso image of the disc. (Of
course I imagine linux_udf and linux-kernel don't want that attached.)
>> - Main: length,location: 32768, 30654 expected: 32768, 32
>> - Reserve: length,location: 32768, 30670 expected: 32768, 48
I likewise find these interesting. Don't know yet what they mean -
again I say "Ben wrote udf.ko, not I".
I'll try to hunt for relevant claims in the
udfct/src/udf_tester/udf_test (aka phgfsck) output when I receive it.
// David Burg:
>> Let me know if you ... think ... Nero has a mistake
Wow. Will do with pleasure thank you for your interest.
Pat LaVarre
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can not read UDF CD
2004-07-29 16:32 David Balazic
2004-07-29 17:06 ` Pat LaVarre
@ 2004-07-29 17:33 ` Ben Fennema
1 sibling, 0 replies; 17+ messages in thread
From: Ben Fennema @ 2004-07-29 17:33 UTC (permalink / raw)
To: David Balazic
Cc: 'Pat LaVarre', 'David Burg', linux_udf,
linux-kernel
On Thu, Jul 29, 2004 at 06:32:13PM +0200, David Balazic wrote:
> Just ask if you need any more info.
> I will try to see if the problem is reproducable with burning
> more UDF CDs... ( I guess the UDF part of Nero is not
> as widely used as ISO9660 )
Try mounting with -o session=0 (or something like that).
It's comming up with some totally random 2nd session in the middle of the
disc and trying to mount that.
Ben
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-07-30 7:16 David Balazic
0 siblings, 0 replies; 17+ messages in thread
From: David Balazic @ 2004-07-30 7:16 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'
Cc: 'linux_udf@hpesjro.fc.hp.com',
'linux-kernel@vger.kernel.org'
I tried your suggestions , but none of them worked :
(60071 was calculated as per your code)
(all failed with mount error(not printed here), the text below is from
dmesg)
mount -r -t udf -o anchor=60071 /dev/cdrom2 /mnt/cdrom2
UDF-fs DEBUG fs/udf/lowlevel.c:57:udf_get_last_session: XA disk: yes,
vol_desc_start=30622
UDF-fs DEBUG fs/udf/super.c:1552:udf_fill_super: Multi-session=30622
UDF-fs DEBUG fs/udf/super.c:540:udf_vrs: Starting at sector 30638 (2048 byte
sectors)
attempt to access beyond end of device
hdd: rw=0, want=362776, limit=240288
UDF-fs DEBUG fs/udf/misc.c:225:udf_read_tagged: block=90693, location=60071:
read failed
UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block
30878, tag 30878 != 256
UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor block found
UDF-fs: No partition found (1)
----
mount -r -t udf -o lastblock=60071 /dev/cdrom2 /mnt/cdrom2
UDF-fs DEBUG fs/udf/lowlevel.c:57:udf_get_last_session: XA disk: yes,
vol_desc_start=30622
UDF-fs DEBUG fs/udf/super.c:1552:udf_fill_super: Multi-session=30622
UDF-fs DEBUG fs/udf/super.c:540:udf_vrs: Starting at sector 30638 (2048 byte
sectors)
hdd: command error: status=0x51 { DriveReady SeekComplete Error }
hdd: command error: error=0x54
end_request: I/O error, dev hdd, sector 240284
UDF-fs DEBUG fs/udf/super.c:684:udf_find_anchor: Anchor found at block
60069, location mismatch 60069.
UDF-fs DEBUG fs/udf/super.c:684:udf_find_anchor: Anchor found at block
59921, location mismatch 59921.
UDF-fs DEBUG fs/udf/super.c:684:udf_find_anchor: Anchor found at block
59919, location mismatch 59919.
UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block
30878, tag 30878 != 256
UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor block found
UDF-fs: No partition found (1)
---
With your patch from mail :
mount -r -t udf /dev/cdrom2 /mnt/cdrom2
attempt to access beyond end of device
hdd: rw=0, want=240292, limit=240288
UDF-fs: No partition found (1)
> ----------
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 29. julij 2004 16:44
> To: David Balazic
> Cc: 'linux_udf@hpesjro.fc.hp.com'; 'linux-kernel@vger.kernel.org'
> Subject: Re: Can not read UDF CD
>
> David B:
>
> /// In short,
>
> I suggest quickly trying the mount -o lastblock= and anchor= udf.ko
> options described at:
>
> http://lxr.linux.no/source/Documentation/filesystems/udf.txt?v=2.6.5
>
> else working thru til able to try the phgfsck described at my page:
>
> http://udfko.blog-city.com/read/577369.htm
>
> If you do post the phgfsck report on the web, I'll gladly link to it.
>
> /// At length, in Seven parts ...
>
> /// 1) Similarly
>
> > UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch block
> 30878, tag 30878 != 256
> > UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor block
> found
> > UDF-fs: No partition found (1)
>
> In the merely private archives of linux_udf, just this week we see me
> suffering thru something highly similar, specifically:
>
> kernel: UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch
> block 256, tag 0 != 256
> kernel: UDF-fs DEBUG fs/udf/super.c:1342:udf_load_partition: No Anchor
> block found
> kernel: UDF-fs: No partition found (1)
>
> Note, since 2.6.7, by default these messages will grow more cryptic, we
> will see only:
>
> kernel: UDF-fs: No partition found (1)
>
> > > > UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch
> block 30878, tag 30878 != 256
> > > UDF-fs DEBUG fs/udf/misc.c:236:udf_read_tagged: location mismatch
> block 256, tag 0 != 256
>
> I'm guessing these messages mean the try to mount halted over garbage
> found at LBA x100 (256), but Ben wrote this code, not me.
>
> /// 2) Where
>
> What kind of cable do you use, what is your device name, what is your
> mount point?
>
> Til I know, I will cover both USB and PATAPI and pretend you want to
> mount /dev/scd0 at /mnt/scd0.
>
> /// 3) -o lastblock="$n"
>
> Up in user land, my workaround was:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
> sudo mount -r -o lastblock="$n" /dev/scd0 /mnt/scd0
>
> /// 4) patch -p1 ...
>
> To recover the feature:
>
> sudo mount -r /dev/scd0 /mnt/scd0
>
> for such unfriendly discs, I web-published the patch quoted below to the
> patches-udf.lastblock package of http://iomrrdtools.sourceforge.net/
>
> /// 5) -o anchor=...
>
> If -o lastblock="$n" doesn't work for you, then one more blind try is -o
> anchor="$n" i.e.
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
> sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> Please note -o anchor is arguably reckless except when combined with -r.
>
> /// 6) phgfsck
>
> If neither blind try works for you, then to make sense of the disc you
> can try phgfsck. For example, here, I see:
>
> $ sudo phgfsck -scsi /dev/sg0 | grep 'AVDPs at'
> Number of AVDPs: 2, AVDPs at N-256, N
> $
>
> Seeing "AVDP ... at ... N" tells me to try what I mentioned above:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 - p\"`"
> sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> /// 7) reconfiguring Linux to permit phgfsck
>
> http://www.extra.research.philips.com/udf/
> is the Philips page that offers the phgfsck, aka the "Philips UDF
> Verifier".
>
> My clarification of that page is:
>
> http://udfko.blog-city.com/read/577369.htm
>
> Philips deserves nothing but kudos for donating the phgfsck to improve
> UDF interoperability worldwide ... except the fact remains they haven't
> chosen to release their copyright under a license approved as open
> source by such authorities as sourceforge.net.
>
> Consequently, the phgfsck can be unusually hard to use in Linux.
> Specifically, it does Not incorporate any of the better SCSI pass thru
> libraries. Privately, as yet I've heard from Two employees of different
> corporations who privately requested and privately were denied
> permission to donate code into the phgfsck, because its source is partly
> closed.
>
> First, as yet with the phgfsck, you have to substitute an sg name for
> the regular dev name, even when running 2.6.
>
> To discover your sg name, you can try each of /dev/sg* to see what
> happens, or you can download yet another tool, such as sg_scan -i or my
> own plscsi -w, found at http://members.aol.com/plscsi/linux/
>
> In theory `phgfsck -showscsi` will give you device names, but for me
> that query doesn't work reliably. Trying here just now in
> 2.6.8-rc2-bk7, it hangs. In the past, I've seen it miss names.
>
> Often you need root privilege to discover the sg name.
>
> You will probably have an sg name to find only if your kernel has a
> drivers/scsi/sg.ko and your device name was among the /dev/scd*
>
> Else you might have to get into substituting ide-scsi.ko for ide-cd.ko,
> especially if your device name was among the /dev/hd*. linux-scsi
> speaks occasionally of the issues such substitutions raise.
>
> Pat LaVarre
> http://iomrrdtools.sourceforge.net/
> http://udfko.blog-city.com/
>
> --- From:
> http://sourceforge.net/project/showfiles.php?group_id=101444&package_id=12
> 5426
>
> See also: Readme.txt
> ... Copyright (c) 2004 Iomega Corp
> ... free software ...
> ... GNU General Public License as ... either ... or ...
> ...
>
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c
> --- linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c 2004-06-15
> 23:19:36.000000000 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c 2004-07-28
> 14:46:02.373806296 -0600
> @@ -73,9 +73,9 @@ udf_get_last_block(struct super_block *s
> struct block_device *bdev = sb->s_bdev;
> unsigned long lblock = 0;
>
> - if (ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> - lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> -
> + if (!ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> + return lblock;
> + lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> if (lblock)
> return lblock - 1;
> else
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/super.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/super.c
> --- linux-2.6.8-rc2-bk7/fs/udf/super.c 2004-07-28
> 10:36:35.928051888 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/super.c 2004-07-28
> 14:45:45.356393336 -0600
> @@ -1562,6 +1562,9 @@ static int udf_fill_super(struct super_b
> goto error_out;
> }
>
> + if (!UDF_SB_LASTBLOCK(sb)) {
> + UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
> + }
> udf_find_anchor(sb);
>
> /* Fill in the rest of the superblock */
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-07-30 7:17 David Balazic
2004-08-02 14:42 ` Pat LaVarre
2004-08-17 14:05 ` Pat LaVarre
0 siblings, 2 replies; 17+ messages in thread
From: David Balazic @ 2004-07-30 7:17 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'
Cc: 'David Burg', linux_udf, linux-kernel
How should I make the image ?
Remember, it is a multisession CD ( has two sessions ).
> ----------
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 29. julij 2004 19:06
> To: David Balazic
> Cc: 'David Burg'; linux_udf@hpesjro.fc.hp.com;
> linux-kernel@vger.kernel.org
> Subject: Re: Can not read UDF CD
>
> // David Balazic:
>
> > I will try to see if the problem is reproducable with burning
> > more UDF CDs...
>
> Yes please thank you.
>
> >> I attach the "udf_test -scsi 1:0" output.
>
> Attach did Not arrive here, sorry, please retry attach, at least to me,
> else publish on web.
>
> Also please say if you can easily share a .iso image of the disc. (Of
> course I imagine linux_udf and linux-kernel don't want that attached.)
>
> >> - Main: length,location: 32768, 30654 expected: 32768, 32
> >> - Reserve: length,location: 32768, 30670 expected: 32768, 48
>
> I likewise find these interesting. Don't know yet what they mean -
> again I say "Ben wrote udf.ko, not I".
>
> I'll try to hunt for relevant claims in the
> udfct/src/udf_tester/udf_test (aka phgfsck) output when I receive it.
>
> // David Burg:
>
> >> Let me know if you ... think ... Nero has a mistake
>
> Wow. Will do with pleasure thank you for your interest.
>
> Pat LaVarre
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can not read UDF CD
2004-07-30 7:17 Can not read UDF CD David Balazic
@ 2004-08-02 14:42 ` Pat LaVarre
2004-08-17 14:05 ` Pat LaVarre
1 sibling, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-08-02 14:42 UTC (permalink / raw)
To: David Balazic; +Cc: 'David Burg', linux_udf, linux-kernel
> How should I make the image ?
> Remember, it is a multisession CD ( has two sessions ).
Sorry I'm not yet caught up on all the help volunteered in this thread.
Have you specifically confirmed you can make more than one of these
discs? In the last resort, you could send the actual disc to my
mailing address.
Have you specifically confirmed certain forms of the session= option do
not work?
Pat LaVarre
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-08-09 7:33 David Balazic
2004-08-09 16:22 ` Pat LaVarre
0 siblings, 1 reply; 17+ messages in thread
From: David Balazic @ 2004-08-09 7:33 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'
Cc: 'David Burg', linux_udf, linux-kernel
> ----------
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 2. avgust 2004 16:42
> To: David Balazic
> Cc: 'David Burg'; linux_udf@hpesjro.fc.hp.com;
> linux-kernel@vger.kernel.org
> Subject: Re: Can not read UDF CD
>
> > How should I make the image ?
> > Remember, it is a multisession CD ( has two sessions ).
>
> Sorry I'm not yet caught up on all the help volunteered in this thread.
>
> Have you specifically confirmed you can make more than one of these
> discs? In the last resort, you could send the actual disc to my
> mailing address.
>
> Have you specifically confirmed certain forms of the session= option do
> not work?
>
I tried session=0.
This gives me the files form the first session, but I can only list them.
I can not see their attributes ( size, permissions etc.. ) or read them.
other session=x values fails to mount.
> Pat LaVarre
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-08-09 14:27 David Balazic
0 siblings, 0 replies; 17+ messages in thread
From: David Balazic @ 2004-08-09 14:27 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'
Cc: 'David Burg', linux_udf, linux-kernel
OK, I put the ISO image and the udf checker outputs on BitTorrent,
the torrent file is avaliable at
http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent
In case you don't have a BitTorrent client, one can be had at
http://bitconjurer.org/BitTorrent/download.html
( even a commandline version , written in python )
Regards,
David
> ----------
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 29. julij 2004 19:06
> To: David Balazic
> Cc: 'David Burg'; linux_udf@hpesjro.fc.hp.com;
> linux-kernel@vger.kernel.org
> Subject: Re: Can not read UDF CD
>
> // David Balazic:
>
> > I will try to see if the problem is reproducable with burning
> > more UDF CDs...
>
> Yes please thank you.
>
> >> I attach the "udf_test -scsi 1:0" output.
>
> Attach did Not arrive here, sorry, please retry attach, at least to me,
> else publish on web.
>
> Also please say if you can easily share a .iso image of the disc. (Of
> course I imagine linux_udf and linux-kernel don't want that attached.)
>
> >> - Main: length,location: 32768, 30654 expected: 32768, 32
> >> - Reserve: length,location: 32768, 30670 expected: 32768, 48
>
> I likewise find these interesting. Don't know yet what they mean -
> again I say "Ben wrote udf.ko, not I".
>
> I'll try to hunt for relevant claims in the
> udfct/src/udf_tester/udf_test (aka phgfsck) output when I receive it.
>
> // David Burg:
>
> >> Let me know if you ... think ... Nero has a mistake
>
> Wow. Will do with pleasure thank you for your interest.
>
> Pat LaVarre
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can not read UDF CD
2004-08-09 7:33 David Balazic
@ 2004-08-09 16:22 ` Pat LaVarre
0 siblings, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-08-09 16:22 UTC (permalink / raw)
To: David Balazic; +Cc: linux_udf, linux-kernel
> I tried session=0.
> This gives me the files form the first session, but I can only list
> them.
> I can not see their attributes ( size, permissions etc.. ) or read
> them.
This sounds exactly like the known bug, shared by 2.6.6 and 2.6.5,
fixed in 2.6.7, described previously as occurring for UDF discs written
to Linux from Windows:
ls works, but ls -l does not and cd does not.
> other session=x values fails to mount.
The dmesg for session=1 might interest us, but in any case, I vote we
try reasonably current code e.g. 2.6.7 or a cvs fetch of UDF.
> I put the ISO image and the udf checker outputs on BitTorrent,
> the torrent file is avaliable at
> http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent
Excellent, now in theory I can try this myself.
> In case you don't have a BitTorrent client, one can be had at
> http://bitconjurer.org/BitTorrent/download.html
> ( even a commandline version , written in python )
In practice I am not yet a BitTorrent client, thanks for this clear
invitation.
>> Re: potential bug in udf
>> ... a new bug ...
> Upgraded to 2.6.7 - the problem is still there.
I hear 2.6.7 is by now old enough to have begun collecting known bugs.
Pat LaVarre
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-08-10 8:31 David Balazic
0 siblings, 0 replies; 17+ messages in thread
From: David Balazic @ 2004-08-10 8:31 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'; +Cc: linux_udf, linux-kernel
I case the torrent does not work, you can also use the "traditional"
http protocol ;-)
http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports/
> ----------
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 9. avgust 2004 18:22
> To: David Balazic
> Cc: linux_udf@hpesjro.fc.hp.com; linux-kernel@vger.kernel.org
> Subject: Re: Can not read UDF CD
>
> > I tried session=0.
> > This gives me the files form the first session, but I can only list
> > them.
> > I can not see their attributes ( size, permissions etc.. ) or read
> > them.
>
> This sounds exactly like the known bug, shared by 2.6.6 and 2.6.5,
> fixed in 2.6.7, described previously as occurring for UDF discs written
> to Linux from Windows:
>
> ls works, but ls -l does not and cd does not.
>
> > other session=x values fails to mount.
>
> The dmesg for session=1 might interest us, but in any case, I vote we
> try reasonably current code e.g. 2.6.7 or a cvs fetch of UDF.
>
> > I put the ISO image and the udf checker outputs on BitTorrent,
> > the torrent file is avaliable at
> > http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent
>
> Excellent, now in theory I can try this myself.
>
> > In case you don't have a BitTorrent client, one can be had at
> > http://bitconjurer.org/BitTorrent/download.html
> > ( even a commandline version , written in python )
>
> In practice I am not yet a BitTorrent client, thanks for this clear
> invitation.
>
> >> Re: potential bug in udf
> >> ... a new bug ...
> > Upgraded to 2.6.7 - the problem is still there.
>
> I hear 2.6.7 is by now old enough to have begun collecting known bugs.
>
> Pat LaVarre
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can not read UDF CD
@ 2004-08-11 12:27 xerces8
0 siblings, 0 replies; 17+ messages in thread
From: xerces8 @ 2004-08-11 12:27 UTC (permalink / raw)
To: linux-kernel, p.lavarre, dburg
Hi!
I (D.Balazic, from another email account) created another CD and it has
the same problem.
Nero version : 5.5.10.56
OS : Windows 2003 Enterprise Edition
Nero settings :
- FS : UDF
- UDF partition type : Physical
FS version : UDF 1.02
I burned a small text file in the first session and then another text file
in the second session ( did not finalize the CD ).
It can not be mounted in linux. Using the mount option session=0 mounts
the first session, but I can only list the files (well, one file), not
access them. This time I used a slightly older kernel, the one from Fedora
Core 2 ( 2.6.7-something IIRC ).
So it seems the problem is reproducable both in Nero 5.5.x and 6.x
Regards,
David
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
2004-07-30 7:17 Can not read UDF CD David Balazic
2004-08-02 14:42 ` Pat LaVarre
@ 2004-08-17 14:05 ` Pat LaVarre
1 sibling, 0 replies; 17+ messages in thread
From: Pat LaVarre @ 2004-08-17 14:05 UTC (permalink / raw)
To: David Balazic; +Cc: linux_udf, linux-kernel
David Balazic:
Sorry I still have Not caught up on all this thread, yet I can add:
> How should I make the image ?
> Remember, it is a multisession CD ( has two sessions ).
I'm curious to know how you answered that question, because:
> http://bitconjurer.org/BitTorrent/download.html
> http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent
> http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports/udf.iso
I see this UDF disc image did Not arrive here in a usable form:
$ logger 1
$ sudo mount -r -t udf -o loop=/dev/loop0 udf.iso /mnt/loop0
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
or too many mounted file systems
(could this be the IDE device where you in fact use
ide-scsi so that sr0 or sda or so is needed?)
$ sudo cat /var/log/messages | tail -2
Aug 17 07:48:20 patlinux pat: 1
Aug 17 07:48:25 patlinux kernel: UDF-fs: No partition found (1)
$
$ phgfsck | head -4 | tail -2
Application version: 1.1r0
UCT Core version : 1.1r0
$ dd if=udf.iso bs=2K conv=sync >udf.2Ki.iso
$ phgfsck -mlimit 99 udf.2Ki.iso | grep 'total o'
Error count: 11 total occurrences: 43
Warning count: 0 total occurrences: 0
$
$ md5sum *.iso
22ab5c118f73307f88c43a820ced4718 udf.2Ki.iso
03ef2c1d988f65acde82c5da40ef17a2 udf.iso
$
> > I still have Not caught up on all this thread
I haven't yet seen you report uname -msr of 2.6.7 or better.
I missed how Ben F's suggestion of mount -t udf -o session=$n worked
out.
The David Burg & Gerrit S input I have not processed.
Etc.
> http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports/udf.iso
Link rotted away by now, I think.
Pat LaVarre
http://sourceforge.net/tracker/index.php?func=detail&aid=1008156&group_id=295&atid=100295
http://linux-pel.blog-city.com/read/768572.htm
http://linux-pel.blog-city.com/read/776884.htm
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Can not read UDF CD
@ 2004-08-17 14:24 David Balazic
0 siblings, 0 replies; 17+ messages in thread
From: David Balazic @ 2004-08-17 14:24 UTC (permalink / raw)
To: David Balazic, 'Pat LaVarre'; +Cc: linux_udf, linux-kernel
> 03ef2c1d988f65acde82c5da40ef17a2 udf.iso
>
This is the correct md5sum, you have the correct file.
I will create a smaller CD and try a fresh kernel, real soon now ;-)
> ----------
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 17. avgust 2004 16:05
> To: David Balazic
> Cc: linux_udf@hpesjro.fc.hp.com; linux-kernel@vger.kernel.org
> Subject: RE: Can not read UDF CD
>
> David Balazic:
>
> Sorry I still have Not caught up on all this thread, yet I can add:
>
> > How should I make the image ?
> > Remember, it is a multisession CD ( has two sessions ).
>
> I'm curious to know how you answered that question, because:
>
> > http://bitconjurer.org/BitTorrent/download.html
> > http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent
> > http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports/udf.iso
>
> I see this UDF disc image did Not arrive here in a usable form:
>
> $ logger 1
> $ sudo mount -r -t udf -o loop=/dev/loop0 udf.iso /mnt/loop0
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
> or too many mounted file systems
> (could this be the IDE device where you in fact use
> ide-scsi so that sr0 or sda or so is needed?)
> $ sudo cat /var/log/messages | tail -2
> Aug 17 07:48:20 patlinux pat: 1
> Aug 17 07:48:25 patlinux kernel: UDF-fs: No partition found (1)
> $
> $ phgfsck | head -4 | tail -2
> Application version: 1.1r0
> UCT Core version : 1.1r0
> $ dd if=udf.iso bs=2K conv=sync >udf.2Ki.iso
> $ phgfsck -mlimit 99 udf.2Ki.iso | grep 'total o'
> Error count: 11 total occurrences: 43
> Warning count: 0 total occurrences: 0
> $
> $ md5sum *.iso
> 22ab5c118f73307f88c43a820ced4718 udf.2Ki.iso
> 03ef2c1d988f65acde82c5da40ef17a2 udf.iso
> $
>
> > > I still have Not caught up on all this thread
>
> I haven't yet seen you report uname -msr of 2.6.7 or better.
>
> I missed how Ben F's suggestion of mount -t udf -o session=$n worked
> out.
>
> The David Burg & Gerrit S input I have not processed.
>
> Etc.
>
> > http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports/udf.iso
>
> Link rotted away by now, I think.
>
> Pat LaVarre
> http://sourceforge.net/tracker/index.php?func=detail&aid=1008156&group_id=
> 295&atid=100295
> http://linux-pel.blog-city.com/read/768572.htm
> http://linux-pel.blog-city.com/read/776884.htm
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-08-17 14:26 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-30 7:17 Can not read UDF CD David Balazic
2004-08-02 14:42 ` Pat LaVarre
2004-08-17 14:05 ` Pat LaVarre
-- strict thread matches above, loose matches on Subject: below --
2004-08-17 14:24 David Balazic
2004-08-11 12:27 xerces8
2004-08-10 8:31 David Balazic
2004-08-09 14:27 David Balazic
2004-08-09 7:33 David Balazic
2004-08-09 16:22 ` Pat LaVarre
2004-07-30 7:16 David Balazic
2004-07-29 16:32 David Balazic
2004-07-29 17:06 ` Pat LaVarre
2004-07-29 17:33 ` Ben Fennema
2004-07-29 15:32 David Balazic
2004-07-29 16:23 ` David Burg
2004-07-29 8:48 David Balazic
2004-07-29 14:44 ` Pat LaVarre
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox