This feature is marked as ZFEATURE_FLAG_READONLY_COMPAT and so
irrelevant for read-only pool imports by the loader:
"com.delphix:spacemap_v2"
This should cause no functional changes, just a code cleanup.
I'm sorry, missed it in previous commit.
MFC after: 2 months
These features are marked as ZFEATURE_FLAG_READONLY_COMPAT and so
irrelevant for read-only pool imports by the loader:
"com.datto:resilver_defer",
"com.delphix:obsolete_counts",
"com.delphix:spacemap_histogram",
"com.delphix:zpool_checkpoint",
"com.intel:allocation_classes",
"org.zfsonlinux:allocation_classes"
This should cause no functional changes, just a code cleanup.
MFC after: 2 months
To read/update the boot loader nvstore, we always need to call
zfs_attach_nvstore() regardless of whether we use bootonce key
in nvstore or the bootfs property of the pool. The call was
unintentionally left in the block of code that is processed
only when bootonce key is present.
In particular this fixes broken 'nextboot -k'.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41795
Fixes: e3e2681d0e
The module entries should generally allow whatever is allowed as an
env_var in the pattern table. Notably, we're missing periods which
would allow proper entries for .dtb files in loader.conf that don't need
to specify a module_name entry for it.
%d in this expression is actually redundant as %w is actually
"all alphanumerics," but I've included it for now to match the env_var
entry. We should really remove it from both.
Reported by: "aribi" on the forums via allanjude@
MFC after: 1 week
9600 was a standard baud rate decades ago, but 115200 is now more common
so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains
unchanged.
Reviewed by: bz, imp, manu
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36295
We plan to increase the default serial rate to 115200 (see review
D36295) but early boot components that use BIOS interfaces do not
support higher rates. Add a note to that effect.
Reported by: imp
Sponsored by: The FreeBSD Foundation
By not exporting _start, we get various warnings of the form:
ld: warning: cannot find entry symbol _start
Note that in practice these don't matter because we manually construct
our PE header and use objcopy -O binary, so the entry point is set to
whatever we put explicitly in the PE header, but we should still do the
right thing and silence these warnings.
This was found in CheriBSD, where bsd.prog.mk has similar logic to
bsd.lib.mk and sets -Wl,--(no-)fatal-warnings based on LD_FATAL_WARNINGS
(unlike FreeBSD which only does so in the latter).
The removal of the sparc64 support in February 2020 obsoleted the
VTOC8 partitioning scheme as no other FreeBSD platform makes use
of it. Moreover, the code is bitrotting as nothing defines e. g.
LOADER_VTOC8_SUPPORT any more and, thus, should go now, too. With
this change, the following commits are reverted as far as VTOC8
is concerned and parts haven't already previously been deleted
along with prior sparc64 removals:
094fcb157da7d366e958ba8d50d08b
The alignment example d9711c28ef
added to the VTOC8 section of gpart.8 is folded into the MBR one.
This should finally conclude the deorbit of sparc64-specific bits.
We had joy, we had fun
we ran Unix on a Sun.
But that source and the song
of FreeBSD have all gone.
Credits to Michael Bueker for the original "Unix on a Sun" and Rod
McKuen for the "Seasons in the Sun" lyrics.
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
As a result, it is only really checking for the word Drive, making
"Drive" appended to anything else considered for efi env.
Reviewed by: imp, kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/738
Before this change we would only pass the bootonce dataset name
to the environment for the next loader, while actually reading
the next stage loader from the 'bootfs' dataset, not the bootonce
dataset.
Another problem fixed by this change is a boot from a configuration
when bootonce attribute is present, but 'bootfs' property is not set.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40389
First check if bootonce is configured and if it is, then change currdev
accordingly and after that do the sanity check. This fixes boot in a
situation when ZFS pool doesn't have the "bootfs" property, but has
bootonce attribute set. A strange, but legitimate case.
Reviewed by: tsoome, imp
Differential Revision: https://reviews.freebsd.org/D40388
We don't keep comc_port around anymore if the console's not present, but
some things might still try to set one of the environment variables we
hook. In particular, one need not even set efi_com_port/efi_com_speed
in loader.conf; loader may do it itself and induce the crash if ConOut
depicts an available uart.
Probably reported by: dch
OK for now: imp
If we can't find the serial port, free comc_port and return early. The
serial port just isn't there.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D40223
Make the compat code more correct by probing using the eficom console
structure, not the comconsole one.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D40222
If the machine isn't hyperv on amd64, then this driver fails the probe
and will do nothing further now, even if explicitly listed in a config.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D40221
Don't even have a comc_port when the port doesn't exist: always free it
if we probe that it's not there. Also, when it's not present, clear the
flags indicating presence to avoid disturbing other flags.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D40220
It would be nice to make decisions early in boot, about maybe consoles,
based on smbios variables. Set them just after we setup the archsw so we
can use them everywhere.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D40219
UEFI device path may be path to one device, or concatenated list of instances
to different devices (textually represented as comma separated list).
Provide generic function to get next instance from device path.
Returns next instance or end node.
The use case is like:
EFI_DEVICE_PATH *node = (EFI_DEVICE_PATH *)buf;
while (!IsDevicePathEnd(node)) {
process(node);
node = efi_devpath_next_instance(node);
}
Where buf is pointing to either single device path or
concatenated list of device paths (such as from ConIn or ConOut).
Reviewers: imp
Differential Revision: https://reviews.freebsd.org/D40081
Commit e32fecd0c2 intended to skip installing all but one copy of
each loader variant's help file, but accidentally skipped all copies for
the userboot help file. (Other loaders install help files via the _simp
variant, but there is is no userboot_simp.)
PR: 271178
Fixes: e32fecd0c2 ("loader: install help files only once")
Sponsored by: The FreeBSD Foundation
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Remove the i386 ifdefs and files. It never worked.
Sponsored by: Netflix
Reviewed by: manu, tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D40012
Only set the baudrate when it is different than what the device has
reported. In addition, pass in the args to effect no change to the other
parameters to the serial port. Some EFI firmware gets cranky when you
set them to the same value, so avoid doing so (we likely can remove the
HyperV workaround with this fix, but I kept it in place). Add comments
to the code for why we do this too.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D40010
Remove rtsdtr_off. It's basically unused. Expand its meaning, but put
changing flow control to under an ifdef. We shouldn't set it unless
we're sure we need to do so. UEFI normally initializes the device
correctly, and we should avoid needless changes that aren't user
requested.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D40009
Rename efiserialc to eficom.c and move it to libefi. Remove
loader.efi.h, since it's not needed. It's architecture independent
(though how we use it might vary). Drivers also belong in libfoo
in the boot loader: all the BIOS drivers are in i386/libi386 and
the console driver is in efi/libefi.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D40007
Add a compat shim for the "comconsole" name so that people with a
"console=comconsole" in their loader.conf on aarch64 will continue to
work (though with a warning).
This is only aarch64: it will never be there for amd64 (where comconsole
always means talk to the hardware directly). To do that is too hard.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39983
Fix the 'renaming kludge' that we absolutely cannot do going forward
(it's cost us days of engineering time).
console=comconsole talks to the hardware directly. This is available
only on amd64. It is not available anywhere else (and so requires
changes for people doing comconsole on aarch64)
console=eficom talks to the console via EFI protocols. It's available
on amd64, aarch64 and riscv64. It's the first port that we find, though
it can be overriden by efi_com_port (which should be set to the UID of
the serial port, not the I/O port, despite the name). devinfo -v
will give the UID to uartX mapping.
This is an incompatible change for HYPER-V on amd64. It only works with
eficom console, so you'll need to change your configuration in
loader.conf. No compatibility hack will ever be provided for this (since
it requires renamig, which the loader cannot reliably do).
It's also an incompatible change for aarch64. comconsole will need to
change to eficom. There might be a comconsole "shim" for this.
All the interlock to keep only eficom and comconsole from both attaching
have been removed.
RelNotes: Yes
Sponsored by: Netflix
Discussed with: kevans
Differential Revision: https://reviews.freebsd.org/D39982