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 tried to automate it with kernel-hooks.d; this is run after kernel
upgrades:
$ cat /etc/kernel-hooks.d/efi.hook
cp --verbose --update \
/boot/vmlinuz-* /boot/initramfs-* \
/efi
But is buggy because it runs before initramfs is updated (details below.)
My own "trigger" on apk upgrade could work, but there's no path I can add
one to (they must originate from a package)
Regular syslinux (on MBR) reads the ext4 /boot partition; the EFI variant
cannot do this, and otherwise that would seem to be the best solution.
Perhaps GRUB can, but I like syslinux as it feels straightforward (unlike
GRUB)
--
Mark
$ cat /efi/EFI/syslinux/syslinux.cfg
TIMEOUT 20
PROMPT 1
DEFAULT lts
LABEL lts
LINUX /vmlinuz-lts
INITRD /initramfs-lts
APPEND root=/dev/vg0/root modules=ext4 quiet
$ ls /efi
EFI initramfs-lts vmlinuz-lts
$ doas apk upgrade
[...]
(13/17) Upgrading linux-lts (6.6.68-r0 -> 6.6.71-r0)
(14/17) Upgrading linux-lts-doc (6.6.68-r0 -> 6.6.71-r0)
(15/17) Upgrading linux-lts-dev (6.6.68-r0 -> 6.6.71-r0)
[...]
Executing busybox-1.36.1-r29.trigger
Executing kmod-32-r0.trigger
Executing kernel-hooks-0.2-r0.trigger
kernel-hooks: executing hook 20-akms.hook (lts, 6.6.71-0, 6.6.68-0)
akms: Uninstalling module acpi_call/1.2.2-r0 from kernel 6.6.68-0-lts
akms: Building module acpi_call/1.2.2-r0 for kernel 6.6.71-0-lts
make: Entering directory '/usr/src/linux-headers-6.6.71-0-lts'
CC [M] /var/lib/akms/6.6.71-0-lts/acpi_call/1.2.2-r0/build/acpi_call.o
MODPOST /var/lib/akms/6.6.71-0-lts/acpi_call/1.2.2-r0/build/Module.symvers
CC [M] /var/lib/akms/6.6.71-0-lts/acpi_call/1.2.2-r0/build/acpi_call.mod.o
LD [M] /var/lib/akms/6.6.71-0-lts/acpi_call/1.2.2-r0/build/acpi_call.ko
make: Leaving directory '/usr/src/linux-headers-6.6.71-0-lts'
akms: Installing module acpi_call 1.2.2-r0 for kernel 6.6.71-0-lts
akms: Module acpi_call/1.2.2-r0 for 6.6.71-0-lts installed successfully
kernel-hooks: executing hook efi.hook (lts, 6.6.71-0, 6.6.68-0)
+ cp --verbose --update /boot/vmlinuz-lts /boot/initramfs-lts /efi
'/boot/vmlinuz-lts' -> '/efi/vmlinuz-lts'
Executing akms-0.2.1-r0.trigger
Executing ca-certificates-20241121-r1.trigger
Executing gtk-update-icon-cache-3.24.43-r0.trigger
Executing desktop-file-utils-0.27-r0.trigger
Executing mkinitfs-3.10.1-r0.trigger
==> initramfs: creating /boot/initramfs-lts for 6.6.71-0-lts
Executing mandoc-apropos-1.14.6-r13.trigger
Executing syslinux-6.04_pre1-r15.trigger
/boot is device /dev/nvme0n1p2
Executing texinfo-7.1-r1.trigger
OK: 5847 MiB in 1489 packages
Mark Hills wrote in
<8f3899df-71b7-6562-7688-7bebc6ac1f94@xwax.org>:
|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.
Use overlay / --bind mounts?
Why use a boot loader at all, i think the AlpineLinux kernel has
EFI_STUB enabled? efibootmgr and you should be fine.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|In Fall and Winter, feel "The Dropbear Bard"s pint(er).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear
On 19 January 2025 03:43:00 GMT, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> Mark Hills wrote in> <8f3899df-71b7-6562-7688-7bebc6ac1f94@xwax.org>:> |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.> > Use overlay / --bind mounts?
Can you be more specific please? How to apply these to the problem.
> Why use a boot loader at all, i think the AlpineLinux kernel has> EFI_STUB enabled? efibootmgr and you should be fine.
Is that an improvement though? It locks in the need for kernel+initramfs to be on the EFI partition, but doesn't help with making it happen.
--
Mark
> 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 tried to automate it with kernel-hooks.d; this is run after kernel > upgrades:>> $ cat /etc/kernel-hooks.d/efi.hook> cp --verbose --update \> /boot/vmlinuz-* /boot/initramfs-* \> /efi>> But is buggy because it runs before initramfs is updated (details below.)>> My own "trigger" on apk upgrade could work, but there's no path I can add > one to (they must originate from a package)>> Regular syslinux (on MBR) reads the ext4 /boot partition; the EFI variant > cannot do this, and otherwise that would seem to be the best solution. > Perhaps GRUB can, but I like syslinux as it feels straightforward (unlike > GRUB)
I think it should work if you mount the EFI partition at /boot instead
of /efi. Then there isn't any copying needed.
You would need to copy all existing contents of /boot to /efi and then
change in /etc/fstab change /efi to /boot. Then you should be able to
reboot/upgrade just fine. To clean up the duplicate files you would need
to unmount /boot after a reboot and then remove the files that were
hidden by the mount (and probably reboot before any upgrade). Be carefull
to not delete the wrong file though.
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?
Thanks
--
Mark
On Wed, 15 Jan 2025 at 05:50, Mark Hills <mark@xwax.org> wrote:
>> The kernel+initramfs are copied to /efi, where syslinux finds them.
That is the wrong mount point.
Your ESP should be mounted at `/boot/efi`. Whatever your boot loader.
The Arch wiki has more info:
https://wiki.archlinux.org/title/Syslinux#UEFI_systems
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
On Tue, 21 Jan 2025, Liam Proven wrote:
> On Wed, 15 Jan 2025 at 05:50, Mark Hills <mark@xwax.org> wrote:> >> > The kernel+initramfs are copied to /efi, where syslinux finds them.> > That is the wrong mount point.> > Your ESP should be mounted at `/boot/efi`. Whatever your boot loader.>> The Arch wiki has more info:> > https://wiki.archlinux.org/title/Syslinux#UEFI_systems
Can you more specific... how does changing the mountpoint help? (or why is
that a problem here?)
Especially since Alpine other docs state /efi:
https://wiki.archlinux.org/title/EFI_system_partition
But even that page discusses OS-specific mechanism to copy kernels to this
partition.
--
Mark
On Thu, 23 Jan 2025 at 00:45, Mark Hills <mark@xwax.org> wrote:
>> Can you more specific... how does changing the mountpoint help? (or why is> that a problem here?)
I am not sure that it _will_ help, but this is the standard mountpoint
on every distro I have seen so far.
> Especially since Alpine other docs state /efi:>> https://wiki.archlinux.org/title/EFI_system_partition
Wow! OK, I sit corrected. I suspect that doc may be old and pre-standardisation.
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053