Fedora 20 Post-Upgrade: / boot-Partition ist fast voll

509
DroBuddy

Ich habe kürzlich eine meiner Boxen von F18 auf F20 umgerüstet, was sehr reibungslos verlief (mit Fedup). Jetzt ist meine / boot-Partition fast voll:

/dev/sda2 477M 436M 12M 98% /boot

Die FC18-spezifischen Inhalte sind unten zu sehen:

[root@local-dev boot]# ls -hal | grep fc18 root root 129K Dec 2 14:35 config-3.11.10-100.fc18.x86_64 root root 129K Dec 2 14:23 config-3.11.10-100.fc18.x86_64.debug root root 129K Nov 4 09:14 config-3.11.7-100.fc18.x86_64 root root 129K Nov 4 09:05 config-3.11.7-100.fc18.x86_64.debug root root 129K Nov 20 15:29 config-3.11.9-100.fc18.x86_64 root root 129K Nov 20 15:17 config-3.11.9-100.fc18.x86_64.debug root root 36M Dec 13 18:23 initramfs-3.11.10-100.fc18.x86_64.debug.img root root 35M Dec 13 18:25 initramfs-3.11.10-100.fc18.x86_64.img root root 7.7M Dec 13 18:28 initramfs-3.11.10-100.fc18.x86_64kdump.img root root 36M Nov 13 15:24 initramfs-3.11.7-100.fc18.x86_64.debug.img root root 35M Nov 13 15:23 initramfs-3.11.7-100.fc18.x86_64.img root root 7.7M Nov 13 15:36 initramfs-3.11.7-100.fc18.x86_64kdump.img root root 36M Dec 1 20:35 initramfs-3.11.9-100.fc18.x86_64.debug.img root root 35M Dec 1 20:33 initramfs-3.11.9-100.fc18.x86_64.img root root 7.7M Dec 1 20:55 initramfs-3.11.9-100.fc18.x86_64kdump.img root root 2.6M Dec 2 14:35 System.map-3.11.10-100.fc18.x86_64 root root 2.8M Dec 2 14:23 System.map-3.11.10-100.fc18.x86_64.debug root root 2.6M Nov 4 09:14 System.map-3.11.7-100.fc18.x86_64 root root 2.8M Nov 4 09:05 System.map-3.11.7-100.fc18.x86_64.debug root root 2.6M Nov 20 15:29 System.map-3.11.9-100.fc18.x86_64 root root 2.8M Nov 20 15:17 System.map-3.11.9-100.fc18.x86_64.debug root root 5.0M Dec 2 14:35 vmlinuz-3.11.10-100.fc18.x86_64 root root 5.5M Dec 2 14:23 vmlinuz-3.11.10-100.fc18.x86_64.debug root root 174 Dec 2 14:23 .vmlinuz-3.11.10-100.fc18.x86_64.debug.hmac root root 168 Dec 2 14:35 .vmlinuz-3.11.10-100.fc18.x86_64.hmac root root 5.0M Nov 4 09:14 vmlinuz-3.11.7-100.fc18.x86_64 root root 5.5M Nov 4 09:05 vmlinuz-3.11.7-100.fc18.x86_64.debug root root 173 Nov 4 09:05 .vmlinuz-3.11.7-100.fc18.x86_64.debug.hmac root root 167 Nov 4 09:14 .vmlinuz-3.11.7-100.fc18.x86_64.hmac root root 5.0M Nov 20 15:29 vmlinuz-3.11.9-100.fc18.x86_64 root root 5.5M Nov 20 15:17 vmlinuz-3.11.9-100.fc18.x86_64.debug root root 173 Nov 20 15:17 .vmlinuz-3.11.9-100.fc18.x86_64.debug.hmac root root 167 Nov 20 15:29 .vmlinuz-3.11.9-100.fc18.x86_64.hmac

Ich bin ziemlich zuversichtlich, aber ich konnte noch keine direkte Antwort bei Google finden, aber ich kann diese Dateien jetzt sicher löschen, richtig?

Vielen Dank für Ihre Zeit und Ihren Einblick.

Grüße,

0

1 Antwort auf die Frage

0
DroBuddy

Die einfache Lösung (Linux distro agnostic) liegt darin cd /boot && ls -hl. Lesen Sie die Ausgabe durch und entfernen Sie alle alten Kernel-Dateien. In meinem Fall war der neueste Kernel 3.14. , also habe ich sudo rm config-3.11*die anderen 3.11- Kernel-Dateien entfernt und entfernt . Dadurch wurden ca. 280 MB von der / boot-Partition freigegeben.

Jetzt arbeitet sie wieder wunderbar.

Wenn Sie eine Debian-Basisdistribution ausführen, müssen Sie linux-image*in / boot nach den Dateien suchen. Bei CentOS / Fedora / RHEL werden jedoch die folgenden Dateien entfernt:

Hinweis: Verwenden uname -aSie diese Option, um Ihre aktuelle Kerenl-Version herauszufinden (z. B. Ausgabe:, Linux local-dev 3.14.2-200.fc20.x86_64 #1 SMP Mon Apr 28 14:40:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linuxdaher ist meine aktuelle Kernel-Version 3.14.2).

sudo rm vmlinuz-3.*

sudo rm config-3.*

sudo rm System.map-3.*

Und nach dem Neustart sind Sie gut!

WARNUNG: Das Ändern der / boot-Partition kann Ihr System leicht beeinträchtigen. Gehen Sie vorsichtig vor und verwenden Sie die obigen Befehle nur, wenn Sie wissen, was sie tun und was Sie tun, wenn Sie sie ausführen!

Verwandte Probleme