Я обнаружил, что эта ошибка появляется, когда в logrotate.conf перечислены несуществующие файлы журнала. (Это может происходить из-за того, что служба, которая должна создавать журнал, не запущена ). Либо удалите записи, либо удалите связанные с ними пакеты.
Ошибиться в сторону осторожности.
Раздел EFI может содержать прошивку материнской платы, безопасные ключи шифрования загрузки, потенциально несколько ядер (, если они настроены для их хранения здесь ), и даже загрузчики для нескольких операционных систем. В конце концов, все это может занять довольно много места.
Windows использует раздел меньшего размера, потому что обрабатывает раздел по-другому (и, скорее всего, предполагается, что это будет единственная операционная система на машине ).
Если вы планируете иметь только 1 операционную систему на этой конкретной машине, используйте /boot
для хранения ваших ядер (, что является значением по умолчанию для Debian, я полагаю ), и на самом деле только инструкции загрузчика и прошивка материнской платы, чем у вас может быть раздел размером даже меньше 100 МБ. Тем не менее, 500 МБ в общей схеме вещей не намного больше, и в случае, если загрузочный раздел заполнен и не может загрузиться, вы оцените наличие свободного места, поэтому вам не нужно выполнять восстановление системы.
запуская rhel >= 7.6 на рабочих серверах, я устанавливаю linux следующим образом, максимально упрощая его.
mount size file system
-------------------------------------
/boot 1gb XFS
/boot/efi 100mb EFI
/ max XFS
Между прочим, это то, что у меня сейчас происходит на RHEL 7.9:
Filesystem Size Used Avail Use% Mounted on
/dev/sdc3 558G 134G 424G 24% /
tmpfs 252G 4.3M 252G 1% /tmp
/dev/sdc2 950M 246M 704M 26% /boot
/dev/sdc1 190M 10M 180M 6% /boot/efi
ls /boot/efi/efi/redhat
BOOT.CSV* fw/ grub.cfg* mmx64.efi* shimx64-redhat.efi*
BOOTX64.CSV* fwupia32.efi* grubenv* shim.efi* user.cfg*
fonts/ fwupx64.efi* grubx64.efi* shimx64.efi*
ls /boot
config-3.10.0-1127.18.2.el7.x86_64
config-3.10.0-1127.19.1.el7.x86_64
config-3.10.0-1160.2.2.el7.x86_64
efi/
grub2/
initramfs-0-rescue-b00f5bf4f58746a0a8e879b918fc99ec.img
initramfs-3.10.0-1127.18.2.el7.x86_64.img
initramfs-3.10.0-1127.19.1.el7.x86_64.img
initramfs-3.10.0-1160.2.2.el7.x86_64.img
symvers-3.10.0-1127.18.2.el7.x86_64.gz
symvers-3.10.0-1127.19.1.el7.x86_64.gz
symvers-3.10.0-1160.2.2.el7.x86_64.gz
System.map-3.10.0-1127.18.2.el7.x86_64
System.map-3.10.0-1127.19.1.el7.x86_64
System.map-3.10.0-1160.2.2.el7.x86_64
vmlinuz-0-rescue-b00f5bf4f58746a0a8e879b918fc99ec*
vmlinuz-3.10.0-1127.18.2.el7.x86_64*
vmlinuz-3.10.0-1127.19.1.el7.x86_64*
vmlinuz-3.10.0-1160.2.2.el7.x86_64*
Я полагаю, что настройка GRUB2 по умолчанию равна 5 для количества элементов, которые вы можете выбрать в меню загрузки, так что по мере того, как вы продолжаете обновляться до нового ядра, действительно старые в конечном итоге очищаются. Но это происходит в /boot
, а не в разделе efi
, поэтому, если вы хотите сохранить много, я думаю, вам следует беспокоиться о размере /boot
. Я еще не испытывал необходимости делать раздел EFI
больше 100 МБ. Я согласен с тем, что создание раздела EFI размером 500 МБ становится расточительным.
если бы мне пришлось угадывать, это может быть папка fw в EFI, куда можно было бы поместить файлы прошивки, чтобы сделать их доступными во время загрузки для обновления или установки прошивки. Но этот процесс может и часто выполняется с этими файлами на внешнем USB-накопителе, и я не знаю о фактическом требовании чего-то, что должно находиться в разделе EFI таким образом.Таким образом, возникает вопрос, хотите ли вы поддерживать раздел efi размером 500 МБ для чего-то, что вы, возможно, никогда не сделаете.
Размер рекомендуемого загрузочного раздела EFI составляет от 100 -до 550 МиБ.
Загрузочный раздел можно использовать для нескольких ОС (мультизагрузка )и различные версии initramfs, grub, драйверов... ; Так что это зависит от системы, на которой вы работаете.
Также рекомендуемый размер — 550 МБ, чтобы избежать увеличения раздела в будущем, что может оказаться трудным для выполнения.