When loading bigger variables form UEFI it is necessary to know their
size beforehand, so that an appropriate amount of memory can be
allocated. The easiest way to do this is to try to read the variable
with buffer size equal 0, expecting EFI_BUFFER_TOO_SMALL error to be
returned. Allow such possible approach in efi_getenv routine.
Extracted from a bigger patch as suggested by imp.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Use recent best practices for Copyright form at the top of
the license:
1. Remove all the All Rights Reserved clauses on our stuff. Where we
piggybacked others, use a separate line to make things clear.
2. Use "Netflix, Inc." everywhere.
3. Use a single line for the copyright for grep friendliness.
4. Use date ranges in all places for our stuff.
Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
Since the loader zfs reader does not need to read the dump zvol, we can
just enable the feature.
illumos issue #9051https://www.illumos.org/issues/9051
MFC after: 2 weeks
An integrity check such as a check-hash or a cross-correlation failed.
The integrity error falls between EINVAL that identifies errors in
parameters to a system call and EIO that identifies errors with the
underlying storage media. EINTEGRITY is typically raised by intermediate
kernel layers such as a filesystem or an in-kernel GEOM subsystem when
they detect inconsistencies. Uses include allowing the mount(8) command
to return a different exit value to automate the running of fsck(8)
during a system boot.
These changes make no use of the new error, they just add it. Later
commits will be made for the use of the new error number and it will
be added to additional manual pages as appropriate.
Reviewed by: gnn, dim, brueffer, imp
Discussed with: kib, cem, emaste, ed, jilles
Differential Revision: https://reviews.freebsd.org/D18765
Just like for Acer C270 chromebook the E820 extmem workaround is required for
FreeBSD to boot on Dell chromebook.
PR: 204916
Submitted by: Keith White <kwhite@site.uottawa.ca>
MFC after: 1 week
biospci_write_config args swapped length and value to write. Some
hardware coped just fine, while other hardware had issues.
PR: 155441
Submitted by: longwitz at incore dot de
We have no option than trust INT13 ah=08 return code during the init phase.
PR: 234460
Reported by: Oleh Hushchenkov
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18723
This update does add diag and debug capabilities to interpret the efi
variables, configuration and protocols (lsefi).
The side effect is that we add/update bunch of related headers.
We do have 16KB buffer space defined in pxe.c, move it to bio.c and implement
bio_alloc()/bio_free() interface to make it possible to use this space for
other BIOS calls (notably, from biosdisk.c).
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D17131
The reason for this change is that currently, a send/recv
takes many hours to time out.
This is suboptimal in the bootloader because it means for example
that NFS will take hours to fail before allowing subsequent access
methods such as gzip to be tried.
Setting MAXWAIT to 300 seconds (5 minutes) still allows slow
connections of 1Mb to be used to download a 30MB kernel file.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18544
With r342151 I did fix the BIOS version of zfs_probe_dev() from accessing
the whole disk, but the fix was not complete - we actually did not check
if the device name was really for whole disk. Since UEFI version
is only calling the zfs_probe_dev() with partitions and not with whole
disk, the UEFI loader was not able to find the zfs pools.
This update does correct the issue by calling archsw.arch_getdev() to
translate the device name back to dev_desc, and we have whole disk when both
partition and slice values are -1.
Reported by: alvisen_gmail.com
Differential Revision: https://reviews.freebsd.org/D18558
First of all, normal setups can not boot such pools as the tools
do not support installing boot programs.
Secondly, for proper pool configuration detection, we need to checks all
four label copies on disk, 2 from front and 2 from the end of the disk,
but zfs label does not contain the size of the disk - so we depend on
firmware to report the correct disk size or use information from the
partition table.
Without partition table, we only can rely on firmware to report and support
disk IO properly.
There is a specific case: 8TB disks are reported by BIOS to have 4294967295
sectors (0x00000000ffffffff), the sectors reported by OS is 15628053168
(0x00000003a3812ab0), so the reported size is less than actual but is hitting
32-bit max. Unfortuantely the real limit must be even lower because probing
this disk in this system will wnd up with hung system.
UEFI boot of this system seems not to be affected.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D18558
With the default Qemu parameters, only 128MB RAM gets given to a VM. This causes
the loader to be unable to allocate the 64MB it needs for the heap. This change
makes the cause of the error more obvious.
Differential Revision: https://reviews.freebsd.org/D17958
superblock has a check-hash error, an error message noting the
superblock check-hash failure is printed and the mount fails. The
administrator then runs fsck to repair the filesystem and when
successful, the filesystem can once again be mounted.
This approach fails if the filesystem in question is a root filesystem
from which you are trying to boot. Here, the loader fails when trying
to access the filesystem to get the kernel to boot. So it is necessary
to allow the loader to ignore the superblock check-hash error and make
a best effort to read the kernel. The filesystem may be suffiently
corrupted that the read attempt fails, but there is no harm in trying
since the loader makes no attempt to write to the filesystem.
Once the kernel is loaded and starts to run, it attempts to mount its
root filesystem. Once again, failure means that it breaks to its prompt
to ask where to get its root filesystem. Unless you have an alternate
root filesystem, you are stuck.
Since the root filesystem is initially mounted read-only, it is
safe to make an attempt to mount the root filesystem with the failed
superblock check-hash. Thus, when asked to mount a root filesystem
with a failed superblock check-hash, the kernel prints a warning
message that the root filesystem superblock check-hash needs repair,
but notes that it is ignoring the error and proceeding. It does
mark the filesystem as needing an fsck which prevents it from being
enabled for writing until fsck has been run on it. The net effect
is that the reboot fails to single user, but at least at that point
the administrator has the tools at hand to fix the problem.
Reported by: Rick Macklem (rmacklem@)
Discussed with: Warner Losh (imp@)
Sponsored by: Netflix
When loader(8) is built with zfs support enabled, it assumes that any extarg
data present is a zfs_boot_args struct, but if the first-stage loader was
gptboot(8) the extarg data is actually a geli_boot_args struct. Luckily,
zfsboot(8) and gptzfsboot(8) have always passed KARGS_FLAGS_ZFS along with
KARGS_FLAGS_EXTARG, so we can use KARGS_FLAGS_ZFS to decide whether the
extarg data is a zfs_boot_args struct.
To avoid similar problems in the future, gptboot(8) now passes a new
KARGS_FLAGS_GELI to indicate that extarg data is geli_boot_args. In
loader(8), if the neither KARGS_FLAGS_ZFS nor KARGS_FLAGS_GELI is set but
extarg data is present (which will be the case for gptboot compiled before
this change), we now check for the known size of the geli_boot_args struct
passed by the older versions of gptboot as a way of confirming what type of
extarg data is present.
In a semi-related tidying up, since loader's main() has already decided
what type of extarg data is present and set the global 'zargs' var
accordingly, don't repeat the check in extract_currdev, just check whether
zargs is NULL or not.
X-MFC after: a few days, along with prior related changes.
As part of the migration away from obsolete binutils we want to retire
GNU as. Most assembly files used on amd64 have a .S extension and
(via rules in share/mk/bsd.suffixes.mk) are assembled with Clang's
Integrated Assembler (IAS). Rename files in stand/i386 to .S to use
the integrated assembler.
Clang's IAS supports the defsym option (via -Wa,) but only with one
dash, not two. As both -defsym and --defsym are accepted by GNU as,
use the former.
PR: 233611
Reviewed by: tsoome
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18369
src.opts.mk includes bsd.own.mk. This in turn defines CTFCONVERT_CMD
depending on the MK_CTF value. We then set MK_CTF to no, which has no
real effect. The solution is to set all the MK_foo values before
including src.opts.mk.
This should stop the cdboot binary from exploding in size for releases
built WITH_CTF=yes in src.conf.
Sponsored by: Netflix
of args data between gptboot/zfsboot and loader(8).
Despite what seems like a lot of changes here, there are no actual
changes in behavior, or in the data layout in the structures involved.
This is just eliminating identical code pasted into multiple locations.
In detail, the changes are...
- Move struct zfs_boot_args definition from libsa/zfs/libzfs.h to
i386/common/bootargs.h because it is specific to x86 booting and the
handoff between zfsboot and loader, and has no relation to the zfs
library code in general.
- The geli_boot_args and zfs_boot_args structs both contain an identical
set of member variables containing geli information. Extract this out
to a new geli_boot_data struct, and embed it in the arg-passing structs.
- Provide new routines geli_import_boot_data() and geli_export_boot_data()
that can be shared between gptboot, zfsboot, and loader instead of
pasting identical code into several different .c files.
- Remove some checks for a NULL pointer that can never be true because the
pointer being tested was set using pointer math (kargs + 1) and that can
never result in NULL in this code.
This fix is ported from illumos (issue #9970), the analysis and initial
implementation was done by John Levon.
See also: https://www.illumos.org/issues/9970
Currently, efi_cons_getchar() will wait for a key. While this seems to make
sense, the implementation of getchar() in common/console.c will loop across
getchar() for all consoles without doing ischar() first.
This means that if we've configured multiple consoles, we can't input into
the serial, as getchar() will be sat waiting for input only from efi_console.c
This patch does implement a bit more generic key buffer to support
translation of input keys, and we use generic efi_readkey() to reduce
duplication from calls from getchar() and poll().
Create unified block IO implementation in BIOS version, like it is done in UEFI
side. Implement fd, disk and cd device lists, this will split floppy devices
from disks and will allow us to have consistent, predictable device naming
(modulo BIOS issues).
Differential Revision: https://reviews.freebsd.org/D17888
-msoft-float seems to be insufficient for disabling the SPE on powerpcspe.
Force it off with -mno-spe as well. This prevents a crash in ubldr on
powerpcspe.
in gptboot.
When arch-independent geli support was added, a new static 'gdsk' struct
was added, but there was still a static 'dsk' struct, and when you typed
in an alternate disk/partition, the string was parsed into that struct,
which was then never used for anything. Now the string gets parsed into
gdsk.dsk, the struct that's actually used.
X-MFC after: 3 days
As part of the migration away from obsolete binutils we want to retire
GNU as. Most assembly files used on amd64 have a .S extension and are
assembled with Clang's Integrated Assembler (IAS); rename pxetram.s to
.S to use IAS as well.
The generated .text is identical (the entire .o file is not, as Clang
adds debug info.)
PR: 205250, 233094
Sponsored by: The FreeBSD Foundation
As part of the migration away from obsolete binutils we want to retire
GNU as. Most assembly files used on amd64 have a .S extension and are
assembled with Clang's integrated assembler; rename two files in
stand/i386/btx/lib to .S to use IAS as well.
The generated .text is identical (the entire .o files are not, as Clang
adds debug info).
PR: 205250, 233094
Discussed with: imp
Sponsored by: The FreeBSD Foundation
the malloc()/free() as well as having potential of softening the handling
in case error is detected down to a mere warning as compared to hard panic
in free().
Submitted by: tsoome
Differential Revision: https://reviews.freebsd.org/D18299
A user may enable build-id for all builds by adding
LDFLAGS=-Wl,--build-id=sha1 to /etc/make.conf. In this case the build-id
note ends added up to mbr and pmbr's .text, which makes it too large (it
ends up being 532 bytes). To avoid this explicitly turn off build-id for
these components.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15470
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler (IAS) did not handle .codeNN directives. Clang
gained support quite some time ago, and we can now build stand/ with
IAS.
Note that in some cases there are small differences in the generated
output, so CLANG_NO_IAS should be removed only after testing (or after
finding no differences in the output).
PR: 205250, 233094
Sponsored by: The FreeBSD Foundation
The ptable_*read() functions return NULL on read errors (and partition table
closed as an side effect). The ptable_open must check the return value and
act properly.
PR: 232483
Reported by: lev
Reviewed by: lev,cem
Differential Revision: https://reviews.freebsd.org/D17890
The disk access is validated by using partition table definitions, therefore
we have no need for if statements, just set the disk size.
Of course the partition table itself may be incorrect/inconsistent, but if
so, we are in trouble anyhow.
Differential Revision: https://reviews.freebsd.org/D17822
The bd_print/bd_open/bd_strategy need to make sure the device does have
media, before getting into performing IO operations. Some systems can
hung if the device without a media is accessed.
Reported by: yuripv
