boot: Segmentation fault message

[jggimi]

I'm not there and cannot see over your shoulder, but my opinion differs regarding the apparent root cause.

I would guess that the root cause is a damaged /bsd file, as that file is the source of the kernel symbol name list being created by kvm_mkdb. The program goes off the rails because the input is not valid. I assume that strtab + sbuf.st_name in nlist.c line 218 points outside the kernel address space, causing the segfault.

[shep]

This has always bothered me that I did not get to a conclusion but I think this was not actually a bug.

I noticed that some Linux (Fedora, RHEL, Centos, Rocky) systems use /boot/efi/BOOT/BOOTX64.EFI which is exactly where OpenBSD puts its BOOTX64.EFI. If you install one of the conflicting linux systems followed by a GPT/EFI OpenBSD install, OpenBSD overwrites the Linux BOOTX64.EFI and the Grub Linux boot option will boot OpenBSD. For that reason, I would rename OpenBSD BOOTX64.EFI to BSD_BOOTX64.EFI. Re-linking in OpenBSD would subsequently fail.

Debian, and it's derivatives do not use the same location and if the OpenBSD BOOTX64.EFI file is not renamed, there are no kernel re-linking errors.

Two thoughts on fixing. Upstream i could make this a configurable option in the re-linking code or if the BSD's rename their *.EFI's to something like NBSD_BOOTX64.EFI, OBSD_BOOTX64.EFI and FBSD_BOOTX64.EFI.

[IdOp]

While I've not used one of the "conflicting" Linuxes, or grub ... just a thought:

Maybe you could move their EFI boot stuff into a different directory, and tell the UEFI firmware where to find it with the Linux efibootmgr program?

[shep]

Originally Posted by IdOp

Maybe you could move their EFI boot stuff into a different directory, and tell the UEFI firmware where to find it with the Linux efibootmgr program?

That was my initial work around based on this:

https://ackstorm.de/posts/uefi-openb...dual-boot.html

I think this 2016 guide was before OpenBSD implemented kernel re-linking. My system still functioned but without the security of a re-linked kernel

I suspect it was because the OpenBSD re-linking code was looking for /boot/efi/BOOTX64.EFI. It the file was renamed/relocated, it would not be found.