2014/08/18 14:57 "Christopher Chavez" <20007pr@gmail.com>:
>
> (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.)
Upstream relative to what? Boot managers have their own projects and mailing lists.
> Background:
>
> 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).
debian, at any rate, has not had problems with old kernels filling up the /boot partition for a long time. I don't care for the way it's being done, but it pretty much works.
> 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.
I generally never bothered with a separate /boot on i386 back in the days of Fedora 4 or so, but I knew my BIOS could see the whole drive.
openbsd uses a different partitioning scheme and a different way to boot, fits the boot-up code and all the openbsd partitions within a single BIOS recognized partition. It uses a kind of relay or trampoline technique, so the code that the BIOS passes control off to doesn't ever have to move.
Grub 1 was kind of like that, too, but in a different way. openbsd can boot without a boot manager, but the whole purpose of grub is to hand off the boot to something else.
> Questions:
>
> 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?
I guess it depends on what you mean by easy access. If you mean, to keep the kernel where it can be easily found by the boot manager, yeah, that's one of the big reasons.
That information used to be a lot more available, until some IPidiots started trying to claim rights to it. But you can still find it on wikipedia. But I think your question was answered in the chat session you quoted below. And elsewhere in this thread.
It occurs to me that putting grub in its own partition might make it easier for the various distros to cooperate about updating the grub configuration file. But I don't know if anyone is working on that. I would definitely not do it with the old BIOS partitions. Not enough partitions to work with.
> 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.)
Have you found a way to tell each distro to use the independent grub?
> 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
> better.)
Have you looked at the grub project's site?
> I attempted to collect some preliminary feedback on IRC (the following was
> logged publicly):
>
> #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
or, more specifically, the grub configuration updater tool.
> > [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
> > /boot/grub…
> > [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
But, really, what is it you are after, here?