Mostrando mensaje 1173     < Anterior | Siguiente > Responder a este mensaje Asunto: [glisc] Quemar & verificar CDs Fecha: Miercoles, 16 de Abril, 2003  14:23:17 (-0400) Autor: Alfonso Fernandez <afernandez @........bo> Coasterless CD Burning Copyright (C) 2002, 2003 by Steve Litt Contents: Executive Summary Disclaimer Accurately Reading a CD Device Writing a CD Testing a CD: Verifying an ISO Summary Executive Summary Editor's Note: Until 2/17/2003 the contents of this page were inaccurate. Until that date, this page presented procedures that tended to produce correct CD's, but in fact just played the odds. As of 2/17/2003, this page displays procedures which we now believe (but we've been wrong before) completely addresses CD burning, image making and verification. A big thank you goes out to John Desmond, who was nice enough to let me know about the isoinfo program. An additional thank you goes to Tony Becker, who first let me know that dd was indeed better than cat for CD device reading, because dd gives complete control over block size and quantity. A "coaster" is defined as a defective CD. It's called a coaster because its only use is as a coaster to put drinks on. CD burning can seem iffy -- intermittent with respect to time, hardware, and many other things. We're really dealing with two problems: CD burns that are wrong or non-portable CD reads that are inaccurate The burning problem is solved by adding the -pad argument to the cdrecord program. The reading problem is solved by deducing the block size and number of blocks from the isoinfo program. You will meet many people who do not perceive a problem, and will assume the problem is yours personally. It is not. Depending on hardware and software, a great many people cannot successfully burn and checksum a CD, and have it come out correctly. A great many people cannot copy a CD to an iso file without changing the checksum. But if you work with enough CD's on enough systems, you will run into this problem, and when you do, this page contains the solution. Sections of this page show how to use the -pad argument to the cdrecord utility, and also a script called rawread that consistently reads the right amount of data off the CDROM device. Disclaimer Obviously, you use this document at your own risk. I am not responsible for any damage or injury caused by your use of this document, or caused by errors and/or omissions in this document. If that's not acceptable to you, you may not use this document. By using this document you are accepting this disclaimer. Accurately Reading a CD Device Accurate CD device reads are essential to CD creation. For instance, when you test your newly burned CD with md5sum, the data you read from /dev/cdrom must be accurate, or you'll get a false error alarm. Also, many CD's are burned off ISO images created from other CDs. If those original CD's were read incorrectly, then the resulting ISO's are incorrect, and every duplicate made from those ISO's is incorrect. Accurate CD reading is essential. Most bad CD device reads are caused by either: Reading too few or too many blocks of the CD device Inability to read the last block.  This section explains how to consistently read the correct number of blocks. The only reliable method I've found to find the true end of the CD is with the isoinfo utility. Specifically, you use the -d and -i options.  -d prints information from the primary volume  descriptor. -i specifies the path of the image to investigate, typically /dev/cdrom. Here's an example, using CD1 of the Red Hat 5.1 I bought directly from Red Hat: [slitt@mydesk slitt]$ isoinfo -d -i /dev/cdrom CD-ROM is in ISO 9660 format System id: LINUX Volume id: Red Hat Linux/Intel 5.1.5 Volume set id: Publisher id: Red Hat Software, (888) RED-HAT1 Data preparer id: Red Hat Software, (888) RED-HAT1 Application id: Red Hat Linux/Intel 5.1.5 Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set seqence number is: 1 Logical block size is: 2048 Volume size is: 329989 NO Joliet present Rock Ridge signatures version 1 found [slitt@mydesk slitt]$ In the preceding, notice the lines saying "Logical block size is: 2048" and "Volume size is: 329989". This means there are 329989 blocks on the ISO, each of which is 2048 bytes. For this CD, you can read exactly the right amount of data from it with the following dd command: dd if=/dev/cdrom bs=2048 count= 329989 The preceding command reads all valid data from the CD to stdout. This is great, but requires the user to manually run isoinfo, copy the values to the dd command, and run the dd command. Too much work. The following is a bash script, which I call rawread, that reads any CD to stdout: #!/bin/sh device=$1 blocksize=`isoinfo -d -i $device | grep "^Logical block size is:" | cut -d " " -f 5` if test "$blocksize" = ""; then echo catdevice FATAL ERROR: Blank blocksize >&2 exit fi blockcount=`isoinfo -d -i $device | grep "^Volume size is:" | cut -d " " -f 4` if test "$blockcount" = ""; then echo catdevice FATAL ERROR: Blank blockcount >&2 exit fi command="dd if=$device bs=$blocksize count=$blockcount conv=notrunc,noerror" echo "$command" >&2 $command The preceding script (which I call rawread) parses the output of isoinfo for the blocksize and blockcount, assigns them to variables, and then runs the proper dd command to copy data from the device (first argument of the rawread command) to stdout. To use this script to create an iso, do the following: rawread /dev/cdrom > myiso.iso  To use this script to check the md5sum of the CD, do the following: rawread /dev/cdrom | md5sum To summarize, many supposed CD writing problems are actually CD device reading problems, either an incorrect CD device read during checksum testing of that CD, or incorrect creation of the ISO from which the CD was created. Most inaccurate reads are caused either by reading too few or too many blocks, or by padding errors on the CD itself. The padding errors are a CD burning problem which is discussed later on this page, but the inaccurate block count can be corrected by acquiring the block size and block count from the isoinfo program, and then using those values in the dd command. This section presented a script, called rawread , which automates the isoinfo to dd process, correctly reading all the data on the device defined by its argument to stdout. By using the rawread command defined in this section, you'll be assured of reading the correct number of blocks on the CD. Writing a CD My experience is that once your CD writer is set up correctly and get your write speed right, the vast majority of write problems, especially the intermittent ones, come from lack of the -pad argument to the cdrecord program. This section explains the phenomenon and how to fix it. If you're having problems with CDRW setup, see Installing Your ATAPI CDRW Drive in Linux. The following command tells you the SCSI number of your CDRW, and also assures you that your CD works: cdrecord -scanbus If everything's working, the result should look something like this:   [slitt@mydesk slitt]$ cdrecord -scanbus Cdrecord 1.9 (i586-mandrake-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' scsibus0:         0,0,0     0) 'ATAPI   ' 'CD-R/RW CRW6206A' '1.2A' Removable CD-ROM         0,1,0     1) *         0,2,0     2) *         0,3,0     3) *         0,4,0     4) *         0,5,0     5) *         0,6,0     6) *         0,7,0     7) * [slitt@mydesk slitt]$ As you can see, in this example my SCSI device number is 0,0,0. Later versions of Mandrake (Mandrake 9.0, for instance), for some reason place the CD on 0,3,0., so don't assume it will always be 0,0,0. First, find the right speed, which is the lower of the CDRW drive's capability or the CDR/CDRW media's capability. Remember that your writer has less speed capability for rewritables, so use that lower speed when writing CDRW media. With CDRW's, always blank the CD: cdrecord dev=0,0,0 speed=10 blank=fast -v -eject The preceding command blanks only the necessary parts of the disk (blank=fast) at a speed of 10, and it does this to device 0,0,0 (change this if your cdrecord -scanbus indicated a different number). Obviously, change the 10 if your rewrite speed (lesser of device or media) is not 10. NOTE You can blank the CD at the same time as you record just by including the blank=fast argument in the cdrecord command to burn the CD. Next, burn the CD from the ISO: cdrecord dev=0,0,0 speed=10 -pad -v -eject myimage.iso Unless your CDRW device has a hardware "burnproof" or "buffer underflow prevention" feature, do not do other work on the machine while burning the CD. At 10x speed the burn will take only 7 minutes, so this isn't much of an imposition. Likewise, unless you have these features, do not burn at fast speeds when the source ISO is on a network drive.   NOTE There are many ways to burn a CD, including applications like xcdroast and gtoaster. Most are good, so use whichever suits your needs. Just remember the basic principles from this section: Burn at the right speed Pad properly Unless your burner prevents buffer underflow, do no other work while you're burning. Make sure the CD is properly padded According to the cdrecord program's man page, Linux has a read-ahead buffer bug as described in the following exerp from the cdrecord man page: -pad If the track is a data track, 15 sectors of zeroed data will be added to the end of this and each subsequent data track. In this case, the -pad option is superseded by the padsize= option. It will remain however as a shorthand for padsize=15s. If the -pad option refers to an audio track, cdrecord will pad the audio data to be a multiple of 2352 bytes. The audio data padding is done with binary zeroes which is equal to absolute silence. -pad remains valid until disabled by -nopad. padsize=# Set the amount of data to be appended as padding to the next track to #. Opposed to the behavior of the -pad option, the value for padsize= is reset to zero for each new track. See fs= option for possible arguments. Use this option if your CD-drive is not able to read the last sectors of a track or if you want to be able to read the CD on a Linux system with the ISO-9660 filesystem read ahead bug. If an empty file is used for track data, this option may be used to create a disk that is entirely made of padding. Note the bolded text in the preceding man page. Those "I/O  error" messages you get toward the end of a CD are caused by a known bug which can be worked around by adding the -pad argument to your cdrecord command. Depending on the configuration of the ISO image from which the CD is burned, those I/O errors might result in corruption of the last file on the CD, or all files might be correct but the md5sum result of /dev/cdrom might differ from that of the original ISO. Often a CD burned without the -pad argument will md5sum perfectly on one machine, and inaccurately on another. WARNING The mkisofs program also has  a -pad  argument, and it is the default for the same reasons described  above. Unless you have an excellent reason, never defeat that default. Those not experiencing problems often don't use -pad because it doesn't seem to be needed. Then, when they loan out their installation CD's, the installs fail on some machines. Ughhh. So unless you have an excellent reason not to, always use -pad. The command should look something like this: cdrecord dev=0,0,0 speed=10 -pad -v -eject /home/myuid/myiso.iso Summary To burn a CD correctly, you must take care of the following: Set up your burner correctly. Burn at the right speed. While burning, do not perform other CPU or disk intensive work, as it will cause buffer underflow on burners without underflow protection. Always pad correctly with the -pad argument to cdrecord. Without excellent reason, do not defeat the -pad default of the mkisofs program. The padding is what most people miss. They miss it because in a great many situations lack of padding causes no problem. But when it does, it takes the form of a hard to troubleshoot intermittent. Always pad. Once your CD is burned, you need to test it to verify it's an exact copy of the ISO image from which it was made. Read on... Testing a CD: The definitive test for a CD you just burned is to compare its checksum with that of the ISO from which it was burned. Recalling the rawread script from the Accurately Reading a CD Device section, your CD is an accurate reproduction of the ISO file if the numbers produced by these two commands match: md5sum myiso.iso rawread /dev/cdrom | md5sum If they match, you've burned a winner. But sometimes you need to verify the ISO itself. Read on... Verifying an ISO Garbage in, garbage out. If your ISO is wrong, every CD you burn from that ISO will be wrong. If you're making SWAG for your LUG's booth at a regional trade show, this could be several hundred coasters. Worse yet, these coasters might be "almost right", and either bomb during installation or possibly install faulty Linux. Your ISO images must be verified to be correct. There are different verification methods depending on the way the ISO came into being. When downloading an ISO image of a free software distribution, the web site usually publishes the md5sum value for that image. If humanly possible, for every ISO you have, find the published md5sum value and compare it to that. This is vital because ISO images typically go through all sorts of generations. For instance, Bill downloads the Mandrake ISO for CD 1 on his T1 at work. Bill burns a Mandrake CD off the downloaded ISO and brings it to your LUGs Installfest. Unfortunately, Bill forgot to use the -pad argument when using cdrecord. At the Installfest, Phil uses the catprogram to copy /dev/cdrom to myiso.iso, thereby getting the wrong block count, but he doesn't md5sum to verify. Phil burns several CD's off the ISO he made from Bill's CD, but unfortunately once he too forgets to use -pad. Will obtains one of Phil's CD's, and does everything right. He uses isoinfo to obtain the block size and count, and uses dd with the size and count to create an ISO. Fortunately for Will (actually unfortunately), his system reads even unpadded CD's correctly, so there are no I/O errors to clue him in that Phil forgot to pad. Will creates several properly padded CDs from that ISO, and for each CD he uses isoinfo and dd (or better yet, the rawread script described in the Accurately Reading a CD Device section of this page), to pipe the CD device to the md5sum utility, verifying that the checksum on the CD's are the same as the checksum on the ISO he made from Phil's CD. Will makes 20 such CD's and distributes them to his Installfestmates. Unfortunately for Will and the 20 other people, although his CD's matched the ISO perfectly, the ISO did not match the original Mandrake ISO. In fact, successive errors by Bill and Phil further damaged the ISO. Some of those using Will's CD's encountered glitchy problems, and blamed it on either Linux or on Mandrake. Some using Will's CD's got perfect results, so Will never thought to check for bad data on his CD's. After all, the CD's all matched the checksum of his master ISO. If there exists a published md5sum for a CD image, always check your master ISO against that published md5sum value. After all, garbage in, garbage out. Sometimes there's no published checksum. If, for backup purposes, you create an ISO image of a crucial proprietary program, obviously there will be no published checksum. In that case, the best you can do is create an ISO from the proprietary program's install CD. And I mean a factory printed, non-counterfeit CD. If there have been additional generations, you probably already have garbage in. And of course, if there have been additional generations, you're violating copyright law and are subject to a $150,000 fine. WARNING You might be violating the law making any ISO copy of a proprietary install CD. Shrinkwrap licenses are all different, and surrounding laws such as DMCA, UCITA and CBDTPA influence the legality. Some licenses permit you to create a single copy for backup purposes, but if that backup is an ISO, where would you store it? And in the case of installable software, would your original install CD be considered the one and only backup? Are there consumer protection or fair use laws guaranteeing you the right for additional backups, and are those consumer protection or fair use laws trumped by laws such as DMCA, UCITA and CBDTPA? I'm not a lawyer and don't even pretend to know the answers to any of these questions. Because of this uncertainty, and the possible $150,000 fine for violation, my advice to you is quickly rid yourself of proprietary software and use only Open Source (free software, free as in freedom). When making an ISO from an existing factory created CD, create and verify the ISO against the CD using the rawread script (defined in the Accurately Reading a CD Device section) as follows: rawread /dev/cdrom > myiso.iso rawread /dev/cdrom | md5sum md5sum myiso.iso If the two checksums match, you can be fairly confident that your ISO is an exact duplicate of the original CD. Summary Much coaster production can be traced to one of two breaches: Reading too few or too many blocks of a good CD Producing a CD whose last one or several blocks cause I/O errors.  Problem 1 is fixed by the rawread script defined in the Accurately Reading a CD Device section. Problem 2 is usually fixed by using the -pad argument to the cdrecord utility, and making sure to retain the mkisofs utilitie's default of -pad. Because many free software CD's are duplicated over several generations, it's vital to burn from a known good ISO, hopefully an ISO whose md5sum value conforms to the value published by the software's website. When creating an ISO from an existing CD, be sure to use the rawrite script in order to get the right number of blocks into the new ISO, and then checksum against the published value. When burning a CD, always use the -pad argument to cdrecord, and never negate the default -pad argument to the mkisofs program. Also, never burn while using other disk or CPU intensive software unless your CD writer hardware and software are set to prevent buffer underflow (such protection is sometimes called "burn-free"). Be sure you burn at a speed at or below the lower of your CD writer's maximum speed and the CD media's maximum speed. If you're using a rewritable CD, you must use the "rewrite" speed values. Naturally, your CD writer must be set up correctly. If there are problems in that regard, see Installing Your ATAPI CDRW Drive in Linux. If you follow all these suggestions, you will burn very few coasters, and at Installfests you will be widely respected. http://www.troubleshooters.com/linux/coasterless.htm