Need to trim some bytes off the end of a file
 

So I am trying to install Slackware 12.0 and it's locking up hard at the keyboard selection during boot. I am going to assume a bad burn to dvd.

Here is the run down:

1. Downloaded the iso via torrent.
2. Checked the .iso against the .md5 (not that it's needed using torrents)
3. # growisofs -dvd-compat -speed=4 -Z /dev/dvd=slackware-12.0-install-dvd.iso
4. {several failed install attempts}
5. dd if=/dev/dvd of=rip.iso bs=1M

This results in rip.iso being slightly larger than slackware-12.0-install-dvd.iso, most likely due to the use of -dvd-compat during growisofs.

So I need something to trim rip.iso to the same size as slackware-12.0-install-dvd.iso and then check the md5sum to determine a good burn.

I am currently trying to dd rip.iso to another file using bs=1 and count={exact size of slackware-12.0-install-dvd.iso} but it is painfully slow.

Is there something to trim the end of a file?

I think that dvds use block sizes of either 1024 or 2048. The problem was probably caused but using 1M as the block size.

Use split to break up the file into parts. Use the length of the slackware-12.0-install-dvd.iso as the slice size. Then delete the excess.

There is a truncate function in C but I don't know how you would access it unless you created a program to do it. Maybe a perl library function exists.

Split!
I knew there was something to do it.
man -k trim & google linux+trim+file were useless.

I thought dd would just give up on the last read block (writing the part it had) if it couldn't fill the whole blocksize. I guess there is only one way to find out though.

Thanks.

OK. The dvd image verified so I'm off to see what went wrong during the install.

For the record, using a bs=2048 or bs=1M made no difference in the rip.iso size as without count=xxx it means nothing. Except that 1M rips faster.

After burning the DVD, you could have used the md5sum program on the device (as root) instead of copying the disk to a file. Alternately you could use dd to copy from the device and pipe the output into "md5sum --"

Nope.

It always fails and I believe it's the -dvd-compat option causing it. Probably does something similar to cdrecord -pad. Larger file should never have the same md5.

I guess the obvious answer is to not use the -dvd-compat flag then md5sum /dev/dvd would actually work.

BTW, here is the results of the dd rip from earlier: