# arm64 changeroot mit amd64?

## 3PO

Hallo Zusammen,

gibt es eigentlich eine Möglichkeit, ein arm64 System mit einem x86_64 System zu changerooten?

Ich würde gerne eine arm64 Installation in einer changeroot betreiben, um das System upzudaten.

Google ist da recht widersprüchlich, was das Thema angeht. Evtl. hat ja Jemand eine Anleitung?

----------

## schmidicom

Auf der folgenden Seite hat mal einer mit sowas herum gespielt:

http://blog.oddbit.com/2016/02/07/systemd-nspawn-for-fun-and-well-mostly-f/

Ich konnte es bis jetzt allerdings noch nicht erfolgreich reproduzieren, was aber vermutlich eher an mir lag.  :Wink: 

----------

## 3PO

So richtig kann ich diesem Blog nicht folgen, aber abgesehen davon, verwende ich kein systemd.

----------

## ChrisJumper

Ich bin mir bei dem ARM64 nicht sicher. Dachte mein Atom-Notebook hätte diese Architektur. So wirklich gut unterstützt scheint das auch nicht zu sein -wobei fairer Weise muss man mal schauen wie das ARM-Team hier bei Gentoo noch an dem Projekt arbeitet.

Das letzte ARM64 stage3 Tarbel war schon über ein Jahr alt, also quasi eigentlich schon nicht mehr zu gebrauchen.

Der Blog Eintrag Probiert da ja QUEMU, also die Linux-Kernl(VM) Virtual Machine aus um das zu testen.

Genau das müsste bei dir eigentlich auch passen. Das du dir eine Virtuelle Maschine aufsetzt und einfachst probierst darin Code den du vielleicht per Cross Compiling erstellst, zum laufen zu bringen.

Wahrscheinlich ginge das dann auch ala Linux from the Streach so das du dir eine aktuelles Gentoo da aufbauen könntest. Der Zeitaufwand ist natürlich etwas größer und du musst genau schauen wie viel Arbeitsspeicher du hast.

Sind die Smartwatches nicht auch ARM-Geräte? Eventuell kannst du auch ein Android nutzen. Vielleicht gibt es auch schon eine ähnliche Alternative die einfacher zu greifen ist, wie FirefoxOS... eine mal die Augen offen halten. Edit: warum hab ich nicht gleich daran gedacht! Der Raspberry Pi ist ja auch ARM! Sicher das Linux dafür ist wahrscheinlich stark angepasst für den Raspi, aber den Kernel müsstest du auch selber herrichten und Konfigurieren können.

Was die Chroot-Möglichkeit betrifft. Ich hab auf meinem Atom eine ARM Stage3 tarbel entpackt (in ein altes Linux amd-x86_64), von dem ich dachte es ei ein ARM System. Wenn der Chroot nicht geht, bekommst du das beim Versuch von chroot /mnt/gentoo /bin/bash direkt angezeigt weil er halt Probleme hat /bin/bash zu nutzen, er mit dem Binary Package nichts anfangen kann.

Es kommt halt auf die verwendete CPU und unterstützen Befehlssatz an. Keine ARM-Architektur unterstützt den x86_64 Befehlssatz. Die letzte Generation von ARM (ARMv8 ab 2011) unterstützt wohl ähnlich zu modernen x86_64 Rechnern auch den Befehlssatz von 32-Bit vorgänger, aber nur für ARM. Also nicht X86 aber halt AArch32, quasi als Abwärtskompatibilität. Selbst wenn das System sonst im 64 Bit Modus läuft (A64).

Klaus Knopper hatte wohl auch eine Version mal eine Knoppix Version entwickelt die unter ARM lief beziehungsweise auf dem Raspberry Pi. Aber die finde ich nicht. Lediglich ein PDF dazu hab ich auf die Schnelle gefunden.

----------

## 3PO

Nun, crossdev ist installiert und funktioniert auch. Ich habe den Kernel damit gebaut und das System funktioniert ja auch. nur ist es hat so, wie Du schon richtig bemerkt hast, dass das stage3 schon recht alt ist und genau deshalb will ich es ja changerooten, denn wenn ich ein world Update auf einem Pi3 starte und so ca. 500 Pakete (~ 2000 MB Sourcecode) compiliere, dann ist das System, bis der fertig ist, auch wieder veraltet.  :Smile: 

----------

## schmidicom

 *3PO wrote:*   

> So richtig kann ich diesem Blog nicht folgen, aber abgesehen davon, verwende ich kein systemd.

 

Es dürfte vermutlich auch mit chroot und einem statisch compilierten qemu funktionieren. Der Ablauf wäre dann wohl ähnlich wie beim Installieren von Gentoo über eine eine Live-CD nur eben mit Qemu und binfmt dazwischen.

EDIT2: (Das folgende ist durch den Fund von 3PO im Gentoo Wiki hinfällig geworden)

1. Die nötigen Verzeichnisse in die arm64-Umgebung mounten.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Mounting_the_necessary_filesystems

2. Die static Qemu-Binary "/usr/bin/qemu-aarch64" in die arm64-Umgebung kopieren und zwar so das diese nach einem chroot unter dem Pfad "/qemu-aarch64" gefunden werden kann.

3. Die nötige Binfmt-Konfiguration einrichten.

```
# AArch64 binaries.

:qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/qemu-aarch64:OC
```

4. In die arm64-Umgebung chrooten.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Entering_the_new_environment

EDIT:

Habe gerade bemerkt das unter Gentoo zusammen mit qemu ein OpenRC-Service "/etc/init.d/qemu-binfmt" installiert wird das die binfmt-Konfiguration übernimmt, nur mit anderen Pfadangaben.Last edited by schmidicom on Tue Jan 23, 2018 12:22 pm; edited 1 time in total

----------

## 3PO

Auf Grund des Poastings von "schmidicom" habe im Wiki diesen Eintrag gefunden:

https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot

Ich habe auf meinem System aber bereits "app-emulation/qemu" installiert und auch einige VMs am laufen.

Die Frage ist nun, ob ich da einfach das USEfalg "static-user" setzen kann, ohne meine bisherige Installation zu zerstören?

----------

## 3PO

Ich habe da noch etwas gefunden, von dem ich annehme, dass das genau das ist, was ich brauche:

--> https://wiki.gentoo.org/wiki/User:NeddySeagoon/Pi3_Build_Root#Setting_Up_An_Aarch64_Chroot_For_a_Pi_3

Leider aber sind die Ausführungen doch sehr knapp. Mal sehen, ob ich damit klar komme.

----------

## musv

Da ich mittlerweile einen längeren Leidensprozess hinter mir hab, kann ich ein paar Sachen dazu sagen. Ich hab Gentoo auf dem Ding (Marvell Armada 380) laufen. Zum Compilieren nutze ich meinen Xeon-Rechner. Das ARM-Teil ist noch etwas langsamer als ein RPi und mit 512mb RAM bestückt.

Qemu-User

Ansich hübsch, wenn es denn das entsprechende Profil bzw. die genaue Zielarchitektur darin gäbe. Ich hab versucht, da so einiges zu compilieren. Wirklich nativ hab ich die Compilate dann nicht zum Laufen gebracht bzw. schon vorher aufgegeben. Im Grunde genommen war Qemu-User für mich hier eine totale Sackgasse. Um irgendwelche ARM-Binaries auf dem x86-Host auszuprobieren, ist qemu-user ganz gut. 

Systemd-Nspawn

Hübsche Sache. Ich nutze Systemd und hatte auch mal 'ne Zeit lang Nspawn im Einsatz. Obwohl es im o.g. Artikel mit Docker verglichen wird, würde ich es eher bei unserem Einsatzzweck als ein erweitertes Chroot ansehen. Der Vorteil von NSpawn besteht hauptsächlich im Weiterreichen der ganzen notwendigen Devices und Verzeichnisse, die man bei einem normalen Chroot per mount --bind einbinden müsste. Nspawn ist bequem und spart Zeit.

Chroot

Ist hier der falsche Weg. Beim Compilieren werden das Profil und die Binaries des Zielrechners auf einem anderen Rechner ausgeführt. Das klappt nur, wenn die Architektur der zu compilierenden CPU-Architektur eine Teilmenge der CPU-Architektur ist, auf der im Endeffekt compiliert wird. ARM nutzt aber andere Befehle als eine x86-CPU. Dabei klappt das Ganze schon innerhalb der x86-Architektur nicht zu 100% (Xeon kennt den movbe-Befehl des Atom nicht).

Crossdev + NFS

Ist für mich die derzeitige Fallback-Lösung. Damit hab ich die Compilierung des Systems begonnen. Einige Pakete, z.B. Python konnte ich nur damit compilieren. Andere klappen überhaupt nicht. 

Anleitung:

Crossdev installieren. Die Umgebung landet in /usr. Bei mir heißt das Ding: /usr/armv7a-hardfloat-linux-gnueabi. Wichtiger dabei sind aber die Befehle in in /usr/bin, u.a. /usr/bin/armv7a-hardfloat-linux-gnueabi-emerge. Sofern die Dateien und Verzeichnisse nicht auf dem PI vorhanden sind, kopiert man die rüber. 

Auf dem PI richtet man einen NFS-Server ein und gibt / an den Compilier-Host frei. 

Auf dem Compilier-Host mountet man dann das Ziel / nach /usr/arm... 

```
nas:/root     /usr/armv7a-hardfloat-linux-gnueabi       nfs4    noauto,rw,intr,noatime,nodiratime,vers=4.1  0 0
```

In der make.conf auf dem PI müssen noch ein paar Anpassungen vorgenommen werden (Kommentare immer raus, wenn man es benutzt):

```
############### Zeug aus Cross-Compiling-Umgebung ##########

#VERS=6.4.0

#VERS=7.2.0

#CBUILD=x86_64-pc-linux-gnu

#ARCH="arm"

##

#HOSTCC=x86_64-pc-linux-gnu-gcc

##

#ROOT=/usr/${CHOST}/

#CCFULL=/usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/gcc-bin/${VERS}/armv7a-hardfloat-linux-gnueabi

#CC=${CCFULL}-gcc

#CXX=${CCFULL}-g++

#######################################
```

Das Compilieren erfolgt dann mit: 

```
armv7a-hardfloat-linux-gnueabi-emerge mein_paket
```

Das Ganze funktioniert überwiegend gut. Bei manchen Paketen zieht sich emerge allerdings falsche Daten. Z.B. wurde bei mir emerge bei der Installation von app/portage ins Verzeichnis /usr/lib64 installiert, was auf einer 32-Bit-ARM-Plattform relativ wenig Sinn ergibt. Auch kommt es zu einigen Compilierabbrüchen, weil manche Pakete halt mal während des Compilierens auf den x86_64-gcc umschalten.

Crossdev + Distcc

Ist die von mir präferierte Variante, da es die stabilste ist. Leider ist es auch die langsamste. 

Man installiere wieder crossdev auf dem x86-Compilierhost (siehe Crossdev + NFS).

Auf beiden Rechner wird Distcc installiert, auf dem Compilier-Host wird der Daemon gestartet. 

Auf dem PI: 

```
compilierhost/8
```

Ja, der PI steht hier nicht drin. Ich hab bei mir gemerkt, dass das Compilieren wesentlich schneller abläuft, wenn sich der GCC auf dem ARM-Teil nur darum kümmert, die Precompile-/Configure-Sachen zu übernehmen und das Compilieren vollständig dem x86-Host überlässt. Der PI ist auch mit diesen Ausgaben schon hinreichend stark ausgelastet.

Compilieren auf dem PI: 

```
FEATURES="distcc" MAKEOPTS="-j9" emerge $@
```

Es gibt ja noch den Pump-Mode. Allerdings hab ich den nie brauchbar zum Laufen bekommen. Wenn's bei einem Paket funktioniert hatte, hagelte es bei nächsten irgendwelche Fehler im Log. Deswegen hab ich den Pump-Mode nicht im Einsatz.

Und noch ein kleiner abschließender Tipp: Ich hab mir auf meinem ARM-Teil eine 8GB große Swap-Datei eingerichtet, die ich beim Compilieren größerer Brocken dem Swap hinzufüg. Anders bekomm ich z.B.  den gcc nicht compiliert. Den GCC compilier ich im Updatefall sogar ohne Distcc und lass den Compiliervorgang dafür über Nacht laufen. Die ARM-Dinger sind ja sowieso für 24/7 ausgerichtet.

----------

## 3PO

Danke @ musv für wirklich ausführlichen Ausführungen.

Ich habe HIER noch etwas gefunden, allerdings habe ich ehrlich gesagt, das Interesse am PI3, bzw. dem ganzen ARM Zeugs verloren.

Zum einem ist es quälend langsam und zum anderen ist es auch nicht wesentlich günstiger, als z.B. ein kleiner NUC.

----------

## musv

 *3PO wrote:*   

> Zum einem ist es quälend langsam und zum anderen ist es auch nicht wesentlich günstiger, als z.B. ein kleiner NUC.

 

Der Reiz ist ein anderer. Es ist mal was Anderes als nur x86-Architektur.

Meinen Beitrag hab ich ja mit dem Zyxel NSA326 begonnen. Ich hatte mir vor einigen Jahren den Vorgänger gekauft. Die originale Firmware, die da drauf lief, war ja ganz nett anzusehen, aber hat mir irgendwie nur einen Bruchteil der Funktionalität geliefert, die ich gern gehabt hätte. Außerdem war das viel zu sehr auf Windows zugeschnitten. 

Auf dem Vorgänger (NSA325) lief zuerst ein Arch. An Gentoo auf dem Ding traute ich mich noch nicht ran u.a. wegen des Cross-Compile-Desasters. Als mir das Teil abrauchte, kaufte ich mir den Nachfolger. Dummerweise war das 'ne andere Architektur. In einem anderen Forum hackten wir dann das Ding. Die Lernkurve war steil, der Lernprozess schmerzhaft. Aber Gentoo läuft, und es läuft gut auf dem Teil. 

Das Ergebnis:

24/7-Server, passiv gekühlt (hab den Lüfter rausgebaut), unter 10 Watt Stromaufnahme. Auf dem Ding läuft: NFS-Server, DHCP-/DNS-Server (zentraler Werbeblocker fürs Heimnetzwerk), Github, NZBGet, Pyload, DLNA-Server, Nginx mit Mediawiki, PHP-Admin und Kanboard. In Kürze kommt noch ein Bitcoin-Trading-Bot drauf. 

Da keine der Anwendungen wirklich CPU-Leistung braucht, ist das Ding für mich der optimale 24/7-Server. Klar könnte ich das auch leichter auf einem Intel-NUC realisieren. Aber es würde mir keine Vorteile bringen und mehr Strom benötigen.

----------

## ChrisJumper

Nebenbei: Man müsste doch so auch Gentoo für eine Smartwatch die ARM nutzt, kompiliert bekommen oder?

Mit einem winzigen Displaymanager/Bluetooth oder SSH, kann man da doch bestimmt was schickes zaubern.

Gerade was eine Reduktion der Komplexität betrifft ist mir das Ding an einigen stellen lieber als ein Smartphone. Zum Beispiel um Netzwerkinfomationen zu erhalten, Kurznachrichten oder um die Heimelektronik zu steuern.

Wollte mir zuerst noch so eine Smartwatch kaufen, aber nach Meltdown warte ich jetzt erst mal ab. Auch schien mir da das Linux-Wissen in dem Bereich relativ dünn. Ich fand nachdem ich eine Hardwere gefunden hatte nur ein oder zwei Webseiten wo man Pakete laden konnte und die waren dann vor einem Jahr aktualisiert wurden.

Was dann letztlich Android wieder in einem besseren Licht darstellte.

Letztlich kann man bei einem "normalen Linux-Kernel" aber viel genauer einstellen was man da will, als bei einem Android, bei dem Traiber oder CPU plötzlich nicht mehr ausreicht oder mit dem aktuellen Android klar kommen.

----------

## musv

 *ChrisJumper wrote:*   

> Nebenbei: Man müsste doch so auch Gentoo für eine Smartwatch die ARM nutzt, kompiliert bekommen oder?

 

Das Hauptproblem ist der Device Tree, über den die vergebaute Hardware beschrieben wird. Rückt das der Hardwarehersteller nicht raus, dann hast du eigentlich keine Chance, einen funktionierenden Kernel zu bauen. Und zusätzlich brauchst du natürlich noch die Treiber.

----------

