Guymager and Zip drives

[aber...@gmail.com]

Hi all,

I am running into a problem imaging Iomega Zip disks with Guymager. I am using an Iomega Zip 750 drive with a Firewire to USB connection. 

I am getting a few errors on the "Device Info" page that are preventing me from successfully imaging the disk (see attachment "DeviceInfo_Guymager.png").

The error that has given me the most information is: "/dev/sdb: Uknown USB bridge"

From some googling, I've found a way to see if the computer recognizes the USB device by using the smartctl command in the terminal: smartctl -x -d usbcypress /dev/sdb. I attached a screen capture of the command and terminal output proving the computer is able to recognize the Zip drive, but it doesn't provide any additional information about the drive like it should (see attachment "smartctl_output.png").

Background info: I am using Guymager in a dedicated install of BitCurator. I believe these are Apple formatted zip disks (when I attempted to image them using the FRED + FTK Imager, it showed Apple formatted files). I have tried to swap out the cable, and used 3 different USB-Firewire cables, in all of the available USB ports on the computer running BitCurator, which resulted in the same errors. I have also tried plugging the zip drive into another machine running a Linux environment, tried the smartctl command, and got the same results. The cables functioned when they were plugged into the UltraBay write blockers on the FRED. 

Has anyone experienced something similar, or have any idea what may be causing this problem? 

All thoughts are welcome and any guidance would be appreciated! 

Amy Berish

Assistant Archivist

Rockefeller Archive Center

Sleepy Hollow, NY

 

 

 

[Matthew Disregardmatthew Farrell]

Hi Amy - 

I haven't run into this specific issue, but I've not had a ton of experience with ZIP drives. Can you clarify, is the Firewire-->USB connector a built-in output option for the ZIP drive, or are you using an adapter? 

In a completely different scenario (IDE HDD) some time ago, I was unable to get an OS to recognize the HDD when using an IDE-->USB adapter attached to a USB write-blocker. There was no issue when connecting that same HDD to a write blocker that could connect to IDE without an adapter, however. Sorry if this is irrelevant, but it was unclear to me from your message whether you were using an adapter or not.

best,

farrell

--
You received this message because you are subscribed to the Google Groups "BitCurator Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-use...@googlegroups.com.
To post to this group, send email to bitcurat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/371504a0-dc9c-4902-8002-7843d38d6306%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aber...@gmail.com]

Hi, 

The firewire-USB connection is not built-in to the zip drive (see example image below). I was able to try a bunch of different firewire-USB cables so I know that it is not a specific cord that is causing the problem. Unlike the picture below, I am not plugging the zip drive into a write blocker that is plugged into the computer using BitCurator - my drive is plugged straight into the computer (this is for testing reasons, I am aware of the importance of using write blockers during imaging)

(source: https://www.cca.qc.ca/en/issues/3/technology-sometimes-falls-short/49023/how-to-access-digital-files-from-the-nineties)

At this point, I have doubts that it is a hardware problem, especially since I have tried various cables and connected the drive to multiple computers. As I mentioned earlier, I had no problem reading data from the drive when it was plugged into the FRED - which is why I am feeling so stumped. I believe that it might have something to do with either Guymager, BitCurator, or simply using this drive on a Linux environment.

Amy

[Allen Kwan]

I’m sure this is a long shot, could it be a driver issue with Bitcurator?

I saw that there was one out there supported more exotic hardware.

http://manpages.ubuntu.com/manpages/cosmic/man4/umass.4freebsd.html#description

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/3e88f3af-b1c6-4d29-a0f6-9f52d3a37be0%40googlegroups.com.

[Lode s]

Hi, 
We had the exact same error when we where trying the capture iOmega Jaz disks,  "/dev/sda: Uknown USB bridge". With both our ultra SCSI to USB cables.
The issue is not the cable or the drive, we managed to read the jaz disks fine with dd and or rsync. The disk even mounts normally on our Bitcurator 20.04. 
After the error from Guymager the disk would not eject. 
If anyone has any updates on this, it would be appreciated. 

Nastasia & Lode
Meemoo VZW 
Gent 
Belgium

[co...@digitalsleuth.ca]

Hi all, I've looked into this and it's not an issue with BitCurator. The error you're seeing is coming from a Guymager command issued to detect the disk (as seen in the output from Amy Berish in the Guymager DeviceInfo tab), but the error is actually from smartctl. Neither of these tools are broken or misconfigured, they're just not set up to search for anything which doesn't connect using either SATA, IDE, or standard USB protocols. You might get more results from using smartctl -d scsi /dev/<whatever your disk identifier is> since it may actually be using the SCSI protocol.

The error you're getting is that Guymager is not built to dynamically determine the disk type, it has a set of static commands which it runs, and the necessary command for this type of device isn't included. This won't prevent you from mounting and accessing the disk in Bitcurator, you just won't be able to use Guymager to do what you need.

Hope this helps.