Post by BorisPost by PaulPost by BorisHuge snip
Post by PaulWell, if you absolutely cannot get the table with smartctl
in Linux, go back to windows and use the Health tab
of HDTune 2.55.
http://www.hdtune.com/files/hdtune_255.exe
While Linux could be mis-interpreting some parameters
in SMART, it's possible the disk itself has some way
of indicating imminent failure after "doing the short
test" on its own. It could be a failure indicated by
short test, rather than an analysis of the SMART
parameter table to reach the same conclusion.
You really need to get working on your ddrescue/gddrescue.
And try and get as much data off the disk as possible.
Perhaps the active surface of the disk is toast, but
you'll discover that when you try. The thing is, the
disk would not have responded, unless the disk heads
loaded and the controller was able to read the
Service Area. So *some* portion of the platters
is readable. But we don't know how much.
Paul
I ran HDTune 2.55 a few weeks ago with the MAC HD USB tethered. The
https://postimg.cc/gallery/25g6b1tdo/
The Health Tab displayed nothing for the MAC HD..
At the same time, to be sure HDTune was working correctly, I applied
HDTune 2.55 to my Windows OS disk, and it reported ok on all tabs but
the
Post by PaulPost by BorisHealth Tab, which displayed nothing.
Yesterday, with the MAC HD connected directly to the SATA motherboard
connection, HDTune recognized all drives on my system, except for the
MAC
Post by PaulPost by BorisHD.
I'm not going to dick around any longer trying to get S.M.A.R.T. dats.
I'm going to see what I can do with imaging the MAC HD to another hard
drive.
It should have worked.
But ddrescue is where you have to go, and quickly.
The details don't matter any more, just the objective matters.
Save the sectors before it is too late.
Paul
So the next step was to try ddrescue. I remembered Frank Slootweg (in
"sda and sdb dependent on the sequence in which you connect the
original disk and the to-be-copied-to disk?"
I tested this, and discovered this is true, that the device designation is
dependent on order of connection. With internal, USB flash, and USB
external drives attached, the sdX designations were different than if only
the two disks I wanted to use were connected. Also, the designations were
different depending on the order of connection. I guess Linux orders them
in order of discovery.
I disconnected all disks (including the Win7 OS disk, not wanting to blow
it up in error) and loaded up Knoppix. I then connected the MAC HD and a
new Western Digital Passport 1TB HD.
MAC HD = sda (source, 500GB)
Passport HD = sdf (destination, 1TB)
Linusx Disks told me that the Passport drive was mounted at /media/sdf1
I tried to run ddrescue with a log file, but couldn't get the syntax
ddrescue: Mapfile exists and is not a regular file.
GNU ddrescue 1.22
ipos: 500107 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 500107 MB, non-scraped: 0 B, average rate: 0 B/s
non-tried: 0 B, bad-sector: 500107 MB, error rate: 17313 kB/s
rescued: 0 B, bad areas: 1, run time: 2h 55m 25s
pct rescued: 0.00%, read errors:984404307, remaining time: n/a
time since last successful read: n/a
Finished
For the first few minutes, there was a line that said someting about
Trials 5. I thought this would last till the end of the run, but it
disappeared shortly, so I wasn't able to copy/paste it here.
I then logged on to the Passport drive...no changes.
Boris
The mapfile should be a text file, not a partition.
You transfer a whole-disk-identifier to a whole-disk-identifier,
to do device to device cloning. You got that part right.
/dev/sda /dev/sdf
The third item in the list, should be a text file. Perhaps that's
the map file they refer to.
All I have here at the moment to test with is:
KNOPPIX_V8.1-2017-09-05-EN.iso 4,553,826,304 bytes
Which one do you have ?
The package likely comes from Debian, and you could check
your version of ddrescue as well. Mine is "version 1.22
of GNU ddrescue".
ddrescue -V
I doubt it's highly sensitive to version, but I don't
want to wander too far off target.
And you have the basic form right, except the mapfile.
ddrescue -f /dev/sda /dev/sdf ~/mymapfile.txt
You can use "whoami" to check what account you
are using currently. On Knoppix, this is likely
"root", so sudo is not needed. On Ubuntu, you
would use...
sudo ddrescue -f /dev/sda /dev/sdf ~/mymapfile.txt
**********
ddrescue can copy from a device to a device, a device to an image file,
an image file to a device. In this example (one I tested), I transferred
a device to an image file.
sudo ddrescue -S -b8M /dev/sdb /mount/external/backup/sdb.raw /mount/external/backup/sdb.log
The -S in that example, makes "sdb.raw" a "sparse" file, which
means that sectors full of zeros need not be recorded using
disk surface. Instead, a table of present or missing sectors
is kept, to conserve space. This only makes sense for disks
that are mostly full of zeros to start with. Normal disks
don't have an excess of sectors-full-of-zeros, so this -S
option will not help you.
The -b8M on the version I was using, was supposed to set the
transfer size. Yet, the manual page says it sets the sector
size. Which isn't the same thing. A lot of conventional
disks support 512 byte sectors. A "512n" disk is native,
and externally visible and internal representation are
both the same. A 512n disk is "512,512".
A 512e disk (quite common in 2018), is 512 bytes externally
(emulated) for compatibility, while inside the drive, the
storage is done using 4096 sectors. This 512e disk
would be "512,4096". This is not a preferred option for
WinXP, but Vista+ OSes align on 1MB boundaries, so the
4096 sector size aligns with the 1MB boundaries. Most
cluster operations on Vista+ then align with the
internal representation, for maximum efficiency.
The third type is not common. A 4Kn disk is "4096,4096"
disk. There are few tools to use with it (partition management
is hopeless). Windows 10 I think, will support a 4K sector,
so Windows 10 could see one. But my recommendation to people,
is to stay far away from these, unless you want your
computer usage with them to be one continuous experiment
and breadcrumb exercise.
So the only part of my command that doesn't make a lot
of sense, is the -b8M. Does it set the maximum transfer
size ? Or does it set a sector size ? The program should
be able to read the information, just the same way that
fdisk does.
sudo fdisk /dev/sdb
If you select "p" for print, then "q" for quit,
there's a line near the beginning that shows the
512n, 512e, 4Kn nature of the drive. The internal and
external sector sizes are shown.
In any case, this is the syntax I'd be trying. The -b8M
may speed up the trial speed. The claim I read, is
the transfer size is "adaptive" and the command adjusts
the transfer size per command, to optimize bandwidth.
That's what the -b was supposed to do, according to the
documentation I was reading at one time.
ddrescue -b8M /dev/sda /dev/sdf ~/mymapfile.txt
Some more examples here.
https://unix.stackexchange.com/questions/17087/clone-whole-partition-or-hard-drive-to-a-sparse-file
*******
You showed me a result before with HDTune, which is
consistent with your ddrescue result.
And both results make no sense :-/
There is something *weird* about that Mac disk.
An ATA disk will *not* be visible, if it has internal
troubles. The ATA disk spins up, and loads the heads onto
the platter, using a relatively small firmware loader
on the controller board.
The full ATA command set, is a larger chunk of code in
the Service Area of the platter. Otherwise known as
"Sector -1" because it is in an area that ordinary users
cannot access. Once the SA is loaded, the drive is ready
to accept ATA commands from the SATA bus.
The first command sent by the BIOS, is an "identify yourself".
And the returning of a single packet with "ST3500418..."
tells you that a SATA packet was eventually received
error free from the drive.
And we know enough of the drive works, that HDTune plays with
it in Windows.
But we also know, that an HDTune error scan, returns nothing
but red blocks. How is that possible ? How can the surface
be inaccessible like that, when we know the SA loaded
(a couple megabytes), and the drive came up ?
There is something about this disk, I just don't understand.
The only other breadcrumb I have for you, is certain
Macs years ago, needed the Spread Spectrum jumper
inserted on the back of the drive. Some brands of
drives have four pins. (Note that there can be *several*
four pin blocks, and you have to be careful to pick the
correct one.)
X X X X
Force150 SpreadSpectrum
The Force150 jumper is only needed for VIA chipsets
(something Apple isn't likely to use). The SpreadSpectrum
on the other hand, when you insert that jumper, it defeats
SpreadSpectrum clock modulation on the cable.
The purpose of SpreadSpectrum, is to defeat FCC15 testing.
It spreads the emissions to a slightly broader peak, so
hardware can pass FCC testing. It doesn't mean that the
device interferes any less with other radio equipment.
A very small number of interface chips, cannot track the
triangle wave modulation of SS. Normally, you'd use a PLL
or DLL or training clock, to come up with a scheme so you
can read packets while the clock rate continuously changes.
Some Apple chip could not do this at the time, and drives
connected to that Apple device, needed the SS jumper to
be inserted.
But other than that observation, I don't understand
how the entire surface of the disk is inaccessible,
while the SA reads fine and the drive comes up.
Would some service person have changed the jumper
state, and if so, why ?
Jumpers on those drives are probably 2mm type. There are
two jumper caps - 0.1" jumpers and 2mm jumpers, and one
type doesn't fit the other spacing all that well. I
had to look in my basement, in an old disk enclosure
product box, for a bag of ten 2mm jumpers I had. And
I've been using those over the years for stuff like
this.
I tried running the part number
ST3500418ASQ
only to find this gibberish about a "thermal sensor".
https://forums.macrumors.com/threads/21-5-27-imac-hd-replacement.841205/
Some more here. These guys are usually pretty good at this
stuff (they tap into other forums to get the scoop
on "non-standard" crap).
https://blog.macsales.com/10206-further-explained-apples-imac-2011-model-hard-drive-restrictions
Now, does that have anything electrically to do with the
drive ? Is it just the controller sensor, pinned out
to a header, so the controller can take external
temp readings ?
That should have nothing to do with reading data
from the drive. Whereas Spread Spectrum could.
I can't find that exact part number on the Seagate site.
It could be considered an OEM special just for Apple.
I haven't been able to find any dmesg Linux boot
cycles for that device, giving particulars. And the
Mac boot log is useless.
*******
Note the usage of branded firmware on the controller board. WTF?
http://firmware.hddsurgery.com/?manufacturer=Seagate&family=Pharaoh
ST3500418ASQ AP24 Pharaoh 5VM59RXH 2016-07-16
ST3500418AS CC37 Pharaoh 6VM66MWD 2016-07-16
The label on my 418AS drive shows it is running CC46, but
you can see the basic idea. That the "Apple OEM" drive
runs "APxx" firmware for some reason (maybe it does head park
or spins slower when idle or something, like a more aggressive
power management scheme).
So far, no evidence any of this affects reading data
from the drive.
I didn't rush this post off to you, because I suspect
we won't be getting any ddrescue data, until we figure
out what else isn't standard about the drive. I can't find
enough discussions in threads on the Internet about the
drive, to figure it out.
Perhaps you could take a picture of your hard drive or
at least examine it for differences to this.
Loading Image...Even if the drive was encrypted, it should still read
without CRC errors. Why is the *whole* surface unreadable.
It's not a failure.
Paul