Re: GSoC 2025 / Igor Svilenkov Bozic (Introduction)

Hi Martin,

Following up on the stretch goal you suggested. I've been exploring how this could be achieved and looking into relevant parts of the source and boot flow.

So far, I've traced the full call path from the userland utility down to the firmware-level SetVariable() runtime service. I've been plumbing around how EFI variables are constructed in userspace (via set_bootorder(), set_variable(), etc.), passed to the kernel via ioctl (EFIIOC_VAR_SET), handled by efi_ioctl_var_set(), and ultimately relayed to the firmware via efi_rt.rt_setvar through efi_runtime_setvar().

It looks something like this:

Userland (efi(8) utility)
└── set_bootorder(int fd, const char *target, const char *bootorder)
└── set_variable(fd, &efi_var_ioc)
└── ioctl(fd, EFIIOC_VAR_SET, &efi_var_ioc)
↓ Kernel entry point
└── efi_ioctl(dev_t dev, u_long cmd, void *data, ...)
└── case EFIIOC_VAR_SET:
└── efi_ioctl_var_set(struct efi_var_ioc *var)
└── efi_ops->efi_setvar(namebuf, &vendor, attrib, size, data)
↓ Calling Firmware's Runtime services (or stub)
└── SetVariable()
(writes to NVRAM eg. Boot####, BootOrder, etc.)

I believe I've got the gist of how NetBSD boot entries are created and where hooks could be added in sysinst to preserve and manipulate EFI Boot#### entries.

Example Use Case: User wants to install NetBSD alongside another OS (like Linux)
- Enumerate existing Boot#### entries
- sysinst detects existing ESP and does not wipe it
- Insert a new entry for NetBSD (e.g. 'NetBSD 10.0')
- Leaves existing Linux entries untouched.
- Update BootOrder in a safe and optional way

What needs to be done to get there (top-level guess):
- Extension of sysinst logic for bootloader placement
- Logic to detect and parse existing EFI entries
- Reuse or extend the efi(8) utility functions for variable management
- Sanity checks for BootOrder consistency
- Safe mount/handling of existing ESPs during install
- Possibly some new command-line flags or install options

I hope this should be enough to start drafting the full detailed GSoC proposal and submit an application, since the application window is now open as of Monday.

Thanks again,
Igor Svilenkov Bozic

On Mon, 24 Mar 2025 at 07:54, Igor Svilenkov <svilenkov%gmail.com@localhost> wrote:

Hi Martin,

Thanks for the feedback. That sounds good for scope expansion, kind of like an automated rEFInd-like functionality. I'll explore in which ways this may be achieved, then get back to you

Best,
Igor Svilenkov Bozic

On Mon, 24 Mar 2025 at 07:04, Martin Husemann <martin%duskware.de@localhost> wrote:
On Sun, Mar 23, 2025 at 06:22:16PM +0100, Igor Svilenkov wrote:
> The goal is to implement proper boot entries, making it nicer to see boot
> menu entries such as ?NetBSD 10.0? instead of the generic
> ?UEFI OS?.

Hi Igor, your proposal sounds good so far.

How about adding a close related but different additional goal as a possible
stretch goal (in case you get everything done quick enough)?

The proper setup of (U)EFI boot options will make it possible to
enhance sysinst to allow automatic installation of NetBSD side by side
on the same disk with other already installed OSes, relying on the
(U)EFI boot selector to pick a system to boot. Strictly speaking this
is not part of the original project, but it is a simple extensions and
will be easy once you are comfortable with the sysinst internals
required for the boot option setup.

Martin