Mientras diagnosticaba un problema con un sistema Ubuntu que instalé, linux-crashdump
intenté capturar registros en caso de que pudieran darme pistas útiles sobre lo que estaba sucediendo.
Después de resolver el problema, unos meses después lo eliminé linux-crashdump
, sin embargo, todavía parece que tengo muchas crashkernel=
opciones en mis argumentos de arranque:
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
No estoy seguro de cómo se ha vuelto tan complicado, pero me gustaría deshacerme de esto para asegurarme de que no se asigne memoria a algo que ya no está instalado.
Creo que estos argumentos se encuentran en el archivo /boot/grub/grub.cf
, pero dado lo crítica que es esta parte del sistema, desconfío de simplemente eliminar cosas.
Entonces mi pregunta es; ¿Cuál es la forma correcta de eliminar completamente estos crashkernel=
argumentos (o restablecer los valores predeterminados) y hay algo más que deba verificar para asegurarme de que mi sistema esté libre de comportamientos de falla del kernel?
Estoy ejecutando Ubuntu Server 16.04.6 LTS
Lo instalé linux-crashdump
siguiendo las instrucciones que se encuentran aquí:
https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
Esencialmente solosudo apt-get install linux-crashdump
Solía sudo apt-get remove linux-crashdump
desinstalarlo
Respuesta1
/boot/grub/grub.cfg
se genera automáticamente: ¡no lo edites manualmente! La forma correcta de personalizar la instalación de grub es modificar /etc/default/grub
(y cualquier archivo de configuración en /etc/default/grub.d
, si existe) y ejecutarlo update-grub
como root cuando haya terminado.