pkg_add has been gone since 2013(?). Refer to pkg(8) instead.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D44946
- Mention the options that are amd64-only.
- Provide a minimal example for booting an arm64 guest.
Reviewed by: corvink
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44738
It is a no-op on amd64 now and is not implemented on arm64, so let's
remove mention of it altogether so as to reduce confusion for arm64
users.
Reviewed by: corvink, jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44737
1. Currently, distfetch checks environment variables existence
when it will use them or in a case (in chdir()) it doesn't check
at all. As they are necessary to set before doing anything with
it, check them, if they set or not, before proceeding any further.
This also avoids extra cleaning when that environment variable
isn't set.
2. Handle memory allocation error in malloc(PATH_MAX) and replace
(sizeof const char *) with (sizeof char *). Both are similar and
const doesn't have a size.
3. Indent the error message a bit in chdir().
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1071
Reported by: Jose Luis Duran <jlduran@gmail.com>
Fixes: b37333899b
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44871
Previously, mailwrapper(8) would default to invoking _PATH_DEFAULTMTA
(i.e., dma) if mailer.conf couldn't be opened for any reason, including
transient errors like ENFILE. This behaviour is undesirable, because if
the administrator has configured a different MTA in mailer.conf, they
almost certainly don't want mailwrapper to unpredictably fall back to
the compiled-in default; and in any case, the default MTA is probably
not running, meaning the mail may be queued and then never delivered,
which is worse than not accepting it to begin with.
Change this behaviour depending on why mailer.conf can't be opened:
- If it doesn't exist, keep the existing behaviour of falling back to
the default MTA, on the assumption that this is a reasonable default
if mailer.conf hasn't been configured at all.
- If it cannot be opened for any other reason, do not invoke an MTA and
instead return an error to the caller.
PR: 25218
Reviewed by: imp, emaste, markj
Pull Request: https://github.com/freebsd/freebsd-src/pull/969
Most importantly:
* Make local variables local.
* Use `$()` instead of backticks.
* Avoid unsafe use of `-a` and `-o` operators in `test` expressions.
* Remove a hack intended to ease the transition from Perl 22 years ago.
MFC after: 1 week
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D44863
"bsdbox --list" will print all tools in the binary, one per line. The
main use case for this is to make it easier to create links:
for t in $(bsdbox --list); do
ln -s bsdbox $t
done
The name --list was taken from busybox.
This just adds a new "program" with the name "--list". I don't think we
need to do real argument parsing here, and this is also how busybox does
it.
An additional minor change is that just "bsdbox" will no longer print
the binary name itself ("bsdbox" in this case). Before it would do:
% bsdbox
usage: boxlike <prog> <args> ..., where <prog> is one of:
cp ls mv bsdbox
And now just:
% bsdbox
usage: boxlike <prog> <args> ..., where <prog> is one of:
cp ls mv
And just "bsdbox" will also exit with code 0 (and print to stdout)
rather than exit with 0 and print to stderr
Example output:
% ./bsdbox
usage: bsdbox program [args ...]
bsdbox --list
program [args ...]
bsdbox combines several programs in one executable. Create a link to this
executable with the program name to run that program, or give the program
name as the first argument.
Currently defined programs:
true false tail head uname
% ./bsdbox --list
true
false
tail
head
uname
% ./bsdbox uname -a
FreeBSD freebsd 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64
% ln -s bsdbox uname
% ./uname -a
FreeBSD freebsd 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64
Pull Request: https://github.com/freebsd/freebsd-src/pull/894
Signed-off-by: Martin Tournoij <martin@arp242.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/894
If not, then in general the entire filesystem containing the exported
directory is accessiable. This may be surprising, so try to make it
more clear.
Reviewed by: rmacklem, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44614
Mergemaster has been deprecated for quite some time, but was not
removed prior to FreeBSD 14.0. Update the deprecation notice in the man
page to reflect this.
PR: 274967
Reported by: naddy
Sponsored by: The FreeBSD Foundation
During the install process tzsetup asks a question like
Does the abbreviation `EDT' look reasonable?
The installer asks lots of questions, some that relate to the previous
screen or topic and some that do not. A new user installed FreeBSD for
the first time and was confused by this question, not realizing that it
was asking whether the abbreviation is correct for the selected
timezone.
Reviewed by: bapt, brooks, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44500
People get confused when some software (VirtualBox, etc) does not work as
expected (or at all) after a major upgrade.
We have a nice way to deal with this when using sources, namely including
PORTS_MODULES in /etc/make.conf, but we lack something similar for binary
updates.
This patch retrieves a list of kernel modules installed from packages and
advises the user to recompile from ports to avoid problems.
Approved by: zlei@
Differential Revision: https://reviews.freebsd.org/D39695
If we're doing restarts, then we must supervise -- the 'R' case simply
got missed.
PR: 278342
Fixes: f907027b49 ("daemon: set supervise_enabled during [..]")
The __builtin_unreachable macro provided by Clang and GCC is a hint to
the compiler used for optimization. The programs work fine even if the
compiler doesn't support it. The sys/cdefs.h has had __unreachable for
9 years (commit 732b31de5d). It expands
to the builtin if it is available. In the rare case that it is
unsupported it expands to a null statement so compilation does not
fail.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed by: imp, freebsd@igalic.co
Pull Request: https://github.com/freebsd/freebsd-src/pull/1117
The __builtin_unreachable macro provided by Clang and GCC is a hint to
the compiler used for optimization. The programs work fine even if the
compiler doesn't support it. The sys/cdefs.h has had __unreachable for
9 years (commit 732b31de5d). It expands
to the builtin if it is available. In the rare case that it is
unsupported it expands to a null statement so compilation does not
fail.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed by: imp, freebsd@igalic.co
Pull Request: https://github.com/freebsd/freebsd-src/pull/1117
1. Both trackbuf and vrfybuf are initialized to
zero (NULL). While it's okay to initialize pointers
to zero, to keep consistency, as they're explicitly
pointers, it's better to just use NULL ((void *)0)
instead of 0 (both are equivalent to the compilers).
2. Call free() for both trackbuf and vrfybuf after
their job has been done.
3. Remove the register keyword. Compilers generally
ignore this keyword (except for very very old compilers
and CPUs).
4. Remove the ctype.h header. It's not being used
anywhere in the file.
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1059
On systems utilizing ZFS, default to creating a ZFS dataset for a new
user's home directory if the parent directory resides on a ZFS dataset.
Add a flag that disables this behavior if the administrator explicitly
does not want it.
If run during installation from within a chroot, set mountpoint to legacy
after dataset creation and mount directly into the chroot. Then umount
and reset the mountpoint to inherit from parent.
Also support ZFS default encryption on user's home directory.
Feedback by: delphij
Reviewed by: imp, kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/881
Unlike amd64's, this RTC is implemented entirely in userspace. This is
the same RTC as is provided by QEMU's virt machine.
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This clock will also be used by the PL031 RTC (rather than defining
redundant per-device clocks).
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This is supposed to combine with the memory range to make one contiguous
block, as is laid out in the FDT, so make this match what the OS is told
and thus actually configures.
Also drop the confusing leading zero from all three of these constants
that is making these 9 rather than 8 hex digits long (as one would
expect for a 32-bit address).
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This allows us to remove various #ifdef hacks and enable building more
PCI devices.
Note that a hole is left in the interrupt mapping for the RTC rather
than having the two core devices straddle the PCIe interrupts. QEMU's
virt machine also takes this approach.
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
After a couple of attempts I think this is the cleanest approach despite
the expense of some code duplication. Quite a few of the single-letter
bhyve options are x86-specific.
I think that going forward we should strongly discourage the addition of
new options and instead configure guests using the more general
configuration file syntax.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41753
A FreeBSD guest won't make use of this support and pci_lintr_* is not
implemented on arm64. Simply make pci_lintr_*() calls amd64-specific
for now.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41741
- The extended config space and BAR ranges are listed in the FDT.
- Avoid referencing I/O ports in ACPI tables. Currently the arm64 port
does not support ACPI in any case.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41739
Some required kernel functionality is not yet implemented.
For now this means that one cannot specify host PCI register values, but
that functionality is only used by amd64-specific device models for now.
Note that this limitation is rather artificial; it arises only because
pci_host_read_config() lives in pci_passthru.c.
Reviewed by: corvink, andrew, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41738
This reduces the coupling between libvmmapi (which creates the highmem
segment) and bhyve, in preparation for the arm64 port.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40992
fdt.c provides some basic routines which let platform initialization
code build the FDT that gets passed into the guest. For now this is not
very generic; we declare info about CPUs, memory, a single UART
(specified by -o console), a PCIe controller (used for virtio devices),
an interrupt controller and the platform timer.
Co-authored-by: andrew
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40996
The arm64 port currently does not support ACPI, it instead builds up an
FDT which is exported to the guest. This mechanism will not be used on
amd64 but isn't really arm64-specific either, so provide an opt-in
mechanism to link libfdt.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40995
This will be use for arm64 guests, instead of the existing ns16550 UART
model.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40997
As mentioned in zpoolprops(7), on some SSDs, it may not be desirable to
use ZFS autotrim because a large number of trim requests can degrade
disk performance; instead, the pool should be manually trimmed at
regular intervals.
Add a new daily periodic script for this purpose, 801.trim-zfs. If
enabled (daily_trim_zfs_enable=YES; the default is NO), it will run a
'zpool trim' operation on all online pools, or on the pools listed in
'daily_trim_zfs_pools'.
The trim is not started if the pool is degraded (which matches the
behaviour of the existing 800.scrub-zfs script) or if a trim is already
running on that pool. Having autotrim enabled does not inhibit the
periodic trim; it's sometimes desirable to run periodic trims even with
autotrim enabled, because autotrim can elide trims for very small
regions.
PR: 275965
MFC after: 1 week
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/956
