đź’» ARM Architektur (Raspberry Pi) Test-Umgebung simulieren đź’»

in STEMGeeks • 3 months ago (edited)

Moin Nerd's und Minicomputer-Fans


raspberry-pi-4980917_640.jpg
Bild von planet_fox auf Pixabay


Einleitung

  • Wozu sollte man sich eigentlich eine Test-Umgebung schaffen, da man eigentlich mittels "Debootstrapping" und Qemu/KVM, direkt funktionierende Images erstellen kann?

Der Bau eines eigens abgestimmten und schlanken Systemes, ist sehr Zeitaufwendig und mit der Zusammenstellung von Kern-Modulen und Firmware, ist der Betrieb nur auf ganz bestimmter Hardware möglich.
Eine Test-Umgebung ermöglicht eine Zusammenstellung von Modulen und Diensten, ohne auf Besonderheiten spezifischer Geräte (z.B. Raspberry Pi) Rücksicht zu nehmen.
Ein weiterer Vorteil besteht darin, dass man im Vorfeld die Hardware nicht benötigt. Es langt lediglich die Vorstellungen über Beschaffenheit und CPU-Architektur aus. Es ist somit möglich, in der Test-Umgebung ein System zu entwickeln und nach deren Fertigstellung, der jeweils ausgewählten Hardware anzupassen. Auch bietet die Test-Umgebung die Möglichkeit, Systeme für unterschiedlicher Hardware, mit einer allgemeinen Basis der Architektur, zu testen und zu bauen.


Grundlagen

  • Eigentlich ist dieser ganze Vorgang recht einfach, aber trotzdem richtet sich dieser Beitrag an den etwas Fortgeschrittenen Nutzer. Grundkenntnisse von Linux und deren Komponenten sollten schon vorhanden sein.

In meiner Anleitung wird ein Ubuntu 18.04 als Host betrieben, auf dem ein Gast-PC, mit allgemeiner ARM-Architektur und ein Grundsystem auf Debian-Stretch-Basis, simuliert wird.
Da die Test-Umgebung nicht viel Leistung benötigt, können MS Windows-Nutzer diese Simulation, auf ein in Virtual Box installiertes Ubuntu (Lubuntu), problemlos ausführen.

Weil die Umgebung speziell der ARM-Architektur nur über Qemu und KVM ausgeführt werden kann, ist es im Vorfeld nötig, diese Pakete zu installieren und sich mit der Funktionsweise vertraut zu machen.
Eine Anleitung zur Installation und Bedienung, kann man auf Ubuntuusers.de - Qemu und Ubuntuusers.de - KVM finden.
Denkt bitte daran, dass Ihr euren Account zur KVM-Gruppe hinzufĂĽgt.

  id

Bildschirmfoto_2020-12-12_17-06-25.png

Falls nicht, langt ein

  sudo adduser $USER kvm

Nach einem System-Neustart, solltet Ihr dann der Gruppe angehören.

Zusätzlich benötigen wir libguestfs, da in unserer Testumgebung ein Bootloader nicht nötig und vorgesehen ist. - Wir starten die fertige Umgebung ganz altmodisch manuell ;)

Um eine Grundlage (Systembasis) zu schaffen, nutzen wir in dieser Anleitung einen fertigen Debian Installer, mit dem wir ein schlankes Basissystem auf dem Emulator installieren.
Selbstverständlich kann man die selben Schritte auch mit einem selbstgebauten Installer und Kernel durchführen.


Installation Medium beschaffen

Damit es fĂĽr mich etwas ĂĽbersichtlicher bleibt, habe ich mir ein gesondertes Verzeichnis eingerichtet, in welches ich die Installerdateien geladen habe.

  wget -O installer-linux http://http.us.debian.org/debian/dists/stretch/main/installer-arm64/current/images/netboot/debian-installer/arm64/linux

  wget -O installer-initrd.gz http://http.us.debian.org/debian/dists/stretch/main/installer-arm64/current/images/netboot/debian-installer/arm64/initrd.gz

Bildschirmfoto_2020-12-11_22-10-29.png


Welches Debian Ihr dafĂĽr nehmt ist ganz egal. Wer's mag, kann auch ein Stabil oder Sid nehmen. Wichtig ist in unseren Fall nur, dass sie der ARM-Architektur ( binary-arm64 ) entspricht.
Auch sollte man darauf achten, dass die beiden Dateien im selben Verzeichnis geladen und so benannt werden, dass sie nicht mit dem endgültigen Kernel und initrd verwechselt werden können, welche später bei der Installation erzeugt werden.
In meinem Fall habe ich sie "installer-linux" und "installer-initrd.gz" genannt.

Bildschirmfoto_2020-12-12_17-54-07.png

Da wir unter Qemu die "virt" Karte nutzen, brauchen wir keinen separaten Gerätebaum herunterladen oder erstellen, da er durch Qemu automatisch erstellt und an den Kernel übergeben wird.


Installation der Systembasis (Testumgebung)

  • ein virtuelles Laufwerk im Testverzeichnis erstellen

Je nach Bedarf kann eine Festplatte mit ausreichender Größe erzeugt werden. Unser Beispiel erzeugt ein Laufwerk mit einer Größe von 16 GB.

  qemu-img create -f qcow2 hda.qcow2 16G

Bildschirmfoto_2020-12-11_22-32-57.png

Da wir nun eine Festplatte haben, können wir die Installation starten.

  qemu-system-aarch64 -M virt -m 1024 -cpu cortex-a53 \
-kernel installer-linux \
-initrd installer-initrd.gz \
-drive if=none,file=hda.qcow2,format=qcow2,id=hd \
-device virtio-blk-pci,drive=hd \
-netdev user,id=mynet \
-device virtio-net-pci,netdev=mynet \
-nographic -no-reboot

Dieser Befehl kann komplett in einem Schritt eingegeben werden und nach Bedarf verändert werden (siehe man qemu).

  -m 1024 

Dieser Parameter gaukelt einen Hauptspeicher (RAM) von 1 GB vor. Wenn man mehr wünscht, kann man es gerne ändern. Einen Umrechner findet man auf https://www.gbmb.org/gb-to-mb

Nun beginnt die Installation, welche ĂĽber eine Konsole ĂĽberwacht und eingerichtet wird.
Hier werden Ländereinstellung, Tastenlayout und Zeitzone ausgewählt

Bildschirmfoto_2020-12-11_22-39-13.png

Bildschirmfoto_2020-12-11_22-37-26.png

Sowie ein Hostname, Passwort fĂĽr den Root und ein Benutzerkonto angelegt.

Bildschirmfoto_2020-12-11_22-40-35.png

Bildschirmfoto_2020-12-11_22-48-31.png

Insgesamt kann die Installation 1 bis 2 Stunden in Anspruch nehmen, da die ausgewählten Komponenten aus dem WWW geladen werden.

Bildschirmfoto_2020-12-11_23-27-54.png

Die Partitionierung der Festplatte kann fĂĽr diese Testumgehung einfach per Default angelegt werden.

Bildschirmfoto_2020-12-11_22-52-50.png

Es geht schneller und ist völlig ausreichend.

Bildschirmfoto_2020-12-11_22-55-14.png

Außer dem Systemkomponenten benötigen wir noch ssh. Dieses sollte schon während der Installation ausgewählt werden, da wir später im laufenden System Dateien vom Host zum Gast kopieren wollen und können.

Bildschirmfoto_2020-12-12_00-02-22.png

Wenn die Installation beendet ist, erscheint am Ende noch der Hinweis darauf, dass kein Bootloader installiert wurde.

Bildschirmfoto_2020-12-12_00-27-10.png

Im Parameter " no-reboot " haben wir im Vorfeld einen Reboot ausgeschlossen und können diesen Hinweis ohne weiteres quittieren.

Bildschirmfoto_2020-12-12_00-27-47.png

Das System wird nun vollständig heruntergefahren. - Genau genommen stürzt es ab, aber mit dem gewollten Ziel, dass es beendet ist ;)

Es empfiehlt sich eine Kopie von dem neu erstellten System zu machen, um bei der Erstellung einer neuen Testumgebung sich eine neue aufwendige Installation ersparen zu können.


Der erste Start

Da wir ja keinen Bootloader installiert haben, mĂĽssen wir Qemu mitteilen, mit welchem Kernel das System gestartet werden soll und wo sich die "Root" befindet.
Mit folgenden Befehl lassen wir uns die Partitionen anzeigen

virt-filesystems -a hda.qcow2

Bildschirmfoto_2020-12-12_19-20-07.png

Hier werden zwei Partitionen angezeigt, wovon sda1 den Einhängepunkt "/boot" hat und sda2 das Wurzelsystem "/" hat.
Wir benötigen zum Starten also sda2.

Den aktuelle funktionierenden Kernel liefert uns der Befehl

  virt-ls -a hda.qcow2 /boot/

Bildschirmfoto_2020-12-12_19-03-18.png

Sollte obiger Befehl sowie

  virt-filesystems -a hda.qcow2

einen Fehler ausgeben, so könnte ein

  sudo chmod 644 /boot/vmlinuz*

auf dem Host Abhilfe bringen.
Werden zwei Kernelversionen angezeigt, so sollte der erste (Ă„ltere) meistens arbeiten. - Zwei Kernel hat man schnell durchprobiert ;)

Hier im Beispiel wird uns 4.9.0.13 angezeigt und wir nutzen diesen Kernel fĂĽr unseren ersten Start.

  virt-copy-out -a hda.qcow2 /boot/vmlinuz-4.9.0-13-arm64 /boot/initrd.img-4.9.0-13-arm64

Mit diesem Befehl werden die Komponenten in unser Hostverzeichnis kopiert.

Bildschirmfoto_2020-12-12_17-54-07.png

So, das war es erstmal auch schon.
Da wir das System erstmal nur auf seine Funktionalität prüfen wollen, langt ein einfacher Befehl völlig aus.
Auch hier können Parameter je nach Bedarf geändert und hinzugefügt werden. Denkt aber bitte daran, dass wir eine funktionierende Netzwerk-, Internet-Verbindung benötigen. Dieses sollte unbedingt in den Startparametern enthalten sein.
Wenn sich jemand im Vorfeld nicht ganz sicher ist, ob seine Startangaben korrekt sind und funktionieren, kann man sich ja Dateien aus einem Bootloader eines funktionierenden Systems anschauen und die Startparameter dementsprechend ableiten und testen - habe ich ebenfalls so getan und nach ein paar Versuchen ist es mir dann tatsächlich gelungen ;)

  qemu-system-aarch64 -M virt -m 4096 -cpu cortex-a53 \
-kernel vmlinuz-4.9.0-13-arm64 \
-initrd initrd.img-4.9.0-13-arm64 \
-append 'root=/dev/vda2' \
-drive if=none,file=hda.qcow2,format=qcow2,id=hd \
-device virtio-blk-pci,drive=hd \
-netdev user,id=mynet \
-device virtio-net-pci,netdev=mynet \
-nographic

Mit den obigen Angaben, sollte es ohne Fehlermeldungen sauber starten

Bildschirmfoto_2020-12-12_19-30-36.png

und wir können uns entweder mit dem Benutzerkonto oder Root anmelden

Bildschirmfoto_2020-12-12_19-31-54.png

Ein Test ob die Paketquellen und das Internet funktionieren, kann man als root mit

  apt-get update

starten.
Unser System sollte so kurz nach der Installation eigentlich auf dem neusten Stand sein.


AbschluĂź

Jetzt haben wir auf ziemlich einfacher Weise eine Testumgebung für ARM-Architekturen aller Art geschaffen und können nun anfangen unser System um Komponenten und Diensten zu erweitern und zu testen.

Ich sehe diese Testumgebung als gutes Hilfsmittel, mit dem ich Systeme erweitern und verändern kann, ohne sie auf einer speziellen Hardware ausführen zu müssen. - Mir ging nämlich dieses ständige auf SD-Karte kopieren und Hardware starten mächtig auf den Senkel :-)

Eine Bitte habe ich am Schluss noch. Bevor Ihr mit der Installation dieser oder einer anderen Testumgebung anfangt, solltet Ihr euch unbedingt mit der Bedienung von KVM/Qemu vertraut machen und eventuell erstmal an einer einfachen Installation eines Betriebssystems ĂĽben.
Für Neueinsteiger können diese Befehle schon sehr verwirrend und nichtssagend wirken, aber mit etwas Übung und der richtigen Lektüre ( https://help.ubuntu.com/community/KVM ) ist es durchaus Machbar ;)


Schönen Tag noch und frohes basteln

Posted with STEMGeeks

Sort:  

Erst mal Bookmark und Reblog gesetzt. So ein Beitrag von Dir bürgt von hoher Qualität und viel Arbeit. Den werde ich mir mit mehr Zeit ansehen müssen. Fundiertes Feedback kommt also noch.Es kann ja auch als wirklich gute Dokumentation auf der Blockchain genutzt werden. Löschen ist ja nicht mehr. (Den Bilden könnte es an den Kragen gehen.

Ich finde es immer wieder sehr schade wie sehr personenabhängig das Voten von Posts ist und Du da keine Unterschiede machst.

Respekt! Der gleiche Post hätte jetzt schon ein vielfaches an Money eingenommen.

Liebe GrĂĽĂźe Michael

!invest_vote
!jeenger

Dem kann ich eigentlich nur zustimmen.

Congratulations @stuntman.mike! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You received more than 50 upvotes. Your next target is to reach 100 upvotes.

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @hivebuzz:

The Hive Gamification Proposal #2

I hope some day get one and try to learn about it.

Your decision!

@mima2606 denkt du hast ein Vote durch @investinthefutur verdient!
@mima2606 thinks you have earned a vote of @investinthefutur !

Your contribution was curated manually by @mima2606
Keep up the good work!