Nach NAS (omv) upgrade: NAS nicht mehr über Namen zu verbinden-über IP geht

@lisanet ich habe mal noch ein paar vergleichende Analysen zwischen den beiden Systemen omv6 und omv7 gemacht.
Dabei die outputs von systemctl und journalctl zum avahi-daemon berücksichtigt.
"ifconfig" outputs habe ich auch verglichen sowie die jeweilige avahi-daemon.conf.

Ergebnisse:
- auf omv7 läuft avahi nicht richtig (welch Wunder). systemctl zeigt da die CGroup Einträge in "hellgrau"
- journalctl zeigt keinerlei Einträge auf omv7
- "ifconfig" bringt auf omv7 eine Konfig von LAN-IF "end0", auf omv6 heißt das LAN-IF "eth0"
- in der avahi-daemon.conf (die ja von omv generiert wird) gibt es auf beiden systemen einen Eintrag "allow-interfaces=eth0" (aber nix mit "end0")

Das sieht für mich seltsam aus - kann es aber nicht wirlkich beurteilen - vor allem die Benamung der LAN-IF Namen
Ich habe das auch mal mit mehr Details und Code-Outputs an die omv-Leute gegeben.
 
"allow-interfaces=eth0" (aber nix mit "end0")

das ist das was ich meinte. Debian 12 hat die Namen der Schnittstellen verändert.

Diese config-Zeile bestimmt, auf welcher Schnittstelle avahi überhaupt läuft. Wenn die falsch ist, dann kriegst du definitv kein bonjour-Announce. Genau das ist mir mal vor etlicher Zeit passiert, beim kopieren der configs vom Raspi auf einen PC, da der PC die Schnittstellen anders benennt.

Ändere mal das eth0 oben in end0 und starte avahi neu, ggf. mal den Rapsi neu starten. Ob und wie dann bei updates u.dgl. omv7 da wieder das auf eth0 ändert weiß ich nicht. Falls ja, kann man das aber auch patchen. Aber da müsste ich est selbst das update auf omv7 wagen (und dazu habe ich zur Zeit keine Lust)
 
das ist das was ich meinte. Debian 12 hat die Namen der Schnittstellen verändert.

Ändere mal das eth0 oben in end0 und starte avahi nue, ggf. mal den Rapsi neu starten.
jau - das würde ich ja gern ändern. Ich habe aber einen Fehler gemacht:
ich hatte gelesen, dass omv-firstaid helfen soll die Konfig für omv anzupassen. Also habe ich spontan omv-firstaid für die NW-Konfig gestartet, anstatt einfach mal nur fix den Eintrag in der avahi Konfig zu ändern - und siehe da: er hat mir das NW irgendwie komplett zerschossen, so dass ich nicht mehr ans System komme :-/
Ich werde also morgen zunächst noch einmal die sd-karte mit omv7 wiederherstellen müssen, da ich gerade keinen Monitor habe, um sehen zu können wo es hängt. Gut, dass das eigentlich keine "Arbeit" ist, sondern einfach nur etwas Zeit dauert. Läuft ja fast automatisch.
 
ich hatte gelesen, dass omv-firstaid helfen soll die Konfig für omv anzupassen.

naja, nicht anpassen, sondern auf die Standard-Einstellungen hin anpassen. Wenn du aber schon ein System hast, das nicht korrekt in einzelnen Punkten läuft, ist so ein Tool, egal welches Betriebssystem, halt echt nur "erste Hilfe". Kann helfen, muss nicht, und wird auch selten helfen. So wie "Recht reparieren" und macOS. Klappt manchmal, meistens aber nicht.

Naja, installiere dann einfach neu. Nachdem was du geschrieben hast, bin ich mir schon ziemlich sicher, dass es an den geänderten Namen der Schnittstellen liegt.
 
...

Naja, installiere dann einfach neu. Nachdem was du geschrieben hast, bin ich mir schon ziemlich sicher, dass es an den geänderten Namen der Schnittstellen liegt.
ja - da bin ich mir auch ziemlich sicher. Und Restore mit fsarchiver geht in 15-20 mins - kein Thema (mehr :) ) + omv-release-upgrade (ca. 30min)

Aber was ich mich gerade frage: löscht fsarchiver beim restore eigentlich zuvor die Inhalte der Partition oder kopiert es einfach nur drüber?
Hintergrund: muss ich die SD-Karte vorher löschen und neu partitionieren oder kann ich mir das sparen? Jetzt ist ja noch Debian12/omv7 drauf - mein Backup ist aber Debian11/omv6
 
Aber was ich mich gerade frage: löscht fsarchiver beim restore eigentlich zuvor die Inhalte der Partition oder kopiert es einfach nur drüber?

... kann ich dir nicht sagen. Ich habe damals beim Testen des restores aus purer Gewohnheit selbst die SD-Karte gelöscht. Hast du schon mal auf der Website / manpage nachgesehen?
 
... kann ich dir nicht sagen. Ich habe damals beim Testen des restores aus purer Gewohnheit selbst die SD-Karte gelöscht. Hast du schon mal auf der Website / manpage nachgesehen?
nee, habe ich nicht - dachte du weißt das auswendig - egal - ich habe nun einfach die sd-karte gelöscht.
Alles ist nun wieder auf omv7/bookworm - und: das avahi Problem ist gelöst
Ich habe den Eintrag in der avahi-daemon.conf gemacht, reboot --> omv wird wieder im Finder angezeigt und ist über omv.local im Terminal, ... erreichbar.

ABER: die OMV-Experten sind echt witzig. Das Problem mit der Änderung der Schnittstellenbenamung ist bekannt und bereits gelöst. Auf omv-extras in der omv7-Installationsanleitung steht, dass man vor einem upgrade ein bestimmtes script starten soll (....-pre-install). Nur steht da nicht was es eigentlich tut. Und das blödeste ist eigentlich: die Experten wissen um end0 vs eth0 und sagen es irgendwie nicht. Es heißt immer nur: "Starte omv-release-upgrade und du bist durch (wenn alles gut läuft)". Und wer schaut denn in eine "Installationsanleitung für omv7 für neue user" wenn er/sie ein upgrade machen will?

Na ja, ich habe mal im omv-forum den Status geschildert und gefragt, was ich denn jetzt am besten tue damit alles sauber ist. Denn die manuelle Änderung der avahi Konfig wird ja wieder beim nächsten update überschrieben wenn ich nicht patche.
 
nee, habe ich nicht - dachte du weißt das auswendig - egal - ich habe nun einfach die sd-karte gelöscht.
Alles ist nun wieder auf omv7/bookworm - und: das avahi Problem ist gelöst

sehr gut.

Ich habe den Eintrag in der avahi-daemon.conf gemacht, reboot --> omv wird wieder im Finder angezeigt und ist über omv.local im Terminal, ... erreichbar.

ABER: die OMV-Experten sind echt witzig. Das Problem mit der Änderung der Schnittstellenbenamung ist bekannt und bereits gelöst. Auf omv-extras in der omv7-Installationsanleitung steht, dass man vor einem upgrade ein bestimmtes script starten soll (....-pre-install). Nur steht da nicht was es eigentlich tut. Und das blödeste ist eigentlich: die Experten wissen um end0 vs eth0 und sagen es irgendwie nicht. Es heißt immer nur: "Starte omv-release-upgrade und du bist durch (wenn alles gut läuft)". Und wer schaut denn in eine "Installationsanleitung für omv7 für neue user" wenn er/sie ein upgrade machen will?

ja, das sind einige unterwegs, die sich etwas seltsam verhalten. Da gibt es mehrere Dinge die nicht technisch beantwortet werden, sondern halt "tu es einfach". Bsp: frage mal nach, warum man mit USB-Platte kein RAID über die GUI aufbauen kann. Oder warum man den uralten Pixel-Cursor aus Amiga-Zeiten nicht abschalten kann, oder warum der Hostname immer in Kleinbuchstaben konvertiert wird, oder warum Share-Namen keine Spaces enthalten dürfen und rsync Tags auch nicht. Alles seltsam und alles softwaretechnisch sehr einfach lösbar. Es geht bei manchem omv-Entwickler eher um "will ich nicht"

Naja, zum Glück ist omv open-source und man kann es selbst patchen. Die Möglichkeit über die GUI bspw. auch USB-Platten als RAID zu konfigurieren ist banal zu realisieren.

Na ja, ich habe mal im omv-forum den Status geschildert und gefragt, was ich denn jetzt am besten tue damit alles sauber ist. Denn die manuelle Änderung der avahi Konfig wird ja wieder beim nächsten update überschrieben wenn ich nicht patche.

Also, wenn das omv wirklich überschrewiben sollte, dann haben die großen Mist gebaut. Von der gesamten Software-Architektur von omv gesehen, besteht überhaupt kein Grund, dass es überschrieben wird, wenn der korrekten Schnittstellenname in der GUI steht. ( unter Network -> Interfaces). Probleme gibts aber immer bei update von debian 11 auf 12, da omv offensichtlich die früher eingetragenen Werte nicht aktualisiert (obowohl sie es einfach tun könnten, da sie es ja wissen)
 
Also, wenn das omv wirklich überschrewiben sollte, dann haben die großen Mist gebaut. Von der gesamten Software-Architektur von omv gesehen, besteht überhaupt kein Grund, dass es überschrieben wird, wenn der korrekten Schnittstellenname in der GUI steht. ( unter Network -> Interfaces). Probleme gibts aber immer bei update von debian 11 auf 12, da omv offensichtlich die früher eingetragenen Werte nicht aktualisiert (obowohl sie es einfach tun könnten, da sie es ja wissen)
Ja, das ist das Problem wenn man "nur" omv-release-upgrade macht.
In der GUI steht bei mir immer noch eth0 obwohl es das gar nicht mehr gibt. Ich habe das auch mal angefragt wie ich das nun ändern kann (ohne mir wieder das NW komplett lahmzulegen).

Meine Überlegng geht dahin, in der GUI ein neues Interface anzulegen --> "end0" mit den gleichen Parametern wie eth0
Dann wären da zwei in der Übersicht.
Und dann eth0 löschen.
Ich weiss nur nicht, ob ich mir wieder damit selbst ein Ei lege ...

Edit: ich habe gerade mal in der GUI nachgeschaut. eth0 zeigt in den Details gar keine "Echtzeitdaten" an - kann ja auch nicht wenn es gar nicht existiert.

Was meinst du: soll ich einfach mal einen neuen Eintrag end0 anlegen?
 
kann (und will) ich dir nicht beantworten. Das musst du entscheiden.
Du willst wohl nicht mein Risiko übernehmen, was? Feigling! :D
Na gut, ich lasse es erstmal so laufen und warte, ob ich was von den Experten höre.
Ggf. mache ich einfach mal einen Klon von der SD-Karte damit ich einen guten Stand gesichert habe und nicht wieder bei 0 anfangen muss.
 
Soooo, alles nun im Lot:
1. avahi löppt
2. omv7-gui zeigt nun auch das richtige Interface an
3. mit meinen Änderungen in der omv7-gui (Netzwerk->Interfaces --> neu: end0 , löschen: eth0) wurde auch die avahi-daemon.conf automatisch neu generiert und das richtige NW-IF eingetragen.

Also bei mir hat nun der Upgrade (mit wenig Schmerz :) ) von omv6 auf omv7 geklappt - auf meiner Backup-SD-Karte.
Nun lasse ich das mal etwas laufen und mache dann das Upgrade auf meiner System-SSD - oder klone einfach die sd-karte auf die ssd - mal schauen.

Dank an alle, die geholfen haben - oder es zumindest versuchten :)
 
  • Gefällt mir
Reaktionen: lisanet
Und nun als Abschluss (für alle Interessenten):
Hätte ich mich bei dem Upgrade omv6 zu omv7 an das Manual gehalten - wenn ich denn gewusst hätte, dass das überhaupt relevant ist - wären mir die ganzen Problemchen erspart geblieben.

Meine System-SSD ist nun auch auf OMV7/Debian12 (nach Handbuch vorgegangen) und alles läuft problemlos ohne weitere manuellen Eingriffe.
 
Hätte ich mich bei dem Upgrade omv6 zu omv7 an das Manual gehalten - wenn ich denn gewusst hätte, dass das überhaupt relevant ist - wären mir die ganzen Problemchen erspart geblieben.

was meinst du mit "manual"? In der Doku steht ja auch nur was von omv-release-upgrade
 
was meinst du mit "manual"? In der Doku steht ja auch nur was von omv-release-upgrade
Hier - https://wiki.omv-extras.org/doku.php?id=omv7:raspberry_pi_install - und ich hatte das nur relevant für "Neuinstallationen" gedacht. Ich habe aber nun das "preinstall" bei meinem omv6 gemacht (kam aus dem omv-forum) und dann war beim anschließenden omv-release-upgrade alles korrekt konfiguriert (auf eth0)

Raspberry PI OS Updates and Upgrades​

Before installing OMV, update, upgrade and prepare Raspberry PI OS using the following commands, executed one at at time:
sudo apt-get update
sudo apt-get upgrade -y
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash

When the above commands are complete, type;
sudo reboot

----------------
 
ah, ok. Danke.

Das script nennt die Schnittstelle lediglich auf eth0 um und gibt das debian als "fix" vor.

Dann ist das im Grunde nur der "umgekehrte" Weg. Entweder end0 via GUI konfigurieren und eth0 löschen, oder auf Debian-Seite den Schnittstelle-Namen auf eth0 fest nageln.
 
  • Gefällt mir
Reaktionen: jteschner
ah, ok. Danke.

Das script nennt die Schnittstelle lediglich auf eth0 um und gibt das debian als "fix" vor.

Dann ist das im Grunde nur der "umgekehrte" Weg. Entweder end0 via GUI konfigurieren und eth0 löschen, oder auf Debian-Seite den Schnittstelle-Namen auf eth0 fest nageln.
Ja, so hatte ich das auch im groben verstanden als ich in das Script geschaut habe - mit meinen eingeschränkten Kenntnissen allerdings.
Ich habe mich aber gefragt, warum sie das nicht direkt in omv-release-upgrade eingebaut haben.

Na ja, ich bin ja nicht in der Lage, qualifierte Kritik zu üben - und für mich machen die in ihrem "Hobbyprojekt" schon exzellente Arbeit. So wie ich von "chente" verstanden habe, sind sie gerade mal zu zweit, die nebenbei alles vorantreiben. Da kann ich schon verstehen, warum da manches auf der Strecke bleibt.
 
So wie ich von "chente" verstanden habe, sind sie gerade mal zu zweit, die nebenbei alles vorantreiben.

yep. Das ist leider bei vielen open source Projekten der Fall.

Schade ist aber dabei dann dennoch, dass manche Entwickler bestimmt Anregungen und Funktionen einfach nicht aufnehmen wollen, wie bspw bei omv dieser grauenhafte Pixel-Amiga-Cursor. Wenn man Hardcore-Amiga-Fan im Jahr 2024 ist, dann mag das ein guter gag sein, aber die Weigerung das abzustellen oder konfigurierbar zu machen ist nicht so toll. Aber wie schon mal geschrieben, es ist open source und dann patche ich mir das eben selbst zurecht.

Wenn ich mal viel Lust habe, veröffentliche ich die Patches auf meinem blog. Ein Teil (der bei Usern weniger Know-How erfordert) ist ja schon online.

Die interessanter Dinge fehlen noch: der fix für avavahi, dass die Hostnamen nicht mehr hochgezählt werden, das Hostnamen auch Groß/Kleinschreibung unterstützen, USB-Platten als RAID verwendet werden können, den Amiga-Cursor ersetzen und besonders die extrem nervige und überflüssige checkbox zum Bestätigen des Bestätigungsbuttons im Bestätigungsdialog entfernen, da der Dialog eh schon explizit ausgewählt werden muss. Schlimmer geht es echt nicht mehr.
 
Zurück
Oben Unten