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.
As mentioned in my previous post, I had wanted to install Debian in a existing encrypted LVM on my hard drive. But I was stymied by a lack of installer support. So I installed on an external drive instead.
It occurred to me that I could just copy the installed system back to where I had originally wanted to install it. So I did. And it worked quite well. In this post, I will describe the steps that I went through.
The first step was to boot into a linux system, but not one of the systems involved in the copying. I could have done this by booting a live system on CD or USB. However, I happened to have Tumbleweed installed in a separate partition on the same computer, so I just booted into that.
This post is prompted by a couple of case where people were having problems:
In both cases, the user had a UEFI capable computer, but wanted to install opensuse to use Legacy booting (also called MBR booting). In both cases, they already had an installed Windows system that used legacy booting. They wanted to install opensuse for legacy booting for better compatibility.
I usually prefer to install for UEFI booting. That’s a better way of booting. But in this case, the users were right that they should install for Legacy booting.
In both of these cases, the user thought that he had configured the BIOS to use legacy booting. However, in both cases, the opensuse install media was booted using UEFI. And that is where things became confused. Read More…
When we boot our computers, what we want to do is load an operating system. Traditionally, we booted devices and it was up to the operating system to work out how to get the system loaded by booting a device. However, UEFI was supposed to change all of that. With UEFI (or Unified Extensible Firmware Interface) the idea is to directly load an operating system without the steps of device booting.
There is, in the UEFI design, a fallback ability to boot devices. This is needed when the operating system is not yet installed, so that booting the install device can set things up. However, this was intended only as a fallback. The main use of UEFI was to be to directly load an operating system.
I have recently posted about a Toshiba system and an HP system, where the manufacturer did not seem to get the message. Both appear to be cases of backward thinking that sticks to the old idea of booting devices rather than operating systems.