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
Am 18.12.18 um 15:37 schrieb J. Roeleveld:
I had similar issues with multiple packages.
Solved by updating the kernel, are you using latest stable gentoo sources?
far from ...
4.14.12-gentoo ... uptime 323 days
I will have to check that IRMC-like KVM-box with outdated Java before I
dare a
Hi,
I installed Krita:
[I] media-gfx/krita
Available versions: (5) 4.1.5^t (~)4.1.7^t
{color-management debug fftw gif +gsl heif +jpeg openexr pdf qtmedia
+raw test tiff vc PYTHON_SINGLE_TARGET="python3_4 python3_5 python3_6
python3_7" PYTHON_TARGETS="python3_4 python3_5 python3_6
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
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
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
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,
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
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
On December 18, 2018 1:48:42 PM UTC, "Stefan G. Weichinger"
wrote:
>
>I see
>
>[27905442.641298] amcheck-device[8581]: segfault at 8 ip
>7f36788986e6 sp 7ffc67faf2f8 error 4 in
>libc-2.27.so[7f36787fa000+1be000]
>[27905718.857330] amcheck-device[8733]: segfault at 8 ip
>7f143d7ae6e6
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 see
[27905442.641298] amcheck-device[8581]: segfault at 8 ip
7f36788986e6 sp 7ffc67faf2f8 error 4 in
libc-2.27.so[7f36787fa000+1be000]
[27905718.857330] amcheck-device[8733]: segfault at 8 ip
7f143d7ae6e6 sp 7ffeb709f728 error 4 in
libc-2.27.so[7f143d71+1be000]
when I run
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
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
16 matches
Mail list logo
