introduce zfsboottest.sh script that will verify if it will be possible to boot
from the given pool.
# zfsboottest.sh system
Where "system" is pool name of the pool we want to boot from.
What is being verified by the script:
- Does the pool exist?
- Does it have bootfs property configured?
- Is mountpoint property of the boot dataset set to 'legacy'?
Dataset configured in bootfs property has to be mounted to perform more
checks:
- Does the /boot directory in boot dataset exist?
- Is this dataset configured as root file system in /etc/fstab or set
in vfs.root.mountfrom variable in /boot/loader.conf?
By using zfsboottest tool the script will read all the files in /boot
directory using ZFS boot code and calculate their checksums.
Then, it will walk /boot directory using find(1) though regular file sytem
and also read all the files in /boot directory and calculate their checksums.
If any of the files cannot be looked up, read or checksum is invalid it will
be reported and booting off of this pool is probably not possible.
Some additional checks may be interesting as well. For example if the disks
contain proper pmbr and gptzfsboot code or if all expected files in /boot/
are present.
When upgrading FreeBSD, one should snapshot datasets that contain operating
system, upgrade (install new world and kernel) and use zfsboottest.sh to verify
if it will be possible to boot from new configuration. If all is good one
should upgrade boot blocks, by eg.:
# gpart -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
If something is wrong, one should rollback datasets and report the problems.
MFC after: 3 days
zfsboottest gpt/system0 gpt/system1 - /boot/kernel/kernel /boot/zfsloader
- Instead of printing file's content calculate MD5 hash of the file,
so it can be easly compared to the hash calculated via file system.
- Some other minor improvements.
MFC after: 3 days
According to POSIX, these two header files should be able to be included
by themselves, not depending on other headers. The <net/if.h> header
uses struct sockaddr when __BSD_VISIBLE=1, while <netinet/tcp.h> uses
integer datatypes (u_int32_t, u_short, etc).
MFC after: 2 months
ioctlname() to return a pointer to the name rather than print it. This did
not show up in testing because truss had its own prototype for ioctlname(),
so it would build fine and run fine as long as the program being traced did
not issue an ioctl.
Teach mkioctls to generate different versions of ioctlname() based on its
first command-line argument.
Pointed out by: Garrett Cooper <yanegomi@gmail.com>
implement a deprecated FPU control interface in addition to the
standard one. To make this clearer, further deprecate ieeefp.h
by not declaring the function prototypes except on architectures
that implement them already.
Currently i386 and amd64 implement the ieeefp.h interface for
compatibility, and for fp[gs]etprec(), which doesn't exist on
most other hardware. Powerpc, sparc64, and ia64 partially implement
it and probably shouldn't, and other architectures don't implement it
at all.
working MI one. The MI one only needs to be overridden on machines
with non-IEEE754 arithmetic. (The last supported one was the VAX.)
It can also be overridden if someone comes up with a faster one that
actually passes the regression tests -- but this is harder than it sounds.
- Handle cases where exp(x) would overflow, but ccosh(x) ~= exp(x) / 2
shouldn't.
- Use the ccosh(x) ~= exp(x) / 2 approximation to simplify the calculation
when x is large.
Similarly for csinh(). Also fixed the return value of csinh(-Inf +- 0i).
exp(x) scaled down by some factor, and the challenge is doing this
accurately when exp(x) would overflow. This change replaces all of
the tricks we've been using with common __ldexp_exp() and
__ldexp_cexp() routines that handle all the scaling.
bde plans to improve on this further by moving the guts of exp() into
k_exp.c and handling the scaling in a more direct manner. But the
current approach is simple and adequate for now.
- Decompress assembled gang block data if compressed.
- Verify checksum of a gang header.
- Verify checksum of assembled gang block data.
- Verify checksum of uber block.
Submitted by: avg
MFC after: 3 days
physical block size declared in bp may not always be what we want.
For example in case of gang block header physical block size declared
in bp is much larger than SPA_GANGBLOCKSIZE (512 bytes) and checksum
calculation failed. This bug could lead to accessing unallocated
memory and resets/failures during boot.
MFC after: 3 days
handled by lower layers like vdev_raidz, which uses bp for checksum
verification. This bug could lead to NULL pointer reference and resets
during boot.
MFC after: 3 days
display() to calculate column widths, but was not initialized in
main(). This resulted in a division by zero.
Noticed by: Michael Butler <imb@protected-networks.net>
to document where we are expecting to be called with a lock held to
more easily catch unnoticed code paths.
This does not neccessarily improve locking in pfsync, it just tries
to avoid the panics reported.
PR: kern/159390, kern/158873
Submitted by: pluknet (at least something that partly resembles
my patch ignoring other cleanup, which I only saw
too late on the 2nd PR)
MFC After: 3 days
and virtualization it is not helpful but complicates things.
Current state of art is to not virtualize these kinds of locks -
inp_group/hash/info/.. are all not virtualized either.
MFC after: 3 days
pfsync also depends on pf to be initialized already so pf goes at
FIRST and the interfaces go at ANY.
Then the (VNET_)SYSINIT startups for pf stays at SI_SUB_PROTO_BEGIN
and for pfsync we move to the later SI_SUB_PROTO_IF.
This is not ideal either but at least an order that should work for
the moment and can be re-fined with the VIMAGE merge, once this will
actually work with more than one network stack.
MFC after: 3 days
and never remove state.
This fixes the problem some people are seeing that state is removed when pf
is loaded as a module but not in situations when compiled into the kernel.
Reported by: many on freebsd-pf
Tested by: flo
MFC after: 3 days
With the addition of various GEOM layers some device names now exceed
this length, for example /dev/mirror/encrypted.elig.journal. This
change expands the field to 53 bytes which brings the /etc/dumpdates
lines to 80 characters. Exceeding 80 characters makes the /etc/dumpdates
file much less human readable. A test is added to dump so that it
verifies that the device name will fit in the 53 character field
failing the dump if it is too long.
This change has been checked to verify that its /etc/dumpdates file
is compatible with older versions of dump.
Reported by: Martin Sugioarto <martin@sugioarto.com>
PR: kern/160678
MFC after: 3 weeks
