Not a problem with Fedora as such, but perhaps someone might help.
I’ve recently bought a 2TB Toshiba Canvio Basics external hard disk. I could plug it in and started writing on it, but then it accidentally dropped and disconnected. Then I could no longer access its content. So I tried to format it (the only operation I was allowed to do). I tried to format it as password-protected EXT4. This was taking absurdly long (after 5 hours it had done 0.3%, estimated one month and a half left…), so I had to interrupt it. Since then I can no longer access the drive in any way. I have tried to restart the formatting with a faster method but in the ‘Disks’ utility I get the message: ‘Error wiping device: Failed to probe the device ‘/dev/sdc’ (udisks-error-quark, 0)’. I’ve tried several lines of advice found online, including the Fedora-recommended method for creating a partition, but I get error each time - the device is seen (it appears on /dev/sdc when I connect it, and the ‘Disks’ utility recognises it as Toshiba etc), but cannot be accessed.
I use Fedora 38.
The manufacturer doesn’t offer Linux support, they say that since the disk doesn’t work, to try asking for a replacement under warranty, but this feels dishonest - it was working when I got it.
Any advice would be priceless.
You mean physically dropping it? HDDs are delicate inside and are sensitive to rough handling.
Can you show what dmesg reports when the formatting fails?
[19536.792457] sd 3:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[19536.792473] sd 3:0:0:0: [sdc] tag#0 Sense Key : Medium Error [current]
[19536.792484] sd 3:0:0:0: [sdc] tag#0 Add. Sense: Unrecovered read error
[19536.792495] sd 3:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
[19536.792502] critical medium error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[19536.792517] Buffer I/O error on dev sdc, logical block 0, async page read
[19536.792545] ldm_validate_partition_table(): Disk read failed.
[19536.793776] Buffer I/O error on dev sdc, logical block 0, async page read
[19536.797735] sdc: unable to read partition table
Yes, it physically dropped, not from a great height, I don’t think/I hope it’s not physically damaged (though it may), but it disconnected from the USB plug.
> parted -l
[...]
Error: /dev/sdc: unrecognised disk label
Model: TOSHIBA EXTERNAL_USB (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Model: Unknown (unknown)
Disk /dev/zram0: 8590MB
Sector size (logical/physical): 4096B/4096B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 8590MB 8590MB linux-swap(v1)
> parted /dev/sdc
GNU Parted 3.5
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
Error: Input/output error during read on /dev/sdc
Retry/Ignore/Cancel?
This looks like physical damage to your disk. Try running the badblocks utility to detect bad sectors.
You probably should also try some SMART self tests.
But the errors began to appear not after the disk fell, they began to appear after I interrupted the formatting. After the disk fell, I could not access its content - which may well have been due to an unclean mount, or something else that did not necessarily indicate physical damage.
One question is why the formatting was taking so absurdly long - I cannot rule out that this was because there had been some physical damage. But the errors began to appear after I interrupted the formatting, not after the disk fell.
I’ll try badblocks and report back. I don’t know which other SMART self tests to do, apart from the output I quoted above.
Seagate seems to define this as “Frequency of mistakes as a result of impact loads as detected by a shock sensor(?).” so there is evidence left showing the drive suffered a shock. Portable/laptop drives are expected to survive minor shocks, so it is possible that the drive is OK if your can find a way to correct the “mistakes”. It is possilble that some “mistakes” affect internal housekeeping data not accessible by user tools. If Seagate is willing to replace the drive that may be your easy solution.
What is not clear to me: why do these testing tools have access to the disk, but when I try to format it, I get an error? I don’t think the disk is physically damaged. George N White III’s answer makes sense, also, even without the G–sense-errors, clearly interrupting the formatting had the potential to cause problems. But there must be a tool that gets past these problems. Is fsck worth a try? I saw somewhere recommended testdisk, might this work?
I’ll report on extended smart self-check and badblocks later today, they’re pretty slow.
I can try another cable, but when the drive fell, it actually slipped, the cable remained connected to the laptop, so it doesn’t feel intuitive that it may have been damaged.
The extended smart self-test came with no errors, other than the G-sense ones, all rubrics were reported as ‘ok’. Badblocks is extremely slow, I’ll give it a bit more time but almost certainly I’ll interrupt it. But I don’t think it’s a physical problem, anyway.
Any other thoughts I might try? If not, I’ll try to send it back, with the exact explanation of what happened - perhaps they can reset it and send it to me, rather than replacing it.
> mkfs.ext4 /dev/sdc
mke2fs 1.46.5 (30-Dec-2021)
Warning: could not erase sector 2: Input/output error
Creating filesystem with 488378646 4k blocks and 122101760 inodes
Filesystem UUID: 25675e06-f3b8-4bd9-b7a1-2743fb045509
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Allocating group tables: done
Warning: could not read block 0: Input/output error
Warning: could not erase sector 0: Input/output error
Writing inode tables: done
Creating journal (262144 blocks):
done
Writing superblocks and filesystem accounting information: 0/14905
mkfs.ext4: Input/output error while writing out and closing file system
however badblocks -w and smartctl find no errors.
gparted doesn’t see /dev/sdc at all (same as the gnome Files application). The gnome Disks application identifies the disk, but gives error when I try to format it.
I don’t know what else to try - any last-minute ideas?
I’ve tried using a different (similar) cable, but I don’t think I have a Y-type one.
I want to try testdisk, it sounds like it might work, but I’m a bit worried to not do damage to my system in the process - has anyone run it? Is it safe for dummies? I understand I cannot run testdisk /dev/sdc, but rather testdisk with no options, then navigate through menus, and I am worried to not accidentally choose a wrong option.
fsck -y /dev/sdc
fsck from util-linux 2.38.1
e2fsck 1.46.5 (30-Dec-2021)
fsck.ext2: Input/output error while trying to open /dev/sdc
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
and the e2fsck commands give exactly the same output
I wonder if it would work better by creating a partition table and a single partition then doing mkfs.ext4 /dev/sdc1
It seems you are trying to format the raw device. Even though it may work at times that seems to not be the standard except for the smaller flash drives.