As mentioned in my previous post, the plan for the jump project is to be able to take some packages directly from SLE to build the next Leap version. Since that post, an updated version has been release. It is Build76.2, released 4 days ago. So I downloaded this release, and installed to a virtual machine for testing.
Again, I installed only the KDE desktop. And KDE does not come from SLE, though other basic packages do.
Here are some of things I have seen change in the latest release:
- When installed, this is now called “Jump 15.2.1” instead of Leap 15.2.
- It now has its own repos. Previously, if you installed Jump and then updated it, you would have a standard Leap. Now if you install Jump 15.2.1 and update it, you still have Jump. This is a necessary step, in moving toward 15.3.
Yesterday, I took a look at the Jump 15.2 download site.
Well, more accurately, I looked to see if I could find a download site. And it was there, with an iso ready for test.
For future reference, follow this link to the DOWNLOAD SITE
So what is Jump 15.2? It is really Leap 15.2, but being rebuilt in a different way. It is a test for how 15.3 will be built.
The Jump project
With the Leap series thus far, openSUSE is using some software sources from SLE and some that came from Tumbleweed. Those sources are then builts at OBS (the Open Build System) to produce the software release.
With the Jump project, the idea is to reduce some of the redundant operations. So the Jump release is supposed to use rpm binary packages that were built for SLE where available, and separately build the binary packages where the source does not come directly from SLE.
The release of Leap 15.2 is expected in early July. As previously posted, I have been using 15.2 on my main desktop for around 6 weeks. I update it as new releases become available. It has been at the RC level (release candidate) for a little over two weeks now.
My advice on installing is based on the release candidate. I’ll include a small set of images (printscreen images) to illustrate how the installation goes.
Preparing screen images
First a note on how I prepared these images. I downloaded the latest DVD installer. And I booted to that (as a virtual DVD drive), on a KVM virtual machine. I actually used two different virtual machines — one for legacy booting and another for UEFI booting.
Yes, Leap 15.2 is still in Beta testing. However, I have now switched over to 15.2 on my main desktop.
I installed 15.2 some time ago, and have been periodically updating it since then. My plan was to switch to 15.2 shortly before the release date, because I can test more thoroughly when it is the system that I use for normal computing activity.
The original plan was for Leap 15.2 to be released in May, which is this month. However, there has been some slippage in that date:
Final release of Leap 15.2 is now expected to be in early July. In spite of that delay, I decided to go ahead with my planned switchover to using 15.2.
There’s a new plan afoot to more closely link Leap with SLE (the Enterprise SUSE release). This is the “Jump” project, mentioned that factory mailing list message, an that is the reason for the slippage. We will probably see that change for Leap 15.3, but there are some preparations being made now. The idea is that for packages that come from SLE, we will use them directly without have to rebuild. That should save effort. Leap packages that do not come from SLE will continue to be handled as they are now.
My main desktop is also an NFS and Samba server for the home network. I had already setup both NFS and Samba on the 15.2 install, a month or two ago.
There was another update to openSUSE Leap 15.2 last week. I updated my installs at that time. I currently have it installed in two KVM virtual machines and on an external USB drive. I’ll note that 15.2 is still at the Alpha testing phase.
The most recent update brought Gnome to version 3.34.2. This will probably be close the final release version. It seems to be working pretty well. OpenSUSE Tumbleweed went to Gnome 3.34.2 some time ago. But, judging by bug reports, there were some problems in preparing this Gnome version for SLE 15 and for Leap 15.2. Apparently, those problems have been mostly resolved. Read More…
When I recently updated my Leap 15.1 systems, the “Beta” disappeared from the version information in “/etc/os-release”. That indicates that we are now seeing release candidates rather than beta versions. The final release is expected to be in late May.
After noticing this, I download the DVD installer iso so that I could try a clean install. As usual, I used “aria2c” for the download. And I also downloaded the sha256 checksum file. The gpg signature on the checksum file validated that download, and then the checksum validated the iso download.
The install itself went well. I mostly took the defaults. I selected the KDE desktop (there isn’t a default choice there). And this install was on a UEFI virtual machine (under KVM).
As indicated, I took the defaults for most choices. And, as a result, the installer used “btrfs”. I have normally avoided “btrfs”, and will probably revert to using “ext4”.
OpenSUSE 15.1 is moving along steadily. I have been testing most releases. Sometimes I download the DVD installer for testing an install. And, at other times, I just update my already installed systems.
During the alpha testing phase, I was mostly doing this in two differently configured KVM virtual machines.
The first Beta release was Build414.1, which was available Thursday last week. I downloaded DVD installer for that, and wrote that to a USB drive. I then installed on a virtual machine. And later that same day, I installed on a real computer (a laptop).
Since that time, there have been two more releases — Build416.2 was available around two days ago. And, today, Build417.2 came out.
My update procedure, at present, is to use
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.