Qubes won't boot

[Boot problems]

Hello, I wanted to migrate from my old hhd to a new ssd, I installed Qubes on the new ssd and it works fine but now the old hhd won't boot, I tried the rescue option that is in the installation iso but it says there are no Linux partitions found, to be fair I don't know how to use the rescue tool neither, did I format my disk accidentally or could it be a grub issue? What can I do?

[dhorf-hfre...@hashmail.org]

On Sun, May 31, 2020 at 12:45:22PM -0700, Boot problems wrote:
> Hello, I wanted to migrate from my old hhd to a new ssd, I installed

[...]

> could it be a grub issue? What can I do?

assuming you were NOT reinstalling because you were compromised...

- just boot your new qubes system
- with the old HDD attached (directly or through USB)
- check if there are partitions on it (fdisk -l /dev/hdx)
- open the luks container from the HDD (google: cryptopen)
- you should now have access to the lvm volume of your old system
- with that access, you can create replacement vms and dd over their
private volumes.

see how far you can get on that list.
ask more specific questions as required.

[Boot problems]

I attached the hdd to a VM and used the fdisk -l command, with /dev/hdx it says the directory did not exists so I brought up the gnome-disks GUI and saw that it was on the directory /dev/xvdi but using that it just says permission denied.

I googled the cryptopen and if the command I'm supposed to enter is the cryptsetup luksOpen /dev/xvdi2 name, then it says access denied, I can seemingly unencrypted it from the gnome-disks GUI but not mount it.

However I tried booting up the old hdd again and now it works as long as the ssd is connected too but all my data is gone and is just a clone of the new ssd, without the ssd connected it doesn't boot up like before, I guess it has been formatted then, is there a way to recover some of the lost information? I only really need a few files.

[dhorf-hfre...@hashmail.org]

On Sun, May 31, 2020 at 01:57:24PM -0700, Boot problems wrote:
> /dev/xvdi but using that it just says permission denied.

so use "sudo fdisk -l /dev/xvdi"

> the cryptsetup luksOpen /dev/xvdi2 name, then it says access denied, I

so use "sudo cryptsetup luksOpen /dev/xvdi2 name"

> can seemingly unencrypted it from the gnome-disks GUI but not mount it.

it contains an lvm stack, so there will be many virtual volumes inside.
after the luksOpen, check "ls -al /dev/mapper/*-private" and look for
the devices with the names of your old VMs.
you should be able to mount these.
hint: use "sudo mount /dev/mapper/whatever-private /mnt/whatever"
hint2: you will have to replace the "whatever" part there.
hint3: you will have to "sudo mkdir /mnt/whatever"

or create new VMs, and restore the whole private volumes with dd.

> However I tried booting up the old hdd again and now it works as long
> as the ssd is connected too but all my data is gone and is just a
> clone of the new ssd, without the ssd connected it doesn't boot up
> like before, I guess it has been formatted then, is there a way to

that sounds more like you are just booting from your ssd into the fresh
install.

[Boot problems]

LuksOpen worked now, it was stupid of me to forget the sudo.

Mounted it as oldhdd, using
ls -al /dev/mapper/*-private says there is no such directory

ls -al /dev/mapper/oldhdd-private says the same

ls -al /dev/mapper/oldhdd returns only one line
lrwxrwxrwx 1 root root 7 May 31 17:39 /dev/mapper/oldhdd -> ../dm-0

Tried those 3 ways with and without sudo

I really appreciate you helping me, sorry to be so dumb for these stuff, I manage just fine for every day things.

[Boot problems]

Using fdisk -l /dev/xvdi shows me 2 partitions only, a 200m EFI System and xvdi2 a 931G Linux file system, there are no more partitions even if I decrypt, mount and fdisk -l /dev/xvdi2

[dhorf-hfre...@hashmail.org]

after the luksOpen, check with lvm tools:

run "sudo vgs -a".
(if you dont have vgs installed: "sudo dnf -y install lvm2")
does it report a qubes_dom0? good.

now check for logical volumes: "sudo lvs -a"
_lots_ of reports, with vm names in them? good!
what are the attrs on those (third column)? "Vwi---tz--"?
(the important part there is: no "a" in the attrs.)

then you need to activate the volume group: "vgchange -ay qubes_dom0"

after that, you should have a-plenty of new devices in /dev/mapper
and the vm-private-volume ones are the ones with names ending in
-private.

you should be able to mount these.

(or just restore them with dd to new vms)

[haaber]

On 6/3/20 10:58 PM, Boot problems wrote:
> How do I restore a mounted vm using dd?

dd = disk destroyer.

I there is the slightest chance of error, don't use it.

[haaber]

On 6/3/20 6:47 AM, Boot problems wrote:
> I tried all that in my new ssd but could not make it work, however I made an Ubuntu live CD and it worked like a charm, I can mount and see the files on each vm, so at least my files are not lost forever, but you said that the Attr should not have an -a- and it does in every single one, is that a problem?
>
> At this point I think is better for me to save the files I really need and forget about the restoring the vms
>
That is exact. If you can boot a live linux, first step is ALWAYS data
recovery. Repair attempts come second. You could use an external drive
for that. In this case, the emergency backup procedure is:

cd /externaldrive
(go to mounted external vlume)
truncate -s 200G backup.luks
(where 200G means 200 giga, change appropriately)
losetup /dev/loop0 backup.luks
(make the file a device)
cryptsetup luksCreate /dev/loop0
(setup crypto, you may use your qubes disc-pwd.)
cryptsetup luksOpen /dev/loop0 BACKUP
(open it)
mkfs.ext2 /dev/mapper/BACKUP
(generate easy fs for backup purposes)
mkdir /backup
(make backup path)
mount /dev/mapp/BACKUP /backup
(mount it)

Then create a subfolder for each VM and save all data in the right subdir.

rsync -auv /path-to-vm/ /backup/vm-name/

THINK TO PUT the final "/" at both paths!

[dhorf-hfre...@hashmail.org]

> On 6/3/20 10:58 PM, Boot problems wrote:
> > How do I restore a mounted vm using dd?

qvm-run -p HELPERVM "sudo cat /dev/mapper/qubes_dom0-vm--VMOLD--private" | sudo dd conv=sparse of=/dev/mapper/qubes_dom0-vm--VMNEW--private

this assumes you have the old disk opened in HELPERVM,
the old vm name is VMOLD and the new VM name is VMNEW.
this needs to be run in dom0, as one line (or with a linebreak after the |)
VMOLD and VMNEW can have the same name.
VMNEW needs to be created and should not have been started
before running this.
if you started VMNEW already (or need to rerun the dd),
run "blkdiscard /dev/mapper/qubes_dom0-vm--VMNEW--private"
before the dd chain.
the private volume for VMNEW needs to be same-or-bigger than the
one of VMOLD.

On Thu, Jun 04, 2020 at 01:20:43PM +0200, haaber wrote:
> dd = disk destroyer.
> I there is the slightest chance of error, don't use it.

that is really overly pessimistic, you can completely destroy your
system with pretty much any tool when used the wrong way.
yes, even with firefox.

[haaber]

>
> qvm-run -p HELPERVM "sudo cat /dev/mapper/qubes_dom0-vm--VMOLD--private" | sudo dd conv=sparse of=/dev/mapper/qubes_dom0-vm--VMNEW--private
>

how do you use qvm-run if qubes won't boot? First step is a always
proper backup, on some external drive. That is what I wrote in my other
answer.

>> dd = disk destroyer.
>> I there is the slightest chance of error, don't use it.
>
> that is really overly pessimistic, you can completely destroy your
> system with pretty much any tool when used the wrong way.
> yes, even with firefox.

Correct, but with dd it is much more easy :) If the qubesbootingdrama
was as experienced and skilled as you, he would not have asked, right?

[dhorf-hfre...@hashmail.org]

On Thu, Jun 04, 2020 at 01:45:26PM +0200, haaber wrote:

> how do you use qvm-run if qubes won't boot? First step is a always
> proper backup, on some external drive. That is what I wrote in my other
> answer.

i recommend to read what this thread is about.
the user installed qubes to a new ssd and is trying to
recover data from his old qubes install on a hdd.
both are connected to the same computer and we already
made it past the "lukeOpen and activate VG in VM" hurdles.

afaict the initial "wont boot" problem was the computer having
strong opinions about which of the devices it wanted to boot from.

[Ulrich Windl]

On 5/31/20 10:02 PM, dhorf-hfre...@hashmail.org wrote:
> On Sun, May 31, 2020 at 12:45:22PM -0700, Boot problems wrote:

>> Hello, I wanted to migrate from my old hhd to a new ssd, I installed

> [...]

>> could it be a grub issue? What can I do?
>

> assuming you were NOT reinstalling because you were compromised...
>
> - just boot your new qubes system
> - with the old HDD attached (directly or through USB)
> - check if there are partitions on it (fdisk -l /dev/hdx)
> - open the luks container from the HDD (google: cryptopen)
> - you should now have access to the lvm volume of your old system
> - with that access, you can create replacement vms and dd over their
> private volumes.

At least in the past there were issues when different devices had the
same volume group name, especially when the devices were cloned.
Maybe you need "pvchange -u ..." and "vgchange -u ...".
To protext yourself, you should (at least temporarily) rename one of the
two identical VGs (which can be a challenge by itself).

[Ulrich Windl]

On 6/1/20 1:59 AM, Boot problems wrote:
> Using fdisk -l /dev/xvdi shows me 2 partitions only, a 200m EFI System and xvdi2 a 931G Linux file system, there are no more partitions even if I decrypt, mount and fdisk -l /dev/xvdi2

luksopen won't add another partition; it will create /dev/mapper/<name>
Maybe it's easier to check the out put of these commands (after having
opened all the encrypted partitions):
pvs
vgs
lvs
(I don't think a pvscan is necessary after opening encrypted devices)

>