| 48b29e9e | 29-Sep-2026 |
Krzysztof Galazka <kgalazka@FreeBSD.org> |
loader.efi: Retain standalone network configuration
DHCP initmd discovery used net_configure() to open and configure SNP,
then immediately closed the socket and released the protocol.
Selecting net0
loader.efi: Retain standalone network configuration
DHCP initmd discovery used net_configure() to open and configure SNP,
then immediately closed the socket and released the protocol.
Selecting net0 as currdev subsequently required another exclusive
SNP attach, which may hang on some EDK II firmware.
Keep the configured socket available for ordinary network consumers
so NFS boot can reuse it. Add an explicit deconfiguration operation
and invoke it only when an initmd URL requires handing SNP back
to the firmware network stack.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: imp
Assisted by: Github Copilot (GPT-5.6 Sol)
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D59999
show more ...
|
| 752bde7d | 11-Sep-2026 |
Warner Losh <imp@FreeBSD.org> |
loader: Allow dynmaic creation of MD disks
Augment the md device to allow creation of md devices. This is useful
when UEFI doesn't support RamDisk and in other cases where we have a
handy initrd-lik
loader: Allow dynmaic creation of MD disks
Augment the md device to allow creation of md devices. This is useful
when UEFI doesn't support RamDisk and in other cases where we have a
handy initrd-like image we want to use.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D59418
show more ...
|
| 80ee17c0 | 31-Jul-2026 |
John Baldwin <jhb@FreeBSD.org> |
stand: Improve error handling when loading ELF files
Previously all the 'goto out' statements after the image was loaded into
memory returned success rather than an error. This is despite comments
stand: Improve error handling when loading ELF files
Previously all the 'goto out' statements after the image was loaded into
memory returned success rather than an error. This is despite comments
indicating some of these conditions were in fact errors, and some of
these error conditions (such as missing PT_DYNAMIC) are treated as errors
in the kernel linker.
In addition, when failing to looking up the symbols for the linker
set, those cases returned failure leaking memory (though it's clear
from the original code from commit ca49b3342d1e that only the second
failure was intended to be an actual error).
To avoid more confusion, move the assignment of `ret` to just before
the `out` label so that `goto out` always returns an error. This is a
more consistent pattern with other code in the tree that tends to use
labels for the error case.
Restructure some other code to avoid a few bogus errors.
Specifically, a symbol table is not required so don't treat lack of a
symbol table as an error. Also, if the start symbol for the module
metadata linker set is not found, don't treat that as an error either.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D58540
show more ...
|
| 510e473f | 22-Aug-2025 |
Kyle Evans <kevans@FreeBSD.org> |
stand: add a mechanism to avoid env var propagation to kenv
Our only user of this at the moment is teken.{fg,bg}_color. These are
special because teken is a library common to both the kernel and th
stand: add a mechanism to avoid env var propagation to kenv
Our only user of this at the moment is teken.{fg,bg}_color. These are
special because teken is a library common to both the kernel and the
loader, and we want to avoid having special vars to control the loader
vs. the kernel. Ideally, if a user wants a different set of console
colors, then they set the appropriate teken variable and it
Just Works(TM) everywhere. We can't just avoid setting the env vars,
because we specifically want to install a hook to adjust how loader is
drawn.
This allows us to avoid breaking a kernel config(5) that has some
default teken colors set with our defaults. That's a valid
configuration, even if it might seem weird that they don't want to set
colors in both loader and the kernel -- they may not anticipate spending
any time in loader, and thus prefer to just let it do its default
behavior.
NOKENV is expected to be unset if the value is overwritten, rather than
acting as a persistent marker that we do not want the value to persist
under any circumstance. We can always add another flag bit later for
persistence if we find a use for that, but most variables are fine to
carry over. This is mostly needed for environment variables that we
really just want to set a hook for.
Future work could expand this to break it out to the scripted
interfaces. We have discussed some options like a new built-in command,
or adding a flag to the existing `set` command, but haven't really come
up with a concrete plan to avoid confusion.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D50888
show more ...
|