/boot Partition Too Small

Home » CentOS » /boot Partition Too Small
CentOS 31 Comments

First off – let me say I am not an administrator.   I need to know if there is an easy way to increase my /boot partition.  When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size.  it’s too small and I can’t do yum updates. if it’s not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea?  I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this?   Thanks in advance. KM

31 thoughts on - /boot Partition Too Small

  • If there are many old kernels in there, you can probably remove the oldest one(s) to make room for newer ones.

    I’ve run into problems where the yum update didn’t work because there wasn’t enough room in /boot; my notes for updating now include removing old kernels first before running updates.

  • How big is it?

    No, you can’t do that. /boot is special and needs to be a separate partition.

    The most likely cause of your problems is that you have multiple kernels installed – when you boot the machine do you see multiple versions on the grub boot screen? If you don’t need the previous versions then they can just be deleted using yum: do ‘rpm -q kernel’ to see which kernels are installed and ‘uname -r’ to see which version you are currently running (it should be the same as the highest version installed). You can then use ‘yum erase …’ to remove the old kernels. It’s always handy to have a version or two old ones in case of emergency so I always leave three on a system.

    The multiple versions installed of some things – i.e. the kernel – is controlled by a yum variable in /etc/yum.conf called
    ‘installonly_limit’. It’s probably set to 5 at the moment, you can set it to 3 safely and that is usually sufficient to stop /boot filling up.

    P.

  • Thanks for the idea.  I’ve already restricted it to one kernel.  …. so this will not help me.

    First off – let me say I am not an administrator.  I need to know if there is an easy way to increase my /boot partition.  When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size.  it’s too small and I can’t do yum updates. if it’s not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea?  I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this?  Thanks in advance. KM

  • Here is my current info, should have increased it to like 500M or so at least. Filesystem     Size  Used   Avail Use% Mounted on/dev/sda1       96M   33M   59M  36%   /boot

    ls /boot config-2.6.32-358.el6.x86_64
    efi grub initramfs-2.6.32-358.el6.x86_64.img initrd-2.6.32-358.el6.x86_64kdump.img lost+found symvers-2.6.32-358.el6.x86_64.gz System.map-2.6.32-358.el6.x86_64
    vmlinuz-2.6.32-358.el6.x86_64

    How big is it?

    No, you can’t do that. /boot is special and needs to be a separate partition. The most likely cause of your problems is that you have multiple kernels installed – when you boot the machine do you see multiple versions on the grub boot screen? If you don’t need the previous versions then they can just be deleted using yum: do ‘rpm -q kernel’ to see which kernels are installed and ‘uname -r’ to see which version you are currently running (it should be the same as the highest version installed).  You can then use ‘yum erase …’ to remove the old kernels. It’s always handy to have a version or two old ones in case of emergency so I always leave three on a system.

    The multiple versions installed of some things – i.e. the kernel – is controlled by a yum variable in /etc/yum.conf called
    ‘installonly_limit’. It’s probably set to 5 at the moment, you can set it to 3 safely and that is usually sufficient to stop /boot filling up.

    P.

  • Needs is a bit strong, as grub2 does support LVM. It’s not a supported configuration for Redhat.

    I’m not a sure there’s a lot to it beyond having the lvm module loaded in grub, but I’ve honestly not tried.

    jh

  • There is no easy way to increase the /boot partition. One can try to build another /boot partition and use that but that isn’t simple either and prone to problems if the /boot is outside of where that particular BIOS can intepret (aka embedded in an LVM) or jump to.

    I have found the simpler method is usually: dump the disks to backup, reinstall the system with 500 to 1000 MB /boot and restore from backups.

  • You can do this (warning–back up everything first, just in case):
    -download the grub live CD image (google for it)
    -burn it to a CD
    -boot it
    -use the graphical partition editor to resize and/or move existing partitions to make room for a larger boot then enlarge the /boot. all this may take a while once you tell it to commit your changes, but it isn’t hard to do. I’ve done it several times, as well as smaller changes, and have yet to have a failure (knock on wood).

    Does it work with LVM? Hmmm… good question. I think so, but would have to go check to be sure.

    Good luck!

  • Thanks for all of the input, not really sure what if anything I will do.  i was hoping it would be easy and i could just create a /boot in root, and copy the actual boot contents to it and use it.   wishful thinking i guess.  just to give a complete picture here is the current partitioning on the server….in case anyone wants to say anymore.  Thanks in advance. Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vg_bldsrv-lv_root
                           50G   26G   22G  55% /
    tmpfs                 9.0G  156K  9.0G   1% /dev/shm
    /dev/sda1              96M   33M   59M  36% /boot
    /dev/mapper/vg_bldsrv-lv_home
                          861G  371G  447G  46% /home

    Most of this is like speaking another language to me anyway.  I’ll consider it all. KM

    You can do this (warning–back up everything first, just in case):
    -download the grub live CD image (google for it)
    -burn it to a CD
    -boot it
    -use the graphical partition editor to resize and/or move existing partitions to make room for a larger boot then enlarge the /boot. all this may take a while once you tell it to commit your changes, but it isn’t hard to do. I’ve done it several times, as well as smaller changes, and have yet to have a failure (knock on wood).

    Does it work with LVM? Hmmm… good question. I think so, but would have to go check to be sure.

    Good luck!


    —- Fred Smith — fredex@fcshome.stoneham.ma.us —————————–
                          I can do all things through Christ
                                  who strengthens me.
    —————————— Philippians 4:13 ——————————-

  • Indeed, /boot does not need to be a separate partition. I have /boot within the root filesystem on my test boxes where I know I will need to install many / all kernels for testing / development purposes for the specific reason that I do not need to set a size for /boot and it can just consume whatever it needs from the rest of the filesystem.

  • This is what I do. When /boot hits about 80% I go through and remove old kernels I will never boot into anyway.

    Usually that’s at four kernels.

  • Do i need to do something special or is it as easy as:
    – save the contents of the current /boot – umount /boot and change the /etc/fstab so it doesn’t mount again-  create a boot directory that is in the root  filesystem- copy the contents back I realize the physical/current /boot will be a waste of space but it’s not that big so it’s fine.   
    I thought i probably have to make configuration changes of some sort. Again I apologize in advance since I am not really good at this (partition/file system).  I have tried searching but am never sure exactly what I should try.   I need to find the “for dummies” version(s) of this. Thanks again. KM

    Indeed, /boot does not need to be a separate partition. I have /boot within the root filesystem on my test boxes where I know I will need to install many / all kernels for testing / development purposes for the specific reason that I do not need to set a size for /boot and it can just consume whatever it needs from the rest of the filesystem.

  • KM wrote:

    What I would recommend: go out and buy a “small” new h/d, say, 150GB or
    250GB. Also get an adapter for it (let me note that I actually bought, a year or two ago, a hot-swap drive bay that fits in a std. tower case…). Then partition that (we’ve been using 1G for /boot for years), mount it on
    /mnt, mount newdrive/boot /mnt/newdrive/boot, and rsync -HPavx /.
    /mnt/newdrive, and rsync -HPavx /boot /mnt/newdrive/boot

    Then grub-install /dev/newdrive, and swap drives.

    mark

  • Your root filesystem is in an LVM volume. CentOS 6 is still using GRUB legacy, which does not support /boot in LVM.

    For you, there really is no way around the messy and delicate process of shrinking and relocating a filesystem and the LVM volumes to make space for a larger /boot partition. Frankly, I would hesitate to do that in place on my own system, and I have quite a bit of experience with doing unspeakable things with LVM volumes. You really need to do that resizing in the context of moving everything to another disk.

    If it’s a server that you don’t want to take down for the time it takes for that procedure, you can do amazing things with pvmove while your system continues to run, but you still need another disk to hold those volumes temporarily.


    Bob Nichols “NOSPAM” is really part of my email address.
    Do NOT delete it.

  • says up there, /boot is /dev/sda1, this is almost exactly the config of my C6 servers.


    john r pierce, recycling bits in santa cruz

  • Been there done that.

    A simple solution is to edit /etc/yum.conf and change the line

    installonly_limit=5

    to e.g.

    installonly_limit=3

    and see if that’s enough with the existing boot partition size.

    A “yum update” should delete the two oldest kernel images.

  • Assuming you have backups, if something should go south, you might want to try out the Gparted boot-iso.

    Using Gparted you should be able to shrink some of the other partitions, and then grow the boot partition.

    More info on:
    https://gparted.org/index.php

    If you have another non-critical computer to test using Gparted on, do that first before doing it “for real”.

    Hope this helps.

  • Hi,

    Since a lot of people seem to say none of the above can be done, I’m starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data. You’d have to use the
    “live” version when operating on system partitions. See https://gparted.org

    – T

  • I would prefer boot up in single, and partition a new boot device, with the larger /dev/sda1, and whatever else lvm stuff, then copy the file systems across with dump or xfsdump or whatever, swap the devices and boot.   this way the old disk is a safe backup.   heck, /boot can be a SD card or USB stick :-p


    john r pierce, recycling bits in santa cruz

  • You would be asking gparted to:
    1. Reach inside an LVM PV and shrink one filesystem and its LV,
    2. Rearrange the extents inside the PV to make free space at the beginning,
    3. Move the start of the PV and adjust all of the starting offsets for the LVs,
    4. Finally, enlarge partition 1 into the freed-up space.

    Even if gparted was willing to attempt that, there is no way I would trust it to do it correctly.


    Bob Nichols “NOSPAM” is really part of my email address.
    Do NOT delete it.

  • Le 10/10/2017 à 15:55, KM a écrit :

    Here’s a possible solution to your problem:

    # yum install yum-utils
    # package-cleanup –oldkernels –count=1
    # yum update

    Prevent this from happening again by editing /etc/yum.conf:

    installonly_limit=2 (default value 5, reduce to 2)

    Cheers,

    Niki

    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

  • Quite. I’d never try this without a backup, of course. In fact, I’ve only ever used gparted in situations where I had a system dump already. Still, it could save you from a bit of work, as in, if it does succeed, you won’t have to do a full recovery.  Also, I’m not really sure about the state of the LVM support, now that you mention it. (But there is supposed to be *something* in that area.)

    – Toralf

  • With 100Mbyte /boot on a non-EFI system, I wouldn’t have enough room for two kernels, so updates would be tricky.

    jh

  • You have a point there. I was thinking the OP’s situation was
    /boot is a reasonable size but just got filled up because it was not being monitored. And, as a result, he made yum sad. So now all he wants is to clean it up just enough to use other stuff, and then as mentioned before reconfigure grub2.cfg to keep only a couple of 3
    kernels around.

    Not going to say that happened to me in ubuntu before. O:)