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.
Last month, I created a Tumbleweed Virtual Machine (or VM), using KVM. Yesterday’s project was to install into that existing VM. I wanted a clean install, retaining “/home” but reformatting everything else.
Fortunately, that previous install was for UEFI booting. I’m not sure how easy it would have been to do new install into the same BIOS based virtual machine.
I started by downloading the DVD installer for Tumbleweed snapshot 20171007. As usual, I downloaded the sha256 checksum file with “wget”, and I downloaded the iso itself using “aria2c”.
I then verified the gpg signature on the sha256 checksum file, using gpg. Then I used “sha256sum -c” to verify the checksum of the download iso file.
In my previous post, I explained how I setup KVM. Today, I’ll describe creating virtual machines that run under KVM.
Creating with Yast
The easiest way to do this with openSUSE, is to use Yast. Click on “Virtualization” and then on “Create virtual machines …”.
In the first step (step 1 of 5), you specify whether the source for the virtual machine is an iso file, a network install, a PXE network boot or an existing disk image. For me, the iso file is the most suitable source. On the second screen (step 2 of 5), I can browse for the iso file.
On the third screen, I can specify how much memory to use. On my system, it defaults to 1G (or 1024M). For my first install, I took that default. Since that time, I have been upping it to 2G or 4G. I can also specify how much CPU to assign. I have 4-core machine. This defaults to assigning 1 cpu. I have been increasing that to 2 cpu. For my first install, however, I left it at the default of 1 cpu.
In yesterday’s post, I discussed ways of having multiple linux installs on that same computer, using my laptop as an example. Today, I continue with that, but mostly concentrate on the details of booting.
If you have multiple versions of linux installed, then you presumably want to be able to boot any of them. Fortunately, linux usually installs a boot manager, typically grub2, which provides a menu that allow selecting which system to boot.
There are a couple of problems with this. Firstly, the most recent linux that is installed usually takes over the booting. And that might not be what you want. And, secondly, if there is a kernel update on one of the installed linux versions that is not controlling the boot, that might cause problems on the next boot unless the boot menu that you use is updated.
Leap 42.1 started out with some UEFI problems. The last of those were fixed in an update yesterday. However, the fix only solves the problem for already installed systems. The install media still have these problems. Since opensuse usually does not re-release install isos, it is unlikely that install problems will completely go away.
In this post, I’ll describe what were the problems and how to deal with them on a fresh install.
I’ll describe these problems in terms of the associated bug number.
- bug 950569: with this bug, the computer would seem to lockup during boot, though CTRL-ALT-DEL did work to retry the boot. Disabling secure-boot allowed the system to boot.
- bug 954126: this bug prevented booting Windows in a UEFI box, unless secure-boot was disabled.
- bug 917427: if you installed into an encrypted LVM, and if you did not use a separate unencrypted “/boot”, then the secure-boot method of booting did not work.
Boot files for UEFI
I’ll start by describing what the various files do during booting.