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).
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.
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.
I don’t often post about Windows, because I mainly use linux. But this is a Windows post. I should mention that the computer involved is a UEFI box, since that might be relevant.
My main desktop has both Windows 8.1 and openSUSE 42.2. On Friday, I attempted to install the May updates for Windows. The updates are the two listed in the subject line above.
The updates failed.
They seemed succeed. I got the message to restart windows to complete the update. So I rebooted. Then I saw the messages about “working with updates”. At around the 30% mark, it rebooted. Then, on reboot, it continued until the 100% mark. That looked good.
But then a message:
We couldn’t complete the updates
Don’t turn off your computer
I have previously reported on KaOS, in 2015. I have actually kept it installed since August 2015. When I saw the announcement for 2017.01, I decided that it was time for a re-install. I’ll note that I could have just updated the already installed version, but it seemed like time for a fresh start.
What is KaOS?
KaOS is a rolling distribution, based on KDE.
I am a KDE user, with openSUSE Leap (currently at 42.2). But I also keep openSUSE Tumbleweed installed for looking at what will be coming up. And I’m using KaOS as an alternative view of what is going to be showing up in the future.
I have not used KaOS extensively, except for occasion testing and occasional updating. I’m expecting to continue that practice with the new install.
I downloaded from the download site listed on the announcement. I then checked the md5sum for the download. There did not appear to be a gpg signature that I could check.
As mentioned in my previous post, here is my separate post on booting Solus.
What’s wrong with the installation defaults for booting?
Probably nothing, at least for most users. But they do not suit my needs.
The main issue, for me, is that I have several linux systems installed. So I don’t want Solus to take control of the booting. I would prefer to have an entry added to my openSUSE boot menu.
Do I even need a bootloader?
You probably do. The grub configuration (as with “grub2-mkconfig” in openSUSE) can find other linux systems and add menu items for them. But that configuration process looks at the boot menus for the other linux systems, to decide how to boot them.
This month’s install was interesting.
My original plan was to install from the KDE live iso. So I downloaded “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20160307-Media.iso” and wrote that to a USB. It booted up nicely, and ran well. Among other things, that suggests that the problems with persistent storage on the usb device have been fixed. It created a hybrid partition that was mounted as “ext4” instead of the “btrfs” that had been giving problems with the persistent hybrid partition.
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.
Some folk like to have more than one linux version installed on a computer. And, possibly, they also have Windows installed. So that’s a multi-boot situation.
I’m doing that. In this post, I’ll describe how I am doing it.
When I first did multi-boot, I was somewhat haphazard in how I organized things. But by now, based on my experience, I’m a bit more organized.
I’ll describe my laptop, and how I am using that. I have Windows 7 installed (that came on the computer when I purchased it). And I currently have opensuse 13.2, opensuse Leap 42.1 and opensuse Tumbleweed all installed.
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.