aaru-dps/Aaru-aaru-dps
1
0
Fork 0
mirror of https://github.com/aaru-dps/Aaru.git synced 2026-02-04 00:54:33 +00:00
Code Issues 657 Packages Projects Releases 19 Wiki Activity

Aaru cannot read DDS2 tape using Sony SDT-11000 over Aaru Remote Server / Debian 5 #971

New Issue
Open
opened 2026-01-29 15:35:17 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 15:35:17 +00:00
Owner
Copy Link

Originally created by @kkaisershot on GitHub (Oct 23, 2023).

Version

5.3.0

Commit hash

No response

Tested debug version?

  • Yes

Which operating systems have you used?

  • Windows
  • Linux
  • macOS
  • Other

What is the architectural bit size you're using?

  • 32-bit
  • 64-bit
  • Unsure or unknown

What processor are you using?

  • An Intel or AMD
  • An ARM or Apple Silicon
  • Unsure or unknown

Device manufacturer

Sony

Device model

SDT-11000

Bus the device uses to attach to the computer

  • Parallel ATA
  • Serial ATA
  • SCSI (any)
  • ATAPI (mark above if parallel or serial)
  • USB
  • FireWire
  • PCMCIA
  • SecureDigital
  • MultiMediaCard

USB cable or card reader manufacturer

No response

USB cable or card reader model

No response

What were you doing when it failed?

  • I was dumping media (disk, tape, etc)...
  • I was retrieving media (disk, tape, etc) information...
  • I was scanning media (disk, tape, etc)...
  • I was retrieving device information...

Description

This bug report is rather involved and doesn't quite fit the standard template, but please bear with me while I do my best to describe it...

My Aaru setup (for the purpose of this report) consists of a standalone Arch Linux (kernel 6.0.5-arch1-1) box hosting Aaru 5.3.2 LTS, and a Debian Linux 5.0 (kernel 2.6.26-2-powerpc) Power Mac G3 beige minitower @ local IP 10.0.0.159 running Aaru Remote Server 0.99.195, specifically Git hash 6186813 which is the latest upstream as of the time of this writing. This configuration is because my Power Mac is the only machine I have with native SCSI capabilities, and I want to use Aaru to dump DDS tapes using the Sony SDT-11000 drive I have connected via the Power Mac's onboard SCSI controller. I have previously submitted a device report for the Sony SDT-11000 here: https://github.com/aaru-dps/Aaru/issues/764

The bug here is two-fold:

  1. An unmodified Aaru Remote Server built from hash 6186813 will not allow Aaru to detect the presence of my Sony SDT-11000 drive when queried via aaru device list -vd aaru://10.0.0.159 > aaru-device-list-stock-aaruremote.txt 2>&1. See aaru-device-list-stock-aaruremote.txt for full Aaru output. I also captured and attached an strace on the Power Mac by running strace -e trace=ioctl,open,read,close,write -o strace-stock-aaruremote.log linux/aaruremote as root from an unmodified local aaruremote checkout and build.

  2. When the upstream Aaru Remote Server hash 6186813 is patched to force listing /dev/st0 as a SCSI device (see attached aaruremote-blitter-st.patch), Aaru will detect it via aaru device list -vd aaru://10.0.0.159 > aaru-device-list-patched-aaruremote.txt 2>&1 -- see attached output and aaruremote strace. Furthermore, if Aaru is then used to attempt a media dump via aaru media dump -vd aaru://10.0.0.159/dev/st0 /mnt/tapetest.aaruf > aaru-media-dump-patched-aaruremote.txt 2>&1, Aaru will correctly identify the type of media in the drive, but cannot read it and aborts operation. See attached aaru-media-dump-patched-aaruremote.txt and strace-patched-aaruremote-dumping.log files for details.

Not sure whether this is an Aaru Remote Server bug or an Aaru bug (possibly both), but since an error message is reported in Aaru, I'm reporting it as an Aaru bug.

It is worth noting that the tape in question definitely has data on it and that both the tape and the drive are known working-- they work without issue in Retrospect 5 in Mac OS 9.2.2 on the same Power Mac. Indeed, I used Retrospect 5 to read and write to my test tape in preparing a minimal example for this bug report.

aaru-device-list-stock-aaruremote.txt
strace-stock-aaruremote.log
aaruremote-blitter-st.patch
aaru-device-list-patched-aaruremote.txt
strace-patched-aaruremote.log
aaru-media-dump-patched-aaruremote.txt
strace-patched-aaruremote-dumping.log

Exact command line used

aaru media dump -vd aaru://10.0.0.159/dev/st0 /mnt/tapetest.aaruf

Expected behavior

I expected Aaru to list my Sony SDT-11000 via aaru device list aaru://10.0.0.159 using an unpatched build of Aaru Remote Server running on my Power Mac / Debian 5. Failing that, I expected a patched build of Aaru Remote Server that forces listing /dev/st0 to allow Aaru to dump a test tape via aaru media dump -vd aaru://10.0.0.159/dev/st0 /mnt/tapetest.aaruf

Actual behavior

Aaru Remote Server as of hash 6186813 must be patched to force /dev/st0 on my Power Mac / Debian 5 to be listed for Aaru to detect its presence at all. But even with such a hack, Aaru cannot dump a test tape from aaru://10.0.0.159/dev/st0. "Cannot read device, don't know why, exiting..."

Output of command execution with debug output enabled

aaru 5.3.2+f4fef21d
Copyright © 2011-2023 Natalia Portillo

DEBUG (Dump-Media command): --cicm-xml=
DEBUG (Dump-Media command): --debug=True
DEBUG (Dump-Media command): --device=aaru://10.0.0.159/dev/st0
DEBUG (Dump-Media command): --encoding=
DEBUG (Dump-Media command): --first-pregap=False
DEBUG (Dump-Media command): --fix-offset=True
DEBUG (Dump-Media command): --force=False
DEBUG (Dump-Media command): --format=
DEBUG (Dump-Media command): --metadata=True
DEBUG (Dump-Media command): --options=
DEBUG (Dump-Media command): --output=/mnt/tapetest.aaruf
DEBUG (Dump-Media command): --persistent=False
DEBUG (Dump-Media command): --resume=True
DEBUG (Dump-Media command): --retry-passes=5
DEBUG (Dump-Media command): --skip=512
DEBUG (Dump-Media command): --stop-on-error=False
DEBUG (Dump-Media command): --trim=True
DEBUG (Dump-Media command): --verbose=True
DEBUG (Dump-Media command): --subchannel=any
DEBUG (Dump-Media command): --private=False
DEBUG (Dump-Media command): --fix-subchannel-position=True
DEBUG (Dump-Media command): --retry-subchannel=True
DEBUG (Dump-Media command): --fix-subchannel=False
DEBUG (Dump-Media command): --fix-subchannel-crc=False
DEBUG (Dump-Media command): --generate-subchannels=False
DEBUG (Dump-Media command): --skip-cdiready-hole=True
DEBUG (Dump-Media command): --eject=False
DEBUG (Dump-Media command): --max-blocks=64
DEBUG (Dump-Media command): --use-buffered-reads=True
DEBUG (Dump-Media command): --store-encrypted=True
DEBUG (Dump-Media command): --title-keys=True
DEBUG (Dump-Media command): Parsed options:
Connected to 10.0.0.159
DEBUG (SCSI Device): INQUIRY took 0 ms.
DEBUG (SCSI Device): INQUIRY took 4 ms.
DEBUG (ATA Device): IDENTIFY PACKET DEVICE took 0 ms.
Output image format: Aaru Format (49360069-1784-4a2f-b723-0c844d610b0a).
Device not in database, please create a device report and attach it to a Github issue.
DEBUG (SCSI Device): TEST UNIT READY took 0 ms.

DEBUG (SCSI Device): REQUEST SENSE took 4 ms.
DEBUG (SCSI Device): READ POSITION took 4 ms.

Requesting MODE SENSE (10).
Requesting MODE SENSE (6).
DEBUG (SCSI Device): MODE SENSE(6) took 0 ms.
Device reports 0 blocks (0 bytes).
DEBUG (SCSI Device): READ BLOCK LIMITS took 4 ms.
DEBUG (Media detection): SCSI medium type is 00h, density code is 24h, setting media type to DDS-2.
SCSI device type: SequentialAccess.
SCSI medium type: 0.
SCSI density type: 36.
Media identified as DDS2.
DEBUG (SCSI Device): READ (6) took 2880 ms.
Cannot read device, don't know why, exiting...
Uploading statistics

Media details

Maxell HS-4/120s DDS2

Originally created by @kkaisershot on GitHub (Oct 23, 2023). ### Version 5.3.0 ### Commit hash _No response_ ### Tested debug version? - [X] Yes ### Which operating systems have you used? - [ ] Windows - [X] Linux - [ ] macOS - [ ] Other ### What is the architectural bit size you're using? - [X] 32-bit - [X] 64-bit - [ ] Unsure or unknown ### What processor are you using? - [X] An Intel or AMD - [ ] An ARM or Apple Silicon - [X] Unsure or unknown ### Device manufacturer Sony ### Device model SDT-11000 ### Bus the device uses to attach to the computer - [ ] Parallel ATA - [ ] Serial ATA - [X] SCSI (any) - [ ] ATAPI (mark above if parallel or serial) - [ ] USB - [ ] FireWire - [ ] PCMCIA - [ ] SecureDigital - [ ] MultiMediaCard ### USB cable or card reader manufacturer _No response_ ### USB cable or card reader model _No response_ ### What were you doing when it failed? - [X] I was dumping media (disk, tape, etc)... - [ ] I was retrieving media (disk, tape, etc) information... - [ ] I was scanning media (disk, tape, etc)... - [ ] I was retrieving device information... ### Description This bug report is rather involved and doesn't quite fit the standard template, but please bear with me while I do my best to describe it... My Aaru setup (for the purpose of this report) consists of a standalone Arch Linux (kernel 6.0.5-arch1-1) box hosting Aaru 5.3.2 LTS, and a Debian Linux 5.0 (kernel 2.6.26-2-powerpc) Power Mac G3 beige minitower @ local IP 10.0.0.159 running Aaru Remote Server 0.99.195, specifically Git hash 6186813 which is the latest upstream as of the time of this writing. This configuration is because my Power Mac is the only machine I have with native SCSI capabilities, and I want to use Aaru to dump DDS tapes using the Sony SDT-11000 drive I have connected via the Power Mac's onboard SCSI controller. I have previously submitted a device report for the Sony SDT-11000 here: https://github.com/aaru-dps/Aaru/issues/764 The bug here is two-fold: 1) An unmodified Aaru Remote Server built from hash 6186813 will not allow Aaru to detect the presence of my Sony SDT-11000 drive when queried via `aaru device list -vd aaru://10.0.0.159 > aaru-device-list-stock-aaruremote.txt 2>&1`. See aaru-device-list-stock-aaruremote.txt for full Aaru output. I also captured and attached an strace on the Power Mac by running `strace -e trace=ioctl,open,read,close,write -o strace-stock-aaruremote.log linux/aaruremote` as root from an unmodified local aaruremote checkout and build. 2) When the upstream Aaru Remote Server hash 6186813 is patched to force listing /dev/st0 as a SCSI device (see attached aaruremote-blitter-st.patch), Aaru will detect it via `aaru device list -vd aaru://10.0.0.159 > aaru-device-list-patched-aaruremote.txt 2>&1` -- see attached output and aaruremote strace. Furthermore, if Aaru is then used to attempt a media dump via `aaru media dump -vd aaru://10.0.0.159/dev/st0 /mnt/tapetest.aaruf > aaru-media-dump-patched-aaruremote.txt 2>&1`, Aaru will correctly identify the type of media in the drive, but cannot read it and aborts operation. See attached aaru-media-dump-patched-aaruremote.txt and strace-patched-aaruremote-dumping.log files for details. Not sure whether this is an Aaru Remote Server bug or an Aaru bug (possibly both), but since an error message is reported in Aaru, I'm reporting it as an Aaru bug. It is worth noting that the tape in question definitely has data on it and that both the tape and the drive are known working-- they work without issue in Retrospect 5 in Mac OS 9.2.2 on the same Power Mac. Indeed, I used Retrospect 5 to read and write to my test tape in preparing a minimal example for this bug report. [aaru-device-list-stock-aaruremote.txt](https://github.com/aaru-dps/Aaru/files/13066191/aaru-device-list-stock-aaruremote.txt) [strace-stock-aaruremote.log](https://github.com/aaru-dps/Aaru/files/13066192/strace-stock-aaruremote.log) [aaruremote-blitter-st.patch](https://github.com/aaru-dps/Aaru/files/13066204/aaruremote-blitter-st.patch) [aaru-device-list-patched-aaruremote.txt](https://github.com/aaru-dps/Aaru/files/13066194/aaru-device-list-patched-aaruremote.txt) [strace-patched-aaruremote.log](https://github.com/aaru-dps/Aaru/files/13066195/strace-patched-aaruremote.log) [aaru-media-dump-patched-aaruremote.txt](https://github.com/aaru-dps/Aaru/files/13066196/aaru-media-dump-patched-aaruremote.txt) [strace-patched-aaruremote-dumping.log](https://github.com/aaru-dps/Aaru/files/13066220/strace-patched-aaruremote-dumping.log) ### Exact command line used aaru media dump -vd aaru://10.0.0.159/dev/st0 /mnt/tapetest.aaruf ### Expected behavior I expected Aaru to list my Sony SDT-11000 via `aaru device list aaru://10.0.0.159` using an unpatched build of Aaru Remote Server running on my Power Mac / Debian 5. Failing that, I expected a patched build of Aaru Remote Server that forces listing /dev/st0 to allow Aaru to dump a test tape via `aaru media dump -vd aaru://10.0.0.159/dev/st0 /mnt/tapetest.aaruf` ### Actual behavior Aaru Remote Server as of hash 6186813 must be patched to force /dev/st0 on my Power Mac / Debian 5 to be listed for Aaru to detect its presence at all. But even with such a hack, Aaru cannot dump a test tape from aaru://10.0.0.159/dev/st0. "Cannot read device, don't know why, exiting..." ### Output of command execution with debug output enabled ```shell aaru 5.3.2+f4fef21d Copyright © 2011-2023 Natalia Portillo DEBUG (Dump-Media command): --cicm-xml= DEBUG (Dump-Media command): --debug=True DEBUG (Dump-Media command): --device=aaru://10.0.0.159/dev/st0 DEBUG (Dump-Media command): --encoding= DEBUG (Dump-Media command): --first-pregap=False DEBUG (Dump-Media command): --fix-offset=True DEBUG (Dump-Media command): --force=False DEBUG (Dump-Media command): --format= DEBUG (Dump-Media command): --metadata=True DEBUG (Dump-Media command): --options= DEBUG (Dump-Media command): --output=/mnt/tapetest.aaruf DEBUG (Dump-Media command): --persistent=False DEBUG (Dump-Media command): --resume=True DEBUG (Dump-Media command): --retry-passes=5 DEBUG (Dump-Media command): --skip=512 DEBUG (Dump-Media command): --stop-on-error=False DEBUG (Dump-Media command): --trim=True DEBUG (Dump-Media command): --verbose=True DEBUG (Dump-Media command): --subchannel=any DEBUG (Dump-Media command): --private=False DEBUG (Dump-Media command): --fix-subchannel-position=True DEBUG (Dump-Media command): --retry-subchannel=True DEBUG (Dump-Media command): --fix-subchannel=False DEBUG (Dump-Media command): --fix-subchannel-crc=False DEBUG (Dump-Media command): --generate-subchannels=False DEBUG (Dump-Media command): --skip-cdiready-hole=True DEBUG (Dump-Media command): --eject=False DEBUG (Dump-Media command): --max-blocks=64 DEBUG (Dump-Media command): --use-buffered-reads=True DEBUG (Dump-Media command): --store-encrypted=True DEBUG (Dump-Media command): --title-keys=True DEBUG (Dump-Media command): Parsed options: Connected to 10.0.0.159 DEBUG (SCSI Device): INQUIRY took 0 ms. DEBUG (SCSI Device): INQUIRY took 4 ms. DEBUG (ATA Device): IDENTIFY PACKET DEVICE took 0 ms. Output image format: Aaru Format (49360069-1784-4a2f-b723-0c844d610b0a). Device not in database, please create a device report and attach it to a Github issue. DEBUG (SCSI Device): TEST UNIT READY took 0 ms. DEBUG (SCSI Device): REQUEST SENSE took 4 ms. DEBUG (SCSI Device): READ POSITION took 4 ms. Requesting MODE SENSE (10). Requesting MODE SENSE (6). DEBUG (SCSI Device): MODE SENSE(6) took 0 ms. Device reports 0 blocks (0 bytes). DEBUG (SCSI Device): READ BLOCK LIMITS took 4 ms. DEBUG (Media detection): SCSI medium type is 00h, density code is 24h, setting media type to DDS-2. SCSI device type: SequentialAccess. SCSI medium type: 0. SCSI density type: 36. Media identified as DDS2. DEBUG (SCSI Device): READ (6) took 2880 ms. Cannot read device, don't know why, exiting... Uploading statistics ``` ### Media details Maxell HS-4/120s DDS2
claunia added the bugneeds triagemedia labels 2026-01-29 15:35:17 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
archive
beginner
bug
bug
dependencies
device
device
dump image format
duplicate
Epic
feature request
filesystem
filter
gui
gui
gui
help wanted
invalid
invalid
media
needs triage
partitioning scheme
pull-request
Mirrored from GitHub Pull Request
 upstream
wontfix
No Label bug media needs triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: aaru-dps/Aaru-aaru-dps#971
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?