[Fli4l_dev] Problem mit Netzwerkkartentreiber (Mellanox): [Gelöst]

[Alexander Dahl]

Moin,

B. Sprenger schrieb Freitag, 14. August 2020, 09:42 (CEST):
> Hallo zusammen,
>> 
>>> Aber: Ein kosmetischer Fehler:?
>>>
>>> fli4l 4.0.0-r58978 # cat /var/run/netdrivers.conf
>>> eth0=e1000
>>> eth1=e1000
>>> eth2=e1000e
>>> eth3=e1000e
>>> fli4l 4.0.0-r58978 #
>> 
>> Huch, die Datei hab ich noch nie gesehen. Da fehlt jetzt bei Dir eth4,
>> richtig?
>> 
>>>
>>> Auf der Supportseite des Routers gibt es ja den Reiter
>>> "Zuordnung der Netzwerkgeräte zu Kernelmodulnamen"
>> 
>> Das Ding hier?
>> 
>> http://<hostname>/admin/help_support.cgi?section=show&action=ZuordnungderNetzwerkgertezuKernelmodulnamen
>
> Bei mir ist das
> http://[IPAdresse]/admin/help_support.cgi
>> 
>>> Dort fehlt der Mellanox-Treiber.
>> 
>> Das ist genau der selbe Inhalt der o.g. Datei. Bin nicht sicher wofür
>> das benutzt wird.
>
> Ich vermute zur Anzeige der Support-Information?
> Für mich ist das immer hilfreich, wenn es irgendwo klemmt.
> Oder aber dieser Eintrag bei den Experimenten mit Netzwerkkarten.
> Für einen Linux-Spezialisten ist das natürlich kein Thema, aber für mich 
> einfacher als mit Konsole-Befehlen zu hantieren.

Na ich schau mir das nochmal in Ruhe an, scheint aber soweit nicht
kritisch zu sein erstmal.

>> 
>
>>> In der base.txt habe ich derzeit folgende Einträge:
>>> NET_DRV[]='mlx4_core'
>>> und
>>> NET_DRV[]='mlx4_en'
>>>
>>> Benötige ich hier beide? Oder reicht der mlx4_core?
>> 
>> Probier's aus. ;-)
> Ja, werde ich machen.
> Das wird allerdings etwas dauern.
> Ich hatte noch ein paar kosmetische Änderungen an der base.txt 
> vorgenommen und jetzt läuft der Build-Prozess nicht mehr durch.
>
> Nur der Vollständigkiet halber:
>==================================================================
> opt/circuits.txt:67: cannot access
>      'usr/share/circuits/proto/ipv6.disabled' of type 'local file
>      system object'
> opt/circuits.txt:69: cannot access 'etc/ppp/ip-up900.user' of type
>      'local file system object'
> check/base.ext:147: cannot access 'etc/ppp/prefix-up050.circuits-net'
>                  of type 'local file system object'
> check/base.ext:148: cannot access
>                  'etc/ppp/prefix-down950.circuits-net' of type 'local
>                  file system object'
> Warning: es wurde mindestens ein file in abhängigkeit von
>           opt_template kopiert
>==================================================================
>
> Es waren wirklich nur Änderungen an der base (MAC-Adresse  hinzugefügt)
> Ich habe die Änderungen natürlich rückgängig gemacht, der Fehler bleibt 
> aber.
>
> Ich muss also die Dateien nochmal runterladen und sauber zusammenpacken.

Ja so sieht das aus. Du schriebst ja, Du hättest da Pakete aus CI
genommen, also direkt aus trunk und das kann zwischendurch auch mal
kaputt sein.

> Das wird aber vor Ende nächster oder sogar übernächster Woche nix.
>
> Macht aber nix, es läuft ja.
>
>
>> 
>>> Nach meinem Verständnis müsste der mlx_en doch automatisch nachgeladen
>>> werden?
>> 
>> Nein, es ist umgekehrt.
>> 
>>> Ich kann das natürlich auch ausprobieren, aber mit dem Neustart des
>>> Routers ist ja immer Ausfall der Telefonie und anderer Dienste verbunden.
>> 
>> Achso, na dann trage da bitte mal nur 'mlx4_en' ein, das reicht, der
>> 'mlx4_core' wird automatisch nachgeladen.
>> 
>
> Ich werde es testen und mich wieder melden.

Okay gut. Gerne auch direkt im Ticket kommentieren, ob das jetzt so
passt.

> Noch eine Frage
> Im weekly tarball ist der Patch noch nicht drin?

Doch, ist drin. Im Weekly von heute sollte das schon funktionieren
jetzt.

> Sorry falls die Frage dämlich ist, aber mir ist der Unterschied zwischen 
> trunk und testing nicht ganz klar.

Die Entwicklung läuft in verschiedenen Zweigen parallel ab. Bei fli4l
heißen die Zweige trunk, testing und stable. Änderungen am Code werden
nur im trunk gemacht, das ist sozusagen der Hauptentwicklungszweig, das
wo aktiv gearbeitet wird. Da man Änderungen üblicherweise in mehrere
Commits aufteilt und sich die Ergebnisse unserer automatischen
Build-Infrastruktur auch auf mehrere Commits aufteilen, können wir nicht
für jede einzelne Revision garantieren, dass das auch installierbar und
zusammen lauffähig ist. 

Wenn der Entwickler jedenfalls so weit durch ist mit den Änderungen am
gerade konkreten Problem, dann werden diese Änderungen gesammelt in den
Zweig testing übertragen. Der sollte zumindest vom Code her eigentlich
immer direkt nutzbar zur Installation auf der Hardware sein, sobald nach
dem Zusammenführen bzw. Mergen der Zweige die CI die Binaries neu
gebaut hat.

Ist das alles genug getestet, wird der Kram dann von testing nach stable
übertragen und daraus können dann Pakete für ein Release erstellt
werden.

Die verschiedenen Tarballs von https://web.nettworks.org/fli4l/tarballs/
werden nun aus diesen unterschiedlichen Zweigen gebaut. Direkt nach
Änderung in trunk vom CI, da kann es ggf. schwierig sein, dass alles
zusammenpasst. Und dann wird einmal täglich noch der Stand aus trunk als
sog. "daily tarball" gebaut und einmal wöchentlich aus testing der
weekly tarball.

Für Nutzer:innen, die nicht direkt bleeding edge aus trunk ihren Router
laufen lassen wollen, ist testing bzw. weekly zu empfehlen. Dann dauern
die Test-Iterationen ggf. etwas länger, dafür ist das aber eine Version,
wo wir drauf achten, da nix groß kaputt zu machen und die man guten
Gewissens einsetzen kann.

HTH & Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6