public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 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