Leap 42.1 started out with some UEFI problems. The last of those were fixed in an update yesterday. However, the fix only solves the problem for already installed systems. The install media still have these problems. Since opensuse usually does not re-release install isos, it is unlikely that install problems will completely go away.
In this post, I’ll describe what were the problems and how to deal with them on a fresh install.
I’ll describe these problems in terms of the associated bug number.
- bug 950569: with this bug, the computer would seem to lockup during boot, though CTRL-ALT-DEL did work to retry the boot. Disabling secure-boot allowed the system to boot.
- bug 954126: this bug prevented booting Windows in a UEFI box, unless secure-boot was disabled.
- bug 917427: if you installed into an encrypted LVM, and if you did not use a separate unencrypted “/boot”, then the secure-boot method of booting did not work.
Boot files for UEFI
I’ll start by describing what the various files do during booting.
There have been several problems with UEFI on Leap.
As originally installed, it suffered from bug 950569, where some hardware would hang during boot unless secure-boot was disabled. This bug was originally reported for Tumbleweed, but also showed up in Leap. It was recently fixed in Tumbleweed. And today, an update showed up for Leap to fix this bug. The update also fixed a MokManager problem, which I have not personally experienced.
There’s a problem, though. The updated shim package has been installed. But the updated shim.efi was not installed in the EFI boot settings (normally in “/boot/efi/EFI/opensuse”).
A few days ago I ran into a problem with my Tumbleweed install. In this post, I’ll describe what happened and how I investigated it.
I had just updated to the 20141225 snapshot. The availability of that snapshot had been announced on the factory mailing list. I updated using the command
# zypper dup
During the dialog for the update, I noticed that this included an updated kernel (3.18.1-1-desktop).
After the update, I rebooted to make sure that I was using the newly installed software. And that’s where I ran into problems. My Tumbleweed system is using an encrypted LVM. So, as expected, I was prompted for the encryption key during the boot. When I tried to type in the key, nothing happened. It looked as if the keyboard was not being read. Note that this system is using a generic USB keyboard. It’s actually a Dell keyboard, though the computer itself is a Lenovo.
In an earlier post, I noted a problem of infinitely looping caja, when MATE is installed alongside other desktops. If MATE is installed as the only desktop, this problem does not occur.
A workaround has been provided in the bug report. It requires editing the file “.gtkrc-2.0” in the home directory. That file contains an “include” line that reads in settings for the KDE oxygen theme. That’s apparently what causes the problem. Simply commenting out that line fixes the problem, and the MATE desktop now loads without that looping.
I’m not at all sure how that will affect KDE. Presumably those settings are for gtk applications (such as firefox) that are run under KDE.
For the moment, I have two versions of that file. I switch to the MATE compatible version if I am about to start MATE. Otherwise I use the standard version. I mainly use KDE, so I won’t be switching very often.
In my previous post, I described how to install MATE. I have since run into two problems. One of these is minor, and has to do with WiFi. The other is a serious problem that occurs in some circumstances.
The (minor) WiFi problem
I had indicated that, after switching to NetworkManager, there was a WiFi applet in the panel. But I had not made much use of that applet, other than to check whether connected.
I later tried to edit the connection settings for one of my connections. And that failed, because a “polkit” agent was not running.
This was easy enough to work around. I simply started “/usr/lib/polkit-gnome-authentication-agent-1” and I was then able to edit connections.
I have successfully used “gparted” from the opensuse 13.2 live rescue image (if you can call that success). But I did run into some initial problems, which I will describe below.
Here’s a quick summary. If you want to use “gparted” on the live rescue system, then I recommend the following steps:
- logout, returning you to a login prompt (a “lightdm” prompt);
- login again, but select “Icewm” as the desktop to which you will login;
- open a terminal session in “icewm” by clicking the terminal icon near the bottom left;
- use the “su” command to become root (no password is needed);
- run “gparted” at the root command line.
Using from the “icewm” desktop works fine. But I first tried to use with the default XFCE desktop, and that ran into problems.
A brief note on konqueror.
It is crashing badly for me on opensuse factory and on opensuse 13.2-RC1.
It seems that there is some kind of conflict between konqueror and the other desktops (Gnome, XFCE and LXDE) that I usually install. If I install only KDE, then konqueror works well. But if I also install Gnome, XFCE and LXDE, then konqueror crashes on many sites.
If I switch konqueror to use the KHTML engine instead of the WebKit engine, then it is stable. But I’m not a fan of KHTML, so I prefer it with WebKit.
When 13.2 final is released, I guess I will install only KDE on my main desktop, so that I can have a stable konqueror. I’ll continue to install the other desktops (in addition to KDE) on my laptop and backup systems.
This problem has been reported as bug 901006.
[the kernel update to fix this problem is now available 5/19/2014]
I’ve just noticed discussion of a recently discovered kernel bug:
This does not appear to be of great concern for the typical home user of linux, but is a potential problem for servers.
We can probably expect to see a kernel update soon.
I have briefly mentioned this in an earlier post.
When I look around, while running 13.1, I notice that there are some systemd user manager processes:
% ps -ef | grep '[/]systemd' root 377 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd-journald root 418 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd-udevd root 749 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd-logind lightdm 3258 1 0 10:29 ? 00:00:00 /usr/lib/systemd/systemd --user root 3421 1 0 10:30 ? 00:00:00 /usr/lib/systemd/systemd --user rickert 3443 1 0 10:30 ? 00:00:00 /usr/lib/systemd/systemd --user
The last three of those are user manager processes, as shown by the “–user” flag to the process. There is also an additional process that seems to be PAM related:
% ps -ef | grep '[p]am' lightdm 3259 3258 0 10:29 ? 00:00:00 (sd-pam) croot 3423 3421 0 10:30 ? 00:00:00 (sd-pam) rickert 3447 3443 0 10:30 ? 00:00:00 (sd-pam)
Well, technically, it isn’t solved until a fix is officially out. But the problem seems to have been tracked down.
Here’s how I described the problem in an earlier post:
I was alerted to a possible problem while running Tumbleweed on my Dell Dimension C521. After installing a 3.11.0 kernel on Tumbleweed, found that it would not boot. During boot, I was prompted for the LVM encryption key. But the system seemed to never respond to what I typed in. It looks to me as if it is failing to read the USB keyboard.
This issue was reported (by another user) as bug 839071.