In recent tests with openSUSE Leap 15.0 and with Tumbleweed, I have been testing out pam_kwallet. It seems to work pretty well. So I have since converted another Tumbleweed system to using pam_kwallet. However, I am not using pam_kwallet with Leap 42.3, on the grand principle that if it ain’t broke, don’t fix it.
Leap 15.0 should be released some time in May. So pam_kwallet is something you might want to think about when you install it.
What is pam_kwallet?
First things first, so I should first explain “kwallet”, sometimes called “kdewallet”. It is a protected place for storing passwords that are used by KDE applications. Typically, it is used for the WiFi passphrase, for web password and email passwords. This, of course, depends on what applications you are using for web browing and for email.
There are times when you want to have several versions of openSUSE on the same computer. For example, on one of my computers I have:
- openSUSE Leap 42.3 (this is what I mainly use);
- openSUSE Tumbleweed (for a look at the bleeding edge);
- openSUSE Leap 15.0 (alpha release of the next Leap version).
So how do I manage those, so that I can boot whichever I want?
I’ll note that, in part, this is an update of an earlier post. I’ll describe how I am handling this situation.
I’ll start with what will happen if you just install these versions willy-nilly, and go with the installation defaults.
In a UEFI box, the installer creates a directory “/boot/efi/EFI/opensuse”. That’s really directory “\EFI\opensuse” in the EFI partition (which uses the FAT file system). EFI boot files are installed in that directory, and NVRAM entries for “opensuse” and “opensuse-secureboot” are created. The “opensuse” boot entry uses “grubx64.efi” to boot the system. The “opensuse-secureboot” entry uses “shim.efi”. If secure-boot is disabled in your firmware, either of those should work. If secure-boot is enabled, then only the “opensuse-secureboot” entry will work.
I saw the announcement for Tumbleweed snapshot 20171022. So I booted up Tumbleweed in the KVM virtual machine on my desktop. And I ran “zypper dup” to apply the update. I then rebooted.
Then came the surprise. I had been using “lightdm” to login to the desktop. But, after reboot, the login screen appeared to be from “gdm”. I logged in, which took me to the KDE Plasma 5 desktop. And, from there, I checked the displaymanager setting in “/etc/sysconfig”. And that still said “lightdm”. Hmm, something was up.
In my previous post, I explained how I setup KVM. Today, I’ll describe creating virtual machines that run under KVM.
Creating with Yast
The easiest way to do this with openSUSE, is to use Yast. Click on “Virtualization” and then on “Create virtual machines …”.
In the first step (step 1 of 5), you specify whether the source for the virtual machine is an iso file, a network install, a PXE network boot or an existing disk image. For me, the iso file is the most suitable source. On the second screen (step 2 of 5), I can browse for the iso file.
On the third screen, I can specify how much memory to use. On my system, it defaults to 1G (or 1024M). For my first install, I took that default. Since that time, I have been upping it to 2G or 4G. I can also specify how much CPU to assign. I have 4-core machine. This defaults to assigning 1 cpu. I have been increasing that to 2 cpu. For my first install, however, I left it at the default of 1 cpu.
Up until now, I have mainly tested other distros by installing them in a spare partition. And I still see that as the most thorough way of testing. So I didn’t bother with virtualization.
That has now changed. I decided that it was time to give virtualization a try.
So where to start. Many people use “virtualbox” as their way of doing virtualization. I did consider that. But I decided that it would be better to use a method more directly supported by openSUSE.
Of course, “virtualbox” is supported, in the sense that it is in the repos. So wanting openSUSE support doesn’t completely rule it out. But it was not my choice.
The other main options are Xen virtualization and KVM virtualization. There’s actually a useful guide available: Virtualization Guide.
I’m a couple of days late to the party. I had intended to post on Wednesday, but our refrigerator broke so I had more urgent concerns.
The release itself went quite smoothly. I have not tried to install with the final installer. But I have installed some of the pre-release versions. And those went very well. Most people seem to be installing without problems.
Leap 42.3 is only a relatively small change from 42.2. It is still at Plasma 5 version 5.8.7. As I recall, 42.2 was released as Plasma 5.8.2 or 5.8.3, and later updates brought it to 5.8.7.
The main change that I am seeing with the KDE desktop, is that now “konqueror” comes from Plasma 5, instead of being the Plasma 4 version. However, “rekonq” is still from Plasma 4. And “Amarok” is apparently from Plasma 4.
Recently, openSUSE Tumbleweed updated Gnome to version 3.24. So I decided to give it a test. And I ran into some “problems”. This post will discuss those problems.
Gnome under Wayland
My oldest Tumbleweed system was installed in November 2014. And that’s where I first tested Gnome. At the time, I was using “sddm” for logins. Selecting “Gnome” on the login menu gave me a Gnome session running under X11. This was as expected. There was also a menu item for “Gnome-Wayland”. Selecting that gave me Gnome running under Wayland for managing the graphics.
I later switched to using “gdm” as login manager. And, with “gdm”, selecting “Gnome” gave me a Wayland session.
Next, I tried on my laptop. Tumbleweed was installed there on March 14 this year. I was already configured to use “gdm” for logins there. But, try as I did, I was unable to get a Wayland session for Gnome.
While reviewing KaOS in a recent post, I indicated that I expected to add some comments in another post. Here are those comments.
I’ll first note I am primarily an openSUSE user, so my experience with KaOS is rather less than that with openSUSE.
The KaOS software selection is different from that of openSUSE. For example, it uses Calligra for office software, instead of LibreOffice (used by openSUSE). I should add that LibreOffice is in the repo, so I could install that if I preferred. And, for that matter, if I add the KDE-extras repo for opensuse, I’m pretty sure that I can install Calligra.
I did experiment with Calligra on a spread sheet. It seemed to work pretty well. But I don’t actually use a spreadsheet very often, so this is not a thorough test.
As mentioned in my previous post, here is my separate post on booting Solus.
What’s wrong with the installation defaults for booting?
Probably nothing, at least for most users. But they do not suit my needs.
The main issue, for me, is that I have several linux systems installed. So I don’t want Solus to take control of the booting. I would prefer to have an entry added to my openSUSE boot menu.
Do I even need a bootloader?
You probably do. The grub configuration (as with “grub2-mkconfig” in openSUSE) can find other linux systems and add menu items for them. But that configuration process looks at the boot menus for the other linux systems, to decide how to boot them.
I downloaded the DVD installer, using “aria2c”. I then “burned” that to a USB. I then booted that USB to install on my main desktop.
This was a clean install. I kept the previous 42.1 on a separate disk area. That way I can boot either.
After installing, I was switching between 42.1 and 42.2. I needed to tweak the new install to suit my needs. And booting to 42.1 allowed me to get my work done. By Thursday, I had completed the switch, and I am now running 42.2.
For my other computers, I updated the already installed RC2 (release candidate 2) to the final version. For that, I plugged in the USB, and made sure that it was enabled as a repo. I then did
# zypper refresh # zypper dup