Tag Archives: KVM

Upgrade workstation from Opensuse Leap 15.1 to Leap 15.2

Posted on by

Two weeks ago I upgraded my main Linux-Workstation from Leap 15.1 to Leap 15.2. Some first impressions:

  • Leap 15.2 with KDE/X11 works relatively well. Some minor setting-options for the Plasma desktop have changed.
  • KDE/Wayland with Nvidia cards does not work – unusable for production.
  • No problems with QEMU based KVM- and LXC-container virtualization – my old Debian and Kali guest systems worked as expected on the Leap 15.2-host. No problems with multi-screen configurations of the guests with remote-viewer either.
  • Unexpected high power consumption of the Nvidia card – it has increased by about 5% to 8%. I am not sure whether this is a KDE or a driver problem.
  • The usual suspects for problems during the upgrade are the Nvidia drivers, Pulseaudio, VMware and this time – to my big surprise – CUPS.
  • You may have to change/reset some KDE config and rc-files in your home-directory – especially for the plasma desktop itself.
  • Chromium showed some glitches.

I shortly describe the upgrade process and some obstacles I had to overcome.

Basic upgrade process

I always prepare for a quick restoration of my running system configuration (here: Leap 15.1). Ahead of any upgrade activity, I therefore create a backup of my Leap 15.1 “/”-filesystem on an external drive and in addition create another copy in a target partition on one of my bootable disks. I use the “dd“-command for both purposes. As all productive application and development data as mails, project documents, PHP- and Python modules are on independent partitions or on network locations anyway, the risk of running into major problems afterwards is relatively small. In addition I comment certain critical entries in the “/etc/fstab” out.
In case of a major disaster a recovery can be achieved very quickly by just re-copying the copy of the Leap 15.1 partition back to its original place.

Regarding the backup of the “/”-filesystem to an external disk you have the choice between creating a copy of a partition and creating a (zipped) file. See e.g.:
https://www.poftut.com/linux-dd-command-backup-examples/
https://linoxide.com/linux-command/linux-dd-command-create-1gb-file/
I just made simple partition copies. Regarding the blocksize “bs” option of “dd” I am very generous with SSDs; I use a size like bs=1M or bs=4M to get a reasonable performance. When copying around 100 GB you probably do not want to wait for an hour :-). E.g.:

dd if=/dev/sdg1 of=/dev/sdh5 bs=4M status=progress

Warning 1:

If you copy your partition with “/”-filesystem into another partition, then the target partition must at least have the size of the original one. Really take care of this point! I always try to achieve the exact same size with a partition tool (gparted or YaST partitioner).

Warning 2:

Do not forget to change the UUID of the partition’s copy if the target partition resides on an internal disk; you should never have two filesystems with the same UUID on a system! But write down the original UUID at a safe place. Use “uuidgen
” and the “tune2fs -U” commands to change the copied filesystem’s UUID, afterwards.

See: how-to-change-filesystem-uuid-2-same-uuid

And: In case of an emergency restoration, i.e. after having copied the backup filesystem into its old position, you, of course, have to change the UUID back to the old one.

Why are these UUID-precautions required?
Because of your boot-loader – probably Grub2. Depending on its configuration (and some other system settings) it will probably have created entries in the “/boot/grub2/grub.cfg” which refer to the UUIDs of the bootable partitions. And if such a UUID-reference cannot be resolved in a unique way you may in the best case boot a system you did not want to boot, but you may also experience worse conflicts. Now, you may ask:

What is the copy on the same or another internal hard disk good for anyway?
I create the copy on my main SSD (or another internal disk) not only for restoration purposes, but also for the purpose of transforming it into a fully bootable filesystem at its new position later on – i.e. after the upgrade. I shall return this point in an extra section below.

Upgrade process

After the backup procedures I followed the guideline of the Brasilian Linux Kamarada for the upgrade; see
https://kamarada.github.io/en/2020/09/01/linux-kamarada-and-opensuse-leap-how-to-upgrade-from-151-to-152

Their way of upgrading Opnesuse systems is straight-forward and well-tested. I also liked their recent inclusion of the “releasever“-variable …

I tend to use multiple repositories besides the standard upgrade repository of Opensuse. Therefore, I had to delete quite an amount of repositories following the Kamarada recipe. If you are in the same position, you should make a screenshot of the repository-configuration in YaST to be able to reconfigure them after the upgrade. During the upgrade zypper may recognize many packages for which it has to change the repository. It is a bit of an ordeal to answer to all of the related questions, but I recommend to follow the questions with focused concentration: The order of offered alternatives may change!

Hint: Take care of sufficient filesystem-space! The download of new packages requires extra space during the upgrade period – and usually also the total size of used disk space after an upgrade typically tends to grow somewhat. Therefore: Have at least 20GB available on your “/”-filesystem. (LVM is your friend – if you use(d) it …).

After the upgrade you have to reboot (init 6). If your graphics card is from Nvidia you probably will find yourself on some console terminal and not at a desktop-manager-login (e.g. sddm or gdm3) at the end of the boot process. We must install the (new) Nvidia drivers afterwards.

Nvidia re-setup

There are at least two ways of installing Nvidia-drivers on an Opensuse-system: 1) Directly, i.e. by a manual installation with the help of of the downloaded driver installation scripts. 2) With the help of YaST and the Nvidia community repository. I have used the latter option during the last 2 years. Either way you probably prohibited loading the Opensource Nouveau driver already at some point in the past – e.g. by blacklisting the related kernel module in some of the files in “/etc/modprobe.d”. If not – it is time to do so now.

When you rebooted after the Leap 15.2 upgrade the old Nvidia modules did not work as they were not compiled for the new kernel which was installed during the upgrade. So, from the console login, which you hopefully have reached, you need to invoke YaST in ASCII-mode, activate the
Nvidia community repository and reinstall the proprietary Nvidia drivers from there. In my case the packages

nvidia-computeG05, nvidia-gfxG05-kmp-default, nvidia-glG05, x11-video-nvidiaG05

A compilation is done automatically during this update.
Hint: I also suggest to issue “mkinitrd” immediately after the driver installation to be on the safe side regarding the “initramfs”-phase of the boot-process.
This worked pretty well in may case. After a reboot I got to my SDDM-login screen afterwards. My standard X11-based graphical KDE Plasma desktop started smoothly afterwards. I also tested the functionality of my Cuda installation for Keras and Tensorflow2 – worked perfectly.

Increased idle power consumption of the graphics card on a running KDE plasma desktop (Version 5.18)
A unwelcome surprise regarding Nvidia was the following: When watching the power consumption of my graphics card with

watch -n0.1 nvidia-smi

I saw a rise in the average consumption.
An average value of the GPU load (with “Force Composition Pipeline” activated on all my 3 screens) now had a value of 15%; on my old Leap 15.1 it was below 10%. All with having set the Powermizer mode to “Adaptive” (via (nvidia-settings). I fiddled a bit around with some Nvidia settings – but found no real solution, yet. When I changed a desktop theme (with the help of “systemsettings5”) I observed a drop of power consumption to 11% – but after some movement of windows across my 3 screens it settles again at 15% – quite independent of style and desktop settings. At least with an OpenGL-compositor activated (systemsettings5 >> “screen … >> compositor”. Choosing “Xrender” leads to a drop of GPU-consumption to 9%.

What brought me down a bit to 12% with an activated OpenGL-compositor (OpenGL2 or OpenGL3.1) was to deactivate keeping window-previews:

I did not experience any real disadvantages by doing so. On Leap 15.1 the average consumption with a driver a bit older was still lower by 4% to 5%. We talk about 2 Watt here, but still I do not like such unexpected changes. I do not know whose fault this is – KDE’s or Nvidia’s. We shall see what happens with the next driver version ….

Reconfigure KDE settings

The screen order on my Plasma 5.18 desktop was OK. No screen-tearing (see: Opensuse, KDE Plasma, X11, Nvidia – stop video and screen tearing); my old “xorg.conf“-settings were respected and active.

However, when trying to change design- and plasma-style-settings via “systemsettings5” a click on the “plasma-style”-icon led to a window crash and a Plasma error. This is usually a sign that something is wrong with the KDE configuration files:

Because the KDE setting- and configuration files in the home-directory survive the upgrade untouched some may not be compatible with the new KDE version.

I do not know about an easy way to find out which of the files are to be recreated. My standard way is to make a copy of the “~/.config-directory (with a new suitable name), delete the original directory, wait until it is automatically created again (with new default settings). We
make a copy of this new default-“.config” version (with a unique name), too, and then copy the original version into its standard place again. In the end we have 3 “.config”- directories with different names – one in place with the user’s original settings, one with the new default settings and one with the original settings as “.config”.
Then I overwrite files in the “.config”-file with the new default files, at least those for which I suspect some problems – starting with the plasma-specific “plasma…..rc”-files, then the “systemsettingrc”, then “kwinrc”. Thus, the problems with “plasma-style”-settings could be resolved quickly.

I also got some problems with a standard activation of the OpenGL-compositor at the start of the plasma desktop. A change of the respective settings in the “kwinrc”-file helped – especially “Enabled=True”: 

[Compositing]
AnimationSpeed[$d]
Backend=OpenGL
Enabled=true
GLCore=true
GLPreferBufferSwap=a
GLTextureFilter=1
HiddenPreviews=4
OpenGLIsUnsafe=false
WindowsBlockCompositing=false
XRenderSmoothScale=false

Pulseaudio [PA]

A major frustration came up when I tried to start Clementine and listen to some songs – all my PA-settings were gone with the exception of the PA-LADSPA-equalizer. This had partially to do with changes in the Phonon-settings – now to be found under “systemsettings5 >> Audio“. I had to turn off my onboard HD sound card, activate my mainly used Xonar D2X explicitly and also deactivate an existing XFI-Card, too.

The dialog for setting the KDE/Phonon “standard device” have changed once again :-(. You cannot choose priorities for different sources (audio, video, …) any longer. Simplification? I hate this new KDE politics of taking more and more configuration options away from the standard user. I had to make the equalizer the “standard device” in the new dialog to direct all streams (from browsers and players) through this device.

Compare this to the settings in Leap 15.1; see KDE, Pulseaudio and Browsers – make the LADSPA equalizer the default sink.
In addition: We cannot play test sounds for the various sinks any more. This does no longer work in “YaST Audio” either … I do not call such things progress.

With PA activated “pavucontrol” serves as my primary mixer. It worked more or less as expected though some functionality has been removed there, too. E.g. the ability to remove some input channels completely. Another stupid thing which happens now regarding the default channel for volume adjustment via kmix is now that you may choose “Simultaneous output ….” – but volume controls will affect the Xonar channels, too – at least as long as no device uses the equalizer ….

It took some fiddling until I got back most of my old functionality and sound quality. I found again that its worth to reduce the Clementine input in pavucontrol down to 80% to avoid some oversteering and sound-distortion. Do not forget to set the default channel for sound control with kmix to “Simultaneous output …” for your multi-channel soundcard!

One can in addition install and activate the XFCE-mixer, which basically is a graphical frontend to an alsa mixer. This allows additional shifts of the different channels against each other – performed after pulseaudio’s own mixer settings, namely those of “pavucontrol”.

A major problem with sound and the onboard card:
For some reason a switch from the graphical terminal to a console terminal (by “Ctrl Alt F3”) automatically
activates an Nvidia HDMI stereo device on my system now. It comes up again even if I explicitly deactivated it in the KDE or PA audio settings. I have no solution for this, yet. It affects, however, at least a running Chromium (see below) – and leads to a restart of desktop effects when I return to the graphical session. I get a corresponding explicit message from Plasma ….

VMware – a yearly game of money …

VMware Workstation 15.5 Pro does not work on a Leap 15.2 host without special prerequisites. See e.g.:
https://forums.opensuse.org/showthread.php/540779-vmware-worksation-pro-15-5-not-failed
https://www.opensuse-forum.de/thread/63542-vmware-workstation-pro-leap-15-2b/?pageNo=1
https://communities.vmware.com/t5/VMware-Workstation-Pro/Can-t-compile-wmware-workstation-15-5-on-leap-15-2/m-p/2286237

However, WS Pro 16.0 does. I upgraded to this version. My Win 10 guests felt a bit more sluggish than with WS 15.5. But this may also have to do with a subsequent Upgrade of Win 10 to the 2004 version.

By the way: Note that VMware wants you to pay extra maintenance support, if you order it from SW resellers – at least here in Germany. The cheapest choice was to order it directly from the VMware shop. Do we like such anti-competition monopoly and customer control measures? No, we do not like it => time to get Windows 10 guests running on KVM machines … and to forget VMware for the future. See:
https://getlabsdone.com/10-easy-steps-to-install-windows-10-on-linux-kvm/#Customizing-the-Hardware-for-Windows-10

Hint: Be a bit reluctant with changing the HW compatibility of your VMware virtual machine for two reasons: You may want the virtual image to continue running in your old 15.1 implementation, too – until you feel that Leap 15.2 is stable enough. Second reason: Changing too much of HW settings may lead to a reactivation of your Windows license key.

CUPS bug – reconfigure printers – use the CUPS packages from the printing repository

I have two printers in my network. They can be addressed both by a local configuration and via a cups server in the net, which offers a variety of queues.
The reconfiguration of the local settings were a piece of cake with YaST. The updated HP-drivers simply worked.
However, printing from my system via a CUPS server in the net and its queues did not work any more. In contrast to all previous upgrades of at least the last 4 years :-(.
It took me a while to find out that this is due to a major bug in the present CUPS version delivered by the standard Update repository of Opensuse. Use the CUPS version > 2.3.0 from the “Printing repository“.
Then your server based queues will work again!

Chromium: Problems with HW acceleration / sound from Chromium does not get upmixed on a multichannel sound card

I had some problems with Chromium. Maybe I had them already before, but I noticed them now:
I had to refrain from HW-acceleration: Whenever I changed to one of the console terminals (e.g. Ctrl-Alt-F2) and returned to the graphical terminal the Chromium user interface got totally destroyed. Not funny when you were editing a blog :-(.
In addition: Chromium sound does not get upmixed completely – the probable reason is that Chromium supports real 7.1 channel sound these days. So, stereo may remain stereo or only gets upmixed by some special soundcard setting to 4.0, 6.0 – but not by PA. Despite such
settings on my Xonar card, I had some disturbing experiences: When changing to a console terminal and back to the graphical one, the upmixing changed from 4.0 to 2.0 …. :-(. When I rebooted afterwards, the 4.0 upmixing was there again. The whole effect probably was due to an automatic activation of some onboard/oncard Nvidia HDMI sound channels during the switch to the console terminals.

Firefox sound, however, which sends a pure stereo signal to the system as, gets properly upmixed by PA to 7.1 sound and this remains stable during switches between console and graphical terminals. So, for the time being, I do not use chromium for TV streaming any longer. Maybe the Chromium developers should have a talk with the PA developer …. It seems to be a difficult problem to me – you would have to analyze that only stereo sound is coming despite a 8 channel signal. A simple workaround would be that we get a switch in the chromium browser which allows to set its operation from multichannel to stereo, only.

For those who like to experiment with “pactl” commands (like “pactl list sinks” as standard user) I would like to draw your attention to work others ave done regarding PA and upmixing:
https://gist.github.com/dex4er/8646669
https://bbs.archlinux.de/viewtopic.php?id=16093

It should be possible to write two scripts one activating a certain upmixing with pactl commands and one deactivating it again. But my time is so limited that I haven’t tried it myself, yet.

KDE Plasma, Nvidia and Wayland do not work

As with Leap 15.1, KDE and Wayland lead to a direct crash on my workstation with Nividia graphics. The system freezes. You have to enforce a reset of your PC and start a reboot. However, on a laptop with a i915 Intel driver for a CPU integrated graphics Wayland works. So, we have a clear Nvidia topic here.

After the upgrade: Make the copy of our original partition of Leap 15.1 a bootable one

If you had copied your original Leap 15.1 partition into another partition on your hard disk you may want to make it a bootable fully functional system offered as an entry in the Grub2 menu. This requires some additional efforts.

Firstly, you have to change all references to the modified UUID in the internal boot-relevant files of the moved filesystem – i.e. in the “/etc/fstab”  AND  in the “/boot/grub2/grub.cfg” there on the Leap 15.1-partition. For this purpose you must mount the copied Leap 15.1 partition on your running Leap 15.2 system and edit the entries in both files of the mounted Leap 15.1 filesystem very carefully with respect to the changed UUID (see the sections on backups above). Take care that you do not change the files on the running Leap 15.2 system. And, please, make copies of both files before you change them! You may need the original contents.

Instead ofchnaging entries in the “/boot/grub2/grub.cfg” of the Leap 15.1 copy you can also rename the “/boot/grub2/grub.conf” on the Leap 15.1 partition to something like “grub.conf_orig” (you want to keep the contents!). This gives the grub “os-prober” on you Leap 15.2 installation a chance to create correct entries regarding the address of the partition.

Then we remove the “/boot/grub2/grub.cfg” in the Leap 15.2 installation and run “grub2-mkconfig -o /boot/grub2/grub.cfg” again to give the os-prober there a chance to create valid entries. Please, cou check these entries first before you install the grub loader from your running Leap 15.2 again! If you find correct UUID or other references to the partition the you can reinstall the bootloader. I always do this with YaST. Afterwards you should be able to boot both your new Leap 15.2 and your old 15.1 installation a respective entries in the Grub2 menu. Thus we have our old Leap 15.1
installation available for comparisons.

Conclusion

An upgrade of a Linux workstation from Opensuse Leap 15.1 to Leap 15.2 brought no major problems with it. One remarkable exception is a bug in the CUPS package – for which you find a solution in form of a newer package in another Suse repository. The fact that Wayland does not work with KDE on Nvidia graphics came not unexpected – although I think its a shame for Nvidia. The same could be said about the increased power consumption of the Nvidia card.

Have fun with Leap 15.2.

Long boot time of Kali Linux after swap partition changes – swap settings for the initramfs

Posted on by

Recently, I reactivated an old KVM-based installation of Kali Linux from 2018. So, some hurdles to upgrade the Kali distribution to version 2020.4 had to be overcome. Actually, it was a mess. I had to solve multiple circle like problems with package dependencies (Python3, Ruby, special packages in the Discovery section, …). Sometimes I had to delete packages explicitly. The new Kali minimum installation and its enhancement via meta-packages contributed to the problems. In the end I also reinstalled a the Gnome desktop environment – supplemented by a few KDE applications. Now, my Kali was fully functional again. However, the remaining disk space had shrunk …

Resizing the qcow2-file for the virtual disk of the virtual machine for Kali Linux

During all the back and forth with installing meta-packages I came close to exhausting virtual disk space, before I could clean up and remove packages again (with “apt-get autoclean” and “apt-get autoremove”). The virtual hard disk was a qcow2-file in my case. For further experiments I had to expand its capacity. This could easily be done by

qemu-img resize PATH_TO_qcow2_FILE +NG

where I had to chose a suitable “N” (20). The extended file must, of course, still fit into its filesystem on the KVM host!

Extending and rearranging partitions within the Kali system

The more difficult part in my case was the rearrangement of the two partitions ( one for the “/”-fs and one for swap) on the virtual disk for my Kali guest system. I did this within the running Kali system. Bad habit; such operations are dangerous, of course, but I trusted in the abilities of gparted. An extension of a mounted “ext4”-formatted partition is in my experience no major problem as long as there is enough free space behind its current location …. But, I recommend, of course, to make a backups of your virtual machine, before you start with any potentially dangerous operations regarding the file-systems of your Linux machines.

As my old Kali installation unfortunately did not have a LVM-layout and the disk partition table was of the old MS-DOS type, I actually had to move a blocking swap partition which was located directly after the “/”-partition. Meaning: I had to delete and later recreate it at a different position. Of course, after having disabled the swap in the running Kali guest :-). The partition keeping the “/”-filesystem (ext4) could then be extended without any problems on the running system. The new swap partition afterwards got its place behind the “/”-partition. According to “gparted” everything was OK after the partition changes: Then I rebooted…

The problem: A boot time of almost 30 secs …

The next restart took about 28 secs! But the machine came up in the end – which is almost a wonder, after I understood the cause of the problem. A standard boot-process until login normally required about 4 secs, only, before my filesystem changes. A major discrepancy and a clear indications of a major problem! Looking at the “dmesg”-output I got the impression that the delay had to do with operations occurring at the very beginning of the boot process. So, I checked the “/etc/fstab”. And got a first glimpse of the cause: The entries there referred to the UUIDs of the partitions! Not unexpectedly – this is the standard these days for almost all major distributions.

So, stupid me: Of course, the UUID of the swap partition had changed during the mentioned operations! I adapted it to the new value (which I got from gparted). I also checked whether there was
any reference to the swap-partition in the Grub command line (check “/etc/default/grub” for a “resume”-parameter!) To be on the safe side I also checked the result of “update-grub” in the file “/boot/grub/grub.cfg”). I did not find any references there. So, I gladly restarted my Kali system. However, the problem had not disappeared … .

Solution: The initramfs-configuration includes an explicit setting for the swap-partition!

Now, at this point there were not many options left. I started suspecting that the initramfs had a wrong entry. Now, where do we find options regarding the swap for the initramfs on a Debian based systems? A bit of duckduckgoing pointed me to the file

/etc/initramfs-tools/conf.d/resume

And there I did find an entry like

RESUME=UUID=d222524c-5add-2fcf-82dd-4d1b7e528d0c

OK – I changed it to the new value. Then I used

update-initramfs -u

to update the initramfs. And, guess what: The problem disappeared! I got my 4 secs of boot time again.

Conclusion

Never forget to check the UUID-settings for partitions after major changes of the filesystem-layout on your disks. Do the necessary checks not only on real host systems, but also on virtualized systems. Check both the “/etc/fstab” AND the Grub2-configuration AND the initramfs-configuration for possible references to changed or moved partitions.

Off topic – but related: When copying the contents of a partition with “dd” into another partition on your hard disk, e.g. for a backup, you should also care about the fact that you have two partitions with the same UUID afterwards. This may lead to major problems for any active Grub2. Always change the UUID of the copied partition with tune2fs before any reboots. If the copied partition was a bootable one, you also take care of its “/etc/fstab”-entries and initramfs settings, if you want it to be bootable in its new place.

General warning: Whenever you move/copy partitions, write down and save the original UUIDs – you may need them in case of trouble.

 

Opensuse Leap, KVM/QEMU-guests, KMS – problems with QXL/Spice after upgrade to Leap 15

Posted on by

Many services in my LAN are provided by virtual KVM/QEMU-guests of a dedicated KVM-server-host. More special services are provided by local KVM-guests on Workstations. All my virtualized systems get normally equipped with a qxl/spice-combination to provide a graphical interface – which can be used on the KVM-host or by remote spice clients. A direct graphical access via a spice client is required only seldomly (besides ssh connections) – but in some cases or situations it is useful, if not mandatory.

Recently, I upgraded both the central KVM-Server, its guests and also guests on workstations from Opensuse Leap 42.3 to Leap 15.0. Unfortunately, after the upgrade no graphical access was possible any longer to my guest-systems via spice-clients (as virt-viewer or the graphical spice-console of virt-manager).

After some tests I found out that this was due to missing KMS on the guest systems – present qxl-modules, however, do require KMS. But, if you update/install from an ISO image “KMS” may not be compatible with the graphical SuSE installer. And due to previous configurations “nomodeset” may be a kernel parameter used in the installation before the upgrade. Here is the story …

The problem: Unreadable, freezing interfaces on spice-clients

Normally, I upgrade by a 5-step sequence: 1) Update all packets, 2) reduce repositories to the Update- and OSS-repository, 3) switch to the repositories of the new distribution, 4) “zypper dup –download-only”, 5) “zypper –no-refresh dup” (see e.g. how-to-upgrade-from-opensuse-leap-422-to-423/).

The KVM server-host itself gave me no major problem during its upgrade. Also the KVM-guests – with their server-services – seemed to work well. Most often, I access the KVM-guest-systems via ssh to perform regular administration tasks. So, I did not even notice for a while that something was wrong with the qxl/spice-configuration. But when I used “virt-manager” in an “ssh -X” session from my workstation to the KVM-server and tried to open the graphical console for a guest there, I got an unreadable virtual screen, which froze instantly and did no longer react to any input – special commands sent via “virt-manager” to switch to a non-graphical console terminal were ignored. The same happened with “virt-viewer” and/or when I executed virt-manager directly on the graphical screen of the KVM-server.

Independent test with a new installation of a “Leap 15”-guest-system

To find out more I tested a new installation of Leap 15 on my Leap 15 workstation as a KVM-server. I chose a guest system configuration with standard equipment – among other things qxl/spice-components. The installation was started via the “virt-installer” component of virt-manager. I used an ISO-image of the Leap 15 installation image.

First thing I stumbled across was that I had to use a “No KMS” for the text console setting on the first screen of the Opensuse installer (see the options for the graphical setup there; F3-key). Otherwise the installer froze during the first “udev” checks. I knew this effect already from installations on some physical systems. Note that the choice of “No KMS” leads to an kernel parameter entry “nomodeset” in the command line for the kernel call in the Grub2 configuration (see the file /etc/default/grub).

Such a full new installation lead into a void. SuSE’s graphical installer itself worked perfectly with high resolution. However, after a restart of the freshly installed guest-system the switch to the graphical screen lead to a flickering virtual screen and the graphical display of the SDDM login manager never appeared.

Still and luckily, it was possible to login as root and execute a “init 3” command – which brought me to a working, non-flickering ASCII console interface (TTY1).

I had experienced this
type of behavior before, too, on some real physical systems. I recommend Leap users to be prepared: activate ssh-services during installation and open the firewall for ssh-ports! The SuSE-installer allows for such settings on its summary screen for the installation configuration. This gives you a chance to switch to a working text console (init 3) from a remote SSH-command line – if the graphical console does not allow for any input.

Tests 2: Upgrade to latest KVM / QEMU / libvirt – versions of the “Virtualization” repository

An installation of the cutting edge versions of KVM/QEMU and spice sever and client software did not change anything – neither on my dedicated KVM-server-system and its upgraded guests nor on my workstation with the fresh Leap 15 test-guest.

Repair of the older upgraded guest-systems

The emulated “hardware” of my older (upgraded) guest-systems, which stem from an OS 13.2 era, is a bit different from the equipment of the newest test guest. On these older systems I still had the choice to use a cirrus, vga or vmwvga graphics. Interestingly, these drivers do not provide the performance of qxl – but they worked at least with the virtual spice client displays.

One central question was whether the QXL driver – more precisely the corresponding kernel module “qxl” – was loaded at all. Answer for the guests on the central KVM-server: No, it was not.

So, on the first guest I simply tried “modprobe qxl” – and hey – the module loaded. An “init 5” then gave me the aspired graphical screen.

Later I checked that actually no “nomodeset” parameter was set in these guests. So, something went “wrong” with the system’s startup-configuration during the upgrade procedure. I have no real clue why – as the qxl-module was loaded without problems on the previous Leap 42.3 installations.

For Opensuse Leap the wrapper-script “mkinitrd” transfers a running configuration with its loaded kernel modules via “dracut” into a suitable and permanent initramfs/initrd- and systemd-startup configuration. So, issue “mkinitrd” after a successful test of a qxl/spice-interface.

Repair of the freshly installed Leap 15 guest-system

On the freshly installed Leap 15 guest client on my workstation things were slightly different: The qxl-module did not load there. A “modinfo qxl” shows you parameters you can apply. The right thing to do there was to try

modprobe qxl modeset=1

This worked! Then I eliminated the “nomodeset”-parameter from the “GRUB_CMDLINE_LINUX_DEFAULT”-entry in the file “/etc/default/grub” and started “mkinitrd” to get a stable permanent startup-configuration (via dracut) which booted the guest into graphical mode afterwards.

Adjustment of the TTYs and KDE

As soon as you have a reasonable configuration, you may want to adjust the screen dimensions of the text consoles tty1 to tty6, the sddm-login-screen and the KDE or Gnome screen. These are topics for separate articles. See, however, previous articles in this blog on KVM guests for some hints.

For the text console TTYs try reasonable settings for the following entries in the “/etc/default/grub” – below e.g. for a resolution of “1680×1050”:

GRUB_CMDLINE_LINUX_DEFAULT=” …. OTHER PARAMETERS …… video=1680×1050″
GRUB_GFXMODE=”1680×1050″
GRUB_GFXPAYLOAD=keep

(see https://www.suse.com/de-de/support/kb/doc/?id=7017979)

Do not forget to execute “mkinitrd” again afterwards!

For KDE adjustments a user can use the command “systemsettings5” and then specify screen resolutions in the dialog for “display and monitors”.

Conclusion

The graphical installer of Opensuse, but also upgrade-procedures on working virtual KVM/QEMU guests with qxl/spice can lead to situations where KMS is or
must be deactivated both for physical and virtual systems. As a consequence the “qxl-module” may not be loadable automatically afterwards. This can lead to failures during the start of a graphical qxl/spice-interface for local and remote spice-clients.

The remedy is to remove any “nomodeset”-parameter which may be a part of the entry for “GRUB_CMDLINE_LINUX_DEFAULT” in the file “/etc/default/grub”.

For tests of the qxl-driver try loading the qxl-module with “modprobe qxl modeset=1”. After a successful start of a graphical interface use the command “mkinitrd” (whilst the qxl-module is loaded!) to establish a permanent configuration which loads “qxl” during system start.