Gluon: Build schlägt nach den letzten OpenWrt-Bumps fehl

Erstellt am 14. Aug. 2020  ·  4Kommentare  ·  Quelle: freifunk-gluon/gluon

Was ist das Problem?

nach den jüngsten OpenWrt-Bumps scheitert der Build von Gluon-Zweigen basierend auf OpenWrt 19.07 mit "Error 2", angehängt ist die entsprechende Log-Ausgabe
20200813_gluon_openwrt1907_openvswitch_wireguard_build_error.txt

Builds basierend auf OpenWrt 19.07 Commit 73fecd36bfd2b9f92a2a20f38bdb73b4433dec3e funktionieren, Builds mit späteren Commits schlagen bis heute fehl.

das Problem könnte sein, dass sowohl openvswitch als auch wireguard versuchen, einige Kernel-prandom_u32*-Funktionen als Backports zu definieren
https://github.com/openvswitch/ovs/blob/branch-2.11/datapath/linux/compat/include/linux/random.h#L11
https://git.zx2c4.com/wireguard-linux-compat/tree/src/compat/compat.h#n243

Gluon-Version:
Zweige v2020.1.x , v2020.2.x, Master

Standortkonfiguration:
irrelevant, passiert auch bei anderen Site-Konfigurationen

Problemumgehung
im Anhang finden Sie einen Patch, der den Build des openvswitch-Pakets deaktiviert, was zu einem funktionierenden Gluon-Build führt.
das gleiche Verhalten wird erwartet - aber ungetestet - beim Deaktivieren von Wireguard-Builds.
0001-disable-build-of-openvswitch.patch.txt

vielleicht können die beiden Pakete so behoben werden, dass sie nicht mehr in Konflikt geraten, @NeoRaider möchte sich das Problem ansehen

bug blocker
Quelle
picture rotanid

Hilfreichster Kommentar

Ich kann dies nicht reproduzieren, bitte fügen Sie ein vollständiges Protokoll bei, das auch die Konfigurationsschritte dieser Pakete enthält.

picture NeoRaider am 14. Aug. 2020
😄2

Alle 4 Kommentare

Ich kann dies nicht reproduzieren, bitte fügen Sie ein vollständiges Protokoll bei, das auch die Konfigurationsschritte dieser Pakete enthält.

NeoRaider picture NeoRaider am 14. Aug. 2020
😄2

Hast du auch lokale Patches? Die Zweige v2020.1.x , v2020.2.x und master beziehen sich alle auf eine OpenWrt-Version, die sich derzeit auf Kernel 4.14.187 befindet. Ihr Log zeigt 4.14.193 an, also muss es sich um eine neuere Version 19.07 handeln.

NeoRaider picture NeoRaider am 14. Aug. 2020

Hast du auch lokale Patches? Die Zweige v2020.1.x , v2020.2.x und master beziehen sich alle auf eine OpenWrt-Version, die sich derzeit auf Kernel 4.14.187 befindet. Ihr Log zeigt 4.14.193 an, also muss es sich um eine neuere Version 19.07 handeln.

Sicher, ich habe einen weiteren Stoß gemacht, um zu versuchen, ob dies das Problem behebt. ich werde mit dem älteren zustand nicht mehr bauen, ich glaube ihr könnt mir und zustand fehlgeschlagen ist, den man aktuell auf github findet.

Ich habe einfach nicht auf meinen Bauch gedrückt, weil es die Dinge nicht repariert hat und daher ist es nicht wichtig

rotanid picture rotanid am 14. Aug. 2020
  • Der Bruch mit Kernel 4.14.187 wurde mit dem neuesten Update für openwrt/packages behoben, das nicht versehentlich auf v2020.1.x und v2020.2.x zurückportiert wurde
  • OVS bricht wieder mit Kernel 4.14.193 ab. Dies ist im OVS-Upstream behoben, aber noch nicht in openwrt/packages. Wir können mit unserem nächsten OpenWrt-Bump warten, bis dies behoben ist, um den Bruch zu vermeiden.
NeoRaider picture NeoRaider am 14. Aug. 2020
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

rotanid picture rotanid  ·  5Kommentare
HACKER-3000 picture HACKER-3000  ·  5Kommentare
jenell95 picture jenell95  ·  3Kommentare
A-Kasper picture A-Kasper  ·  4Kommentare
lcb01a picture lcb01a  ·  3Kommentare