On 12/19/2018 03:16 PM, Mick wrote:
Grant, you're spot on!
/me looks around wondering what he did and if he needs to run and hide.
Symbol: EFI_PARTITION [=n]
Oops. That will certainly mess with you.
I was under the impression I had it enabled, but clearly I hadn't on
this PC; which has a
On Wednesday, 19 December 2018 18:46:40 GMT Grant Taylor wrote:
> On 12/19/2018 04:43 AM, Mick wrote:
> > Partition table holds up to 128 entries
>
> 128 entries tells me that the disk has GPT partition table, not a
> classis MS-DOS / PC-BIOS partition table.
>
> This sounds like the (what I und
On 12/19/2018 04:43 AM, Mick wrote:
I ran ddrescue while the drive was still on the laptop. The clone was on the
USB caddy.
ACK
The disk block device is there and so is the first partition (only):
ls -la /dev/sdb*
brw-rw 1 root disk 8, 16 Dec 19 11:20 /dev/sdb
brw-rw 1 root disk 8,
On Tuesday, 18 December 2018 21:28:38 GMT Marc Joliet wrote:
> Just to add a personal anecdote: I once had an external drive that I thought
> had broken (it made the "clicks of death"), but after taking it out of its
> USB enclosure and connecting it directly via IDE (shows how old the drive
> was
On Tuesday, 18 December 2018 18:51:55 GMT Grant Taylor wrote:
> On 12/18/2018 10:42 AM, Mick wrote:
> > I know others have commented on the reliability of recovering data from
> > drives connected via USB caddy, but I have had satisfactory results on a
> > number of cases.
>
> I think it completel
Am Dienstag, 18. Dezember 2018, 16:56:02 CET schrieb Grant Taylor:
> On 12/18/2018 05:21 AM, Wols Lists wrote:
> > I really don't trust USB and hard drives
>
> IMHO external USB drive enclosures (physical enclosure, USB to SATA /
> PATA / ??? adapter, (no)fan) are suboptimal at best and are most l
On 12/18/2018 10:49 AM, Jack wrote:
I should be in good shape there. The partition's new location should
have the first half intact, and since the overwriting was of the first
part of the old location, it's second half should be intact. The files
should all be there - but I imagine I might ha
On 12/18/2018 10:42 AM, Mick wrote:
I know others have commented on the reliability of recovering data from drives
connected via USB caddy, but I have had satisfactory results on a number of
cases.
I think it completely depends on the type of problem. In my experience,
SATA-to-USB adapters do
On Tuesday, 18 December 2018 17:49:37 GMT Jack wrote:
> On 2018.12.18 12:42, Mick wrote:
> [snip...]
>
> > So, I used losetup with --offset on the failing drive itself over USB
> > 2.0 and was able to mount and recover all the NTFS files.
>
> I definitely need to read up on that one - I totally u
On 2018.12.18 12:42, Mick wrote:
[snip...]
So, I used losetup with --offset on the failing drive itself over USB
2.0 and was able to mount and recover all the NTFS files.
I definitely need to read up on that one - I totally unfamiliar with it.
Over the years I've used clonezilla, ddrescue, te
On 2018.12.18 07:21, Wols Lists wrote:
On 17/12/18 19:32, Jack wrote:
ddrescue has now been running for almost 22 hours, and it's been 47
seconds less than that since its last successful read.
Doesn't sound good. Just to throw my tuppence-worth of bad news into
the mix, are your drives in U
On Tuesday, 18 December 2018 17:11:28 GMT Jack wrote:
> On 2018.12.18 04:43, Peter Humphrey wrote:
> > On Monday, 17 December 2018 23:19:39 GMT Jack wrote:
> >> At this point, I think I've forgotten the details, but using the
> >> example of a 300G drive with 100G empty and then a 200G partition,
>
On 2018.12.18 04:43, Peter Humphrey wrote:
On Monday, 17 December 2018 23:19:39 GMT Jack wrote:
At this point, I think I've forgotten the details, but using the
example of a 300G drive with 100G empty and then a 200G partition,
when I moved the partition to the beginning of the disk (using
On 12/18/2018 05:21 AM, Wols Lists wrote:
I really don't trust USB and hard drives
IMHO external USB drive enclosures (physical enclosure, USB to SATA /
PATA / ??? adapter, (no)fan) are suboptimal at best and are most likely
to work when all the components are happy.
I view them as the weak
Wols Lists wrote:
> On 17/12/18 19:32, Jack wrote:
>> ddrescue has now been running for almost 22 hours, and it's been 47
>> seconds less than that since its last successful read.
> Doesn't sound good. Just to throw my tuppence-worth of bad news into the
> mix, are your drives in USB enclosures? I
On 17/12/18 19:32, Jack wrote:
> ddrescue has now been running for almost 22 hours, and it's been 47
> seconds less than that since its last successful read.
Doesn't sound good. Just to throw my tuppence-worth of bad news into the
mix, are your drives in USB enclosures? I really don't trust USB a
On Monday, 17 December 2018 23:19:39 GMT Jack wrote:
> At this point, I think I've forgotten the details, but using the
> example of a 300G drive with 100G empty and then a 200G partition, when
> I moved the partition to the beginning of the disk (using gparted, as I
> remember) once it moved more
On 2018.12.17 17:32, Heiko Baums wrote:
Am Sat, 15 Dec 2018 18:33:35 -0500
schrieb Jack :
Some months ago, I borked a laptop HDD by trying to move a partition
in a way that left both the old and new partitions invalid. (For my
sanity, I've forced the details out of my memory, but the old an
Am Sat, 15 Dec 2018 18:33:35 -0500
schrieb Jack :
> Some months ago, I borked a laptop HDD by trying to move a partition
> in a way that left both the old and new partitions invalid. (For my
> sanity, I've forced the details out of my memory, but the old and
> new locations overlapped, and I th
On 12/17/2018 12:42 PM, Rich Freeman wrote:
There is of course no guarantee that it will EVER successfully read all
your data. You might be able to tell it to skip blocks and move on.
Obviously all it can do is keep asking the drive to try again. If you
want better than that then you're talki
On 12/17/2018 12:32 PM, Jack wrote:
The other drive failed over a shorter period of time, even though SMART
testing said all was OK.
IMHO, by the time that S.M.A.R.T. complains, most chances of data
retrieval are gone.
I treat S.M.A.R.T. errors as a confirmation that the drive realizes that
On Mon, Dec 17, 2018 at 2:32 PM Jack wrote:
>
> ddrescue has now been running for almost 22 hours, and it's been 47
> seconds less than that since its last successful read.
There is of course no guarantee that it will EVER successfully read
all your data. You might be able to tell it to skip blo
Thanks to both Rich and Grant for suggestions. Part of my issue is
that I currently have two different failing/failed HDDs to deal with,
and one of them has two different problems. At this point, although
there are files I would really love to recover from each of them, it's
not critical,
On Sat, Dec 15, 2018 at 6:33 PM Jack wrote:
>
> So, I removed that HDD for safekeeping (completely reinstalled the
> laptop on a new drive) and now I'm trying to recover data from an
> intact partition on the old drive, the problem being that the drive is
> giving some read errors, so I want to mi
On 12/15/18 4:33 PM, Jack wrote:
Is there any way to fix this other than completely repeating the copy?
I'm sure there are other ways, but the first things that comes to mind
is touch. Or rather a script that uses touch, and possibly find or a
recursive glob. The idea being to have the lis
Some months ago, I borked a laptop HDD by trying to move a partition in
a way that left both the old and new partitions invalid. (For my
sanity, I've forced the details out of my memory, but the old and new
locations overlapped, and I think the move might have been
interrupted. My own fau
26 matches
Mail list logo
