Solus is a nicely themed linux distro. I particularly liked the Budgie desktop, which comes from the Solus team. Solus would not be my personal choice, because I’m a command line type of person and Solus seems more oriented to people used to Windows.
While it would not be my preferred distro, it is still disappointing that Solus does not seem to handle booting well. I’ve had Solus installed in an extra partition for some time now, and how it handles booting is an issue. Perhaps I’ll report on the problems that I have seen in another post. But, for now, I will just be describing my tests.
I don’t often post about Windows, because I mainly use linux. But this is a Windows post. I should mention that the computer involved is a UEFI box, since that might be relevant.
My main desktop has both Windows 8.1 and openSUSE 42.2. On Friday, I attempted to install the May updates for Windows. The updates are the two listed in the subject line above.
The updates failed.
They seemed succeed. I got the message to restart windows to complete the update. So I rebooted. Then I saw the messages about “working with updates”. At around the 30% mark, it rebooted. Then, on reboot, it continued until the 100% mark. That looked good.
But then a message:
We couldn’t complete the updates
Don’t turn off your computer
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.