[Swlug] Remote SWLUG, Join us on Jitsi tonight - Tuesday 20 April 2021 19:00 (BST)

[Daniel Morris]

Sorry about the very late reminder, enabled by realising my swlug list
email now goes through gmail instead of POP to my broken disk..

I spent a head-banging day yesterday scrabbling through backups
Realised that my flaky data is on a wholly LVM managed disk
Made enough room to drag data off the complete disk, rather than 200G
"partition" I thought I was messing with (LV)
Finding the writes (ddrescue) to other internal disks spawn SATA errors
themselves that bring those disks down to read-only
Having a sulk/pity-party for one
Leaping on colleague's suggestion that I swap the failing disk into one of
the external caddies to try again with my other system (rather than do the
system surgery):

# dd_rescue /dev/sdc /run/media/danielm/goodexternalcaddy/failingdisk.img
/root/failingdisk.mapfile
# dd_rescue -r3 /dev/sdc
/run/media/danielm/goodexternalcaddy/failingdisk.img
/root/failingdisk.mapfile

ddrescue (that's GNU/gddrescue, not dd_rescue) sucked all ~720GiB off in
one run with zero read errors overnight through my laptop, out to another
external backup disk which was plugged into the laptop's other USB port,
which gave me hope. After storing the flaky disk, I re-mounted my good
external caddy to try working on the image:

# losetup -r /dev/loop1 /run/media/danielm/goodexternalcaddy/failingdisk.img

I've just mounted the image (ro) on a loopback device and openSUSE's LVM
automagically scanned, detected the volume groups, but a simple mount has
failed complaining that it  "can't read superblock".

I expect it may be a bit confused as the journal shows a device mapper has
misidentified a FAT-fs. Bearing in mind I know have what's probably an ext2
structure in a logical volume bound inside an image that's mounted over a
loopback via USB to an encrypted, probably native XFS store. To just write
that sequence down makes me marvel at how clever the layers are.

I've come full-circle to think that perhaps the disk might be Ok and the
issues that first appeared in December are actually down to a failing
motherboard and/or SATA expansion cards. I've been holding back the
full-scale Ryzen/mobo/m2/graphics/memory/psu swapout since the last of the
upgrade bits arrived. I wanted to do a full backup-and-check before diving
in...

Daniel


On Wed, 21 Apr 2021 at 09:18, Clifford Perry via Swlug <
swlug at mailman.lug.org.uk> wrote:

> I enjoyed my first virtual meet up - thanks all :)
>
> Cliff
>
> On Wed, Apr 21, 2021 at 8:42 AM Dick Bain via Swlug <
> swlug at mailman.lug.org.uk> wrote:
>
>> Humble apologies for not seeing this until this morning, knackered after
>> a day in the garden is my only excuse 😉
>> Hopefully see you all next month
>> Dick
>>
>> On Tue, 20 Apr 2021, 18:28 Daniel Morris via Swlug, <
>> swlug at mailman.lug.org.uk> wrote:
>>
>>> It's the third Tuesday in the month, so 7pm tonight will be
>>> SWLUG-time! We're going to meet again using Jitsi.
>>>
>>> Simply launch a web-browser and go to
>>>
>>> https://meet.jit.si/swlugmeetonline
>>>
>>> Or,
>>> https://jitsi.org/jitsi-meet/ and choose "Start a call" and enter
>>> "swlugmeetonline" as the name.
>>>
>>> Join me to grumble about yet another failing disk and another emergency
>>> backup that is taking forever, the wonders of Ryzen, the fantabulousness of
>>> vaccines, or whatever...
>>>
>>>  Daniel
>>> --
>>> Swlug mailing list
>>> Swlug at mailman.lug.org.uk
>>> https://mailman.lug.org.uk/mailman/listinfo/swlug
>>
>> --
>> Swlug mailing list
>> Swlug at mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/swlug
>
> --
> Swlug mailing list
> Swlug at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/swlug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/swlug/attachments/20210422/9724f979/attachment.html>