Differential D22062

Allow loader.efi to identify non-standard boot setup
ClosedPublic
Actions

Authored by sjg on Oct 16 2019, 9:37 PM.

Details

Reviewers

imp
kevans
bcran

Commits

rS354039: Allow loader.efi to identify non-standard boot setup
rS353697: Allow loader.efi to identify non-standard boot setup

Summary

PATH_BOOTABLE_TOKEN can be set to a non-standard
path that identifies a device as bootable.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 27077
Build 25359: arc lint + arc unit

Event Timeline

sjg created this revision.Oct 16 2019, 9:37 PM

Herald added subscribers: bcran, imp. · View Herald TranscriptOct 16 2019, 9:37 PM

Harbormaster completed remote builds in B27077: Diff 63381.Oct 16 2019, 9:37 PM

sjg added reviewers: imp, kevans.Oct 16 2019, 9:38 PM

Just curious what is this a fix for? I assume some specific type or class of hardware.

In D22062#482063, @darkfiberiru_gmail.com wrote:

Just curious what is this a fix for? I assume some specific type or class of hardware.

Downstream OS/vendors that don't have /boot/defaults/loader.conf or /boot/kernel/kernel because they store all of this elsewhere as part of a versioned boot scheme (or something to this effect) -- they'd then define PATH_BOOTABLE_TOKEN as another path to check to determine if this is a valid rootfs.

This revision is now accepted and ready to land.Oct 17 2019, 5:31 PM

In D22062#482064, @kevans wrote:

Downstream OS/vendors that don't have /boot/defaults/loader.conf or /boot/kernel/kernel because they store all of this elsewhere as part of a versioned boot scheme (or something to this effect) -- they'd then define PATH_BOOTABLE_TOKEN as another path to check to determine if this is a valid rootfs.

So how does the loader find the loader.conf and kernel to load? Should users set a different PATH_KERNEL?

In D22062#482141, @bcran wrote:

In D22062#482064, @kevans wrote:

Downstream OS/vendors that don't have /boot/defaults/loader.conf or /boot/kernel/kernel because they store all of this elsewhere as part of a versioned boot scheme (or something to this effect) -- they'd then define PATH_BOOTABLE_TOKEN as another path to check to determine if this is a valid rootfs.

So how does the loader find the loader.conf and kernel to load? Should users set a different PATH_KERNEL?

loader.conf really isn't all that necessary, to be honest. For EFI, one can use the mechanism imp added to salt the environment from a file on the ESP. That file can include a module_path that includes where the kernel/modules actually lives.

I have a vague recollection from years past that @sjg doesn't have a single kernel path that would be sensible for hardcoding as this #define.

bcran accepted this revision.Oct 17 2019, 8:31 PM

Closed by commit rS353697: Allow loader.efi to identify non-standard boot setup (authored by sjg). · Explain WhyOct 17 2019, 8:40 PM

This revision was automatically updated to reflect the committed changes.

sjg added a commit: rS353697: Allow loader.efi to identify non-standard boot setup.

sjg added a commit: rS354039: Allow loader.efi to identify non-standard boot setup.Oct 24 2019, 7:52 PM