Beowulf und Buster

Buster in die Tonne zu treten, war etwas voreilig. Der Kerneloops kommt auch bei Beowulf vor und deswegen habe ich mir das nochmal angeschaut.

Jeder Kernel der LiveCDs hat anscheinend unterschiedliche Bootparameter. Da gibt es wohl keine Standards. Unter Ubuntu liegt der Kernel in /casper  unter MX-Linux in /antiX und bei Debian und Devuan in /live – das aber alleine langt als Wissen nicht. MX-Linux ist bisher der schwerste Brocken, dessen Bootscripte suchen nach Devices eine Isodatei ist halt kein klassisches Gerät wie /dev/sr0 usf. ich habe noch nicht rausgefunden wie ich dem vmlinuz von MX-Linux beibringe auf loop zu suchen.

Ubuntu 16.04 sieht zum Beispiel so aus:

 linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile noprompt noeject locale=de_DE bootkbd=de console-setup/layoutcode=de

Ubuntu 18.04 dann so:

linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject locale=de_DE bootkbd=de console-setup/layoutcode=de
initrd (loop)/casper/initrd.lz

Und Ubuntu 20.04 wieder anders:

linux (loop)/casper/vmlinuz iso-scan/filename=$isofile file=/cdrom/preseed/ubuntu.seed boot=casper locale=de_DE bootkbd=de console-setup/layoutcode=de quiet splash ---
initrd (loop)/casper/initrd

Die Variablen set root und set isofile sind eigentlich bei allen Distributionen gleich.  Wenn das Isofile auf der ersten Festplatte der ersten  Partition liegt, dann wäre es

set root='hd0,msdos1'

Ich lege mir die zu testen LiveCDs aber immer auf die zweite Partition msdos2, da ich später das System auf die erste Partition installieren will. Die zweite Partition ist auch mein /home wo meine Daten liegen und die will ich auch bei Neuinstallation behalten. Ausserdem hat sich das bei Ubuntu bisher bewährt, dass ich damit nicht immer wieder alles neu einrichten muss und ein Rettungssystem immer im Grub zur Verfügung habe.

Nun musste ich feststellen, dass zwischen den Distribution nicht nur das Verzeichnis anders ist, sondern die Kernelbootparameter nicht übertragbar sind. Bei Devuan Beowulf funktioniert folgendes:

set root='hd0,msdos2'
set isofile="/devuan_beowulf_3.0.0_beta3_amd64_desktop-live.iso"
set cmdline="locales=de_DE.UTF-8 keyboard-layouts=de timezone=Europe/Berlin"
loopback loop $isofile
linux (loop)/live/vmlinuz boot=live config findiso=$isofile $cmdline username=devuan apparmor=0 
initrd (loop)/live/initrd.img

funktioniert unter MX-Linux leider nicht

keyboard-layouts=de 

verursacht einen Kerneloops, aber so kommt es, dass Buster nochmal eine Chance bekommen hat. Momentan schreibe ich unter Buster, weil mir das XFCE in der Konfiguration von Devuan nicht gefallen hat. Es wird sich sichelich einstellen lassen, dass das Touchpad auf Tippen reagiert, aber ich habe die Einstellung unter Devuan nicht gefunden. Buster hingegen hat zwar diese Einstellung auch, dass Tippen standardmässig ausgeschaltet ist, aber in der Oberfläche ist es dem Ubuntu sehr ähnlich und Einstellung Touchpad hat mir das wiedergegeben. In der grub.cfg für Debian Buster sieht dass dann so aus:

set root='hd0,msdos2' 
set isofile="/installdebian.iso"
set cmdline="locales=de_DE.UTF-8 keyboard-layouts=de timezone=Europe/Berlin"
loopback loop (hd0,msdos2)/$isofile
linux (loop)/live/vmlinuz-4.19.0-8-amd64 boot=live config findiso=$isofile $cmdline 
initrd (loop)/live/initrd.img-4.19.0-8-amd64

Ecryptfs kommt aus der Mode. Moniert wird bei dieser Festplattenverschlüsselung, dass es nicht ganz sicher ist. Das stimmt in gewisser Hinsicht. Für mich ist es aber kein Bug sondern eher ein Feature. Moniert wird, dass wenn sich ein Nutzer einmal mit seinem Passwort eingeloggt hat und sein /home entschlüsselt ist, dass dann das Verzeichnis entschlüsselt ist und zwar auch dann, wenn er sich wieder auslogt. Dieses Ausloggen kann zum Beispiel passieren wenn man Strg+Alt+Tab macht und den Xserver abschiesst, weil das System aus welchen gründen auch immer zuviel swapt, weil man Blödsinn angestellt hat, und das eine gute Möglichkeit ist, den wildgewordenen Prozess gewaltsam zu beenden. In diesem Moment ist das Verzeichnis dann immer noch unverschlüsselt und mit physischen Zugriff lesbar. Das kann man als Sicherheitslücke einer ordentlichen Verschlüsselung betrachten. Ja es ist nicht so sicher wie eine Verschlüsselung auf Geräteebene. Man könnte auch sagen, es ist broken bei Desigen, weil es nur eine Dateiverschlüsselung Jahrelang also so von 2006 bis 2018 hat das niemanden gestört. Irgendwann hat aber wohl ein Sicherheitsfanatiker dazu einen Bug aufgemacht. Und jetzt scheint ecryptfs aus allen Distributionen zu fliegen. So ist ecryptfs auch in  Buster nicht enthalten.  Ebenso weil die Meute dann allesamt in die gleiche Richtung rennt, ist es auch in Devuan Beowulf nicht enthalten. In Devuan Ascii ist es noch vorhanden.  Nun ich habe mein Home aber 2006 mit ecryptfs verschlüsselt und ziehe es seitdem halt immer mit. Tatsächlich hat das Heimatverzeichnis eine Größe erreicht, dass ich nicht genügend Platz auf der Festplatte habe um es so eben mal unentschlüsselt auf dieselbe Festplatte zu legen. Um ecryptfs rückgänge zu machen, sagt die Anleitung einfach entschlüssel es mach ein tar aus den entschlüsselten Daten, dann eine umount auf das private und dann wieder entpacken. Nette Empfehlung, aber die verschlüsselten Daten sind dann immer noch auf der Festplatte und man braucht den Platz quasi dreimal um das wieder rückgängig zu machen. In meinem Fall auf einer 500GB Platte also 600GB bei einem Heimatverzeichnis von 200GB.

Deswegen beinhaltet mein Test auch immer, komme ich auch wieder an meine Daten.

To be continued ….

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

7 + siebzehn =