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
permanent home.

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.

Any suggestions?

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 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to