my computer complains that the /boot partition is nearly full and I cannot update my system due to this.
also i already tried removing the old kernal only 2 kernals are remained left.
please help
can you show us the ouput of ls -lh /boot as well as sudo dnf list installed kernel\* please.
Also tell us how large your /boot partition is, see df -h /boot
1 Like
I have attached all the screenshot of your code. now check and tell me as of last code below is the output
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 974M 850M 57M 94% /boot
Post deleted due to my errors reading your post.
Actually No. What is listed below “Available Packages” are not installed.
1 Like
Thank you very much for spotting my errors on reading that screen.
There are several ways a directory may occupy space that ls won’t show: corrupt filesystem, hidden files (try ls -al), files in lost+found, and sparse files. It would be useful to know what filesystem is used for /boot.
Here (text pasted using <Ctrl-E> (icon:</>)):
% doas du -sm /boot/efi /boot/lost+found /boot/extlinux /boot/grub2
116 /boot/efi
1 /boot/lost+found
2 /boot/extlinux
3 /boot/grub2
Look at man df for additional options if this doesn’t identify the missing space.
Arch linux often has good documentation: btrfs uses more space than the actual size of the files.
1 Like
I am unable to understand you, can u please elaborate it ?
I am new Linux so i donk know many things
My bad, I had forgotten to write the important “installed” in above command (fixed now)
Ok, you really only have one kernel installed.
Following @gnwiii 's advice, what is the output of
sudo du -sm /boot/efi /boot/lost+found /boot/grub2 ?
Instead of screenshots, please paste command line outputs as “Preformatted Text” (CTRL + e or using the </>icon from the icon bar of the editor).
18 /boot/efi
1 /boot/lost+found
3 /boot/grub2
We need to know more.
You should check the “health” of your drive. The Disks program reports device “health” and has options to run checks. When disks do unexpected things, it is a good idea to do the tests before attempting repairs.
- what filesystem is used for
/boot. Please show us the output of
mount -v | grep "/boot "(note the space afterboot).
Here, this gives:
% mount -v | grep "/boot "
/dev/nvme0n1p5 on /boot type ext4 (rw,relatime,seclabel)
If that is “not found”, then show us the output of `mount -v | grep "/ "
You will need the UUID (Universally Unique ID) of the boot partition. Use sudo ls -l /dev/disk/by-uuid and looking for the partition used by /boot. For the above example, this gives:
$ sudo ls -l /dev/disk/by-uuid | grep nvme0n1p5
lrwxrwxrwx. 1 root root 15 Feb 21 21:09 fbfbd967-e7b3-4682-a4f1-f4b71483b94e -> ../../nvme0n1p5
- is the filesystem of the boot partition corrupt? If your filesystem is
ext4, please read fsck command before proceeding. Note that you can’t repair a mounted filesystem, and repairs don’t always work, so you should make a backup of the files you don’t want to loose of the system won’t boot following the attempted repair.
If /boot is not using ext4, e.g., btrfs or xfs, you need post what you have and wait for further advice.
For ext4, note the device location in the first field of the mount -v output from the first step above (/dev/nvme0n1p5 in the above example).
Make a note of your login credentials for the ask.fedora so you can post details from the live system. Then boot from a “live” Linux USB stick and run: sudo fsck -f UUID=<your_UUID>.
$ mount -v | grep "/boot "
/dev/nvme0n1p2 on /boot type ext4 (rw,relatime,seclabel)
this is the output
1 Like
Good. That is probably the most common configuration, so many people are able to help.
Did you try ls -al /boot to make sure the space isn’t used by hidden files?
If that doesn’t explain the missing space you should continue with the steps to check the hardware, make a backup, and try repairing the filesystem, but you have some reading to do. If something in the document isn’t clear, you can ask here (you may want to start a new topic such as “fsck repair of ext4 filesystem” to reach a wider audience.
1 Like
There may be some rogue process(es) we haven’t seen using /boot. If a rogue process runs intermittently, it might not be caught by lsof, so it is safer to run fsck from a Live distro using UUID=<uuid>.
sudo du --max-depth=1 /boot | sort -rg
paste the output
1 Like
887908 /boot
696916 /boot/.Trash-0
17796 /boot/efi
2360 /boot/grub2
16 /boot/lost+found
16 /boot/loader
this is the output
It appears you forgot to empty the trash!
This is all too common after using a GUI to “delete” unwanted files. Normally
dnf removes old kernels. Running GUI tools as root increases exposure to evildoers, so many of us don’t do it.
2 Likes