Bug 313551 (vista-udf)
| Summary: | Vista burned UDF volumes won't mount | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jay Turner <jturner> | ||||||||
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 9 | CC: | antonio.bulgheroni, ch.nolte, chris.brown, esandeen, k.georgiou, ma, mishu, pebolle, perja, spike85051, srevivo, thesource, triage, wbachman | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-07-14 16:56:50 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 235705 | ||||||||||
| Attachments: |
|
||||||||||
A similar problem: http://forums.fedoraforum.org/forum/showthread.php?t=166393 http://lists.rpmforge.net/pipermail/users/2007-June/000812.html I've read numerous reports that mounting it via /dev/pktcdvd* device set up by pktsetup may help. Do we have packet writing support? These are probably formatted as UDF version 2.50, and not supported in Linux... Chuck: That is very possible. How do I find out? The cd-info says it's 0.00. In any case, the kernel seems to be able to recognize that it was meant to be an UDF, so we could output and information about version mismatch rather that that 'no filesets found' (assumeing the filesystem is not really corrupt, as it seems from that 0.00). Not that it's definitive, but what does file -Ls /dev/cdrom say about this disk? Thanks, -Eric Eric: /dev/cdrom: data heh, yep, not definitive :) It would be nice to know for sure that this is an issue with UDF 2.5 and not something else... perhaps you could dd out, compress, and attach the first 64k or so of the device/disk? -Eric $ dd if=/dev/cdrom of=image-313551 dd: reading `/dev/cdrom': Input/output error 1248+0 records in 1248+0 records out 638976 bytes (639 kB) copied, 0.513541 s, 1.2 MB/s $ Oct 3 10:31:09 localhost kernel: end_request: I/O error, dev sr0, sector 1248 Oct 3 10:31:09 localhost kernel: printk: 60 messages suppressed. Oct 3 10:31:09 localhost kernel: Buffer I/O error on device sr0, logical block 312 Oct 3 10:31:09 localhost kernel: Buffer I/O error on device sr0, logical block 313 Oct 3 10:31:09 localhost kernel: Buffer I/O error on device sr0, logical block 314 Oct 3 10:31:09 localhost kernel: Buffer I/O error on device sr0, logical block 315 Oct 3 10:31:09 localhost kernel: Buffer I/O error on device sr0, logical block 316 http://skosi.org/~lkundrak/misc/image-313551 *** Bug 291961 has been marked as a duplicate of this bug. *** FWIW, this is actually not a rev 2.50 UDF image. Looking at the hexdump: 0000b0d0 00 00 00 17 00 08 00 00 00 2a 4f 53 54 41 20 55 |.........*OSTA U| 0000b0e0 44 46 20 43 6f 6d 70 6c 69 61 6e 74 00 00 00 00 |DF Compliant....| 0000b0f0 01 02 00 00 00 00 00 00 00 08 00 00 00 00 00 00 |................| The string is the Domain Identifier, 23 chars, followed by an IdentifierSuffix, which is 1 byte of flags and 2 bytes of version... I'm only slightly lost here; this is either version 2.00 or 2.01. But, not 2.50 it seems. Hmm... look at http://lkml.org/lkml/2007/9/19/344 where someone had a similar problem: --------- Now what goes wrong? In udf/inode.c/udf_current_aext there is support for allocation types ICBTAG_FLAG_AD_SHORT (0) and ICBTAG_FLAG_AD_LONG (1) and for no other types. However, ECMA 167 writes (in 14.6.8): 0-2 Shall be interpreted as a 3-bit unsigned binary number as follows. The value 0 shall mean that Short Allocation Descriptors are used. The value 1 shall mean that Long Allocation Descriptors are used. The value 2 shall mean that Extended Allocation Descriptors are used. The value 3 shall mean that the file shall be treated as though it had exactly one allocation descriptor describing an extent which starts with the first byte of the Allocation Descriptors field and has a length, in bytes, recorded in the Length of Allocation Descriptors field. The values of 4-7 are reserved for future standardisation. and this particular CD-ROM uses type 3. So, I guess udf_current_aext() must be updated a bit. With the fragment Lubomir sent, we never even get to udf_current_aext before mount hits the: UDF-fs: No fileset found message... Created attachment 216091 [details]
Attempt to fix udf mount
The issue seems to be that when reading virtual maps, udf_load_logicalvol does
not recognize version 2.01 filesystems, only 2.00.
Lubomir, can you try a patch something like this; I'm not sure which kernel
version you're using, and there have been whitspace changes so this may not
apply directly, but you should be able to hand-merge pretty easily - it just
adds one more test. If that's a problem, pls let me know which kernel version
& arch you're using, and I can attach a udf.ko
Thanks,
-Eric
Eric: thanks for your patch. I checked out latest kernel from CVS (2.6.23-0.218.rc9.git1.fc7) and built it with the patch. It does not solve the problem, but the error message is a bit different: udf: udf_fill_inode(ino 256288) failed unknown file type=248 UDF-fs: No partition found (1) Darn.. I got some errors too but they were related to the truncated image I got from you, so I hoped that was all. Since you're rebuilding, could you try #defining UDFFS_DEBUG here: include/linux/udf_fs.h:#undef UDFFS_DEBUG and send me all the messages you get when you try to mount? or if there's any luck getting an actual full image of the disc... or maybe remote access would be in order, now. I'll see what might be causing the above two messages. Thanks, -Eric Eric: To me it seems like it's due to the same problems as the dd one: UDF-fs DEBUG fs/udf/lowlevel.c:44:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG fs/udf/super.c:1491:udf_fill_super: Multi-session=0 UDF-fs DEBUG fs/udf/super.c:554:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG fs/udf/super.c:846:udf_load_pvoldesc: recording time 1184676503/590500, 2007/07/17 12:48 (1000) UDF-fs DEBUG fs/udf/super.c:855:udf_load_pvoldesc: volIdent[] = 'UDF Volume' UDF-fs DEBUG fs/udf/super.c:861:udf_load_pvoldesc: volSetIdent[] = '0C30173B UDF Volume Set' UDF-fs DEBUG fs/udf/super.c:1044:udf_load_logicalvol: Partition (0:8192) type 1 on volume 1 UDF-fs DEBUG fs/udf/super.c:1044:udf_load_logicalvol: Partition (1:8192) type 2 on volume 1 UDF-fs DEBUG fs/udf/super.c:1053:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=0, partition=1 UDF-fs DEBUG fs/udf/super.c:889:udf_load_partdesc: Searching map: (8192 == 8192) UDF-fs DEBUG fs/udf/super.c:977:udf_load_partdesc: Partition (8192:0 type 1511) starts at physical 288, block length 359296 UDF-fs DEBUG fs/udf/super.c:1283:udf_load_partition: Using anchor in block 256 sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK sr 0:0:0:0: [sr0] Sense Key : Medium Error [current] Info fld=0x3e922 sr 0:0:0:0: [sr0] Add. Sense: Unrecovered read error end_request: I/O error, dev sr0, sector 1025160 UDF-fs DEBUG fs/udf/misc.c:213:udf_read_tagged: location mismatch block 512, tag 2910063269 != 512 udf: udf_fill_inode(ino 256288) failed unknown file type=248 UDF-fs: No partition found (1) Please note that I still believe that the medium is fine; though I don't have an access to a windows machine anymore. If I dd with conv=noerror, it seems that attempt to read any sector after those 640K returns a read error. What's weird is that in a proliant03 machine I get 655360 bytes: # dd if=/dev/cdrom of=image dd: reading `/dev/cdrom': Input/output error 1280+0 records in 1280+0 records out 655360 bytes (655 kB) copied, 2.23518 s, 293 kB/s # If I try back im my workstation again, I get only 638976, as quoted in comment #8. I'll mail you details about accessing the machine. If you feel that the media might be broken, please don't spend time on this and I'll try to get someone burn me another medium so we can be sure, or attempt to find someone with windows to test the media for me. Back at my workstation, with the very same kernel installed, I get no read errors: UDF-fs DEBUG fs/udf/lowlevel.c:44:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG fs/udf/super.c:1491:udf_fill_super: Multi-session=0 UDF-fs DEBUG fs/udf/super.c:554:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG fs/udf/super.c:846:udf_load_pvoldesc: recording time 1184676503/590500, 2007/07/17 12:48 (1000) UDF-fs DEBUG fs/udf/super.c:855:udf_load_pvoldesc: volIdent[] = 'UDF Volume' UDF-fs DEBUG fs/udf/super.c:861:udf_load_pvoldesc: volSetIdent[] = '0C30173B UDF Volume Set' UDF-fs DEBUG fs/udf/super.c:1044:udf_load_logicalvol: Partition (0:8192) type 1 on volume 1 UDF-fs DEBUG fs/udf/super.c:1044:udf_load_logicalvol: Partition (1:8192) type 2 on volume 1 UDF-fs DEBUG fs/udf/super.c:1053:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=0, partition=1 UDF-fs DEBUG fs/udf/super.c:889:udf_load_partdesc: Searching map: (8192 == 8192) UDF-fs DEBUG fs/udf/super.c:977:udf_load_partdesc: Partition (8192:0 type 1511) starts at physical 288, block length 359296 UDF-fs DEBUG fs/udf/super.c:1283:udf_load_partition: Using anchor in block 256 UDF-fs DEBUG fs/udf/misc.c:213:udf_read_tagged: location mismatch block 512, tag 2910063269 != 512 udf: udf_fill_inode(ino 256288) failed unknown file type=248 UDF-fs: No partition found (1) I'm not sure what to make of the read errors: sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK sr 0:0:0:0: [sr0] Sense Key : Medium Error [current] Info fld=0x3e922 sr 0:0:0:0: [sr0] Add. Sense: Unrecovered read error end_request: I/O error, dev sr0, sector 1025160 but this seems like it must be a media problem...? Especially if even dd fails. I think the patch I sent is still valid, but there must be other issues here. Lubomir, talked w/ jgarzik too, and this can't be anything but a simple media error. But, I think the udf bug I found is valid too. Can you have this image re-burned and try it again, with & without the patch? :) Thanks, -Eric So, I burned a "Live Filesystem" (a.k.a. UDF 2.01) image from vista, and I get the exact same results: no fileset, fixed that, then get IO errors and no partition found, dd from the device fails with IO errors as well. Interesting... -Eric Created attachment 223781 [details]
udf_test output
For what it's worth, the udf_test verifier from philips doesn't like this disk,
either.
Mac OSX can't mount the Vista "UDF 2.01" image either. Created attachment 228141 [details]
philips udf_test output & associated dmesg
philips udf verifier also finds that it can't read everything it wants to on
the vista-burned UDF image.
Any progress on this? Does Vista create purposefully broken UDF volumes? No progress I'm afraid, hard to say what windows is doing. I'd like to get to the bottom of it but it's just not a high enough priority right now. It sure does look like windows is broken if Mac & the Philips verifier also find problems. Same issue here with Fedora 8 and kernel 2.6.23.8-63.fc8 cheers, Hm, well. My UDF-2.01 CD from vista mounts fine on OSX 10.5.1, so... more investigation is needed. I have encountered the same problem with FC8. After some experimentation I found that Vista disks written in UDF 2.50 and 2.01 formats cannot be read but a UDF 1.50 disk works perfectly. FYI: there is a patch for UDF-2.50 support here: http://sourceforge.net/tracker/ index.php?func=detail&aid=1907699&group_id=295&atid=300295 From the page: "I've submitted the patch for inclusion into the mainline kernel, and it looks like it will make it into 2.6.26. Hopefully good news for anyone interested :)." Last I checked, that patch unfortunately did not resolve this particular issue. Even vista-burned UDF v2.01 volumes wouldn't mount, in my testing. -Eric FWIW, I tested UDF from 2.6.26-git, no more luck after that round of changes. Just haven't had time to dig into this one. -Eric This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping still a problem upstream, see comment #35 same issue. got a dvd by a friend created using a DVD TV recorder, and i get exactly that message. Is there any information that I can provide in order to help fix the problem? Disc mode is listed as: Unknown/unclassified DVD CD-ROM Track List (1 - 1) #: MSF LSN Type Green? Copy? 1: 00:02:00 000000 data true yes 170: e1:07:21 634896 leadout (1424 MB raw, 1240 MB formatted) __________________________________ CD Analysis Report Would be great to have it sorted out.. For what it's worth, I ran into a UDF formatted CD that couldn't be mounted with the current F9 kernel (2.6.25.6-55.fc9.i686) but can be mounted with a recent rawhide kernel (2.6.26-0.74.rc6.git4.fc10.i686). /var/log/messages simply says: UDF-fs: Filesystem marked read-only because writing to pseudooverwrite partition is not implemented. UDF-fs INFO UDF: Mounting volume 'UDF Volume', timestamp 2008/03/24 18:53 (1078) dmesg has more: UDF-fs DEBUG fs/udf/lowlevel.c:43:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG fs/udf/super.c:1920:udf_fill_super: Multi-session=0 UDF-fs DEBUG fs/udf/super.c:613:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG fs/udf/super.c:935:udf_load_pvoldesc: recording time 2008/03/24 16:53 (1000) UDF-fs DEBUG fs/udf/super.c:944:udf_load_pvoldesc: volIdent[] = 'UDF Volume' UDF-fs DEBUG fs/udf/super.c:949:udf_load_pvoldesc: volSetIdent[] = '10353852 UDF Volume Set' UDF-fs DEBUG fs/udf/super.c:1481:udf_load_logicalvol: Partition (0:8192) type 1 on volume 1 UDF-fs DEBUG fs/udf/super.c:1481:udf_load_logicalvol: Partition (1:8192) type 2 on volume 1 UDF-fs DEBUG fs/udf/super.c:1490:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=0, partition=1 UDF-fs DEBUG fs/udf/super.c:1271:udf_load_partdesc: Searching map: (8192 == 8192) UDF-fs DEBUG fs/udf/super.c:1125:udf_fill_partdesc_info: Partition (0 type 1511) starts at physical 288, block length 359296 UDF-fs DEBUG fs/udf/super.c:1125:udf_fill_partdesc_info: Partition (1 type 2012) starts at physical 288, block length 359296 UDF-fs: Filesystem marked read-only because writing to pseudooverwrite partition is not implemented. UDF-fs DEBUG fs/udf/super.c:1745:udf_load_sequence: Using anchor in block 256 UDF-fs DEBUG fs/udf/super.c:1947:udf_fill_super: Lastblock=49120 UDF-fs DEBUG fs/udf/super.c:903:udf_find_fileset: Fileset at block=0, partition=1 UDF-fs DEBUG fs/udf/super.c:1062:udf_load_fileset: Rootdir at block=1, partition=1 UDF-fs INFO UDF: Mounting volume 'UDF Volume', timestamp 2008/03/24 18:53 (1078) part of hexdump looks similar to comment#11: 0000b0d0 00 00 00 21 00 08 00 00 00 2a 4f 53 54 41 20 55 |...!.....*OSTA U| 0000b0e0 44 46 20 43 6f 6d 70 6c 69 61 6e 74 00 00 00 00 |DF Compliant....| 0000b0f0 01 02 00 00 00 00 00 00 00 08 00 00 00 00 00 00 |................| /proc/mounts just gives: /dev/sr1 /mnt/tmp udf ro,utf8 0 0 So (part of?) this bug seems fixed in kernel 2.6.26-rc6. As was to be expected, the UDF formatted CD of comment #40 can now also be mounted with current F9 kernel (2.6.26.3-29.fc9.i686). (Automagically even.) This bug can be CLOSED/FIXED, can't it? Hm, the original reporter no longer has a bugzilla acct so can't circle back to check there. Anyone else who chimed in on this bug - does the latest kernel actually fix this for you too? (I have a few vista-udf cds I burned at home as well, can re-test those next week...) HoMM V: Silver Edition mounts normally. This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. Similar effect in FC21 when using media burned within windows 7+.It could just be flaky read on LG14/16 LH series drives forcing a reboot.Im assuming the BDROMs I burned use UDF as there are large files present.(Warcraft backup as an example) Unfortunately I no longer have the media.They were tossed as unreadble media by Fedora. I used a win7+ machine and removeable bay with my spare LH16 to get around the issue for the time being.Seems windows is NOT burning compatible RR/Joliet info so Linux can read the media.I think I used winxp burner to burn the media. |
Description of problem: CDs and DVDs that I suspect to be burned with Windows Vista won't mount. Steps to Reproduce: 1. Insert such media and wait. 2. See Gnome complain. 3. Try to mount it by hand and you'll get the same results. Actual results: # mount /dev/cdrom /mnt mount: block device /dev/cdrom is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/cdrom, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so This goes into the kernel message buffer: UDF-fs: No fileset found Additional info: This is the relevant part of cd-info output: __________________________________ Disc mode is listed as: CD DATA (Mode 2) CD-ROM Track List (1 - 1) #: MSF LSN Type Green? Copy? 1: 00:02:00 000000 data false no 170: 56:59:16 256291 leadout (574 MB raw, 570 MB formatted) Media Catalog Number (MCN): 0000000000000 Last CD Session LSN: 0 __________________________________ CD Analysis Report UDF: version 0.00