Der Build vom ISO ist die 64710 von Mai 2024
Die bringst du aber immer auf den aktuellen Stand mittels
Der Build vom ISO ist die 64710 von Mai 2024
Die bringst du aber immer auf den aktuellen Stand mittels
Ich habe mal deine letzte Anweisung probiert und die Repos in yast entfernt, die neu installierte VM führt ein Upgrade durch , verliert aber sogar die Netzwerkkonfiguration. Die Produktive VM startet danach nur noch ohne xfce und auch ohne Netzwerk.
Ich habe mal deine letzte Anweisung probiert und die Repos in yast entfernt, die neu installierte VM führt ein Upgrade durch , verliert aber sogar die Netzwerkkonfiguration. Die Produktive VM startet danach nur noch ohne xfce und auch ohne Netzwerk.
Was für eine Netzwerkkarte mit welchem Treiber (Leap 15.6)? Selber gebaut?
XFCE und wayland sind, soweit ich weiß, sich nicht grün.
Ich glaube, das nimmt langsam zu heftige Formen an. U.a. habe ich einen auf yast aufgesetzten named DNS-Server. Ich fürchte, der überlebt so ein upgrade auch nicht.
Yast hat nichts damit zu tun, wenn dann wären die Konfiguration der Versionen des DNS-Servers unterschiedlich.
Auf gut deutsch:
Yast macht nichts, was man auch mit dem bearbeiten von Konfigurationsdateien erreichen kann.
Es ist ja leider so dass das Migrationstool kein eigenes Logfile schreibt. Insofern wissen wir ja nicht woran es genau hängt.
Hast Du schon mal im Journal nachgeschaut ob es da während das Migrationstool läuft irgendwelche Hinweise gibt was genau nicht funktioniert,
z.B. mit journalctl -b ? Eventuell muss man weitere Filtermöglichkeiten in Betracht ziehen.
Könnte das Problem in irgend einer Weise mit der Infrastruktur zusammenhängen in der Du da diese virtuellen Maschinen betreibst ?
Was ist denn mit dem internen DNS ? Könnte es möglich sein dass der (aus welchem Grund auch immer) irgendwas nicht auflösen kann ?
Ist nur sowas wie ein Brainstorming meinerseits weil ja die Versuche in Richtung zypper / Repositories zu keiner Verbesserung der Lage führen. Insofern könnte es sein dass der Fehler wo anders zu suchen ist.
Ich habe auf den OpenSuse-VM’s den DNS auf 8.8.8.8 umgestellt, da ja für das Update interne DNS-Auflösung nicht benötigt wird. IPv6 ist default aud Automatic. Alle Leap15-Updates sind immer durchgelaufen. Parallel laufen über eine ganze Menge VM’s mit unterschiedlichsten Betriebssystemen, die bis jetzt keine derartigen Probleme hatten.
Dann würde ich während des Updates mal im Journal schauen ob da was drin zu finden ist wenn das Update wieder an diesem einen Paket hängt.
Da kommt nicht viel brauchbares:
Aug 18 14:39:50 [RPM][3518]: Transaction ID 6a845296 started
Aug 18 14:39:50 [RPM][3518]: erase openSUSE-repos-Leap-20250604.94835c9-lp156.2.9.1.x86_64: success
Aug 18 14:39:50 [RPM][3518]: install openSUSE-repos-Leap-20260218.3c95c01-lp160.1.1.x86_64: success
Aug 18 14:39:50 [RPM][3518]: erase openSUSE-repos-Leap-20250604.94835c9-lp156.2.9.1.x86_64: success
Aug 18 14:39:50 [RPM][3518]: Transaction ID 6a845296 finished: 0
Aug 18 14:41:08 systemd[1973]: Created slice User Background Tasks Slice.
Aug 18 14:41:08 systemd[1973]: Starting Cleanup of User's Temporary Files and Directories...
Aug 18 14:41:08 systemd[1973]: Finished Cleanup of User's Temporary Files and Directories.
Aug 18 14:41:12 systemd[1893]: Created slice User Background Tasks Slice.
Aug 18 14:41:12 systemd[1893]: Starting Cleanup of User's Temporary Files and Directories...
Aug 18 14:41:12 systemd[1893]: Finished Cleanup of User's Temporary Files and Directories.
Aug 18 14:45:12 systemd[1]: Started Daily Cleanup of Snapper Snapshots.
Aug 18 14:45:12 systemd[1]: snapper-cleanup.service: Deactivated successfully.
Aug 18 14:50:12 systemd[1]: Starting Cleanup of Temporary Directories...
Aug 18 14:50:12 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Aug 18 14:50:12 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 18 14:50:12 systemd[1]: run-credentials-systemd\x2dtmpfiles\x2dclean.service.mount: Deactivated successfully.
Aug 18 15:00:12 systemd[1]: Started Timeline of Snapper Snapshots.
Aug 18 15:00:12 systemd[1]: snapper-timeline.service: Deactivated successfully.
Aug 18 15:35:06 rsyslogd[1555]: -- MARK --
Aug 18 15:39:05 dbus-daemon[761]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requested>
Aug 18 15:39:05 systemd[1]: Starting PackageKit Daemon...
Aug 18 15:39:05 PackageKit[4189]: daemon start
Aug 18 15:39:05 dbus-daemon[761]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Aug 18 15:39:05 systemd[1]: Started PackageKit Daemon.
Aug 18 15:39:05 PackageKit[4189]: get-updates transaction /1_bcaeaedd from uid 1000 finished with failed after 9ms
Aug 18 15:39:25 PackageKit[4189]: daemon quit
Aug 18 15:39:25 systemd[1]: packagekit.service: Deactivated successfully.
Alles anzeigen
Dann fällt mir jetzt nur noch ein dass unter /var/log bei einem Update ein updateTestcase-Verzeichnis angelegt wird. Vielleicht steht dort irgendwo drin was genau schief geht.
Wenn das nichts bringt dann muss auch ich hier passen.