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 root. 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 things. 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. http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ 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.) Thanks. JJ -- 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 https://groups.google.com/d/msgid/qubes-users/4a13a2407f863a5b6a6a6f0ee6d225e4.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
