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.
For this month, I installed snapshot 20151218. The install was done on Monday morning.
I had recently replaced the hard drive on my main desktop, so this was a new install to replace what I had installed on the previous drive. I had already created partitions, including an encrypted LVM with space for several root file systems, a swap file system and a home file system. So I wanted to install Tumbleweed into the encrypted LVM.
Up until now, I have avoided “btrfs”, except for a brief trial with a beta release of 13.1. It is about time for more serious testing. So I decided to use “btrfs” for the root file system with this Tumbleweed install. Apparently, “btrfs” works best if “/boot” is part of the root file system. So this meant no separate unencrypted “/boot”.
There have been several problems with UEFI on Leap.
As originally installed, it suffered from bug 950569, where some hardware would hang during boot unless secure-boot was disabled. This bug was originally reported for Tumbleweed, but also showed up in Leap. It was recently fixed in Tumbleweed. And today, an update showed up for Leap to fix this bug. The update also fixed a MokManager problem, which I have not personally experienced.
There’s a problem, though. The updated shim package has been installed. But the updated shim.efi was not installed in the EFI boot settings (normally in “/boot/efi/EFI/opensuse”).
I said there would not be a Tumbleweed install this month. But I changed my mind on that. Snapshot 20151017 came out after I had finished my Leap 42.1-RC1 installs, and I had a little free time.
For this install, I used a 1T disk. It had previously been used for Windows. I plugged the disk into a SATA disk docking station, and planned to use the entire disk for the Tumbleweed install. I connected the docking station to a UEFI computer (via a USB cable).
My plan was to try installing to an encrypted LVM. There are some open bug reports indicating problems, so I wanted to see what would happen.
I saw a Distrowatch announcement of a new release of KaOS, so decided to give it a try. From there, I followed the link to the release announcement.
My previous experience with KaOS was in April, where it failed to install. This time, I had a better experience.
KaOS is a rolling KDE based distro. It is using plasma 5. The new version came with a beta release of plasma 5, so gives me an early look of what I can soon expect to see in opensuse Tumbleweed. The downloaded system uses a release-candidate for Plasma 5.4.
I check the torrent link, but that seemed to be for an earlier release. My understanding is that torrent downloads are provided by users, and I probably looked before they had set it up for the new release.
I’ve been doing an install of the month, in order to test Tumbleweed installation. For August, I installed in an alternate partition on my main desktop system.
The Tumbleweed install media have been broken for the last two weeks. If used from a USB flash drive, the installer cannot be booted in UEFI mode. Apparently it can still be booted with UEFI if it is actually burned to a DVD. However, I prefer to install with a USB, so I decided to give it a try in spite of the problems. I had actually wanted to test whether a UEFI install can be done when the install media is not UEFI bootable. So this was a good time to test that.
I downloaded the install DVD iso for the 20150802 snapshot. As usual, I used “aria2c” to download. That went well. I also used “wget” to download the file containing the sha256 checksum. I verified the gpg signature on that checksum file. Then I compared the checksum in that file with the checksum that I could compute from the downloaded iso. And all was fine.
A week ago, I saw an announcement for Mageia 5, and I decided to take a closer look. My first look at Mandrake linux was around 1999, where I installed it for a brief test. It was later renamed to “Mandriva” to avoid trademark conflicts. And Mageia was forked from Mandriva. Recently, Mandriva appears to have closed down, leaving Mageia as what remains from the earlier Mandrake.
Mandrake was originally based on RedHat linux, but Mandriva later diversified that. And linux has changed a lot since my earlier 1999 test install.
I initially downloaded “Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso”. That was actually an accident. I had intended to download the DVD installer, but did not look closely at the name. I had instead downloaded the live KDE iso. I’ll note that this can be used for installing, though I later downloaded “Mageia-5-x86_64-DVD.iso” and used that for my test install.
[update: please check the comments]
I finally got around to signing a kernel. That went pretty well. So I thought that I would describe what I did.
This post presupposes a little knowledge of digital certificates. If you are looking for a quick introduction, try my post on my other blog.
My test machine has opensuse Tumbleweed. But it also has Mint 17.1 (updated from the Mint 17 that I installed). UEFI booting has been working well with Tumbleweed. But I installed Mint without secure-boot support, so I had to leave secure-boot disabled to boot it.
In more detail, I installed Mint in legacy MBR booting mode, because I did not want to clutter the UEFI name space. That worked fine. I could then UEFI boot it anyway, either with the generated grub menu for Tumbleweed or with a “configfile” command that I added to that menu. But secure-boot did not work, because the installed Mint kernel was not signed by an accepted key (it was not signed at all, it seems).