I have a Creative Zen Vision M that has a ZIF Drive (so it's described on the Internet). It seems that iPods and competitors like the Creative Zen Vision M had a disk drive falling into the general category of ZIF. About a year ago, the device stopped working (wouldn't start).
However, when I plugged it in to recharge, the drive was definitely spinning. Youtube has enough videos describing how to disassemble the device, and Amazon has caddies for the drive so that you can plug it into a USB port.
I got one of the caddies, placed the drive into it, connected the cable, and the drive can be seen when doing lsusb. But its not mountable given whatever instructions I have been able to find. I do get the following descriptions when I issue #> smartctl -i -d scsi -T permissive /dev/sdc
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.15-200.fc31.x86_64] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION === Vendor: HTC42603 Product: 0G5CE00 User Capacity: 30,005,821,440 bytes [30.0 GB] Logical block size: 512 bytes scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Terminate command early due to bad response to IEC mode page
The size is 30GB. Reading from the label on the disk: Hitachi hard disk drive Model: HTC426030G5CE00 (a match) Attn Travelstar 30GB 4200 rpm APR-06
Is there a way to mount this drive in order to recover the data?
Much thanks,
Max Pyziur pyz@brama.com
On 2/6/20 8:06 AM, Max Pyziur wrote:
I have a Creative Zen Vision M that has a ZIF Drive (so it's described on the Internet). It seems that iPods and competitors like the Creative Zen Vision M had a disk drive falling into the general category of ZIF. About a year ago, the device stopped working (wouldn't start).
However, when I plugged it in to recharge, the drive was definitely spinning. Youtube has enough videos describing how to disassemble the device, and Amazon has caddies for the drive so that you can plug it into a USB port.
I got one of the caddies, placed the drive into it, connected the cable, and the drive can be seen when doing lsusb. But its not mountable given whatever instructions I have been able to find. I do get the following descriptions when I issue #> smartctl -i -d scsi -T permissive /dev/sdc
It's being recognized. What do the journal logs show from when you plugged it in?
Is there a way to mount this drive in order to recover the data?
Maybe the reason the device stopped working was because the drive was dead?
On Thu, 6 Feb 2020, Samuel Sieb wrote:
On 2/6/20 8:06 AM, Max Pyziur wrote:
I have a Creative Zen Vision M that has a ZIF Drive (so it's described on the Internet). It seems that iPods and competitors like the Creative Zen Vision M had a disk drive falling into the general category of ZIF. About a year ago, the device stopped working (wouldn't start).
However, when I plugged it in to recharge, the drive was definitely spinning. Youtube has enough videos describing how to disassemble the device, and Amazon has caddies for the drive so that you can plug it into a USB port.
I got one of the caddies, placed the drive into it, connected the cable, and the drive can be seen when doing lsusb. But its not mountable given whatever instructions I have been able to find. I do get the following descriptions when I issue #> smartctl -i -d scsi -T permissive /dev/sdc
It's being recognized. What do the journal logs show from when you plugged it in?
This is what journalctl -f reports when it's plugged in: Feb 06 17:39:43 pegasus kernel: usb 3-1: new high-speed USB device number 3 using xhci_hcd Feb 06 17:39:43 pegasus kernel: usb 3-1: New USB device found, idVendor=14cd, idProduct=6600, bcdDevice= 2.01 Feb 06 17:39:43 pegasus kernel: usb 3-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2 Feb 06 17:39:43 pegasus kernel: usb 3-1: Product: USB 2.0 IDE DEVICE Feb 06 17:39:43 pegasus kernel: usb 3-1: Manufacturer: Super Top Feb 06 17:39:43 pegasus kernel: usb 3-1: SerialNumber: †††††††㉌㉊夷 Feb 06 17:39:43 pegasus kernel: usb-storage 3-1:1.0: USB Mass Storage device detected Feb 06 17:39:43 pegasus kernel: usb-storage 3-1:1.0: Quirks match for vid 14cd pid 6600: 20 Feb 06 17:39:43 pegasus kernel: scsi host6: usb-storage 3-1:1.0 Feb 06 17:39:43 pegasus mtp-probe[43141]: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1" Feb 06 17:39:43 pegasus mtp-probe[43141]: bus: 3, device: 3 was not an MTP device Feb 06 17:39:43 pegasus mtp-probe[43148]: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1" Feb 06 17:39:43 pegasus mtp-probe[43148]: bus: 3, device: 3 was not an MTP device Feb 06 17:39:43 pegasus Thunar[2003]: thunar-volman: Unsupported USB device type "usb". Feb 06 17:39:43 pegasus Thunar[2003]: thunar-volman: Unsupported USB device type "usb-storage". Feb 06 17:39:44 pegasus kernel: scsi 6:0:0:0: Direct-Access HTC42603 0G5CE00 PQ: 0 ANSI: 0 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] 58605120 512-byte logical blocks: (30.0 GB/27.9 GiB) Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Mode Sense: 03 00 00 00 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] No Caching mode page found Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Feb 06 17:39:44 pegasus Thunar[2003]: thunar-volman: Unknown block device type "disk".
Is there a way to mount this drive in order to recover the data?
Maybe the reason the device stopped working was because the drive was dead?
Per this stackexchange page, my results are typical: https://unix.stackexchange.com/questions/39064/smartctl-on-external-hdd-insi...
MP pyz@brama.com
On 2/6/20 2:43 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
On 2/6/20 8:06 AM, Max Pyziur wrote:
I have a Creative Zen Vision M that has a ZIF Drive (so it's described on the Internet). It seems that iPods and competitors like the Creative Zen Vision M had a disk drive falling into the general category of ZIF. About a year ago, the device stopped working (wouldn't start).
However, when I plugged it in to recharge, the drive was definitely spinning. Youtube has enough videos describing how to disassemble the device, and Amazon has caddies for the drive so that you can plug it into a USB port.
I got one of the caddies, placed the drive into it, connected the cable, and the drive can be seen when doing lsusb. But its not mountable given whatever instructions I have been able to find. I do get the following descriptions when I issue #> smartctl -i -d scsi -T permissive /dev/sdc
It's being recognized. What do the journal logs show from when you plugged it in?
This is what journalctl -f reports when it's plugged in: Feb 06 17:39:44 pegasus kernel: scsi 6:0:0:0: Direct-Access HTC42603 0G5CE00 PQ: 0 ANSI: 0 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] 58605120 512-byte logical blocks: (30.0 GB/27.9 GiB) Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Mode Sense: 03 00 00 00 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] No Caching mode page found Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Feb 06 17:39:44 pegasus Thunar[2003]: thunar-volman: Unknown block device type "disk".
I assume this was a different time than before. You had sdc before and this is sdb. What do "fdisk -l /dev/sdb" and "file -s /dev/sdb" give you? (Replace block device name as necessary.)
On Thu, 6 Feb 2020, Samuel Sieb wrote:
On 2/6/20 2:43 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
On 2/6/20 8:06 AM, Max Pyziur wrote:
I have a Creative Zen Vision M that has a ZIF Drive (so it's described on the Internet). It seems that iPods and competitors like the Creative Zen Vision M had a disk drive falling into the general category of ZIF. About a year ago, the device stopped working (wouldn't start).
However, when I plugged it in to recharge, the drive was definitely spinning. Youtube has enough videos describing how to disassemble the device, and Amazon has caddies for the drive so that you can plug it into a USB port.
I got one of the caddies, placed the drive into it, connected the cable, and the drive can be seen when doing lsusb. But its not mountable given whatever instructions I have been able to find. I do get the following descriptions when I issue #> smartctl -i -d scsi -T permissive /dev/sdc
It's being recognized. What do the journal logs show from when you plugged it in?
This is what journalctl -f reports when it's plugged in: Feb 06 17:39:44 pegasus kernel: scsi 6:0:0:0: Direct-Access HTC42603 0G5CE00 PQ: 0 ANSI: 0 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] 58605120 512-byte logical blocks: (30.0 GB/27.9 GiB) Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Mode Sense: 03 00 00 00 Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] No Caching mode page found Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through Feb 06 17:39:44 pegasus kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Feb 06 17:39:44 pegasus Thunar[2003]: thunar-volman: Unknown block device type "disk".
I assume this was a different time than before. You had sdc before and this is sdb.
No, I had a USB flashdrive on /dev/sdb when I first reported this. The ZIF drive showed up on /dev/sdc.
What do "fdisk -l /dev/sdb" and "file -s /dev/sdb" give you? (Replace block device name as necessary.)
~> fdisk -l /dev/sdb Disk /dev/sdb: 27.97 GiB, 30005821440 bytes, 58605120 sectors Disk model: 0G5CE00 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ~> file -s /dev/sdb /dev/sdb: data
MP pyz@brama.com
_______________________________________________
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2/6/20 3:21 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
What do "fdisk -l /dev/sdb" and "file -s /dev/sdb" give you? (Replace block device name as necessary.)
~> fdisk -l /dev/sdb Disk /dev/sdb: 27.97 GiB, 30005821440 bytes, 58605120 sectors Disk model: 0G5CE00 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ~> file -s /dev/sdb /dev/sdb: data
If that's the drive, then that's not looking good for getting anything off of it. What does this show: dd if=/dev/sdb bs=1K count=1 | od -a
On Thu, 6 Feb 2020, Samuel Sieb wrote:
On 2/6/20 3:21 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
What do "fdisk -l /dev/sdb" and "file -s /dev/sdb" give you? (Replace block device name as necessary.)
~> fdisk -l /dev/sdb Disk /dev/sdb: 27.97 GiB, 30005821440 bytes, 58605120 sectors Disk model: 0G5CE00 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ~> file -s /dev/sdb /dev/sdb: data
If that's the drive, then that's not looking good for getting anything off of it. What does this show: dd if=/dev/sdb bs=1K count=1 | od -a
1+0 records in 1+0 records out 0000000 K L B M nul stx nul nul @ > ~ etx nul nul nul nul 1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00131726 s, 777 kB/s 0000020 nul dle soh nul soh nul nul nul m i n i f s nul nul 0000040 ? . | etx soh dle soh nul c f s nul nul nul nul nul 0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul * 0001000 soh nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul 0001020 nul nul nul nul nul nul nul | nul nul nul nul nul nul nul nul 0001040 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul * 0002000
MP pyz@brama.com
On 2/6/20 3:57 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
If that's the drive, then that's not looking good for getting anything off of it. What does this show: dd if=/dev/sdb bs=1K count=1 | od -a
1+0 records in 1+0 records out 0000000 K L B M nul stx nul nul @ > ~ etx nul nul nul nul 1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00131726 s, 777 kB/s 0000020 nul dle soh nul soh nul nul nul m i n i f s nul nul 0000040 ? . | etx soh dle soh nul c f s nul nul nul nul nul 0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
It turns out that the device uses a "special" filesystem. I recommend making a copy of the hard drive and working with that. Here's a script that looks like it can get the files off: https://gist.github.com/joemck/483969
On Thu, 6 Feb 2020, Samuel Sieb wrote:
On 2/6/20 3:57 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
If that's the drive, then that's not looking good for getting anything off of it. What does this show: dd if=/dev/sdb bs=1K count=1 | od -a
1+0 records in 1+0 records out 0000000 K L B M nul stx nul nul @ > ~ etx nul nul nul nul 1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00131726 s, 777 kB/s 0000020 nul dle soh nul soh nul nul nul m i n i f s nul nul 0000040 ? . | etx soh dle soh nul c f s nul nul nul nul nul 0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
It turns out that the device uses a "special" filesystem. I recommend making a copy of the hard drive and working with that. Here's a script that looks like it can get the files off: https://gist.github.com/joemck/483969
Much thanks for your help on this.
Some progress, but no recovery yet. The script does run for a while, the ZIF caddy light blinks like a typical drive light, and then it exits after a minute or so with the following message: Traceback (most recent call last): File "/home/pyz/projects/Documents/VideosMP3s/ZenRecover/zenrecover.py", line 251, in <module> raise "Could not find the root inode" TypeError: exceptions must be old-style classes or derived from BaseException, not str
From reading the python script, it requires four command line arguments. The first of these, the argument for the disk, requires an offset for the filesystem start.
So far, I've used /dev/sdb but have not specified an offset since the brief help screen indicates that the default offset is 20M.
I'm uncertain if this (not specifying the offset) is the cause of the error.
Thanks again,
M pyz@brama.com
On 2/6/20 6:47 PM, Max Pyziur wrote:
On Thu, 6 Feb 2020, Samuel Sieb wrote:
It turns out that the device uses a "special" filesystem. I recommend making a copy of the hard drive and working with that. Here's a script that looks like it can get the files off: https://gist.github.com/joemck/483969
Much thanks for your help on this.
Some progress, but no recovery yet. The script does run for a while, the ZIF caddy light blinks like a typical drive light, and then it exits after a minute or so with the following message: Traceback (most recent call last):
So far, I've used /dev/sdb but have not specified an offset since the brief help screen indicates that the default offset is 20M.
I'm uncertain if this (not specifying the offset) is the cause of the error.
First, please make an image of the disk to work with instead of the original drive. I don't know what your programming skills are like, but I would suggest determining what the script is looking for and scanning the image to locate it.
Since this is not Fedora related and a rather niche problem, feel free to contact me off-list to continue this discussion.
-
Max Pyziur -
Samuel Sieb