I have been seeing mentions of Leap 15.1. What I mainly see are notes in the factory email list or in bug reports. And they suggest that planning is already going on for Leap 15.1.
I decided to look at the download area. I used the link that I have for the Leap 15.0 download area, but I changed the “.0” to “.1”. And that found a download page. And, on that page, was the link to download the DVD installer for Build271.4.
So I downloaded. I first downloaded the “sha256” checksum file, using “wget” for that download. Then I verified the “gpg” signature on that checksum file. Next, I downloaded the DVD iso file, using “aria2c”. And, when that download was complete, I use the “sha256sum” command to verify its checksum.
I decided to go ahead and try a test install. My plan was to install to a virtual machine under KVM, using the downloaded “iso” file as a virtual DVD. I went with legacy bios booting for the VM. The installer booted up without difficulty.
A few days ago, I noticed (at DistroWatch.com) that there was a new release of GeckoLinux. So I decided to download it and give it trial run.
GeckoLinux is based on openSUSE. The new release feature openSUSE Leap 15.0, which is the latest stable release from openSUSE. GeckoLinux also has rolling versions, based on openSUSE Tumbleweed.
The home page of GeckoLinux lists the various versions available. Since I mainly use KDE, I decided to go with the KDE Plasma 5 version of GeckoLinux. So I downloaded the image “GeckoLinux_STATIC_Plasma.x86_64-150.180607.0.iso” to use for my test install. I checked the sha1 checksum, which showed my download to be good.
In the past, I have usually written the downloaded iso to a USB, and then booted from that USB flash drive. However, for this version, I decided to test only in a KVM virtual machine. And, for that, I can use the iso file as a virtual DVD for the virtual machine.
Leap 15.0 was released at around 1200 UTC today, which is around 7am at my local time (Chicago time).
There appears to have been a problem with the bit torrent seeding. I hope that was fixed. For my own download, I used aria2c, which uses the meta4 link.
Today, I downloaded the DVD installer. And I then did a final test install. This went perfectly. I also downloaded the live KDE media, and booted that as a virtual DVD on a KVM virtual machine. That booted up nicely. However, the live download page has updated since my download.
My laptop is already running 15.0. And 15.0 is already installed on my main desktop, but in a different partition. I’m continuing to run 42.3 for another day or two before I switch over. My main desktop is also a file server for the home network, so I have to do the changeover at a time when it won’t disrupt anything.
A good launch
It looks as if Leap 15.0 has had a good launch. I am hearing very few problems reported at the openSUSE forums. Actually, a number of users started running 15.0 during the testing phase.
I’m expecting this to be a very good release.
OpenSUSE Leap 15.0 is expected to be released on Friday May 25th. That’s just a few days away. I have already posted two guides to different aspects of installing:
So here’s one more post before the release. I will fill in some of the gaps left by the other guides.
Some quick notes
First some notes. If you have already been testing pre-release versions of openSUSE 15.0, then now would be a good time to run
from a root command line. This should bring your system to the final release version. After that, you should update the usual way with “zypper up” or with the desktop update applet, or with Yast online update.
It is expected that Leap 15.0 will be released by the end of this month (May 2018). At present, I have Build 241.1 installed for testing. It is considered to be a release candidate.
The biggest installer change from earlier openSUSE releases is with the partitioner. So that’s what I’ll be discussing in this post.
I’ll note that the new partitioner is also being used if you install Tumbleweed. And, after installing Leap 15.0, you will also be able to access the partitioner via Yast, for making changes to your disks.
And one additional note about the installer. Before now, I have been reporting a problem with installing into an existing encrypted LVM. The problem was that the installer failed to create “/etc/crypttab”. That has now been corrected. So installing into an existing encrypted LVM should be relatively straightforward.
Starting the install
My previous post was on booting the installer. And there, I showed the possible boot screens for legacy booting or UEFI booting. Now let’s look at what we will see after booting the installer.
OpenSUSE Leap 15 is getting closer to release. The last two builds have been release candidates. Or, at least, the last two builds no longer say “Beta”, so I take them to be release candidates.
This post will be about booting the installer. And perhaps that’s no big deal. However, some folk are unsure on whether they have booted the installer in UEFI mode or in Legacy boot mode. So I am including some screen shots to help explain the difference between the boot screens. These screen shots are from when booting the install media (Build224.1) in a KVM virtual machine. Using a virtual machine is what makes it possible to take a screen shot while booting.
Ubuntu-18.04 was announced yesterday. I had been waiting for this. So I soon started a download. I used torrent for the download. I also downloaded the checksum file and its gpg signature. After the download completed, I verified the gpg signature for the checksum file, and then I verified the checksum for the install iso.
My earlier install of 16.04 was intended as a trial run for 18.04. As in that case, my plan was to install in an existing encrypted LVM. I expected this to be easy. But it wasn’t.
The install went smoothly enough. But the installed system would not boot. I was never prompted for the encryption key.
I eventually got it working. Having found out where I went wrong, I did another install, this time to a KVM virtual machine. And that install worked out very well. So that’s what I will describe.
I’ve been testing Leap 15.0 for some time. I have not always posted about that. As long as it is working, a post would not be very interesting. However, it is time to sum up the current status.
We now have a release date for the finalized Leap 15.0. The plan is to release on May 25, at 12:00 UTC. See the announcement for more details:
I’m expecting further test releases before that date. They will mostly be release candidates. My own plans are to update my current installs for each release candidate. I probably won’t do another full install on a real machine, but I will install some of the release candidates on a KVM virtual machine.
My current usage
At present I am still using Leap 42.3 on my main desktop. Sometime within the next week or so, I plan to switch to full time use of Leap 15.0, and mostly retire 42.3.
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.
Yes, Ubuntu 16.04 is old hat. This was a recent re-release, but who cares with 18.04 just around the corner. But I decided to install anyway, and I’ll shortly explain why.
The problem with installing Ubuntu into an existing encrypted LVM, is that it doesn’t boot. You have to go into repair mode to fix it. The reason for this is that the file “/etc/crypttab” is not created by the install. And the system won’t boot unless that is created and the “initrd” file is generated so as to contain a copy of that file. That’s needed to handle the crypto early in the boot process.
What has changed?
I’ve done this before, and blogged about it. So what’s new?