Hallo Thomas,
Ja, es sollte so funktionieren, kann ich gerade nicht testen.
default bedeutet einfach das default gateway, und wenn es nicht verschiedene Gateway pro Netzwerksegment gibt, kann man es vereinfachen.
Das gilt aber nur ab Ubuntu 22.04, in Ubuntu 18.04 ist default nicht erkannt im Netplan.
Ich warte aber auf die Bestätigung von @kstenzel
Gruß
Arnaud
Hallo Arnaud,
bien, dann fixen wir das mal.
Das Paket-Upgrade von linuxmuster-prepare passt die netplan yaml an.
VG, Thomas
Hallo Thomas,
ich hab gestern linbo 4.1.32 installiert. Heute booten meine Windowskisten nicht mehr.
BlueScreen … nicht so schlimm, hab nicht mehr viele davon.
Grund ist der Regpatcher (was sonst …).
Ich habe den Vorlagenregpatch so angepaßt, dass er bei mir wieder funktioniert.
hier kommen nun drei Regpatches. Nur der letzte (der ohne „CurrentControlSet“) funktioniert.
Windows Registry Editor Version 5.00
; linuxmuster.net 7
; patches hostname, to be applied after every image sync
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
; add your custom registry patches belowWindows Registry Editor Version 5.00
; linuxmuster.net 7
; thomas@linuxmuster.net
; 20230510
; patches hostname, to be applied after every image sync
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
; add your custom registry patches belowWindows Registry Editor Version 5.00
; linuxmuster.net 7
; thomas@linuxmuster.net
; 20230510
; patches hostname, to be applied after every image sync
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ActiveComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName\]
"ComputerName"="{$HostName$}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\]
"Hostname"="{$HostName$}"
"NV Hostname"="{$HostName$}"
; add your custom registry patches belowRechner bootet wieder ohne BlueScreen und Anmelden am Client funktioniert.
LG
Holger
Hallo @thomas ,
nicht cool!!:
Fixing default route in /etc/netplan/01-netcfg.yaml.
sed: -e Ausdruck #1, Zeichen 16: Nicht beendeter »s«-Befehl
dpkg: Fehler beim Bearbeiten des Paketes linuxmuster-prepare (--configure):
»installiertes linuxmuster-prepare-Skript des Paketes post-installation«-Unterprozess gab
den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
linuxmuster-prepare
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
danach ist die .yaml leer und die Netzwerkkonfig kaputt…da passt was nicht! Hier meine original 01-netcfg.yaml:
network:
ethernets:
eth0:
addresses:
- 10.16.1.1/24
dhcp4: false
dhcp6: false
gateway4: 10.16.1.254
nameservers:
addresses:
- 10.16.1.1
- 10.16.1.254
search:
- linuxmuster.windeck-gymnasium.de
routes:
- to: 10.16.1.0/24
via: 10.16.1.253
- to: 10.30.10.0/24
via: 10.16.1.253
- to: 10.20.10.0/24
via: 10.16.1.253
- to: 10.20.20.0/24
via: 10.16.1.253
- to: 10.20.30.0/24
via: 10.16.1.253
- to: 10.20.29.0/24
via: 10.16.1.253
- to: 10.20.41.0/24
via: 10.16.1.253
- to: 10.20.40.0/24
via: 10.16.1.253
- to: 10.20.103.0/24
via: 10.16.1.253
- to: 10.20.104.0/24
via: 10.16.1.253
- to: 10.20.105.0/24
via: 10.16.1.253
- to: 10.20.99.0/24
via: 10.16.1.253
- to: 10.20.50.0/24
via: 10.16.1.253
version: 2
VG Dominik
Hi @thomas die zweite,
mit dem neuen Linbo kommt ein Problem mit dem laden des r8168 Moduls:
Kernel command line: BOOT_IMAGE=/linbo64 quiet splash nomodeset dhcpretry=20 forcegrub warmstart=no loadmodules=r8168 localboot
Unknown kernel command line parameters "splash forcegrub localboot BOOT_IMAGE=/linbo64 dhcpretry=20 warmstart=no loadmodules=r8168", will be passed to user space.
loadmodules=r8168
module r8168: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time
Das Modul wird nicht geladen, daher sind die Durchsatzraten der Clients wieder mies. Am Client sieht das dann so aus:
VG Dominik
Hi Dominik,
Danke für die Meldung.
Wenn du manuel alle
to: ...
via: 10.16.1.253
durch einen einzigen
to: default
via: 10.16.1.253
funktioniert es wieder ?
Gruß
Arnaud
Hallo Dominik,
danke fürs Testen. Sieht so aus, dass ip route show wohl je nach Netzwerkkonfiguration unterschiedliche Ausgaben macht und daher im Skript manchmal die Bestimmung des Netzwerkinterfaces fehlschlägt. Muss das noch abfangen. Stay tuned.
VG, Thomas
Moingiorno!
Es gibt jetzt linuxmuster-prepare 7.2.4:
VG, Thomas
Moingiorno!
linuxmuster-linbo7 4.1.33 ist verfügbar:
@foer @baumhof
Das sollte die von euch gemeldeten Probleme lösen. Falls CurrentControlSet in einer Reg-Datei verwendet wird, ändert der Regpatcher das jetzt wieder in ControlSet001.
VG, Thomas
Hallo Thomas,
… na: da haben deine zwei Betatester ja mal wieder ganze Arbeit geleistet: gleich in die BUGs gelaufen 
Tausend Dank für das schnelle fixen.
Ich spiel das neue linbo Heute Nacht ein und starte die Rechner Morgen mal (mit der „falschen“ regpatchdatei) um das zu testen.
LG
Holger
Hi @Arnaud und @thomas und @ alle VORSICHT mit dem UPDATE!!!,
also NEIN! das funktioniert nicht! Ich habe jetzt 10 Stunden gebraucht um herauszufinden, warum mein gesamtes Netzwerk gestern komplett ausgefallen ist. Da das ziemlich schlagartig um 13 Uhr war dachte ich an einen Hardwaredefekt. Ich kam nicht auf das Update, weil ich das ja am Morgen gemacht hatte.
Nach einem Rollback der OPnsense und des Servers lief es dann aber direkt wieder!? Das war eigentlich eine Verzweiflungstat, weil ich einfach keine defekte Hardware gefunden habe und nicht mehr weiter wusste. Ich habe dann das Update nochmal gemacht nur um sicher zu gehen und auch dieses Mal ist das Netzwerk Stück für Stück ausgefallen und war nach ca. 90 Minuten komplett offline. Es ist so, dass das entfernen der einzelnen Routen für die Subnets beim Server irgendetwas beim Routing zwischen Server - OpnSense - L3 Router komplett schief laufen lässt!
Der Default Eintrag darf sich nur auf das Servernetz beziehen! Die einzelnen Routen für die Subnets müssen erhalten bleiben!
Bei mir also:
routes:
- to: default
via: 10.16.1.253
- to: 10.30.10.0/24
via: 10.16.1.253
- to: 10.20.10.0/24
via: 10.16.1.253
- to: 10.20.20.0/24
via: 10.16.1.253
- to: 10.20.30.0/24
via: 10.16.1.253
- to: 10.20.29.0/24
via: 10.16.1.253
- to: 10.20.41.0/24
via: 10.16.1.253
- to: 10.20.40.0/24
via: 10.16.1.253
- to: 10.20.103.0/24
via: 10.16.1.253
- to: 10.20.104.0/24
via: 10.16.1.253
- to: 10.20.105.0/24
via: 10.16.1.253
- to: 10.20.99.0/24
via: 10.16.1.253
- to: 10.20.50.0/24
via: 10.16.1.253
Das hat keinen Spaß gemacht!
VG Dominik
Hallo,
bei mir habe ich keien Probleme feststellen können.
Meine /etc/netplan/01-netcfg.yaml
auf dem lmn 7.2 server sieht so aus
network:
ethernets:
eth0:
addresses:
- 10.16.1.1/24
dhcp4: false
dhcp6: false
gateway4: 10.16.1.254
nameservers:
addresses:
- 10.16.1.1
- 10.16.1.254
search:
- bzpf.lan
routes:
- to: 10.16.1.0/24
via: 10.16.1.253
- to: 10.17.100.0/24
via: 10.16.1.253
- to: 10.17.101.0/24
via: 10.16.1.253
- to: 10.17.102.0/24
via: 10.16.1.253
- to: 10.17.103.0/24
via: 10.16.1.253
- to: 10.17.1.0/24
via: 10.16.1.253
- to: 10.17.145.0/24
via: 10.16.1.253
- to: 10.17.154.0/24
via: 10.16.1.253
- to: 10.17.155.0/24
via: 10.16.1.253
- to: 10.17.27.0/24
via: 10.16.1.253
- to: 10.17.61.0/24
via: 10.16.1.253
- to: 10.18.126.0/24
via: 10.16.1.253
- to: 10.17.15.0/24
via: 10.16.1.253
version: 2
… wobei: ich hab wohl zu früh upgedatet: bei mir steht
linuxmuster-prepare mit der Version 7.2.2-0 als installiert drin und es
gibt eine neuere (die ich jetzt noch nicht installiert habe).
Würde denn ein einfaches zurückkopieren der 01-netcfg.yaml und ein
reboot das Problem beheben?
LG
Holger
Hallo Holger,
die alte Konfiguration funktioniert zwar weiter, netplan meckert aber dann bei jedem Start, dass gateway4 deprecated ist. Das neue linuxmuster-prepare-Paket aktualisiert die Konfiguration und sichert die alte. Kein Neustart notwendig.
Gleichzeitig kommt ein aktualisiertes linuxmuster-base7-Paket, das ein angepasstes linuxmuster-import-devices enthält. Das trägt keine Subnetzrouten mehr in netplan ein, da mit der neuen netplan.yml nicht mehr notwendig. Also bitte alle Pakete updaten.
VG, Thomas
Hallo @thomas ,
hast du gelesen was ich geschrieben habe!
Ich habe meinen Post nochmal ergänzt. Ich würde wirklich vom Update abraten…zumindest mein Netz geht dabei kaputt.
VG Dominik
Hi Holger,
bei mir hat das nicht gereicht, weil irgendwas auch mit der Opnsense schräg war…ich musste beide Maschinen wieder aus dem Backup herstellen…
… ich vermute, dass es in diesem Zusammenhang entscheidend ist, ob der Befehl linuxmuster-import-subnets sauber durchläuft, da dieser Befehl doch auf der OPNSense die entsprechenden Routen anlegt, oder?! 
Hallo Dominik,
sorry für die Unannehmlichkeiten. Auf meinem Produktivsystem hat das mit der neuen netplan.yml funktioniert. Aber egal. Ich nehme die Änderung wieder zurück und stelle den alten Stand wieder her.
linuxmuster-prepare 7.2.5 und linuxmuster-base7 7.2.0-rc9 sind online und funktionieren wieder wie zuvor.
VG, Thomas
Hi Thomas, (@thomas )
danke? Aber der Weißheit letzter Schluss kann das nicht sein…die Netplanconfig sollte ja schon up to date sein. Ich vermute Folgendes: Mein StandartGateway ist für den Server ist nicht der L3 Router (10.16.1.253) sondern die OPnsense (10.16.1.254). So war das immer. Ist übrigens oben bei Holger auch so (s. oben). Nach dem Update ist der Eintrag für das Gateway weg und es steht als default jetzt der L3 Router drin. Müsste da eben nicht die OPNSense stehen und dann für alle Subnetze die Routen…etwa so:
Habe jetzt gerade etwas Schiss das live auszuprobieren…aber so sollte es doch richtig sein oder?
VG
Dominik
Hi Thomas,
kein Ding…ist eine Beta…Adrenalin gehört dazu🤪.
Dir vielen Dank für die viele Arbeit!
LG Dominik
Hallo Dominik,
Und das ist die Krux. In einem System mit Subnetzen ist nach meinem Verständnis basierend auf der Vorarbeit von Andreas Grupp immer der L3-Switch das Defaultgateway. Ist das nicht auch so dokumentiert? Warum macht ihr das anders? Ich verstehe es nicht.
VG, Thomas