ubuntuusers.de

Vermutlich dasselbe Problem wie das, mit dem ich zu kämpfen habe bzw. hatte, nur dass beim Boot kein Login erfolgen musste (automatisches Einloggen, und das klappte). Habe von 24.04 auf 26.04 upgedatet. Update war allem Anschein nach fehlerfrei, zumindest nach Reparatur nach Anleitung von DuckDuckGo AI, aber nach wie vor: jeder Benutzerwechsel → schwarzer Schirm, egal, ob Ausloggen; dasselbe nach Standby, Bildschirmsperre, Versuch des Einschachteln eines neuen Users. Nichts geht dann mehr ausser Langer Druck auf den Ausschaltknopf oder Strom ausschalten. Kein Tipp der AI von DuckDuckGo half, auch wenn er noch so plausibel aussah, sie nette Tips gibt, im Ganzen machte sie eher unnötige Schwierigkeiten.

Teilweise habe ich jedenfalls meines gelöst. Die Lösung war trivial - wenn man sie findet. Ein paar läppische Voreinstellungen fehlten:

Systemeinstellungen → Farben und Designs → Anmeldebildschirm(SDDM) ... einfach ein Design oder eine Farbe auswählen Dasselbe für Startbildschirm.

Bildschirmsperre habe ich zunächst so gesetzt: Bildschirm automatisch sperren: Niemals

Nicht gelöst ist die Rückkehr nach Standby (manchmal klappt das trotzdem, aber warum, unter welchen Bedingungen, und was ist zu tun, damit das immer klappt?)

Wenn der erste Login aus dem gleichen Grund nicht klappt, wie ich annehme, müsste man schauen, ob man so eine Änderung von aussen machen kann - also von einer parallelen Installation oder vom single user mode aus. Letzteres habe ich jahrzehntelang nicht mehr gemacht, die Übersetzung der Änderung wollte ich deshalb anderen überlassen. Die oben beschriebene Situation dürfte danach sowieso eintreten. Im übrigen ist Lösung per AI inzwischen entspannter als die Formalien in Foren wie diesem, die Vorschläge treffen eher öfter. Ich verstehe schon, was Sie meinen. Wollen Sie aber im Ernst einen 82-Jährigen belehren?

Hallo urold,

Das hängt wahrscheinlich alles mit dem Wechsel vom X-Server auf Wayland von Kubuntu 26.04 zusammen ....

Gruss Lidux

urold schrieb:

... Wollen Sie aber im Ernst einen 82-Jährigen belehren?

Es gibt hier keine Narrenfreiheit für ältere User. Auch ein 82-Jähriger kann sich an die Regeln halten. 😛

Lidux schrieb:

Das hängt wahrscheinlich alles mit dem Wechsel vom X-Server auf Wayland von Kubuntu 26.04 zusammen ....

Ja, ist wohl eine sehr indirekte Folge, Wayland ist kaum schuld (off topic: Was ich bei Wayland bisher sehe, ist eine unglaublich fehlerarme Kopie der Oberfläche von X11 - leider inklusive aller Fehler von X11).

urold schrieb:

Wayland ist kaum schuld

Doch! Es ist bekannt, dass ausloggen, und anschließendes wieder einloggen mit Wayland Probleme macht.

Einfach auf den bewährten XServer wechseln, wofür das DEB-Paket plasma-session-x11 installiert werden muss, dann läufts.

sudo apt install plasma-session-x11

@trollsportverein

Oh, danke für die Info! Werde ich gelegentlich ausprobieren.

Einfaches Ab- und Wiederanmelden geht bei mir aber in der 26.04 nach Definition von Hintergrundbildern störungslos, aber anderes wie etwa Anmelden in einem zweiten User (bzw. dem Versuch dazu) und Aufwachen nach langen Pausen bzw. Standby zickt nach wie vor.

Kubuntu 26.04 ist aber bei weitem nicht die erste Linux-Version mit Wayland, zuvor hatte ich nie Probleme damit (hatte noch nie eine Nvidia-Karte), auch nicht zusammen mit meiner traditionell programmierten OpenGL/Mesa - Anwendung (OpenGL als Schnittstelle ist an sich schon bescheuert genug, Mesa hat früher bei Hardwarewechsel reichlich Ärger gemacht). Der spätere Übergang auf Wayland (bzw. XWayland) oder zurück auf X11 war hingegen kaum zu merken. Dass jetzt Wayland schuld sein soll und nicht etwa Ungenauigkeiten bei Anpassung oder beim Updatevorgang, erschließt sich mir also nicht wirklich.

urold schrieb:

... und nicht etwa Ungenauigkeiten bei Anpassung oder beim Updatevorgang, erschließt sich mir also nicht wirklich.

Gerne schleichen sich Layer 8 Entscheidungsfehler bei der Abfrage, welche Konfigurationsdatei; bei einem Upgrade, behalten/verwendet werden soll, ein. Gerade beim Wechsel von 24.04. mit Qt5 und X11 zu 26.04 mit Qt6, Wayland und X11 wäre so etwas suboptimal.

Mylin schrieb:

Gerne schleichen sich Layer 8 Entscheidungsfehler bei der Abfrage, welche Konfigurationsdatei; bei einem Upgrade, behalten/verwendet werden soll, ein. Gerade beim Wechsel von 24.04. mit Qt5 und X11 zu 26.04 mit Qt6, Wayland und X11 wäre so etwas suboptimal.

Nach Wechsel auf einen "textuellen" Systemstartbildschirm fiel mir auf, dass der einen Vermerk auf die 26.04-Betatestversion enthält, warum auch immer. Sagt vermutlich nicht viel, solche Nachlässigkeiten kamen auch früher schon vor, macht aber aufmerksam. Im Gegensatz zu früher achte ich heute aber auf offizielle, vornehmlich LTS-Versionen, und der Online-Update, den ich im Juli verwendet habe, war nicht als Testversion bezeichnet.

Habe deshalb nochmal auf weitere Layer 8 Fehler überprüft und noch einen gefunden, einen peinlichen von mir: Ich hatte vergessen, dass ich, um endlich einen Kernel zu bekommen, der Audio auf meinem Laptop beherrscht, vor längerem von der 24.04 auf die 25.10 upgedatet hatte, sorry. So vergesslich sollte man nicht werden, kommt aber von alleine ... dabei war der Grund für den Update der Hinweis auf das Auslaufen der Maintenance der 25.10

Nach Studium der log-Files in mehreren Fällen und Websuche dürfte der Grund des Problems feststehen:

Es ist mit secure boot verbunden. Lösen kann das nur die Distro.

Ich bitte schwarzheit als Zuständigen, das zu prüfen und ggf. Abhilfe anzuleiern.

Das 2011 von Microsoft ausgestellte Zertifikat, mit dem die „Shim“-Schicht von Linux-Distributionen signiert wurde, ist Ende Juni 2026 abgelaufen. Das Ablaufen der Gültigkeitsdauer verhindert zwar nicht, dass bestehende Systeme starten, aber bei Standby wird gewähnt, dass Systemteile verändert werden könnten - deshalb fährt Standby nicht vollständig herunter.

Fedora und andere Distributionen sollen bereits doppelt signierte Shim-Layer haben, die das neue Microsoft-Zertifikat von 2023 enthalten. Das ist allem Anschein nach bei Kubuntu unterblieben.

Als ohne neue Schlüssel unverwendbarer Tip gilt: "Es wird empfohlen, die Firmware mit fwupdmgr zu aktualisieren, um die neuen Schlüssel sicher zu integrieren.

Es ist unbedingt erforderlich, den 2011-Schlüssel nicht manuell aus der Firmware zu löschen, da er zur Validierung der Peripheriegeräte verwendet wird und seine Löschung das Gerät unbrauchbar machen könnte."

urold schrieb:

Ich bitte schwarzheit als Zuständigen, das zu prüfen und ggf. Abhilfe anzuleiern.

Pff nicht meine Zuständigkeit.

Ausserdem kein *buntu braucht SecureBoot. Deaktivieren und gut ist.

Alleine ein verschlüsselten Windows braucht SecureBoot. Ansonsten ist es zu nichts nutze.

@schwarzheit

Pardon, das trifft nicht zu. Z.B. gibt es eine Reihe User, die parallel Windows haben - und ohne SecureBoot geht dann gar nichts.

Früher hätte ich ja unmittelbar selbst eine Systemfehlermeldung geschrieben - aber der groteske Zirkus, der heute dafür nötig ist ... nein, das mache ich nie mehr.

urold schrieb:

Pardon, das trifft nicht zu. Z.B. gibt es eine Reihe User, die parallel Windows haben - und ohne SecureBoot geht dann gar nichts.

Das ist Blödsinn. DualBoot hat überhaupt gar nichts mit SecureBoot zu tun.

@schwarzheit

Richtig ist, dass DualBoot nichts mit SecureBoot zu tun hat. Leider ist aber Ihre Aussage trotzdem nicht zielführend. Richtig ist nämlich, dass Linux beim Setzen des Industriestandards unterlegen ist, und nur noch nolens volens geduldet wird. Viel günstiger wäre es gewesen, Linux hätte bei SecureBoot die Nase vorn gehabt - diese Entwicklung wurde nämlich nicht von Microsoft initiiert, sondern auf Druck von Wirtschaft und Industrie.

Ausserdem ist es Tatsache, dass ein Gutteil der Linuxnutzer um Windows nicht herumkommen, egal, ob sie es als Angestellte nutzen müssen, oder als Geschäftsleute oder Freiberufler auf Tools angewiesen sind, die nur für Windows entwickelt werden. Ohne SecureBoot läuft Windows 11 nicht. Es ist zudem zu erwarten, dass in absehbarer Zeit Peripheriegeräte auf den Markt kommen, die ebenfalls SecureBoot verlangen, und das könnte bald vorgeschrieben werden.

SecureBoot kümmert sich bislang nur um die Sicherheit von Windows. Beim Start eines nicht offiziell signierten Kernels setzt SecureBoot ein "tainted"-Signal. Wird Windows das nächstemal gestartet, wird es zunächst aufwendigst überprüft und danach "wiederhergestellt". Dabei werden alle möglicherweise "befleckenden" Täter, also nicht geeignet signierte Linuxe, erkannt und ihre Bootberechtigung entzogen. Dasselbe geschieht aber auch in kurzen Abständen, sobald Windows 11 installiert ist, und danach ist kein nicht oder ungültig signiertes Linux mehr bootfähig.

Schrott, also z.B. ein unsigniertes oder ungültig signiertes Linux, kann auf Rechnern, die unter SecureBoot laufen, gar nicht erst installiert werden. Um die Sicherheit im Netz besser zu gewährleisten, gibt es Bemühungen, SecureBoot generell vorzuschreiben.

Bedaure, ich belehre andere ungern, selbst wenn es sich um blutige Laien handelt, aber manchmal sehe ich mich dazu genötigt.

Zweifellos wird Ubuntu bald nachziehen bei der Signierung - sie müssen das spätestens bis Jahresende, sonst ist die Welt um eine Reihe wichtiger Linux-Versionen ärmer. Es wäre erheblich nutzerfreundlicher gewesen, wie andere Distros rechtzeitig zu agieren, um möglichst vielen die unnötige Pein einer Nachsignierung zu ersparen. Davor hätte zumindest eine neue LTS-Version nicht ausgeliefert werden sollen.

Bitte unterlasse Fullquotes. Sie blähen den Thread nur sinnlos auf.

Lies dazu Zitate & Verhaltenskodex/Fullquote.

Da steht eindeutig:

Hier wird ausdrücklich von "Teile eines vorherigen Beitrags" gesprochen, gesamte -also komplette- Beitragen zu zitieren ist unerwünscht.

Und wenn man direkt antwortet reicht ein @[user:Benutzername:] da braucht es garkein Zitat.

urold schrieb:

Ohne SecureBoot läuft Windows 11 nicht.

Auch das ist absoluter Blödsinn.

schwarzheit@hp455g9:~$ sudo parted -l
Modell: KXG80ZNV1T02 KIOXIA (nvme)
Festplatte  /dev/nvme0n1:  1024GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem     Name                          Flags
 1      1049kB  274MB   273MB   fat32           EFI system partition          boot, esp
 2      274MB   290MB   16,8MB                  Microsoft reserved partition  msftres
 3      290MB   108GB   108GB   ntfs            Win11                         msftdata
 5      108GB   162GB   53,5GB  ext4            /
 6      162GB   330GB   168GB   ext4            home
 7      330GB   373GB   43,0GB  linux-swap(v1)  swap                          swap
 8      373GB   1023GB  651GB   ext4            Daten
 4      1023GB  1024GB  915MB   ntfs            Basic data partition          versteckt, diag


schwarzheit@hp455g9:~$ mokutil --sb-state
SecureBoot disabled
schwarzheit@hp455g9:~$

Nochmal:

• Kein Linux braucht SB.

• Und NUR ein verschlüsseltes Win braucht es.