[Update: this bug has now been fixed. The fixed “openssh” package is in the update repo, so you should be able to install it right now. Tests here show that openssh is now working as it should be.]
Be wary of the Tumbleweed update to snapshot 20181029.
I was warned of this by some posts to the factory mailing list. So I updated my own Tumbleweed (in a VM), and ran into the same problems.
Briefly, this snapshop updates openssh from version 7.7p1 to version 7.8p1.
From the system running openssh-7.8p1, I am still able to use ssh to connect to a system using 7.7p1. However, it does not work the other way. I cannot connect from openssh-7.7p1 to openssh-7.8p1. And I cannot even connect from openssh-7.8p1 to itself (as with “ssh localhost”).
I installed Ubuntu 17.10 shortly after it was released. And I posted a review. I recently heard that it has a serious problem. Apparently one of the kernel drivers can corrupt the BIOS of some computers.
The Ubuntu bug discussion thread is HERE.
At this point, it is unclear whether other distros are affected. Some folk are concerned that it might also be a problem for openSUSE Tumbleweed. See the discussion HERE.
I have Ubuntu 17.10 installed in two places. It is installed in a virtual machine under KVM. And it is installed on my Lenovo ThinkServer. As far as I can tell, the ThinkServer is not one of the vulnerable machines. In any case, I have not found a problem.
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.