Installing kubuntu 16.04 in an existing encrypted LVM

Ubuntu 16.04, in several different varieties, came out last week.  So I decided to give the kubuntu variant a try.  I planned to install in an existing LVM.  I knew, from previous experience, that this could be tricky.  And, to make it more tricky, I wanted “/boot” to be inside that encrypted LVM.

It didn’t quite work out.  I am successfully booting it using the grub2-efi from opensuse.  I was unable to get the grub-efi from kubuntu to work.

Background

I planned to install this to replace an experimental Tumbleweed.  I had originally set that up a year ago, to test using opensuse with “/boot” part of the encrypted LVM.  That test is now well past, and the opensuse bugs have been fixed.  So that disk space was free for kubuntu.

I downloaded the iso using “ktorrent”.  Then I checked it against the announced “sha256” checksum.  With that done, I wrote to a USB (using “dd_rescue”).  The live kubuntu system booted up without a problem.

I later booted the same USB on a different computer, with nvidia graphics.  It did pretty well there, too.  Apparently the latest version of Plasma 5 is handling the nouveau driver better than the version that came with opensuse Leap 42.1.  There were a few screen artifacts, but the plasma 5 session did not lockup.  I switched the desktop effects to use XRender, then logged out and logged back in.  That solved the screen artifact problem.

I’ll probably post a review of kubuntu 16.04 within a few days.  It is mostly running well.

Installing

I first attempted to install on Friday.

The preliminary installer screens were easy enough.  One of them asked for a password.  Reading the fine print, I realized that this was only if I wanted to install additional drivers during install, which would require disabling secure-boot.  So I skipped that part.

The next screen was for partitioning.  It offered several varieties of “guided” partitioning.  But all of them amounted to deleting everything on the disk and starting afresh with kubuntu.  I was not ready for that.  So I instead chose “manual” partitioning.

I should backup for a moment.  Before starting the installer, I ran “cryptsetup” to open the encrypted LVM that I wanted to use.  I then checked “/dev/mapper” to make sure that the volumes were all available.

The manual partitioning listed the LVM volumes and the other partitions.  I selected the volume where I wanted to install kubuntu, and set it to be formatted with “ext4”.  I then checked the swap volume.  It was already set to be used as swap.  Next I checked the home volume, and set that to mount at “/xhome” (without reformatting).  And I checked the EFI partition, which was already set to be used for EFI.  I wanted to set that to be mounted at “/boot/efi”, but the installer would not allow it.

So far, so good.  However, the bottom of the screen had a place to select where booting is to be installed.  This defaulted to “/dev/dm-0”.  That was surely wrong.  On an EFI system, I should not need to assign a partition for booting.  But, no matter what, “/dev/dm-0” was wrong.

I aborted the install at that point, and took a couple of days to rethink whether I wanted to do that.

I finally decided that this was probably just misleading information from the installer.  So I set the boot location to “/dev/sda” (the MBR of that disk), and hoped that it would be ignored.  But it probably would not cause serious damage if it wasn’t ignored.

I then went ahead with the install.  This was on Sunday.  It mostly looked to be doing well until near the end.  Then there was a message that the bootloader install had failed (I was not surprised at this).  And then another message indicated that the installer had crashed — this one was a surprise, but it was almost done anyway, so I did not panic.

Repairs

I did not expect the installed system to be bootable.

I first checked what was mounted.  And nothing remained mounted from the install.  So the installer had unmounted those before it crashed, which was a good sign.

I mounted the root file system at “/mnt”.  Then I mounted everthing else that would be needed for rescue mode.

I first looked at “/etc/crypttab” for the mounted system.  That did not exist.  So I created that file, and added the entry for the encrypted LVM.

Next, I looked at “/etc/default/grub”.  I added the line

GRUB_ENABLE_CRYPTODISK=y

which would be needed when “/boot” is part of the encrypted LVM.

Next, I did a “chroot /mnt” to move into the mounted system.  I then ran:

grub-install --target=x86_64-efi

That generated many lines of output, but seemed to be successful.  So I then ran:

update-initramfs -k all -c -v

in order to rebuild the “initrd” file.

Finally, I ran

cd /boot/grub
grub-mkconfig -o grub.cfg

to regenerate the “grub.cfg”.

Rebooting

I was ready to see if the system would boot.  So I rebooted.  I first went to BIOS settings, and disabled secure-boot.  That would give me more options.  Next, on reboot, I hit F12.  There were two boot options labeled “ubuntu”.  I tried the second.  That gave a bunch of error messages about file systems not found, followed by a grub shell.  I tried again, this time with the first “ubuntu” option.  That failed similarly.

I booted to one of my opensuse systems on the same computer, and edited the file “grub.cfg” in the directory “/boot/efi/EFI/ubuntu”.  That file should be used for secure boot.  In editing, I added a “cryptomount” command at the beginning, which should unlock the encrypted LVM so that the file systems could be found.

I now tried booting again, choosing the first “ubuntu” option (the secure-boot version).  That gave me an error message that “cryptomount” was not found.

Sigh!  Ubuntu did this wrongly.  They have to make sure that “cryptomount” is preloaded into grub.  Checking the installed “grub.cfg”, I see that it wanted to load the “cryptodisk” module.  But it had to first decrypt the LVM before it could get to that module.  That’s why a preload is needed.

Now maybe I could have forced that on the “grub-install” command line.  But that would not work for secure boot.  The grub code has to be created by ubuntu at their factory system, so that it can be signed with the ubuntu key (or canonical key).

So I went with the other alternative.  I knew that the opensuse grub2-efi did this correctly.  So I signed the kubuntu kernel with my own installed “machine owner key”, and setup an opensuse grub entry to boot kubuntu.  That worked.  I turned secure-boot back on, and it still worked.

Summary

I am now able to boot into kubuntu 16.04, using the opensuse menu entry.

My conclusion is that ubuntu support for encrypted “/boot” is not yet adequate.  Installing into an existing encrypted LVM is possible, with a bit of rescue effort.  But I advise that you use an unencrypted “/boot” to avoid the additional problems that I ran into.

Advertisements

Tags: , ,

About Neil Rickert

Mathematician and computer scientist who dabbles in cognitive science.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: