I've finally got Qubes set up in a way I'm comfortable working every day.
Now I wanted to move that same installation to another drive for its
The current drive has a standard bios /boot partition (sda1), and an
encrypted extended partition (#5) containing lvm with swap and /.
The destination drive has a few existing partitions on it, #2 - Extended
partition containing #5/#6/#7 which are a few encrypted partitions
containing some data I'd like to keep.
The destination drive has a 500M empty space at the start ready for
partition #1 (/boot) and 550G at the end, ready for partition #8, a future
encrypted partition, which will contain a physical volume/volume group
containing the logical volumes for swap and /.
1) First attempt to migrate, I created the new /boot partition by hand,
rsync'd from the old. Similarly, I created the new encrypted partition,
added the pv,vg,lvm's for swap/root, and rsync'd all the data from the old
root to the new root.
I tweaked up the UUID's in /boot/grub2/grub.cfg, /etc/crypttab,
/etc/fstab, and (I think) in the initrd.
However, that failed to boot. It got as far as dropping into the dracut
shell, and when I manually set up the qubes_dom0/root to be /dev/root and
exited, systemd went a little ways, but then went into some loop where it
kept saying target paths were ready, but did nothing further. Argh.
2) Second attempt was a raw DD of both /boot and the whole encrypted lvm
partition. (The destination partitions, luckily, were bigger.)
I then unplugged the original drive (since there'd be conflicting UUID's
now), rebooted, and same deal... The boot wouldn't mount the crypted
drive, and went into some loop.
Third attempt, I figured I'd do it the more official way, and do a fresh
install of Qubes, and then restore a backup from my old setup.
But with 3.2rc3, I couldn't get the installer to do what I wanted.
Occasionally I'd get a weird pop-up error about "e not being defined yet"
or something like that. :S
I tried and tried to coax it into creating a biosboot partition in
/dev/sda1, and making a /dev/sda8 as an encrypted, lvm-containing
partition, to no avail.
The closest I came, when it described the steps it was about to take (nice
feature!), it said it was going to create a partition in /dev/sda8, put an
LVM in that, and then create two Luks partitions, one for swap and one for
That's not what I had before, and not what I wanted. I wanted the
encryption outside the LVM, which I thought was the standard way of doing
If I choose "automatically partition the drive", will it preserve my
existing #5/#6/#7 extended partitions and just add new partitions as
needed? I don't want to nuke everything by mistake.
Also, on my first attempt to set it up, for the heck of it, I made the
/boot partition encrypted.
That part seemed to work fine; asked for passphrase right away, decrypted
/boot, loaded xen/vmlinux/initrd and started things rolling. But the same
systemd failure happened as described above. So I went back to
non-encrypted /boot. I do think encrypted /boot might be a good default
or optional feature for Qubes. Why leave more attack surface than
necessary, and the /boot partition is a pretty big glaring one.
(Why would an attacker care if root is encrypted, or bother with it, if
they have free reign to tamper with an un-encrypted /boot with all it's
kernel-ey and initrd goodness. It's like locking your front door, but
leaving your basement door wide open.)
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.