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
m.roth at 5-cent.us
2016-Feb-11 18:45 UTC
[CentOS] heads up: /boot space on kernel upgrade
Devin Reade wrote:> 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. >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).
On Thu, Feb 11, 2016 at 1:19 PM, Devin Reade <gdr at gno.org> wrote:> 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. >Hmm, for some reason I decided on ~500MB /boot on the CentOS6 systems I built.> > 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. >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! ) -- ---~~.~~--- Mike // SilverTip257 //
Devin Reade wrote:> 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.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? -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin
On 02/13/2016 05:57 AM, Timothy Murphy wrote:> Devin Reade wrote: > >> 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. > > 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. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
On Sat, February 13, 2016 5:57 am, Timothy Murphy wrote:> Devin Reade wrote: > >> 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. > > 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? >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 ++++++++++++++++++++++++++++++++++++++++
On 02/13/2016 04:19 PM, Valeri Galtsev wrote:> On Sat, February 13, 2016 2:24 pm, David Both wrote: >> +1 Valeri. I agree that things have changed a lot! > _things_ changed? I wouldn't quite agree. It is people who have changed > definitely.'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.
On 02/13/2016 03:50 PM, John R Pierce wrote:> 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. >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 02/15/2016 02:12 PM, Valeri Galtsev wrote:> 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... 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.