10:06 a.m.
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(a)brama.com
12:03 p.m.
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?
4:43 p.m.
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-i...
MP
pyz(a)brama.com
4:53 p.m.
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.)
5:21 p.m.
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(a)brama.com
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
5:34 p.m.
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
5:57 p.m.
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(a)brama.com
6:35 p.m.
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
8:47 p.m.
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(a)brama.com
9:54 p.m.
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.
1538
days inactive
1539
days old
9 comments
2 participants
participants (2)
-
Max Pyziur -
Samuel Sieb