arm64 changeroot mit amd64?

3PO · Posted: Fri Jan 19, 2018 10:27 pm Post subject: arm64 changeroot mit amd64?

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 · Veteran Joined: 09 Mar 2006 Posts: 1924 Location: Schweiz

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.

_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

3PO · Posted: Sat Jan 20, 2018 8:56 am Post subject:

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

ChrisJumper · Advocate Joined: 12 Mar 2005 Posts: 2390 Location: Germany

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 · Posted: Sat Jan 20, 2018 7:21 pm Post subject:

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.

schmidicom · Veteran Joined: 09 Mar 2006 Posts: 1924 Location: Schweiz

3PO · Posted: Tue Jan 23, 2018 9:50 am Post subject:

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 · Posted: Thu Jan 25, 2018 9:30 am Post subject:

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 · Advocate Joined: 01 Dec 2002 Posts: 3337 Location: de

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...
/etc/fstab:

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):

/etc/portage/make.conf:

############### 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:
Code:

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:
/etc/distcc/hosts:

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:
/usr/local/bin/xmerge:

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 · Posted: Sat Jan 27, 2018 1:42 pm Post subject:

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 · Advocate Joined: 01 Dec 2002 Posts: 3337 Location: de

ChrisJumper · Advocate Joined: 12 Mar 2005 Posts: 2390 Location: Germany

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 · Advocate Joined: 01 Dec 2002 Posts: 3337 Location: de