[erledigt] Bullseye und swap und resume/suspend Probleme nach dem ersten Neustart

[ralli]

Also die Installation von Bullsey verlief wirklich problemlos. Aber beim ersten Booten nach der Installation kam es doch zu Problemen, die sich dahingehend äußerten, das während des Bootens auf eine von der Installation selbst erstellten Swap Partition /dev/sdb5 versucht wurde, zuzugreifen, was aber offensichtlich mißlang. Der Bootvorgang stoppte 2 bis 3 Minuten, endete dann aber beim Anmeldemanger Lightdm. Mein Workaround zur Problemlösung sah folgendermaßen aus:

Ich editierte mit nano die folgende Datei:

Code: Alles auswählen

/etc/initramfs-tools/conf.d/resume

und ersetzte

Code: Alles auswählen

RESUME=/dev/sdb5

durch

Code: Alles auswählen

RESUME=none

Dann editierte ich die Datei:

Code: Alles auswählen

/etc/login.defs 

und fügte

Code: Alles auswählen

ALWAYS_SET_PATH yes

hinzu. Jetzt rebootete ich den Rechner neu.

In der Konsole setzte ich nun folgenden Befehl ab:

Code: Alles auswählen

update-initramfs -u

Nun installierte ich gparted und entfernte die Swap /dev/sdb5 Partition, die in einer erweiterten Partiton angelegt wurde. Nun löschte ich den entsprechenden Eintrag in der /etc/fstab.

Dann noch einmal:

Code: Alles auswählen

update-initramfs -u

Rechner neu gestartet und der Spuk war vorbei. Nun bootet mein Bullseye schnell und sicher in den Anmeldemanger, der dann den Mate Desktop startet.

Diese Vorgehensweise hatte ich auch schon beim Vorgänger Debian Buster. Was da genau schief läuft und warum, weiß ich nicht. Vielleicht kann mir das einer unserer Experten erklären.

Im übrigen könnte ich auch (habe ich auch schon mal gemacht), eine Experten Installation machen und generell auf eine Swap Partition verzichten, denn ich habe 16 GB RAM und das reicht ja immer.

Grüße ralli

[dufty2]

Zum eigentlichen Problem kann ich nichts sagen.
Mein Laptop hat auch 16 Gig und deshalb benutze ich auch keinen swap mehr (u.a.).

[hikaru]

Passte der fstab-Eintrag zur Swap-Partition (vermutlich beide per UUID identifiziert)?

ich habe 16 GB RAM und das reicht ja immer.

"640K ought to be enough for anybody."

[ralli]

Passte der fstab-Eintrag zur Swap-Partition (vermutlich beide per UUID identifiziert)?

ich habe 16 GB RAM und das reicht ja immer.

"640K ought to be enough for anybody."

Ja der paßte. Ich habe neu im Expertenmous installiert und bei der Partitonierung die Swap Partiton gelöscht. Damit spar ich mir das anschließende Gefrickel und alles läuft, wie es soll.

Bill Gates hat dementiert, das jemals gesagt zu haben ....

Grüße ralli

[hikaru]

Ja der paßte. Ich habe neu im Expertenmous installiert und bei der Partitonierung die Swap Partiton gelöscht. Damit spar ich mir das anschließende Gefrickel und alles läuft, wie es soll.

Ich meinte die ursprüngliche Installation, die zur Eröffnung dieses Threads geführt hat.

Bill Gates hat dementiert, das jemals gesagt zu haben ....

Irgendjemand hat es gesagt/geschrieben.

[ralli]

Auch wenn es jetzt funktioniert und ich damit leben kann, im Expertenmodus zu installieren, so würde mich trotzdem brennend interessieren, was Debian hier bei einer normalen Installation veranstaltet. Hat denn niemand hier eine Idee? Hab auch schon erlebt, das wenn von einem USB Stick installiert wurde, bei diversen Os alles auf sdb1 geschrieben wurde und der Bildschirm anschließend schwarz blieb. Allerdings nie bei Debian. So etwas hatte ich früher nie. Aber irgendwas ist ja immer.

Gruß ralli

[ralli]

So, ich bin fündig geworden, offenbar existiert dieses Problem schon länger und ist als Bug bekannt. Guckst Du hier:

viewtopic.php?t=166647

Gruß ralli

PS: Ich betrachte das Problem als erledigt.

[hikaru]

Hat denn niemand hier eine Idee?

Doch. Ich vermute, dass die UUIDs von Partition und fstab-Eintrag nicht zusammengpasst haben. Aus welchem Grund auch immer.
Aber um diesen Anfangsverdacht zu bestätigen und nach möglichen Bugs zu suchen müsste man das Problem zunächst nachvollziehen können. Und das geht mit den spärlichen vorliegenden Informationen nicht. Daher meine Frage nach den Original-UUIDs.

[ralli]

Es ist gut möglich, das Deine Vermutung richtig ist. Leider kann ich das jetzt nicht mehr überprüfen, da ich bereits eine Neuinstallation im Expertenmodus vorgenommen habe. Aber wie sehe ich, welche UUID richtig oder falsch ist? Auch wenn eine falsche UUID in die fstab eingetragen wurde, erklärt es ja noch nicht die Ursache, und wie das passieren kann.

Das ich die UUID's mit folgendem Befehl ermitteln kann:

Code: Alles auswählen

ls -l /dev/disk/by-uuid

ist mir bekannt.

Gruß ralli

[ralli]

Hab ein bißchen recherchiert, also das eine falsche UUID vom System (oder grub) erzeugt wird, ist nicht unbedingt so selten. Ich könne noch

Code: Alles auswählen

systemd-analyze blame

ein Analyse vornehmen, welcher Prozess da spinnt, wenn der Bootvorgang pausiert.

Oder in default/grub

Code: Alles auswählen

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

auskommentieren.

Gruß ralli

[MSfree]

Auch wenn es jetzt funktioniert und ich damit leben kann, im Expertenmodus zu installieren

Ich habe den Expertenmodus bisher so gut wie nie genutzt, höchstens mal aus Neugier, um die zusätzlichen Optionen anzusehen.

Die Partitionierung ist aber im normalen und im Expertenmodus völlig identisch. Ich nutze aber auch hier praktisch nie den normalen Weg, das System automatisch partitionieren zu lassen, weil ich eben auch immer ohne Swap installieren, und das geht nicht bei der automatischen Partitionierung. Ich empfinde auch eine 500MB große EFI-Partition als pure Verschwendung für eine 120kByte winzige Datei, die dort hineingeschrieben wird. 1MB wäre da schon viel zu viel, leider ist meines Wissens 100MB die Untergrenze.

Warum du mit deiner Swappartition Probleme hattest, kann ich natürlich nicht nachvollziehen. Knn es sein, daß dort noch ein "altes" Buster-Resumeimage drauflag, mit dem Bullseye dann Probleme hatte?

[ralli]

Hallo MSfree, danke für Deine Informationen, daraus lerne ich auch. Es gibt Neuigkeiten, ich habe eine Neuinstallation durchgeführt (um zu lernen), und dieses mal gab es dieses Swap Problem mit suspend/resume nicht, alles lief nach der Installation und einem Neustart ohne Probleme. Was aber war anders als bei der vorherigen Installation? Ich habe vor der normalen Debian Installation mit Knoppix und gparted die Debian Partition auf der SSD (sda) gelöscht, allerdings ohne eine neue Partiton mit msdos oder GPT vorzunehmen. Und siehe da, nach der normalen Installation fuhr der Rechner problemlos hoch. Ob da vorher noch Reste einer vorherigen Installation auf der SSD war, möglich ist das. Wie auch immer, wir brauchen nicht weiter zu suchen, das Problem ist jetzt wirklich gelöst. Danke allen für Eure Unterstützung und Denkanstöße.

Grüße ralli