How to clean up full /boot safely?

[Colin Watson]

On Mon, Feb 12, 2018 at 11:00:06AM +0100, Liam Proven wrote:
> On 10 February 2018 at 22:26, Ralf Mardorf <silver.bullet at zoho.com> wrote:
> > Indeed, but there actually is no plausible reason for GRUB users to
> > seperate /boot from /.
> 
> The main reason _used_ to be that the initial part of the boot process
> was done in Real Mode, via BIOS calls, and this could not access some
> areas of the hard disk (e.g. cylinders above 1024, or anything above
> 511MB on C/H/S EIDE controllers -- i.e. pre-EIDE, or any area above
> 8GB (on pre-UltraATA EIDE controllers).

There are conceivably some similar kinds of requirements on more recent
systems.  For instance, it's possible to use GPT on most non-UEFI
systems with a bit of luck and a following wind, and thus make use of
disks larger than 2TB; but if you do that then you need to make sure
that /boot is in the bottom 2TB of the disk.

http://www.tldp.org/HOWTO/html_single/Large-Disk-HOWTO/ is mostly of
historical interest these days, but contains descriptions of the various
limits that have been in effect at various times.

> The kernel can access anything it likes, once the drivers are loaded
> -- but the kernel must be on something GRUB can read, i.e. a
> straightforward Linux filesystem.

This was the traditional requirement, but GRUB is quite a bit more
powerful these days and can read more than just straightforward
filesystems.

> Things GRUB might have problems with:
> 
> * filesystems that are not built into the kernel but run as modules (e.g. ZFS)
> * filesystems that spread across multiple disks (e.g. ZFS, LVM, software RAID)

All your examples are supported by GRUB.

Of course it's necessary for GRUB to track on-disk format changes, and
the more code you're relying on in the boot loader the more there is to
go wrong, so it's true that there "might" be problems and I can
understand it if people choose to avoid it anyway; but generally
speaking if grub-install manages to work then you're OK.  Things like
LVM are pretty safe these days - the system my email client is running
on has had its /boot on LVM for quite a while now.

(Of course, there might also be problems even with what you might view
as relatively straightforward filesystems.  XFS has had on-disk format
changes in the last few years that GRUB has had to keep up with, for
instance.)

> * filesystems which are encrypted

This is supported by GRUB, although it does mean entering your
encryption passphrase twice.  Depending on your threat model you may or
may not consider this to be worth it.  (It's possible to avoid this
requirement by embedding a keyfile in the initramfs, at the cost of some
administrative effort.)

> However my home server badly needs an upgrade to be useful again. It
> has 2GB RAM and a Linux software RAID5 of 4 × 300GB disks, formatted
> ext4.
> 
> The plan is 8GB of RAM and a Zraid of 4 × 2TB disks using ZFS.
> 
> It boots off a non-RAID drive, but that kind of thing is why /boot is
> still relevant for some.

In principle all this should be fine with GRUB >= 2.02; just not exactly
the most common configuration.  I would try /boot on ZFS, but be
prepared to fall back to a traditional separate /boot in case of
problems.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]