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.
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.
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.
Keine Kommentare:
Kommentar veröffentlichen