Subject: Re: Solutions for EFI booting / copying kernels

From: Mark Hills <[email-masked]>
Date: Sun, 26 Jan 2025 15:16:52 +0000 (GMT)

(useful reply; hope you don't mind me keeping this on-list for all)

On Sat, 25 Jan 2025, Sertonix wrote:

> On 2025-01-21 12:20, Mark Hills wrote:
> > On Mon, 20 Jan 2025, Sertonix wrote:
> > 
> > > > I have a few Alpine systems which use EFI to boot with syslinux.
> > > >
> > > > I'd like to improve this setup.
> > > >
> > > > The kernel+initramfs are copied to /efi, where syslinux finds them.
> > > >
> > > > Invariably, after "apk upgrade" I forget to do this copy, resulting in a
> > > > system that won't boot.
> > [...]
> > > I think it should work if you mount the EFI partition at /boot instead
> > > of /efi. Then there isn't any copying needed.
> > 
> > I had assumed having /boot as some kind of DOS/VFAT filesystem would cause
> > trouble. It 'feels' very wrong, but I had assumed it would cause problem
> > with filenames & permissions managed by apk, disk checks and so on.
> > 
> > Is this a common practice?
> 
> I have used VFAT partitions for /boot without any issue.

Thanks for sharing your experience.

The web shows up some other posts from people allowing /boot to double as 
/efi.

What I dislike about such a proposal is VFAT lacks journaling and other 
robusness features compared to ext4, were this partition to fail a check 
on boot. That's more likely too; now that VFAT is used for a partition 
that changes on each kernel update.

> Mounting /boot as VFAT is as far as I know standard for BIOS boot setups 
> which alpine supports as well. So there shouldn't be any issues with 
> that.

My experience differs; I don't I or my employers have ever seen VFAT here.

Besides, historically LILO _required_ an ext partition to host the kernel 
(perhaps boot or /); SYSLINUX and GRUB are capable of the same.

I can't think of a reason (pre-EFI) that VFAT has ever been required as 
/boot?

Thanks

-- 
Mark

---

From: Liam Proven <[email-masked]>
Date: Mon, 27 Jan 2025 18:47:05 +0000

> that changes on each kernel update.

I don't think this is a significant risk.

VFAT is not a filesystem in its own right: it's the name of Windows
for Workgroups' 32-bit FAT driver VXD. Linux appropriated the name for
its driver for FAT126 with Long File Names, the extension to FAT16
that was used in Windows 95 and Windows NT 3.51.

The problem is that this blurs over about 4 different types of disk format:
* Plain old DOS FAT16 with 8.3 filenames (as used in WfWg 3.11's VFAT)
* Win95 FAT16 with long file names
* Win95 OSR 2.1's FAT32, which became more common with Windows 98.
FAT32 always had LFNs.

> I can't think of a reason (pre-EFI) that VFAT has ever been required as

It hasn't, but the old `/boot` filesystem is not the same thing as the
EFI system partition which we're talking about here.

There have been a few reasons for a `/boot` filesystem:

* Disk over 8GB on an early EIDE machine where the BIOS can only read
from the first 8GB of the drive
* Linux setups where the root volume is not directly accessible from
the bare kernel -- for example
    - Linux with an encryped `/` filesystem
    - Linux with `/` on a filesystem that is not part of the kernel, such as ZFS
    - Linux with `/` on software RAID which must be assembled before
it can be mounted

All legit reasons but usually it would, as you say, be an ext4 or
whatever volume.

The ESP is a different consideration. For it, it is not whether the
Linux kernel can read it: it's whether the UEFI _firmware_ can read
it.

That means that in most machines it has to be a  FAT16 or FAT32
volume. exFAT is more robust but I don't think UEFI can handle it.

I have _heard_ reports of Windows-only machines with the ESP on NTFS
but it's rare.

If you want to use the ESP for the functional role of /boot, then the
systemd-boot bootloader, which is not part of system and which does
not I think _need_ systemd, does this. It is an alternative to GRUB or
Syslinux and it keeps the kernel and the initramfs in the ESP. So, you
need a bigger ESP, but it makes the bootloader much simpler.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: [email-masked] ~ gMail/gTalk/FB: [email-masked]
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053