Heads Up: /boot Space On Kernel Upgrade

Home » CentOS » Heads Up: /boot Space On Kernel Upgrade
CentOS 20 Comments

I have a CentOS 6 machine that was initially installed as CentOS 6.4
in May of 2013. It’s /boot filesystem is 200M which, IIRC, was the default /boot size at the time.

The most recent kernel update (2.6.32-573.18.1.el6) fails because of lack of space in /boot. The workaround is edit /etc/yum.conf, reduce installonly_limit from 5 to something lower (I used 3), remove the oldest kernel via ‘rpm -e’, and then re-apply the update. In this case, it was necessary to use the ‘yum update’ command line vs the Update Applet due to an incomplete transaction from the failed update.

Devin

20 thoughts on - Heads Up: /boot Space On Kernel Upgrade

  • Devin Reade wrote:
    Right. Around that time, fedora wanted a gig, and so, seeing the future, we’ve been assigning a gig to /boot for a few years now. I would
    *strongly* recommend that for new or rebuilt systems.

    On the other hand, don’t really see the need to save five previous kernels.

    mark

  • Default boot volume on Fedora is 500M, with a kernel installonly_limit of 3. So far this seems sufficient, even accounting for the “rescue kernel” (which is really a nohostonly initramfs, which is quite a bit larger than the standard hostonly initramfs used for numbered kernels).

  • Chris Murphy wrote:

    IIRC, we saw discussions elsewhere, and … I think it’s called fedup
    (great name, great marketing!) that updated a full release, and it
    *really* needed > 500M, as it was dumping a *lot* in /boot. And, as they say, disk space is cheap, esp. when we buy multiterabyte disks, even for the root drive. (Ok, most of them are 1TB).

    mark

  • Hello, I always used 500~512 with yum configured for clean kernels installation 2.

    Best regards, El dia 11/02/2016 8:25 p. m., va escriure:

  • Hmm, for some reason I decided on ~500MB /boot on the CentOS6 systems I
    built.

    I’ve seen, but not used the yum.conf option for kernel retention. Not many kernels would fit, so in my case cloning was the best option. :-/

    Yeah, having to deal with it being out of space stinks. I’ve gone through it on a system where a former sysadmin set up a 100MB
    /boot partition for that CentOS6 server. Eventually I managed the time to clone the system so that the /boot partition was 500MB.
    ( What a pain in the butt until I fixed it! )

  • Devin Reade wrote:

    As a matter of interest, is there any advantage today in having a /boot partition?
    I thought it went back to the days when the boot-loader had to be near the beginning of the disk?

  • With GRUB legacy, there are some limitations on /boot. It cannot be encrypted, cannot reside on some types of software RAID, cannot be in an LVM logical volume, and must be in an ext2/3/4
    filesystem. If your root filesystem violates any of that, then you need a separate /boot partition. GRUB 2 removes most of those restrictions.

  • It is interesting to observe how perceptions are changing over time. Decade or two ago we were partitioning small then drives (thus loosing some of the space) just to separate regular users from those places vital for secure and reliable running of the system. Security. There days I bet there will be multiple experts who will bag me to death if I will try to offer any pro partitioning argument. This is just a very interesting (for me) observation.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • +1 Valeri. I agree that things have changed a lot!

    However, Devin, the answer to your question is that the /boot partition is a necessity in a LVM environment, which everything else is by default. The /boot partition cannot be a logical volume; it must be a raw disk partition with an EXT[34] file system.

  • I still like making /home its own file system, and if I’m running a substantial (non-trivial) database server, it also has its own volume, quite likely on its own raid.

  • It’s even more relaxed: btrfs and xfs are also valid filesystems with grub2 on C7. If you do some extra legwork you can allow even more filesystems, most of the ssd / flash special filesystems a possible, as long as /boot (also as part of /(root) ) resides on a native disk partition.

    The oh-so-hyped LVM (all versions) is not a valid home for /boot without kompling the kernel AND grub2 yourself, and even then its much easier to move the kernels and initrds into the EFI
    partition (which MUST be vfat32, per spec).

    On bootloaders, well, for bios machines with just linux, or linux + win, nothing was as easy to setup and maintain as “lilo”

    But, for my new box, well it came with UEFI, and (e)lilo was just declared discontiued, and added on top I wanted more than one Linux Distro on the drive, so grub2 was the choice of the day.

    Secureboot with the choice of multiple Distos was easy with grub2, compared to choices for bootloaders.

    YMMV. Have a nice weekend,
    – Yamaban

  • _things_ changed? I wouldn’t quite agree. It is people who have changed definitely. As far as things are concerned, they have changed a lot, but not fundamentally. Disks are huge, but they still are not infinite. Number of inodes filesystem can have increased multiple orders of magnitude, but it is still finite, and so on – one can go through the whole list of good practices dated some 15-20 years back. But we, people, have changed a lot.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • John, you made my day! It is so wonderful to know I’m not the only one who still does this!

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Equipment and prices and have changed significantly since I started in
    1967. Attitudes of genuine computer people have changed a lot less.

    Disk storage will always be finite. Everything is finite, even the universe.

    My first hard disk, for a BBC Micro, was a massive 20 MB. It cost GBP
    320 (circa USD 500). My first mouse cost me GBP 53 (circa USD 80).

    Yes everything continues to evolve, optimistically for the betterment of mankind :-)

  • It is so great to hear that! I was shushed a few times by modern experts –
    I bet on this list too – about following ancient practices and having more than just / partition… so I felt myself as a relic dinosaur, and just kept doing it and kept quiet about that. It nice to be back in a good big company of other like myself ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • ‘Things have changed’ is idiomatic English for the passive voice construct ‘Things have (been) changed’ which translates to the active voice ‘(understood but unvoiced subject) has changed things.’ It is indeed the people who have changed the things.

  • I’ve done this for close to 20 years (19 years this April, to be exact); my current /home has been copied mostly intact (some dotfile stuff left behind, of course) since my Red Hat Linux 4 days.

    It makes certain operations simpler and safer; things like completely reinstalling the OS if required aren’t nearly as problematic with a separate /home (I did this to be able to change / from ext3 to xfs once, for an example).

  • On a public-facing server I tend to make /var a separate partition, and sometimes I’ll go as far as making /var/log a separate partition, since I have been burned before by log file growth. It does depend upon the use case; for my Scalix servers the /var/opt/scalix dir was always on a separate filesystem, and even today on an e-mail server I would likely put /var/spool/mail on a separate partition or logical volume. Nothing like an e-mail DoS to take a server down when / or /var fills up…..

    And I love LVM for the most part, since it allows you to do
    ‘repartitioning’ without really repartitioning. Yeah, it adds a layer of complexity, but flexibility does come at a price, and LVM is very flexible. Although now that most of my storage is on EMC SAN it is easier to resize what the OS considers to be whole disks, and so I will put different filesystems not just on different partitions but on different LUNs and manage with the EMC Unisphere tools.

  • –For the record, I didn’t ask the question; I only posted the original heads-up. That was Tim Murphy asking the question. Watch the attributions, please.

    Devin