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
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).
Chris Murphy wrote:
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).
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., m.roth@5-cent.us va escriure:
Chris Murphy wrote:
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).
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
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, Feb 11, 2016 at 1:19 PM, Devin Reade gdr@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! )
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?
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.
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 ++++++++++++++++++++++++++++++++++++++++
+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.
On 02/13/2016 03:19 PM, Valeri Galtsev wrote:
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 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--
David P. Both, RHCE Millennium Technology Consulting LLC Raleigh, NC, USA 919-389-8678
dboth@millennium-technology.com
www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both
This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately.
On Sat, 13 Feb 2016 21:24, David Both <dboth@...> wrote:
+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.
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
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. 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
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.
On 02/13/2016 03:19 PM, Valeri Galtsev wrote:
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 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--
David P. Both, RHCE Millennium Technology Consulting LLC Raleigh, NC, USA 919-389-8678
dboth@millennium-technology.com
www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both
This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Sat, 2016-02-13 at 15:19 -0600, Valeri Galtsev wrote:
_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.
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 :-)
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 Saturday, February 13, 2016 03:24:53 PM -0500 David Both dboth@millennium-technology.com wrote:
However, Devin, the answer to your question [...]
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
On 2/13/2016 12:19 PM, Valeri Galtsev wrote:
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.
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.
On Sat, February 13, 2016 2:50 pm, John R Pierce wrote:
On 2/13/2016 12:19 PM, Valeri Galtsev wrote:
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.
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.
John, you made my day! It is so wonderful to know I'm not the only one who still does this!
Valeri
-- john r pierce, recycling bits in santa cruz
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
El Sábado 13/02/2016, Valeri Galtsev escribió:
On Sat, February 13, 2016 2:50 pm, John R Pierce wrote:
On 2/13/2016 12:19 PM, Valeri Galtsev wrote:
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.
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.
John, you made my day! It is so wonderful to know I'm not the only one who still does this!
Well, I though this was standard practice, at least for severs.
At work we usually set several partitions (/boot, /, /opt, /var, /var/lib/mysql, /tmp, /home, /home/backup) depending on the use case.
For desktops it's always /boot, / and /home.
Cheers,
On Mon, February 15, 2016 1:00 pm, Ricardo J. Barberis wrote:
El Sábado 13/02/2016, Valeri Galtsev escribió:
On Sat, February 13, 2016 2:50 pm, John R Pierce wrote:
On 2/13/2016 12:19 PM, Valeri Galtsev wrote:
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.
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.
John, you made my day! It is so wonderful to know I'm not the only one who still does this!
Well, I though this was standard practice, at least for severs.
At work we usually set several partitions (/boot, /, /opt, /var, /var/lib/mysql, /tmp, /home, /home/backup) depending on the use case.
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 ++++++++++++++++++++++++++++++++++++++++
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.
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).
-
Always Learning -
Chris Murphy -
David Both -
Devin Reade -
John R Pierce -
Lamar Owen -
m.roth＠5-cent.us -
Mike - st257 -
Oscar Osta Pueyo -
Ricardo J. Barberis -
Robert Nichols -
Timothy Murphy -
Valeri Galtsev -
Yamaban