BLUE often translates to DARK BLUE. On BLACK this is hard to
read. Instead, use CYAN which looks good on both black and white
backgrounds.
Discussed with: kevans
Sponsored by: Netflix
* Add PVR bits for POWER10 and POWER11
* Initialize the `err` outvar, in case it's not touched on success by
the hypervisor, to prevent spurious errors.
Notable upstream pull request merges:
#9416 -multiple zio_compress: introduce max size threshold
#10018a10e552b9 Adding Direct IO Support
#15147e419a63bf xattr dataset prop: change defaults to sa
#154547e957fde7 send/recv: open up additional stream feature flags
#158100d77e738e Defer resilver only when progress is above a threshold
#159213cf2bfa57 Allocate zap_attribute_t from kmem instead of stack
#16483 -multiple dmu_objset: replace dnode_hash impl with cityhash4
#164858be2f4c3d zio_resume: log when unsuspending the pool
#1649188433e640 sys/types32.h: Remove struct timeval32 from libspl header
#16496f245541e2 zfs_file: implement zfs_file_deallocate for FreeBSD 14
#16511308f7c2f1 Fix an uninitialized data access
#1652929c9e6c32 Fix handling of DNS names with '-' in them for sharenfs
#16531ddf5f34f0 Avoid fault diagnosis if multiple vdevs have errors
#165396f50f8e16 zfs_log: add flex array fields to log record structs
#16546d40d40913 Evicting too many bytes from MFU metadata
#165513014dcb76 Reduce and handle EAGAIN errors on AIO label reads
#1655480645d658 FreeBSD: restore zfs_znode_update_vfs()
#16565832f66b21 FreeBSD: Sync taskq_cancel_id() returns with Linux
#1656748d1be254 Properly release key in spa_keystore_dsl_key_hold_dd()
#16569141368a4b Restrict raidz faulted vdev count
#16583c84a37ae9 lua: add flex array field to TString type
#1658486737c592 Avoid computing strlen() inside loops
#16587d34d4f97a snapdir: add 'disabled' value to make .zfs inaccessible
#16593224393a32 feature: large_microzap
#16597412105977 Temporarily disable Direct IO by default
#166054ebe674d9 ARC: Cache arc_c value during arc_evict()
Backported pull request merges:
#16613ab777f436 Return boolean_t in inline functions of
lib/libspl/include/sys/uio.h
#16616efeb60b86 FreeBSD: ignore some includes when not building kernel
#16635 ---TBD--- zdb: fix printf format in dump_zap()
Obtained from: OpenZFS
OpenZFS commit: b109925820
OpenZFS tag: 2.3.0-rc1
With 8GB disk image and FAT32, our read offset calculation wraps over
32-bit integer and we end up reading garbage. The problem appears when
disk image is filled with data and the block to bytes translations do
not fit into 32-bit integers.
illumos issue: https://www.illumos.org/issues/16666
Sponsored by: MNX Cloud, Inc.
MFC after: 1 week
These were reported by `mandoc -T lint ...` as errors.
The rendered output (in ascii and html) is not affected by this commit.
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne, Alexander Ziaee <concussious.bugzilla@runbox.com>
MFC after: 3 days
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1454
fsize is using 2 bytes for cluster number, but with fat32 we
actually do have 4 bytes and with large disks the high bytes will be in use.
illumos issue: https://www.illumos.org/issues/16821
Sponsored by: MNX Cloud, Inc.
MFC after: 1 week
Reduce the number of md5c.c between the three of these from two to one
by just reaching into the kernel build for both userland builds. The
precedent for this already exists for sha2 in both cases.
_libmd_ symbol privatization bits have been moved to sys/md5.h and
md5.h remains to #include <sys/md5.h> for compatibility.
This stops exporting MD5Pad() in the process because the kernel stopped
exporting it in 502a35d60f. soversion is bumped accordingly.
This also renames the libc version of stack_protector.c; it previously
only worked by coincidence because .PATH ordering worked out such that
we got the right one, but this is not the case anymore. Remove the
landmine.
PR: 280784 (exp-run)
Reviewed by: allanjude, delphij
Differential Revision: https://reviews.freebsd.org/D34497
In two places we use '0' for a column number. However, the upper left
hand corner of the screen is 1, 1. Fix those two confusions. Also, fix
a comment that flipped the coordinates in a comment (I'm used to the
vt100 convention where it's row, column (eg y, x)) and didn't notice
the rest of the code uses x, y.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D46777
print automatically adds a newline, while printc does not. Use printc in
preference to print for managing the autoboot message. This means we can
use line 24 safely on a 24x80 terminal, restoring some functionality
that was lost in 101afbc6ee.
Note: we still set the default curosor position to 25,1 in screen.lua,
but real VT100s (and successors) will treat any row larger than the
pnumber of rows in a cursor motion command to be the last physical row
(this is so you can move to 9999,9999 and do a cursor location query to
get the size of the screen). Keeping that as is looks better on a
typical VGA console.
Fixes: 101afbc6ee
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D46771
The upstream fix to make lld output for our EFI loaders reproducible
again was committed in 54521a2ff9. Bump lld's LINKER_FREEBSD_VERSION
to be able to check this in the EFI loader Makefile.
MFC after: 3 days
In 5c73b3e0a3 calls to core.loadEntropy were added to core.boot
and core.autoboot; but neither of those is invoked if we disable
the "beastie" menu. Add a core.loadEntropy call to the no-menu
path.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Amazon
Fixes: 5c73b3e0a3 ("Add support for getting early entropy from UEFI")
Differential Revision: https://reviews.freebsd.org/D46637
The EFI RNG on some platforms takes a long time if we request 2048
bytes of entropy, so we would like to request less; but our kernel
Fortuna RNG needs to be fed 2048 bytes in order to consider itself
"fully seeded". If we have between 64 bytes (the size of a single
Fortuna pool and enough to guarantee cryptographic security) and
2048 bytes (what Fortuna wants) then the boot process will hang
waiting for more entropy despite in fact having enough to operate
securely.
Since 64 bytes of entropy is plenty to be cryptographically secure
(an attack of cost ~ 2^128 is infeasible, which implies a mere 16
bytes of entropy), use PBKDF2 (aka pkcs5v2_genkey_raw) to spread
the entropy across 2048 bytes. This is secure since PBKDF2 has
the property that every subset of output bytes has within O(1) of
the maximum possible amount of entropy.
Reviewed by: pjd
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46635
This was previously only available if GELI support was included, but I
want to use it for processing entropy from EFI
Reviewed by: imp
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46634
Add a new loader variable entropy_efi_seed_size which defaults to 2048;
if not defined (e.g. if the /boot/lua/ is updated but /boot/defaults/
isn't) the same 2048 default will be used.
Reviewed by: Val Packett
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46632
On some systems, the EFI GetRNG is slow. Make it show up in flamecharts.
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46631
Wrap each call to a built-in command with TSENTER/TSEXIT to make
it easier to see where time is going in the loader.
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46630
With the new 32-bit UEFI loader, it's convenient to have a sysctl to
figure out how we booted. Can be accessed at machdep.efi_arch
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
Some machines have 64-bit capable cpus but are stuck on 32-bit uefi
firmware.
Add support for them by building a new "loader_ia32" with
LOADER_DEFAULT_INTERP along with the 64-bit one. The loader
can be disabled using MK_LOADER_IA32.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
main.c - Fix rsdp cast.
framebuffer.c -
- Use temp variable instead of directly passing pointer when
EFI_PHYSICAL_ADDRESS is expected.
Also fix FreePages cast.
- Mask framebuffer address given to us by UEFI.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
Using AllocateMaxAddress here means that gfx_state->tg_shadow_fb is
treated as the highest address we can receive. Since
gfx_state->tg_shadow_fb is NULL, we never receive anything. Use
AllocateAnyPages instead.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
In preparation for supporting 64-bit machines with 32-bit UEFI firmware,
add a 32-bit variant of libefi since we need to compile both the 64-bit
version and the 32-bit version at the same time.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
Follow the path of what is done with bsnmp, build the modules along
with the main binary, this allows to build the modules at a moment
where all needed libraries are already built and available in the
linker path instead of having to declare all the libraries which a
flua module will be linked to in _prebuild_libs.
Discused with: markj
Reviewed by: markj, jrtc27, kevans, imp
Accepted by: kevans, imp
Differential Revision: https://reviews.freebsd.org/D46610
For build reproducibility we set PE headers to an arbitrary timestamp.
Nothing in FreeBSD uses this timestamp, but bump it from 2016 to 2024 so
that the timestamp does not seem "too old" in case some third party tool
is used to inspect EFI boot components.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46527
There's a huge variety of situations when booting with UEFI. Document
more of them, hopefully better.
Feedback from: jrtc27
MFC After: 3 days
Sponsored by: Netflix
I added a line to the menu, but didn't adjust so things were a
line off. Make the necessary adjustments.
Fixes: 7cb65be96d
Sponsored by: Netflix
MFC After: 3 days
When the various loaders under stand/efi are built, the resulting
binaries differ over multiple runs, even if WITH_REPRODUCIBLE_BUILD is
used. This is caused by lld multithreading and the custom linker scripts
for the loaders, and affects the following binaries:
* loader_4th.efi
* loader_4th.sym
* loader_4th.sym.full
* loader_lua.efi
* loader_lua.sym
* loader_lua.sym.full
* loader_simp.efi
* loader_simp.sym
* loader_simp.sym.full
Work around this by disabling lld threading for these binaries.
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46271
Have a separate PXEBOOTSIZE variable that acts much like LOADERSIZE
variable to limit the size of the loader used for pxeldr. This allows
people to override it independently of LOADERSIZE, which they may need
to set larger for other reasons. Combined with PXEBOOT_DEFAULT_INTERP,
you can build a larger lua loader, while still being able to build pxeldr
with the 4th one, for example.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46214
Sometimes you need / want a different boot loader than loader_lua for
pkeldr. Provide an option to get either the 4th one or the simp one.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46213
Make it possible to disable pxeboot. This loader will fail to build when
it's too large. When /boot/loader needs to be larger like that, this
options will disable a component whose build will fail. It is an explicit
option rather than implicit when things are too large to force the user to
make the explicit tradeoffs rather than wonder why they have a stale pxeboot
or other odd failure mode.
MFC After: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D46212
The largest loader that works for PXE boot is about 500k. PXE needs low
memory for packets and other driver state, so the largest safe size for
the loader is about 500k. Reduce the size from 560k to 500k so we don't
accidentally break PXE in the future.
Add a comment for people with special needs. If you control the
hardware, it can be safe to have boot loaders as large as 580k or 600k
in some cases. Since the BIOS loader is becoming more and more of a
legacy item, the build variable LOADERSIZE isn't documented. This change
doesn't change that: there's been little demand for this documentation
and in general, users shouldn't change it lightly.
PR: 257018
Sponsored by: Netflix
Use the correct loader code that adds an inactive highlighted menu item
indicating that an update is needed.
My laptop is the only machine that I have a boot menu. I'd debugged the
menu part there, but had all the other changes, including my original
menu code, on my server and hadn't copied it back before pushing.
Fixes: 0eac99f76e
Sponsored by: Netflix
When the boot loader version is too old, add a warning to the boot menu
to maybe catch people's attention.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D45890
If the loader is < 3.0, print a warning that it's too old and needs to
be upgraded.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45889
Each incompatible change we make, we bump the major version. We've not
done the bump in a while, so sync everybody to 3.0. Anything older than
3.0 will be given a warning that their boot loader is too old. We check
only the major version, though, so minor versions can still be bumped
for individual loaders (though I honestly doubt we'll ever need to do
that again).
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D45888
This reverts commit 552f3072af.
loader.command_error was added just after 11.2, but appears to not have
been back ported to 11.x. 11.0 was the first lua loader release, so keep
this compat shim until we sort out what to do.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45883
This reverts commit ab97d42add.
There's too many people in the field with FreeBSD 12.0 loader.efi that
stubbed their toe on upgrading to 14.1 since they'd not updated
loader.efi. While we sort out that mess, add back this workaround. Can
revisit after 14.2 maybe.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45882
This reverts commit 8b9178cd0d.
Really old loader.efi files persist in the field. Revert this to support
it. We need to support this through at least 14.2 now, alas.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45881
This line is no longer needed as fallback, and should have been deleted
in 7870a52598 instead of commented out, but 26 years later, I have a
high degree of confidence that old change was right and we won't need
this line as a fallback.
Sponsored by: Netflix
Reviewed by: kevans, jhb
Differential Revision: https://reviews.freebsd.org/D45880
We long ago changed newvers.sh to make these comments bogus. Remove
them since every single one of them is broken after the $FreeBSD$
removal.
Sponsored by: Netflix
Reviewed by: kevans, jhb
Differential Revision: https://reviews.freebsd.org/D45879
This saves space to allow pxeboot to work again. Users desiring these
features can turn them on for their custom build. While these are useful
for some specialized applications, they aren't needed to boot the
typical system, and we're low on space.
text data bss dec hex filename
Before: 465866 20740 31612 518218 0x7e84a loader_lua.bin
After: 441535 17484 31092 490111 0x77a7f loader_lua.bin
Savings: 28,107 bytes
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D42416
