While playing around with void Linux live, using KDE partitionmanager I accidentally deleted all qubes os partitions. (BIOS installation: boot partition + luks encrypted pool)
I’m really devastated as this luks partition contained really important information.
only one copy of ssh keys
not committed 1 month changes to my personal project, nobody else worked on
family pictures
above 200 positions browser bookmarks
I don’t really care if qubes boots up again, I just need to restore mentioned files (so lvm pool).
I’m not expert but I’ve tried my best:
I’ve read a little about testdisk but after choosing analyze ==> partition type intel it shows me only the:
Disk /dev/nvme0n1 - 500 GB / 465 GiB - CHS 476940 64 32
Partition Start End Size in sectors
>* Linux 1 0 1 1024 63 32 2097152
So this seems to be the /boot one
But, where’s the luks?
Sorry @BBro, what you’re asking is above my pay-grade
If I were you I would read about ddresque, maybe you can find a solution there.
Maybe also google “LVM recovery”?
wise decision!
If you have a disk laying around of the same size or bigger, (or buy one) you could make an exact copy with dd before trying anything else. (but be careful!)
The hdd of my old laptop died…(it still spins, but controller is dead) I bought the exact same disk… now I’m waiting on a particular screw-driver (why do they have to use different/exotic ones?) to arrive so I can switch over the heads… hoping to be able to recover my data… so I know what you’re feeling :-s
If it was me, I wouldn’t touch it. I would take the drive out of your computer and bring it to a recovery specialist and see what they can do. Missing partitions on an encrypted disk means that you can make things worse by doing more. You risk overwriting crucial parts of the encrypted volume that would allow you to decrypt it with your password. Good luck…
I called specialists and described whole situation.
It seems that NVMe drive have TRIM support, so probably there’s nothing left to restore as disk probably received TRIM command so controller started overwriting data… If I wanted them to check it regardless, it would cost an arm and a leg. Literally…
What I’ve learned from this situation is to always do backups and be careful with ssd drives as they are hard/impossible to restore.
KDE Partition Manager doesn’t appear to send a TRIM/discard command if you delete a partition. What it does is run wipefs --all on the partition before it is deleted, which in case it contained LUKS1 data (assuming we’re talking about Qubes R4.0.x; R4.1 would be LUKS2) merely changes its first six bytes from 4c 55 4b 53 ba be to zeros. Hence TestDisk can’t find it as is, but it’s still perfectly recoverable.
So don’t give up on your data just yet. I’d get one or two cheap backup drive(s) and make a complete disk image, as a first step.
Something similar has happened to me. I have Qubes spread across my 256gb first ssd and a second 1tb ssd. I boot both Windows and Qubes on the first drive. On the second I have games (not important) and the rest of my Qubes.
I was using old Qubes 4.01. I had deleted an un-needed (unrelated) 50gb partition on my 1TB drive and was using archinstall to install arch linux there. Arch install started to format the whole drive and then failed after seconds. So I don’t know how far into the format it went.
“KDE Partition Manager … merely changes its first six bytes from 4c 55 4b 53 ba be to zeros. Hence TestDisk can’t find it as is, but it’s still perfectly recoverable.”
Could you please say something more about this? I just started running this to see if I can find the partition information on my unfortunate drive.
sudo hexdump -C /dev/nvme1n1 |grep LUKS
When I mount the encrypted partition from the first SSD I get all of my Qubes listed as partial, which, I guess, indicates they were spread across both drives in “pools”?
Some examples. All of my qubes are listed. Could these give a clue for recovery?
--- Logical volume ---
LV Name pool00
VG Name qubes_dom0
LV UUID tZ3cuG-GtKA-yXMT-doJm-LVpP-SSQr-pHMqY0
LV Write Access read/write
LV Creation host, time localhost.localdomain, 2021-06-22 11:48:07 -0400
LV Pool metadata pool00_tmeta
LV Pool data pool00_tdata
LV Status NOT available (partial)
LV Size 243.09 GiB
Current LE 62232
Segments 1
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/qubes_dom0/root
LV Name root
VG Name qubes_dom0
LV UUID k0A8an-QQE7-6T80-TXrT-JDEI-YioW-JF4gPz
LV Write Access read/write
LV Creation host, time localhost.localdomain, 2021-06-22 11:48:07 -0400
LV Pool name pool00
LV Status NOT available (partial)
LV Size 243.09 GiB
Current LE 62232
Segments 1
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/qubes_dom0/swap
LV Name swap
VG Name qubes_dom0
LV UUID V0fXPY-6wt2-GfEi-eKfM-M58g-219U-vTaTI5
LV Write Access read/write
LV Creation host, time localhost.localdomain, 2021-06-22 11:48:08 -0400
LV Status NOT available
LV Size <7.29 GiB
Current LE 1865
Segments 1
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/qubes_dom0/vm-NordVPN-root-1653403473-back
LV Name vm-NordVPN-root-1653403473-back
VG Name qubes_dom0
LV UUID gISctR-Smeg-wIf3-Q8d3-1cO3-UmTg-zqCgzL
LV Write Access read/write
LV Creation host, time dom0, 2022-05-23 03:50:59 -0400
LV Pool name pool00
LV Status NOT available (partial)
LV Size 49.06 GiB
Current LE 12560
Segments 1
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/qubes_dom0/vm-NordVPN-private-1653403473-back
LV Name vm-NordVPN-private-1653403473-back
VG Name qubes_dom0
LV UUID eXp56N-QA14-Ppf8-PbdC-cC84-YcGs-UCCME4
LV Write Access read/write
LV Creation host, time dom0, 2022-05-23 03:50:59 -0400
LV Pool name pool00
LV Status NOT available (partial)
LV Size 2.00 GiB
Current LE 512
Segments 1
Allocation inherit
Read ahead sectors auto
--- Logical volume ---
LV Path /dev/qubes_dom0/vm-NordVPN-root
LV Name vm-NordVPN-root
VG Name qubes_dom0
LV UUID 3UtZQU-D0tV-xqe7-lT4w-GMJt-6hLs-DKRFiZ
LV Write Access read/write
LV Creation host, time dom0, 2022-05-24 04:30:35 -0400
LV Pool name pool00
LV Thin origin name vm-NordVPN-root-1653403473-back
LV Status NOT available (partial)
LV Size 49.06 GiB
Current LE 12560
Segments 1
Allocation inherit
Read ahead sectors auto
If you think that the LUKS signature bytes weren’t wiped (in contrast to OP’s situation), you might as well try TestDisk to see if it can find the partition content.
Back up at least one complete disk image of both SSD drives before doing anything else!
Not sure that those are LUKS headers. The second match has the wrong value in the fifth byte (0f instead of ba), and the first match doesn’t show the fifth and sixth byte but the address 0x205029050 + 12 is not aligned to a 512 byte sector.
Thanks. I ran testdisk but the “fast” (takes hours) version found a few partitions but said the structure was bad. I didn’t want to do anything potentially destructive so I stopped and came over to the Qubes forum. Hopefully when I ran testdisk it didn’t wreck anything. I will go back and have a closer look once this scan has finished and followed up.
Looking at other internet posts, I guess a valid LUKS header looks something like
" ```
00100000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS…aes…|
`
My partial matches are just coincidences of characters on the 1tb disk most likely. It is still running. I have it on a live usb which I didn’t realize was sleeping after 15 mins of inactivity.
Edit again: I just made some calculations and it turns out this hex dump scan will take 2 days from start to finish. I seem to remember that the Qubes partitions are 1/2 to 2/3rd of the way through the disk. At least it gives me a possibility of recovering the data.
My hexdump of the SSD found only a LUKS 50gb partition which I had deleted and intended to install archlinux onto. I was able to mount that 50GB partition from a Fedora live CD. It didn’t find the Qubes LUKS partition, so I don’t have a solution for my particular problem.
For anyone else, this is how I did it.
→ find the LUKS partitions. This took 2 days on a 1tb drive. But you can resume
→ from an offset, so you don’t have to do it at once.
sudo hexdump -C /dev/nvme1n1 |grep LUKS
→ set up a loop device for the LUKS partition at that offset
sudo losetup -o 0xaae7000000 -r -f /dev/nvme0n1
→ find out the loop device name (loop3 in this case on a live fedora usb)
sudo losetup -a
→ open the partition, giving the pass phrase
cryptsetup luksOpen /dev/loop3 luksrecover
→ make a directory to mount it somewhere and then mount it
sudo mkdir /mnt/find01
sudo mount /dev/mapper/luksrecover /mnt/find01
copy your files to safety
→ close the loop device and shut down crypto mapper
sudo cryptsetup luksClose /dev/mapper/luksrecover
sudo losetup -d /dev/loop3
These are all the matches for LUKS I got from the drive. Out of these I can only see one LUKS partition - which is something empty that I deleted earlier (but put a single file in there to identify it). Search for aes to find it below.
My Qubes installation is actually in a logical volume across two drives, the 256gb drive with no problems, and the larger 1t drive one that got screwed by archinstall.
Perhaps I am looking for the wrong sequence of characters for the Qubes data as it is part of a logical volume?