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

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 the initramfs for having 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. 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.

 

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – X – Hibernation

In den zurückliegenden Artikeln dieser Serie hatte ich Vorüberlegungen und konkrete Maßnahmen zur Installation eines voll-verschlüsselten Laptops dargestellt:

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VIII – Systemd-Fehler nach Neustart
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IX – Verschlüsselter SWAP

Auf dieser Basis hatten wir zuletzt eine einfache "Opensuse Leap 15"-Variante auf einer externen SSD mit "LUKS on LVM"-Volumes zum Laufen gebracht. Wir können diese Installation bereits in einen Konsolen-Modus booten und Shutdowns durchführen.

Sowohl Grub2 als auch der Kernel fragen uns im Boot-Vorgang erwartungsgemäß nach LUKS-Passphrases für den Zugang zum jeweiligen Master-Key der bislang verschlüsselten zwei Raw-Volumes, die uns quasi als Krypto-Container für das root-Filesystem ["/"-FS] und den SWAP dienen. Wir haben die Volumes aus Gründen der Flexibilität in zwei separaten Volume Groups [VGs] untergebracht; die Passphrases für die Volumes wurden identisch gewählt, um statt 4 nur 2 Eingaben durchführen zu müssen. So weit - so gut.

Der Einsatz eines Laptops ist allerdings auch dadurch geprägt, dass man das System manchmal zügig in einen inaktiven (und stromsparenden) Zustand versetzen muss - ohne dass man dabei den Status laufender Applikationen verlieren will. Ein typisches Beispiel ist etwa das Schließen eines Laptops für einen Raum-, Zug- oder Flugzeug-Wechsel. Unsere Anforderung ist dabei weniger Geschwindigkeit als vielmehr Sicherheit. Dies spricht für Hibernation (s.u.).

Wir wollen in diesem Beitrag deshalb einen ersten Kurztest des Hibernation-Verhaltens unseres Laptops durchführen. Im Zuge dieser Aktivitäten lernen wir leider auch, dass weder das Herunterfahren in den Hibernation-Zustand - noch der Resume-Vorgang unter Leap 15 frei von Fehlermeldungen sind. Dennoch funktioniert Hibernation - zumindest auf meinem System.

Einschränkungen:

  • Ich betrachte hier - wie in den vorhergehenden Artikeln - nur ein klassisches BIOS-System und keine UEFI-basiertes System. Das wirkt sich (je nach Linux-Distribution) u.a. auf die Grub2-Konfiguration aus; u.a. können die Namen der Konfigurationsdateien abweichen. Die dort zu setzenden Kernel-Parameter sind typischerweise aber gleich.
  • Hibernation und ein später folgender Resume-Vorgang aus einem Hibernation Zustand sind relativ komplexe Prozesse. Für eine erfolgreiche Wake-Up-Phase sind initial ggf. auch BIOS- oder UEFI- und ACPI-Funktionen erforderlich. Das BIOS muss den sog. S4-Zustand unterstützen. Sind diese Funktionen nicht standardgerecht implementiert, kann es auf bestimmten Systemen zu Problemen kommen, die ich hier nicht aufgreifen kann. Man muss sich ggf. um ein BIOS-Update bemühen. Die Linux-Kernel-, GRUB- und systemd-Entwickler haben aber versucht, das Thema Hibernation so weit als möglich unter eigene Kontrolle zu bringen.
  • Wir betrachten im Moment nur einen Start/Resume-Vorgang in einen Konsolen-Modus (früher Runlevel 3; heute Multi-User-Target). Diese Einschränkung ist durchaus bedeutsam, da im Falle von grafischen Komponenten Video-Systeme restauriert werden müssen; das ist bei bestimmten Systemen, u.a. Optimus-Systemen, durchaus ein problembehaftetes Thema. Ich komme in einem späteren Artikel darauf zurück.

Weiterlesen

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IX – Verschlüsselter SWAP

Ich setze meinen Ausflug in das Setup eines Opensuse Laptops mit Voll-Verschlüsselung fort:

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VIII – Systemd-Fehler nach Neustart

Die Leser der bisherigen Artikel erinnern sich sicher daran, dass ich während der Installation von Leap 15 auf einem verschlüsselten LUKS-Volume vermieden hatte, ein ebenfalls verschlüsseltes SWAP-Volume einzubinden. Der SWAP wird weder in der Grub2-Konfiguration, noch in der "/etc/fstab" oder der "/etc/crypttab" des Root-Filesystems der Installation referenziert. Wir werden dies nun nachträglich ändern.

Wir schließen unseren Laptop ans LAN an und booten die Leap 15-Installation von unserem verschlüsselten LUKS-Volume "/dev/vga/lva1" (LUKS on LVM) auf der externen SSD. Da wir während der Installation bereits den SSH-Service aktivieren ließen und die lokale Firewall deaktivierten, können wir uns nun bequemerweise von einem externen System einloggen. Wem das nicht möglich ist, muss halt an einem Konsolen-Terminal des Laptops arbeiten. Uns steht im Moment noch kein grafischer Desktop zur Verfügung; Arbeiten auf der Kommandozeile ist notwendig. FS steht nachfolgend wie immer für "Filesystem".

Weiterlesen