Re: Use dedicated partition for /boot/grub instead of /boot

2014-08-19 Thread Joel Rees
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] 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-, 

Re: Use dedicated partition for /boot/grub instead of /boot

2014-08-19 Thread Hendrik Boom
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



Re: Use dedicated partition for /boot/grub instead of /boot

2014-08-18 Thread Hendrik Boom
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

2014-08-18 Thread Ben Hutchings
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