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.) 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). 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. 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? 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 better.) I attempted to collect some preliminary feedback on IRC (the following was logged publicly): #ubuntu, 25 Jul 2014: > [00:50] 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] 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] 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] 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] chrstphrchvz: You're asking to confuse GRUB, since it expects > /boot/ and /boot/grub/ to be in the same root file-system > [00:59] chrstphrchvz: but specifically, grub/ doesn't vary much in size, > it contains the GRUB loadable modules, the saved environment, and grub.cfg > [01:04] 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] 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] chrstphrchvz: the update-grub scripts might generate incorrect > UUIDs in some circumstances > [01:07] chrstphrchvz: LVM is out of my sphere of knowledge, No > idea how one would boot up a full LVM system . > [01:08] 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] 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] chrstphrchvz: my /boot/grub is currently 8M. I just cleaned > up a dozen kernels just yesterday, pity :/ > [01:02] sarnold, I'm almost certain kernels are in /boot, not > /boot/grub… > [01:03] 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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caafq00njt7jfblw7bpugfhbesunduqw6acbj1zj6tbnb5l6...@mail.gmail.com
Re: Use dedicated partition for /boot/grub instead of /boot
On Mon, Aug 18, 2014 at 12:40:13AM -0500, Christopher Chavez wrote: > > 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.) If it's separate partition, it could be shared between several different bootable Linux systems. Might this actually work, given that files in .boot/grub might end up being updated by any of them? Which might actually be what we want? -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818163350.gb32...@topoi.pooq.com
Re: Use dedicated partition for /boot/grub instead of /boot
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. signature.asc Description: This is a digitally signed message part
Re: Use dedicated partition for /boot/grub instead of /boot
2014/08/18 14:57 "Christopher Chavez" <2000...@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] 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] 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] 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] 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] 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] chrstphrchvz: but specifically, grub/ doesn't vary much in size, > > it contains the GRUB loadable modules, the saved environment, and grub.cfg > > [01:04] 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). >
Re: Use dedicated partition for /boot/grub instead of /boot
On Tue, Aug 19, 2014 at 09:45:03PM +0900, Joel Rees wrote: > 2014/08/18 14:57 "Christopher Chavez" <2000...@gmail.com>: > > > > 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. Old systems used to have a strong restriction on which part of the hard drive could be read by the initial firmware bootloader. The exact boundary changed from time to time, as the dcades wore on, but there was such a restriction often enough that some measure wsas needed so that the initial boot would sastisfy this restriction. The easy way to manage this was to have a separte partition for the these files, and place it near the start of the hard drive. Hence /boot was born. It's probably wise to keep /boot for this purpose, since one of these years we're going to hit the next order-of-magitude restriction. But just what files are subject to such a restriction, and what the file format of that partition should be probably depende on the firmware-level bootloader. At the moment, /boot and the EFI partition seem to have boot-time restrictions, either because of firmware or bootloader restrictions. -- hendrik > > That information used to be a lot more available, until some IPidiots > started trying to claim rights to it. IPidiots? Can I have more details or a reference on these IPidiots? -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819172902.ga29...@topoi.pooq.com
