[Olmimoe]

Hallo,

mein MLD 6.5 möchte 710 Pakete updaten. Ist das so OK oder läuft da gerade etwas schief?
Das Update habe ich erst mal nicht gestartet.
Es sind sehr viele glibc-gconv* Pakete und jede Menge andere.
Update gefahrlos?

Grüße,
Olmimoe

[herb01]

ich habe gestern mehr als 800 Pakete upgedatet und alles hat zumindest bei mir problemlos funktioniert

Viele Grüße
Herbert

[clausmuus]

Ich habe vor ein paar Tagen eine Quelle für nicht benötigte Pakete entfernt. Dadurch hat sich der Hash von sehr vielen Paketen geändert, und dafür gesorgt dass diese neu angeboten werden. Der Inhalt sollte sich jedoch nicht geändert haben.

[kuro13]

Heute habe ich das riesige update mit 1009 Dateien durchgeführt und gewartet, bis im WebIf der sich drehende Kreis verschwunden war. Dann den Rechner ausgeschaltet.
Nun komme ich nicht mehr auf den Rechner und der FS zeigt diese Bild - nun musste ich auf ein altes Backup vom 6.2.26 zurück.
Komisch, bei diesem Backup werden mir 879 Dateien zum Update angezeigt.

[wayne]

Nach dem großen Update gibt es einige Problem bei mir:

• keine Verbindung zum Server per svdrp, also keine Timer mehr auf dem Server sichtbar
• FB reagiert nur sehr träge
• Powerknopf an der FB schaltet den Rechner nicht mehr vollständig ab, macht nur noch suspend2ram

Bin wieder zurück per Snapshot...

[kuro13]

@ wayne

Powerknopf an der FB schaltet den Rechner nicht mehr vollständig ab, macht nur noch suspend2ram

Bedeutet suspend2ram, daß auf dem Fernsehschirm nur das mld Logo zu sehen ist? Wenn ja, das kam bei mir nach updates auch schon vor.

[wayne]

Bedeutet suspend2ram, daß auf dem Fernsehschirm nur das mld Logo zu sehen ist? Wenn ja, das kam bei mir nach updates auch schon vor.

Nee, das MLD Logo ist nicht mehr zu sehen.
Er schaltet die Ausgabe ab...

[franky]

Ich habe mittlerweile bei mehreren Systemen dieses große Dist-Upgrade gemacht und bin auch bei 3 Systemen nach dem Upgrade nur noch auf Konsole gelandet (wie beim geposteten Bild von kuro13).
Ich habe mittlerweile herausgefunden, dass bei mir immer nur die Systeme betroffen sind, die kein CSM mehr haben (z.B. die Intel NUC) oder das CSM deaktiviert war.
Dann kann das System nur im UEFI Boot-Mode starteten was schief geht.
Eine Installation auf einem USB-Stick mit diesem Problem ist auf einem anderen System mit Legacy-Boot problemlos gestartet.

Der Übeltäter schein die Datei /boot/efi/boot/bootx64.efi zu sein, die beim Dist-Upgrade überschrieben wird.
Das sieht man auch an der Dateigröße von 192KB vor dem Dist-Upgrade und 102 KB danach.
Wenn ich den Stick auf einem anderen System mit CSM im Legacy-Boot starte und dann die Datei wieder austausche, funktioniert das System auch wieder auf dem System, das nur UEFI-Boot beherrscht.
Ich habe das gerade nochmal bei einem Intel NUC getestet.

Also am Besten die funktionierende bootx64.efi mit 192 KB vor dem Dist-Upgrade sichern und gleich danach vor dem ersten Reboot wieder zurück kopieren.

[thinokoe]

Hallo zusammen,
bei mir funktionieren nach dem Update der 849 Pakete das Keyboard und Mouse am USB-Anschluss eines RPi5 nicht mehr. Ich habe dann den Snapshot vom 30.03.2026 zurück gespielt und schon geht alles wieder.
Grüße
thinokoe

[franky]

@thinokoe
Ich habe das große Distupgrade bei mehreren x86ern gemacht und mit der Tastatur hinterher keine Probleme.
Bei den Distupgrades meiner x86er Systeme ist mir aber aufgefallen, dass die KBD.conf aktualisiert wird.

Code: [Select]

Neue Version der Konfigurationsdatei /etc/vdr/remote.conf.d/KBD.conf wird installiert ...Bei den x86ern läuft ja softhddevice mit XServer weshalb die XKeySym.conf für die Tastatur genutzt wird.
Und diese wird beim Distupgrade nicht verändert.

Beim RPI5 läuft ja aufgrund von softhddevice-drm-gles kein XServer weshalb die KBD.conf für die Steuerung per Tastatur genutzt wird.
Daher könnte ich mir vorstellen, dass die Installation dieser neuen KBD.conf etwas mit deinem Problem zu tun hat.

[thinokoe]

Beim RPI5 läuft ja aufgrund von softhddevice-drm-gles kein XServer weshalb die KBD.conf für die Steuerung per Tastatur genutzt wird.
Daher könnte ich mir vorstellen, dass die Installation dieser neuen KBD.conf etwas mit deinem Problem zu tun hat.

Hat denn jemand eine Idee, wie das Problem zu lösen wäre?

[franky]

Da du ja auf einen funktionierenden Snapshot zurück bist, könntest du ja mal dort die /etc/vdr/remote.conf.d/KBD.conf sichern und dann nach einem Distupgrade diese Datei wieder zurück kopieren.

Wenn dann die Tastatur doch nicht geht, war ich auf dem Holzweg und die nicht funktionierende Tastatur hat doch andere Ursachen.

[thinokoe]

Ich habe es so macht, wie du gesagt hast, leider ohne Erfolg.

[wayne]

...nur mal so nebenbei...

Jetzt haben doch mehrere verschiedenste Probleme nach dem Riesen-Update.
D.h., da ging was generelles in die Hose.

Müsste man nicht zuerst den Grund finden bevor hier jeder an seinem Problem rumbastelt?

[kuro13]

An etwas habe ich mich wieder erinnert, wie es unter MS DOS und Windows 3.0 immer hieß:
never touch a running system 

Ich werde in Zukunft bei einem fehlerfrei laufenden System mit den Updates einige Zeit warten. Erst wenn ich hier nichts negatives lese, dann....