Can't burn Mandrake 10.0 CD2 - comp.os.linux.misc

I downloaded the official Mandrake 10.0 ISO images for 4 cds. I verified the MD5 checksums of the downloaded files. Numbers 1,3 and 4 burned fine and the MD5 checksum of the resulting CDs verify correctly. I'm completely unable to burn a good copy of CD2. I've tried 12 times now. I've tried three different brands of media, two different machines (two different drives) and three different burn speeds. All failed to come up with the correct checksum. It appears that the resulting CD is always 2K short. The CD ends up being 728795136 bytes, but the file is 728793088 (of course the MD5 checksum doesn't verify). The bytes that _are_ on the CD are right, but the last 2K is always missing. CD#2 isn't the largest of the four, but it's the only one that's not an exact multiple of 4K. The command I'm using is # cdrecord -v dev=<n,n,n> speed=n filename.iso I'm baffled. Can anybody loan me a clue?? -- Grant Edwards grante Yow! Yow! It's some people at inside the wall! This is visi.com better than mopping!

Grant Edwards wrote: > > The command I'm using is > > # cdrecord -v dev=<n,n,n> speed=n filename.iso > > I'm baffled. Can anybody loan me a clue?? cdrecord -v dev=<n,n,n> speed=n -data filename.iso -- Confucius: He who play in root, eventually kill tree. Registered with The Linux Counter. http://counter.li.org/ Slackware 9.1.0 Kernel 2.4.26 SMP i686 (GCC) 3.3.3 Uptime: 8 days, 12:47, 2 users, load average: 0.01, 0.15, 0.68

David wrote: > > cdrecord -v dev=<n,n,n> speed=n -data filename.iso If that doesn't work, have you tried downloading the ISO from a different mirror? -- Confucius: He who play in root, eventually kill tree. Registered with The Linux Counter. http://counter.li.org/ Slackware 9.1.0 Kernel 2.4.26 SMP i686 (GCC) 3.3.3 Uptime: 8 days, 12:47, 2 users, load average: 0.01, 0.15, 0.68

In article <u%Fkc.6388$Ik.539099@attbi_s53>, David wrote: >> cdrecord -v dev=<n,n,n> speed=n -data filename.iso I'll try that, but the cdrecord man page says '-data' is the default. I've been burning CDs with cdrecrod for years without using "-data". > If that doesn't work, have you tried downloading the ISO from a > different mirror? Why? The MD5 checksum of the ISO file is correct. It's the MD5 checksum of the burned CD that isn't right. I have found out that if I mount both the ISO file and the "bad" cd, the directory trees compare OK with both "diff -r" and with "find -type f -exec cmp ...". I can only assume that the last 2K bytes aren't needed (They're all 0's). Now that I look, the last 600K bytes of the ISO file are all 0's. -- Grant Edwards grante Yow! I'll take ROAST BEEF at if you're out of LAMB!! visi.com

In article <4093293e$0$17263$a1866201@newsreader.visi.com>, Grant Edwards <grante@visi.com> wrote: > I downloaded the official Mandrake 10.0 ISO images for 4 cds. I > verified the MD5 checksums of the downloaded files. Numbers 1,3 > and 4 burned fine and the MD5 checksum of the resulting CDs > verify correctly. > > I'm completely unable to burn a good copy of CD2. I've tried > 12 times now. I've tried three different brands of media, two > different machines (two different drives) and three different > burn speeds. All failed to come up with the correct checksum. > > It appears that the resulting CD is always 2K short. > > The CD ends up being 728795136 bytes, but the file is 728793088 > (of course the MD5 checksum doesn't verify). That's 695 MB + 32 KB. Maybe that's too big? You said it's not the biggest in the set, so I guess not. It's not bootable, so try: loopback-mount the *.iso, run mkisofs on it and burn the resulting image. Burn at a lower speed. Don't make any more coasters; do subsequent test burns using "-dummy". Pad an additional 2 KB. > CD#2 isn't the largest of the four, but it's the only one > that's not an exact multiple of 4K. Really? 728793088 = 177928 * 4096 -- -eben ebQenW1@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar Hanlon's Razor: "Never attribute to malice that which can be adequately explained by stupidity." Derived from Robert Heinlein

In article <c6veo7$46c$1@pc.tampabay.rr.com>, Hactar wrote: >> It appears that the resulting CD is always 2K short. >> >> The CD ends up being 728795136 bytes, but the file is 728793088 >> (of course the MD5 checksum doesn't verify). > > That's 695 MB + 32 KB. Maybe that's too big? You said it's not the > biggest in the set, so I guess not. Right. > It's not bootable, so try: loopback-mount the *.iso, run mkisofs on it and > burn the resulting image. I don't see what that will accomplish. If I generate a ISO file that's different than the original and then burn that different ISO file, the CD will still be different than the downloaded ISO file. > Burn at a lower speed. I've gried 2x 4x and 8x. Same results. > Don't make any more coasters; Coasters are free. > do subsequent test burns using "-dummy". I don't understand. How do I know if a CD burned with '-dummy' is correct.? > Pad an additional 2 KB. I thought about that, but again, I still end up with a CD that doesn't match the original ISO file. >> CD#2 isn't the largest of the four, but it's the only one >> that's not an exact multiple of 4K. > > Really? 728793088 = 177928 * 4096 The CD I end up with is a multiple of 4K, but the ISO image I start out with isn't. The two don't match when I'm done. That's the problem. -- Grant Edwards grante Yow! .. over in west at Philadelphia a puppy is visi.com vomiting...

In article <4093d4f3$0$17262$a1866201@newsreader.visi.com>, Grant Edwards <grante@visi.com> wrote: > In article <c6veo7$46c$1@pc.tampabay.rr.com>, Hactar wrote: > > >> It appears that the resulting CD is always 2K short. > >> > >> The CD ends up being 728795136 bytes, but the file is 728793088 > >> (of course the MD5 checksum doesn't verify). > > > It's not bootable, so try: loopback-mount the *.iso, run mkisofs on it and > > burn the resulting image. > > I don't see what that will accomplish. If I generate a ISO > file that's different than the original and then burn that > different ISO file, the CD will still be different than the > downloaded ISO file. Sure, but unless something cares about the actual blocks occupied by a particular file, it won't matter. The resulting *.iso may fit. In fact, what you have done already may be OK. > >> CD#2 isn't the largest of the four, but it's the only one > >> that's not an exact multiple of 4K. > > > > Really? 728793088 = 177928 * 4096 > > The CD I end up with is a multiple of 4K, but the ISO image I > start out with isn't. That's the image size above, ...88, that is a multiple of 4K. (Right?) The CD isn't. > The two don't match when I'm done. That's the problem. Yup. -- -eben ebQenW1@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar And we never failed to fail / It was the easiest thing to do -- CSN

On 2004-05-01, Hactar <ebenONE@tampabay.ARE-ARE.com.unmunge> wrote: >> I don't see what that will accomplish. If I generate a ISO >> file that's different than the original and then burn that >> different ISO file, the CD will still be different than the >> downloaded ISO file. > > Sure, but unless something cares about the actual blocks > occupied by a particular file, it won't matter. The resulting > *.iso may fit. In fact, what you have done already may be OK. I'm pretty sure what I've burned is OK. I can't find any differences in the directory tree or files when I compare the mounted CD and the mounted (downloaded) ISO file. I'm typing this on a box running Mandrake 10 installed from that CD, so it's probably OK. It still annoys me that I don't understand what's going on. Either Mandrake did something goofy when they created the .iso file or cdrecord is doing something weird. Cdrecord _says_ it's burned the right number of bytes (matches the length of the ..iso file), but when I use dd to copy the resulting CD back to a file, it comes out 2K short. One theory is that the .iso file contains info in it saying how long the track is, and that length is 2K shorter than the length of the .iso file. Not sure how to check that... > That's the image size above, ...88, that is a multiple of 4K. > (Right?) The CD isn't. No. The image file size isn't a multiple of 4K, but it is a multiple of 2K. The CD always seems to be the next lower multiple of 4K. IOW, the CD ends up containing the ISO file truncated to a 4K boundary. There appears to be nothing in the last several hundred K of the .iso file, so I guess it's OK. -- Grant Edwards grante Yow! I'm young... I'm at HEALTHY... I can HIKE visi.com THRU CAPT GROGAN'S LUMBAR REGIONS!

Grant Edwards <grante@visi.com> writes: ]It still annoys me that I don't understand what's going on. ]Either Mandrake did something goofy when they created the .iso ]file or cdrecord is doing something weird. Cdrecord _says_ it's ]burned the right number of bytes (matches the length of the ].iso file), but when I use dd to copy the resulting CD back to ]a file, it comes out 2K short. What do you mean "copy the resulting CD back to a file"?

On 2004-05-02, Bill Unruh <unruh@string.physics.ubc.ca> wrote: > Grant Edwards <grante@visi.com> writes: > > > ]It still annoys me that I don't understand what's going on. > ]Either Mandrake did something goofy when they created the .iso > ]file or cdrecord is doing something weird. Cdrecord _says_ it's > ]burned the right number of bytes (matches the length of the > ].iso file), but when I use dd to copy the resulting CD back to > ]a file, it comes out 2K short. > > What do you mean "copy the resulting CD back to a file"? dd if=/dev/hdc of=file.iso bs=2k or, on my other machine dd if=/dev/sr0 of=file.iso bs=2k -- Grant Edwards grante Yow! Does someone from at PEORIA have a SHORTER visi.com ATTENTION span than me?

In article <4093293e$0$17263$a1866201@newsreader.visi.com>, Grant Edwards \ wrote: > I downloaded the official Mandrake 10.0 ISO images for 4 cds. I > verified the MD5 checksums of the downloaded files. Numbers 1,3 > and 4 burned fine and the MD5 checksum of the resulting CDs > verify correctly. > > I'm completely unable to burn a good copy of CD2. I've tried > 12 times now. I've tried three different brands of media, two > different machines (two different drives) and three different > burn speeds. All failed to come up with the correct checksum. I feel your pain. I have the same problem, except I can't get 2 or 4 to verify cleaning by the 'dd' method. In my case, it appears the only thing missing is some padding at the end of the image. One way to do somewhat of a verification is to use 'dd' to read back in an ISO file from the CD, then mount both the original and the extracted ISO files using loopback, then 'diff -r' the two mountpoints. Except for maybe boot block stuff, if 'diff -r' is clean, all the files on the CD should be okay. > It appears that the resulting CD is always 2K short. > > The CD ends up being 728795136 bytes, but the file is 728793088 > (of course the MD5 checksum doesn't verify). The bytes that > _are_ on the CD are right, but the last 2K is always missing. > CD#2 isn't the largest of the four, but it's the only one > that's not an exact multiple of 4K. > > The command I'm using is > > # cdrecord -v dev=<n,n,n> speed=n filename.iso > > I'm baffled. Can anybody loan me a clue?? If I had one, I'd be happy to send it. Good luck. Robert Riches spamtrap42@verizon.net (Yes, that is one of my email addresses.)