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.
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.
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.
Since my last post on Leap 15.0, Build 139.1 was released. It was time for a new install, so I downloaded the iso. And then I installed to a virtual machine.
I ran into some interesting bugs.
It told me that my EFI partition (at 33M) was too small. Well, I agree that’s small. But it is what an earlier build of 15.0 had created. It looks as if they have adjusted to a more reasonable size.
I told the installer to go ahead, in spite of the small EFI partition size. And I then ran into an additional bug. The installer said that some devices (the ones to which I was installing) did not exist. See bug 1082143 for details.
The installer allowed me to continue in spite of those errors. And the install was successful. So the errors were bogus.
A Tumbleweed install
Back to Tumbleweed. Actually, that Leap 15.0 is part of the background. I decided to try installing Tumbleweed into the same virtual machine where I had just installed Leap 15.0. However, this time I would allow it to delete everything on disk and make a fresh start.
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).
[Note: please see addendum at the end of this post.]
Gecko Linux is based on openSUSE. The new release was just announced, so I thought I would give it a try. The version number 423.180105, indicates that this is based on openSUSE Leap 42.3, and that this version was finalized on Jan 5th, 2018 (or 180105).
One of the limitations of the current Leap series of openSUSE releases, is that there is no live installer made available. There is, of course, a DVD based installer. So GeckoLinux is filling that gap by providing a live installer.
I downloaded “GeckoLinux_STATIC_XFCE.x86_64-423.180105.0.iso”, which is the live installer for the XFCE variant of GeckoLinux. After downloading, I verified the SHA1 checksum. And then I wrote the iso to a USB flash drive.
A quick summary for those in a hurry. I would have to call this a FAIL. I’ll give the details below. I ran into multiple failures using the recommended Calamares installer. The problems may be minor, and the maintainer of GeckoLinux will probably come out with an improved version that fixes these problems.
There have been several Tumbleweed snapshots over the last few days. But today we saw the first with a 2018 snapshot date. So I decided to do a test install.
As usual, I used “aria2c” to download the iso (“openSUSE-Tumbleweed-DVD-x86_64-Snapshot20180101-Media.iso”). I also downloaded the sha256 checksum file. I then verified the gpg signature on the checksum file. Then I verified the checksum on the iso, to make sure that I had a good download.
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.
Work on Leap 15 is underway. There was a short discussion on the factory mailing list, beginning HERE.
Two months after my last status update Leap 15 is almost rolling. Following SLE 15 I’d like to aim for a release in April.
It is worth reading that whole message, and perhaps the other emails that follow it. As the message indicates, there is now a download site for isos, in case you want to try Leap 15 for yourself.
I went to the openQA site to look at failures. And they didn’t seem too bad. So I downloaded an iso from there. It was “openSUSE-Leap-15.0-DVD-x86_64-Build48.1-Media.iso”.
Solus is a nicely themed linux distro. I particularly liked the Budgie desktop, which comes from the Solus team. Solus would not be my personal choice, because I’m a command line type of person and Solus seems more oriented to people used to Windows.
While it would not be my preferred distro, it is still disappointing that Solus does not seem to handle booting well. I’ve had Solus installed in an extra partition for some time now, and how it handles booting is an issue. Perhaps I’ll report on the problems that I have seen in another post. But, for now, I will just be describing my tests.