Я недавно обновил одну из своих коробок с F18 до F20, которая прошла очень гладко (с помощью fedup). Однако теперь мой /boot раздел почти заполнен:

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

Конкретное содержание FC18 можно увидеть ниже:

[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

Я довольно уверен, но пока не смог найти прямой ответ в Google, но теперь я могу безопасно удалить эти файлы, верно?

Спасибо за ваше время и понимание.

С Уважением,

1 ответ1

0

Простое решение (Linux distro agnostic) - это cd /boot && ls -hl . Прочитайте вывод и удалите все старые файлы ядра. В моем случае самое последнее ядро было 3.14. , поэтому я sudo rm config-3.11* и удалил другие файлы ядра 3.11 . Это освободило около 280 МБ из раздела /boot.

Теперь она снова прекрасно работает.

Если вы используете дистрибутив на основе Debian, вам нужно искать файлы linux-image* в /boot, но в CentOS / Fedora / RHEL удаляемые файлы выглядят следующим образом:

Примечание. Используйте uname -a чтобы узнать текущую версию kerenl (например, выходные данные: 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/Linux , так что моя текущая версия ядра 3.14.2).

sudo rm vmlinuz-3.{old kerenel version}*

sudo rm config-3.{old kernel version}*

sudo rm System.map-3{old kernel version}.*

И, как только вы перезагрузитесь, вуаля, вы готовы к работе!

ВНИМАНИЕ: Изменение раздела /boot может легко нарушить работу вашей системы. Действуйте с осторожностью и используйте приведенные выше команды только в том случае, если вы знаете, что они делают, и что вы делаете, когда выполняете их!

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .