Bug 313551 - (vista-udf) Vista burned UDF volumes won't mount
Vista burned UDF volumes won't mount
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
: 291961 (view as bug list)
Depends On:
Blocks: F9Target
  Show dependency treegraph
 
Reported: 2007-10-01 03:08 EDT by Jay Turner
Modified: 2015-07-09 00:39 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:56:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Attempt to fix udf mount (784 bytes, patch)
2007-10-04 12:54 EDT, Eric Sandeen
no flags Details | Diff
udf_test output (10.94 KB, text/plain)
2007-10-10 23:17 EDT, Eric Sandeen
no flags Details
philips udf_test output & associated dmesg (11.52 KB, text/plain)
2007-10-15 23:32 EDT, Eric Sandeen
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 10747 None None None Never

  None (edit)
Description Lubomir Kundrak 2007-10-01 03:08:17 EDT
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
Comment 1 Lubomir Kundrak 2007-10-01 03:11:12 EDT
A similar problem:
http://forums.fedoraforum.org/forum/showthread.php?t=166393
Comment 2 Lubomir Kundrak 2007-10-01 03:19:05 EDT
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?
Comment 3 Chuck Ebbert 2007-10-01 19:00:20 EDT
These are probably formatted as UDF version 2.50, and not supported in Linux...
Comment 4 Lubomir Kundrak 2007-10-02 03:39:27 EDT
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).
Comment 5 Eric Sandeen 2007-10-02 13:18:44 EDT
Not that it's definitive, but what does

file -Ls /dev/cdrom

say about this disk?

Thanks,
-Eric
Comment 6 Lubomir Kundrak 2007-10-02 16:43:24 EDT
Eric: /dev/cdrom: data
Comment 7 Eric Sandeen 2007-10-02 18:01:12 EDT
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
Comment 8 Lubomir Kundrak 2007-10-03 04:32:26 EDT
$ 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
Comment 11 Christopher Brown 2007-10-03 10:29:59 EDT
*** Bug 291961 has been marked as a duplicate of this bug. ***
Comment 12 Eric Sandeen 2007-10-03 11:50:32 EDT
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.
Comment 13 Chuck Ebbert 2007-10-03 12:17:26 EDT
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.

Comment 14 Eric Sandeen 2007-10-03 12:40:00 EDT
With the fragment Lubomir sent, we never even get to udf_current_aext before
mount hits the: UDF-fs: No fileset found message...
Comment 15 Eric Sandeen 2007-10-04 12:54:30 EDT
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
Comment 16 Lubomir Kundrak 2007-10-04 18:43:00 EDT
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)
Comment 17 Eric Sandeen 2007-10-04 21:51:07 EDT
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
Comment 18 Lubomir Kundrak 2007-10-05 05:20:38 EDT
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.
Comment 19 Lubomir Kundrak 2007-10-05 05:43:03 EDT
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)
Comment 20 Eric Sandeen 2007-10-05 10:31:03 EDT
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.
Comment 21 Eric Sandeen 2007-10-05 11:26:21 EDT
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
Comment 22 Eric Sandeen 2007-10-10 23:11:33 EDT
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
Comment 23 Eric Sandeen 2007-10-10 23:17:35 EDT
Created attachment 223781 [details]
udf_test output

For what it's worth, the udf_test verifier from philips doesn't like this disk,
either.
Comment 26 Eric Sandeen 2007-10-11 10:03:47 EDT
Mac OSX can't mount the Vista "UDF 2.01" image either.
Comment 27 Eric Sandeen 2007-10-15 23:32:25 EDT
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.
Comment 28 Lubomir Kundrak 2007-11-16 05:09:46 EST
Any progress on this? Does Vista create purposefully broken UDF volumes?
Comment 29 Eric Sandeen 2007-11-16 15:21:35 EST
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.
Comment 30 Antonio Bulgheroni 2008-01-02 08:56:53 EST
Same issue here with Fedora 8 and kernel 2.6.23.8-63.fc8

cheers,
Comment 31 Eric Sandeen 2008-01-02 22:42:14 EST
Hm, well.  My UDF-2.01 CD from vista mounts fine on OSX 10.5.1, so... more investigation is needed.
Comment 32 Ron Hachey 2008-02-19 00:17:35 EST
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.
Comment 33 Per Thomas Jahr 2008-04-23 13:54:06 EDT
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 :)."
Comment 34 Eric Sandeen 2008-04-23 14:09:36 EDT
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
Comment 35 Eric Sandeen 2008-04-29 18:12:37 EDT
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
Comment 36 Bug Zapper 2008-05-14 10:35:23 EDT
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
Comment 37 Eric Sandeen 2008-05-14 10:50:50 EDT
still a problem upstream, see comment #35
Comment 39 Martin Jürgens 2008-06-10 17:07:01 EDT
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?
Comment 40 Martin Jürgens 2008-06-10 17:10:01 EDT
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..
Comment 41 Paul Bolle 2008-06-24 09:31:46 EDT
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. 
Comment 42 Paul Bolle 2008-09-15 05:07:56 EDT
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?
Comment 43 Eric Sandeen 2008-09-15 21:05:27 EDT
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...)
Comment 44 The Source 2008-09-16 15:32:54 EDT
HoMM V: Silver Edition mounts normally.
Comment 45 Bug Zapper 2009-06-09 18:54:04 EDT
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
Comment 46 Bug Zapper 2009-07-14 12:56:50 EDT
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.
Comment 47 Richard Jasmin 2015-07-09 00:39:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.