Netzwerkeinstellungen nach Update teilweise verloren

[PauleFoul]

Hallo zusammen,

mir ist aufgefallen, das gewisse Netzwerkeinstellungen im yocto nach einen Update nicht mehr vorhanden bzw. nicht wieder hergestellt werden.

Ersten ist nach dem Update DHCP immer AN obwohl es vorher AUS war,
zweitens werden Änderungen des Netzwerknamens nicht übernommen hd51 anstatt hd51-buero.

Wäre schön wenn sich das mal jemand anschauen könnte ;-)

Vor dem Update:

screenshot01.png

Nach dem Update:

screenshot02.png

[flk]

/etc/hostname und /etc/network/interfaces werden aber normalerweise schon in die Sicherung geschrieben.

Ich habe das eben mal gestestet ... bei mir waren Änderungen nach dem Flashen noch vorhanden.

Ich würde folgendes probieren:
Zuerst prüfen, ob /etc/hostname und /etc/network/interfaces die passenden Werte enthalten und dann in der telnet Session:
cd /etc
git add network/interfaces
git add hostname
etckeeper commit

[PauleFoul]

etc/hostname

Code: Alles auswählen

hd51-buero

/etc/network/interfaces

Code: Alles auswählen

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
	address 192.168.1.111
	broadcast 192.168.1.255
	gateway 192.168.1.1
	netmask 255.255.255.0

Code: Alles auswählen

 __  __         __         ___       __
 \ \/ /__  ____/ /____    / _ \___  / /____ __
  \  / _ \/ __/ __/ _ \  / ___/ _ \/  ´_/ // /
  /_/\___/\__/\__/\___/ /_/   \___/_/\_\\_, /
                                       /___/

tuxbox-neutrino 3.0.0 hd51-buero /dev/pts/0

hd51-buero login: root
Password:
➜  ~ cd /etc
➜  /etc git:(master) ✗ git add network/interfaces
➜  /etc git:(master) ✗ git add hostname
➜  /etc git:(master) ✗ etckeeper commit
hint: Waiting for your editor to close the file...
  GNU nano 4.4                /etc/.git/COMMIT_EDITMSG
 1
 2 # Please enter the commit message for your changes. Lines starting
 3 # with '#' will be ignored, and an empty message aborts the commit.
 4 #
 5 # On branch master
 6 # Changes to be committed:
 7 #       modified:   hostname
 8 #       modified:   neutrino/config/:empty:.ccache
 9 #
10

[flk]

Zumindest /etc/hostname war in deiner Sicherung noch nicht vorhanden.

Im nano Fenster dann einen Namen für den Commit angeben ... z.B.

add /etc/hostname


und dann mit
strg+x
y

abspeichern und hoffen, dass es nun beim nächsten Update übernommen wird

[PauleFoul]

Leider gehen nach den Anpassungen die angesprochenen Einstellungen immer noch verloren.
Getestet auf zwei verschiedenen Boxen...

Ich werde jetzt eine Box komplett neu aufsetzen/flashen und schauen ob es dann geht.

[Janus]

In grauer Vorzeit hatte ich auch mal ein "teilweise verloren" Problem mit meiner individuellen Vorgehensweise zur Konfiguration der Box im Wettstreit mt der Intelligenz der Firmware. (bin halt nicht voll linux-kompatibel)

Vielleicht hilft auch hier der damalige Tipp weiter:

Falls seltsames Verhalten auftritt kann man (vergleichbar mit dem Löschen des var Bereichs)

/media/sda1/service/partitionx

löschen. Dann ist die jeweilige Sicherung entfernt und man beginnt mit einem sauberen Image

Keine Ahnung, ob das mit aktuellem Stand noch zutriffft...

[flk]

Ich bin mir jetzt nicht sicher, ob das mit deinem Problem zu tun hat, aber seit dem Update auf den aktuellen yocto master Branch gibt es scheinbar tatsächlich ein Problem mit dem Netzwerk. Der systemd-networkd funkt dazwischen und stellt gleich eine dhcp Verbindung beim Boot her. Das darf nicht sein ... Neutrino möchte das Netzwerk über ifupdown konfiguriert haben. Bisher gab es im yocto kein Problem, weil per default keine conf für wired network integriert war. Das hat sich scheinbar geändert. Das muss ich mir die Tage mal genauer anschauen.

Außerdem habe ich den Verdacht, dass der neu in bitbake integrierte Hash Equivalenz Server noch irgendeinen Fehler drin hat. Ich habe momentan komisches Verhalten in neuen Images. Warte also mit weiteren Tests lieber noch, bis die Probleme behoben sind

[flk]

Jetzt kannst du mit dem aktuellen Image testen. Ich habe den networkd aus systemd ausgebaut. Das Netzwerk verhält sich wieder normal. Schade eigentlich .... systemd bringt das Netzwerk 4 Sekunden schneller hoch. Aber nur dhcp ist ja nun auch keine Lösung.

Wenn es dann immer noch nicht geht, hilft bestimmt das Löschen der alten Sicherung. Gesichert und wiederhergestellt wurde die Netzwerk Konfiguration bei mir auch zuvor schon. Die Einstellung für static ip war nur ohne Effekt.

[PauleFoul]

Ok, ich hatte es schon mit dem Image vom 05.10.2019 getestet und wie von Dir vermutet, damit keinen Erfolg.
Die alte Sicherung hatte ich vorher zur Sicherheit gelöscht.

Jetzt teste ich das ganze nochmal mit dem aktuellen Image.

[PauleFoul]

Also ich hab das Image (Stand 10.10.2019) nochmal komplett frisch über USB geflasht, vorher die Sicherungen im HDD/Service Ordner gelöscht
und die Einstellungen wieder händisch hergestellt. Leider waren dann nach dem nächsten Update wieder DHCP aktiv und der Hostname auf hd51
geändert.

[flk]

Das ist jetzt einigermaßen blöd, weil ich es nicht reproduzieren kann. Da bleibt erst mal nur Schritt für Schritt prüfen ...

zuerst wäre mal interessant zu sehen, was bei dir in der Sicherung gelandet ist. Dazu machst du in der telnet/ssh session:

cd /etc
git ls-tree HEAD

Als Output kommt eine Liste mit allen Dateien/Ordnern der Sicherung. Dabei steht 'blob' für Datei und 'tree' für Ordner. Bei mir sieht das so aus:

Code: Alles auswählen

➜  /etc git:(master) ✗ git ls-tree  HEAD           
100755 blob 0fab9af9b95e999ff60ffb76d48ff5f63c4ae500   .etckeeper
100644 blob 3b23ebb736dc4c2edbf50d78b0b12cf2a51b8eac    auto.master
100644 blob 0ee5e75f4d6cdd7dc5806d08096dce2999a83203    auto.misc
100755 blob 61215f6bb3b7e0ee16ed8ab4fc0f72a9e91c60fc    auto.net
100644 blob 25b875aa03b9eefa81744193ee24c2de1739fc90    auto.nfs
100755 blob d296b812f99de34c2c544b7c2c522a733a095134    auto.smb
100644 blob ff024103cdea75ca4f14d87524cc01b8e617fed5    exports
100644 blob a28d5280eded913ddb2d46d1a4c5e452c1593518    hostname
100644 blob 50a2d8729d4b35b4a28aab21b688fc50b4b6c900    minidlna.conf
040000 tree d1c92e1ed25ffd3e986e2699b372a4aceba16222    network
040000 tree 86376cef3910ee7505f28c4df8c92f7c0e97958d    neutrino
100644 blob 5c40de10cbede24505cde2fd6672925648566261    proftpd.conf
100644 blob 537cef05f03edfbf4b123bd954a6269d5ffd5c26    resolv.conf
040000 tree 15479685292b02eabd27a3ed478ec2e0149aefc2    samba
040000 tree 95d9353acc3a3bf6d22600a61e75109b51c919da    ssh
040000 tree a76230d5adf911d4878dc65ef20e17b494e2cd91    systemd
040000 tree 3a9b1eeb87cec81d8582c48917645e09fd4661dc    webmin
040000 tree 0ebabd89b780e44d0d98b0641d2f1b69a87207ed    zsh

Um den Inhalt von 'hostname' deiner Sicherung anzuschauen, markierst und kopierst du den Index (Feld 3) von hostname und gibst ein:

git show a28d5280eded913ddb2d46d1a4c5e452c1593518
# a28d5280eded913ddb2d46d1a4c5e452c1593518 durch Einfügen der Zwischenablage mit deinem Wert ersetzen

Ergebnis bei mir ist:

Code: Alles auswählen

hd51-wohnzimmer

Mit q kommst du zurück zur Konsole

Jetzt fehlt noch der Inhalt von network/interfaces:

git ls-tree HEAD network/interfaces
Index kopieren und hier einfügen:

git show 26044bf69ac5ae3f886c7f5260283c7a243ec493
# 26044bf69ac5ae3f886c7f5260283c7a243ec493 durch Einfügen der Zwischenablage mit deinem Wert ersetzen

Code: Alles auswählen

auto
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 192.168.178.25
        broadcast 192.168.178.255
        gateway 192.168.178.1
        netmask 255.255.255.0

Sollten hier noch Werte für dchp drin stehen, in der Konsole eingeben:

etckeeper commit -a

Danach wieder den Inhalt der Dateien aus der Sicherung anschauen, ob jetzt der richtige Wert drin steht.

[PauleFoul]

Hier wie gewünscht der Inhalt der Sicherung, scheint ja korrekt zu sein.
Dann wird es nach dem Update wohl durch irgendetwas überschrieben...

Code: Alles auswählen

➜  ~ cd /etc
➜  /etc git:(master) ✗ git ls-tree HEAD
100755 blob 0a4792a2b0359c15e6d5cfd473ab4e71d01e2dfe   .etckeeper
100644 blob 3b23ebb736dc4c2edbf50d78b0b12cf2a51b8eac    auto.master
100644 blob 0ee5e75f4d6cdd7dc5806d08096dce2999a83203    auto.misc
100755 blob 61215f6bb3b7e0ee16ed8ab4fc0f72a9e91c60fc    auto.net
100644 blob 25b875aa03b9eefa81744193ee24c2de1739fc90    auto.nfs
100755 blob d296b812f99de34c2c544b7c2c522a733a095134    auto.smb
100644 blob ff024103cdea75ca4f14d87524cc01b8e617fed5    exports
100644 blob 8d39da23947854a35eac96139bff7fb4cc1c196e    hostname
100644 blob 50a2d8729d4b35b4a28aab21b688fc50b4b6c900    minidlna.conf
040000 tree 3407e2f921510fb89995a2f2e0dadad7abb4d32f    network
040000 tree 2a721efb0e4cd1b2ff0d46f65f9aaac8835da8bd    neutrino
100644 blob 5c40de10cbede24505cde2fd6672925648566261    proftpd.conf
100644 blob 946f0ea36d816d8b911a536914ec3cb4eb2ce96d    resolv.conf
040000 tree 49ac7a7f8459cd30667b55bf93fdaa95d9c40c3a    samba
040000 tree d55b30dfaf2bb390bb9c8b7d9caf631a87ea42b0    ssh
040000 tree 14733d86519f24679cce4c4a028ba4a2969d59ee    webmin
040000 tree 0ebabd89b780e44d0d98b0641d2f1b69a87207ed    zsh

Code: Alles auswählen

hd51-wohnen

Code: Alles auswählen

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 192.168.1.110
        broadcast 192.168.1.255
        gateway 192.168.1.1
        netmask 255.255.255.0

[flk]

Wenn das richtig in der Sicherung steht, sollten die Netzwerk Einstellungen aber eigentlich auch nach dem Update übernommen werden. Tut es bei meinen Tests auch. Ich wüsste nicht, wodurch das überschrieben werden könnte.
Was ich mir vorstellen kann ... es ist so, dass beim Flashen ohne Sicherung automatisch beim ersten Boot eine Sicherung angelegt wird. Die wird dann im 24 Stunden Rhythmus aktualisiert. Das ist im normalen use case unproblematisch, weil man ja nicht innerhalb von einem Tag zweimal das Image aktualisiert.

Dazu kann es aber kommen, wenn man das testhalber macht ... so wie in deinem Fall.

D.h., wenn du das Image ohne Sicherung flashst, dann deine Einstellungen machst und hinterher sofort wieder ein Image drüber installierst, kann es sein, dass die Sicherung noch nicht komplett ist. Das wäre erst nach 24 Stunden der Fall. Darum hoffe ich, dass, wenn du jetzt ein Image drüber installierst, die Netzwerk Einstellungen richtig geändert werden.

Die Aktualisierung der Sicherung lässt sich übrigens jederzeit in der telnet/ssh Session mit "etckeeper commit -a" manuell starten

[PauleFoul]

Muss das Thema noch einmal aufgreifen, da es sich durch meine komplette Boxen-Landschaft zieht.

Also normalerweise flashe ich die Images nur alle paar Tage, an machen Boxen sogar nur alle paar Wochen.
Da sollten doch dann immer jeweils die aktuellen Stände auf der HDD abgelegt sein.

Nur leider ist bei mir halt immer DHCP nach dem Update aktiv und somit auf die statische IP-Adresse futsch.

Hab auch die Sicherung auf der HDD gelöscht und versucht die Sicherung manuell anzustoßen. Leider mit wenig Erfolg...

Code: Alles auswählen

login as: root
 __  __         __         ___       __
 \ \/ /__  ____/ /____    / _ \___  / /____ __
  \  / _ \/ __/ __/ _ \  / ___/ _ \/  '_/ // /
  /_/\___/\__/\__/\___/ /_/   \___/_/\_\\_, /
                                       /___/

welcome to hd51 neutrino-hd image
root@192.168.1.110's password:
Last login: Mon Jan 13 14:00:08 2020 from 192.168.1.2
➜  ~ etckeeper commit -a
On branch master
nothing to commit, working tree clean
➜  ~

Wie wäre denn die Vorgehensweise, wenn ich das ganze mal kopmlett neu aufsetze und meinen gesicherten Stand nicht mitnehme?

Alle Sicherungen löschen, über USB Stick neu flashen, Einstellungen anpassen, 24h warten bis Sicherung auf HDD und dann mal ein Update probieren?

[flk]

Zu dem Problem fällt mir gar nicht mehr viel ein. Dummerweise habe ich das ja nicht. Bei mir wird die Netzwerkeinstellung nach dem Flashen ohne Probleme übernommen.

Wenn du wirklich komplett ohne Sicherung und ohne andere Images starten willst, musst du nur die Sicherungsordner löschen und dann per USB neu flashen

rm -r /media/hdd/service/partition_*

bzw. falls du keine Festplatte installiert hast
rm -r /media/usb/service/partition_*

Also quasi genau so, wie du beschrieben hast

[flk]

Endlich habe ich es auch geschafft, das nachzustellen. Das Problem tritt nur auf, wenn man ein Image in die laufende Partition schreibt. Da das zwar so, wie das aktuell gemacht wird irgendwie funktioniert, aber technisch gesehen weit von einwandfrei ist , mache ich das eigentlich nie und hatte deshalb auch nie Ärger beim zurück Schreiben der Sicherung.

Das Problem sollte mit dem aktuellen Stand behoben sein

[PauleFoul]

Ich habe gerade ein Update gemacht und danach war es wieder auf DHCP verstellt, aber beim nächsten Update sollte es dann passen, oder?

[flk]

Genau so ist es

[PauleFoul]

Perfekt! Es funktioniert Danke