Puzzling difference between debian-arm and debian-i386 re growisofs
I wonder whether anyone can help a very puzzled moderately skilled
debian and NSLU2 hacker? Apologies for the length of explanation needed.
I have several i386 machines running etch, lenny and sid, and an NSLU2
running etch which for some time has acted as my main fileserver. On
one of the i386 machines, I have a great process for backing up key data
files to DVD, based on http://patrick.newedorf.net/backup (now only
available from WayBackMachine - but many thanks, Patrick!) which
produces daily, dated backups on one DVD without unnecessarily
duplicating data. This uses the dvd+rw-tools package, specifically
using the growisofs command to write more data to a DVD which already
holds some.
I am now trying to move this backup process to run directly off the NSLU2.
To summarise in the briefest possible detail, the following process
gives different results on the NSLU2/etch and on an i386/etch:
* using a usb DVD-writer (the same one)
* burn a fresh DVD-RW (or DVD-R) with base data, using growisofs -R to
get Rock Ridge extensions for filenames
* use growisofs to write more data to the DVD-RW (or DVD-R)
On the i386/etch, this works fine, with messages including
Rock Ridge signatures found
On the NSLU2/etch (with the SAME usb DVD-writer and exactly the same
scripts) the last step fails, giving messages including:
genisoimage: **BAD RRVERSION (0) for �
NO Rock Ridge present
Disabling Rock Ridge / XA / AA
HOWEVER, mounting the very same DVD on the NSLU2/etch is perfectly
successful, the Rock Ridge signatures are recognised and used.
See the PS at the end for the effectively identical mkisofs=genisoimage
commands logged.
I am extremely puzzled by this. Google has been no help, nor has
searching this list; I have performed lots of experiments to elucidate
or work around, like using -T or -udf (without success), and I can't
follow the genisoimage/growisofs source well enough to understand what's
going on. I haven't tried upgrading the NSLU2 to lenny - I'd rather
not, and the above suggests the anomaly would persist.
BTW, this does NOT seem to be the same problem as bug#457308 and its
ilk, which seem to relate fundamentally to Mac/i386 differences.
I'm aware this may well be a dvd+rw-tools problem, but I'm avoiding
cross-posting at this point, as it seems to involve an arm vs i386
difference.
Anyone had a similar experience? I'm stumped to believe any of the
unlikely looking explanations I can think of, such as:
* the NSLU2/arm accesses the usb drive differently or sees the iso9660
filesystem differently (but why then can it see the Rock Ridge via
mount, but not with growisofs? The answer may lie in the low level
drive access used by growisofs, but would this miss the Rock Ridge??)
* the problem would go away with later versions of DVD+RW-tools (but it
isn't there with THESE versions on i386, and the changelogs don't
suggest any relevant fixes).
I'd be happy to provide more details, or do more experiments. For now,
the kernels are:
2.6.18-6-k7 and 2.6.18-6-ixp4xx
and in both the i386 and NSLU2 contexts the software versions are:
||/ Name Version
+++-============================-============================
ii dvd+rw-tools 7.0-4
ii genisoimage 1.1.2-1
ii libc6 2.3.6.ds1-13etch5
Many thanks for reading this far! And even more thanks for any helpful
comments.
Barry
PS for completeness, the two growisofs outputs before the different Rock
Ridge messages shown above are nearly identical, apart from explicable
date/time changes:
------ on i386/etch:
Executing 'mkisofs -C 16,736 -M /dev/fd/3 -root backup-2008-04-15-18:11
-old-root backup-2008-04-15-18:09 -quiet -R -D -graft-points /etc=/etc |
builtin_dd of=/dev/sr0 obs=32k seek=46'
Rock Ridge signatures found
------ on NSLU2/etch:
Executing 'mkisofs -C 16,736 -M /dev/fd/3 -root backup-2008-04-15-19:14
-old-root backup-2008-04-15-18:12 -quiet -R -D -graft-points /etc=/etc |
builtin_dd of=/dev/sr1 obs=32k seek=46'
genisoimage: **BAD RRVERSION (0) for �
------
Reply to: