
Диагностируя проблему с установленной мной системой Ubuntu, я linux-crashdump
попытался записать логи на случай, если они дадут мне полезную информацию о том, что происходит.
После решения проблемы, несколько месяцев спустя я удалил linux-crashdump
, однако у меня все еще есть много crashkernel=
вариантов в моих аргументах загрузки:
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-145-generic root=UUID=760048a7-4ab2-47e0-9a0d-ad961df07974 ro console=ttyS0 rootwait crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-2G:128M,2G-:256M crashkernel=384M-2G:128M,2G-:256M crashkernel=384M-2G:128M,2G-:256M crashkernel=384M-2G:128M,2G-:256M
Не уверен, как это могло так запутаться, но я хотел бы избавиться от этого, чтобы быть уверенным, что память не выделяется для чего-то, что больше не установлено.
Я полагаю, что эти аргументы находятся в файле /boot/grub/grub.cf
, но, учитывая, насколько это важная часть системы, я опасаюсь просто удалять что-либо.
Итак, мой вопрос: как правильно полностью удалить эти crashkernel=
аргументы (или сбросить их до значений по умолчанию) и есть ли что-то еще, что мне следует проверить, чтобы убедиться, что моя система очищена от поведения ядра, приводящего к сбоям?
Я использую Ubuntu Server 16.04.6 LTS.
Я установил, linux-crashdump
следуя инструкциям, которые можно найти здесь:
https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
По сути простоsudo apt-get install linux-crashdump
Я sudo apt-get remove linux-crashdump
его удалил
решение1
/boot/grub/grub.cfg
автоматически сгенерирован: не редактируйте его вручную! Правильный способ настройки вашей установки grub — это изменить /etc/default/grub
(и любой файл конфигурации в /etc/default/grub.d
, если он существует) и запустить update-grub
как root, когда закончите.