1:37 a.m.
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?
11:33 a.m.
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:
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?
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(a)internap.com -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- To iterate is human, to recurse, divine. -
----------------------------------------------------------------------
3:09 p.m.
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:
>
> 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?
>
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.
3:24 a.m.
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.iso
with 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.
--
(This box runs FC6, my others run FC4 & FC5, in case that's
important to the thread.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
6:58 a.m.
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.iso
>
> with 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.
7:02 a.m.
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.iso
>>
>> with 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.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The course of true anything never does run smooth.
-- Samuel Butler
7:39 a.m.
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
7:52 a.m.
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.
8:09 a.m.
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
8:38 a.m.
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.
9:24 a.m.
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.
--
(This box runs FC5, my others run FC4 & FC6, in case that's
important to the thread.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
9:55 a.m.
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
10:01 a.m.
New subject: Side topic to: How to burn Fedora DVDs to avoid readahead bug?
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
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233745
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
10:09 a.m.
New subject: Side topic to: How to burn Fedora DVDs to avoid readahead bug?
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
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233745
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.
10:33 a.m.
New subject: Side topic to: How to burn Fedora DVDs to avoid readahead bug?
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
8:32 p.m.
| From: Andre Robatino <andre(a)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 ================
9:12 p.m.
On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| From: Andre Robatino <andre(a)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.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Call me bored, but don't call me boring.
-- Larry Wall in <199705101952.MAA00756(a)wall.org>
10:03 p.m.
| From: Gene Heskett <gene.heskett(a)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
11:12 p.m.
On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| From: Gene Heskett <gene.heskett(a)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.
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.
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...
2. 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.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Q: What is printed on the bottom of beer bottles in Minnesota?
A: Open other end.
11:15 p.m.
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.
7:02 p.m.
| From: Gene Heskett <gene.heskett(a)verizon.net>
| On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| >| From: Gene Heskett <gene.heskett(a)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?
8:40 p.m.
On Sunday 13 May 2007, D. Hugh Redelmeier wrote:
| From: Gene Heskett <gene.heskett(a)verizon.net>
|
| On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| >| From: Gene Heskett <gene.heskett(a)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.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Pauca sed matura.
[Few but excellent.]
-- Gauss
2:59 p.m.
| From: D. Hugh Redelmeier <hugh(a)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
6201
days inactive
6227
days old
22 comments
7 participants
participants (7)
-
Andre Robatino -
Anne Wilson -
D. Hugh Redelmeier -
Frode Petersen -
Gene Heskett -
Rick Stevens -
Tim