7:46 a.m.
Greetings all,
I have downloaded the FC5 isos and, after
burning the first one, I found that the media
check failed when I booted.
[...]
I had the same problem on my FC3 disks. But during a long google session
that lead down a dirt road and an abondoned farm, I found this...
When booting the CD, at the the prompt, type "linux mediacheck
ide=nodma". This has always results in a succesful check for me. But
remember, I've only used it on FC3 disks.
Rocco
2:55 p.m.
New subject: Testing iso downloads?
LinuxMedia wrote:
> Greetings all,
> I have downloaded the FC5 isos and, after
> burning the first one, I found that the media
> check failed when I booted.
[...]
I had the same problem on my FC3 disks. But during a long google session
that lead down a dirt road and an abondoned farm, I found this...
When booting the CD, at the the prompt, type "linux mediacheck
ide=nodma". This has always results in a succesful check for me. But
remember, I've only used it on FC3 disks.
This is a well-known kernel problem of long standing.
Any time use of a CDROM drive is flakey, try turning
off DMA.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
3:19 p.m.
New subject: Testing iso downloads?
On Fri, 2006-04-28 at 14:55 -0500, Mike McCarty wrote:
LinuxMedia wrote:
> > Greetings all,
> > I have downloaded the FC5 isos and, after
> > burning the first one, I found that the media
> > check failed when I booted.
> [...]
>
> I had the same problem on my FC3 disks. But during a long google session
> that lead down a dirt road and an abondoned farm, I found this...
>
> When booting the CD, at the the prompt, type "linux mediacheck
> ide=nodma". This has always results in a succesful check for me. But
> remember, I've only used it on FC3 disks.
This is a well-known kernel problem of long standing.
Yep:
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00455.html
Any time use of a CDROM drive is flakey, try turning
off DMA.
Doesn't always help:
http://www.redhat.com/archives/rhl-devel-list/2006-March/msg01191.html
Paul.
4:09 p.m.
New subject: Testing iso downloads?
Paul Howarth wrote:
On Fri, 2006-04-28 at 14:55 -0500, Mike McCarty wrote:
>
>This is a well-known kernel problem of long standing.
Yep:
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00455.html
>Any time use of a CDROM drive is flakey, try turning
>off DMA.
Doesn't always help:
Didn't say it did. I said it was worth a try.
[snip]
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
1:56 a.m.
New subject: Testing iso downloads?
| From: Paul Howarth <paul(a)city-fan.org>
You and I have talked about this in the past:
http://lists.debian.org/cdwrite/2005/06/msg00064.html
My bad experiences have been due to the CD driver reading past the end
of the burned part of the CD and getting all huffy when it doesn't
like what it sees.
The cure that has worked for me is to pad the .iso with zero blocks.
Then the driver can read that stuff without getting indigestion.
I've enclosed a script that I call "isopad". You can use it to add
padding (isopad + x.iso), remove padding (isopad - x.iso), or report
padding (isopad x.iso).
NOTE: this adds and removes padding to your .iso file in-place. This
saves a lot of disk space and file copying but it is rather daring.
How do you use this program?
# pad:
isopad + x.iso
# burn:
cdrecord ... x.iso
# remove padding:
isopad - x.iso
You can replace cdrecord with your favourite program.
md5sum for the script:
5ac2ec3d11e4079d400abaebc22587bf bin/isopad
================ start of isopad script ================
#!/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 ================
4:09 a.m.
New subject: Testing iso downloads?
On Saturday 29 April 2006 02:56, D. Hugh Redelmeier wrote:
| From: Paul Howarth <paul(a)city-fan.org>
You and I have talked about this in the past:
http://lists.debian.org/cdwrite/2005/06/msg00064.html
My bad experiences have been due to the CD driver reading past the end
of the burned part of the CD and getting all huffy when it doesn't
like what it sees.
The cure that has worked for me is to pad the .iso with zero blocks.
Then the driver can read that stuff without getting indigestion.
I've enclosed a script that I call "isopad". You can use it to add
padding (isopad + x.iso), remove padding (isopad - x.iso), or report
padding (isopad x.iso).
NOTE: this adds and removes padding to your .iso file in-place. This
saves a lot of disk space and file copying but it is rather daring.
How do you use this program?
# pad:
isopad + x.iso
# burn:
cdrecord ... x.iso
# remove padding:
isopad - x.iso
You can replace cdrecord with your favourite program.
md5sum for the script:
5ac2ec3d11e4079d400abaebc22587bf bin/isopad
================ start of isopad script ================
#!/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 ================
I thought "Hey, this should be neat", and proceeded to copy/paste it
into a file called /usr/sbin/isopad. Unforch although the copy/paste
seems to be perfect, the md5sum I get on this isn't the same as yours.
I included a linefeed after the word 'done' is the only place I can see
that might be different.
Running it on my directory full of FC5 cd sized iso's with the + option
first seemed to be ok, and with the - option it restored them to where
the sha1sum was good again, but the sha1sum failed on all files while
the padding was in effect. This is not on the actual burnt cd of
course. Should it be expected to fail when treating .iso's resideing
on an ide hard drive?
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
2:07 p.m.
New subject: Testing iso downloads?
| From: Gene Heskett <gene.heskett(a)verizon.net>
[It is always a good idea to trim quotes.]
| I thought "Hey, this should be neat", and proceeded to copy/paste it
| into a file called /usr/sbin/isopad. Unforch although the copy/paste
| seems to be perfect, the md5sum I get on this isn't the same as yours.
| I included a linefeed after the word 'done' is the only place I can see
| that might be different.
Darn. Mail is a lousy transport. I guess I should make it available
another way.
ftp://ftp.cs.utoronto.ca/pub/hugh/isopad
BTW, the copy I got back from the list does have the correct sum. So
your mailer is where stuff is being munged. Cut-and-paste, using X,
often mangles whitespace. The version you quoted has mangled
whitespace -- all indentation in the original is via HT characters
(Horizontal Tab).
| Running it on my directory full of FC5 cd sized iso's with the + option
| first seemed to be ok, and with the - option it restored them to where
| the sha1sum was good again, but the sha1sum failed on all files while
| the padding was in effect. This is not on the actual burnt cd of
| course. Should it be expected to fail when treating .iso's resideing
| on an ide hard drive?
Yes, it should give a different value for a padded file. The whole
point of a hash is to detect any change.
What should be true is that the first `isosize x.iso` bytes should be
the same and therefore the hash of those bytes should be the same.
This is what the CD testing should be looking at.
I've enclosed another script. I call it isoburn. It can burn a DVD
or CD but it needs to be told which because it uses growisofs or
cdrecord depending on which medium is to be burnt.
It does the following
isopad to get extra space at the end of the .iso
cdrecord or growisofs
isopad - to strip the padding
cmp of the medium with the iso, but only for isosize bytes.
eject
So it burns and checks.
I probably should have written a version to just check a disk. I
don't have time to make the change and test, but here is the idea:
- add new flag "-justcheck". This needs to go in the first label of
the first case, so the label would look like this:
"-cd"|"-dvd"|"-justcheck")
- and another alternative to the inner case, parallel to the
alternatives that do cdrecord and growisofs
"-justcheck")
# don't burn
;;
Those lines can be inserted immediately after the 'case "$medium" in'
line
ftp://ftp.cs.utoronto.ca/pub/hugh/isoburn
md5sum for the script:
71828ffe6fa266158c058baa88b791f0 bin/isoburn
================ start of isoburn ================
#!/bin/sh
# isoburn [-cd|-dvd] isofile...
#
# This recipe encapsulates DHR's procedure for burning from a .iso file.
#
# Copyright 2005 D. Hugh Redelmeier
# License: GPL
# Version: Wed Jun 22 10:35:24 EDT 2005
# cdrom drive
drive=/dev/cdwriter
# options for cdrecord
device=ATA:1,0,0
speed=8
medium="-cd"
# strict; show commands as executed
set -u -e -x
for iso
do
case "$iso" in
"-cd"|"-dvd")
medium=$iso
;;
*)
echo -n "press ENTER when you have loaded a new blank CD: "
read junk
isopad - "$iso"
isopad + "$iso"
case "$medium" in
"-cd")
time cdrecord -v dev=$device speed=$speed -dao driveropts=burnfree "$iso"
;;
"-dvd")
# spare bits: -use-the-force-luke=tty
time growisofs -Z "$drive"="$iso" -use-the-force-luke=notray
-use-the-force-luke=dao
;;
esac
isopad - "$iso"
time cmp --bytes `isosize "$iso"` "$iso" $drive
# because of -e, we only get here if the test passes
echo "Test passed."
eject $drive
;;
esac
done
================ end of isoburn ================
8:46 p.m.
New subject: Testing iso downloads?
On Sat, 2006-04-29 at 02:56 -0400, D. Hugh Redelmeier wrote:
My bad experiences have been due to the CD driver reading past the
end
of the burned part of the CD and getting all huffy when it doesn't
like what it sees.
The cure that has worked for me is to pad the .iso with zero blocks.
Then the driver can read that stuff without getting indigestion.
I've enclosed a script that I call "isopad". You can use it to add
padding (isopad + x.iso), remove padding (isopad - x.iso), or report
padding (isopad x.iso).
I am curious why there's a need to do this externally. Both mkisofs and
cdrecord have "padding" options. Do they not do the trick?
--
(Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
12:33 a.m.
New subject: Testing iso downloads?
| From: Tim <ignored_mailbox(a)yahoo.com.au>
| I am curious why there's a need to do this externally. Both mkisofs and
| cdrecord have "padding" options. Do they not do the trick?
Good question.
I think that the cdrecord padsize= option can be used. It is pretty
hard to make out what it does from the man page.
The padding stuff in growisofs will not work with a .iso file. It
only works when creating a new .iso (if then).
In any case, I actually burn with k3b these days and I don't remember
that it has a way of requesting padding. So I use isopad before k3b.
All this is based on superstition, so there may well be better approaches.
6593
days inactive
6595
days old
8 comments
6 participants
participants (6)
-
D. Hugh Redelmeier -
Gene Heskett -
LinuxMedia -
Mike McCarty -
Paul Howarth -
Tim