On 03/03/2024 12:36, Nic wrote:
> On 3/3/24 4:11 AM, RobH wrote:
>> On 02/03/2024 22:06, Enno Borgsteede wrote:
>>> Op 02-03-2024 om 17:38 schreef RobH:
>>>
>>>> I tried Seagate tools from HBCD, but no drive was listed
>>>
>>> Does it have enough power? Mine is the same type, with 2 platters,
>>> and 1 TB, and it is quite essential that you use a proper adapter,
>>> preferably linked to a USB 3 port, or with a Y cable, or an external
>>> power supply.
>>>
>>> And if you leave the external case open for testing, you can hear the
>>> drive start, if that happens.
>>>
>>> Some months ago, a friend came here with a Kingston SSD, and a no
>>> name adapter, and even for that, Gparted did show something, and a
>>> proper tool should at least give you some information about the
>>> adapter itself, and the drive type. And if you have nothing to loose,
>>> you can also let Gparted create a new boot sector, in whatever format
>>> you like.
>>>
>>> This will of course not work, if Gparted can't even detect the drive
>>> type, which I think is a either a sign of a broken connector, or lack
>>> of power.
>>>
>>
>> The 2.5 inch sata to usb adapter I have is a Sabrent , powered from a
>> usb 3 port.
> This leaves the question of a bad power supply. A USB adapter should
> have its own source of power, rather than relying on the USB port for
> power.

fair comment, but it is an old laptop at the moment , and I'm using
tools from HBCD , without success upto press.

DRevitalise is currently running and there are so far 2275 bad sectors
out of 2276.
I have also used other testing and recovery tool to no avail.

On 3/3/2024 4:16 AM, RobH wrote:

> Ok, I tried the Boot Repair tool and it didn't repair the boot. It produced a text file listing a whole load of stuff , but I couldn't do anything with it, ie copy and paste to a usb stick , etc.
>
> One other thing I should have mentioned before, is that when the said disk is trying to boot, it produces what sounds like a 'barp' sound every few seconds. Needless to say, it doesn't boot up.
>
> Thanks

This suggests...

if you check dmesg or "sudo dmesg",
it may indicate it has detected the hard drive.

Normally, a hard drive will not ID itself, unless
the firmware loads off the platter. This means the
heads loaded, read the area before sector 0, and got
as much as 2MB of firmware. The firmware contains
an ATA parser, for parsing ATA commands.

Since it tried to boot, again, it must think
there is a disk drive there, but there's something wrong
not far distant from the firmware it just loaded.

*******

sudo apt install gddrescue

# ddrescue has a reverse direction option.

https://linux.die.net/man/1/ddrescue

cd /tmp # Store rescue.log in /tmp (ramdisk)

ddrescue -f -n -R /dev/sda /dev/null rescue.log # This would be fun on a healthy disk
# but perhaps you'd rather save the data.
# That command is a bad block scan of /dev/sda.

# For normal recovery, it's like this. Copy from /dev/sda to /dev/sdb.

sudo ddrescue -f -n -R /dev/sda /dev/sdb /tmp/rescue.log

# Examine the LOG file for details. A large log file means
# there are many CRC errors.

xed /tmp/rescue.log

# Now, the second pass reads the log, and concentrates only on the
# not-yet-captured sectors. This is attempting to "build up"
# the /dev/sdb replacement drive, with the data from the other drive.
# Eventually, only sectors with CRC errors, cannot be transferred.

sudo ddrescue -d -f -r3 -R /dev/sda /dev/sdb /tmp/rescue.log

If it still "barps", then there is some physical barrier to
success involved. But it would not ID itself, unless a lot
of things were working. Like seeing it in the BIOS or in sudo dmesg,
means a lot of the device must work for that to happen.
Which makes the situation more than a bit strange. It's likely
to be one platter with two heads, and the symmetric heads are all
part of maintaining flying height.

The fact the device has flash, I don't know what consequences that
has. It can be designed similar to a RAID1 mirror, in which case
both the flash and the platter, have a copy of some of the sectors.
I don't know if the SSHD controller has any "freakouts" that involve
damage to the flash. Would an SSHD store the ATA parser in the 8GB NAND
flash ? Dunno.

In the old days, drives had mechanical stops, and they likely
still exist for the travel of the arm. You would not want the
heads to get too close to the hub for example.

A stalled motor makes a "deedle dee" sound repeatedly. The
motor controller is a three phase thing, with a current limit.
And something there makes a pattern that attempts to make the
motor turn (when it is obviously stuck).

In the old days, the "barp" came from the stepper motor that
drove the heads radially. There was a steel band. Rotary action
on the stepper, was converted to linear motion using the
steel band wound around the stepper shaft. Whereas modern
drives use "absolutely quiet" voice coils, where the most
that they do on an elevator seek, is impose a "thump" sound
to the chassis. There's no "barp" on voice coils. Only steppers
did that. Steppers were perhaps closer to a "braaaap".
That's a seek-to-zero on a stepper, when it loses its way.

Paul

On 03/03/2024 13:52, Paul wrote:
> cd /tmp

Thanks but as the said disk is in my old laptop, there isn't any
network, so I can't install anything.
Also, I'm not sure where I would find a linux terminal.

I tried doing it from a DOS prompt, but that didn't work.

I'm just in the process of trying Kon Boot from the HBCD utility, and it
has just told me that
BIOS seems to be OK.
Booting up! - EOT
Fatal - reading original MBR failed!

I think it is almost time to give up on it now, as nothing, tools , I
have tried don't recover any data, and report loads of errors on the disk.

Thanks