[Eisfair] Update Problem NetworkManager

[Martin Faderbauer]

Am 11.12.2025 um 20:39 schrieb Marcus Röckrath:
> Hallo Martin,
> 
> Martin Faderbauer wrote:
> 
>> ich habe heute den Fehler gefunden. Der für das Timeout verantwortlich
>> war.
>>
>> ich hatte nämlich festgestellt das der Server für ein Update nicht ins
>> Internet gekommen ist obwohl Mail Und WEB funktioniert haben.
>>
>>> kommentiere bitte in
>>>
>>> /var/install/include/nm-get-route
>>>
>>> die Zeilen
>>>
>>> 20
>>> 21
>>> 23
>>>
>>> service restart network.config
>>>
>>> hilft das?
>>>
>> diese Veränderung hat das erstellen des Gateways verhindert.
>> das habe ich rückgängig gemacht und nach einen Reboot ist der Eis ins
>> Internet gekommen.
> 
> Die hast das if-Konstrukt wieder reaktiviert?
Ja
> 
>> dann hatte ich aber das Problem mit Samba und SSH wieder.
>> meine Vermutung war das es an der Routen liegen könnte da ja genau das
>> nm-get-route Skript die Routen erzeugt.
> 
> Und nun wieder, wie von Holger vorgeschlagen, rausgeschmissen?
> 
nein gelassen
>> zum testen habe ich in der Baseconfig IP_Route_N auf 0 gesetzt und somit
>> die eingetragenen Routen deaktiviert. und siehe da alles funktioniert
>> ohne Timeout und gewohnt schnell.

das Hat geholfen > Baseconfig IP_Route_N auf 0
>
> Deine Routen hatte ich noch nie so richtig verstanden, weil es IMHO der
> Kernel wissen muss, das 30er-Ziele über die erste Karte gehen müssen.
> 
>>
>> die config der 1 karte
>> [ipv4]
>> address1=172.30.1.12/24
>> method=manual
> 
> Also kein Gateway in den Settings der ersten Karte?
> 
>> die config der 2 Karte
>> [ipv4]
>> address1=172.30.101.12/24
>> gateway=172.30.101.1
>> dns-search=fmit.local;
>> dns=127.0.0.1;172.30.1.11;
>> method=manual
> 
> Wenn in der ersten Karte auch ein gateway steht, gibt Konfusion - richtig?
> 
> Das würde für mich nun bedeuten, dass Gateway nur einmal gesetzt wird, und
> zwar bei der Karte, bei der das Gateway im Netzwerk liegt.
> 
> Wir müssen das klar bekommen, denn das ist in der Konfigurationsgeschichte
> noch nicht so.
> 
>> fmsrv03 # ip r
>> default via 172.30.101.1 dev enx000c299f719a proto static metric 101
>> 172.30.1.0/24 dev enx000c299f7190 proto kernel scope link src
>> 172.30.1.12 metric 100
>> 172.30.101.0/24 dev enx000c299f719a proto kernel scope link src
>> 172.30.101.12 metric 101
> 
> Das sieht so für mich nun deutlich richtiger aus.
> 
>> somit wäre ein Hinweis, zum überdenken der eingetragenen Routen beim
>> Update zum Networkmanager hilfreich.
> 
> Wenn die bislang schon lange so in der Base stehenden Routen nun mit
> NetworkManager nicht ideal sind, waren sie es grundsätzlich vorher auch
> schon nicht. Der Unterschied ergäbe sich dann dadurch, wie die Einstellungen
> in der Konfiguration in route-Befehle umgesetzt wurden.
> 
> Daher wäre es mir ja auch so wichtig, aus dem Backup vor dem NetworkManager-
> Update mal die Ausgaben von
> 
> ip addr
> ip r
das ist die Ausgabe vor dem Update hatte ich mir in einer TXT Datei 
gesichert ganz zurück kann ich leider nicht da ich da Mails und Daten 
verlieren würde und eine Kopie der VM passt nicht auf die Festplatten. 
sind 1,8TB

fmsrv03 # ip r
default via 172.30.101.1 dev enx000c299f719a
172.30.1.0/24 dev enx000c299f7190 proto kernel scope link src 172.30.1.12
172.30.101.0/24 dev enx000c299f719a proto kernel scope link src
172.30.101.12
fmsrv03 #

> 
> zu sehen.
> 
> Was sich geändert hat, ist der Umgang mit dem Gateway. Da ist ein Check
> reingekommen, der so vorher nicht existierte, habe aber hier den alten Code
> nicht mehr lokal vorrätig.
> 
>> die eingetragenen Routen waren bei der Vorigen Version ohne
>> Networkmanager notwendig damit es funktioniere. jetzt anscheinend nicht
>> mehr und sorgen dafür für Fehler wenn sie stehen bleiben.
> 
> Fragt sich, wie richtig in den Fällen mit zwei Netzwerkkarten die
> Netzwerkkonfiguration war.
die gesicherte Ausgabe von oben schaut auch nicht so falsch aus 
jedenfalls sind keine doppelten Routen drinnen wie nach dem Update
von dem Skript erzeugt wurden.