Opensuse Leap 42.1 Milestone 2
Milestone 2 for Leap 42.1 was announced on Friday. So, naturally, I downloaded the install DVD iso, and attempted an install.
Both the download and the install went quite well. As usual, I wrote the iso to a USB flash drive, and used that for installing. I installed Leap on its own (unencrypted) partition, but with swap and home coming from an existing encrypted LVM. I mounted the home volume from the LVM as “/xhome”, so that “/home” is actually part of the root partition. The idea was that users could symlink back to files in “/xhome” to make their usual files/directories available. But desktop configuration would be kept separate to avoid conflicts between different desktop versions.
Trouble began with the first boot. I was prompted for the encryption key, but the system was not reading the keyboard and this prevented entering the key.
This is actually bug 939411. I had run into it before with Milestone 1. I had hoped that it would be corrected for Milestone 2, but that did not happen.
In any case, the fix is simple. One line needs to be changed in a script that “dracut” uses for building the “initrd”. So I went into rescue mode, modified the script and rebuilt the “initrd”.
On the next boot attempt, I was able to provide the encryption key. But alas, the system still did not boot correctly. It went into emergency mode, requesting the root password. In emergency mode, I could see that “/xhome” had not been mounted, and the device special file for it, in “/dev/mapper”, was missing.
I ran the command
vgchange -a y
to make the logical volumes visible. Systemd noticed this, and immediately mounted “/xhome”. I then used
to resume normal startup. That left me with a running system.
It looks as if those emergency mode steps need to be repeated for every boot. Evidently, something is amiss in LVM handling.
I reported this problem as bug 944577.
The running system
I have mainly been testing Plasma 5. Thus far, most of what I have tested seems to be working. But I still have more testing to do.
I did notice that “ecryptfs” is not yet available. That leaves me concerned that it might not be in the final release of 42.1. By now, I have become used to having an ecryptfs private directory for keeping sensitive files. I’m not sure that I am willing to go without that.