meine EFI-System-Partition ist vollgelaufen und ich wollte sie
vergrößern.
Ich habe hinter der Partition mit GParted etwas platz geschaffen und
den freien Platz dann der EFI-Partition zugewiesen.
Das hat aber nicht ganz geklappt.
GParted sagt:
/"502.94 MiB nicht zugeteilter Speicherplatz innerhalb der Partition./
/Um das Dateisystem auf die Größe der Partition zu vergrößern, wählen Sie die Partition und anschließend den Menüeintrag:/
/Partition --> Prüfen"./
Die Prüfung ergibt
/"libparted wird verwendet/
/libparted-Benachrichtigungen ( FEHLER )/
//
/GNU Parted cannot resize this partition to this size. We're working
on it!"/
meine EFI-System-Partition ist vollgelaufen und ich wollte sie vergr��ern. Ich habe hinter der Partition mit GParted etwas platz geschaffen und den freien Platz
dann der EFI-Partition zugewiesen.
Das hat aber nicht ganz geklappt.
GParted sagt:
/"502.94 MiB nicht zugeteilter Speicherplatz innerhalb der Partition./
/Um das Dateisystem auf die Gr��e der Partition zu vergr��ern, w�hlen Sie die Partition
und anschlie�end den Men�eintrag:/
/Partition --> Pr�fen"./
Die Pr�fung ergibt
/"libparted wird verwendet/
/libparted-Benachrichtigungen ( FEHLER )/
/ /
/GNU Parted cannot resize this partition to this size. We're working on it!"/
Die Partition hatte 190 MB und wurde um 500 MB vergr�ssert.
'fdisk' zeigt die richtige Gr��e an. 'df' zeigt aber noch die alte Gr��e.
# fdisk -l /dev/nvme1n1p1
*Disk /dev/nvme1n1p1: 690 MiB, 723517440 bytes, 1413120 sectors*
# df -h /dev/nvme1n1p1
Dateisystem Gr��e Benutzt Verf. Verw% Eingeh�ngt auf
/dev/nvme1n1p1 188M 188M 0 100% /boot/efi
Das System startet immer noch ganz normal, aber bekommt man das irgendwie gefixt
oder muss ich die ESP neu erstellen?
Daf�r br�uchte ich dann aber auch ein paar Tips.
Die EFI Partition ist scheinbar nach /boot/efi gemounted. Was fehlt ist
die komplette Formatierung f�r das FAT Dateisystem. Du m�sstest also den Inhalt von /boot/efi sichern, die Partition formatieren und dann den
Inhalt wieder zur�ck kopieren.
Am Freitag, 8. September 2023, 20:17:22 CEST schrieb Ulf Volmer:
/Mein Kenntnisstand ist, dass gparted selber keine VFAT Filesysteme vergr��ern kann./
Das werde ich noch mal mit einer anderen Partition oder einem USB-Stick testen.
Am Freitag, 8. September 2023, 20:25:31 CEST schrieb Christoph Brinkhaus:
Die EFI Partition ist scheinbar nach /boot/efi gemounted. Was fehlt ist
die komplette Formatierung f�r das FAT Dateisystem. Du m�sstest also den Inhalt von /boot/efi sichern, die Partition formatieren und dann den
Inhalt wieder zur�ck kopieren.
Das macht Sinn.
Muss ich mir Gedanken um die UUID der Partition machen? �ndert die sich beim formatieren? Reicht es dann wenn ich die neue UUID in der fstab eintrage? Dieses ganze Thema um EFI in Verbindung mit systemd-boot oder auch Grub ist nicht so einfach.
In /boot/efi ist z.B. der Ordner 788bf25486834a6cba1da6d5d0f954ee.
Was ist das f�r eine Nummer?
Am Freitag, 8. September 2023, 20:25:31 CEST schrieb Christoph Brinkhaus:
Die EFI Partition ist scheinbar nach /boot/efi gemounted. Was fehlt ist
die komplette Formatierung f�r das FAT Dateisystem. Du m�sstest also den Inhalt von /boot/efi sichern, die Partition formatieren und dann den
Inhalt wieder zur�ck kopieren.
Das macht Sinn.
Muss ich mir Gedanken um die UUID der Partition machen? �ndert die sich beim formatieren? Reicht es dann wenn ich die neue UUID in der fstab eintrage?
In /boot/efi ist z.B. der Ordner 788bf25486834a6cba1da6d5d0f954ee.
Was ist das f�r eine Nummer?
Ich habe die Frage nicht verstanden. Um ein FS vergr��ern zu k�nnen, mu�
man die Stuktur des FS verstehen und �ndern k�nnen.
Das kann parted f�r FAT hat nicht. fatresize hingegen schon.
Am Freitag, 8. September 2023, 21:13:08 CEST schrieb Ulf Volmer:
Ich habe die Frage nicht verstanden. Um ein FS vergr��ern zu k�nnen, mu� man die Stuktur des FS verstehen und �ndern k�nnen.
Das kann parted f�r FAT hat nicht. fatresize hingegen schon.
Die Frage war warum parted das nicht kann. Mit vielen anderen FS kann es das ja. Mit dem alten VFAT aber nicht.
Achso. Dann ist die Antwort: Weil Du noch keine Patches geliefert hast.
Am Freitag, 8. September 2023, 21:15:56 CEST schrieb Ulf Volmer:
In /boot/efi ist z.B. der Ordner 788bf25486834a6cba1da6d5d0f954ee.
Was ist das f�r eine Nummer?
Sowas habe ich hier nicht. Ist das bei Dir ggf. ein Dual Boot System?
Nein, ich schrieb ja schon, dass es von systemd-boot kommt.
Das ist der Bootloader. Von Grub habe ich mich vor einiger Zeit verabschiedet.
Die Partition hatte 190 MB und wurde um 500 MB vergr�ssert.
'fdisk' zeigt die richtige Gr��e an. 'df' zeigt aber noch die alte
Gr��e.
Hi Helge.
Helge Reimer - 08.09.23, 19:21:57 CEST:
Die Partition hatte 190 MB und wurde um 500 MB vergr�ssert.
'fdisk' zeigt die richtige Gr��e an. 'df' zeigt aber noch die alte
Gr��e.
Was ich mich ja frage:
Wie kommt es, dass die Partition vollgelaufen ist?
% df -hT /boot/efi
Dateisystem Typ Gr��e Benutzt Verf. Verw% Eingeh�ngt auf
/dev/nvme0n1p1 vfat 476M 22M 454M 5% /boot/efi
190 MB sollten an sich mehr als ausreichend sein.
Du hast gparted zwei Auftrage erteilt:
* bitte mach die Partition xy gr��er
* bitte mach das darin enthaltete Filesystem gr��er
Wie kommt es, dass die Partition vollgelaufen ist?
Am Freitag, 8. September 2023, 21:37:34 CEST schrieb Martin Steigerwald:
Wie kommt es, dass die Partition vollgelaufen ist?
Das liegt dann auch wieder an systemd-boot.
In dem Ordner mit der Machine-ID liegt f�r jeden installierten Kernel
ein initrd.img mit �ber 40 MB und der Kernel selbst mit 8-10 MB.
Wobei ich mich jetzt frage warum das in /boot liegt und in /boot/efi/ MACHINE_ID/ nochmal.
Ich muss mich noch mal mit systemd-boot besch�ftigen.
Am Freitag, 8. September 2023, 21:35:31 CEST schrieb Ulf Volmer:
Du hast gparted zwei Auftrage erteilt:
* bitte mach die Partition xy gr��er
* bitte mach das darin enthaltete Filesystem gr��er
Nein, ich habe erst die 2. Partition kleiner gemacht um Platz zwischen der 1. und 2. zu schaffen. Das wurde erfolgreich erledigt. Operation abgeschlossen.
Dann sollte die 1. Partition um den geschaffenen Platz vergr��ert werden.
Das wurde auch ohne Fehlermeldung durchgef�hrt. Normalerweise vergr��ert gparted aber auch das entsprechende FS automatisch und das hat es in dem Fall nicht getan, weil es das nicht kann.
Und somit war das vergr��ern der Partition schon sinnlos.
Naja, dann w�re nat�rlich auch ein L�sungsansatz wieder grub zu verwenden.
Oder eben mit fatresize das Dateisystem zu vergr��ern.
Am Freitag, 8. September 2023, 21:51:40 CEST schrieb Ulf Volmer:
Wieso? Weil Du mit dem Aufruf von fatresize �berfordert bist?
Ein Versuch mit einer anderen Partition.
# fatresize -s max /dev/nvme2n1p1
fatresize 1.1.0 (20221231)
part(start=2048, end=411647, length=409600)
No Implementation: GNU Parted cannot resize this partition to this size. We're working on it!
Naja, dann w�re nat�rlich auch ein L�sungsansatz wieder grub zuIch arbeite mit einem Bildschirm mit 34" im Format 21:9 an einer Nvidia- Grafikkarte mit propriet�ren Treibern.
verwenden.
Mit Grub sieht die Konsole schrecklich aus. Riesiger, breitgezogener
Text. Ich habe alles probiert. Grub kann das nicht besser.
Andere Idee: Daten sichern, Partition neu mit VFAT formatieren, Daten
zur�ck kopieren? Allerdings w�re dann in der /etc/fstab die UUID
anzupassen und die Initial Ramdisk neu zu bauen.
GFXMODE in /boot/default/grub hast Du probiert?
Am Freitag, 8. September 2023, 21:51:40 CEST schrieb Ulf Volmer:
Wieso? Weil Du mit dem Aufruf von fatresize �berfordert bist?
Ein Versuch mit einer anderen Partition.
# fatresize -s max /dev/nvme2n1p1
fatresize 1.1.0 (20221231)
part(start=2048, end=411647, length=409600)
No Implementation: GNU Parted cannot resize this partition to this size. We're working on it!
Aber ein Backup und ein Neuerstellen der EFI Partition sollte ja
nicht so da Drama sein.
Am Freitag, 8. September 2023, 22:20:30 CEST schrieb Ulf Volmer:
BUGS
You can't resize FAT32 partition lesser than 512Mb because Windows(R) doesn't work properly with small FAT32 file system. Use FAT16.
Das hei�t, die Partition h�tte von Anfang an gr��er als 512 MB sein m�ssen? Verstehen kann ich das trotzdem nicht.
Ist das ein neuer Bug? Ich hab gerade mal mit meinem alten GParted 0.19.0
an einem USB-Stick rumgespielt. Das hat beim Verkleinern auf 380 MB zwar empfohlen, das vorhandene FAT32 in FAT16 umzuwandeln, aber dennoch ohne Fehler auf 380 MB FAT32 verkleinert. Ebenso auch wieder auf die vollen 16
GB vergr��ert.
diese nochmal mit "mkfs.vfat" zu formatieren. Der Umweg �ber Ext4 ist offenbar f�r Parted erforderlich, damit der die Partition vergr��ert, was
Workaround: Resizing FAT16/FAT32 Partitions (less than 256 MB) ---------------------------------------------------------------
1. Backup the data in the FAT16/FAT32 partition
2. Reformat the partition to EXT4
3. Resize EXT4 partition to desired partition size
4. Reformat the partition back to FAT16/FAT32
5. Restore the FAT16/FAT32 files from backup"/
Ein erneutes Vergr��ern auf die vollen 16 GB spuckte einen Fehler aus, aber anschlie�end wurde die Partition dennoch in voller Gr��e in GParted angezeigt. Direkt anschlie�end dort in FAT32 umwandeln ging einwandfrei.
Dann immer noch in GParted diese Partition zu FAT32 formatieren. Fertig.
Wobei ich mich jetzt frage warum das in /boot liegt und in /boot/efi/ MACHINE_ID/ nochmal.
Helge Reimer wrote:
Am Samstag, 9. September 2023, 00:00:22 CEST schrieb Frank Miller:
Dann immer noch in GParted diese Partition zu FAT32 formatieren. Fertig.
Und damit hast du den Datenverlust den ich nicht wollte.
Ich wollte einfach nur ungenutzten Plattenplatz verschieben und nicht neu formatieren.
Ja, aber *in diesem Teilthread* ging es jetzt um die F�higkeit von libparted, FAT-Partitionen bis zu gewissen Grenzen zu vergr��ern oder zu verkleinern. Und das kann es offenbar (entgegen der Dokumentation) schon, allerdings nur mit Neuformatierung der Partition.
Wird wohl kein Drama werden, hätte aber auch so schön einfach sein
können und hat mich doch etwas überrascht.
Zumindest weiß ich jetzt, UUID in fstab anpassen, initrd neu bauen
und mich mit systemd-boot beschäftigen.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 169:15:48 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,834 |