"Ich beuge mich nicht" - Leserbrief

In der WZ am 18.02.22 ist ein Leserbrief als Antwort auf meinen Leserbrief über "Verachtung für die Demokratie" abgedruckt worden. Am 01.03. wurde dies als Antwort darauf abgedruckt.

Hr. B. zeigt absolut eindrucksvoll, dass er nichts verstanden hat und weiter in seiner schlichten Welt der Querdenker lebt und dort bleiben will.

Er hat mit seinem Leserbrief exakt das bewiesen und bestätigt, was ich schrieb: die Impfgegner suchen sich aus den Rechten und Pflichten eines Bürgers unserer Demokratie genau die Regeln heraus, die ihnen in den Kram passen, und den Rest ignorieren sie, weil das ja "ihr Recht" ist, sich frei zu entfalten. Das wichtigste für Impfgegner ist der Egoismus, nur für sich selbst zu entscheiden und zu leben.

Hr. B. zitiert Art. 8 unseres Grundgesetzes und betont, dass die "Spaziergänge" konform sind mit dem Recht auf Versammlungsfreiheit. Dummerweise oder vielleicht auch ganz gezielt unterschlägt er dabei den zweiten Satz dieses Artikels: "Versammlungen im Freien müssen angemeldet werden".

Diese selektive Wahrnehmung der Realität zieht sich durch das gesamte Verhalten der Impfgegner: wenn ihnen Gesetze nutzen, werden sie lauthals eingefordert. Wenn sie nicht erwünscht sind, werden sie als "Zwangsmaßnahme" genauso lauthals abgelehnt. Hr. B. vergisst nur die Kleinigkeit, das eine demokratische Gemeinschaft nur funktionieren kann, wenn man nicht nur die Rechte nutzt, sondern auch solidarisch die Pflichten befolgt, die sich aus den gewährten Freiheiten ergeben. Die Freiheit des Einen findet ihre Grenzen in der Freiheit der Anderen. Und auch aus meinem vorherigen Leserbrief hat er nur das herausgelesen, was ihn stört, damit er es kritisieren kann. Fakten interessieren nicht.

Der "verdammte Impfstoff" wurde mehr als zehn Milliarden Mal gegeben. Die WHO untersucht derzeit um die 80 Verdachtsfälle von Menschen, die vielleicht aufgrund der Impfung verstorben sind. Noch nie in der Geschichte gab es in so kurzer Zeit so viele gesammelte Daten über ein Medikament - deshalb fallen auch extrem seltene Nebenwirkungen tatsächlich so schnell auf. Traurig nur, dass so viele Menschen versuchen, Kausalitäten zu finden, wo keine sind, und fabulieren sich aus zufälligen Ereignissen eine Verbindung zurecht zwischen Krankheiten und der kurz zuvor erfolgten Impfung.

An der Herstellung von mRNA-Medikamenten und -Impfstoffen wird seit 30 Jahren geforscht, leider über sehr lange Zeit hinweg mit wenig Budget, als Heilmittel z.B. für Krebs. Eine leicht verständliche Beschreibung findet sich hier beim Heise-Verlag. Die Pandemie hat hier weltweit so viel Geld locker gemacht, dass innerhalb von wenigen Monaten tatsächlich wirksame Impfstoffe hergestellt werden konnten. Das ist eine unglaubliche und wunderbare wissenschaftliche Leistung! Biontech fertigt nun mobile Herstellungscontainer an, die z.B. nach Afrika geliefert werden können, wo mehr als 50 Staaten nach wie vor massiv unterversorgt sind.

Freiheit ist das neue Wort für Egoismus

[Veröffentlicht in der WZ vom 11.02.22]

Erneut zeigen die Querdenker und Impfgegner, wes Geistes Kind sie sind: der Leserbrief von Hr. Marel bringt es mit zwei kurzen Sätzen auf den Punkt. Diese Zitate klingen harmlos, aber mit etwas Hintergrundwissen offenbart sich dahinter ein Abgrund von Verachtung für Mitbürger und Demokratie.

Hintergrund dazu: Hr. Marel war Kandidat der AfD bei der letzten Kreistagswahl, unterzeichnete die als extrem eingestufte „Erfurter Resolution“ und wurde 2021 von immerhin 23.500 Menschen gewählt. Das von ihm angeführte Zitat stammt von Ken Jebsen, einem ehemaligen Moderator des rbb, der seit 2011 in Verschwörungstheorien abgedriftet ist. Er klagte mehrfach gegen Medien wegen deren Behauptung, er sei wegen antisemitischer Äußerungen entlassen worden. Klagen gegen die taz und den Spiegel verlor er.

Die Wikipedia weiß zum Künstlernamen "Ken Jebsen" interessante Details, hier nur ein kurzer Ausschnitt: "2014 und 2015 trat Jebsen als Hauptredner bei den umstrittenen Mahnwachen für den Frieden, ab 2020 bei „Querdenken“-Demonstrationen hervor. Wegen seiner Bill-Gates-Verschwörungstheorie und anderen Falschinformationen zur COVID-19-Pandemie sperrte YouTube den KenFM-Kanal im November 2020 dauerhaft. Der Verfassungsschutz Berlin beobachtet KenFM seit März 2021 als Verdachtsfall."

Die rechte Ideologie basiert auf einer verqueren Auslegung von darwinistischen Ideen: nur die Starken setzen sich durch, und auf Schwächere muss keine Rücksicht genommen werden.

Es geht den Impfgegnern überhaupt nicht mehr um die Einhaltung von demokratischen Regeln und Solidarität mit schwächeren Mitmenschen, sondern nur noch um die Durchsetzung des eigenen Willens, eben auch auf Kosten der Allgemeinheit, die im dritten Jahr mehr schlecht als recht durch diese Pandemie taumelt, mit politischen Beschlüssen, die aktiv wissenschaftliche Erkenntnisse und Expertenempfehlungen ignorieren.

"Freiheit" ist für Impfgegner das Kampfwort, um ihren Egoismus zu rechtfertigen. "Freiheit" bedeutet, dass es egal ist, wie voll die Krankenhäuser werden und dass dadurch Behandlungen und Operationen verschoben werden müssen. "Freiheit" bedeutet, an unangemeldeten Demonstrationen teilzunehmen, sie mit dem Feigenblatt des "Spaziergangs" zu tarnen und dabei Hygieneauflagen vorsätzlich zu mißachten. "Freiheit" bedeutet, wissenschaftliche Erkenntnisse als "Meinung" abzulehnen und die eigene Meinung zu Tatsachen zu erhöhen. "Freiheit" bedeutet, den Widerspruch als Verletzung ihrer demokratischen Rechte zu bejammern.

Es ist traurig, erschreckend und bezeichnend, dass Hr. Marel einen Menschen wie Ken Jebsen für zitierfähig hält und sich sogar die Mühe macht, dafür einen Leserbrief zu schreiben.

Linux from Scratch in einer Linux-VM installieren

Ich bin seit langem ein großer Fan von "Linux from Scratch", bei dem man ein komplettes Linux-System aus den Quelltexten kompiliert und installiert. Ich schrieb vor längerem schon mal darüber, wie man dieses Kompilieren automatisieren kann.

Das hat bislang auf "Blech" gut funktioniert. In letzter Zeit habe ich sehr viel mit virtuellen Maschinen gearbeitet und den Ehrgeiz entwickelt, auch ein LFS in einer VM zum Laufen zu bekommen.

Ich habe meine bisherigen LFS-Versionen direkt nach dem ersten erfolgreichen Booten als tar-Archiv gesichert, und ich dachte mir, es wäre doch schön, diese ganzen historischen Schätzchen auch ohne zugehörige Hardware weiter zu benutzen.

Es hat ein bißchen Schweiß gekostet, aber schlussendlich ist es gelungen. Ich habe eine VM mit einer alten LFS-Version bootfähig machen können. Zwischendurch gab es ein paar Stolpersteine, deshalb schreibe ich das alles mal auf ;)

Das Gastsystem ist ein Fedora mit dem installierten @Virtualization-Paket. Darin enthalten ist eine nette GUI namens virt-manager, mit der man bequem neue VMs erstellen oder eine VM aus einem bestehender Imagedatei importieren kann.

Genau wie "Linux from scratch" wollte ich aber auch eine "VM from scratch" bauen. Dafür brauche ich zuerst eine "leere" Datei im Format qcow2. Das ist gut für kleine Festplatten, weil es ein "sparse" Dateiformat ist - die Datei ist nicht so groß wie definiert, sondern wächst an ihren Aufgaben bzw. der Füllung, "leere" Lücken belegen keinen Speicherplatz. Diese leere Datei habe ich mit dem folgenden Befehl erzeugt:

# qemu-img create -f qcow2 LFS-11.0-32.qcow2 2048M

Wie üblich bei LFS braucht man für den allerersten Schritt ein Gastsystem, auf dem man die LFS-Quellen kompilieren kann. Wenn man schon ein fertiges LFS als Archiv hat, entfällt dieser Schritt, aber es ist sehr praktisch, auf dem Gastsystem eine ISO-Datei mit einem "Live Linux" für Reparaturzwecke greifbar zu haben. Diese ISO-Datei bietet man der VM als virtuelles CD- bzw. DVD-Laufwerk an und kann ggfs. sogar davon booten, um sich die VM "von innen" anzuschauen. Das funktioniert selbst dann, wenn das LFS noch nicht bootfähig ist.

qcow2 kann man als Dateisystem auf dem Gastsystem mounten, wenn die VM nicht gestartet ist. Auf diese Weise kann man die virtuelle Festplatte (in Linuxjargon aus Sicht der VM /dev/vda) partitionieren und formatieren.

Das Stichwort "virtuelle Festplatte" deutet schon den ersten Stolperstein an: als Sparbrötchen habe ich beim Kompilieren des Linuxkernels für LFS auf echtem Blech nur die allernötigsten Optionen eingeschaltet, und die reichen nicht aus für den Betrieb in einer VM. Man muss die Optionen für "virtio" (das bedeutet "ich bin eine virtuelle Maschine") aktivieren, und ohne Basteleien an der "initial ramdisk" initrd ist es besser, wenn man alle virtio-Funktionen fest in den Kernel aufnimmt und gerade nicht als Module. Wenn man das Modul virtio_blk beim Booten nicht hat, findet der Kernel seine virtuelle Festplatte nicht und stoppt mit einem "kernel panic".

Während man also die virtuelle Festplatte vorbereitet, kann in einem anderen Fenster nebenbei ein Kernel kompiliert werden ;). Mindestens die Optionen CONFIG_VIRTIO und CONFIG_VIRTIO_BLK müssen in der .config-Datei auf "y" gesetzt werden (nicht "m"). Alle einzuschalten (console, net, iommu etc.) ist natürlich nicht verkehrt, soviel größer wird der kompilierte Kernel dadurch nicht. Da ich nur eine Sorte Kernel kompilieren will, der auf Blech und virtuell funktionieren soll, brauche ich auch das Modul für SATA-Festplatten fest eingebaut, d.h.  das SCSI-Disk-Modul "sd" ist nötig, also ist auch CONFIG_BLK_DEV_SD auf "y" zu setzen. Wer sich mit initialen Ramdisks auskennt, kann natürlich sportlich alle Optionen auf "m" für "module compile" setzen und eine initrd erzeugen. Das wird aber in LFS nicht gut unterstützt und ist deshalb "left as an exercise to the reader" ;)

Für das Mounten der VM-Festplatte auf dem VM-Host ist ein Linuxmodul "nbd" nötig, das die Verbindung zwischen der qcow2-Datei und einem Device in /dev herstellt. Ob man nun eine Partition für alles baut oder sich am moderneren EFI-Layout mit separaten Partitionen für /boot etc. orientiert, ist bei LFS eigentlich ziemlich egal.

Nach dem Erzeugen der qcow2-Datei muss das Device mit qemu-nbd gemountet ("connected") werden. Danach kann man mit fdisk oder parted die gewünschten Partitionen anlegen und formatieren. Die Größe der Partitionen ist im Skript unten hartkodiert und muss ggfs. angepasst werden. Die Größe der 3. Partition (root) erfährt man mit dem Befehl "parted devicename print". Dies ist der Wert beim letzten mkpart-Befehl (hier fett hervorgehoben).

# parted /dev/nbd0 print
Model: Unknown (unknown)
Disk /dev/nbd0: 2147MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  257MB   256MB   primary
 2      258MB   514MB   256MB   primary
 3      515MB   2147MB  1633MB  primary

Dieses Skript erledigt nun die ganze Arbeit, eine qcow2-Datei als virtuelle Festplatte für die VM vorzubereiten und mit Filesystemen zu versehen.

TO=/dev/nbd0
BOOT="${TO}p1"
SWAP="${TO}p2"
ROOT="${TO}p3"

img=~ths/kvm/LFS-10.1-32.qcow2
size=2048M
MNTROOT=/mnt/lfs
MNTBOOT="${MNTROOT}/boot"

modprobe nbd max_part=8
mkdir -p "${MNTROOT}"
qemu-img create -f qcow2 "${img}" "${size}"

qemu-nbd --connect="${TO}" "${img}"
P="parted --script --fix ${TO}"

${P} mklabel msdos
${P} mkpart primary ext4   1  257
${P} mkpart primary ext4 258  514
${P} mkpart primary ext4 515 2147
${P} set 1 boot on
${P} print 

mkfs -t ext4 "${BOOT}"
mkfs -t ext4 "${ROOT}"
mkswap /dev/nbd0p2

mount "${ROOT}" "${MNTROOT}"
mkdir -p "${MNTBOOT}"
mount "${BOOT}" "${MNTBOOT}"

Als nächstes wird das LFS-Archiv ausgepackt. Mein Beispiel zeigt ein historisches LFS 8.0 mit einem damaligen Kernel 4.10 ;), man könnte aber auch ein aktuelles LFS verwenden.

cd /mnt/lfs
tar xf LFS-8.0-32.tar

Danach müssen die grub.cfg und die fstab angepasst werden, damit die Namen der Partitionen mit denen übereinstimmen, die die VM zur Verfügung stellt.

/dev/vda3 /      ext4  defaults  1 1
/dev/vda2 swap   swap  pri=1     0 0
/dev/vda1 /boot  ext4  defaults  1 1

Es ist auch eine gute Idee zu kontrollieren, ob die Verzeichnisse, die so ein Linuxsystem zum Betrieb benötigt, alle da sind, z.B. /tmp mit den richtigen Berechtigungen (wer weiß, was die "1" in "1777" bedeutet?), /var/log, /run, /sys usw. Danach folgt der (für mich) größte Stolperstein. Es ist nun nötig, dem Bootloader grub mitzuteilen, wie Linux von der Festplatte gestartet wird.

Der dazu nötige "Trick" ist sogar in der LFS-Anleitung beschrieben. Man muss nur auf die Idee kommen, dass diese Schritte auch für das Erzeugen einer VM nötig sind!

Die virtuellen Devices, die ein Linuxkernel zum Funktionieren benötigt, muss man in die künftige VM "duplizieren". Diesen Vorgang nennt man "bind mount", das ist eine Kopie eines Mounts an einer zweiten Stelle. Mit Hilfe dieser Devices ist grub erst in der Lage, die virtuelle Festplatte bootfähig zu machen.

export LFS=/mnt/lfs
mkdir -pv $LFS/{dev,proc,sys,run}
mknod -m 600 $LFS/dev/console c 5 1
mknod -m 666 $LFS/dev/null c 1 3
mount -v --bind /dev $LFS/dev
mount -v --bind /dev/pts $LFS/dev/pts
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run
if [ -h $LFS/dev/shm ]; then
  mkdir -pv $LFS/$(readlink $LFS/dev/shm)
fi

Beim Auspacken eines "fertigen" LFS-Archivs sind die Device-Nodes für console und null natürlich schon da; die Fehlermeldungen kann man getrost ignorieren. Der Vollständigkeit halber habe ich die Schritte aus der LFS-Anleitung komplett zitiert.

Der nächste Schritt ist genauso wichtig: grub muss die "echten" Pfad- und Dateinamen sehen können. Dazu muss man mit chroot in das neue LFS-System wechseln.

export LFS=/mnt/lfs
chroot "${LFS}" /usr/bin/env -i \
    HOME=/root                  \
    TERM="${TERM}"              \
    PS1='(lfs chroot) \u:\w\$ ' \
    PATH=/usr/bin:/usr/sbin     \
    /bin/bash --login +h

In dieser schon "halb" simulierten Umgebung führt man grub-install auf die virtuelle Festplatte aus. Falls Host und Gast unterschiedlich "große" CPUs verwenden, muss grub Bescheid wissen, ob das Gast-LFS mit 32 Bit läuft. Ansonsten reicht es, das Device anzugeben.

grub-install /dev/nbd0

bzw.

grub-install --target=i386-pc /dev/nbd0

Danach kann man mit exit die chroot-Umgebung verlassen und die "bind mounts" wieder rückgängig machen.

export LFS=/mnt/lfs
umount $LFS/dev/pts
umount $LFS/dev
umount $LFS/proc
umount $LFS/sys
umount $LFS/run 

Weiter oben hatte ich vorgeschlagen, in einem anderen Fenster einen Linuxkernel vorzubereiten, in dem die VIRTIO-Optionen alle fest in den Kernel eingebaut sind. Diesen Kernel sollte man nun nach /boot in die virtuelle Festplatte kopieren und den exakten Dateinamen in die grub.cfg eintragen. Die Anweisung "set root" in grub.cfg weist den Bootloader auf die Partition hin, in der der Kernel zu finden ist. In der Kernelkommandozeile hingegen ist "root=..." die Angabe, auf welcher Partition das Root-Filesystem dieser Linuxinstallation zu finden ist. Meine sehr schlichte /boot/grub/grub.cfg sieht so aus:

# Begin /boot/grub/grub.cfg
set default=0
set timeout=2

insmod ext2
insmod gzio
insmod part_msdos
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
font="/usr/share/grub/unicode.pf2"

menuentry "Linux from Scratch 11.0 5.15.21-64 vda3" {
    set root=(hd0,1)
    linux  /vmlinuz-5.15.21-64 root=/dev/vda3 ro
    initrd /initrd-5.15.21-64.img
}

Als vorletzten Schritt muss man nun die virtuellen Festplattenpartitionen unmounten und nbd anweisen, die Verbindung zwischen der qcow2-Datei und dem Device aufzuheben.

umount "${MNTBOOT}"
umount "${MNTROOT}"
qemu-nbd --disconnect "${TO}"
rmmod nbd

Nachdem die Datei der virtuellen Festplatte freigegeben ist, kann entweder mit dem GUI virt-manager oder auf der Kommandozeile mit virsh die eigentliche virtuelle Maschine aus der qcow2-Datei erzeugt werden. Im GUI klickt man sich durch das "create"-Menü und wählt "import existing disk image" und den Dateinamen aus. In der virsh verwendet man am besten eine bestehende VM als Muster, um die Definition als XML-Datei zu exportieren, ein paar Zeilen zu ändern (falls später die beiden VMs parallel laufen sollen), insbesondere natürlich den Dateinamen der neuen qcow2-Datei.

# virsh dumpxml vm-lfs1-11.0-64 > vm-lfs2-11.0-64.xml

Ich schlage vor, die folgenden Einträge in der XML-Datei zu verändern. Die man-Page von virsh empfiehlt, auch die UUID zu verändern oder die Zeile komplett zu löschen - dann vergibt virsh eine neue UUID.

>   <name>vm-lfs2-11.0-64</name>
>   <title>vm-lfs2-11.0-64</title>
>   <description>vm-lfs2-11.0-64</description>
<       <source file='/home/ths/kvm/vm-lfs1-11.0-64.qcow2'/>
>       <mac address='52:54:00:01:d1:22'/>

Dann kann man mit "define" die neue "Domain" bekannt machen. "Domain" ist der Begriff, mit dem KVM die virtuellen Maschinen bezeichnet.

# virsh define vm-lfs2-11.0-64.xml

Die VM kann jetzt gestartet werden, entweder im GUI des virt-manager oder mit virsh auf der Kommandozeile. Falls der Bootvorgang mit einem "kernel panic" und dem Hinweis "unknown block device (0,0)" endet, kann der Linuxkernel die virtuelle Festplatte nicht erkennen. Dann hat etwas beim Kompilieren des Kernels nicht geklappt mit der Aktivierung der VIRTIO-Optionen.

# virsh start vm-lfs2-11.0-64

Eine alternative Möglichkeit zur Reparatur ist das Starten der VM mit einer ISO-Datei eines Live-Linux-Systems. Dieses System sollte die virtuelle Festplatte ebenfalls erkennen, und man kann erneut versuchen, mit dem chroot-Schritt von oben die VM bootfähig zu machen.