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@
Earlier efforts to stop loading the menu broke the ability to skip the menu
with, e.g., beastie_disable in loader.conf(5) as it was decided before
configuration was read.
Defer bringing in the menu module until we've loaded configuration so that
we can make a more informed decision on whether the menu should be skipped
or not.
btxld does not correctly handle input with other than 2 PT_LOAD
segments. Passing --no-rosegment lets lld produce output eqivalent to
ld.bfd: 2 PT_LOAD segments and no PT_GNU_RELRO.
PR: 225775
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14956
When booted via isoboot(8) loader will be handed a disk that simply contains
an ISO9660 image. Currently this confuses it greatly. Teach it how to spot
that it's in this situation and that ISO9660 has one "partition" covering
the whole disk.
Reviewed by: imp
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14915
This is part of a project for adding the ability to create hybrid CD/USB boot
images. In the BIOS case when booting from something that isn't a CD we need
some extra boot code to actually find our next stage (loader) within an
ISO9660 filesystem. This code will reside in a GPT partition (similar to
gptboot(8) from which it is derived) and looks for /boot/loader in an
ISO9660 filesystem on the image.
Reviewed by: imp
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14914
Effectively disabling the mode changing bits in the loader. No matter which
way we go with it, it seems to be wrong- either the firmware doesn't change
the resolution and reports the resolution we requested, or the firmware
changes the resolution and doesn't report the resolution we requested. It
some cases, it does the right thing, but the bad cases outweight those.
Interested individuals can still set efi_max_resolution to 1080p or whatnot
in loader.conf(5) to restore the new behavior, but the new behavior does not
work out well for many cases.
Discussed with: imp
This commit splits all of the logodefs/graphics out into their own own files
and provides a method for these files to register their logodefs with the
drawer. Graphics are now loaded on demand if they don't exist in the current
set of logodefs.
The drawer module becomes a little easier to navigate through without all of
the graphics mixed in. It's also easy to do one-off graphics like the
9.2 Die Hard tribute by dteske@ without adding even more to our memory
requirements.
- No need for a 'goto' when our entire loop body is then wrapped in a
conditional.
- No need to leave commented out prints laying around
- If an expression is clearly going to be either nil or an expression that
isn't likely to be a boolean, we might as well use `or` to specify a
default value for the expression. e.g. `loader.getenv(...) or "no"`
The previous iteration of this assumed that {module}_load was set. In the
old world order of default loader.conf(5), this was probably a safe
assumption given that we had almost every module explicitly not-loaded in
it.
In the new world order, this is no longer the case, so one could delete a
_load line inadvertently while leaving a _name, _type, _flags, _before,
_after, or _error. This would have caused a confusing Lua error and borked
module loading.
If the network interface or the uefi implementation do not support the
ReceiveFilter interface do not return only and just print a message.
U-Boot doesn't support is and likely never will. Also even if this fails
it doesn't mean that network in EFI isn't supported.
hrs@ and kuriyama@ have found that on some HP BIOS, a system will fail to
boot immediately after installation with the claim that it can't work out
which disk they are booting from.
They tracked it down to a buffer overrun, and found that it could be
alleviated by doing a dummy read before-hand.
Submitted by: kuriyama
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14341
