Hi: [SuSE 8.1] I use mkisofs and cdrecord in a little script to backup selected dirs in my home. I had it set up on 7.3 and it worked great. Now on 8.1 I am having terrible problems getting a checksum agreement using md5sum on the .iso vs. the disk. I updated the cdrecord that came out of the box with the 1.11.a28-33 that I downloaded from Suse's updates for 8.1. (7.3 has cdrecord version 1.11.a06-6.) That got me some agreement on my test script, then when I run the main backup script, it fails. I booted to SuSE 7.3 and ran the same script using the same disk (just to be sure it wasn't the disk) and the backup checksums agreed. What the heck is wrong with cdrecord? I would advise anybody burning CDs on 8.1 to try some md5sums, and behold. It is very strange, as you can fail to get a valid md5sum agreement, and you can still mount the disk and read files. But then you will go to get some file one day, and *that* one will give an IO error. Problems like this are what made me add the md5sum commands to my backup operation, in order to be sure after a burn that all data on the disk agreed with the image. Here is my script: #!/bin/bash echo We are in the full.CD-RW.backup.script! CDRW_SCSI_DEV=0,0,0 CDRW_DEV_PATH=/dev/cdrecorder mkisofs -o ~/cd-rw/full.backup.iso -R -J -v -graft-points \ -path-list ~/backup.scripts/full.backup.dir.list cdrecord dev=$CDRW_SCSI_DEV -v blank=fast speed=10 -dao ~/cd-rw/full.backup.iso echo \n md5sum ~/cd-rw/full.backup.iso md5sum $CDRW_DEV_PATH echo \n echo Press Enter or close when done... read REPLY exit Thanks for comments. -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov
On Monday 11 November 2002 22:06, Chris Carlen wrote:
Hi: [SuSE 8.1]
I use mkisofs and cdrecord in a little script to backup selected dirs in my home. I had it set up on 7.3 and it worked great. Now on 8.1 I am having terrible problems getting a checksum agreement using md5sum on the .iso vs. the disk.
I updated the cdrecord that came out of the box with the 1.11.a28-33 that I downloaded from Suse's updates for 8.1. (7.3 has cdrecord version 1.11.a06-6.) That got me some agreement on my test script, then when I run the main backup script, it fails.
I booted to SuSE 7.3 and ran the same script using the same disk (just to be sure it wasn't the disk) and the backup checksums agreed.
What the heck is wrong with cdrecord?
I would advise anybody burning CDs on 8.1 to try some md5sums, and behold. It is very strange, as you can fail to get a valid md5sum agreement, and you can still mount the disk and read files. But then you will go to get some file one day, and *that* one will give an IO error. Problems like this are what made me add the md5sum commands to my backup operation, in order to be sure after a burn that all data on the disk agreed with the image.
Here is my script:
#!/bin/bash echo We are in the full.CD-RW.backup.script! CDRW_SCSI_DEV=0,0,0 CDRW_DEV_PATH=/dev/cdrecorder mkisofs -o ~/cd-rw/full.backup.iso -R -J -v -graft-points \ -path-list ~/backup.scripts/full.backup.dir.list cdrecord dev=$CDRW_SCSI_DEV -v blank=fast speed=10 -dao ~/cd-rw/full.backup.iso echo \n md5sum ~/cd-rw/full.backup.iso md5sum $CDRW_DEV_PATH echo \n echo Press Enter or close when done... read REPLY exit
Good day Chris, I have only suggestions. Try without -dao. It shouldn't be needed when you burn an ISO. I do it that way, and it works fine for me. Have you tried to make a table of MD5 sums for all of the files in the directories, in stead of juste one for the ISO? That is what I do to see if the files on the mounted CD matches what was on the hard drive before I made the ISO that went on the CD. Best regards :o) Johnny :o)
Johnny Ernst Nielsen wrote:
Good day Chris,
I have only suggestions.
Try without -dao. It shouldn't be needed when you burn an ISO. I do it that way, and it works fine for me.
Have you tried to make a table of MD5 sums for all of the files in the directories, in stead of juste one for the ISO?
Thanks for your reply. This seems like a great deal of effort. I don't know why this should be necessary, as the goal is to verify that the disk equals the image.
That is what I do to see if the files on the mounted CD matches what was on the hard drive before I made the ISO that went on the CD.
I used to do the cdrecord without the -dao. Then I encountered a disk that had read errors on some files. So I added the md5sums. But I got I/O errors from the md5sum *always* without using -dao. Thus, I discovered that using -dao made the I/O errors disappear, and then had no problems, until SuSE 8.1's cdrecord. Now it seems I don't get IO errors anymore when I don't use -dao. The 3 transcripts below show that when I do my small test backup on Suse 8.1, it works with or without -dao. But notice it uses SAO mode when I specify -dao. The third transcript shows my full backup, and with or without (here I show without, as you suggested), I don't get the md5sums to agree. Here's what happens for me: crcarle@mango:~> cdrecord dev=0,0,0 -v blank=fast speed=10 -dao\ /cd-rw/test.backup.iso Cdrecord 1.11a28 (i686-suse-linux) Copyright (C) 1995-2002 Jvrg Schilling [edited a lot of output] Starting to write CD/DVD at speed 10 in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Blanking PMA, TOC, pregap Blanking time: 18.566s BURN-Free is ON. Performing OPC... Sending CUE sheet... Writing pregap for track 1 at -150 Starting new track at sector: 0 Track 01: 1 of 1 MB written (fifo 100%) 35.9x. Track 01: Total bytes read/written: 1474560/1474560 (720 sectors). Writing time: 16.389s Fixating... Fixating time: 10.100s cdrecord: fifo had 24 puts and 24 gets. cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%. crcarle@mango:~> md5sum /dev/sr0 a46d33b0afb990eec3224953ad62fe46 /dev/sr0 crcarle@mango:~> cdrecord dev=0,0,0 -v blank=fast speed=10 ~/cd-rw/test.backup.iso Cdrecord 1.11a28 (i686-suse-linux) Copyright (C) 1995-2002 Jvrg Schilling [edited] Starting to write CD/DVD at speed 10 in real TAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Blanking PMA, TOC, pregap Blanking time: 18.581s BURN-Free is ON. Performing OPC... Starting new track at sector: 0 Track 01: 1 of 1 MB written (fifo 100%) 26.5x. Track 01: Total bytes read/written: 1474560/1474560 (720 sectors). Writing time: 2.986s Fixating... Fixating time: 31.093s cdrecord: fifo had 24 puts and 24 gets. cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%. crcarle@mango:~> md5sum /dev/sr0 a46d33b0afb990eec3224953ad62fe46 /dev/sr0 NOTE: This would have given an IO error on Suse 7.3. Now the large backup, done by the script in the OP but removed the -dao option. This still fails to give agreement: Cdrecord 1.11a28 (i686-suse-linux) Copyright (C) 1995-2002 Jvrg Schilling Starting to write CD/DVD at speed 10 in real TAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Blanking PMA, TOC, pregap Blanking time: 18.549s BURN-Free is ON. Performing OPC... Starting new track at sector: 0 Track 01: 191 of 191 MB written (fifo 100%) 10.6x. Track 01: Total bytes read/written: 201129984/201129984 (98208 sectors). Writing time: 133.831s Fixating... Fixating time: 32.563s cdrecord: fifo had 3168 puts and 3168 gets. cdrecord: fifo was 0 times empty and 2997 times full, min fill was 78%. n c22163222c34988ed29cef09e1d320f3 /home/crcarle/cd-rw/full.backup.iso e305ca47632a0d2992d2daba44aa3c17 /dev/cdrecorder I'm getting rather annoyed by this. This shouldn't require rocket science, and was not a big deal on Suse 7.3. What changed? It's even the same cdrecord version. One thing I might try is installing the cdrecord version from Suse 7.3. I will open a support issue I think after a few more tests. Good day! -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov
Good day Chris, first off, I go through the lengthy manouvres checking all files on the burned CD against all files on the hard disk because I assume errors _may_ happen when mkisofs makes the image. Thus I might end with a corrupt image whose md5 sum will match the (also corrupt) CD, when the CD is burned. I may be paranoid, but I prefer to check up against the original and not the copy. Anyway, checking all the files is not that difficult. Let me show you how my backup script does this all automatically: find /root /home -type f | sed '/[.]DCOPserver_/d;s/./\\&/g;s/^/md5sum -b /' | bash | tee /tmp/sikkerhedskopi.md5; The find command lists all full file names under the the given directories, but only ordinary files -- not symbolic links. The first sed command deletes all output lines about files starting with '.DCOPserver_'. They are temporary KDE session files that exist only during the individual KDE session. The other sed command escapes all characters in the file names, to avoid problems with special characters like $ og *. The third sed command inserts the md5sum command before the file names. The bash command executes all the md5sum commands. The tee command puts a copy of the terminal output in a file. I need to show the user progress, as well as produce an md5sum file. Make the ISO image. Make sure to include the md5sum file in the root of the CD image. Burn the ISO image to a CD. Mount the CD sed 's|/|'"$CDRPATH"'/|' "$CDRPATH/sikkerhedskopi.md5" | md5sum --check | tee /tmp/checkresult The sed command substitutes every first '/' in all lines of the md5sum file on the CD, with the correct path to the CD. The variable holds the path to where the CD-R is mounted. All the altered lines are fed to md5sum so that it md5sum-checks every single file on the CD against the harddisk-files' md5sum values in the md5sum file. The trick is that the md5sum file holds the md5sums for the harddisk files. But after the correcting the paths in the list with sed all the filenames in the md5sum file points to the files on the CD in stead of those on the harddisk. Thus the files on the CD is checked with the md5sums of the harddisk files. After the md5sum check I check the result file, like this: sed '/FAILED/!d' /tmp/checkresult This will output all lines with the message 'FAILED' so I can see what files failed the md5sum check. Hopefully there will be no output. Best regards :o) Johnny :o)
participants (2)
-
Chris Carlen
-
Johnny Ernst Nielsen