Bullseye ist "fertig"

[mcb]

Hab mich auch "getraut" Bullseye zu installieren, mich aber nicht entsprechend vorbereitet und die Quittung dafür bekommen . Auf meinem Thinkpad T410 funktioniert kein Suspend/Hibernate mehr mit dem 5.X Kernel . Der Bildschirm wird schwarz und der Laptop läuft im Hintergrund weiter, reagiert aber auf nichts mehr. Scheint ein häufigeres Problem auf dem Rechner zu sein: https://forum.xfce.org/viewtopic.php?id=14394. Lösung hab ich - auf die Schnelle - noch keine gefunden. Bin also wieder auf Buster zurück; Mit dem 4.19er Kernel klappt alles wunderbar.
Von daher schon mal die Empfehlung an alle mit ähnlicher Hardware: Immer vorher mit der LiveCD ausprobieren (es sei denn Suspend ist euch egal ).

Das ist nicht gut, liegt aber an Xfce ?

- du könntest aus Spaß mal den Backportkernel unter Buster probieren? Kann man ja schnell Rückgängig machen.
- alternativ Gnome unter Bullseye

[willy4711]

Ich glaub nicht, dass es an der Hardware liegt.
(Xfce /Testing)
Ich hab das Problem mit einem ausgewachsenen Rechner (Suspend to RAM) schon seit Ewigkeiten.

Ob das mal klappt oder nicht scheint irgendwie am Sonnenstand oder anderen mir unbekannten
Konfigurationen des Himmels zu liegen.

Jedenfalls startet meine Büchse nach dem Suspend sofort wieder durch. Logs dazu sind nicht zu finden.
Suspend to Disk funktioniert zwar, aber ein Neustart ist schneller.

Also hab ich mich daran gewöhnt, und gönne meiner Büchse auch mal ne "Zicke"

[dasebastian]

Braucht ein Rechner mit SSD Suspend/HIbernate noch?

[keep3r]

[...]

Das ist nicht gut, liegt aber an Xfce ?

- du könntest aus Spaß mal den Backportkernel unter Buster probieren? Kann man ja schnell Rückgängig machen.
- alternativ Gnome unter Bullseye

Ich glaube nein. Der OP aus dem XFCE Forum hatte es nur ursprünglich dort vermutet; Darum landete es in dem Forum. Backports werd ich evtl. mal probieren

Ich glaub nicht, dass es an der Hardware liegt.
(Xfce /Testing)
Ich hab das Problem mit einem ausgewachsenen Rechner (Suspend to RAM) schon seit Ewigkeiten.

Ob das mal klappt oder nicht scheint irgendwie am Sonnenstand oder anderen mir unbekannten
Konfigurationen des Himmels zu liegen.

Jedenfalls startet meine Büchse nach dem Suspend sofort wieder durch. Logs dazu sind nicht zu finden.
Suspend to Disk funktioniert zwar, aber ein Neustart ist schneller.

Also hab ich mich daran gewöhnt, und gönne meiner Büchse auch mal ne "Zicke"

Okay Für mich ist "Suspend to Ram" eines der wichtigsten Features überhaupt. Auf dem Gerät hat das die letzten 10 Jahre auch immer tadellos funktioniert. Sowohl unter Xubuntu, als auch unter Debian. Bei zwei etwas jüngeren Laptops hat suspend sogar mit dem 5.Xer Kernel ganz normal funktioniert. "Suspend to Disk"/Hibernate nutze ich dagegen so gut wie nie, weils mir auch zu lange dauert (ging aber auf dem Thinkpad unter 5.X auch nicht mehr).

Braucht ein Rechner mit SSD Suspend/HIbernate noch?

Gute Frage ... Ich persönlich, JA . Mobile Geräte verschlüssle ich inzwischen üblicherweise mit Luks2 und einem längeren Passphrase. Wenn das Gerät zu Hause steht, verwende ich es meist mehrmals am Tag und "suspende" es wenn ich länger Pause oder was anderes mach (dann muss ich nicht jedesmal den Passphrase eingeben). Ein jüngeres Gerät würd ich evtl. einfach durchlaufen lassen, aber muss ja nicht sein .

[dasebastian]

Ein jüngeres Gerät würd ich evtl. einfach durchlaufen lassen, aber muss ja nicht sein .

Ich fahre meinen alten Panzer immer runter seit HDD-Austausch gegen SSD. Diese paar Sekunden und Tasten...

[edmund]

Braucht ein Rechner mit SSD Suspend/HIbernate noch?

Wahrscheinlich nicht.

[fischig]

Ich fahre meinen alten Panzer immer runter seit [...]. Diese paar Sekunden und Tasten...

Sehe ich genauso.

Sinn macht suspend/hibernate für mich dann, wenn die Maschine zu bestimmten Zeiten rtcwake aufwachen soll.

[mcb]

Ich kann mir nicht recht vorstellen das es am Kernel liegt. Laufen doch so viele Thinkpads mit Debian ?!?

Ev. kann ich mal auf einem R500 testen. Ja Standby braucht man nicht unbedingt, aber am Laptop sollte das schon gehen.

[tijuca]

Die Ursache liegt vermutlich im TPM. Ich hatte damals als der Kerne 5.x in testing auftauchte folgendes erstellt und seit dem funktioniert auch S2RAM wieder.

Code: Alles auswählen

$ cat /etc/modprobe.d/blacklist-tpm.conf 
# Prevent TPM from loading. It breaks suspend and power cycle.
blacklist tpm
blacklist tpm_crb
blacklist tpm_tis
blacklist tpm_tis_core

[willy4711]

Die Ursache liegt vermutlich im TPM. Ich hatte damals als der Kerne 5.x in testing auftauchte folgendes erstellt und seit dem funktioniert auch S2RAM wieder.

Geil Das hat wirklich funktioniert

4 mal Bereitschaft selbst mit offenen VM's

Das einzige was anscheinend keine Lust auf Suspend to RAM ist mein VPN (Purevpn)
Das quittiert die Bereitschaft mit fehlendem Netz (LAN).
Netz neu gestartet ---> gut.

Aber ich habe nicht die geringste Ahnung, was ich da gerade "verzapft" habe

Es gibt kein einziges Paket bei mir, das mit Trusted Platform Module (TPM) zu tun haben könnte.
Nur ein Paket führt die Buchstaben tpm im Namen libnatpmp1, hat aber wohl
damit nichts zu tun.

Ich wäre dir wirklich dankbar, wenn du ein paar aufklärende Wort dazu bringen könntest.

Vielleicht noch ein paar wahrscheinlich wichtige Teile meiner Büchse:

Unverschlüsselt, kein UEFI / Testing / Xfce

Code: Alles auswählen

Machine:   Type: Desktop Mobo: ASRock model: Z390 Extreme4 serial: <superuser required> UEFI [Legacy]: American Megatrends 
           RAM Report: permissions: Unable to run dmidecode. Root privileges required. 
CPU:       Info: 8-Core model: Intel Core i9-9900 bits: 64 type: MT MCP L2 cache: 16 MiB 

[funkymaster]

Änderungen: https://www.debian.org/releases/bullsey ... ex.de.html

Edit: Link von testing auf bullseye korrigiert.

[mcb]

Ah dort steht es ja auch:

https://www.debian.org/releases/testing ... ml#rc-bugs

#991788 - xfce4-settings black screen after suspend when laptop lid is closed and re-opened - Debian Bug report logs:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=991788

Ich weiß nicht wie Debian das handhabt

- werden de Feher mit einem Pointrelease behoben oder

- bleiben sie (stable = bloß keine Änderung)

[edmund]

Bullseye wird gerade zu stable:
FTP-masters have moved "buster" to the oldstable alias in preparation for promoting testing to "bullseye"

"Debian's CD team is warming up their build server - did you know it uses 88 CPUs, 377GiB of RAM and over 8TiB of SSDs to generate images for bullseye's 9 architectures?"

https://micronews.debian.org/2021/16289 ... um=twitter

[ralli]

Langsam kommen sie auf Touren :

https://micronews.debian.org/2021/16289 ... um=twitter

Gruß ralli

[whisper]

88 CPUs, 377GiB of RAM and over 8TiB of SSDs to generate images for bullseye's 9 architectures?"

Hui! Nee, da staune ich aber nun wirklich, was für eine riesige Infrastruktur da vorhanden ist

[edmund]

88 CPUs, 377GiB of RAM and over 8TiB of SSDs to generate images for bullseye's 9 architectures?"

Hui! Nee, da staune ich aber nun wirklich, was für eine riesige Infrastruktur da vorhanden ist

Wer mal Firefox oder die qt5-webengine selber kompiliert hast, weiß wieso.

[TRex]

Wir können die quotes aus dem Titel streichen

[smutbert]

und @frox zum Sieg der Release-Wette gratulieren

[ralli]

Tor, Toooor. der Balli ist drin! Und Bullseye draußen.
Danke an alle Entwickler, die dieses ermöglicht haben. Ich installiere grundsätzlich immer neu. Gute Arbeit, alles reibungslos.

Grüße ralli

[willy4711]

Tor, Toooor. der Balli ist drin! Und Bullseye draußen.
Danke an alle Entwickler, die dieses ermöglicht haben. Ich installiere grundsätzlich immer neu. Gute Arbeit, alles reibungslos.

Das ist aber nur ein Pfostenschuss bei einer Neuinstallation

Ansonsten schließe ich mich mal dem Lob an

6,3 GB ---> 4 VM's von Stable nach Stable Full-Upgrade (LXQT - Mate - Xfce - KDE)
Bis auf KDE ist alles reibungslos gelaufen.
Bei KDE vermute ich bei mIr 2 Fehler:
1. Hatte vor einer Woche auf Wayland umgestellt
2) Autologin.
Jetzt gibt es nur noch den Rettungsmodus. (beide Kernel)
Hab aber momentan absolut keinen Lust in einem Mini-Fenster nach Fehlern zu suchen ,
werde mir also den Luxus einer Neuinstallation der VM zu erlaube,

Nun noch einen Frage.
Ich habe in meinen sources.list(en) durchgängig stable bzw. testing stehen.

nun kommt naturgemäß beim update die Frage:

Code: Alles auswählen

N: Für das Depot »http://deb.debian.org/debian stable InRelease« wurde der »Version«-Wert von »10.10« in »11.0« geändert.
E: Für das Depot »http://deb.debian.org/debian stable InRelease« wurde der »Codename«-Wert von »buster« in »bullseye« geändert.
N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie weitere Informationen benötigen.
Möchten Sie diese Änderungen übernehmen und mit der Aktualisierung von diesem Depot fortfahren? [j/N] 

Wo wird das eigentlich hingeschrieben ? ich finde nichts im Verzeichnis /etc/apt

[mcb]

https://fasttrack.debian.net/

Ist gerade nicht online. Falls sich noch jemand wundert wieso apt Fehler schmeißt.

[hikaru]

88 CPUs, 377GiB of RAM and over 8TiB of SSDs to generate images for bullseye's 9 architectures?"

Hui! Nee, da staune ich aber nun wirklich, was für eine riesige Infrastruktur da vorhanden ist

So viel ist das gar nicht. Wenn man die Zahlen 1:1 für voll nimmt, dann bedeutet das, dass jeder der 88 Rechner im Schnitt nur gut 4GiB RAM und nicht mal eine 100GiB-SSD hat. Das wären also individuell gesehen eher unterdurchschnittlich ausgestattete Rechner. Mit 4GiB RAM (ohne Swap) kriegt man manche Pakete gar nicht gebaut.
Aber hier geht's ja auch nur um das Zusammenschieben von Images, vermutlich mit jigdo. Dafür ergeben 88 Rechner eigentlich keinen Sinn. Ich würde eher einen Rechner pro Architektur nehmen, daher vermute ich, die "88 CPUs" sind eigentlich 88 CPU-Kerne. Nimmt man an, dass das im Schnitt 8-Kern-CPUs sind, dann wären das 11 Rechner mit je 34GiB RAM und gut 700GiB SSD-Speicher. Der RAM pro Rechner erscheint mir realistisch (dann kann jigdo alle Pakete im RAM ablegen), aber 700GiB SSD-Speicher ergäbe wenig Sinn.
Ich denke deshalb, dass es eher sowas wie 1-2 TiB pro Rechner für den Imagebau sind und der Rest liegt an zentraler Stelle in einer RAID-Konfiguration.

[segmentationfault]

Hallo zusammen,

ich habe auch gestern und vorgestern meine Rechner von buster auf bullseye umgestellt. Beides Neuinstallationen auf den entsprechenden Partitionen und unveränderte /home Partition sowie wo nur Daten liegen. Läuft alles bestens.

Gruß
segmentationfault

[KP97]

Wir können die quotes aus dem Titel streichen...

Nicht nur das. Da ja jetzt jeder, der ein Upgrade gemacht hat, meint, das der Forengemeinde unbedingt mitteilen zu müssen, gehört das sicher nach Smalltalk.

[mcb]

So die ersten backports gibt es auch schon.

Code: Alles auswählen

inxi:
  Installed: 3.3.01-1-1
  Candidate: 3.3.01-1-1
  Version table:
     3.3.06-1-1~bpo11+1 100
        100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages
        100 https://deb.debian.org/debian bullseye-backports/main i386 Packages
 *** 3.3.01-1-1 600
        600 https://deb.debian.org/debian bullseye/main amd64 Packages
        600 https://deb.debian.org/debian bullseye/main i386 Packages
        100 /var/lib/dpkg/status
marc@mb:~$ 

https://ftp-master.debian.org/backports-new.html

Fasttrack läuft auch.

Wenn es interessiert es gibt noch:

Code: Alles auswählen

# fasttrack / staging
deb https://fasttrack.debian.net/debian/ bullseye-fasttrack main contrib
deb https://fasttrack.debian.net/debian/ bullseye-backports-staging main contrib