[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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: