I am encountering a problem using yum update where /boot does not have enough free space to continue. I have read over a few other posts and the most helpful responses I found indicate the safest and most efficient way to solve the problem is to use yum-utils and run package-cleanup. Unfortunately that solution did not correct the problem I am having. I have /boot as a 100mb partition which I have read is plenty of space.

I have installed yum-utils and when running

package-cleanup --oldkernels --count=1

The result is:

Not removing kernel 2.6.32-642.13.1.e16 because it is the running kernel
No old kernels to remove

The results of rpm -qa | grep kernel is:


My initial thought was to remove everything that wasn't my kernel but I am hesitant because package-cleanup didn't decide the older kernels should be removed.

Doing a ls -ls /boot results in this:

  113 -rw-r--r--. 1 root root   112760 Jan 11 15:26 config-2.6.32-642.13.1.el6.i686
  113 -rw-r--r--. 1 root root   112820 Apr 11 12:43 config-2.6.32-696.1.1.el6.i686
    2 drwxr-xr-x. 3 root root     1024 Dec 20  2016 efi
    2 drwxr-xr-x. 2 root root     1024 Apr 28 22:16 grub
23036 -rw-------. 1 root root 23494547 Jan 20 11:09 initramfs-2.6.32-642.13.1.el6.i686.img
23062 -rw-------. 1 root root 23521098 Apr 28 22:16 initramfs-2.6.32-696.1.1.el6.i686.img
 4526 -rw-------. 1 root root  4613691 Apr 28 22:13 initrd-2.6.32-642.13.1.el6.i686kdump.img
   13 drwx------. 2 root root    12288 Dec 20  2016 lost+found
  209 -rw-r--r--. 1 root root   211920 Jan 11 15:26 symvers-2.6.32-642.13.1.el6.i686.gz
  210 -rw-r--r--. 1 root root   211993 Apr 11 12:43 symvers-2.6.32-696.1.1.el6.i686.gz
 2023 -rw-r--r--. 1 root root  2061183 Jan 11 15:26 System.map-2.6.32-642.13.1.el6.i686
 2026 -rw-r--r--. 1 root root  2064145 Apr 11 12:43 System.map-2.6.32-696.1.1.el6.i686
 4051 -rwxr-xr-x. 1 root root  4128992 Jan 11 15:26 vmlinuz-2.6.32-642.13.1.el6.i686
 4058 -rwxr-xr-x. 1 root root  4136928 Apr 11 12:43 vmlinuz-2.6.32-696.1.1.el6.i686

Not super familiar with what should be in the /boot directory and/or what is safe to remove. Hopefully this can help with determining what is safe to remove and can help others in the future.

I have already edited /etc/yum.conf with installonly_limit=2 from the original limit of 5 to hopefully stop this from occurring in the future.

  • Have you considered not having a boot partition at all? In many cases you can place the boot directory in the root partition. – Emmanuel Rosa Jul 9 '17 at 14:46
  • I'm definitely not an expert in Unix installs but I was lead to believe the /boot partition was required, at least for installation. Would it be possible to change the partition to a directory without a redo of the install? My understanding was that the grub boot loader could only read certain partitions which is why /boot is created separately from the rest of the file system? – ityler22 Jul 9 '17 at 14:54
  • That used to be the case in the past. In fact, it was so long ago I don't even remember the exact nature of GRUB's limitation at the time. However, now that I see that your /boot is actually the EFI partition (ESP), you'll need to keep that partition. So you're best option is to resize it, no easy task. The way I'd do it, is to back up both partitions using tar, redo the disk partitioning from a liveCD (which will "erase" everything), and restore from the backups. But that requires tying up loose ends because recreating the filesystems will change their UUIDs, which can prevent booting. – Emmanuel Rosa Jul 9 '17 at 16:33
  • Wow well seems like this is a larger problem after all. Since this is a production web server I wont be able to do this without some prep work for sure. Thanks for the help. – ityler22 Jul 9 '17 at 20:50
  • Hold on.... I noticed your efi directory is empty. Is your system efi/uefi or bios? – Emmanuel Rosa Jul 10 '17 at 1:26

If you relocate your /boot into your root filesystem, you'd gain whatever amount of storage your root filesystem has, and no longer be limited by the size of the boot partition.

Adjusting the boot loader, GRUB, is a delicate operation. In the following process I mitigate the risk by not making any changes which cannot easily be reverted. The process involves relocating /boot and then updating the boot loader.

Relocating /boot

Currently, /boot is located on a partition separate from the root filesystem. A safe way to relocate it is to copy rather than move the files:

umount /boot
mount /dev/sd?? /mnt
cp -av /mnt/* /boot/

Copying the files involves umount-ing /boot, mounting it elsewhere, and copying the files from the mounted location to /boot.

Next, edit /etc/fstab and comment out the line which mounts /boot.

Updating the boot loader

Before actually updating the boot loader, it's best to do a test to ensure GRUB can boot from your relocated files:

  1. Open /boot/grub/grub.conf and make note of the kernel and initrd lines used to boot your Cent OS kernel. You'll be typing these in manually for the test.
  2. Reboot the machine.
  3. At the GRUB screen press "c"
  4. At the GRUB prompt enter find /boot/grub/stage1. It should print out something like (hd0,5). That should correspond to the disk and partition of the root filesystem.
  5. Enter root (hd0,5) (or whatever the previous command printed)
  6. Enter the kernel line you wrote down. Something like: kernel /boot/vmlinuz-2.6.18-238.19.1.el5.centos.plusPAE ro root=/dev/sda6
  7. Enter the initrd line you wrote down. Something like: initrd /boot/initrd-2.6.18-238.19.1.el5.centos.plusPAE.img
  8. Enter boot to boot the kernel.

If all goes well, the system should boot an the old /boot partition should not be mounted, which you can confirm with the mount command.

Assuming it worked, to make the boot loader change permanent:

  1. Edit /boot/grub/grub.conf and update the root, kernel, and initrd lines as you entered them during the test.
  2. Run grub to enter the GRUB prompt. To clarify, this is done from within Cent OS not by rebooting.
  3. Similar to the test, enter root (hd0,5) (or whatever partition is supposed to be)
  4. Run setup (hd0), where hd0 is the disk where the GRUB installs it's MBR stage. It could be that you're using the disk MBR or a partition's first sector. Whichever it is, that's what hd0 should be.

After those steps, GRUB will present a menu which will boot the kernel from your new /boot. Note that you're boot partition is still intact.

You can read a bit more about GRUB and Cent OS here: https://wiki.centos.org/HowTos/GrubInstallation Pay particular attention to the Notes and warnings section.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.