Monthly Archives: November 2020

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, KDE Plasma, X11, Nvidia – stop video and screen tearing

Posted on by

In these times of Corona, home-office and of increased Internet usage some of us Linux guys may experience an old phenomenon: screen and video tearing. In my case it happened with an Nvidia card and with X11 (Wayland does not yet work on my Opensuse Leap 15.1 – I am too lazy to investigate why). I have ignored the tearing already for some months – but now it really annoyed me. I saw tearing already some years ago; at that point in time activating triple buffering helped. But not these days …

Where did I see the tearing?

I observed tearing effects

  • when moving “wobbling windows” (one of KDE’s desktop effects) across the screen – strangely enough when moving them slowly,
  • when watching TV and video streams in browsers (independent of FF, Opera or Chromium) – mostly when major parts of the video changed quickly.

Not much, not always – but enough to find it annoying. So, I invested some time – and got rid of it.

Driver and contents of the xorg.conf file

Driver: Latest Nvidia driver from Opensuse’s NVidia Repository: nvidia-glG05, x11-video-nvidiaG05.

I have three screens attached to my NVidia card (GTX 960); two of them are of the same type, but one has a lower resolution than the others. The screens are configured to work together as a super wide screen via the Xinerama setting in the xorg configuration file. Below, you find the contents of the file “/etc/X11/xorg.conf” with details about the screen configuration and modes.

xorg.conf

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 450.80.02


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2515H"
    HorizSync       30.0 - 113.0
    VertRefresh     56.0 - 86.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 960"
EndSection

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-2"
    Option         "ForceFullCompositionPipeline"  "on"
#    Option         "ForceCompositionPipeline"  "on"
    Option         "metamodes" "DP-4: nvidia-auto-select +0+0, DP-0: nvidia-auto-select +2560+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1920x1080 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1680x1050 +5120+0; DP-4: nvidia-auto-select 
+2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1600x1200 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1440x900 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x1024 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x960 +5120+0"
    Option         "SLI" "Off"
    Option         "TripleBuffer" "True"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

 

The most important statement regarding the suppression of tearing is 

    Option         "ForceFullCompositionPipeline"  "on"

Alternatively, 

    Option         "ForceCompositionPipeline"  "on"

seems to work equally well. Use the latter, if your graphics should react a bit sluggish.

We find more information about these options in the “nvidia-settings” application:

When you move your mouse over the option for “ForceCompositionPipeline” and “ForceFullCompositionPipeline”, you get

The Nvidia driver can use a composition pipeline to apply Xscreen transformations and rotations. “ForceCompositionPipeline” can be used to force the use of this pipeline, even when no transformations or rotations are applied to the screen. This option is implicitly set by ForceFullCompositionPipeline.

and, respectively,

“This option implicitly enables “ForceCompositionPipeline” and additionally makes use of the composition pipeline to apply ViewPortOut scaling.”

Important: If you want to test the setting via nidia-settings, you have to activate the options it for all three screens!.

When I first tested “ForceCompositionPipeline” I just set it on the page of “nvidia-settings” for the first screen of my three, wrongly assuming that this setting was applied in general. However, tearing did not disappear. I realized after some time that it still happened on 2 screens predominantly. I even suspected a different quality of the display-port cables to my screens to be the cause of tearing. Wrong … the ForceCompositionPipeline had been applied to one screen, only.

So, switch to the other screens by using the first combo-box on the “nvidia-settings”-page and set “ForceCompositionPipeline” for all screens. Do this before you eventually save the settings to a “xorg.conf”-file (as root). Your resulting xorg.conf file may look a bit different; the CompositionPipeline-settings might be included as a side-option of the meta-mode settings – and not in form of a special separate line as shown above.

Regarding Xvideo- and OpenGL-settings you should activate syncing;

KDE Plasma settings

KDE Plasma settings for the screens should be consistent with the “nvidia-settings”. You use KDE’s “system-settings” >> “Display and Monitor” >> “Displays” and “Compositor”.

The combination of all the settings discussed above worked in my case – the tearing disappeared for videos in browsers, in video applications as well as on the Xinerama KDE Plasma screen in general.

Conclusion

It is easy to suppress video and screen tearing on an Opensuse Leap system with KDE PLasma and a Nvidia graphics card. The most important point is to activate “ForceCompositionPipeline” on all individual screens via “nvidia-settings” or to activate this option globally for the Xinerama screen of a multi-monitor configuration.