My Tumbleweed install for October

I said there would not be a Tumbleweed install this month.  But I changed my mind on that.  Snapshot 20151017 came out after I had finished my Leap 42.1-RC1 installs, and I had a little free time.

For this install, I used a 1T disk.  It had previously been used for Windows.  I plugged the disk into a SATA disk docking station, and planned to use the entire disk for the Tumbleweed install.  I connected the docking station to a UEFI computer (via a USB cable).

First attempt

My plan was to try installing to an encrypted LVM.  There are some open bug reports indicating problems, so I wanted to see what would happen.

I booted the installer (the 64-bit DVD installer, written to a USB).  Booting was fine.  I was asked for encryption keys (there is an encrypted LVM on the internal hard driver).  I provided the key.  Then partitioning was proposed.

Since I did not want to use the internal drive, I did not accept the proposal.  Instead, I clicked on “Create Partitioning”.  On the next screen, I selected the 1T USB drive (“/dev/sdc”).  Next I clicked the option to use the entire disk.

I then clicked “Edit proposal settings”.  That’s where I told it to install to an LVM and to encrypt the LVM.  I also told it to use “ext4” for the root partition.

The result was a new proposal.  A partition “/dev/sdc1” was to be created for booting, formatted as vfat, and at around 150M.  I took this to be an EFI partition.  Another 150M partition, “/dev/sdc2”, was to be created, to use a native linux file system.  But the file system type was unspecified, and where to mount it was not mentioned.  This seemed odd.

Additionally, an encrypted LVM (“/dev/sdc3”) was to be created, at around 930G (I was prompted for an encryption key).  It would contain a 20G root volume, a 25G home volume, and a 2G swap volume.  This was also odd.  Why allocate a 930G LVM, but only use 29G of that space?  This seems like a poor choice.

In any case, I accepted the proposal, and continued with the install.  I mostly went with defaults.  When it got to the install, it failed because it did not know how to format “/dev/sdc2” with an unspecified file system.

Second attempt

I tried a second time.  This time, my plan was to go to expert mode and fill in the missing details for “/dev/sdc2”.

The second attempt was also a failure.  I again told it to use the entire disk.  But it refused to delete the LVM at “/dev/sdc2”, so did not find space for the root partition.  Perhaps this was because I had given in the encryption key, when requested.

Third attempt

On the third try, I was successful.  Given the problems that I had with the second attempt, I first booted my installed linux system on that computer, and deleted all partitions on “/dev/sdc”.  I then restarted the installer.

I went through similar partitioning steps to those in the first attempt.  Again, it wanted “/dev/sdc1” as an EFI partition, “/dev/sdc2” as an unspecified partition, and “/dev/sdc3” as the encrypted LVM.  Again, the LVM was around 930G, with 20G for root, 25G for home, 2G for swap and the remainder unassigned.

This time, I then clicked the button for the expert partitioner.  There, I changed “/dev/sdc2” to be formatted as “ext2” and to be mounted as “/boot”.

This time, the install was successful.

Booting issues

After the install, the system rebooted into the newly installed system.  Unfortunately, I could no longer boot into the opensuse that was on my internal drive.  The installer had deleted to original firmware boot entries for “opensuse” and “opensuse-secureboot” and replaced them with entries to boot the newly installed system on the external drive.

I’ll call that my mistake.  I should have expected it.  I could have given a different name for the grub2-efi distributor, so that a different boot name would be used and a conflict would be avoided.  I’ll remember that next time.  In any case, it was not hard to repair the installed system on my internal drive.  This, of course, deleted the firmware entry to boot the newly installed system.

I actually did not want a firmware entry for booting the system installed on the USB drive.  I would prefer to use the option to boot it it as a USB drive.  So I proceeded to set that up.

On the newly installed system, the EFI partition contained directories “/EFI/opensuse” and “/EFI/boot”.  The directory “/EFI/opensuse” contained the normal boot setup for UEFI.  The directory “/EFI/boot” contained two files, “bootx64.efi” and “fallback.efi”.  The file “bootx64.efi” was actually a copy of the “shim.efi” from the “/EFI/opensuse” directory.

I deleted “fallback.efi”  I then copied “grub.efi” and “grub.cfg” from the “/EFI/opensuse” directory to the “/EFI/boot” directory.  And I then deleted that “/EFI/opensuse” directory.

With those changes, if I hit F12 while booting, the UEFI firmware shows a boot entry for that USB drive, and selecting that boots the newly installed system.

Summary

The main moral to draw from this experience, is that if you want an encrypted LVM, you should set that up first to your own requirements before you start the install.  At present, you will have poor choices if you leave the decisions up to the installer.