Re: How to use dmsetuup?
On 11/5/23 14:16, Thomas Schmitt wrote:
David Christensen wrote:
Adding checksum file(s) to the contents burned to disc is an important step
that should not be omitted
I let xorriso compute and store the checksums in a non-file block range
at the end of the ISO filesystem. Each file gets an AAIP attribute which
points to an MD5 in this checksum array.
The user only has to issue the xorriso command -for_backup or -md5 "on".
Are there tools other than xorriso(1) that can create a compatible
checksum? Read the checksum?
My approach is *.md5 and *.sha256 sister files for each archive
encrypted tarball file.
Thomas Schmitt wrote:
i only once in my life watched a DVD giving bad data without an SCSI
error.
Interesting. My WAG is that there was a marginal/ ambiguous dot on disc (?).
The astonishing fact is not the damaged data chunk but the drive's failure
to recognize the damage. There are substantial parity data wrapped around
each DVD "ECC Block" which the drive may use for error detection and
possibly for correction. If i count correctly in MMC-5 Figure 26, then
32 KiB payload data get added 192 * 10 + 15 * 182 = 4650 bytes of parity
data. ECMA-337 (about DVD+RW) mentions in 13.1 two more checksums with
6 bytes per 2048 bytes of payload data.
With such much of redundancy it is highly unlikely that an alteration
stays undetected or that an error correction yields a wrong result.
Nevertheless in this special combination of medium and drive the error was
not reported or corrected by the drive but rather a wrong data chunk was
handed out.
At that occasion an MD5 recorded by xorriso indicated the error.
Comparing the read results on several drives showed that it was about a
single ECC block of 32 KiB payload.
I was thinking opto-electronics -- phototransistor and analog-to-digital
conversion -- but you are right: the error detection and error
correction math should be the same on all the drives and they all should
have caught a bad bit (or combination of bad bits). Then again,
implementing algorithms from standards is non-trivial; bugs are not
uncommon. Perhaps the cause was a combination of both. But, your
xorriso(1) MD5 checksum added one more layer of defense and that saved
the day.
I seem to recall a post by you that indicated *BSD lacked the features
needed for good optical drive/ media/ format support.
I have difficulties to remember ...
Can I get xorriso(1) on FreeBSD?
I don't have a FreeBSD test machine any more. So we have to rely on the
web ... xorriso seems to be available in the versions as in Sid (1.5.6)
and Buster (1.5.0):
https://www.freshports.org/sysutils/xorriso/
GNU xorriso should compile on FreeBSD out of the box:
https://www.gnu.org/software/xorriso/#download
Older versions available on
https://ftp.gnu.org/gnu/xorriso
User experience reports are welcome.
Bingo!
2023-11-05 14:39:58 dpchrist@f3 ~
$ freebsd-version -kru ; uname -a
12.4-RELEASE-p6
12.4-RELEASE-p6
12.4-RELEASE-p6
FreeBSD f3.tracy.holgerdanske.com 12.4-RELEASE-p6 FreeBSD
12.4-RELEASE-p6 GENERIC amd64
2023-11-05 14:40:05 dpchrist@f3 ~
$ pkg search xorriso
xorriso-1.5.6 ISO image manipulation tool based on
Libburnia
David
Reply to: