Around two months back, I experimented with kubuntu-19.04. I’m not intending to post on that. But, while testing, I noticed a padlock icon in the system tray. It turned out to be the icon for Plasma Vault.
Checking, I found that Plasma Vault was available for openSUSE. At that time, I was using Leap 15.0 and testing the pre-release version of Leap 15.1. So I installed Plasma Vault in both, for testing. And I also installed in openSUSE Tumbleweed. As the name suggests, it is part of KDE Plasma 5.
In brief, Plasma Vaults allows you to have a directory with encrypted files. You see the files as plain text (unencrypted). But what is actually stored on disk is encrypted.
The image above is a screenshot from clicking on that tray padlock. It shows two vaults (directories).
Installing Plasma Vaults results in a directory “Vaults” under my home directory. It was initially empty until I created some vaults. You can see the option there, to create a new vault.
It is close to release time for openSUSE 15.1. My experience with testing pre-release versions has been pretty good. I expect this to go well. I’ve prepared a selection of screenshots as a guide to installing.
These screenshots were all taken on virtual machines (with KVM), because that makes it easier to take screenshots of an install.
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.
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.