DISKWARN blocks Mount Point /boot currently use 85.1%

[Rawand Sae]

Hi,

I received multiple Disk usage warnings about the Mount Point “/boot” partition being almost full 85.1% Percent Used!
I have checked the server to see if the kernel installations are causing this but I can confirm there are only 2 versions of the kernel installed
-----------------------------
[root@srv1 boot]# rpm -q kernel
kernel-4.18.0-348.2.1.el8_5.x86_64
kernel-4.18.0-348.7.1.el8_5.x86_64
-----------------------------

and there are multiple IMG files inside /boot not sure if these img files causing DISKWARN?:

[root@srv1 ~]# cd /boot
[root@srv1 boot]# ls -la
total 384792
dr-xr-xr-x.  6 root root     1024 Jan 20 09:05 .
dr-xr-xr-x. 20 root root     4096 Jan 21 15:50 ..
-rw-r--r--.  1 root root   193933 Nov 15 15:37 config-4.18.0-348.2.1.el8_5.x86_64
-rw-r--r--.  1 root root   193933 Dec 21 20:17 config-4.18.0-348.7.1.el8_5.x86_64
drwxr-xr-x.  3 root root     1024 Jan  1  1970 efi
drwx------.  4 root root     1024 Jan  9 12:58 grub2
-rw-------.  1 root root 83359124 Nov 29 12:23 initramfs-0-rescue-5cd97a44bbe04c08a5e1e6070ead0d48.img
-rw-------.  1 root root 87363817 Jan 20 09:05 initramfs-0-rescue-a662a72b3d284ac282af283cff6978a6.img
-rw-------.  1 root root 57053587 Jan  9 12:58 initramfs-4.18.0-348.2.1.el8_5.x86_64.img
-rw-------.  1 root root 28587008 Jan  9 13:28 initramfs-4.18.0-348.2.1.el8_5.x86_64kdump.img
-rw-------.  1 root root 86272301 Jan 20 09:05 initramfs-4.18.0-348.7.1.el8_5.x86_64.img
drwxr-xr-x.  3 root root     1024 Nov 29 12:22 loader
drwx------.  2 root root    12288 Jan  9 12:57 lost+found
lrwxrwxrwx.  1 root root       51 Nov 29 12:22 symvers-4.18.0-348.2.1.el8_5.x86_64.gz -> /lib/modules/4.18.0-348.2.1.el8_5.x86_64/symvers.gz
lrwxrwxrwx.  1 root root       51 Jan 20 09:05 symvers-4.18.0-348.7.1.el8_5.x86_64.gz -> /lib/modules/4.18.0-348.7.1.el8_5.x86_64/symvers.gz
-rw-------.  1 root root  4259443 Nov 15 15:37 System.map-4.18.0-348.2.1.el8_5.x86_64
-rw-------.  1 root root  4260003 Dec 21 20:17 System.map-4.18.0-348.7.1.el8_5.x86_64
-rwxr-xr-x.  1 root root 10215304 Nov 29 12:22 vmlinuz-0-rescue-5cd97a44bbe04c08a5e1e6070ead0d48
-rwxr-xr-x.  1 root root 10223496 Jan 20 09:05 vmlinuz-0-rescue-a662a72b3d284ac282af283cff6978a6
-rwxr-xr-x.  1 root root 10215304 Nov 15 15:37 vmlinuz-4.18.0-348.2.1.el8_5.x86_64
-rw-r--r--.  1 root root      172 Nov 15 15:36 .vmlinuz-4.18.0-348.2.1.el8_5.x86_64.hmac
-rwxr-xr-x.  1 root root 10223496 Dec 21 20:17 vmlinuz-4.18.0-348.7.1.el8_5.x86_64
-rw-r--r--.  1 root root      172 Dec 21 20:17 .vmlinuz-4.18.0-348.7.1.el8_5.x86_64.hmac

is these files initramfs-* can be safely removed with rm manualy?

your help is greatly appreciated.

 

[andrew.n]

You can remove the unused kernels like this:

How to remove old unused kernels on CentOS Linux

How to remove old unused kernels on CentOS Linux

linuxconfig.org

but be careful as this can damage your system if not done properly.

 

[Rawand Sae]

You can remove the unused kernels like this:

How to remove old unused kernels on CentOS Linux

How to remove old unused kernels on CentOS Linux

linuxconfig.org

but be careful as this can damage your system if not done properly.

thanks for your reply, in my case the installed kernels was not the issue like I mentioned above only 2 versions were installed this should not cause high disk usage.

The vmlinuz-0-rescue-* and initramfs-0-rescue-* files were causing DISKWARN and they are not owned by any package I had to remove them with rm manually.

i removed:
initramfs-0-rescue-5cd97a44bbe04c08a5e1e6070ead0d48.img
initramfs-0-rescue-a662a72b3d284ac282af283cff6978a6.img
vmlinuz-0-rescue-5cd97a44bbe04c08a5e1e6070ead0d48
vmlinuz-0-rescue-a662a72b3d284ac282af283cff6978a6

after removing I used this command to regenerate grub config so they don't show up in the boot menu.

grub2-mkconfig -o /boot/grub2/grub.cfg

I hope this helps others who have similar issues as I had.

 

[andrew.n]

you just killed your rescue kernel....it was not a wise step lets hope you won't need it in the future.

 

[cPRex]

It's not abnormal for /boot to run with high disk usage, and that isn't something to worry about unless you are experiencing issues such as failed updates. In the future, if the server is created with custom partitions for areas like /boot you may want to make that area larger.

 

[Rawand Sae]

you just killed your rescue kernel....it was not a wise step lets hope you won't need it in the future.

I had no other choice, I believe you can re-generate the rescue kernel image for the current kernel with the command!

dnf reinstall kernel-core

It's not abnormal for /boot to run with high disk usage, and that isn't something to worry about unless you are experiencing issues such as failed updates. In the future, if the server is created with custom partitions for areas like /boot you may want to make that area larger.

yes, I had issues with a kernel update, due to /boot high disk usage the system was unable to update running_version and I kept getting the "You must reboot the server to apply kernel updates" Warning.