No I simply copied the cd's I was given. Try md5'ing the indivdual rpm files
assuming the cd is mounted on /mnt/cdrom cd /mnt/cdrom/Mandrake/RPMS (on cd 2 it is RPMS2 etc) rpm --checksig --nogpg *.rpm On Tue, 11 Mar 2003 11:07:47 +1300 Jason Greenwood <[EMAIL PROTECTED]> wrote: > Agree'd, thank you Volker!! > > Now, Nick, did your CD's md5sum come out ok?? Maybe I got some bad > burns??... > Chris?? Your md5's?? > > Nick Rout wrote: > > >Volker, very very informative, thank you. > > > > > >On Tue, 11 Mar 2003 10:54:43 +1300 > >Volker Kuhlmann <[EMAIL PROTECTED]> wrote: > > > > > > > >>>If you cannot get an .iso image file on your hard drive to md5sum correctly > >>>after a couple of tries, it's pointless going on any further. > >>> > >>> > >>True. > >> > >> > >> > >>>Those silver SKC disks are obviously not of sufficient quality for use as > >>>stores for computer files. Sorry I didn't know that when I bought them. > >>> > >>> > >>This may not be the real reason. The implementation of the isofs in > >>Linux is quite bad (e.g. the method of making inodes will prevent > >>hardlinked files from ever being stored properly on an isofs). The > >>kernel also has the habit (ever since the first version) of reading too > >>much data from the device, i.e. it reads past end of file on the disk. > >>Needless to say this can cause I/O errors (oh what a surprise). For > >>this reason only cdrecord has a -pad option, which simply writes > >>additional zeros past the end of the filesystem onto the disk. Of > >>course, this also stuffs your md5 sums. Another bug in the kernel is > >>that it can't properly detect end-of-file on CD media. These additional > >>zeros will screw your md5. > >> > >>For the record, all these are 100% identical: > >> > >> cat /dev/cdrom | md5sum > >> md5sum < /dev/cdrom > >> dd if=/dev/cdrom bs=2k | md5sum > >> dd </dev/cdrom bs=2k | md5sum > >> > >>plus any more combinations everyone can think of. They either all work, > >>or not at all. For current 2.4.18/2.4.19 kernels, they don't work > >>reliably. Depending on how many blocks there are on the CD, reading > >>will work, or fal with an I/O error (when the kernel tries to read past > >>the end of the recorded bit stream on the media). Even if the read goes > >>ok, unless you have happened to read precisely the correct number of > >>bytes your md5 is screwed anyway. I have had kernels where cat > >>/dev/cdrom resulted in a complete crash (kernel panick) right at the > >>very end of reading. > >> > >>In my experience the only way to get reliable md5 sums with cds is to > >>take matters into my own hands. Download the scriptutils package/tar > >>from my web site and use > >> > >> writecd --blockread /dev/cdrom | md5sum > >> > >>or cook your own. The trick is > >> > >> dd bs=2k if=/dev/cdrom count=`isoinfo -i /dev/cdrom -d | awk ...` > >> > >>This will force reading of the correct number of blocks from the disk > >>media (or any disk file). Note it will only work with an isofs on the > >>CD, not with any other filesystem. > >> > >>Recently I got too fed up with this Linux isofs crap that I started to > >>put ext2 onto the cds. Much easier and trouble free: create a 650MB or > >>700MB file filled with zeros (by reading from /dev/zero). Run mkfs -t > >>ext2, don't forget -m0 as there really isn't any point in reserving > >>blocks for the super user on a read-only filesystem. Loop-mount. Master > >>your cd with cp, or rsync, or tar, or whatever, but no need to mess > >>with mkisofs. Unmount. cdrecord file to cd, finished. Won't be readable > >>by microsofties, but for my backups that's just as well. > >> > >>Volker > >> > >>-- > >>Volker Kuhlmann is possibly list0570 with the domain in header > >>http://volker.dnsalias.net/ Please do not CC list postings to me. > >> > >> > >> > > > >-- > >Nick Rout > >Barrister & Solicitor > >Christchurch, NZ > >Ph +64 3 3798966 > >Fax + 64 3 3798853 > >http://www.rout.co.nz > >[EMAIL PROTECTED] > > > > > > > > > > -- Nick Rout <[EMAIL PROTECTED]>
