Opensuse Tumbleweed and UEFI
The main significance of Tumbleweed, for UEFI systems, is that there are frequent updates to newer kernels, and those newer kernels are not signed for secure-boot validation. Here, I will describe how I am dealing with that.
As described in a recent post about my UEFI setup, I installed two separate instances of opensuse. The second instance was intended just for testing things, so I decided to convert that to using Tumbleweed. After a few fumbles that worked well. So, when I decided to replace that instance of opensuse with an install of 13.1 Milestone 1, I decided to convert my primary instance of opensuse on that box to Tumbleweed, so that the Tumbleweed experience could continue. This post reports on my combined experience of Tumbleweed, spread over those two different instances.
First things first
The way to switch to Tumbleweed, is to make a few changes in the configured repos (repositories), and then update to what those repos support.
Here is the list of repos one is supposed to use:
1 | openSUSE Current updates | Yes | Yes | 99 | http://download.opensuse.org/update/openSUSE-current/ | 2 | openSUSE non-oss-Current updates | Yes | Yes | 99 | http://download.opensuse.org/update/openSUSE-non-oss-current/ | 3 | openSUSE Current non-oss | Yes | Yes | 99 | http://download.opensuse.org/distribution/openSUSE-current/repo/non-oss/ | 4 | openSUSE Current oss | Yes | Yes | 99 | http://download.opensuse.org/distribution/openSUSE-current/repo/oss/ | 5 | openSUSE Tumbleweed | Yes | Yes | 99 | http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ | 6 | Packman Tumbleweed | Yes | Yes | 99 | http://packman.inode.at/suse/openSUSE_Tumbleweed
The change amounts to renaming the standard 12.3 repos to the “current” name, and adding the two Tumbleweed repos. The “current” repos really are the 12.3 repos, by virtue of the magic of symbolic links. The change to the “current” url is so that one central change at opensuse will switch these to the next release when that time comes.
With the repos configured, one does
# zypper dup
to upgrade. Here, “zypper” is the opensuse package management tool. The command “dup” is short for “distribution upgrade”. It switches to the current version at the configured repos, and will “change vendor” (switch a software source from one repo to another) as needed.
On running that command, I ran into some sort of error — one of the updates seemed to hang forever until I killed the apparently looping process. And, after that, Gnome would not start. Following a suggestion in the factory mailing list, I changed the priority of the last two of those listed repos to 98 instead of 99. Note that a lower priority number is actually a higher priority. What was happening was that some packages had a higher version numbers in the standard repos than their upgraded version in the tumbleweed repos. So I was getting a mixed inconsistent set of packages. Changing those priorities, then rerunning “zypper dup” fixed that problem.
Once that repo priority change was made, everything began to work smoothly.
The newer kernels
The main issue with Tumbleweed and UEFI is with the newer kernels. It is an issue because those kernels are not signed. And therefore, with normal booting, those kernels will not boot if secure-boot is enabled. The simplest way to deal with the problem, then, is to disable secure-boot in the BIOS.
Personally, I don’t have much use for secure-boot. So it did not bother me that I had to disable it. However, I also wanted to have secure-boot enabled for testing, such as testing whether 13.1M1 would install with secure-boot enabled. And that meant that I was often having to turn secure-boot off or turn it back on.
It turns out that there’s another method that I can use. And that is to edit “/boot/grub2/grub.cfg”, and change it so that it does not check signatures of the newer kernels.
It’s a bit hard to read “grub.cfg” because there’s a lot of detail that has to do with how grub presents the menu. The basic idea, however, is this — grub2-efi uses a command of the form
linuxefi kernelfile [options] initrdefi initrdfile [more options]
to boot linux. If I change that “linuxefi” to “linux” and that “initrdefi” to “initrd”, then it will boot without checking kernel signature.
The upshot is that now, after any update to “grub.cfg”, I edit it and search for the words “linuxefi” and “initrdefi”. I delete the “efi” from the ends of those words when they refer to an unsigned kernel version. I do not change those words for signed kernel versions.
My practice, at present, is to always keep a signed kernel available. At present, that is kernel version 3.7.10-1.11. In the file “/etc/zypp/zypp.conf”, the multiversion line now reads (after my editing)
multiversion.kernels = oldest,latest,latest-1,running
As you can see, I added “oldest” to that line. This is so the automatic purging of older kernels will keep the oldest one around. And I make sure that the oldest one is a signed kernel. If kernel “3.7.10-1.11” is updated to, say, “3.7.10-1.14”, then at that time I will install kernel 3.7.10-1.14 and uninstall kernel 3.7.10-1.11 on my Tumbleweed system. I’ll notice the change, because my standard desktop, the one from which I am posting this message, uses standard opensuse 12.3 and a kernel update here will prompt me to do the corresponding update on the UEFI Tumbleweed box.
If some software update, such as a new kernel install on Tumbleweed, causes “grub.cfg” to be automatically updated, I must remember to re-edit that file. But, if I forget, then that’s not a serious problem. If I have secure-boot enabled, I will notice what happened because the boot attempt will fail due to the unsigned kernel. So I can then select the older signed kernel for booting. Then, having been reminded of the need, I can re-edit “grub.cfg” as discussed above.
These practices seem to be working well.