[GELÖST] Boot-Flag auf andere Partition verschieben

[BrotherJ]

Hallo zusammen,

ich möchte im laufenden Betrieb das Bootflag von /dev/sda1 nach /dev/sda3 verlegen, weil mir /boot, das auf /dev/sda1 gemountet ist, einfach bei Kernelupgrades immer wieder Probleme macht.

Code: Alles auswählen

fdisk /dev/sda
Festplatte /dev/sda: 446,6 GiB, 479559942144 Bytes, 936640512 Sektoren
Disk model: MR9361-8i       
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 262144 Bytes / 262144 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x6808a261

Gerät      Boot    Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sda1  *         2048    485375    483328   236M 83 Linux
/dev/sda2          485376 125485055 124999680  59,6G 82 Linux Swap / Solaris
/dev/sda3       125485056 906735615 781250560 372,5G 83 Linux
/dev/sda4       906735616 936638463  29902848  14,3G 83 Linux

Kann ich mit fdisk das Flag einfach neu in den MBR einer anderen Partition eintragen, ohne die Partitionen neu zu formatieren? Ich würde dann das Verzeichnis /boot samt Inhalt auf / ablegen.

Beste Grüße
BrotherJ

[mludwig]

Im fdisk als command a eingeben, um das boot-flag zu setzen, dann fragt er nach der ID der gewünschten Partition. Neupartitionieren ist nicht nötig.

Der MBR (Master Boot Record) sitzt jedoch am Anfang der Festplatte, dort ist dann normalerweise grub installiert. Dort wählst du dann deinen Kernel oder auch dein Betriebssystem aus, unabhängig davon welche Partition mit dem boot-flag markiert wurde. Ich weiß jedoch von einzelnen Mainboards, die sich weigern von Festplatte zu booten, wenn dort keine Partition mit bootflag existiert. Welche dann das boot-flag hatte war aber egal ...

[BrotherJ]

Das klingt ja bereits vielversprechend. Wichtig ist, dass nach dem Ändern über fdisk a nicht neuformatiert werden muss. Die Daten auf /dev/sda3 als "/" sollen ja nicht verloren gehen.

Anderer Alternativ-Gedanke wäre, /dev/sda1 und /dev/sda2 (swap) beides unmounten und beide Partitionen zu löschen, um dann /dev/sda1 als 1GB anzulegen und /dev/sda2 um 1GB kleiner wieder als Swap zur Verfügung zu stellen. Das alles im laufenden Betrieb.

Grüße

BrotherJ

[willy4711]

An sich braucht Linux nach meinem Wissen kein Boot-Flag, wie mludwig ja schon sagte.
Wenn /dev/sda1 Probleme macht, wäre also die Frage, warum. (zu viele Kernel-Versionen >> Platzprobleme?)
Das Boot-Flag zu ändern, wird das Problem mit sda1 nicht ändern, da Grub diese Partition anspricht.
Ich vermute mal, dass sda1 als /boot gemountet ist ?
Vielleicht mal:

Code: Alles auswählen

~$ df |grep /dev/

[mludwig]

Beide Partitionen löschen und mit geänderten Größen neu anlegen kann man machen. Vorher /boot und swap unmounten. Die 3. Partition bleibt dabei unberührt.

Aber: vom Inhalt der Boot-Partition vorher ein Backup erstellen, und nachdem anlegen, formatieren und mounten der Boot-Partition wieder einspielen. Sonst sind die Kernel-Images weg ...

[BrotherJ]

Beide Partitionen löschen und mit geänderten Größen neu anlegen kann man machen. Vorher /boot und swap unmounten. Die 3. Partition bleibt dabei unberührt.

Aber: vom Inhalt der Boot-Partition vorher ein Backup erstellen, und nachdem anlegen, formatieren und mounten der Boot-Partition wieder einspielen. Sonst sind die Kernel-Images weg ...

So hatte ich das vor. /dev/sda1 ist zu klein dimensioniert wurden. Und das System wird nicht crashen, wenn für den Zeitpunkt des Neuanlegen der Swap-Partition, die Swap-Partition nicht zur Verfügung steht?

[willy4711]

Ich wage zu bezweifeln , das so einfach funktioniert, lasse mich aber gerne eines Besseren belehren.

Was ist mit den Dateien ./boot/config-xxxxx-amd64 und /boot/System.map xxxx1-amd64
Lassen die so einfach woanders hin verschieben ?
Mal abgesehen, dass die UUIDs ja alle angepasst werden müssen?

Ist es da nicht einfacher ein paar Kernel-Images zu löschen ?
Bei mir ist /boot 71 MB groß (1 Kernel)
Ich bin gespannt, ob das funktioniert.

[BrotherJ]

Das sind nur zwei Kernelimages drin. Das Laufende und ein Aktuelles von Proxmox, das Laufende kann ich wohl schlecht löschen. Und das Aktuelle will ich ja nutzen, nur bricht die Installation ab wegen Platzmangel:

Code: Alles auswählen

# df -h /boot
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1       225M    167M   43M   80% /boot

Ich hatte jetzt zumindest mal /boot gesichert, ungemountet und stattdessen eine Kopie davon /boot_neu auf /dev/sda3 als /boot nach dem Unmounten zur Verfügung gestellt. So funktionierte zumindest das Upgrade. Jetzt könnte ich ja auch diesen neuen Inhalt auf /dev/sda1 einspielen und dann diese Partition wieder als /boot mounten.

[willy4711]

Dein /swap ist ja auch extrem groß

Code: Alles auswählen

/dev/sda2          485376 125485055 124999680  59,6G 82 Linux Swap / Solaris

Kann man den nicht einfach verkleinern ? Oder Brauchst du so viel wg. Suspend to Disk ?
Kann ich mir nicht vorstellen, dass man dafür 59 GB benötigt.

[mludwig]

Hinterher würde ich zur Sicherheit
- die /etc/fstab prüfen, ob dort die richtige UID für boot steht
- grub aktualisieren - update-grub - bzw. neu installieren - grub-install /dev/sda

[willy4711]

Ich habe meinen Vorschlag gerade mal in einer VM getestet. geht mit Gparted völlig problemlos.
Brauchst keinen Grub updaten einfach nur die Partitionen verkleinern /vergrößern.

Vorher:

Code: Alles auswählen

lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   32G  0 disk 
├─sda1   8:1    0  953M  0 part /boot
├─sda2   8:2    0  4,7G  0 part [SWAP]
├─sda3   8:3    0  9,7G  0 part /
└─sda4   8:4    0 16,7G  0 part /home
sr0     11:0    1   57M  0 rom  

Nacher:

Code: Alles auswählen

lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   32G  0 disk 
├─sda1   8:1    0  1,9G  0 part /boot
├─sda2   8:2    0  3,7G  0 part [SWAP]
├─sda3   8:3    0  9,7G  0 part /
└─sda4   8:4    0 16,7G  0 part /home
sr0     11:0    1   57M  0 rom  

Code: Alles auswählen

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048  4001791  3999744  1,9G 83 Linux
/dev/sda2        4001792 11718655  7716864  3,7G 82 Linux swap / Solaris
/dev/sda3       11718656 32030719 20312064  9,7G 83 Linux
/dev/sda4       32030720 67106815 35076096 16,7G 83 Linux

[BrotherJ]

Danke für Euer Engagement. Das ist eine gute Idee mit Gparted.
Ich habe allerdings, wie ober beschrieben, das /boot leergeräumt und dann den Inhalt von /boot_neu dort hinein synchronisiert und den Server rebootet. Bei der Synchronisation wurde nicht bemängelt, dass kein freier Plattenplatz mehr da wäre wie bei dem Upgrade, sondern es sind auch jetzt nur 80% belegt.