From user report, the errors are seen:
error 1
error 1
gptzfsboot: error 1 lba 4294967288
gptzfsboot: error 1 lba 1
gptzfsboot: no ZFS pools located, can't boot
The first two errors above are from issuing INT13 EAX=0x4800, meaning we
need to check if EDD is available and use EAX=0x800 if not.
For an workaround I'm using the similar idea as in biosdisk.c - first probe
ah=8h, then check if we have EDD.
Note we would like to see the correct disk size info, but we *may*
get away with anything >64MB, so we could at least test 2 zfs pool labels
on whole disk setup and not to freak out the INT13 interface.
If we get away with initial disk probing, then we have partition sizes from
the partition table and we should be able to complete the disk probing.
Note: this update does not provide full fix to all errors, but we get
the drvsize() errors removed.
Reported by: Michael W. Lucas
Reviewed by: julian
Differential Revision: https://reviews.freebsd.org/D10591
The current zfs reader is only checking first label from each device, however,
we do have 4 labels on device and we should check all 4 to be protected
against disk failures and incomplete label updates.
The difficulty is about the fact that 2 label copies are in front of the
pool data, and 2 are at the end, which means, we have to know the size of
the pool data area.
Since we have now the mechanism from common/disk.c to use the partition
information, it does help us in this task; however, there are still some
corner cases.
Namely, if the pool is created without partition, directly on the disk,
and firmware will give us the wrong size for the disk, we only can check
the first two label copies.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10203
This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
Make sure sensitive memory is properly cleared when finished with it
Reviewed by: Eric McCorkle <eric@metricspace.net>
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9798
This is a better pattern to follow when creating the bootloaders and doing
the relevant space checks to make sure that the sizes aren't exceeded (and
thus, copy-pasting is a bit less error prone).
MFC after: 3 days
Sponsored by: Dell EMC Isilon
being a bootstrap tool. However, for reproducible build output,
FreeBSD added dd status=none because it was otherwise difficult to
suppress the status information, but retain any errors that might
happen. There's no real reason that dd has to be a build tool, other
than we use status=none unconditional. Remove dd from a bootstrap tool
entirely by only using status=none when available. This may also help
efforts to build the system on non-FreeBSD hosts as well.
Differential Revision: https://reviews.freebsd.org/D8605
(gpt)zfsboot will read one-time boot directives from a special ZFS pool
area. The area was previously described as "Boot Block Header", but
currently it is know as Pad2, marked as reserved and is zeroed out on
pool creation. The new code interprets data in this area, if any, using
the same format as boot.config. The area is immediately wiped out.
Failure to parse the directives results in a reboot right after the
cleanup. Otherwise the boot sequence proceeds as usual.
zfsbootcfg writes zfsboot arguments specified on its command line to the
Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and
vfs.zfs.boot.primary_vdev kenv variables that are set by loader during
boot. Please see the manual page for more.
Thanks to all who reviewed, contributed and made suggestions! There are
many potential improvements to the feature, please see the review for
details.
Reviewed by: wblock (docs)
Discussed with: jhb, tsoome
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D7612
When tsoome@ added skein support to the ZFS boot code and zfsloader, it
resulted in an explosion in code size, running close to a number of
limits.
The default for the C version of skein is to unroll all loops for
skein-256 and 512
Disabling the loop unrolling saves 20-28kb from each binary
boot1.efi
gptzfsboot
loader.efi
userboot.so
zfsloader
Reviewed by: emaste, tsoome
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D7826
not page aligned. To do this, use the ld script gnu ld installs on my
system.
This is imperfect: LDFLAGS_BIN and LD_FLAGS_BIN describe different
things. The loader script could be better named and take into account
other architectures. And having two different mechanisms to do
basically the same thing needs study. However, it's blocking forward
progress on lld, so I'll work in parallel to sort these out.
Differential Revision: https://reviews.freebsd.org/D7409
Reviewed by: emaste
Updated sha512 from illumos.
Using skein from freebsd crypto tree.
Since loader itself is using 64MB memory for heap, updated zfsboot to
use same, and this also allows to support zfs large blocks.
Note, adding additional features does increate zfsboot code, therefore
this update does increase zfsboot code to 128k, also I have ported gptldr.S
update to zfsldr.S to support 64k+ code.
With this update, boot1.efi has almost reached the current limit of the size
set for it, so one of the future patches for boot1.efi will need to
increase the limit.
Currently known missing zfs features in boot loader are edonr and gzip support.
Reviewed by: delphij, imp
Approved by: imp (mentor)
Obtained from: sha256.c update and skein_zfs.c stub from illumos.
Differential Revision: https://reviews.freebsd.org/D7418
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone.
Detected with devel/coccinelle following a hint from DragonFlyBSD.
MFC after: 1 month
Replace all rounding with the round{up,down}2 macros
a missing set of braces caused the previous code to be incorrect
replace alloca() with malloc() because alloca() can return an allocation
that is actually invalid, causing boot to fail
Reviewed by: emaste, ed
Thanks To: peter
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D6213
macro. Adjust the buffer clipping code to work as expected.
This prevented a number of machines in the FreeBSD.org cluster from
booting due to "ZFS: i/o error - all block copies unavailable"
after an unclean shutdown.
Add support for 4k sector GELI encrypted partitions to the bootloader
This is the default created by the installer
Because the IV is different for each sector, and the XTS tweak carries forward you can not decrypt a partial sector if the starting offset is not 0
Make boot2 and the loader read in 4k aligned chunks
Reviewed by: ed, oshogbo
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D5820
hate adding yet another define, but it is the lessor of the evil
choices available. Kill another evil by removing PATH_BOOT3 and
replacing it with PATH_LOADER or PATH_LOADER_ZFS as appropriate.
PR: 206659
magic number to use V86_CY() instead. These should have been fixed as
part of the cleanup in r226746 but were missed.
The md5 sums of the object files were unchanged, so there should be no
functional change.
PR: 205424
Submitted by: Alexander Kuleshov <kuleshovmail@gmail.com>
MFC after: 1 week
This is not properly respecting WITHOUT or ARCH dependencies in target/.
Doing so requires a massive effort to rework targets/ to do so. A
better approach will be to either include the SUBDIR Makefiles directly
and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose
the benefit of having a userland/lib, userland/libexec, etc, though and
results in a massive package. The current implementation of targets/ is
very unmaintainable.
Currently rescue/rescue and sys/modules are still not connected.
Sponsored by: EMC / Isilon Storage Division
stage, just like for the regular world stage.
Reviewed by: rodrigc, imp, bapt, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D2187
A 32-bit libstand is needed on 64-bit platforms for use by various
bootloaders. Previously only the 32-bit version was built, installed as
/usr/lib/libstand.a.
A new 64-bit libstand consumer will arrive in the near future, so move
the bootloader-specific 32-bit version to sys/boot/libstand32/.
Explicitly link against this version in the 32-bit loaders.
Sponsored by: The FreeBSD Foundation
directly to the linker (LD_FLAGS) from flags passed indirectly, via the
compiler driver (LDFLAGS).
This is because several Makefiles under sys/boot/i386 and sys/boot/pc98
use ${LD} directly to link, and the normal LDFLAGS value should not be
used in these cases.
MFC after: 3 days
The first discovered pool, whether it covers the whole boot disk or not,
is going to be first in zfs_pools list. So there is no need at all
for spapp parameter.
This commit also fixes a bug where NULL would be assigned to NULL
pointer when probe_drive was called with the spapp parameter of NULL.
MFC after: 21 days
In zfs loader zfs device name format now is "zfs:pool/fs",
fully qualified file path is "zfs:pool/fs:/path/to/file"
loader allows accessing files from various pools and filesystems as well
as changing currdev to a different pool/filesystem.
zfsboot accepts kernel/loader name in a format pool:fs:path/to/file or,
as before, pool:path/to/file; in the latter case a default filesystem
is used (pool root or bootfs). zfsboot passes guids of the selected
pool and dataset to zfsloader to be used as its defaults.
zfs support should be architecture independent and is provided
in a separate library, but architectures wishing to use this zfs support
still have to provide some glue code and their devdesc should be
compatible with zfs_devdesc.
arch_zfs_probe method is used to discover all disk devices that may
be part of ZFS pool(s).
libi386 unconditionally includes zfs support, but some zfs-specific
functions are stubbed out as weak symbols. The strong definitions
are provided in libzfsboot.
This change mean that the size of i386_devspec becomes larger
to match zfs_devspec.
Backward-compatibility shims are provided for recently added sparc64
zfs boot support. Currently that architecture still works the old
way and does not support the new features.
TODO:
- clear up pool root filesystem vs pool bootfs filesystem distinction
- update sparc64 support
- set vfs.root.mountfrom based on currdev (for zfs)
Mid-future TODO:
- loader sub-menu for selecting alternative boot environment
Distant future TODO:
- support accessing snapshots, using a snapshot as readonly root
Reviewed by: marius (sparc64),
Gavin Mu <gavin.mu@gmail.com> (sparc64)
Tested by: Florian Wagner <florian@wagner-flo.net> (x86),
marius (sparc64)
No objections: fs@, hackers@
MFC after: 1 month
Place the arguments at a fixed offset of 0x800 withing the argument area
(of size 0x1000). Allow variable size extended arguments first of which
should be a size of the extended arguments (including the size
parameter).
Consolidate all related definitions in a new i386/common/bootargs.h header.
Many thanks to jhb and bde for their guidance and reviews.
Reviewed by: jhb, bde
Approved by: jhb
MFC after: 1 month
Before r228267 the option was honored but the original content of
boot.config was not preserved. I tried to fix that but missed the idea.
Now the proper way of doing things is taken from i386/boo2.
Also, a comment is added to explain this a little bit unobvious
behavior.
Inspired by: jhb
MFC after: 5 days
get rid of testing explicitly for clang (using ${CC:T:Mclang}) in
individual Makefiles.
Instead, use the following extra macros, for use with clang:
- NO_WERROR.clang (disables -Werror)
- NO_WCAST_ALIGN.clang (disables -Wcast-align)
- NO_WFORMAT.clang (disables -Wformat and friends)
- CLANG_NO_IAS (disables integrated assembler)
- CLANG_OPT_SMALL (adds flags for extra small size optimizations)
As a side effect, this enables setting CC/CXX/CPP in src.conf instead of
make.conf! For clang, use the following:
CC=clang
CXX=clang++
CPP=clang-cpp
MFC after: 2 weeks
gpt and zfs boot blocks are not nearly as size-constrained as boot2
from which they inherited their current optimization and anti-optimization
options. As such the current options do not provide any benefit, but
make debugging of the code much harder.
Also, it has been demonstrated that combination of -mrtd and
-fno-unit-at-a-time may result in mis-compilation of the boot code
with the current base gcc.
Additionally, intermediate assembly file filtering is removed for
zfsboot.
The new boot blocks are all compile- and boot- tested using qemu.
gptzfsboot is tested with real hardware.
Reported by: Peter Jeremy <peterjeremy@acm.org> [miscompilation]
Discussed with: bde, jhb
Tested by: Sebastian Chmielewski <chmielsster@gmail.com> [gptzfsboot]
Approved by: re (kib)
MFC after: 3 weeks
CFLAGS having '-g' in it, clang outputs several assembly directives that
are too new for our version of binutils.
Therefore, assemble the resulting .s files with clang instead. A more
general solution can be implemented when a GNU as-compatible driver for
clang's integrated assembler appears.
Reported by: dougb
floppies, so it will not be used as the start of an emulated floppy
image on a bootable CD which is what the fake BPB was used for.
- Only check that EDD packet mode is available once at the start of
zfsldr rather than for each disk sector now that we read data in one
sector at a time. As a result, collapse the remaining bits of read
up into nread and rename nread to read.
- Restore a return at the end of putstr that I removed in the previous
revision.
Tested by: Henri Hennebert (earlier version)
MFC after: 1 week
unhappy (probably they don't handle crossing the 64k boundary, etc.).
Fix this by changing zfsldr to use a loop reading from the disk one
sector at a time. To avoid trashing the saved copy of the MBR which is
used for disk I/O, read zfsboot2 at address 0x9000. This has the
advantage that BTX no longer needs to be relocated as it is read into
the correct location. However, the loop to relocate zfsboot2.bin can
now cross a 64k boundary, so change it to use relative segments instead.
(This will need further work if zfsboot2.bin ever exceeds 64k.)
While here, stop storing a relocated copy of zfsldr at 0x700. This was
only used by the xread hack which has recently been removed (and even
that use was dubious). Also, include the BIOS error code as hex when
reporting read errors to aid in debugging.
Much thanks to Henri Hennebert for patiently testing various iterations
of the patch as well as fixing the zfsboot2.bin relocation to use
relative segments.
MFC after: 1 week
boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks
do not have the same space constraints, so remove this hack for ZFS.
While here, remove commented out code to support C/H/S addressing from
zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing.
MFC after: 2 weeks
