On Mon, 2014-08-18 at 00:40 -0500, Christopher Chavez wrote: > (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.) > > 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). Old kernel packages are now auto-removable in Debian and Ubuntu. So this should not be a common problem in future. > 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. This should no longer be a problem since the switch to UEFI. > 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? No, your own background text explains why it might not be possible to load a kernel or initramfs from the root filesystem. Also, we support many more boot loaders than GRUB, with different limitations. > 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.) [...] I don't think so. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity.
Attachment:
signature.asc
Description: This is a digitally signed message part