Document "NO" special value for the autoboot_delay and move the
description to loader.conf.5.
imp reworked some of the wording from danger's patch.
Reviewed by: imp
PR: 85128
Differential Revision: https://reviews.freebsd.org/D11887
Large nextboot.conf files (over 80 bytes) are not read correctly by the
Forth loader, causing file parsing to abort, and nextboot configuration
fails to apply.
Simple repro:
nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shutdown -r now
That will cause the bug to cause a parse failure but shouldn't otherwise
affect the boot. Depending on your loader configuration, you may also
have to set beastie_disable and/or reduce the number of modules loaded
to see the error on a small console screen. 12.0 or CURRENT users will
also have to explicitly use the Forth loader instead of the Lua loader.
The error will look something like:
Warning: syntax error on file /boot/loader.conf.local
foo="xxxxxxxxxxxxxxnextboot_enable="YES"
^
/boot/support.4th has crude file I/O buffering, which uses a buffer
'read_buffer', defined to be 80 bytes by the 'read_buffer_size'
constant. The loader first tastes nextboot.conf, reading and parsing
the first line in it for nextboot_enable="YES". If this is true, then
it reopens the file and parses it like other loader .conf files.
Unfortunately, the file I/O buffering code does not fully reset the
buffer state in the reset_line_reading word. If the last file was read
to the end, that doesn't matter; the file buffer is treated as empty
anyway. But in the nextboot.conf case, the loader will not read to the
end of file if it is over 80 bytes, and the file buffer may be reused
when reading the next file. When the file is reread, the corrupt text
may cause file parsing to abort on bad syntax (if the corrupt line has
<>2 quotes in it), the wrong variable to be set, no variable to be set
at all, or (if the splice happens to land at a line ending) something
approximating normal operation.
The bug is very old, dating back to at least 2000 if not before, and is
still present in 12.0 and CURRENT r345863 (though it is now hidden by
the Lua loader by default).
Suggested one-line attached. This does change the behavior of the
reset_line_reading word, which is exported in the line-reading
dictionary (though the export is not documented in loader man pages).
But repo history shows it was probably exported for the PNP support
code, which was never included in the loader build, and was removed 5
months ago.
One thing that puzzles me: how has this bug gone unnoticed/unfixed for
nearly 2 decades? I find it hard to believe that nobody's tried to do
something interesting with nextboot, like load a kernel and filesystem,
which is what I'm doing.
PR: 239315
Reviewed by: imp
When calling file_findfile with only a type it returns
the first file matching the type. But in fdt_apply_overlays we
then iterate on the next files and try loading them as dtb overlays.
Fix this by checking the type one more time.
Sponsored by: Diablotin Systems
Reported by: Mark Millard <marklmi@yahoo.com>
In my initial testing, these are the functions which showed up as
being worth instrumenting. More may be added later.
common/console.c: cons_probe
common/gfx_fb.c: read_list, insert_font, autoload_font
common/interp.c: interact
common/interp_lua.c: interp_init, interp_run
efi/libefi/efipart.c: efipart_readwrite
i386/libi386/biosdisk.c: bd_init, bd_open, bd_edd_io, bd_chs_io, bd_io
libsa/open.c: open
libsa/read.c: read
libsa/twiddle.c: twiddle
Note that profiling interp_run may be of questionable utility as it
may depend on user behaviour (e.g. pressing keys).
Reviewed by: kevans (earlier version)
This adds tslog_init, which allocates a 2MB buffer for recording
timestamped events; and tslog_publish, which takes the buffer and
passes it to the kernel as a "preloaded module". These functions
will be used in a later commit.
Reviewed by: kevans
At present this only supports x86, due to the use of the rdtsc
instruction; and is inert unless a buffer is allocated and passed to
the tslog code (which will be done by a future commit).
Reviewed by: kevans
Caller functions expect __elfN(loadimage) to return a value of zero on
failure and the file size on success.
PR: 256390
Reviewed by: markj
MFC after: 2 weeks
It exist on all ARMv8+ CPUs, and other boot loaders rely on it being
present.
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D30410
A bug in the loader's bzipfs & gzipfs filesystems caused compressed
kernel and modules not to work on EFI systems with a veriexec-enabled
loader. Since the size of files in these filesystems are not known
_a priori_ `stat` would initialize the size to -1 and the loader would
then hang in an infinite loop while trying to seek (read) to the end
of file since the loop termination condition compares the current
offset to that negative target position.
Reviewers: vangyzen, imp, Bret Ketchum (Bret.Ketchum@dell.com)
Differential Revision: https://reviews.freebsd.org/D30414
Sponsored by: Dell EMC Isilon
MFC to: stable/12, stable/13
MFC after: 1 week
The gfx_fb_drawrect() is drawing rectangle by pixels, this can be very
slow on some systems. Use Blt() video fill primitive instead.
Testing done: Tested on mac mini 2012 where the issue was revealed
Reviewed by: yuripv
MFC after: 1 week
There is no need to call it evert 10ms when we need 1s granularity.
Update to update the time every second.
Reviewed by: imp, manu, tsoome
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D30227
According to comments in the Makefile, to make pxeboot work we need to
have crt0.o first. This is needed because the simplified loader in
pxeboot assumes that the startup code is at offset 0 in this binary. In
normal booting, the start address can be obtained from headers of the
binary, but since pxeboot encodes this as a pure binary, it has no way
of knowing where that is and assumes 0. Added comments to that effect
in the Makefile.
We've done this by adding it to OBJS before all the other .o's are
added. However, there's a problem. This also adds it to the CLEANFILES
variable, which causes it to be removed from multiple places. The
dependencies may also cause it to be re-built at a time that's after
boot2 is built. This causes installs to fail because at install time
boot2 is considered to be out of date and the programs to rebuild it are
no longer in the path.
Cope with this problem by just adding it to LDFLAGS instead.
Glanced at by: kevans ("I thought that went in ages ago")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28876
When VECTX is enabled as a kernel option and non-EFI loaders are
built, many reads will fail due to the mis-match of whether
LOADER_VERIEXEC_VECTX or not in readin.h. Source that includes
bootstrap.h must ensure the kernel option agrees with the compile
time CFLAGS in the various make related files.
Submitted by: bret_ketchum@dell.com (original revision)
Reviewed by: sjg, bdrewery, dab, bret_ketchum@dell.com
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29993
As we output spaces around the menu title, we should also check,
if the title is actually empty string.
PR: 255299
Submitted by: Jose Luis Duran
Reported by: Jose Luis Duran
MFC after: 1 week
Until now, the boot image can be embedded into the loader with
/sys/tools/embed_mfs.sh, and memory disk (MD) is already supported
in loader source. But due to memory disk (MD) driver isn't registered
to the loader yet, the boot image can't be boot from embedded memory
disk.
Reviewed by: dab, tsoome
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29512
Add a man page for gptboot.efi. Describe when and how to use this as it differs
from the BIOS cases. Include cross reference for the preferred method described
in efibootmgr(8) as well as cross links in both gptboot(8) and gptboot.efi(8) to
the other.
This man page was heavily copied from the gptboot.8 man page by Warren Block.
They are different enough to need separate man pages for clarity, but there's
enough similarity that I worry about the duplication. In the really long term,
gptboot(8) will disappear, so having the same info here will help when that
day comes. In the short to medium term, the information is likely to not
change in gptboot(8) and any changes to gptboot.efi(8) will be easier to
make in a separate copy.
loader.efi(8) needs a complete rewrite from scratch, otherwise I'd have
referenced gptboot.efi(8) from there.
Suggetions from: cress@, mhorne@
Reviewed by: rpokala@
Differential Revision: https://reviews.freebsd.org/D29591
Add a dummy vendor menu entry on the main welcome menu. Vendors can override
this in their local.lua file to create whatever sub-menu they need for their
products.
Also fix the adding a 'welcome' entry as well based on a suggestion from Kyle.
Silly option menu code also from Kyle. They seem to work for me, but any
transcription error is likely mine.
Reviewed by: kevans@ (the vendor stuff)
LLVM12 complains if you change the symbol binding:
`error: _longjmp changed binding to STB_GLOBAL`
In this case LLVM actually ignored the weak directive and used the
later .global, but GNU as would mark the symbol as weak.
None of the other architectures mark the libsa _setjmp as weak so
just drop this directive.
This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standard library with GCC.
This flag was originally added in back in r94332 but the flag is a no-op
in Clang ("This diagnostic flag exists for GCC compatibility, and has no
effect in Clang"). Removing it should make the GCC build output slightly
more readable.
Reviewed By: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D29235
When drawing cursor, we should store original display
content because there may be image data we would like to restore
when the cursor is removed.
PR: 254054
Reported by: Jose Luis Duran
MFC after: 3 days
This makes bi_load_efi_data cleaner to add common acpi setup code.
Reviewed by: imp, tsoome
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28936
Parentheses added to HASZERO macro to avoid a GCC warning, and formatted
with clang-format as we have adopted these and don't consider them
'contrib' code.
Obtained from: musl (snapshot at commit 4d0a82170a25)
Reviewed by: kib (libc integration), mjg (both earlier)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17630
Calculate font size from 16 density independent pixels (dp) by using:
size = 16 * ppi/160 * display_factor
We are specifying font size 16dp, and assuming 1dp = 160ppi.
Also apply scaling factor 2 (display_factor).
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28849
MIPS BERI boot loader is built with -mno-abicalls and -fno-pic
so prevent adding PIE-related build flags.
Fix build after 9a227a2fd6 ("Enable PIE by default on 64-bit architectures")
Obtained from: Semihalf
Sponsored by: Stormshield
Bootloaders for powerpc are not built as position independent
code. Since bsd.prog.mk is used for building, when PIE is enabled,
the PIE flags are added and that causes the build to fail.
Adding MK_PIE=no stops bsd.prog.mk from adding PIE specific flags.
Submitted by: Dawid Gorecki <dgr@semihalf.com>
Reviewed by: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D28893
When performing buildworld for MIPS with PIE enabled, the build fails
with "position-independent code requires '-mabicalls'" message.
-mno-abicalls and -fno-pic flags are explicitly set in MIPS ubldr
makefile, so to work around this problem, set MK_PIE=no for MIPS
ubldr.
Submitted by: Dawid Gorecki <dgr@semihalf.com>
Reviewed by: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D28370
Check whether we have reached the end of the buffer using search_size
instead of MULTIBOOT_SEARCH, which is the maximum defined by the
specification, but the file can be shorter than that.
This prevents printing a harmless error message when loading a file
that is smaller than MULTIBOOT_SEARCH.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Fixes: adda2797eb ('stand/multiboot2: add support for booting a Xen dom0 in UEFI mode')
Add a missing space in one error message.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Fixes: adda2797eb ('stand/multiboot2: add support for booting a Xen dom0 in UEFI mode')
If we start with console set to comconsole, the local
console (vidconsole, efi) is never initialized and attempt to
use the data can render the loader hung.
Reported by: Kamigishi Rei
MFC after: 3 days
Notable upstream changes:
778869fa1 Fix reporting of mount progress
e7adccf7f Disable use of hardware crypto offload drivers on FreeBSD
03e02e5b5 Fix checksum errors not being counted on repeated repair
64e0fe14f Restore FreeBSD resource usage accounting
11f2e9a49 Fix panic if scrubbing after removing a slog device
MFC after: 2 weeks
Do not attempt to add MODINFOMD_MODULEP to the kernel medatada on
arches that don't have it defined.
This fixes the build for arches different than amd64 after
7d3259775c.
Sponsored by: Citrix Systems R&D
Reported by: lwhsu, arichardson
Add some basic multiboot2 infrastructure to the EFI loader in order to
be capable of booting a FreeBSD/Xen dom0 when booted from UEFI.
Only a very limited subset of the multiboot2 protocol is implemented
in order to support enough to boot into Xen, the implementation
doesn't intend to be a full multiboot2 capable implementation.
Such multiboot2 functionality is hooked up into the amd64 EFI loader,
which is the only architecture that supports Xen dom0 on FreeBSD.
The options to boot a FreeBSD/Xen dom0 system are exactly the same as
on BIOS, and requires setting the xen_kernel and xen_cmdline options
in loader.conf.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28497
This mirrors the functionality of the BIOS amd64 bi_load function,
that stashes the absolute address of the module metadata. This is
required for booting as a Xen dom0 that does relocate the modulep and
the loaded modules, and thus requires adjusting the offset.
No functional change introduced, further patches will make use of this
functionality for Xen dom0 loading.
Sponsored by: Citrix Systems R&D
Reviewed by: imp
Differential revision: https://reviews.freebsd.org/D28496
Xen requires that UEFI BootServices are enabled in order to boot, so
introduce a new parameter to bi_load in order to select whether BS
should be exited.
No functional change introduced in this patch, as all current users of
bi_load request BS to be exited. Further changes will make use of this
functionality.
Note the memory map is still appended to the kernel metadata, even
when it could be modified by further calls to the Boot Services, as it
will be used to detect if the kernel has been booted from UEFI.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28495
While I was there:
- Fix some typos
- Fix an excessive argument "indent" reported by mandoc -Tlint
- Replace a dead link with the one suggested by
https://www.uefi.org/uefi
Submitted by: linimon (in part)
Reviewed by: bcr
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27774
We use ascii box chars with serial console because we do not know
if terminal can draw unixode box chars. Same problem is about userboot
console.
MFC after: 5 days
