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.
For this month, I decided to install the 20150903 Tumbleweed snapshot. I planned to install on an external drive, and to install only KDE (i.e. Plasma 5).
This install turned out to be a disaster. But that’s why I do these monthly installs. I have reported the problems as bug 944662.
The downloading went well. I used “aria2c” to download “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso”. And I used “wget” to download the checksum file “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150903-Media.iso.sha256”. I then used “gpg” to verify the signature on the checksum file. And I used “sha256sum” to compare the checksum of the downloaded iso with that in the checksum file. All went well.
The expression “generic boot code” simply refers to boot code that is not specific to a particular operating system.
Newer computers are moving toward UEFI booting, but there are still many computers that use BIOS based MBR booting. And I still have some of those computers. Booting of such a computer starts with boot code in the MBR (or main boot record). And typically, that is generic boot code.
First a quick rundown on how MBR booting typically works.
The MBR is the first physical sector on the hard drive. When you power on the computer, the BIOS loads that sector into memory at a standard location, and then jumps to that memory location (starts running instructions from there). Normally a properly initialized MBR will have 0xaa55 as the last 16 bits (that’s hexadecimal). This is a boot flag and indicates that the disk is bootable. The BIOS usually checks for this flag before it jumps to the boot code that it has loaded from the MBR.
I have been doing monthly installs of Tumbleweed, mainly to test out the installer. For June, I installed the 20150608 snapshot. I used the DVD installer (written to a USB), and this was for the 64-bit version.
Short “tl;dr” version — the install went pretty well, with only one minor problem.
As usual, I used “aria2c” to download the file “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150608-Media.iso”. In addition, I used “wget” to download “openSUSE-Tumbleweed-DVD-x86_64-Snapshot20150602-Media.iso.sha256”. This is a small file which contains the sha256 checksum for the iso. I used “gpg –verify” to check the digital signature on that “.sha256” file. I then compared the listed checksum of the iso with the one that I computed using the “sha256sum” command. Everything checked as okay.
In this post, I’ll describe what I do when I want two versions of linux. Typically, one is for normal use and the other is for testing. I noticed some confusion about how to do this in a recent thread at opensuse forums. So I thought it might be of interest to describe what I am doing.
This is intended for information only. Of course there are many different ways of handling this. I am describing just one of them.
The particular computer is an older one that uses legacy (MBR) booting. It was my main desktop, until around two years ago. Now I mainly use it for testing and as a backup in case my main desktop fails.
I currently have both opensuse 13.1 and opensuse 13.2 installed. I also have another partition for test installs. Opensuse 13.2 is a 64-bit install, while opensuse 13.1 is a 32-bit install (actually the “linux for education” version. Read More…
When support for legacy grub (or grub1) was dropped for opensuse 13.2, one of the reasons was to make it easier to support encryption without a separate unencrypted “/boot” partition. Recent releases of grub2 have some support for accessing encrypted file systems, so it was mostly a matter of adding support to the installer.
I decided to test how that works. So I did a test install of opensuse 13.2 into an encrypted LVM, without a separate “/boot”. The Yast installer was happy with that. It did not complain that there was no “/boot”. So I continued through the full install.
There were no install errors reported. But it didn’t work. Instead, while booting, I got a grub shell. And the grub shell did not offer any commands related to crypto.
I am planning to do a clean install of Tumbleweed every month. This will usually be a throwaway install. That is, I won’t be intending to keep the installed system. Rather, I am trying out the installer and I will report any bugs that I might find. I’m doing this because Tumbleweed is, in effect, a preview of the next mainline release (opensuse 13.3).
On this occasion, my install was to my laptop. I actually installed to an external 80G hard drive connected to the laptop.
The quick summary is that install mostly went well. I went with defaults for many options, so that the install resulted in the KDE desktop. The main surprise was to notice that the default MTA (mail transfer agent) is now “exim” rather than “postfix”. Read More…
The news from the Windows front has been that there is a new update to Windows 8.1, which is supposed to cure all of the failings of Windows 8/Windows 8.1. From the reports that I have seen, many folk are disappointed. Apparently, the update doesn’t provide what they had been hoping for.
Apart from the disappointment, it does seem that this is a required update. Future updates to Windows 8.1 are expected to build on this update.
So I went ahead and installed the update. Or, at least, I attempted to install the update. It’s a large update, with something like a 750M download. There were several other updates in this weeks collection, so I told Windows to install them all.
One of my computers was having problems. I might try replacing the disk drive and see if that helps. However, it is an older computer, so I decided that I needed a replacement.
I looked at several sites, including Dell and HP. I also looked at Amazon. One of the computers that showed up in the Amazon listing of desktops, was the Lenovo ThinkServer TS140. And it looked interesting, and reasonably priced. The Amazon reviews were mostly quite good. After a few days to think about it, I decided to go with the ThinkServer.
Release candidate 2 was made available yesterday. As you might expect, I have already downloaded it and attempted a couple of installs.
This seems to correct most of the problems with earlier pre-release versions. The installed system is running kernel 3.11.3. KDE is at version 4.11.2 and Gnome is at version 3.10.1. The release will have code name “Bottle”, and is expected to be an LTS release. That is to say, after the normal end of support, it will go to evergreen extended support. Read More…