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.
Recently, I have been posting less often.
I’m actually still testing new releases and other distros. But I’m not posting about it as often as before.
The spammers are still posting comment spam as often as previously. So I have now configured comments to close 30 days after the post. The reduces the opportunities for spammers.
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
I have not been doing monthly Tumbleweed installs for a while. But this month I have done several, for various reasons. I will report on the most interesting install. Well, at least, the install that is most interesting to me. I hope my readers find in interesting.
This was an install to an external hard drive. It is a 250G Seagate hard drive, purchased back when that was a large size for external drives. I originally used that drive for backups, but I am no longer using it for that purpose.
My aim was to have an external drive that I could use for maintenance tasks on other computers. So I wanted it to be bootable on a computer with legacy BIOS booting. But I also want it to be bootable on an EFI box. And, given my recent experiments with 32-bit EFI, I figured that I should also make it bootable on 32-bit EFI.
I recently described how I managed to install and run Leap 15.0 on a system with 32-bit EFI. I decided to do some more experiments, and this time I tried with an install of Tumbleweed.
Most of my experiments with alternative methods of installing were failures. So I finished up doing something similar to what I used in that earlier post. I suggest reading that for the details. I did make a couple of improvements.
As before, I used “deepin” as a starter system, simply because that works out-of-the-box with 32-bit EFI. I still needed to start by installing “deepin”. And again, I really only needed the “/boot” from “deepin”. But I had to make that 800M to keep the “deepin” installer happy.
The first improvement that I made was to make all of the needed additions to the boot menu at the beginning. As before, I used “/etc/grub.d/40_custom” for that. I did not have all of the needed information. But by creating skeleton entries, I finished where I would only need to edit “/boot/grub/grub.cfg” for the final changes. So, after that point, I only needed to retain the “/boot” partition from the “deepin” install.
In my previous post, I described how I used deepin to help me get openSUSE Leap 15.0 installed for 32-bit EFI booting. So maybe I should briefly review deepin itself.
Deepin comes to us from China. It is apparently oriented particularly toward the needs of Chinese users. However, it also works quite well for English speaking users.
I have actually tried deepin before. I have deepin 15.5 installed on one of my computers. But I never did get around to posting a review. Version 15.8 looks similar to the 15.5 that I have installed.
Most desktop and laptop computers use a 64-bit processor, which also supports 32-bit instructions. However, some computers, particularly some tablets, come with 32-bit processors that also support 64-bit instructions. The Intel Atom processors are an example of such 32-bit processors.
The UEFI specifications require that the UEFI firmware be based on the native instruction set. For most computers, that means UEFI booting will be 64-bit. But for systems with 32-bit native processors such as the Intel Atom family, the firmware normally implements 32-bit UEFI.
Most linux systems only provide 64-bit UEFI support. In particular, openSUSE only provides 64-bit UEFI support for installation. OpenSUSE Tumbleweed does include 32-bit UEFI grub packages, but they are not part of the installer DVD.
If I want to install openSUSE Leap 15.0 on such a computer, then I will have to find ways of booting the installer. And then, after installing, I will have to find ways of booting the installed system.
I don’t actually have a computer with 32-bit EFI. But I can setup a KVM virtual machine to use the 32-bit UEFI firmware. I have actually been intending to try this for a while. So I just got around to doing it.
[Update: this bug has now been fixed. The fixed “openssh” package is in the update repo, so you should be able to install it right now. Tests here show that openssh is now working as it should be.]
Be wary of the Tumbleweed update to snapshot 20181029.
I was warned of this by some posts to the factory mailing list. So I updated my own Tumbleweed (in a VM), and ran into the same problems.
Briefly, this snapshop updates openssh from version 7.7p1 to version 7.8p1.
From the system running openssh-7.8p1, I am still able to use ssh to connect to a system using 7.7p1. However, it does not work the other way. I cannot connect from openssh-7.7p1 to openssh-7.8p1. And I cannot even connect from openssh-7.8p1 to itself (as with “ssh localhost”).
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.