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.
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.
Since my last post on 15.0, there have been several new beta releases. We have seen Build115.1, Build 124.1, Build 127.1, Build 128.1 and Build 129.1.
With that many builds, I have not been downloading them all. I have been updating my 15.0 systems. I am updating them in the same way that I update openSUSE Tumbleweed. That is, I am using
to update from the repos. My most recent install attempts have been with Build127.1, though most of my systems are now updated to the latest version.
Things are mostly going well with 15.0. The final release is still planned for May. But if you want to take a look at pre-release versions, then now is a good time to try.
What I have tested is mainly working well. There are still a few bugs in the partitioner, as used for install. Some of those bugs have already been fixed in the latest updates.
Build 109.3 of Leap 15.0 was announced on Friday. So I download and installed. With build 109.3, it is now announcing itself as a Beta release. Previous releases that I tested have indicated that they were Alpha releases.
I followed my usual practice of downloading with “aria2c”. I am using the download site download.opensuse.org/distribution/leap/15.0/iso/. I first used “wget” to download “openSUSE-Leap-15.0-DVD-x86_64-Build109.3-Media.iso.sha256” (the checksum file). I then verified its gpg signature. Next, I downloaded the iso itself. And I used “sha256sum” to verify the sha256 checksum. And, following that, I wrote the iso to an 8G USB flash drive. Read More…
Yesterday, I reported on GeckoLinux. And I found a few problems. I’m happy to say that the maintainer noticed my report, and has provided an updated release 423.180107 to correct those problems.
This time, just to be different, I tried the Plasma version instead of the XFCE version. I downloaded the iso, following the links at the GeckoLinux site. I then verified the download using the provided sha1 checksum.
To test, I planned only to use the downloaded iso as a virtual CDROM with a KVM virtual machine install.
I was already running “virt-manager”, so I used the menu option to define a new virtual machine. I set it to use 10G of virtual disk space, which should be sufficient for my testing. And I set it to use 2G of memory and to use 2 processors (from the 4-core processor in my main desktop system).
I notice, on Thursday Jan 4th, that Build 84.1 was available at the download site. So I download, and did some testing.
As is my usual practice, I used “aria2c” to download the iso, and I used “wget” to download the checksum file. I then verified the “gpg” signature on the checksum file, after which I used the checksum to verify the downloaded iso file.
My first test was to update an existing 15.0 system. For that, I wrote the iso to a USB flash drive. I then configured that flash drive as a repo. And, following that, I used “zypper dup” to bring the existing 15.0 system up to date. When I do this, I can see that most of the updated software comes from the local USB that I configured as a repo. Some updated software comes from the online repos. The “zypper” command seems to recognize that the repo on the local USB is to be preferred to the online repo, when the software is available in both places.
A quick reminder that Leap 15.0 is still at the alpha pre-release stage.
Today, I decided to experiment with upgrading. I have openSUSE Leap 42.3 installed in a virtual machine under KVM. So I cloned that virtual machine, using the “virt-clone” command (as root). I then proceeded to upgrade it to Leap 15.0.
This is intended to be a throw-away. I’ll delete that upgraded virtual machine after a few days of testing. I may repeat the entire procedure when 15.0 is closer to final release.
I first booted the clone VM, to make sure that it could boot into Leap 42.3.
Next, I shutdown that VM. Then on the “hardware details” screen of the viewer, I configured the virtual DVD device to use the DVD installer iso for Leap 15.0. I also checked the box to enable the boot menu (under “boot options”).
The next Leap version, 15.0, is still showing as an alpha release. Still, I was happy to see the install iso for Build 79.1 show up at the download site last Wednesday. At around the same time, there was an update message on the factory mailing list, reporting the current status of Leap 15.0.
According to that update message, the current aim is for a final release in May of 2018. That seems more realistic than the earlier (Feb/March) suggestion.
When I noticed that the iso was available, I of course downloaded it. I followed my usual practice for this:
wget http://download.opensuse.org/distribution/leap/15.0/iso/openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso.sha256 aria2c -V -R http://download.opensuse.org/distribution/leap/15.0/iso/openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso gpg --verify openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso.sha256 sha256sum -c openSUSE-Leap-15.0-DVD-x86_64-Build79.1-Media.iso.sha256
In turn, those commands download the sha256 checksum and the iso itself. Then they verify the gpg signature on the checksum file, and the checksum of the downloaded iso file.
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.