[gelöst] Abhilfe gesucht: Bootpartition zu klein(?)

[hnzngrmpf]

Hallo an alle

Vor Jahren habe ich Windows den Rücken gekehrt und mein Notebook für Debian eingerichtet:

Code: Alles auswählen

$ df -h
df: /run/user/1000/doc: Die Operation ist nicht erlaubt
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            1,9G       0  1,9G    0% /dev
tmpfs           379M    1,4M  378M    1% /run
/dev/sda6        58G    6,9G   48G   13% /
tmpfs           1,9G       0  1,9G    0% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
/dev/sda1       194M     84M  100M   46% /boot
/dev/sda7       393G     27G  346G    8% /home
tmpfs           379M     84K  379M    1% /run/user/1000

Bislang konnte ich zwei Linux-Images (A+B) auf /boot unterbringen. Wenn ich auf ein neues Image (C) upgegradet habe, habe ich das ältere (A) der beiden vorhandenen (A+B) gelöscht, dann konnte ich das neueste (C) laden und hatte also immer zwei Linux-Images, zur Sicherheit auch das ältere (B), um bei Start-Problemen beim neuen Image (C) auf das ältere (B) auszuweichen (kann mich nicht erinnern, kam aber vielleicht aber mal vor).

Jetzt bin ich von Debian 10 auf 11 gegangen. Dabei wurde auch gewechselt auf

Code: Alles auswählen

$ aptitude search ~ilinux-image
i A linux-image-5.10.0-10-amd64                                                 - Linux 5.10 for 64-bit PCs (signed)                                                    
i   linux-image-amd64                                                           - Linux for 64-bit PCs (meta-package) 

(* was bedeutet das "A" vor dem Linux-Image?)

Zuvor war auch noch die Version 4.19.xxxxx (weiß nicht mehr genau) geladen. Aber synaptic und "sudo update-initramfs -u" meldeten einen Fehler, dass nicht genügend Speicher auf /boot vorhanden sei (da waren 78% durch 4.19 und 5.10 belegt) und deshalb die boot-optionen nicht aktualisiert werden könnten. Nach Neustart konnte ich 4.19.xxx entfernen und "sudo update-initramfs -u" hatte Erfolg. Jetzt habe ich aber keine zweite Linux-Version zum Starten im Problemfall.

Auf einem PC, den ich vor etwa einem Jahr ebenfalls mit Linux versorgt habe, ist es anders: So weit ich weiß, liegen die Linux-Images nicht auf einer separaten Partition, sondern auf der System(?)-Partition. (edit: Da habe ich keine Probleme, wenn ich neue Linux-Images installieren will).

Lange Vorrede, jetzt meine eigentliche Frage:

Was soll ich tun, damit ich - falls die Linux-Images immer größer werden - auf dem Notebook weiterhin zwei Images habe? Ich könnte mit einem Partitioniertool (welches würdet ihr empfehlen, am liebsten eine Live-CD) andere Partitionen verkleinern, damit ich /boot größer bekomme. Oder ich könnte das System so einrichten, dass zukünftig die Linux-Images nicht auf /boot kommen, sondern auf die System(?)-Partition.

[towo]

Nimm einfach /boot mit auf die / Partition, die 190 MB Verlust kannst Du verschmerzen.

[fischig]

Ich ließe diese ganze Partitionierungsspielerei sein, wenn ich nicht einen triftigen Grund dafür hätte.

[hnzngrmpf]

Nimm einfach /boot mit auf die / Partition, die 190 MB Verlust kannst Du verschmerzen.

Hallo towo

Danke für die Antwort, diese Lösung hätte ich auch präferiert. Aber ich stelle mir das Verschieben von /boot nach / schwierig vor. Partitionsgrößen ändern habe ich schon ein paar mal gemacht, hat immer geklappt. Gibt es eine Anleitung, wie ich das Verschieben von /boot nach / korrekt durchführe und wie ich das System veranlasse, das Linux-System dann von der neuen Partition zu laden?

[debianoli]

Danke für die Antwort, diese Lösung hätte ich auch präferiert. Aber ich stelle mir das Verschieben von /boot nach / schwierig vor. Partitionsgrößen ändern habe ich schon ein paar mal gemacht, hat immer geklappt. Gibt es eine Anleitung, wie ich das Verschieben von /boot nach / korrekt durchführe und wie ich das System veranlasse, das Linux-System dann von der neuen Partition zu laden?

Das sollte auch ohne Live-System klappen, aber zur Sicherheit würde ich mir einen funktionierenden USB-Stick bereithalten. Und natürlich: BACKUP erstellen vor allen Basteleien.

Dann würde ich das so machen:

• Als Root ein Verzeichnis /boot_neu anlegen

• Daten von /boot nach /boot_neu verschieben:

  Code: Alles auswählen

  mv /boot/* /boot_neu

• Boot aushängen:

  Code: Alles auswählen

  umount /boot

• Boot zurückkopieren:

  Code: Alles auswählen

  mv /boot_neu/* /boot/

• den Eintrag für die Boot-Partition im /etc/fstab auskommentieren

• Dann den Boot-Loader neu schreiben lassen:

  Code: Alles auswählen

  update-grub

Dann Reboot. Ich hoffe, ich habe nix übersehen, aber so müsste es klappen.

[hnzngrmpf]

Einlesen in "/boot verschieben" (Infos hierzu auch in einem anderen debianforum-thread) veranlasste mich, es mit meinem Kenntnisstand besser zu lassen und zu gparted von einer live-CD zu greifen. Hat problemlos funktioniert, jetzt hat /boot genügend Platz.

Danke an die Antwortenden, insbesondere debianoli für die Anleitung.

[seth]

gudn tach!

die obige listenhafte beschreibung finde ich sehr hilfreich. ich habe mittlerweile eine sehr aehnliche beschreibung unter
https://cryptsetup-team.pages.debian.ne ... e-system-1
gefunden.
dort steht auch (oberhalb), dass das sogar bei verschluesselten systempartitionen machbar ist.

hat es irgendwelche nachteile, wenn es keine eigene boot-partition mehr gibt, sondern das boot-verzeichnis direkt auf der system-partition klebt?
was ist der vorteil der nutzung von gparted?

zu meinem problem: ich habe zwei partitionen, die zusammen die komplette SSD ausfuellen. eine davon ist die boot-partition, die ebenfalls wie bei hnzngrmpf langsam zu klein fuer debian (v12) ist. die andere ist die verschluesselte system-partition. vergroessern der boot-partition ist also vermutlich nicht moeglich, ohne vorher _alles_ zu loeschen.

gruss
seth

(ps: ich habe diesen meinem beitrag mehrfach ueberarbeitet, weil ich durch recherche einige fragen dann doch selbst beantworten konnte.)

[hikaru]

dort steht auch (oberhalb), dass das sogar bei verschluesselten systempartitionen machbar ist.

Vorausgesetzt, die root-Partition ist luks1-verschlüsselt.
Für gewöhnlich wird deine root-Partition luks2-verschlüsselt sein. Das soll Grub eigentlich ab Version 2.06 ebenfalls können, allerdings gibt es dabei weitere Einschränkungen, was die Verschlüsselungsfunktion angeht.
Ich hatte Anfang des Jahres mal unter Bookworm (damals noch Testing) getestet, bei einem bestehenden luks2-verschlüsselten System mit separater unverschlüsselter /boot-Partition /boot mit auf die root-Partition umzuziehen. Es gelang mir nicht, weil Grub die root-Partition nicht entschlüsseln konnte.

Wenn du das System von vornherein mit dem Gedanken einrichtest, via Grub die root-Partition zu entschlüsseln, und dabei alle Rahmenbedingungen beachtest, dann wird das wohl funktionieren. Aber bei einer bestehenden root-Partition mit "Standardeinstellungen" wird das nichts.