When I burned the Fedora ISOs to CDs, I used cdrecord with padding to avoid the readahead bug - see
http://www.troubleshooters.com/linux/coasterless.htm
for how. In short, you use something like
cdrecord -v dev=/dev/cdrom -dao -pad padsize=63s FC-6-i386-disc1.iso
It turns out that the same precaution is necessary with DVDs, and until recently I was able to use cdrecord for this, like
cdrecord -v dev=/dev/dvd -dao -pad padsize=63s FC-6-i386-DVD.iso
even though a lot of ugly-looking error messages appeared before the burn commenced. But in the last month or so, instead of burning, cdrecord simply gives up. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233745
I know about growisofs, but unfortunately it's incapable of putting padding on the DVD _after_ the ISO file (I know it has a -pad option, but it just passes it through to mkisofs, which provides padding _inside_ the ISO, which isn't what is needed, and when burning an ISO file it can't be used anyway). I tried once using dd to manually add zero padding after the ISO, but although the resulting DVD passed mediacheck, it failed to boot properly. So it seems that at the moment there's no tool that can reliably burn a DVD and pad it properly. After gradually learning over several years how to reliably burn Fedora ISOs, I don't want to go back to mediacheck hell. As I see it, there are several options:
1) Fix the readahead bug. Unfortunately, we all know that will never happen. No one who's qualified cares enough to do it.
2) Fix cdrecord. The last time I successfully used it was March 29, so some update since then broke it. It's not the kernel, since after booting into the same kernel I was using then, it was still broken.
3) Find some other tool besides cdrecord that can do the necessary padding for DVDs. Are there any?
4) Modify mediacheck. I know that by default mkisofs provides enough padding to protect the files inside the ISO from the readahead bug. But mediacheck is apparently checking the entire ISO, including the padded part at the end after the actual files in it, where the readahead bug occurs. Can it be tweaked to just check up to the end of the last file inside the ISO? And can something similar be done so no errors occur during the actual install either?
On Tue, 2007-05-08 at 02:37 -0400, Andre Robatino wrote:
When I burned the Fedora ISOs to CDs, I used cdrecord with padding to avoid the readahead bug - see
http://www.troubleshooters.com/linux/coasterless.htm
for how. In short, you use something like
cdrecord -v dev=/dev/cdrom -dao -pad padsize=63s FC-6-i386-disc1.iso
It turns out that the same precaution is necessary with DVDs, and until recently I was able to use cdrecord for this, like
cdrecord -v dev=/dev/dvd -dao -pad padsize=63s FC-6-i386-DVD.iso
even though a lot of ugly-looking error messages appeared before the burn commenced. But in the last month or so, instead of burning, cdrecord simply gives up. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233745
I know about growisofs, but unfortunately it's incapable of putting padding on the DVD _after_ the ISO file (I know it has a -pad option, but it just passes it through to mkisofs, which provides padding _inside_ the ISO, which isn't what is needed, and when burning an ISO file it can't be used anyway). I tried once using dd to manually add zero padding after the ISO, but although the resulting DVD passed mediacheck, it failed to boot properly. So it seems that at the moment there's no tool that can reliably burn a DVD and pad it properly. After gradually learning over several years how to reliably burn Fedora ISOs, I don't want to go back to mediacheck hell. As I see it, there are several options:
- Fix the readahead bug. Unfortunately, we all know that will never
happen. No one who's qualified cares enough to do it.
- Fix cdrecord. The last time I successfully used it was March 29, so
some update since then broke it. It's not the kernel, since after booting into the same kernel I was using then, it was still broken.
- Find some other tool besides cdrecord that can do the necessary
padding for DVDs. Are there any?
- Modify mediacheck. I know that by default mkisofs provides enough
padding to protect the files inside the ISO from the readahead bug. But mediacheck is apparently checking the entire ISO, including the padded part at the end after the actual files in it, where the readahead bug occurs. Can it be tweaked to just check up to the end of the last file inside the ISO? And can something similar be done so no errors occur during the actual install either?
All of my FC DVDs have been written with:
growisofs -dvd-compat -Z /dev/dvd=/path/to/dvd.iso
with nary a glitch (no need for read ahead padding, nada). Burned on multiple machines with different DVD writers, readers, etc. Either I've been hugely lucky or you've been hugely unlucky.
---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@internap.com - - VitalStream, Inc. http://www.vitalstream.com - - - - To iterate is human, to recurse, divine. - ----------------------------------------------------------------------
Rick Stevens wrote:
On Tue, 2007-05-08 at 02:37 -0400, Andre Robatino wrote:
When I burned the Fedora ISOs to CDs, I used cdrecord with padding to avoid the readahead bug - see
http://www.troubleshooters.com/linux/coasterless.htm
for how. In short, you use something like
cdrecord -v dev=/dev/cdrom -dao -pad padsize=63s FC-6-i386-disc1.iso
It turns out that the same precaution is necessary with DVDs, and until recently I was able to use cdrecord for this, like
cdrecord -v dev=/dev/dvd -dao -pad padsize=63s FC-6-i386-DVD.iso
even though a lot of ugly-looking error messages appeared before the burn commenced. But in the last month or so, instead of burning, cdrecord simply gives up. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233745
I know about growisofs, but unfortunately it's incapable of putting padding on the DVD _after_ the ISO file (I know it has a -pad option, but it just passes it through to mkisofs, which provides padding _inside_ the ISO, which isn't what is needed, and when burning an ISO file it can't be used anyway). I tried once using dd to manually add zero padding after the ISO, but although the resulting DVD passed mediacheck, it failed to boot properly. So it seems that at the moment there's no tool that can reliably burn a DVD and pad it properly. After gradually learning over several years how to reliably burn Fedora ISOs, I don't want to go back to mediacheck hell. As I see it, there are several options:
- Fix the readahead bug. Unfortunately, we all know that will never
happen. No one who's qualified cares enough to do it.
- Fix cdrecord. The last time I successfully used it was March 29, so
some update since then broke it. It's not the kernel, since after booting into the same kernel I was using then, it was still broken.
- Find some other tool besides cdrecord that can do the necessary
padding for DVDs. Are there any?
- Modify mediacheck. I know that by default mkisofs provides enough
padding to protect the files inside the ISO from the readahead bug. But mediacheck is apparently checking the entire ISO, including the padded part at the end after the actual files in it, where the readahead bug occurs. Can it be tweaked to just check up to the end of the last file inside the ISO? And can something similar be done so no errors occur during the actual install either?
All of my FC DVDs have been written with:
growisofs -dvd-compat -Z /dev/dvd=/path/to/dvd.iso
with nary a glitch (no need for read ahead padding, nada). Burned on multiple machines with different DVD writers, readers, etc. Either I've been hugely lucky or you've been hugely unlucky.
You've been lucky. I have two DVD burners, a Mad Dog MD-8XDVD9 bought 3 years ago which is vulnerable to the mediacheck bug, and a Sony DRU-120C bought a few months ago which doesn't appear to be (although I haven't had it long enough to be sure). It's possible that on average DVD drives are less likely to be vulnerable than CD drives used to be. I know the problem exists when burning DVD+RW discs without padding. IIRC, a DVD+R disc I burned without padding didn't appear to have the problem even on the vulnerable drive, but I'd rather use the padding to be sure.
On Tue, 2007-05-08 at 09:33 -0700, Rick Stevens wrote:
All of my FC DVDs have been written with:
growisofs -dvd-compat -Z /dev/dvd=/path/to/dvd.isowith nary a glitch (no need for read ahead padding, nada). Burned on multiple machines with different DVD writers, readers, etc.
Same here, along with right-clicking on an ISO in Nautilus, and burning from there. Worked fine, including the media check. I'm using Verbatim DVD+R discs. I've found their discs to be the best that I can buy, here. Much of the discs in the local shops are utter crap. And + discs are supposed to have some advantages over - ones, though that does depend on the drive making using of the features.
Tim wrote:
On Tue, 2007-05-08 at 09:33 -0700, Rick Stevens wrote:
All of my FC DVDs have been written with:
growisofs -dvd-compat -Z /dev/dvd=/path/to/dvd.isowith nary a glitch (no need for read ahead padding, nada). Burned on multiple machines with different DVD writers, readers, etc.
Same here, along with right-clicking on an ISO in Nautilus, and burning from there. Worked fine, including the media check. I'm using Verbatim DVD+R discs. I've found their discs to be the best that I can buy, here. Much of the discs in the local shops are utter crap. And + discs are supposed to have some advantages over - ones, though that does depend on the drive making using of the features.
I believe that most mediacheck failures are caused by the readahead bug (although years ago I found that Memorex CDs were so crappy that they would literally sometimes go from pass to fail in about 15 hours after burning). I know that some drives (either DVD or CD) are vulnerable and some aren't. Whether the DVD is RW or just R may also matter - as mentioned before I had the problem burning to a DVD+RW using growisofs (and I have enough experience with the media in question to know that its stability wasn't the problem). But burning to a DVD+R with growisofs seemed to work ok (though it could just have been luck). When F7 comes out I'll try growisofs with the DVD+R and cross my fingers. If that doesn't work I'll try finding a newer version of cdrecord and see if that works. I'd be interested in knowing if anyone out there can currently burn DVDs using the version of cdrecord in either FC6 or F7t4, and whether or not it spews error messages.
On Wednesday 09 May 2007, Andre Robatino wrote:
Tim wrote:
On Tue, 2007-05-08 at 09:33 -0700, Rick Stevens wrote:
All of my FC DVDs have been written with:
growisofs -dvd-compat -Z /dev/dvd=/path/to/dvd.isowith nary a glitch (no need for read ahead padding, nada). Burned on multiple machines with different DVD writers, readers, etc.
Same here, along with right-clicking on an ISO in Nautilus, and burning from there. Worked fine, including the media check. I'm using Verbatim DVD+R discs. I've found their discs to be the best that I can buy, here. Much of the discs in the local shops are utter crap. And + discs are supposed to have some advantages over - ones, though that does depend on the drive making using of the features.
I believe that most mediacheck failures are caused by the readahead bug (although years ago I found that Memorex CDs were so crappy that they would literally sometimes go from pass to fail in about 15 hours after burning). I know that some drives (either DVD or CD) are vulnerable and some aren't. Whether the DVD is RW or just R may also matter - as mentioned before I had the problem burning to a DVD+RW using growisofs (and I have enough experience with the media in question to know that its stability wasn't the problem). But burning to a DVD+R with growisofs seemed to work ok (though it could just have been luck). When F7 comes out I'll try growisofs with the DVD+R and cross my fingers. If that doesn't work I'll try finding a newer version of cdrecord and see if that works. I'd be interested in knowing if anyone out there can currently burn DVDs using the version of cdrecord in either FC6 or F7t4, and whether or not it spews error messages.
It is not being a problem here, and I just burnt a new copy of kubuntu last week, on FC6.
On Wednesday 09 May 2007, Andre Robatino wrote:
I believe that most mediacheck failures are caused by the readahead bug (although years ago I found that Memorex CDs were so crappy that they would literally sometimes go from pass to fail in about 15 hours after burning).
Memorex did go through a bqad patch, which I understand was due to the fact that they used more than one supplier, of which at least one had less-than-adequate quality control. I don't think there is a problem now.
I know that some drives (either DVD or CD) are vulnerable and some aren't.
Not all older drive support burn-free, which could be one factor.
Another thing to consider. I was told by Lite-On technical support people that DVD+R disks are more forgiving than DVD-R. I have certainly had fewer problems on my stand-alone recorder since changing to +R.
Whether the DVD is RW or just R may also matter - as mentioned before I had the problem burning to a DVD+RW using growisofs (and I have enough experience with the media in question to know that its stability wasn't the problem). But burning to a DVD+R with growisofs seemed to work ok (though it could just have been luck). When F7 comes out I'll try growisofs with the DVD+R and cross my fingers. If that doesn't work I'll try finding a newer version of cdrecord and see if that works. I'd be interested in knowing if anyone out there can currently burn DVDs using the version of cdrecord in either FC6 or F7t4, and whether or not it spews error messages.
Yes, I've burned many DVDs under FC6. I use K3B, and have no problem at all.
Anne
Anne Wilson wrote:
On Wednesday 09 May 2007, Andre Robatino wrote:
I believe that most mediacheck failures are caused by the readahead bug (although years ago I found that Memorex CDs were so crappy that they would literally sometimes go from pass to fail in about 15 hours after burning).
Memorex did go through a bqad patch, which I understand was due to the fact that they used more than one supplier, of which at least one had less-than-adequate quality control. I don't think there is a problem now.
I know that some drives (either DVD or CD) are vulnerable and some aren't.
Not all older drive support burn-free, which could be one factor.
I haven't seen any clear correlation between age and vulnerability. Old Samsung SCR-2432 and SCR-3232 CD drives from 8-year old boxes aren't vulnerable.
Another thing to consider. I was told by Lite-On technical support people that DVD+R disks are more forgiving than DVD-R. I have certainly had fewer problems on my stand-alone recorder since changing to +R.
I've seen technical articles (which I don't fully understand) explaining the many reliability advantages of the plus format over the minus. I always use plus. It's no more expensive anyway.
Whether the DVD is RW or just R may also matter - as mentioned before I had the problem burning to a DVD+RW using growisofs (and I have enough experience with the media in question to know that its stability wasn't the problem). But burning to a DVD+R with growisofs seemed to work ok (though it could just have been luck). When F7 comes out I'll try growisofs with the DVD+R and cross my fingers. If that doesn't work I'll try finding a newer version of cdrecord and see if that works. I'd be interested in knowing if anyone out there can currently burn DVDs using the version of cdrecord in either FC6 or F7t4, and whether or not it spews error messages.
Yes, I've burned many DVDs under FC6. I use K3B, and have no problem at all.
Anne
But what about command-line cdrecord? K3B and other graphical tools all probably choose automatically between cdrecord and growisofs, and I'm guessing that with DVDs they always use growisofs.
On Wednesday 09 May 2007, Andre Robatino wrote:
But what about command-line cdrecord? K3B and other graphical tools all probably choose automatically between cdrecord and growisofs, and I'm guessing that with DVDs they always use growisofs.
I've never bothered with command-line burning - except once, but that's irrelevant. As you realise, I'm sure, k3b and others are simply front-ends for command-line tools. I was under the impression that it was necessary to use growisofs for DVDs, but I could be wrong :-)
Anne
Anne Wilson wrote:
On Wednesday 09 May 2007, Andre Robatino wrote:
But what about command-line cdrecord? K3B and other graphical tools all probably choose automatically between cdrecord and growisofs, and I'm guessing that with DVDs they always use growisofs.
I've never bothered with command-line burning - except once, but that's irrelevant. As you realise, I'm sure, k3b and others are simply front-ends for command-line tools. I was under the impression that it was necessary to use growisofs for DVDs, but I could be wrong :-)
Anne
Cdrecord is supposed to be able to burn DVDs, and I was able to use it for this until recently. If it was possible for me to get the desired padding using growisofs, I'd be happy with it. There was some kind of licensing incompatibility involving cdrecord a while back, so I believe a fork was necessary. I don't know if the FC6 version of cdrecord is before or after the fork, but that might be relevant.
On Wed, 2007-05-09 at 13:39 +0100, Anne Wilson wrote:
Another thing to consider. I was told by Lite-On technical support people that DVD+R disks are more forgiving than DVD-R. I have certainly had fewer problems on my stand-alone recorder since changing to +R.
According to the spiel about it, the wiggle to the track on the +R discs means that the laser can very easily find its location, and can start and stop burning at will. Contrarily, the -R discs have a simple spiral that's harder to track, and write stop and starts involve padding the ending and new start with something that's not data (so it can't do it instantly).
Think of it like driving a car blindly. You can either keep bouncing off the sides of the road, trying to keep in the middle. Or have rumble strips that run under the edges of your tires all the time that you're on track.
I just wish they'd sorted themselves out before foisting two different standards on us, and that they'd build better drives.
Tim wrote:
On Wed, 2007-05-09 at 13:39 +0100, Anne Wilson wrote:
Another thing to consider. I was told by Lite-On technical support people that DVD+R disks are more forgiving than DVD-R. I have certainly had fewer problems on my stand-alone recorder since changing to +R.
According to the spiel about it, the wiggle to the track on the +R discs means that the laser can very easily find its location, and can start and stop burning at will. Contrarily, the -R discs have a simple spiral that's harder to track, and write stop and starts involve padding the ending and new start with something that's not data (so it can't do it instantly).
Think of it like driving a car blindly. You can either keep bouncing off the sides of the road, trying to keep in the middle. Or have rumble strips that run under the edges of your tires all the time that you're on track.
I just wish they'd sorted themselves out before foisting two different standards on us, and that they'd build better drives.
http://www.cdfreaks.com/reviews/Why-DVDRW-is-superior-to-DVD-RW
Andre Robatino skrev:
When I burned the Fedora ISOs to CDs, I used cdrecord with padding to avoid the readahead bug - see
http://www.troubleshooters.com/linux/coasterless.htm
for how. In short, you use something like
cdrecord -v dev=/dev/cdrom -dao -pad padsize=63s FC-6-i386-disc1.iso
It turns out that the same precaution is necessary with DVDs, and until recently I was able to use cdrecord for this, like
cdrecord -v dev=/dev/dvd -dao -pad padsize=63s FC-6-i386-DVD.iso
even though a lot of ugly-looking error messages appeared before the burn commenced. But in the last month or so, instead of burning, cdrecord simply gives up. See
This is a very long shot, and probably misses the barn completely, but since you said that this change occured recently, I wonder if you experience the same thing as I do (also with recent isos).
If you burn the CD image and try to boot it, does the installer find the media after you tell it to install from 'Local CR-ROM'? (I use the x86_64 iso, so there might be a difference).
Frode
Frode Petersen wrote:
Andre Robatino skrev:
When I burned the Fedora ISOs to CDs, I used cdrecord with padding to avoid the readahead bug - see
http://www.troubleshooters.com/linux/coasterless.htm
for how. In short, you use something like
cdrecord -v dev=/dev/cdrom -dao -pad padsize=63s FC-6-i386-disc1.iso
It turns out that the same precaution is necessary with DVDs, and until recently I was able to use cdrecord for this, like
cdrecord -v dev=/dev/dvd -dao -pad padsize=63s FC-6-i386-DVD.iso
even though a lot of ugly-looking error messages appeared before the burn commenced. But in the last month or so, instead of burning, cdrecord simply gives up. See
This is a very long shot, and probably misses the barn completely, but since you said that this change occured recently, I wonder if you experience the same thing as I do (also with recent isos).
If you burn the CD image and try to boot it, does the installer find the media after you tell it to install from 'Local CR-ROM'? (I use the x86_64 iso, so there might be a difference).
Frode
The problem I'm referring to is only with DVDs, since cdrecord continues to work perfectly well with CDs. The first Fedora DVD ISO I burned was just a few months ago, after FC6 came out. I did some tests burning DVDs in various ways and running the equivalent of mediacheck (/usr/lib/anaconda-runtime/checkisomd5 from the anaconda-runtime package) but haven't done a DVD install yet. Of course it's possible to go back to burning half a dozen CDs as a last resort.
Andre Robatino skrev:
The problem I'm referring to is only with DVDs, since cdrecord continues to work perfectly well with CDs. The first Fedora DVD ISO I burned was just a few months ago, after FC6 came out. I did some tests burning DVDs in various ways and running the equivalent of mediacheck (/usr/lib/anaconda-runtime/checkisomd5 from the anaconda-runtime package) but haven't done a DVD install yet. Of course it's possible to go back to burning half a dozen CDs as a last resort.
And as I understand, the DVDs can't be burnt at all, so no similarity there. (BTW, the CD image I tried is FC-6-x86_64-boot.iso for internet install, but the normal DVD gave the same result.)
You have probably tested this already, but when I tried cdrecord, I had to use -dev=ATA:1,0,0 to specify the drive. It's an IDE DVD-burner.
Frode
| From: Andre Robatino andre@bwh.harvard.edu
| When I burned the Fedora ISOs to CDs, I used cdrecord with padding to avoid | the readahead bug - see | | http://www.troubleshooters.com/linux/coasterless.htm
Your analysis matches my understanding.
| 3) Find some other tool besides cdrecord that can do the necessary padding for | DVDs. Are there any?
I pad the iso file, burn the padded file, unpad the iso file, and then check to see if the burn worked.
You can use the command isosize(8) to find out how much of an image size is the actual iso9660 file system.
I wrote a utility that I use to pad (and unpad) an image file. I call it "isopad". It pads by 128k bytes of zero which has been enough for my systems.
To see if a burn worked, I just use cmp(1) to compare the contents of the dvd with the image. I only check the filesystem part: cmp --bytes `isosize whatever.ios` whatever.iso /dev/hdc This uses the cmp(1) --bytes flag which is handy but not in the man page.
================ isopad ================ #!/bin/sh
# isopad [+] [-] isofile... # # The Linux IDE CD driver in 2.6 tries to read ahead, even past the end of the # CD or DVD. Even when the program issuing the original read request was only # trying to read legitimate parts of the disc (albeit near the end). # The result is spurious I/O errors and read failures. # It does not seem that this driver bug is going to be fixed soon. # # This program is intended to facilitate a workaround. It can pad (or unpad) # a .iso file so that, when it is burned, the resulting disc will allow # reads past the end of the content to succeed. # # "+" means pad the following .iso files. # "-" means remove all padding. # neither means test file and iso sizes. # # To see how much readahead is enabled on a drive: hdparm -a /dev/hdc # # Why do the padding in place, rather than on a copy of the file? # .iso files are usually quite large so copying takes a lot of time and space. # # Copyright 2005 D. Hugh Redelmeier # License: GPL # Version: Sat Jun 18 02:31:48 EDT 2005
# stop at the least sign of trouble set -u -e
# op is "", "-", or "+": operation to be performed op=""
for fn do case "$fn" in "-h"|"--help") echo "Usage: $0 [-|+|] isofile..." ;; "+"|"-") op="$fn" ;; *) isosize -x "$fn" isz=`isosize "$fn"` fsz=`stat --format='%s' "$fn"`
# conventional block size for CDs bs=2048
# my guess at a sufficient amount of padding (in blocks) pb=64
if [ $fsz -lt $isz ] then echo "$fn is shorter ($fsz) than it should be ($isz)" >&2 exit 3 elif [ ` expr $fsz % $bs ` -ne 0 ] then echo "$fn file size ($fsz) is not a multiple of $bs" >&2 exit 4 elif [ ` expr $isz % $bs ` -ne 0 ] then echo "$fn isosize ($isz) is not a multiple of $bs" >&2 exit 5 else case "$op" in "") if [ $fsz -eq $isz ] then echo "$fn: isosize == file size == $fsz" else echo "$fn: isosize $isz; file size $fsz" fi ;; "+") echo "$fn: padding with $pb blocks of $bs zero bytes" dd if=/dev/zero bs=$bs count=$pb >>"$fn" ;; "-") if [ $fsz -eq $isz ] then echo "$fn: already $fsz bytes" else echo "$fn: truncating from $fsz to $isz bytes" dd if=/dev/null of="$fn" seek=$isz bs=1 fi ;; esac fi ;; esac done ================ end isopad ================
On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| From: Andre Robatino andre@bwh.harvard.edu | | When I burned the Fedora ISOs to CDs, I used cdrecord with padding to | avoid the readahead bug - see | | http://www.troubleshooters.com/linux/coasterless.htm
Your analysis matches my understanding.
| 3) Find some other tool besides cdrecord that can do the necessary padding | for DVDs. Are there any?
I pad the iso file, burn the padded file, unpad the iso file, and then check to see if the burn worked.
You can use the command isosize(8) to find out how much of an image size is the actual iso9660 file system.
I wrote a utility that I use to pad (and unpad) an image file. I call it "isopad". It pads by 128k bytes of zero which has been enough for my systems.
To see if a burn worked, I just use cmp(1) to compare the contents of the dvd with the image. I only check the filesystem part: cmp --bytes `isosize whatever.ios` whatever.iso /dev/hdc This uses the cmp(1) --bytes flag which is handy but not in the man page.
================ isopad ================ #!/bin/sh
# isopad [+] [-] isofile... # # The Linux IDE CD driver in 2.6 tries to read ahead, even past the end of the # CD or DVD. Even when the program issuing the original read request was only # trying to read legitimate parts of the disc (albeit near the end). # The result is spurious I/O errors and read failures. # It does not seem that this driver bug is going to be fixed soon. # # This program is intended to facilitate a workaround. It can pad (or unpad) # a .iso file so that, when it is burned, the resulting disc will allow # reads past the end of the content to succeed. # # "+" means pad the following .iso files. # "-" means remove all padding. # neither means test file and iso sizes. # # To see how much readahead is enabled on a drive: hdparm -a /dev/hdc # # Why do the padding in place, rather than on a copy of the file? # .iso files are usually quite large so copying takes a lot of time and space. # # Copyright 2005 D. Hugh Redelmeier # License: GPL # Version: Sat Jun 18 02:31:48 EDT 2005
# stop at the least sign of trouble set -u -e
# op is "", "-", or "+": operation to be performed op=""
for fn do case "$fn" in "-h"|"--help") echo "Usage: $0 [-|+|] isofile..." ;; "+"|"-") op="$fn" ;; *) isosize -x "$fn" isz=`isosize "$fn"` fsz=`stat --format='%s' "$fn"`
# conventional block size for CDs bs=2048 # my guess at a sufficient amount of padding (in blocks) pb=64 if [ $fsz -lt $isz ] then echo "$fn is shorter ($fsz) than it should be ($isz)" >&2 exit 3 elif [ ` expr $fsz % $bs ` -ne 0 ] then echo "$fn file size ($fsz) is not a multiple of $bs" >&2 exit 4 elif [ ` expr $isz % $bs ` -ne 0 ] then echo "$fn isosize ($isz) is not a multiple of $bs" >&2 exit 5 else case "$op" in "") if [ $fsz -eq $isz ] then echo "$fn: isosize == file size == $fsz" else echo "$fn: isosize $isz; file size $fsz" fi ;; "+") echo "$fn: padding with $pb blocks of $bs zero bytes" dd if=/dev/zero bs=$bs count=$pb >>"$fn" ;; "-") if [ $fsz -eq $isz ] then echo "$fn: already $fsz bytes" else echo "$fn: truncating from $fsz to $isz bytes" dd if=/dev/null of="$fn" seek=$isz bs=1 fi ;; esac fi ;;esac done ================ end isopad ================
I'm totally bumfuzzled here folks, what with all this talk of padding etc. AIUI, by definition, the iso IS an image of the disk, in the cases I've played with, I have never ever come across an iso that had a mod%2048 of other than zero, 2048 being the block size of the iso9660 file system.
And, in every case where a cd or dvd failed the k3b verify phase, I have been able to grab a copy of kcalc, divide the size of the .iso as it exists on my hard drive by 2048 to obtain a 'block count', at which point a
dd if=/dev/cdrom BS=2048 count=the_count_above >md5sum
and the result except for one occasion where my burner was actually doing an exit stage left, a perfect md5sum for the disk, exactly the same as the hard drive file.
And the disk of course Just Worked(TM)
So whats all this 'padding' for anyway? AIUI, any padding would break the iso9660 file format except that it might be properly ignored due to being completely beyond the the reach of the filesystems ken.
| From: Gene Heskett gene.heskett@verizon.net
[It is good style to quote only relevant parts of a message to which you are replying.]
| I'm totally bumfuzzled here folks, what with all this talk of padding etc. | AIUI, by definition, the iso IS an image of the disk, in the cases I've played | with, I have never ever come across an iso that had a mod%2048 of other than | zero, 2048 being the block size of the iso9660 file system.
That is normal. Sun used to use blocksizes of 512 on CDs but I don't know that they ever used them for iso9660 file systems.
| And, in every case where a cd or dvd failed the k3b verify phase, I have been | able to grab a copy of kcalc, divide the size of the .iso as it exists on my | hard drive by 2048 to obtain a 'block count', at which point a | | dd if=/dev/cdrom BS=2048 count=the_count_above >md5sum | | and the result except for one occasion where my burner was actually doing an | exit stage left, a perfect md5sum for the disk, exactly the same as the hard | drive file.
1. just because your DVD reader works this way does not mean that other people's DVD reader works this way. This has been reported by several folks in this mailing list.
2. the dd you use will produce a file called "md5sum" that contains the image of the disk (with luck) and not the hash.
| And the disk of course Just Worked(TM) | | So whats all this 'padding' for anyway? AIUI, any padding would break the | iso9660 file format except that it might be properly ignored due to being | completely beyond the the reach of the filesystems ken.
Padding does not break an iso9660 filesystem. It contains information about its extent. That's what makes isosize(8) possible. Of course there is a chance that padding might cause the image to be too big for the medium.
It has been explained in this thread: the Linux driver tries to read ahead past the legitimate content on the DVD. Then it reports I/O errors when the drive refuses. This is only observed with some hardware.
As I understand it (I've not checked), the driver does a READ CAPACITY command on the drive and feels it can read ahead up until that size. The problem is that on some drives READ CAPACITY does not yield the precise result needed. It is unknown to me whether the ATAPI specs require READ CAPACITY to yield what Linux is assuming. In other words, I know that there is a bug but I don't know whether it is the Linux kernel or the drives that are not following the standards.
The padding is to allow Linux to read past the end of the filesystem without encountering I/O errors.
How would I like this problem addressed?
- Linux should ignore errors in a read-ahead block unless and until the "client" actually tries to read the block
- there should be an ioctl to let a program override the information provided by READ CAPACITY
- drives should implement READ CAPACITY accurately
- growisofs should accept the pad flag as direction to write padding after an image.
- .iso providers (eg. Fedora) should consider padding images them so the unfortunate customers don't need to know this lore
On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| From: Gene Heskett gene.heskett@verizon.net
[It is good style to quote only relevant parts of a message to which you are replying.]
| I'm totally bumfuzzled here folks, what with all this talk of padding etc. | AIUI, by definition, the iso IS an image of the disk, in the cases I've | played with, I have never ever come across an iso that had a mod%2048 of | other than zero, 2048 being the block size of the iso9660 file system.
That is normal. Sun used to use blocksizes of 512 on CDs but I don't know that they ever used them for iso9660 file systems.
I didn't know there were cd writers that could write that small a block still extant on the planet. I think I may have a scsi based 4x Hitachi drive in the basement that dates back to around 1997 that might, if it still works. Amazing...
| And, in every case where a cd or dvd failed the k3b verify phase, I have | been able to grab a copy of kcalc, divide the size of the .iso as it | exists on my hard drive by 2048 to obtain a 'block count', at which point | a | | dd if=/dev/cdrom BS=2048 count=the_count_above >md5sum | | and the result except for one occasion where my burner was actually doing | an exit stage left, a perfect md5sum for the disk, exactly the same as the | hard drive file.
- just because your DVD reader works this way does not mean that other
people's DVD reader works this way. This has been reported by several folks in this mailing list.
I've had lousy luck with optical drives here up until I got a dual layer lightscribe model about 6 months back, but that method did work for the previous 3 drives I had in that slot of a very large tower case. As long as the drive was working that is, I had 1 that only burnt one disk, but because I wasn't using nero on a winderz box they wouldn't warranty it. That's twice now that Memorex has screwed me. But that is not germain to this...
- the dd you use will produce a file called "md5sum" that contains
the image of the disk (with luck) and not the hash.
Its been so long since I had to do that that I may miss-remember and used a pipe instead of a redirect. In any event whatever symbol I did use at the time resulted in md5sum outputting a valid md5sum of the file fed to it.
| And the disk of course Just Worked(TM) | | So whats all this 'padding' for anyway? AIUI, any padding would break the | iso9660 file format except that it might be properly ignored due to being | completely beyond the the reach of the filesystems ken.
Padding does not break an iso9660 filesystem. It contains information about its extent. That's what makes isosize(8) possible. Of course there is a chance that padding might cause the image to be too big for the medium.
Padding in the context that I might use it in, would be the equ of sending several kilobytes of /dev/zero >>name_of_iso file. If you are adding data of some kind for use with an iso wrapper, then to me its not padding but data. Data the iso filesystem can't see when its mounted, but data none the less.
It has been explained in this thread: the Linux driver tries to read ahead past the legitimate content on the DVD. Then it reports I/O errors when the drive refuses. This is only observed with some hardware.
And I might point out, some older kernel versions. IIRC that was fixed back at about 2.6.17 or so, but I don't have a handy bible to swear on as to the exact version so I won't argue the point.
As I understand it (I've not checked), the driver does a READ CAPACITY command on the drive and feels it can read ahead up until that size. The problem is that on some drives READ CAPACITY does not yield the precise result needed. It is unknown to me whether the ATAPI specs require READ CAPACITY to yield what Linux is assuming. In other words, I know that there is a bug but I don't know whether it is the Linux kernel or the drives that are not following the standards.
That's one of the reasons, the main one in fact, for burner stuffs like k3b ejecting the disk and reloading it before they start a verify, this is to force the drive/driver to re-read the disk and update the data. Now if the driver doesn't believe the drive/disk when it says there is only 609 megs of data on a 700 meg disk, then one or the other is out of spec.
The padding is to allow Linux to read past the end of the filesystem without encountering I/O errors.
How would I like this problem addressed?
- Linux should ignore errors in a read-ahead block unless and until
the "client" actually tries to read the block
Agreed.
- there should be an ioctl to let a program override the information
provided by READ CAPACITY
And just where would it get the data to override what READ CAPACITY returns?
- drives should implement READ CAPACITY accurately
Amen, but I believe they are getting better in that regard.
- growisofs should accept the pad flag as direction to write padding
after an image.
That's a crutch IMO, but if it saves a broken drive that would otherwise LOOK as if it had burned a coaster until such time as the laser turns up its toes, I suppose it is usable.
- .iso providers (eg. Fedora) should consider padding images them so
the unfortunate customers don't need to know this lore
Why? If it demonstrates to the user that his drive/driver is a bit duff and bears carefull watching, eventually one or the other will get fixed.
An interesting discussion this, thanks.
| From: Gene Heskett gene.heskett@verizon.net
| On Saturday 12 May 2007, D. Hugh Redelmeier wrote: | >| From: Gene Heskett gene.heskett@verizon.net | > | >[It is good style to quote only relevant parts of a message to which | >you are replying.]
| > Sun used to use blocksizes of 512 on CDs but I don't | >know that they ever used them for iso9660 file systems. | | I didn't know there were cd writers that could write that small a block still | extant on the planet. I think I may have a scsi based 4x Hitachi drive in | the basement that dates back to around 1997 that might, if it still works. | Amazing...
Sun machines originally could only boot from CD drives that defaulted to 512 byte blocks. So when I bought my Sparc Classic in 1993, I had to spend $1000 on a Sun CD drive (1x!). A little later I got a 3x NEC CD drive that could do this (under control of a DIP switch).
| I've had lousy luck with optical drives here up until I got a dual layer | lightscribe model about 6 months back, but that method did work for the | previous 3 drives I had in that slot of a very large tower case. As long as | the drive was working that is, I had 1 that only burnt one disk, but because | I wasn't using nero on a winderz box they wouldn't warranty it. That's twice | now that Memorex has screwed me. But that is not germain to this...
One hopes that newer drives are better. But they might just be less expensive and cheaper.
I have had several drives that seemed to need padding. I have not kept good notes.
The 2.4 kernel + ide-scsi (remember that?) seemed to behave better. That's why I think that the kernel is implicated.
Note that my technique has solved the original poster's problem. So it is at least on the right track.
| Its been so long since I had to do that that I may miss-remember and used a | pipe instead of a redirect. In any event whatever symbol I did use at the | time resulted in md5sum outputting a valid md5sum of the file fed to it.
dd if=/dev/cdrom BS=2048 count=the_count_above | md5sum
I have used this technique (|, not >) but not recently. Piping a whole CD's worth of stuff had a horrible impact on the Linux box's performance. I imagine that it displaced all the useful content from the system's buffer cache. Some bad kernel policies: it should be obvious that the content of a pipe should be discarded after it is consumed.
| >Padding does not break an iso9660 filesystem. It contains information | >about its extent. That's what makes isosize(8) possible. Of course | >there is a chance that padding might cause the image to be too big for | >the medium. | | Padding in the context that I might use it in, would be the equ of sending | several kilobytes of /dev/zero >>name_of_iso file. If you are adding data of | some kind for use with an iso wrapper, then to me its not padding but data. | Data the iso filesystem can't see when its mounted, but data none the less.
What is "an iso wrapper"?
There are layers of representation. Kind of like layers in networking. Inside the .iso is a filesystem conforming to ISO 9660. Inside that are files. Inside them are...
A .iso file is something to dump on a writeable drive. Other things are added to the burn, before and after either by the sofware or the firmware. I refuse to learn all the stuff in the various standards -- too much information that I don't need. But there is no rule that says adding zero bytes to the end of a .iso is wrong.
| And I might point out, some older kernel versions. IIRC that was fixed back | at about 2.6.17 or so, but I don't have a handy bible to swear on as to the | exact version so I won't argue the point.
Actually, the kernel got worse in this respect when ide-scsi was dumped. I don't know of improvement since. Since you don't observe the problem, how would you know?
| >As I understand it (I've not checked), the driver does a READ CAPACITY | >command on the drive and feels it can read ahead up until that size. | >The problem is that on some drives READ CAPACITY does not yield the | >precise result needed. It is unknown to me whether the ATAPI specs | >require READ CAPACITY to yield what Linux is assuming. In other | >words, I know that there is a bug but I don't know whether it is the | >Linux kernel or the drives that are not following the standards. | | That's one of the reasons, the main one in fact, for burner stuffs like k3b | ejecting the disk and reloading it before they start a verify, this is to | force the drive/driver to re-read the disk and update the data. Now if the | driver doesn't believe the drive/disk when it says there is only 609 megs of | data on a 700 meg disk, then one or the other is out of spec.
You assert this, but I suspect that you've never read the standard documents. I'm sure folks have mentioned the problem to drive makers and no fix has been forthcoming.
READ CAPACITY was invented for SCSI fixed disks. In that context, it is like getting the disk sizes from hdparam. Transferring this concept efficiently to CDROMs might not be feasible -- would you want the drive to actually have to read to the end of the burned data to find out how much there is?
I very carefully said that I expect either the Kernel or the drives are wrong. I half expect that the ATAPI standard isn't clear on this. In which case, the Kernel is wrong for assuming too much.
| >How would I like this problem addressed?
| >- there should be an ioctl to let a program override the information | > provided by READ CAPACITY | | And just where would it get the data to override what READ CAPACITY returns?
The program could get the size the way isosize(8) does. I'd write a utility that takes the isosize output and uses it to issue the ioctl. Perhaps the Fedora installation code would do the same.
| >- drives should implement READ CAPACITY accurately | | Amen, but I believe they are getting better in that regard.
I don't have any data on this and I'm sure that you don't (since you've never observed the problem).
| >- growisofs should accept the pad flag as direction to write padding | > after an image. | | That's a crutch IMO, but if it saves a broken drive that would otherwise LOOK | as if it had burned a coaster until such time as the laser turns up its toes, | I suppose it is usable.
It is a pragmatic approach. The principled approach is to go read the standards and bash the appropriate party over the head with them until that party reforms.
| >- .iso providers (eg. Fedora) should consider padding images them so | > the unfortunate customers don't need to know this lore | | Why? If it demonstrates to the user that his drive/driver is a bit duff and | bears carefull watching, eventually one or the other will get fixed.
Drives don't get fixed. Quite the opposite: they eventually break seriously and get replaced.
Anyway, it is a small concession to a real problem in the real world. I wonder how many folks have given up on Linux when their first experience is with being unable to verify the installation disk. This stuff is really really arcane and saving users from having to understand it is a useful goal.
Every time there is a new release of Fedora, I think there are a few people on this list that say that they cannot seem to burn a disk that verifies. How many just give up without knowing to ask here? How many who do ask get told the right advice?
On Sunday 13 May 2007, D. Hugh Redelmeier wrote:
| From: Gene Heskett gene.heskett@verizon.net | | On Saturday 12 May 2007, D. Hugh Redelmeier wrote: | >| From: Gene Heskett gene.heskett@verizon.net | > | >[It is good style to quote only relevant parts of a message to which | >you are replying.] | > | > Sun used to use blocksizes of 512 on CDs but I don't | >know that they ever used them for iso9660 file systems. | | I didn't know there were cd writers that could write that small a block | still extant on the planet. I think I may have a scsi based 4x Hitachi | drive in the basement that dates back to around 1997 that might, if it | still works. Amazing...
Sun machines originally could only boot from CD drives that defaulted to 512 byte blocks. So when I bought my Sparc Classic in 1993, I had to spend $1000 on a Sun CD drive (1x!). A little later I got a 3x NEC CD drive that could do this (under control of a DIP switch).
| I've had lousy luck with optical drives here up until I got a dual layer | lightscribe model about 6 months back, but that method did work for the | previous 3 drives I had in that slot of a very large tower case. As long | as the drive was working that is, I had 1 that only burnt one disk, but | because I wasn't using nero on a winderz box they wouldn't warranty it. | That's twice now that Memorex has screwed me. But that is not germain to | this...
One hopes that newer drives are better. But they might just be less expensive and cheaper.
I have had several drives that seemed to need padding. I have not kept good notes.
The 2.4 kernel + ide-scsi (remember that?) seemed to behave better. That's why I think that the kernel is implicated.
Note that my technique has solved the original poster's problem. So it is at least on the right track.
| Its been so long since I had to do that that I may miss-remember and used | a pipe instead of a redirect. In any event whatever symbol I did use at | the time resulted in md5sum outputting a valid md5sum of the file fed to | it.
dd if=/dev/cdrom BS=2048 count=the_count_above | md5sum
I have used this technique (|, not >) but not recently. Piping a whole CD's worth of stuff had a horrible impact on the Linux box's performance. I imagine that it displaced all the useful content from the system's buffer cache. Some bad kernel policies: it should be obvious that the content of a pipe should be discarded after it is consumed.
| >Padding does not break an iso9660 filesystem. It contains information | >about its extent. That's what makes isosize(8) possible. Of course | >there is a chance that padding might cause the image to be too big for | >the medium. | | Padding in the context that I might use it in, would be the equ of sending | several kilobytes of /dev/zero >>name_of_iso file. If you are adding data | of some kind for use with an iso wrapper, then to me its not padding but | data. Data the iso filesystem can't see when its mounted, but data none | the less.
What is "an iso wrapper"?
There are layers of representation. Kind of like layers in networking. Inside the .iso is a filesystem conforming to ISO 9660. Inside that are files. Inside them are...
A .iso file is something to dump on a writeable drive. Other things are added to the burn, before and after either by the sofware or the firmware. I refuse to learn all the stuff in the various standards -- too much information that I don't need. But there is no rule that says adding zero bytes to the end of a .iso is wrong.
| And I might point out, some older kernel versions. IIRC that was fixed | back at about 2.6.17 or so, but I don't have a handy bible to swear on as | to the exact version so I won't argue the point.
Actually, the kernel got worse in this respect when ide-scsi was dumped. I don't know of improvement since. Since you don't observe the problem, how would you know?
| >As I understand it (I've not checked), the driver does a READ CAPACITY | >command on the drive and feels it can read ahead up until that size. | >The problem is that on some drives READ CAPACITY does not yield the | >precise result needed. It is unknown to me whether the ATAPI specs | >require READ CAPACITY to yield what Linux is assuming. In other | >words, I know that there is a bug but I don't know whether it is the | >Linux kernel or the drives that are not following the standards. | | That's one of the reasons, the main one in fact, for burner stuffs like | k3b ejecting the disk and reloading it before they start a verify, this is | to force the drive/driver to re-read the disk and update the data. Now if | the driver doesn't believe the drive/disk when it says there is only 609 | megs of data on a 700 meg disk, then one or the other is out of spec.
You assert this, but I suspect that you've never read the standard documents. I'm sure folks have mentioned the problem to drive makers and no fix has been forthcoming.
READ CAPACITY was invented for SCSI fixed disks. In that context, it is like getting the disk sizes from hdparam. Transferring this concept efficiently to CDROMs might not be feasible -- would you want the drive to actually have to read to the end of the burned data to find out how much there is?
I very carefully said that I expect either the Kernel or the drives are wrong. I half expect that the ATAPI standard isn't clear on this. In which case, the Kernel is wrong for assuming too much.
The atapi std I think isn't what we should be talking about. I believe the applicable document is known as the "Orange Book"? And some of it is because a legal copy of it costs a lot of real USA $ money. Standard bodies get their income from the publishing of very well protected documents. I've not seen a quote for the Orange book, but one I did inquire about several years ago (USB IIRC) was a cool kilobuck, at which point I had a rather profound loss of interest in pursuing that path any farther.
| >How would I like this problem addressed? | > | >- there should be an ioctl to let a program override the information | > provided by READ CAPACITY | | And just where would it get the data to override what READ CAPACITY | returns?
The program could get the size the way isosize(8) does. I'd write a utility that takes the isosize output and uses it to issue the ioctl. Perhaps the Fedora installation code would do the same.
| >- drives should implement READ CAPACITY accurately | | Amen, but I believe they are getting better in that regard.
I don't have any data on this and I'm sure that you don't (since you've never observed the problem).
I think I have, but didn't recognize it other than a "this damned thing ain't workin" observation. :) Since buying this one I haven't had any seemingly similar to this problems. OTOH, ISTR I also upgraded the burner soft to the new non-schily cdtools, which could also have solved the problem.
| >- growisofs should accept the pad flag as direction to write padding | > after an image. | | That's a crutch IMO, but if it saves a broken drive that would otherwise | LOOK as if it had burned a coaster until such time as the laser turns up | its toes, I suppose it is usable.
It is a pragmatic approach. The principled approach is to go read the standards and bash the appropriate party over the head with them until that party reforms.
Got an address? I'd like to send Vinny and Luigi around to have a chat with them.
| >- .iso providers (eg. Fedora) should consider padding images them so | > the unfortunate customers don't need to know this lore | | Why? If it demonstrates to the user that his drive/driver is a bit duff | and bears carefull watching, eventually one or the other will get fixed.
Drives don't get fixed. Quite the opposite: they eventually break seriously and get replaced.
That was what I was saying, rather tongue-in-cheek. In my case a couple of times I've retired the drive when it could still make visible tracks on the disk. It still reads other drives disks ok, but it can't read what it wrote.
Anyway, it is a small concession to a real problem in the real world. I wonder how many folks have given up on Linux when their first experience is with being unable to verify the installation disk. This stuff is really really arcane and saving users from having to understand it is a useful goal.
Agreed and amen.
Every time there is a new release of Fedora, I think there are a few people on this list that say that they cannot seem to burn a disk that verifies. How many just give up without knowing to ask here? How many who do ask get told the right advice?
An excellent question, and one that we will never have more than a SWAG number to put in front of the % sign because they won't know enough to come here and ask. And everytime it happens, its another black mark against linux in the potential users eyes.
I used the isopad utility to pad a copy of the FC6 DVD ISO, then burned it to a DVD+RW (the same media I had trouble with before) with growisofs, then ran some tests. It works! It's strange since isopad appears to use dd to add the padding, and I mentioned in my original message that when I did this manually, the resulting discs failed to boot properly (even though they passed mediacheck if I swapped them in after booting from a different install disc). There must have been something wrong with my procedure. Anyway, this eliminates the need for cdrecord for DVDs. Thanks again.
| From: D. Hugh Redelmeier hugh@mimosa.com
| 1. just because your DVD reader works this way does not mean that other | people's DVD reader works this way. This has been reported by several | folks in this mailing list.
Another data point or two.
I just burned the Fedora-7-x86_64/F-7-x86_64-DVD.iso on one of my desktops, without padding. The system is running Fedora Core 4 x86_64.
Checking failed on the same drive that burned it. It failed with I/O errors at high sectors (the messages are not completely clear but they indicate sectors very near the end but inside the written zone): hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 6734304 printk: 22 messages suppressed. Buffer I/O error on device hdc, logical block 841788 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 6734312 ...
The isosize is 3447975936 which means that there are 6734328 sectors if you pretend that they are 512 bytes (as is to be expected, isosize says that the actual sector size is 2048).
The drive is IDE. hdparm says about it: # /sbin/hdparm -i /dev/hdc
/dev/hdc:
Model=HP DVD Writer 400, FwRev=KH27, SerialNo=MYHC09 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic } RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=0kB, MaxMultSect=0 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0 IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 AdvancedPM=no Drive conforms to: device does not report version:
* signifies the current active mode
The same disk, as burned in the first drive, checks out fine when tested in a second drive. This drive is an external USB drive on the same computer. That drive is OEMed NEC that has been rebadged by Mad Dog: Vendor: MAD DOG Model: MD-16XDVD9A4 Rev: 1.F2 Type: CD-ROM ANSI SCSI revision: 00
I have no idea whether the improved behaviour is due to a different drive or using the SCSI/USB driver instead of the IDE driver.
From past experience, I'm sure that padding would have avoided this problem.
PS: I checked using the commands: cmp --bytes 3447975936 Fedora-7-x86_64/F-7-x86_64-DVD.iso /dev/hdc cmp --bytes 3447975936 Fedora-7-x86_64/F-7-x86_64-DVD.iso /dev/scd0
-
Andre Robatino -
Anne Wilson -
D. Hugh Redelmeier -
Frode Petersen -
Gene Heskett -
Rick Stevens -
Tim