I just upgraded my Dell XPS 13 Developer Edition (AKA “Sputnik 3”) to Ubuntu 14.04, the newest LTS release, in order to hopefully clear up some remaining glitches and source some newer software more easily. So far it seems to have been a mostly painless process, although there were a few hiccoughs getting encrypted disks working to my liking. This is how it went.
Preparing for installation
Because the Dell 12.04 image contains a number of third-party packages, I decided on a wipe-and-reinstall rather than an upgrade. My experience with various distributions has been that upgrading from a system with significant third-party package presence in the core system (such as drivers and X configuration, as was the case with the Dell image) is asking for trouble.
I have a large, encrypted offline backup disk, so I just booted to the install live image, mounted that disk, and dd'd the entire SSD to it. I then also took an image of only the encrypted /home partition, for convenience. This way I have my entire configuration and all auxiliary data, if I need it, but in the best case scenario I only have to copy over the home partition and be done with it.
With that out of the way, I just unmounted the backup disk, unplugged it, and then blew away the partition table. I'm not clear whether this is ideal from a TRIM point of view or not, but it was at least fast and easy.
Unlike the 12.04 installer, the Ubuntu 14.04 installer knows about whole-disk encryption. Unfortunately, the only way it seems to be able to do it (at least, assuming you want to use LVM) is to encrypt the entire disk other than /boot as a single LUKS partition, and then make that partition a LVM physical volume. This means that every partition on the system is encrypted under one key, and that it is impossible to create clear partitions. Well, that's no good. Therefore, I had to work around the installer again. This time, it was easier because the live image already knows about both LVM and encrypted volumes.
After determining that the default installer wouldn't do what I wanted it to do (boring details omitted), I tried a couple of workarounds before I landed on an actual solution. Unfortunately, I wasn't able to do a completely encrypted install — I wound up having to do a clear install and then encrypt it. This does require more twiddling with config files than I would prefer, but it worked.
First off, I wanted to use LVM but I didn't want to allocate the entire physical volume to a single logical volume. For some reason, this is all the installer appears to know how to do. To get around this, I booted to the live image and partitioned the disk myself. I created a 256 MB /boot partition, a 16 GB swap partition, and an LVM physical volume on a partition spanning the remainder of the disk. On the physical volume, I created a root partition volume of 30 GB and left the rest free. That done, I started the installer and installed the system to the pre-created partitions using manual partitioning.
Setting up encryption
After installing the system, I booted it once and immediately shut it down to get a plausible /etc/mtab in place and generally populate things that may populate on boot. I then rebooted to the live image.
Armed with a ready-to-go disk image, I created another LVM volume for the encrypted root (named root-crypt) and LUKS formatted it per my earlier article on Ubuntu encrypted disks. I then used cryptsetup to mount it, and repeated the process for a home volume named home-crypt. These two volumes are given mapper names of root and home, respectively, when opened. I then mounted these volumes and populated the root with the newly installed image and the home volume with my backup image. For the root volume, I mounted both the installed root and the newly formatted image in separate directories under /mnt and copied the data across with rsync -a. For the home volume I used dd to put the encrypted image back byte-for-byte. Having done this, I deleted the unencrypted volume and then mounted these filesystems, /boot, and various other necessary bits as follows:
mount /dev/mapper/root /mnt mount /dev/mapper/home /mnt/home mount /dev/sda1 /mnt/boot for dir in /proc /sys /run /dev; do mount -o bind $dir /mnt/$dir done
This gets enough stuff in place to chroot to the encrypted install with sudo -H chroot /mnt. Once you're in, there's a variety of patching up to do before the system is bootable.
First, for some reason Ubuntu doesn't install cryptsetup by default. Without it, an encrypted root isn't bootable. It took me a few minutes to figure that out, actually, because why wouldn't it be installed? It's installed on the live image! At any rate, apt-get install cryptsetup takes care of that.
This will create an /etc/crypttab, but of course it doesn't know anything about the encrypted volumes that were just created. Therefore, it and /etc/fstab have to be patched up for the new configuration, and then /etc/mtab has to be brought into line so that update-initramfs will be able to do its job. For the first two files, they should look something like this (after prepping encrypted swap, per my previous article):
# fstab /dev/mapper/root / ext4 errors=remount-ro,relatime 0 1 /dev/mapper/home /home ext4 relatime 0 2 /dev/mapper/cswap0 none swap sw 0 0 # crypttab root /dev/vg0/root-crypt none luks,discard home /dev/vg0/home-crypt none luks,discard cswap0 /dev/sda2 none luks
The third, /etc/mtab, has to be fixed up to reflect the above mountings, which should be pretty straightforward. The old device names simply have to be replaced with the new mapper names.
With the filesystems configured, update-initramfs can be used to generate an initial RAM disk that has encrypted disk capabilities, and then update-grub can be used to fix up the root drive at bootup, as follows:
update-initramfs -k all -u update-grub
At this point, the system should boot, and ask for three passphrases on the way. Unlike 12.04, it even does it without undue graphical glitchery!
Fixing up features
This section will probably change as I locate more broken stuff, but so far it really has only required fixing hibernate and the touchpad (which is admittedly a biggie!).
First, the touchpad. For some reason, the i2c_hid module prevents multitouch from working on the touchpad, and generally causes it to be a little bit spastic. Fixing this is as simple as blacklisting the offending module. To do this, create a /etc/modprobe.d/blacklist-i2c_hid.conf file and place the single line blacklist i2c_hid in it. On the next reboot, it won't muck things up and synclient can be used to configure the touchpad the same as in 12.04.
The good news about hibernate is that it's a lot easier than it was in 12.04! All I had to do to get it working was edit /etc/initramfs-tools/conf.d/resume to point to the new encrypted swap device, rebuild the initial RAM disk again, and it seems to work fine. For some reason I have to decrypt both the root disk and the swap disk on resume (in 12.04 I only had to decrypt the swap disk), but that doesn't seem like a big deal.
Update 2014-04-26: The rsync-across method for achieving separately encrypted LVM volumes did have some collateral damage — rsync does not preserve capabilities. This first manifested itself as an inability for non-root users to ping, receiving the error message “ping: icmp open socket: Operation not permitted”. I fixed this by removing the ping package (which took with it ubuntu-minimal) and reinstalling it via ubuntu-minimal, which restored the cap_net_raw capability. There may be other, harder-to-fix permissions problems to deal with in the future. We shall see.
I'll admit that I basically didn't even look at the new default UI. I just installed my bevy of usual packages and logged right back into fvwm. I therefore can't say much about that.
However, I have been pleased with the Just Workingness of all the other stuff I've used so far, modulo the encrypted disk setup pain documented above. It also seemed less painful than 12.04 was, but that may just be because I've been through this rodeo recently. The fact that the wireless works on the live image and that it contains all of the packages I needed to hack up the setup out of the box make things seem easier, for sure. The (relative) simplicity of getting encrypted hibernate going was a big bonus, too. They're within epsilon of having it work configuration-free!
It's only been a few hours. There may be some time bombs in here I don't know about yet.