Hallo Leute, seit meinem Upgrade auf Debian 12 kann ich mich weder einloggen noch wird der Bootvorgang abgeschlossen. Könnt ihr mir helfen?
Problembeschreibung: Die Kommandozeile (tty; zu erreichen über Strg + Alt + [F1 bis F6]) zeigt „Login incorrect“ an, wenn ich einen Nutzernamen (oder eine andere Zeichenkette) eingebe (und zum Abschluss Return oder Enter drücke (hab beides ausprobiert)). Ein leerer Name (kein Zeichen, sondern gleich Enter bzw. Return drücken) und „root“ zeigen jeweils das gleiche Verhalten. Ausschließen konnte ich, dass das System aufgrund von fehlendem Speicherplatz die Aktualisierung nicht vollenden konnte und mir ein „zerbrochenes“ System zurückgelassen hat. Da ich mit gnome- disks über ein Livesystem nachgeschaut hab, wie voll die einzelnen Partitionen sind, denke ich, das kann man als mögliche Ursache ausschließen.
Die grafische Oberfläche (normal über Strg + Alt + F7 erreichbar) startet erst gar nicht. die letzte Meldung ist nicht bei jedem Bootversuch die selbe, aber „[ OK ] Started Anonymizing overlay network for TCP.“ ist auch dabei (falls das hilft). Nur beginnt jede Kernelmeldung nicht am Zeilen-/Bildschirmanfang, sondern da, wo die vorige aufgehört hat, in der Zeile drunter.
Vielleicht hat mein Problem damit zu tun, dass der Kernel 4.19.0 im GRUB-Menü angezeigt wird und damit scheinbar auch (noch) installiert ist, jedoch nicht der in Debian 12 verwendete (6.1.0). Das ist der, den ich bisher verwendet hab.
Was sagt ihr dazu?
Wenn noch was fehlt, bitte melden :-)
Viele Grüße Julian
PS: Klar könnte ich mein System neuinstallieren. V. a., da ich erst frisch auf ein neues System upgegradet hab. Aber wer will schon seine ganzen Dateien vom Backup rüberkopieren und die individuellen/eigenen Veränderungen am System alle zusammensuchen und – viel wichtiger – auch erneut vornehmen…?
On Thu, Jun 22, 2023 at 07:46:59PM +0200, Julian Schreck wrote:
Hallo Leute, seit meinem Upgrade auf Debian 12 kann ich mich weder einloggen noch wird der Bootvorgang abgeschlossen. Könnt ihr mir helfen?
Problembeschreibung: Die Kommandozeile (tty; zu erreichen über Strg + Alt + [F1 bis F6]) zeigt „Login incorrect“ an, wenn ich einen Nutzernamen (oder eine andere Zeichenkette) eingebe (und zum Abschluss Return oder Enter drücke (hab beides ausprobiert)). Ein leerer Name (kein Zeichen, sondern gleich Enter bzw. Return drücken) und „root“ zeigen jeweils das gleiche Verhalten. Ausschließen konnte ich, dass das System aufgrund von fehlendem Speicherplatz die Aktualisierung nicht vollenden konnte und mir ein „zerbrochenes“ System zurückgelassen hat. Da ich mit gnome- disks über ein Livesystem nachgeschaut hab, wie voll die einzelnen Partitionen sind, denke ich, das kann man als mögliche Ursache ausschließen.
Hm. Es gab mal einen Kernel-Bug, der sowas gemacht hat. Wühlen in den Internetzen deutet auf 4.18.x [0], [1]. Das passt nicht ganz auf Dein 4.19.x, aber die Symptome sind so verdammt ähnlich, dass ich es mir nicht verkneifen kann...
Die grafische Oberfläche (normal über Strg + Alt + F7 erreichbar) startet erst gar nicht. die letzte Meldung ist nicht bei jedem Bootversuch die selbe, aber „[ OK ] Started Anonymizing overlay network for TCP.“ ist auch dabei (falls das hilft). Nur beginnt jede Kernelmeldung nicht am Zeilen-/Bildschirmanfang, sondern da, wo die vorige aufgehört hat, in der Zeile drunter.
Vielleicht hat mein Problem damit zu tun, dass der Kernel 4.19.0 im GRUB-Menü angezeigt wird und damit scheinbar auch (noch) installiert ist, jedoch nicht der in Debian 12 verwendete (6.1.0). Das ist der, den ich bisher verwendet hab.
Was sagt ihr dazu?
Also: ich würde versuchen, in das GRUB-Menü zu kommen und einen anderen Kernel auszuwählen; als Eskalation dann, vielleicht vom Rescue-System (das funktioniert ja, wie Du beschreibst) das System zu booten und dann ein update-grub zu machen.
Du schreibst ja oben, dass genug Platz auf allen Partitionen ist. Ich würde auch double-checken, ob auf der Boot-Partition (so die bei Dir getrennt ist) genug Platz für einen weiteren Kernel samt initramfs wäre; vielleicht ist das beim letzten Update fehlgeschlagen.
lg & drücke die Daumen
[0] https://askubuntu.com/questions/1113704/tty-doesnt-wait-for-password [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873 (die Geräusche kommen alle aus der Ubuntu-Ecke, aber ich glaub', es liegt daran, dass das bei einem "grossen" (LTS)-Upgrade passierte)
Hallo Tomás, danke schon mal so weit :-) Jetzt stellt/-en sich die nächste(n) Frage(n):
* Wo krieg' ich den bzw. einen passenden Kernel her und wie kann ich ihn dann per Livesystem installieren? (Oder gar mit Installationsstick?) Über kernel.org kann ich zwar jeden Kernel runterladen, aber soweit ich weiß, gibt's dort nur die „Rohversionen“ bzw. die unkompilierten oder jedenfalls wahrscheinlich nicht die, die im Debianprojekt verbaut werden bzw. letztendlich im Produktivsystem (z. B. Stable) zum Einsatz kommen.^0 Momentan bietet mir GRUB die Kernel 4.19.0-{14,20,23,24} (also 4.19.0-… …14, …20, …23 und …24) an.
* Kann ich auch „einfach“ mit der Kerneldatei von Debian 12 (wenn ich dann den passenden Kernel gefunden habe) einen im System bestehenden austauschen (und die Datei absichtlich falsch benennen, ja genau), damit mein System denkt, es bootet mit dem Kernel z. B. 6.1.0, aber eigentlich bekommt es 4.19.0? Damit würde ich schon mal vermeiden, manuell in der grub.cfg (o. ä.) rumzuhantieren, müsste dann aber im Weiteren aufpassen, diesen (und erst mal nur genau diesen) Kernel zu löschen, nachdem ich ihn nochmal, allerdings unter seinem richtigen „Namen“ installiert habe.
* Im recovery mode kommt nicht mal eine Kernelmeldung; der Bildschirm hat nur die blinkende Eingabemarke links oben im Eck.
* Würde es dir bzw. euch helfen, wenn ich den Bootvorgang filmen würde? (Ich frage hier aus Verzweiflung.)
* Könnte ich auch in einem Livesystem meine Festplatte einhängen und mit chroot mit dem Update weitermachen? Wo seht ihr da die Gefahren?
Viele Grüße Julian -- ^0 : Ich gehe hier von so Änderungen aus, wie sie z. B. zwischen der Debian-, Mint- und Ubuntuversion von Paketen sind. Die drei Systeme basieren auf bzw. sind Debian, aber unterscheiden sich ja nicht nur darin, welche Pakete im Repository liegen, sondern auch, in welcher Version. Z. B. basiert Mint 21.1 auf Ubuntu 22.04 und das auf Debian Unstable in der damaligen Version, wie das Mergen beschlossen wurde. Ist gerade aber eigentlich auch egal. --
Hallo Leute, seit meinem Upgrade auf Debian 12 kann ich mich weder einloggen noch wird der Bootvorgang abgeschlossen. Könnt ihr mir helfen?
Problembeschreibung: Die Kommandozeile (tty; zu erreichen über Strg + Alt + [F1 bis F6]) zeigt „Login incorrect“ an, wenn ich einen Nutzernamen (oder eine andere Zeichenkette) eingebe (und zum Abschluss Return oder Enter drücke (hab beides ausprobiert)). Ein leerer Name (kein Zeichen, sondern gleich Enter bzw. Return drücken) und „root“ zeigen jeweils das gleiche Verhalten. Ausschließen konnte ich, dass das System aufgrund von fehlendem Speicherplatz die Aktualisierung nicht vollenden konnte und mir ein „zerbrochenes“ System zurückgelassen hat. Da ich mit gnome- disks über ein Livesystem nachgeschaut hab, wie voll die einzelnen Partitionen sind, denke ich, das kann man als mögliche Ursache ausschließen.
Hm. Es gab mal einen Kernel-Bug, der sowas gemacht hat. Wühlen in den Internetzen deutet auf 4.18.x [0], [1]. Das passt nicht ganz auf Dein 4.19.x, aber die Symptome sind so verdammt ähnlich, dass ich es mir nicht verkneifen kann...
Die grafische Oberfläche (normal über Strg + Alt + F7 erreichbar) startet erst gar nicht. die letzte Meldung ist nicht bei jedem Bootversuch die selbe, aber „[ OK ] Started Anonymizing overlay network for TCP.“ ist auch dabei (falls das hilft). Nur beginnt jede Kernelmeldung nicht am Zeilen-/Bildschirmanfang, sondern da, wo die vorige aufgehört hat, in der Zeile drunter.
Vielleicht hat mein Problem damit zu tun, dass der Kernel 4.19.0 im GRUB-Menü angezeigt wird und damit scheinbar auch (noch) installiert ist, jedoch nicht der in Debian 12 verwendete (6.1.0). Das ist der, den ich bisher verwendet hab.
Was sagt ihr dazu?
Also: ich würde versuchen, in das GRUB-Menü zu kommen und einen anderen Kernel auszuwählen; als Eskalation dann, vielleicht vom Rescue-System (das funktioniert ja, wie Du beschreibst) das System zu booten und dann ein update-grub zu machen.
Du schreibst ja oben, dass genug Platz auf allen Partitionen ist. Ich würde auch double-checken, ob auf der Boot-Partition (so die bei Dir getrennt ist) genug Platz für einen weiteren Kernel samt initramfs wäre; vielleicht ist das beim letzten Update fehlgeschlagen.
lg & drücke die Daumen
[0] https://askubuntu.com/questions/1113704/tty-doesnt-wait-for-password [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873 (die Geräusche kommen alle aus der Ubuntu-Ecke, aber ich glaub', es liegt daran, dass das bei einem "grossen" (LTS)-Upgrade passierte)
On Fri, Jun 23, 2023 at 04:02:28PM +0200, Julian Schreck wrote:
Hallo Tomás, danke schon mal so weit :-) Jetzt stellt/-en sich die nächste(n) Frage(n):
Ich versuche sie im Einzelnen zu beantworten. Ganz unten sind meine Fragen :)
- Wo krieg' ich den bzw. einen passenden Kernel her und wie kann ich ihn dann per Livesystem installieren? (Oder gar mit Installationsstick?)
Über kernel.org kann ich zwar jeden Kernel runterladen, aber soweit ich weiß, gibt's dort nur die „Rohversionen“ bzw. die unkompilierten oder jedenfalls wahrscheinlich nicht die, die im Debianprojekt verbaut werden bzw. letztendlich im Produktivsystem (z. B. Stable) zum Einsatz kommen.^0 Momentan bietet mir GRUB die Kernel 4.19.0-{14,20,23,24} (also 4.19.0-… …14, …20, …23 und …24) an.
Das ist nicht ganz so einfech: zum Kernel muss ja das passende initramfs (unter anderem mit den Modulen, die Deine Hardware für die frühe Phase des Bootvorgangs braucht) herumliegen. Der wird beim Installieren des jeweils neuen Kernels mit mkinitramfs gebaut. Das sieht bei mir etwa so aus:
tomas@trotzki:~$ ls -l /boot total 79736 -rw-r--r-- 1 root root 83 Apr 22 14:24 System.map-5.10.0-22-amd64 -rw-r--r-- 1 root root 83 May 12 06:08 System.map-5.10.0-23-amd64 -rw-r--r-- 1 root root 236469 Apr 22 14:24 config-5.10.0-22-amd64 -rw-r--r-- 1 root root 236469 May 12 06:08 config-5.10.0-23-amd64 drwxr-xr-x 5 root root 4096 May 23 13:33 grub -rw-r--r-- 1 root root 33478690 May 2 18:32 initrd.img-5.10.0-22-amd64 -rw-r--r-- 1 root root 33481629 May 16 09:52 initrd.img-5.10.0-23-amd64 drwx------ 2 root root 16384 Oct 30 2017 lost+found -rw-r--r-- 1 root root 7035328 Apr 22 14:24 vmlinuz-5.10.0-22-amd64 -rw-r--r-- 1 root root 7036256 May 12 06:08 vmlinuz-5.10.0-23-amd64
Zwei Kernel: "vmlinuz-5.10.0.22-amd64" und "...-23-amd64", dazu die zwei passenden initramfs "initrd.img-5.10.0-22-amd64" und "...-23-amd64".
- Kann ich auch „einfach“ mit der Kerneldatei von Debian 12 (wenn ich dann den passenden Kernel gefunden habe) einen im System bestehenden austauschen (und die Datei absichtlich falsch
benennen, ja genau), damit mein System denkt, es bootet mit dem Kernel z. B. 6.1.0, aber eigentlich bekommt es 4.19.0? Damit würde ich schon mal vermeiden, manuell in der grub.cfg (o. ä.) rumzuhantieren, müsste dann aber im Weiteren aufpassen, diesen (und erst mal nur genau diesen) Kernel zu löschen, nachdem ich ihn nochmal, allerdings unter seinem richtigen „Namen“ installiert habe.
Wenn Du Glück hast, alles an die richtige Stelle bringst, etc. -- dann kann das klappen. Aber: Du musst mindestens das initramfs (soweit ich weiss liefert der Installer eins, das generisch genug ist, um eine Chance zu haben), dann musst Du noch Grub sagen, dass es da einen neuen Kernel gibt; entweder über "grub-install", dann für das nächste Boot, oder aber in der Grub-Kommandozeile, während des Boots.
- Im recovery mode kommt nicht mal eine Kernelmeldung; der Bildschirm hat nur die blinkende Eingabemarke links oben im Eck.
Ich meinte nicht "recovery", sondern "rescue": du schnappst Dir ein Installations-USB, bootest davon, und sagst nicht "install", sondern suchst unter "advanced" den "rescue mode": der startet ein Minimal- Debian, unter dem Du u.a. Deine Platten mounten kannst, usw.
Ein wenig wie live, nur etwas schneller, dafür weniger komfortabel.
Von da aus kannst Du Dein "normales" root einbinden und versuchen, z.B. mit apt-get einen neuen Kernel zu installieren.
- Würde es dir bzw. euch helfen, wenn ich den Bootvorgang filmen würde? (Ich frage hier aus Verzweiflung.)
Hm. Ich glaube nicht, dass ich viel damit anfangen könnte.
- Könnte ich auch in einem Livesystem meine Festplatte einhängen und mit chroot mit dem Update weitermachen? Wo seht ihr da die Gefahren?
Genau das ist es, was das rescue-System für Dich macht. Du kannst auch Deine Platte in ein "Drittsystem" einbinden und mit etwas Glück und Geschick da hin chrooten (Du musst ein paar Spezialdateisysteme in Deinem chroot verfügbar machen, so etwa
mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev
... aus dem Kopf, bitte überprüfen; ich habe angenommen, dass Du in /mnt das Dateisystem eingebunden hast, in das Du chrootest). Rescue mode macht das alles für Dich.
OK, hier meine Fragen:
- eine reale Möglichkeit ist, dass das Installieren des letzen Kernels mangels Platz schiefgegangen ist. Hast Du genug? - hast Du versucht, von der grub-Kommandozeile aus einen anderen Deiner vielen Kernels zu starten?
viel Glück, lg
- eine reale Möglichkeit ist, dass das Installieren des letzen Kernels mangels Platz schiefgegangen ist. Hast Du genug?
laut gnome-disks:
/dev/sda1: 1,1 GB groß (3,4 % belegt) Partitionstyp: BIOS-Boot (ext2) /dev/sda2: 1,1 GB groß (0,6 % belegt) Partitionstyp: EFI-System (FAT (32-Bitversion)) /dev/sda6: 1,0 GB groß (14,9 % belegt) Partitionstyp: Linux-Dateisystem (ext2)
Soweit ich weiß, reicht das locker. Interessant ist vielleicht, daß /dev/sda1 gar nicht in der /etc/fstab steht (Partitionierung: GUID-Partitionstabelle). /dev/sda1 ist eintragslos (außer „lost+found“); /dev/sda2 hat nur einen Ordner „EFI“; /dev/sda6 hat die vier Kernel (am Mailende).
- hast Du versucht, von der grub-Kommandozeile aus einen anderen Deiner vielen Kernels zu starten?
Falls du die (grafische) Liste meinst, die kommt, wenn man „Advanced options for Debian BNU/Linux“ auswählt: ja. Die vier Kernel hab ich durchprobiert, auch im recovery mode. Ergebnis: (praktisch) unverändert (bzw. ich bekomm' die „verschobenen/eingerückten Kernelmeldungen“ nicht mehr bei allen Kerneln angezeigt). Falls du meinst, daß ich „‚e‘ zum Bearbeiten der Befehle vor dem Booten“ hergenommen habe: nein. Falls du meinst, daß ich „‚c‘ für eine Befehlszeie“ hergenommen habe: nein.
Ist interessant, daß bei mir der GRUB noch mit „GNU GRUB Version 2.06-3~deb10u3“ (speziell „deb10“) überschrieben ist?
Eine Meldung ist aus dem recovery mode vielleicht interessant: [zeit] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
. Hilft die was? (Wahrscheinlich nicht.) Ich mach' mich mal an besagten rescue mode. Sind schon neue Fragen aufgekommen?
Mailende: $ ls -ahlF /media/amnesia/* /media/amnesia/99e52393-949a-42f5-80ef-abc389899a9c: insgesamt 114M drwxr-xr-x 5 root root 4,0K 12. Jun 19:49 ./ drwxr-x---+ 6 root root 120 26. Jun 15:59 ../ -rw-r--r-- 1 root root 202K 30. Jan 2021 config-4.19.0-14-amd64 -rw-r--r-- 1 root root 202K 17. Mär 2022 config-4.19.0-20-amd64 -rw-r--r-- 1 root root 202K 20. Dez 2022 config-4.19.0-23-amd64 -rw-r--r-- 1 root root 202K 29. Apr 20:07 config-4.19.0-24-amd64 drwxr-xr-x 2 root root 4,0K 24. Jan 2020 efi/ drwxr-xr-x 5 root root 4,0K 12. Jun 19:47 grub/ -rw------- 1 root root 674K 9. Jun 2021 initrd.img-4.19.0-14-amd64 -rw-r--r-- 1 root root 27M 11. Jun 2022 initrd.img-4.19.0-20-amd64 -rw-r--r-- 1 root root 27M 1. Apr 13:41 initrd.img-4.19.0-23-amd64 -rw-r--r-- 1 root root 27M 12. Jun 19:49 initrd.img-4.19.0-24-amd64 drwx------ 2 root root 16K 24. Jan 2020 lost+found/ -rw-r--r-- 1 root root 3,3M 30. Jan 2021 System.map-4.19.0-14-amd64 -rw-r--r-- 1 root root 3,3M 17. Mär 2022 System.map-4.19.0-20-amd64 -rw-r--r-- 1 root root 3,3M 20. Dez 2022 System.map-4.19.0-23-amd64 -rw-r--r-- 1 root root 3,3M 29. Apr 20:07 System.map-4.19.0-24-amd64 -rw-r--r-- 1 root root 5,1M 30. Jan 2021 vmlinuz-4.19.0-14-amd64 -rw-r--r-- 1 root root 5,1M 17. Mär 2022 vmlinuz-4.19.0-20-amd64 -rw-r--r-- 1 root root 5,1M 20. Dez 2022 vmlinuz-4.19.0-23-amd64 -rw-r--r-- 1 root root 5,1M 29. Apr 20:07 vmlinuz-4.19.0-24-amd64
- hast Du versucht, von der grub-Kommandozeile aus einen anderen Deiner vielen Kernels zu starten?
Ich hab' mir alle Kommandos angeguckt und keins gefunden, das mir zugesagt hätte. Schwebt dir ein bestimmter Weg bzw. ein bestimmtes Vorgehen (inkl. Kommandos) vor? Unter dem Installationsstick mit Debian 12 konnte ich keinen GRUB ohne Basissystem installieren, was eine Festplattenpartitionierung vorausgesetzt hätte. (Ich bekam die entsprechende Fehlermeldung.) Und mein System neu aufsetzen wollte ich ja möglichst umgehen.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hallo Julian,
Am Donnerstag, dem 22.06.2023 um 19:46 +0200 schrieb Julian Schreck:
Hallo Leute, seit meinem Upgrade auf Debian 12 kann ich mich weder einloggen noch wird der Bootvorgang abgeschlossen. Könnt ihr mir helfen?
[...]
Vielleicht hat mein Problem damit zu tun, dass der Kernel 4.19.0 im GRUB-Menü angezeigt wird und damit scheinbar auch (noch) installiert ist, jedoch nicht der in Debian 12 verwendete (6.1.0). Das ist der, den ich bisher verwendet hab.
Hast Du das Update von Buster direkt auf Bookworm gemacht?
[...]
Wenn noch was fehlt, bitte melden :-)
Viele Grüße Julian
[...]
CU Jörg - -- New: GPG Fingerprint: 4443 9C15 A011 0C89 2EA8 1E9D E2E1 3D93 1842 DAC7 GPG key : DECFAACFC681D824
Jörg Frings-Fürst D-54470 Lieser
git: https://git.jff.email/cgit/
Threema: HU6U7Z6H Wire: @joergfringsfuerst Skype: jff-skype@jff.email Ring: jff Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Am Mittwoch, dem 28.06.2023 um 10:08 +0200 schrieb Julian Schreck:
Ja. Ist das als Problem bekannt?
Hast Du das Update von Buster direkt auf Bookworm gemacht?
Ja, das geht fast immer schief. Richtig wäre Buster -> Bullseye -> Bookworm.
Empfohlen wird auch da full-upgrade erst nach dem ausrollen des 1 Point Releases zu machen.
Damit ist sichergestellt, dass alle Umsetzungen richtig laufen.
IMHO sieht das ganze nicht nur wir ein Kernel - Problem aus.
Kannst Du mal Dein System Booten, einmal versuchen auf der Konsole 1 einzuloggen und ausschalten.
Dann das Livesystem booten, Deine Platten mounten und aus /var/log/ die Dateien
syslog, daemon.log, kern.log und Xorg.0.log zumailen. Wenn die für hier zu groß sind gerne auch direkt an mich.
CU Jörg
- -- New: GPG Fingerprint: 4443 9C15 A011 0C89 2EA8 1E9D E2E1 3D93 1842 DAC7 GPG key : DECFAACFC681D824
Jörg Frings-Fürst D-54470 Lieser
git: https://git.jff.email/cgit/
Threema: HU6U7Z6H Wire: @joergfringsfuerst Skype: jff-skype@jff.email Ring: jff Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de
On Mon, Jun 26, 2023 at 06:27:11PM +0200, Julian Schreck wrote:
- eine reale Möglichkeit ist, dass das Installieren des letzen Kernels mangels Platz schiefgegangen ist. Hast Du genug?
laut gnome-disks:
/dev/sda1: 1,1 GB groß (3,4 % belegt) Partitionstyp: BIOS-Boot (ext2) /dev/sda2: 1,1 GB groß (0,6 % belegt) Partitionstyp: EFI-System (FAT (32-Bitversion)) /dev/sda6: 1,0 GB groß (14,9 % belegt) Partitionstyp: Linux-Dateisystem (ext2)
Sieht gut aus.
Sorry, dass ich länger off-list war. Etwas eng zur Zeit, nächste Woche besser.
Jörg hat da was gefunden, andere Antwort.
lg
On Wed, Jun 28, 2023 at 12:29:31PM +0200, Jörg Frings-Fürst wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Am Mittwoch, dem 28.06.2023 um 10:08 +0200 schrieb Julian Schreck:
Ja. Ist das als Problem bekannt?
Hast Du das Update von Buster direkt auf Bookworm gemacht?
Ja, das geht fast immer schief. Richtig wäre Buster -> Bullseye -> Bookworm.
Oh, good catch, war mir nicht aufgefallen. Ja, ein Release-Sprung wird nicht empfohlen.
[...]
Auch gute Punkte.
lg
Hab' mein System zwischenzeitlich gebraucht und jetzt (nach über einer Woche ohne) neu installiert. Allerdings nimmt immer so viel Zeit in Anspruch, das Backup zurückzukopieren, die Pakete nachzuinstallieren und die „Einstellungen“ (z. B. /etc/hosts) manuell vorzunehmen… Ich kann's keinem empfehlen.
Für's nächste Mal: würd's mir bei sowas helfen, dem mit Abstand größten Verzeichnis (/home) eine separate Partition zu geben, um zumindest „das große Kopieren“ nicht machen zu müssen? (Dann müsste ich für diesen Punkt hinterher nur die /etc/fstab um die Zeile mit „/home“ erweitern, seh' ich das richtig?) --
Am Mittwoch, dem 28.06.2023 um 10:08 +0200 schrieb Julian Schreck:
Ja. Ist das als Problem bekannt?
Hast Du das Update von Buster direkt auf Bookworm gemacht?
Ja, das geht fast immer schief. Richtig wäre Buster -> Bullseye -> Bookworm.
Empfohlen wird auch da full-upgrade erst nach dem ausrollen des 1 Point Releases zu machen.
Damit ist sichergestellt, dass alle Umsetzungen richtig laufen.
IMHO sieht das ganze nicht nur wir ein Kernel - Problem aus.
Kannst Du mal Dein System Booten, einmal versuchen auf der Konsole 1 einzuloggen und ausschalten.
Dann das Livesystem booten, Deine Platten mounten und aus /var/log/ die Dateien
syslog, daemon.log, kern.log und Xorg.0.log zumailen. Wenn die für hier zu groß sind gerne auch direkt an mich.
CU Jörg
Hallo Julian,
On 6/28/23 10:08, Julian Schreck wrote:
Ja. Ist das als Problem bekannt?
Hast Du das Update von Buster direkt auf Bookworm gemacht?
Oh, es scheint noch niemand das passende RTFM auf diese Frage rausgesucht zu haben: https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.h...
Only upgrades from Debian 11 (bullseye) are supported. [...] Please follow the instructions in the Release Notes for Debian 11 to upgrade to Debian 11 first if needed.
Liebe Grüße Uwe
-
Julian Schreck -
Jörg Frings-Fürst -
Olav Seyfarth -
tomas＠tuxteam.de -
Uwe Kleine-König