[Discuss] Ways to Get New Laptops to Boot a LiveCD
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Fri Jan 15 15:46:18 PST 2010
On 2010-01-15 09:48-0800 Steven Kurylo wrote:
> Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
>>
>> I don't know whether the trailing garbage is produced on the drive by the
>> burn step or by some issue when reading a burned disk. But as far as I can
>> tell it makes no practical difference at all (the result mounts without
>> issues, for example) except in interfering with the md5sum of the entire
>> disk at once unless you use head as above to get rid of the trailing
>> garbage.
>
> Does this happen on various hardware for you? I don't recall seeing
> trailing garbage and I've used at least a dozen burners over the (7?)
> years with cdrecord.
>
> I just verified it right now with a cd I burnt
>
> # md5sum cdrom.iso
> 5bf476e2fc445b8d06b3c2a6091fe3aa
> # cat /dev/cdrom |md5sum
> 5bf476e2fc445b8d06b3c2a6091fe3aa
Thanks, Steven, for that interesting follow-up comment which encouraged me
to reassess. For the CD written by k3b but which failed the built-in
checksum test there, I now get the following results.
irwin at raven> cat /dev/cdrom |md5sum
b87e267742595444df32e06e5da68951 -
irwin at raven> md5sum debian-testing-i386-netinst.iso
b87e267742595444df32e06e5da68951 debian-testing-i386-netinst.iso
So that is perfect agreement with no trailing garbage issues at all.
I incorrectly assumed (at the time and in my subsequent post to VLUG) it was
trailing garbage that made k3b issue the failed check message because that
issue has hurt me in the past with a different burner (when using cdrecord
rather than k3b to burn the CD) and older kernel.
So I am left wondering what caused k3b to issue the incorrect failed check
message? This was actually my first use of k3b, and I was most impressed by
how easy that GUI made it to burn and check CD's. (Yes, John, I do attempt
to use GUIs sometimes.... :-) ) I guess it is possible the disk was not left
in an immediately readable state just after the burn and something about
ejecting the disk then (a week ago) and putting it back in the drive 15
minutes later for the head-protected md5sum check and also for the bare
md5sum check results above has solved the hypothesized "not in immediately
readable state" issue. But that is a pretty far-fetched explanation.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
More information about the Discuss
mailing list