qubes r4 installation no longer boots, apparent corruption. anything I can do to get at the data?

[Foppe de Haan]

So it appears that something went very wrong during a dom0 update.
The emergency mode of the regular boot process does attempt to load, but hangs or stops before it finishes, so I can't get a shell that way either.
Have also tried to 'rescue' the system via a qubes installation medium, but after entering the correct LUKS passphrase, it says something like 'no valid linux installation found', and stops.

Anyone have suggestions as to what I might try next, if anything?

[unman]

Depending on how important your data is to you you might want to start
by cloning the disk. (I'd recommend clonezilla for ease of use.)

You can check that your data is safe by booting from a live image -
kali, knoppix etc.
Then try to mount your Qubes partition - you'll need to use cryptsetup
luksOpen to decrypt the disk, and you should then be able to mount the
partition.
You don't say whether you are using 3.2 or 4.0, and the approach to take
will depend on that. In 4.0 individual qubes by default use thin pools
so you will need to identify the qubes you are interested in and check
in /dev/qubes-dom0 using 'ls -l' which of the device files in /dev
match.
You can then mount those devices and copy out the data.

Once you've secured all your data, you can try for recovery of the
system. I've had some success in doing this but frankly it's almost
always better to reinstall, particularly as you don't know *what* went
wrong.
If you've got recent backups or don't care about the data, I would just
skip those steps and reinstall.

If you need specific advice give a little more detail about how you had
the system configured and exactly what steps you've taken so far.

Best of luck

unman

[Foppe de Haan]

Thanks, will do (wrt cloning). Last backup was from april, so I'd like to recover if possible. r4.0; as to what went wrong, not sure exactly; qubes-dom0-update finished properly, but fairly soon afterwards, I experienced a hard reboot, likely due to unstable memory settings, which I had been tinkering with a bit.
So far all I've tried is to boot and/or repair the system, but I can't get the volume to mount, so haven't made any progress yet.

[Foppe de Haan]

(Note that I'm using BTRFS.)

When I try to mount the data volume using a Fedora 29b live image, I get "can't read superblock on /dev/mapper/luks-5047683c-2a3f-463d-8538-53701743acca."

[unman]

On Wed, Oct 17, 2018 at 03:51:57AM -0700, Foppe de Haan wrote:
> (Note that I'm using BTRFS.)
>
> When I try to mount the data volume using a Fedora 29b live image, I get "can't read superblock on /dev/mapper/luks-5047683c-2a3f-463d-8538-53701743acca."
>

Ah, OK hadn't realised that.
Is there a specific error message - if it was included in that image you
attached can you tell me what it was?

If there is a specific BTRFS error have you tried repairing the file
system? Look at the manpage for btrfs-check.
There are some dangerous options to try if all else fails:
'btrfs check --repair' often does what it says.
If that doesn't work or you have a tree error, then you could try 'btrfs
check --init-extent-tree'. I've sometimes doubled on that and recovered
access. ymmv.
(If you have a cloned disk you will feel much happier about trying out
these "dangerous" options, of course.)

unman

[Foppe de Haan]

Thank you for the advice. I managed to recover 1 private image, the rest was salvageable, for whatever reason. (Even VMs that hadn't been started for days, so there must've been another issue than the one I mentioned; because if not, the only other conclusion I see is that btrfs is bizarrely fragile.)

[unman]

I'm sorry to hear that. I don't use btrfs myself, for just such reasons,
although other users find it works for them. I hope you didnt lose too
much.
If you still have the cloned (or original) disk then you could consider
other recovery options depending on how valuable your data was.

unman