Do most people today have /boot on a separate partition, or do they (you) have it on the / partition ? -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin
At Tue, 23 Jun 2015 13:49:08 +0100 CentOS mailing list <centos at centos.org> wrote:> > Do most people today have /boot on a separate partition, > or do they (you) have it on the / partition ?The default CentOS installer always puts /boot on a separate partition. This is mostly because, the default CentOS installer uses LVM for the bulk of the disk and Grub is *generally* clueless WRT LVM (at least Grub V1, not sure how smart Grub V2 is). Also, there are lots of 'fun' options for what/where the root partition can be, not all of them compatible with what Grub (or other boot loaders) know how to deal with. Having /boot on its own (small) partition, using something 'simple' for a file system makes things 'easy' for bootloaders. Once the kernel is fired up it can load all sorts of modules to allow it to mount the root file system, everything from exotic file systems to LVM and RAID, etc. Another advantage of having /boot on its own partition is supporting multiple linux flavors that is, it is possible to 'share' /boot between CentOS, Fedora, Ubuntu, Debian, etc. if one wants to, although it is really easier to pick one system for your 'host' and then install VMs for all of the others, but sometimes one needs to test things with different Linux flavors *on the bare metal* for various reasons.> >-- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller at deepsoft.com -- Webhosting Services
On Tue, Jun 23, 2015 at 01:49:08PM +0100, Timothy Murphy wrote:> Do most people today have /boot on a separate partition, > or do they (you) have it on the / partition ?Not only do I have a /boot partition, but I have a /boot/efi partition. I probably could get away without using the /boot partition, but I've been experimenting with btrfs and snapshots and it makes sense to keep /boot as an ext4 filesystem. I suspect with the move to XFS it might be a good idea to keep an ext4 /boot too. -- Jonathan Billings <billings at negate.org>
Timothy Murphy wrote:> Do most people today have /boot on a separate partition, > or do they (you) have it on the / partition ? >Separate partition, 100% of the time.
On Tue, 23 Jun 2015 10:42:35 -0400 m.roth at 5-cent.us wrote:> Timothy Murphy wrote: > > Do most people today have /boot on a separate partition, > > or do they (you) have it on the / partition ? > > > Separate partition, 100% of the time.Inside / (which is mostly always ext4), 100% of the time. :-) That said, I prefer virtual machines over multiboot environments, and I absolutely despise LVM --- that cursed thing is never getting on my drives. Never again, that is... HTH, :-) Marko
FWIW, we don't use a separate partition and haven't had any issues (we do set up / as a separate partition only 5GB large). We have over 150 systems that have been chugging along with many versions of CentOS this way for years. We only use ext3,4 filesystems though. And no volume manager. On Tue, Jun 23, 2015 at 10:42 AM, <m.roth at 5-cent.us> wrote:> Timothy Murphy wrote: > > Do most people today have /boot on a separate partition, > > or do they (you) have it on the / partition ? > > > Separate partition, 100% of the time. > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >-- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu
I use only / for VMs which tend to be single partition, swap-less. My "real" servers and workstations/laptops will always have a /boot, in case I decide / needs to be on top of LVM, LUKS and so on which will require booting the kernel and then do fancier stuff from the initrd. HTH Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message -----> From: "Timothy Murphy" <gayleard at eircom.net> > To: centos at centos.org > Sent: Tuesday, 23 June, 2015 13:49:08 > Subject: [CentOS] /boot on a separate partition?> Do most people today have /boot on a separate partition, > or do they (you) have it on the / partition ? > > > -- > Timothy Murphy > gayleard /at/ eircom.net > School of Mathematics, Trinity College, Dublin > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos
On Tue, Jun 23, 2015 at 9:27 AM, Robert Heller <heller at deepsoft.com> wrote:> At Tue, 23 Jun 2015 13:49:08 +0100 CentOS mailing list <centos at centos.org> > wrote: > > > > > Do most people today have /boot on a separate partition, > > or do they (you) have it on the / partition ? > > The default CentOS installer always puts /boot on a separate partition. > This > is mostly because, the default CentOS installer uses LVM for the bulk of > the > disk and Grub is *generally* clueless WRT LVM (at least Grub V1, not sure > how > smart Grub V2 is). Also, there are lots of 'fun' options for what/where > the >Accessing /boot within LVM was not possible with legacy GRUB (GRUB1) GRUB2 is much "smarter". I've done a few Debian installs (VMs) with /boot as part of the root partition which was an LV. Those were done as a proof-of-concept, but it also reduced "wasted" space which would otherwise only be usable within the file system for /boot. And the flexibility of having everything a part of LVM (which is great if the file systems in use support shrinking). I'd expect GRUB2 in CentOS7 would allow for /boot within LVM, though I have not tried it.> root partition can be, not all of them compatible with what Grub (or other > boot loaders) know how to deal with. Having /boot on its own (small) > partition, using something 'simple' for a file system makes things 'easy' > for > bootloaders. Once the kernel is fired up it can load all sorts of modules > to > allow it to mount the root file system, everything from exotic file systems > to LVM and RAID, etc. > > Another advantage of having /boot on its own partition is supporting > multiple > linux flavors that is, it is possible to 'share' /boot between CentOS, > Fedora, > Ubuntu, Debian, etc. if one wants to, although it is really easier to pick > one > system for your 'host' and then install VMs for all of the others, but > sometimes one needs to test things with different Linux flavors *on the > bare > metal* for various reasons. > > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > http://www.deepsoft.com/ -- Linux Administration Services > heller at deepsoft.com -- Webhosting Services > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >-- ---~~.~~--- Mike // SilverTip257 //
On Tue, 23 Jun 2015 at 09:27 -0000, Robert Heller wrote:> Another advantage of having /boot on its own partition is supporting > multiple linux flavors that is, it is possible to 'share' /boot > between CentOS, Fedora, Ubuntu, Debian, etc. if one wants to, > although it is really easier to pick one system for your 'host' and > then install VMs for all of the others, but sometimes one needs to > test things with different Linux flavors *on the bare metal* for > various reasons.This might work until the different OS installations start arguing about the version of grub/grub2 and the contents of the grub configuration file (including whose grub configuration files to use). They tend to do this during kernel updates and at other times. Having grub take over your main boot choice is as silly as Windows assuming it is the only OS installed. I have long preferred to use a single / partition for each OS installation and put the system specific grub image in the individual partition. I use the 1 sector (MBR) FreeBSD bootloader to boot the partition I want at boot time. Note that grub2 doesn't like this and spews an error message, but it does work (mostly) (grub2 needs to be fixed to support this functionality and not assume it can become the master boot process). This does tend to limit you to 3 OS choices in the primary partitions (assuming a 4th extended partition for data partitions). That usually is enough for my purposes. With EFI systems, this is changing and my experiences are not complete enough to have strong opinions. It does look like the EFI boot process conceptually handles this by letting the user choose which EFI application to load first (using efimanager). EFI disk based booting does still need the DOS formatted partition often mounted at /boot/efi. For booting encrypted systems, I do put /boot in separate partitions (with the corresponding / being an extended partition). I still use a separate MBR boot loader to select which /boot I use. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone
Lamar Owen
2015-Jun-25 21:22 UTC
[CentOS] LVM hatred, was Re: /boot on a separate partition?
On 06/23/2015 01:54 PM, Marko Vojinovic wrote:> So the story ended up with lots of people in upgrading griefs purely > because they couldn't resize the separate /boot partition, and it was > separate because LVM was present, and LVM was present with the goal of > making partition resizing easy! A textbook example of a catch-22, > unbelievable!! >The Fedora /boot upsize was something I handled relatively easily with the LVM tools and another drive. I actually used an eSATA drive for this, but an internal or a USB external (which would have impacted system performance) could have been used. Here's what I did to resize my Fedora /boot when the upgrade required it several years back: 1.) Added a second drive that was larger than the drive that /boot was on; 2.) Created a PV on that drive; 3.) Added that PV to the volume group corresponding to the PV on the drive with /boot; 4.) Did a pvmove from the PV on the drive with /boot to the second drive (which took quite a while); 5.) Removed the PV on the drive with /boot from the volume group; 6.) Deleted the partition that previously contained the PV; 7.) Resized the /boot partition and its filesystem (this is doable while online, whereas resizing / online can be loads of fun); 8.) Created a new PV on the drive containing /boot; 9.) Added that PV back to the volume group; 10.) Resized the filesystems on the logical volumes on the volume group to shrink it to fit the new PV's space and resized the LV's accordingly (may require single-user mode to shrink some filesystems); 11.) Did a pvmove from the secondary drive back to the drive with /boot; 12.) Removed the secondary drive's PV from the VG (and removed the drive from the system). I was able to do this without a reboot step or going into single user mode since I had not allocated all of the space in the VG to LV's, so I was able to skip step 10. While the pvmoves were executing the system was fully up and running, but with degraded performance; no downtime was experienced until the maintenance window to do the version upgrade. Once step 12 completed, I was able to do the upgrade with no issues with /boot size and no loss of data on the volume group on the /boot drive.