Talk:Optical disc drive
Verifying the burnt ISO image
Although the part with getting the md5sum of the previously created ISO image is quite obvious, the part with verifying the actual contents of the burnt disc seems to be somewhat inaccurate.
As soon as you have an alias like alias ls='ls-hF --color=auto' in your .profile, which could come in handy, the mentioned method for getting the block count is wrong:
$ blocks=$(expr $(ls -l isoimage.iso | awk '{print $5}') / 2048)
To make sure the calculated block count is valid for various user defined environments I would recommend the use of du -b:
$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)
That's what I just stumbled upon while trying to verify my burnt image.
- I did not think of such aliases. My ~/.bashrc has: alias ls=ls
- Your proposed du seems less prone to aliasing. Option -b is promised to be safe from pitfalls of sparse files. So i will put it into the wiki.
- I wonder, though, whether stat(1) would be ubiquitous enough in archlinux:
- $ blocks=$(expr $(stat -c '%s' isoimage.iso) / 2048)
- Scdbackup (talk) 15:42, 29 August 2013 (UTC)
- General thoughts:
- alias is an arbitrary nasty problem with shell commands, of course. One cannot avoid it by alias ls=ls in a sub shell. man 1 bash is merciless in that aspect. Inquiring alias manually, unaliasing, executing size determination, re-aliasing ... is much too complicated. Should we bet on the existence of /bin/ls or /bin/du ? Any other ideas to surely prevent alias evaluation in an interactive command ? Scdbackup (talk) 16:09, 29 August 2013 (UTC)
- Research:
- http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/bin.html and http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard promise the existence of /bin/ls . du is not listed there. So /bin/ls is currently my best bet to prevent alias evaluation.
- I will wait a few days for objections or better ideas before changing the size command in the wiki page again. Please keep me from doing stupid things. Scdbackup (talk) 16:27, 29 August 2013 (UTC)
- Of course there's no way to find a one-size-fits-all solution, maybe it's just worth to quickly mention the problem and propose the ls method as an alternative. I'd keep du as the main method because it's indeed less likely to be aliased. About its existence on all systems, this is the wiki for Arch Linux, whose basic, default installation includes coreutils, where both ls and du are provided. -- Kynikos (talk) 03:55, 31 August 2013 (UTC)
- du -b seems quite robust. I tried to fool it by alias definitions like du='du --human-readable'. But an explict option -b overrides it properly. I still get the byte count. (Sequence matters. du -b --human-readable would show e.g. "590M"). My doubts about availability are rather about stat(1). It would be more appealing than du, because du's main job is to report disk usage, not the addressable byte size.
- One of the problems i feared is demonstrated by :
- dd if=/dev/zero bs=1 count=1 seek=10000000 of=/tmp/sparse_test ; ls -l /tmp/sparse_test ; du /tmp/sparse_test ; du -b /tmp/sparse_test
- On my machine i get a file of adressable 10000001 bytes which uses only 12 disk blocks of 1 KB. But du -b does it right. So for now i postpone my plan to change the size determination once again. Scdbackup (talk) 09:30, 31 August 2013 (UTC)
- The current command for calculating the block size gives a syntax error because I have the following alias alias du=du -c -h' in my .zshrc. The -c results in another row of output and the expr fails, the following change to the command solves this issue. I'm not really sure if its worth including it in the wiki but I thought I'll leave a suggestion here.
- $ blocks=$(expr $(du -b isoimage.iso | awk 'NR==1{print $1}') / 2048)
- The NR==1 makes sure that only the first row of output is used for the expression. --Saifazmi (talk) 13:54, 9 January 2018 (UTC)
restructure to read/play/write
can we slightly restructure the article please into three paragraphs:
- read / copy, includes mount, read an iso image
- write / burn, includes creating iso9660 image
- play
the problem is that currently the paragraph to read an image is kind of hidden in a paragraph called "burning". i fell over this as i did not want to burn a dvd, but just copy one to disk and play to avoid scratching it. so i tried all the tools listed in ripping and none worked. it took a while to clue into the fact that one could just copy the iso off the disk and play it like one would do with an optical disk, no need to rip it. --Soloturn (talk) 04:30, 5 January 2017 (UTC)
- Copying an optical disk means reading one disk and writing it to another optical disk. As it involves both reading and burning, it is too strict to split these topics. Also, Ripping is a topic of its own as it implies time-consuming transcoding of the media into a different format, so I don't agree with this organization. -- Lahwaacz (talk) 09:24, 5 January 2017 (UTC)
how do we solve it then, duplicate the info? ask somebody else what he thinks? --Soloturn (talk) 19:45, 5 January 2017 (UTC)
ISO 9660 and burning on-the-fly
The command provided for burning a DVD on the fly is missing the -dvd-compat parameter.
$ growisofs -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso
I suggest that the command mentioned above changes to include the -dvd-compat parameter.
$ growisofs -dvd-compat -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso
As without it once the data has been written to the DVD it cannot be mounted using the mount command, resulting in the following error.
$ sudo mount /dev/sr0 /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error.
The wiki already mentions the -dvd-compat parameter under the Burning an ISO image to CD, DVD, or BD section
$ growisofs -dvd-compat -Z /dev/sr0=isoimage.iso
But it's somehow missing from the ISO 9660 and burning on-the-fly section.
--Saifazmi (talk) 18:15, 9 January 2018 (UTC)
Suggestion for Verifying the burnt ISO image
EDIT: I just realized that the cat
is totally unnecessary if you remove the second process substitution. Also cleaned up some grammar.
Ksd (talk) 17:13, 21 May 2019 (UTC)
I came up with a modified method for verifying the burnt ISO that eliminates the tedium and human error of having to eyeball two hashes but I wanted to run it past everyone first. It uses dd the same way as before but rather than use md5 it uses diff and process substitution (for those who don't know process substitution is basically a convenient way to use named pipes and is a feature common to all modern shells going as far back as ksh).
With this method you're reading every byte of the ISO and the drive (using the $block count) just as before but you're avoiding all the CPU intensive hashing and instead just comparing the bytes directly.
Suggested method below:
You can verify the integrity of the burnt medium to make sure it contains no errors. Always eject the medium and reinsert it before verifying. It will guarantee that not any kernel cache will be used to read the data.
First calculate the block count of the ISO file. Although some media types deliver exactly the same amount of data as have been submitted to the burn program, many others append trailing garbage when being read. So you should restrict reading to the size of the ISO image file.
$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)
Next perform a byte comparison between the ISO file and the ISO file system on the medium.
$ diff <(dd if=/dev/sr0 bs=2048 count=$blocks) isoimage.iso
43992+0 records in 43992+0 records out 90095616 bytes (90 MB) copied, 0.359539 s, 251 MB/s
There should be no message stating the Binary files differ. If there is one, you will probably also get an I/O error message from the dd
run. dmesg
might then tell about SCSI errors and block numbers, if you are interested.
Ksd (talk) 00:49, 20 October 2018 (UTC)
isosize
, determine the size of the burnt image, and verification
Am I right that most of the discussion here about verifying the burnt image, #Verifying the burnt ISO image and #Suggestion for Verifying the burnt ISO image, revolves around the method to determine the burnt image size? In that case, was
# isosize /dev/sr0
mentioned? Doesn't it adequate for the task?