Re: Interest in Add UEFI boot options project and some design questions

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 21 Apr 2026 19:30:00 +0530
    From:        Gautam Agrawal <gautamnagrawal%gmail.com@localhost>
    Message-ID:  <CAG-ETXugxkDstRqwRJHqmpSva+f889DOFZYtVCO_ii2JVj1VXw%mail.gmail.com@localhost>

  |    1. Boot entries and BootOrder
  |    While installing NetBSD using sysinst in a UEFI setup, I observed that
  |    the installer copies bootx64.efi to the fallback path

Martin replied to that already.

  |    2. Multi-boot support approach
  |    To support multi-boot scenarios, I was considering two possible
  |    approaches:
  |
  | a) Extending bootx64.efi (from sys/arch/i386/stand/efiboot) to provide a
  | GRUB-like menu that scans disks/partitions and lists available NetBSD
  | kernels.

As Martin said, please, no.

  | b) Converting the NetBSD kernel image from ELF to PE/COFF format,

The ability to do that (all you suggested) might be useful, as it would allow
(require) the kernel to live directly in the EFI filesystem - but would also
require the kernel to be modified to be able to be booted that way (it currently
requires information passed to it via efiboot (or boot for non EFI booting).
That's all too much for this project.   And not required either.

But there is a (c) that I had been considering, but haven't had the time
(or perhaps energy) to do anything about.   The format of the BOOT#### EFI
variable allows for extra data to exist after the boot path.   That could
be used to embed boot commands (more or less replacing boot.cfg for that
entry, though another possibility would just be to add a path to the desired
boot.cfg file).   efiboot could then use the commands supplied, or the
boot.cfg supplied, to boot whatever kernel is desired, and pass it any
options desired.   That would allow the firmware boot menu to be all that
is needed to boot NetBSD, no second level menus ever needed (but the option
would always remain of course).

  |    4. Userland tool for EFI variable access

Martin implied. but didn't actually say, that this is already done, and we
now have a tool which allows much of this *see efi(8).   It probably could
do with some enhancements, but is good enough to support setting up UEFI
boot menus.

At some time or other, a provervial someone might add a GUI front end to
that to allow some manipulations to be done more easily -- using something
like wish (tcl/tk) for that, and including it as a pkgsrc add on would probably
be best, but a curses based tool, which could go in the base system would also
be possible (a lot more work).  Not intended as part of this project I'd expect.

kre

ps: I don't deal with gmail, so no direct replies possible.