To recap the problem: with a black-on-white xterm, the menu draws terribly.
Ideally, we would try our best for a white-on-black context for the menu
since graphics and whatnot might not be tested for other setups and there's
no reasonable way to sample the terminal at this point for the used color
scheme.
This commit attempts to address that further in two ways:
- Instead of issuing CSI bg/fg resets (CSI 39m and CSI 49m respectively for
"default"), issue CSI bg/fg escape sequences for our expected color scheme
- Reset to *our* default color scheme before we even attempt to load the
local module, so that we personally don't have any earlier text with the
console default color scheme.
Reported by: emaste (again)
dteske@, I believe, had originally pointed out that lualoader failed to
allow logo-*.lua for new logos to be added. When correcting this mistake, I
failed to do the same for brands.
Correct the sub-mistake: creating new brands is almost identical to creating
new logos, except one must use `drawer.addBrand` and 'graphic' is the only
valid key for a branddef at the moment.
While here, I've added `drawer.default_brand` to be set to name of brand to
be used (e.g. 'fbsd', project default).
Eventually this whole goolash will be documented.
Reported by: kmoore, iXsystems
We support both of the following cases of substitution:
bar="y"
foo="${bar}"
foo="$bar"
The latter substitution syntax is, of course, not recommended- all
punctuation must be considered potential variable names, and we do not go
through the effort of searching the different combinations of, for instance,
"$x.y.z" to determine if the variable is $x, $x.y, or $x.y.z.
This is not officially documented as supported, but it has worked in
forthloader for what is most likely a long time as `evaluate` is used to
process the right hand side of the assignment.
loader.conf(5) documents loader_conf_files to mean "additional configuration
files to be processed right after the present file." However, lualoader
ignored loader_conf_files after processing /boot/defaults/loader.conf.
Rewrite these bits to process loader_conf_files after each loaded file.
e.g. boot_mute, boot_single, boot_verbose, and friends; we checked for these
in multiple places, consolidate into common/ and allow a setting of "NO" for
any of these to turn them off. This allows systems with multiple
loader.conf(5) or loader.conf(5) overlay systems to easily turn off
variables in later processed files by setting it to NO.
Reported by: Nick Wolff @ iXsystems
Reviewed by: imp
- jhb implemented UFS write support a little over 16 years ago.
- Update the library name while we're here.
Reviewed by: jhb, rpokala
Differential Revision: https://reviews.freebsd.org/D14476
This will not be executed on reload, though later work could allow for that.
It's intended/expected that later work won't generally need to happen on
every config load, just once (for, e.g., menu initialization) or just when
config is reloaded but not upon the initial load.
r330809 replaced duplication of devdesc struct fields with an embedded copy
of the devdesc struct, to avoid fragility. That means all the scattered
comments indicating that structs must match are no longer valid. Likewise
asserts that attempted to mitigate some of the old fragility.
Reviewed by: imp@
This makes them compatible with the C standard signatures, avoiding
spurious mismatch errors in the places where the oddball requirements
of standalone code end up putting two declarations of the same function
in play.
* Make autoboot() a static function in stand/common/boot.c, so it does
not shadow local variables in gptboot.c and zfsboot.c.
* Remove -Winline from the Makefiles for gptboot, gptzfsboot and
zfsboot, as gcc will always fail to inline some functions, and there
is nothing we can do about it.
* For gcc <= 4.2.1, silence -Wuninitialized for isoboot, as it produces
a false positive warning.
* Remove deprecated and unnecessary -mcpu=i386 flag from stand/defs.mk,
as there is already a -march=i386 flag further in the file.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D15628
than doing weird type-punning that happened to work because the size
was right. We copied a zfs devdesc into a disk_devdesc and then after
passing through a NULL pointer reinterpreted it as a
zfs_devdesc. Instead, pass the base devdesc around and 'upcase' when
we know the types are right.
This has the happy side effect of fixing a gcc warning about bad
type punning.
Differential Revision: https://reviews.freebsd.org/D15629
If the check for a UFS partition at offset 0 on the disk fails, check
to see if there's a BSD disklabel at block 1 (standard) or at offset
512 (install images assume 512 sector size). If found, probe for UFS
on the 'a' partition.
This fixes UEFI booting images from a BSD labeled MBR slice when the
'a' partiton isn't at offset 0. This is a stop-gap fix since we plan
on removing boot1.efi in FreeBSD 12. We can't easily do that for 11.2,
however, hence the short MFC window.
Tested by: emaste@
MFC After: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D15598
r329190; sparc64 kernels are always 64-bit but with that revision
in place, the loader was treating them as 32-bit ones.
- In order to reduce the likelihood of this kind of breakage in the
future, #ifdef out md_load() on sparc64 and make md_load_dual() -
which is currently local to metadata.c anyway - static.
- Make md_getboothowto() - also local to metadata.c - static.
- Get rid of the unused DTB pointer on sparc64.
Perhaps RB_MUTE could mute user startup (rc) output as well, but right
now it mutes only kernel console output, so make the documentation match
reality.
PR: 228193
Sponsored by: The FreeBSD Foundation
Even though we don't use it, it appears something else requires it to
be != 0 to work. This breaks tftp boot in loader.efi, so revert until
that can be sorted out.
If the 'n' flag is provided the provided key number will be used to
decrypt device. This can be used combined with dryrun to verify if the key
is set correctly. This can be also used to determine which key slot we want to
change on already attached device.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D15309
Contrary to what the message says, this is not only executed in an EFI
context- it provides functions for use in an EFI environment. I don't think
there's much reason to broadcast this fact when we haven't in the past, so
just remove it.
Reported by: emaste (a while ago), cperciva
r332090 added a LINKER_TYPE test to add the --no-rosegment flag when
linking the i386 loader components with lld. Instead, introduce a
general mechanism for setting LDFLAGS for a specific linker type,
and use it for --no-rosegment.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14998
- We should be setting a known graphics mode on conout, but we aren't.
- We shouldn't be setting gop mode if we didn't find a good resolution to
set, but we were. This made efi_max_resolution=1x1 effectively worthless,
since it would always set gop mode 0 if nothing else.
Harry Schmalzbauer reports that some firmware, in his experience, trips
over the ESP we install due to the volume label. It has been theorized that
this is due to some confusion with the label and the path on the ESP to
boot1.efi.
Regardless, Harry found that renaming the label seems to fix it.
PR: 214282
MFC after: 3 days
Since we do free subtopic and desc in help_getnext(), we need to set them also
NULL, so we make sure we dont get double free().
Approved by: bapt
Differential Revision: https://reviews.freebsd.org/D15082
With r328289 we attempt to make sure we free the resources allocated in
help_getnext(), however, it is possible that we get no resources allocated
and help_getnext() will return early.
Make sure we have pointers set to NULL early in help_getnext().
Reported by: Andy Fiddaman
While Arcnet has some continued deployment in industrial controls, the
lack of drivers for any of the PCI, USB, or PCIe NICs on the market
suggests such users aren't running FreeBSD.
Evidence in the PR database suggests that the cm(4) driver (our sole
Arcnet NIC) was broken in 5.0 and has not worked since.
PR: 182297
Reviewed by: jhibbits, vangyzen
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15057
Refactor the currdev setting to find the device we booted from. Limit
searching when we don't already have a reasonable currdev from that to
the same device only. Search a little harder for ZFS volumes as that's
needed for loader.efi to live on an ESP.
Sponsored by: Netflix
Differential Review: https://reviews.freebsd.org/D13784
There's problems with them. The order of efi stuff isn't quite right,
and there's various problems. Revert until thos problems can be fixed.
Reviewed by: kevans@
