Use dedicated partition for /boot/grub instead of /boot
(Please let me know if there's a better venue for collecting feedback for this
idea, or additional ones I should solicit feedback from. I primarily use Ubuntu,
but I assume this is as upstream as it gets.)
It has been discussed (in other venues) where a separate /boot partition (e.g.
for btrfs, LVM, and encrypted installations; or to workaround BIOS limitations),
depending on how large it was when created, will have a likelihood of becoming
full after multiple kernel updates, and there are corresponding bug reports
likewise (which I have not listed here).
One proposed measure was to not use a /boot partition in the first place, which
often works, but I have also managed to have installations fail with "core.img
is unusually large", particularly in instances where the disk was pre-formatted,
including Windows multiboot scenarios.
1. Is it the case that the only reason for having a separate /boot was to
provide easy access /boot/grub? I.e., was it intentional to provide easy access
to kernels as well?
2. Would it be a better idea to only have /boot/grub, instead of /boot, on a
separate partition? (I can confirm that it works both when installing and in
existing setups, i.e. grub-install and update-grub both work as expected.)
3. If so, then what should its size be? Does it vary by installation and is it
expected to grow over time? (In my case it requires ~5MB for i386, so I used a
~30MB ext4 partition. I have not considered UEFI, e.g. if using the ESP is
I attempted to collect some preliminary feedback on IRC (the following was
#ubuntu, 25 Jul 2014:
> [00:50] <chrstphrchvz> Does the size of /boot/grub vary by installation or
> over time, making it undesirable for separate partition? see description:
> http://ur1.ca/htmwi (Unsure if a support or development question, since I am
> seeking knowledge/opinion.)
> [00:52] <TJ-> chrstphrchvz: Yes, it can vary slightly as newer kernels are
> installed, if older kernels aren't also removed. I generally use a 512MB
> /boot/ file-system partition
> [00:56] <Bashing-om> chrstphrchvz: A separate /boot is something of an
> anachronism, dating back to limited PC BIOSes that could only handle small
> disks, so the boot files had to be at the start of the disk. Nowadays, this is
> no longer applicable .
> [00:57] <chrstphrchvz> TJ-, I mean specifically /boot/grub rather than /boot
> (i.e. as an alternative). E.g. I can keep /boot on my root partition, and use
> a separate /boot/grub, but is a good idea? (I know it works.)
> [00:58] <TJ-> chrstphrchvz: You're asking to confuse GRUB, since it expects
> /boot/ and /boot/grub/ to be in the same root file-system
> [00:59] <TJ-> chrstphrchvz: but specifically, grub/ doesn't vary much in size,
> it contains the GRUB loadable modules, the saved environment, and grub.cfg
> [01:04] <chrstphrchvz> Bashing-om, GRUB is (theoretically) able to boot LVM
> etc. (what it is typically installed with nowadays) without a /boot partition,
> but it can result in "core.img unusually large" and failing to install (see
> description for cases).
> [01:06] <chrstphrchvz> TJ-, how is it confusing GRUB? grub-install is OK with
> it once mounted properly (and in fstab), and even manually specifying a
> /boot/grub partition at install time is OK.
> [01:07] <TJ-> chrstphrchvz: the update-grub scripts might generate incorrect
> UUIDs in some circumstances
> [01:07] <Bashing-om> chrstphrchvz: LVM is out of my sphere of knowledge, No
> idea how one would boot up a full LVM system .
> [01:08] <TJ-> Bashing-om: GRUB has raid and lvm modules, it can initialise a
> PV->VG->LV to find file-systems
I can find several bug reports mentioning update-grub and wrong UUID's, some of
which are fixed, but none of which describe an issue directly relating to my
suggestion in question 2.
#ubuntu-devel, 25 Jul 2014:
> [00:46] <chrstphrchvz> Main question: does the size of /boot/grub vary by
> installation or over time, making it undesirable for separate partition? see
> description: http://ur1.ca/htmwi
> [00:59] <sarnold> chrstphrchvz: my /boot/grub is currently 8M. I just cleaned
> up a dozen kernels just yesterday, pity :/
> [01:02] <chrstphrchvz> sarnold, I'm almost certain kernels are in /boot, not
> [01:03] <sarnold> chrstphrchvz: yes, I just don't know (and hanve't looked) to
> see if there's any per-kernel data in the /boot/grub that might have grown /
> shrunk over time..
sarnold may be describing grub.cfg, but otherwise relating to question 3.
Thanks for your interest,
Christopher Chavez / chrstphrchvz