Kernel cross compiling?

[guennid]

Ich möchte einen vanilla-Kern für ein Stretch-32 bit-System auf einem Stretch-64 bit System kompilieren. Geht das? und was ist zu beachten? Ich habe einiges zu cross compiling angelesen, aber die dort zu findenden Beispiele sind wohl doch 'n paar Nummern größer als das, was mir da vorschwebt. Ich weiß auch nicht, ob ich dieses begriffliche Chaos, mit 32 bit,64 bit, i386, amd64, etc. zureichend verstanden habe. Ich sag's mal so: Im Handel würde wohl auf beiden Maschinen ein Windows vorkonfiguriert sein. Es ist nicht unbedingt nötig, das Kompilat der 64 bit Maschine zu erstellen, aber es würde dort doch um einiges schneller gehen - bilde ich mir ein.

Grüße, Günther

[rendegast]

Ich habe hier ein stretch amd64 (foreign i386), kernel / headers / dkms
(make, build-essential, fakeroot usw., das Build-Gelumpe).

Mit einem vanilla 4.18

Code: Alles auswählen

make i386_defconfig
# damit erstmal eine 32bit-.config
[make menuconfig]
# Anpassungen

Die erstellten Pakete von

Code: Alles auswählen

make bindeb-pkg ...
und
KBUILD_DEBARCH=i386 make bindeb-pkg ...

unterscheiden sich geringfügig.
(Einige vorkompilierte Module in scripts/kconfig/lxdialog/.
vmlinuz selbst, aber da sind es wohl nur Zeitstempel)

[guennid]

Danke für die Rückmeldung!

Ich hab's gestern abend mal angetestet.
Eine config existiert ja aus dem laufenden stretch auf der Zielmaschine. Ein make defconfig kann ich mir dann doch sparen - richtig?

Wie sagt man make menuconfig, dass das Kompilat für ein 32 bit System sein soll?

Als erstes erscheint:

Code: Alles auswählen

[ ] 64-bit kernel

ok, wird nicht aktiviert, bleibt so - richtig? Ist das alles?

Ich kompiliere via make-kpkg. Gesonderte headers und anderes benötige ich nicht, jedenfalls nicht auf dieser Zielmaschine.

Ich erinnere mittlerweile, dass ich cross compiling vor ca. zwei Jahren schon einmal angefragt hatte (1). Auf damals gepostete Tipps hin ist aber gerade mein Versuch mit make-kpkg --arch i386 --cross-compile --revision=[Nummer] linux-image gescheitert

(1) viewtopic.php?f=33&t=161689&hilit=make+kpkg

Grüße, Günther

[rendegast]

Wie sagt man make menuconfig, dass das Kompilat für ein 32 bit System sein soll?

Als erstes erscheint:
[ ] 64-bit kernel

ok, wird nicht aktiviert, bleibt so - richtig? Ist das alles?

Das scheint den Unterschied zu machen
64bit/cpu_x84-64-generic <-> 32bit/cpu_pentium-pro,
und leider auch viele weitere, nicht direkt nachvollziehbare Änderungen.




Viele gesetzte Optionen ('make menuconfig' als Ausgang bei laufendem debian-kernel) überleben nicht ein De-/Reaktivieren der Option.

config 'make x86_64_defconfig' ist nach Deaktivieren der 64bit-Option nicht! gleich der 'make i386_defconfig'-config,
und nach Reaktivieren der Option wird das Ergebnis nicht! wieder zur 'make x86_64_defconfig'-config.

Das ist hier aber nicht relevant, da ja von einer gegebenen 32bit-config ausgegangen wird.



Nach 'man make-kpkg' ist bei vorgegebener config wohl kein '--arch ...' nötig.
Ich würde bei vorgegebener config aber zumindest einmal 'make menuconfig' aufrufen (ohne Änderungen auszuführen),
damit die config gegebenenfalls "valide" wird.

[guennid]

Ich würde bei vorgegebener config aber zumindest einmal 'make menuconfig' aufrufen

Gemacht. Außerdem --arch... weggelassen. Es läuft dann zunächst sowas wie make oldconfig. Da das nur ein Test war, habe ich besinnungslos alle Vorschläge durchgewunken, trotzdem Abbruch der Kompilation. Ich schließe mich hikaru an: Cross comiling zu umständlich und wohl auch fehlerträchtig. Ich kompiliere weiterhin auf Systemen für die Kern auch vorgesehen ist.

Trotzdem: Danke für die Hilfe!

Grüße, Günther

[hikaru]

Ich schließe mich hikaru an: Cross comiling zu umständlich und wohl auch fehlerträchtig. Ich kompiliere weiterhin auf Systemen für die Kern auch vorgesehen ist.

Nachdem nun hier mein Name gefallen ist, obwohl ich mich eigentlich wegen Ahnungslosigkeit raushalten wollte, vielleicht doch noch ein Kompromissvorschlag von mir:
Virtualisiere eine i686-Umgebung auf deinem amd64-System und compiliere darin deinen Kernel!

Das kann von einem simplen chroot bis zu einer vollständigen VM Vieles sein. Der springende Punkt ist, dass i686 eine Untermenge von amd64 ist, was bedeutet, dass du ohne CPU-fressende Emulation auskommst. HDD- und RAM-Bedarf sind im Vergleich zur direkten Compilierung auf einer i686-Maschine etwas höher, aber wenn das kein grundsätzliches Problem ist sollte der Weg trotzdem deutlich schneller sein.

[guennid]

Nachdem nun hier mein Name gefallen ist ...

Ich bin eben nachtragend! (siehe verlinkten Thread)

Danke für den Tipp! Aber besonders wichtig war es mir nicht. Die i386-Maschine, auf der der Kern laufen soll und auf der zuerst kompiliert wurde, war halt durchs Kompilieren lahmgelegt, genauer: konnte wähenddessen nicht rebootet werden. Ich habe noch eine andere (das T42, das ich ebenfalls mit deiner Hilfe ausgemustert habe und dessen Stiefmütterchendasein ich jetzt etwas aufpeppe).

Grüße, Günther

[hikaru]

Dein T430 dürfte selbst mit chroot/VM deutlich schneller den Kernel compilieren, als irgendeine deiner i686-Maschinen.

[guennid]

Ich könnt's ja auch nachts auf 'nem x21 laufen lassen.

Übrigens: das T430 finde ich richtig klasse!

Grüße, Günther

[rendegast]

trotzdem Abbruch der Kompilation.

Das lag imo nicht am cross-compiling (was speziell beim linux-Kernel eine einfache Angelegenheit ist).
Ein Grund könnte ein fehlendes Paket(e) sein. Kandidaten wären
libssl-dev
libelf-dev
pkg-config
(Hinweise darauf kommen erst beim config / Kompilieren)

Ein weiterer Hint bei von einem laufenden debian-Kernel ausgehenden 'make menuconfig' wäre das übernommene
CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/test-signing-certs.pem"
(Auch da käme ein Hinweis)
Abhilfe wäre entweder, den Schlüssel leer zu setzen,
oder die entsprechende Datei von Ben Hutchings beizubringen, zBsp.
https://people.debian.org/~benh/packages/secure-boot/

Aua, da liegt das cert nicht mehr, meine Version ist (md5)

Code: Alles auswählen

-rw-r--r-- 1 root root 1233 Nov  8  2016 benh@debian.org.cert.pem
4d81f7b3d0bf9619d861d13d8cf91a11  benh@debian.org.cert.pem

 ('openssl x509 -i ... -text' ergibt "Serial Number: ae:49:40:05:81:47:9d:a2, von 4.4.2016 - 4.5.2016")

Es findet sich aktualisiertes
https://salsa.debian.org/kernel-team/li ... bian/certs
gerade eine test-signing-certs.pem

Code: Alles auswählen

...
        Serial Number:
            e9:87:75:b8:9e:64:51:f4
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = secure-boot-test-key-lfaraone
        Validity
            Not Before: Apr  8 09:46:38 2018 GMT
            Not After : May  8 09:46:38 2018 GMT
...

, es findet sich in der History eine debian-uefi-ca.pem mit "Validity: Aug 2016 - Aug 2046".