Qubes_dom0-root does not exist - preventing boot after ungraceful shutdown

[soulqube]

I’ve spent a couple of hours searching through the forums and github issues. There are reports of this problem, however none of the posts are similar enough to the specifics of my issue to resolve the issue for me.

This is the latest fix I tried.

Here’s my situation -

• Booted into Qubes
• Entered luks password
• Logged into Qubes
• Battery died
• Plugged in laptop
• Rebooted Qubes
• Entered luks password, then get these errors

Warning: /dev/.../qubes_dom0-root does not exist
Warning: /dev/..../root does not exist
Warning: /dev/.../swap does not exist

I looked at journalctl and also rdsosreport.txt The warnings and errors I saw appeared to be disk related. However I did a hardware check on the disk and a sector check, both of which passed without issue.

Any help with further troubleshooting would be appreciated.

Otherwise, is it possible to recover existing qubes from the disk, as I am able to mount it according to these instructions. I found this post about the topic but didn’t quite understand the conclusion.

[apparatus]

Can you post the errors that you have in rdsosreport.txt?
Maybe only root thin pool was corrupted and you can try to recover it.

If you’re able to decrypt the LUKS and your LVM is not corrupted then you can try to get the data from the qube like this:

Paid help: uefi boot items disappeared, re-added and never booted again!

I can only give you approximate untested instructions: Assuming: /dev/sda3 - old Qubes OS encrypted LVM /dev/sdb1 - temporary backup drive and assuming its filesystem support creating sparse files (e.g. ext4) (Sparse file - ArchWiki) or has enough space to contain the VM raw images Mount your backup drive, decrypt old Qubes OS system and activate VG: mkdir /mnt/qubes-backup mount /dev/sdb1 /mnt/qubes-backup mkdir /mnt/qubes-backup/old-qubes-os-backup cryptsetup luksOpen /dev/sda3 luks-old-q…

But you won’t be able to backup the qubes themself to restore them in new Qubes OS late, you can only get the data inside the qubes like this. You’ll have to recreate the qubes in the new Qubes OS installation manually.

[fsflover]

Did you try to follow this solution?

@fsflover

lvextend qubes_dom0/vm-pool --poolmetadatasize +128M

worked.

Then I tried

lvconvert --repair qubes_dom0/vm-pool

and, after some waiting, it fixed the problem for me

[soulqube]

[Can’t figure out how to delete this…]

[soulqube]

I was able to recover some key info so de-prioritized this for a bit and am coming back to it now.

When I run the lvconvert command, I get -

Active pools cannot be repaired. Use lvchange -an first.

So I try -

lvchage -an qubes_dom0/vm-pool

and it excutes without error, however still get the same error when running lvconvert again.

[apparatus]

I think your problem is with root pool so you need to deactivate root pool first before trying to use lvconvert on it e,g,:

lvchage -an qubes_dom0/root-pool
lvconvert --repair qubes_dom0/root-pool

[soulqube]

Here’s the best I can do w/the logs right now. Not sure how helpful they are. After I exit from here I see two messages -

Warning: Not all disks have been found.
Warning: You might want to regenerate your initramfs.

[apparatus]

Try:

cat rds* | grep -i -e err -e fail | less

[soulqube]

Same issue, i.e. lvchange seems to execute successfully but lvconvert throws the same error.

[apparatus]

Then try lvchage -an to deactivate all.

[soulqube]

Here’s the output.

[soulqube]

This doesn’t seem to be the correct syntax to deactivate all. I’ll do some research to figure out how to do that.

[apparatus]

Check this:

cat rds* | grep -i warn | less