
Hallo Liste, ich habe ein großes Problem: Ich habe heute eine VM von 15.1 nach 15.2 geupdatet. Leider klappt die Installation des neuen Kernels nicht. installing package kernel-default-5.3.18-lp152.63.1.x86_64 needs 23MB on the /boot filesystem /boot ist eine eigene Partition mit 109MB Größe Ich habe schon alle Kernel-Pakete bis auf den laufenden gelöscht und auch schon alle vmlinu* und initrd* Dateien nach /tmp/boot veschoben. Laut df -h habe ich 90MB auf /boot frei. Die Partition vergrößern geht leider auch nicht, da /boot die erste Partition auf der Platte ist. Danke schon mal Andreas

Ich kenne diese Meldung auch, aber auf / da ich auch /usr/src/linux* für die vielen Kernel vorhalte. Soweit ich dann mit einem df -h nachgeprüft habe, fehlt in dem Meldungstext ein "more" also benötigst du vmtl. 122 MB statt der 109 die gerade zur Verfügung stehen. Viele Grüße Ralf

Am 07.03.2021 um 22:23 schrieb Ralf Czekalla:
Ich kenne diese Meldung auch, aber auf / da ich auch /usr/src/linux* für die vielen Kernel vorhalte. Soweit ich dann mit einem df -h nachgeprüft habe, fehlt in dem Meldungstext ein "more" also benötigst du vmtl. 122 MB statt der 109 die gerade zur Verfügung stehen.
Viele Grüße Ralf
Danke für die Info, hat sich da so viel seit 15.1 geändert? Dort hatte ich das Problem auch immer. Aber es ließ sich sehr einfach durch Entfernen der alten Kernel lösen. Warum klappt das bei 15.2 nicht mehr? Gruß Andreas

Am 07.03.21 um 20:06 schrieb Andreas Bock:
... Ich habe schon alle Kernel-Pakete bis auf den laufenden gelöscht und auch schon alle vmlinu* und initrd* Dateien nach /tmp/boot veschoben. ...
Das Problem hatte ich beim Übergang 15.1 auf 15.2 auch - ich habe dann tatsächlich auch den laufenden Kernel gelöscht, da ich bezüglich meines Backups sicher war. Letztendlich brauchte ich dann natürlich doch eine Neuinstallation, da ja kein Kernelupdate mehr durchlief. Verschieben und Vergrößern der Partitionen hatte ich an ähnlicher Hardware erfolgreich probiert - nur im Ernstfall ging das dann so schief, dass mir gar nichts anders übrig blieb. Wieso der Platzbedarf auf /boot auf einmal so gestiegen ist, hat sich mir nicht erschlossen. Zudem konnte der neue Installer nicht mehr einfach (wie der alte) ein verschlüsseltes System installieren, da er /boot standardmäßig nicht mehr als extra unverschlüsseltes Filesystem anlegt und man so beim Booten immer zwei Mal die Passphrase eingeben muss. Da war Handarbeit beim Partitionieren nötig. Wenigstens geht jetzt endlich das Suspend-to-Disk richtig, das vorher sporadische Hänger produzierte. Das alte System dürfte durch Upgrades aus 42.1 oder 42.3 entstanden gewesen sein. -- Viele Grüße Michael ________________________________________________________________________ PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt HR: Amtsgericht Darmstadt, HRB 8383 Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz, Dr. Karsten Theis Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) ________________________________________________________________________

Am 08.03.2021 um 18:44 schrieb Michael Behrens:
Am 07.03.21 um 20:06 schrieb Andreas Bock:
... Ich habe schon alle Kernel-Pakete bis auf den laufenden gelöscht und auch schon alle vmlinu* und initrd* Dateien nach /tmp/boot veschoben. ...
Das Problem hatte ich beim Übergang 15.1 auf 15.2 auch - ich habe dann tatsächlich auch den laufenden Kernel gelöscht, da ich bezüglich meines Backups sicher war.
Letztendlich brauchte ich dann natürlich doch eine Neuinstallation, da ja kein Kernelupdate mehr durchlief. Verschieben und Vergrößern der Partitionen hatte ich an ähnlicher Hardware erfolgreich probiert - nur im Ernstfall ging das dann so schief, dass mir gar nichts anders übrig blieb.
Wieso der Platzbedarf auf /boot auf einmal so gestiegen ist, hat sich mir nicht erschlossen.
Zudem konnte der neue Installer nicht mehr einfach (wie der alte) ein verschlüsseltes System installieren, da er /boot standardmäßig nicht mehr als extra unverschlüsseltes Filesystem anlegt und man so beim Booten immer zwei Mal die Passphrase eingeben muss. Da war Handarbeit beim Partitionieren nötig.
Wenigstens geht jetzt endlich das Suspend-to-Disk richtig, das vorher sporadische Hänger produzierte. Das alte System dürfte durch Upgrades aus 42.1 oder 42.3 entstanden gewesen sein.
--
Viele Grüße Michael
Hallo Michael, danke für Deine Ausführungen. Da bleibt mir dann halt doch wohl nichts anderes übrig, als die /boot-Partition zu entsorgen und alles neu zu machen. Das die Arbeit ansteht, war mir bewusst, nur wollte ich sie noch ne Weile hinauszögern. Damit werde ich dann auch das historische ReiserFS auf / los was der Grund für eine seperate /boot-Partition war. (Ja, als ich das ursprünglich installiert hab, war ReiserFS der Standard von SUSE) Viele Grüße Andreas

Hallo Michael, hallo zusammen, Am Montag, 8. März 2021, 18:44:35 CET schrieb Michael Behrens:
Zudem konnte der neue Installer nicht mehr einfach (wie der alte) ein verschlüsseltes System installieren, da er /boot standardmäßig nicht mehr als extra unverschlüsseltes Filesystem anlegt und man so beim Booten immer zwei Mal die Passphrase eingeben muss.
Das ist ein lösbares Problem ;-) https://en.opensuse.org/SDB:Encrypted_root_file_system und darin insbesondere der Abschnitt "Avoiding to type the passphrase twice". Ich nutze dieses Setup (ohne separate /boot) seit Jahren, funktioniert problemlos :-) Gruß Christian Boltz --
es ist doch ausgesprochen ruhig hier und das nach dem Release einer neuen openSUSE Version. Sollte es etwa keine Probleme geben? Vermutlich sind alle damit beschaeftigt, kmail2 ans Laufen zu bekommen. Dann gibt es auch wieder Mails :-) [> Marco Röben und Thomas Moritz in opensuse-de]

Am 08.03.21 um 21:43 schrieb Christian Boltz:
Am Montag, 8. März 2021, 18:44:35 CET schrieb Michael Behrens:
... beim Booten immer zwei Mal die Passphrase eingeben muss.
Das ist ein lösbares Problem ;-)
https://en.opensuse.org/SDB:Encrypted_root_file_system und darin insbesondere der Abschnitt "Avoiding to type the passphrase twice".
Ich nutze dieses Setup (ohne separate /boot) seit Jahren, funktioniert problemlos :-)
Danke für den Hinweis. Aber wenn man diesen Artikel nicht gerade präsent hat, ist das manuelle Partitionieren mit dem Installer vielleicht doch einfacher. Ich wundere mich auch, warum der Installer dieses Vorgehen nicht selber implementiert. Insgesamt empfand ich sein Verhalten an dieser Stelle als Rückschritt gegenüber der Version von 42.?, mit dem ich das alte System ursprünglich installiert hatte. Ich muss mich wohl demnächst nochmal an eine teilweise Neuinstallation machen, da ich mich endlich durchgerungen habe, wenigstens das Betriebssystem auf eine SSD zu installieren. Wobei die Daten auf den magnetischen HDs bleiben sollen. Da kommt mir dein Tip also gerade recht :) Ist das mit dem Schlüssel in initrd, wie es da beschrieben wird, eigentlich die einzige Lösung für mehrere verschlüsselte Filesysteme mit einer Passphrase? -- Viele Grüße Michael ________________________________________________________________________ PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt HR: Amtsgericht Darmstadt, HRB 8383 Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz, Dr. Karsten Theis Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) ________________________________________________________________________

Hallo Michael, hallo zusammen, Am Dienstag, 9. März 2021, 08:28:55 CET schrieb Michael Behrens:
Am 08.03.21 um 21:43 schrieb Christian Boltz:
Am Montag, 8. März 2021, 18:44:35 CET schrieb Michael Behrens:
... beim Booten immer zwei Mal die Passphrase eingeben muss.
Das ist ein lösbares Problem ;-)
https://en.opensuse.org/SDB:Encrypted_root_file_system und darin insbesondere der Abschnitt "Avoiding to type the passphrase twice".
Danke für den Hinweis.
Aber wenn man diesen Artikel nicht gerade präsent hat, ist das manuelle Partitionieren mit dem Installer vielleicht doch einfacher.
Ich wundere mich auch, warum der Installer dieses Vorgehen nicht selber implementiert. Insgesamt empfand ich sein Verhalten an dieser Stelle als Rückschritt gegenüber der Version von 42.?, mit dem ich das alte System ursprünglich installiert hatte.
Ich sehe "keine separate /boot-Partition" eher als Feature - mal davon abgesehen, dass der Kernel nicht unverschlüsselt rumliegt [1], verhindert eine separate /boot-Partition z. B. die Nutzung von btrfs- Rollbacks.
Ist das mit dem Schlüssel in initrd, wie es da beschrieben wird, eigentlich die einzige Lösung für mehrere verschlüsselte Filesysteme mit einer Passphrase?
Jein ;-) Die "späte" Passworteingabe während des Bootens (also nicht im GRUB) cacht die Passphrase - wenn mehrere Partitionen die gleiche Passphrase nutzen, musst Du sie nicht erneut eingeben. Falls Du die Passphrase gemäß dem Artikel nur im GRUB eingibst und eine Schlüsseldatei in der initrd hast, brauchst Du für die anderen Partitionen Schlüsseldateien. Die kannst Du z. B. in /root/ ablegen, damit sie sonst niemand auslesen kann. In der initrd müssen diese Schlüsseldateien aber nicht liegen, weil die root-Partition früh genug gemountet wird. Gruß Christian Boltz [1] Kernel und initrd sind zwar nicht wirklich "geheim" [2], aber wenn jemand Zugriff auf Deine Hardware bekommt, macht die Verschlüsselung Manipulationen z. B. am Kernel extrem schwer bis unmöglich. (Bleibt noch der unverschlüsselte GRUB als Restrisiko - aber irgendwie will man ja noch booten können ;-) [2] Zumindest solange die initrd nicht den Verschlüsselungskey für die root-Partition enthält ;-) --
good luck, Usually "good luck" is going together with "as I told you before" :) [> Greg KH and Johannes Nohl in opensuse-project]
participants (4)
-
Andreas Bock
-
Christian Boltz
-
Michael Behrens
-
Ralf Czekalla