On my last post about Tumbleweed installs, I noted two serious problems:
- installs using the live media do not work correctly;
- a weak password encryption method is used.
I have since done some more installs. And, happily, both problems seem to have been resolved.
I did a new install with Tumbleweed live KDE around 10 days ago. And the install went well. On first boot, the installed system booted without any problems.
After that live install, I checked “/etc/shadow”. There was still a problem there. The encrypted password for the newly defined user was using the weak DES encryption. As before, the root password did use the more secure sha256 hashing method.
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”.
I had been watching for this. I’ve been noticing Solus for a while, and have previously reviewed earlier version. But the future of Solus was in question. Some time last year Ikey Doherty, the founder of Solus, walked away. I’m inclined to say that he abandoned the project. But others in the team picked it up, and managed to get some help from Doherty to set the project on a new footing. If you do a web search for “Ikey Doherty” you will find some of the history of this. But details of that history are beyond the scope of this blog.
So now that Solus 4.0 is out, it looks as if the team has been successful in reestablishing the project. And, naturally, I decided to give it a test run.
To download, I went to the “Download” page (linked from the announcement). There, I used the torrent downloader to retrieve the Budgie Desktop version.
KaOS-2019.02 was released recently, so I decided to test it.
I’ll note that I have tested it only in a KVM virtual machine. I have previously tested earlier KaOS versions on real hardware. But I logged into KaOS so infrequently, that I decided to only use a virtual machine install this time.
What is KaOS
KaOS is a rolling release, featuring the KDE (Plasma 5) desktop. It usually keeps up with new releases from KDE.org. The current release is using Plasma 5.15.2, KDE Frameworks 5.55.0 and QT 5.12.1.
In prior experience with earlier versions of KaOS, it often had the latest KDE release a day or two earlier than openSUSE Tumbleweed.
I downloaded the iso from the source-forge download site. I verified the provided gpg signature to check the download. I already had a copy of the signing key on my keyring, from earlier tests of KaOS.
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.
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?