awk changed somewhere between 14 and 15 and it stopped accepting
a hexadecimal number as its input - it will always return 0.
This results in a very badly written apple boot block.
So just remove it; do the math in shell.
PR: kern/292341
Differential Revision: https://reviews.freebsd.org/D54639
Reviewed by: imp
MFC after: 1 week
The default shell for root has been changed to sh(1) followup changing
in release images sh(1) the shell for the "freebsd" user.
MFC After: 1 week
Reviewed by: manu, emaste (re)
Approved by: manu, emaste (re)
Differential Revision: https://reviews.freebsd.org/D54602
This is required for MSI support on GCE ARM64 instances which is
prerequisite to gve(4) not panicking at boot, and nvme(4) also has
a real sad time without interrupts. Tested on a variety of c4a VMs.
This is meant to be a temporary hack; long term fix would be to
check for the hypervisor and quirk gve(4) device with
PCI_QUIRK_ENABLE_MSI_VM.
PR: kern/292081
MFC after: 1 week
Removes hw.vtnet.mq_disable=1.
This workaround was originally introduced nearly a decade ago to
address stability issues on KVM that have long since been resolved
in both the FreeBSD driver and the GCE hypervisor. Removing this
allows network interrupts to scale across multiple vCPUs.
Tested on n2-highcpu-16 VM with 15.0-RELEASE and confirmed multiple
queue pairs active and interrupts handling across cores.
PR: kern/292081
MFC after: 1 day
The sed command was missing the ${DESTDIR} prefix, meaning it was
attempting to modify the build host's /etc/rc.d/growfs instead of
the target image's script. Tested in an arm64 builder that builds
as non-root.
PR: kern/292081
MFC after: 1 day
Zstd is a discrete, self-contained system component. To match how we
package zlib, bzip2 and xz, move it to its own package, with a separate
lib package.
Add the new package to the minimal set, since this is a core component
that users expect to be installed.
This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.
MFC after: never
Reviewed by: bapt
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53603
In general we want to strip subdir components, rather than appending
`..`s.
Reviewed by: lwhsu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54373
Contrary to the claim made in a previous commit, removing KDE and
adding all of vim and emacs results in an image which does not fit
into 4.7 GB; to be specific, it lands at 4.722 GB rather than the
claimed 4.689 GB. (This descrepancy resulted from doing test DVD
image builds using an out-of-date tree, and became visible when the
15.0-RC3 images were built.)
Limit the emacs packages shipped on the DVD to the "nox" flavor;
this brings the disk image down to 4.407 GB, aka under the 4.7 GB
limit for standard DVDs.
Fixes: 6cc6beb4c8 ("release: Remove KDE from dvd1.iso")
MFC after: 1 day (for 15.0-RC4)
Prior to this commit, we were shipping 2155 MB of packages (from the
ports tree, not counting pkgbase) on dvd1.iso. Due to the amount of
space required by shipping pkgbase packages *and* distribution sets
on the DVD images, we only have 1696 MB available if we want to fit
into the 4.7 GB limit for DVDs. Many users have indicated that this
is indeed important.
It is practically impossible to hit this target without removing KDE;
while KDE and its dependencies narrowly fit (1550 MB), we exceed the
limit as soon as we include either of freebsd-doc-all or gnome. While
we would pick KDE over GNOME (surveys regularly indicate that KDE is
the more widely used of the two), we believe that documentation is the
most important thing to include.
Since removing KDE leaves a bit of extra space, add editors/emacs and
editors/vim. This takes the 15.0 amd64 dvd1.iso up to 4.689 GB. [1]
Requested by: adamw [1]
MFC after: immediately (for 15.0-RC3)
Differential Revision: https://reviews.freebsd.org/D53800
The packages for 15.0-RELEASE built without the bug fix needed to make
files created via @sample get properly listed in METALOG. Fix the
cloudware which contain @sample-using packages by adding the necessary
files to METALOG manually.
This should be reverted after the next full package build, and live on
only in releng/15.0.
Reviewed by: markj
MFC after: immediately (15.0-RC2)
Differential Revision: https://reviews.freebsd.org/D53797
We ship these in order to comply with GCE Marketplace rules about
providing source code and licenses for all the software we ship as
part of images.
Reviewed by: markj
MFC after: immediately (15.0-RC2)
Differential Revision: https://reviews.freebsd.org/D53796
These were forgotten during the METALOGization process earlier.
Reviewed by: markj
MFC after: immediately (for 15.0-RC2)
Differential Revision: https://reviews.freebsd.org/D53795
Paths all need to start with "./" because that's what newfs wants.
Fixes: e0c41af925 ("vmimage.subr: Enable FreeBSD-base repo if pkgbase")
MFC after: immediately
When installing "extra" packages (aka those built from the ports tree),
we record everything being installed in METALOG.pkg; the contents of
that file is appended to METALOG before we generate the filesystem.
There are two cases when files recorded in METALOG.pkg will no longer
exist by the time we create the final disk image:
1. If a pkg bug results in false dependencies being installed which
are later removed by "pkg autoremove", and
2. If the pkg we build and install from /usr/ports is older than the
pkg on pkg.freebsd.org, and pkg gets upgraded automatically as part of
installing extra packages.
The ultimate issue in both cases is that there's no mechanism for
removing entries from METALOG when we run 'pkg delete'.
Address this build breakage by checking, line by line, if filesystem
objects mentioned in METALOG.pkg exist before appending them to METALOG.
Fixes: 6a13aeac3c ("vmimage.subr: pkg autoremove after pkg install")
MFC after: immediately (needed for 15.0-RC1)
Running 'pkg autoremove' without -y results in VM image builds failing
when (bogusly installed) packages are removed.
Fixes: 6a13aeac3c ("vmimage.subr: pkg autoremove after pkg install")
MFC after: immediately (needed for 15.0-RC1)
When creating a VM image using pkgbase, create a configuration file in
/usr/local/etc/pkg/repos/FreeBSD.conf which enables the FreeBSD-base
repository. (This repository is defined in /etc/pkg/FreeBSD.conf as
being disabled by default.)
Reported by: Mark Millard
MFC after: immediately (needed for 15.0-RC1)
We were doing this in vm_extra_install_packages but VM images without
any extra packages installed would not get this installed. This
results in a pkgbase system which thinks it doesn't have any packages
installed (even though all the files are right there).
Add a "metalog_add_data ./var/db/pkg/local.sqlite" call to the pkgbase
install code path, and make the call from vm_extra_install_packages
conditional on !PKGBASE.
Reported by: Michael Dexter
MFC after: immediately (needed for 15.0-RC1)
We ingest Makefile.gce even when we're not trying to create GCE images
so we don't want to .error here. Instead, set GCE_ARCH to a dummy
value which should make the problem clear to anyone who attempts to
create GCE images on an unsupported architecture.
Reported by: Jenkins
Fixes: 0a8ecca4e3 ("GCE: Specify the architecture of images")
Without a specified architecture, a user can attempt to create an
arm64 instance with an amd64 image or vice versa. With the change
the API will prevent that mismatch.
GCE image family is meant to be unique per set of image characteristics
so that a user can create instances using the image family instead of the
image name to reliably get a similar image with updated software, but no
other changes.
Without this change, the instances create API would select the most recent
non-deprecated image matching the name, regardless of architecture or
filesystem.
We need to specify the correct image names -- *.vhdf, not *.vhd -- in
order for them to upload.
15.0 candidate
Reviewed by: lwhsu
MFC after: 2 days
Differential Revision: https://reviews.freebsd.org/D53684
OpenPAM is a discrete, largely self-contained system component.
Users may not need PAM for many use-cases (e.g. jails, containers),
so move it to its own package.
Use LIB_PACKAGE to create a separate pam-lib package for libpam,
so that applications that support PAM don't need to bring in all
the PAM modules if PAM isn't actually in use.
Add pam to the minimal sets, since this is a core system component that
people expect to be installed. This means all supported installation
methods will install the PAM modules by default, so don't add explicit
dependencies on the PAM modules from things that use PAM (e.g. runtime),
allowing custom/embedded systems to omit these easily.
This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.
MFC after: never
Reviewed by: des, bapt
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53602
We have NO_ROOT here, so we need WITHOUT_QEMU to avoid problems.
15.0 candidate.
Reviewed by: emaste, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53637
gtest/gmock are not normally used by users unless running the tests,
so they shouldn't be in the utilities package. Move them to a new
googletest package, to match what we did with ATF/Kyua.
While here, move tests dependencies from tests-all.ucl to tests.ucl,
which is the canonical place for that.
This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.
MFC after: never
Reported by: emaste
Reviewed by: manu
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53607
As set-base depends on set-optional, so should set-base-dbg depend on
set-optional-dbg. Otherwise, people who install set-base-dbg will be
missing a bunch of debug packages.
MFC after: 1 day
Reviewed by: emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53575
We want to fetch distfiles, regardless of whether they contain known
vulnerabilities or we're building images for a different version of
FreeBSD.
Reviewed by: ivy
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53569
In order to comply with the require that GCE images must include their
source code, we fetch distfiles for all of the packages installed into
GCE images. This fails for obvious reasons for packages with an origin
of base/*; filter those out to generate the list to fetch.
Reviewed by: ivy
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53568
GCE images are required by Google to include their source code; we do
this by extracting {src,ports}.txz into the images, from the (legacy)
distribution sets.
Make sure those distribution sets actually exist.
Reviewed by: ivy
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53567
A bug in pkg, which somehow only surfaced as a consequence of pkgbase,
results in pkg install sometimes pulling in false dependencies. This
problem might be limited to cases when the lib32 pkgbase packages are
not installed. In the case of EC2 "small" images, installing the
ebsnvme-id package results in binutils, gcc12-devel, gmp, indexinfo,
liblz4, mpc, mpfr, and zstd packages being installed.
These false dependencies are however not recorded as dependencies --
at some level pkg does understand that they're not needed -- so running
pkg autoremove immediately after pkg install cleans them up.
Note: This does not remove lines from METALOG corresponding to these
packages, and makefs emits an error when it attempts to create the
filesystem but cannot find the files listed in METALOG -- but makefs
does seem to complete normally despite the error messages.
This change should be reverted once the pkg issue has been located and
fixed.
Reviewed by: ivy
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53543
Building VMs as non-root requires no-QEMU code paths (installing
packages from outside the VM image rather than inside it) and vice
versa; we have a check for broken combinations.
Unfortunately that check was breaking
make -C src/usr.sbin/pkg NO_ROOT=YES -V PKGCONFBRANCH
because that code reaches into src/release to determine the branch
name (which is then used to determine which /etc/pkg/FreeBSD.conf to
install).
Wrap the no-root/no-qemu check in an .if to only run when we've
asked for VM and/or CLOUD building to be enabled.
Reviewed by: ivy
MFC after: 5 minutes
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53486
zlib is a standalone third-party component, and deserves its own
package rather than living in runtime. For example, this will make
future security updates less invasive. This also means there's no
dependency on runtime for ports that just require zlib, which is
useful for service jails.
MFC after: 3 days
Reviewed by: bapt, emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53058
This is somewhat widely used in VNET jails, it's fairly small (150kB on
amd64) and it's enough of a core system component that it's reasonable
to include, even if many jails don't require it.
MFC after: 3 days
Reviewed by: dch
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53154
flua is a standalone third-party component that deserves its own
package. In particular, this means things can use flua without
having to depend on FreeBSD-utilities, which will be useful as
more base utilities use flua.
This saves ~500kB in FreeBSD-utilities for systems which don't
need flua.
MFC after: 3 days
Reviewed by: kevans
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53161
Currently, files in /boot (other than /boot/kernel) are assigned to the
bootloader package using a filename match in mtree-to-plist.awk. This
causes some problems, most notably that debug info for userboot ends up
in the utilities-dbg package instead of bootloader-dbg.
Remove the path handling from mtree-to-plist and instead set PACKAGE
in the appropriate Makefiles to put these in the correct package.
While here, move userboot*.so from bootloader-dev to bootloader.
MFC after: 3 days
Reviewed by: cperciva
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53179
This defaults to plain "pkg", but being able to override it is useful
when testing pkg itself.
Reviewed by: cperciva
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53307
There may be other issues here but this change certainly seems to
be necessary.
PR: 290394
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D53263
We're correctly recording all of the packages in the dvd METALOG file,
but if we don't record ./packages/repos/FreeBSD_install_cdrom.conf then
users won't be able to install them very easily.
Reviewed by: markj
Reported by: Lars Tunkrans
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53199
Sometimes one or the other but not both tools are present; this ensures
that all cases are correctly handled.
Reported by: cperciva
Approved by: cperciva (re)
Sponsored by: SkunkWerks, GmbH
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D53186
MFC after: 2 days
We only need to check for unMETALOGed directories and sort the METALOG
file if we're using it, i.e. if we're doing a NO_ROOT build. This
non-NO_ROOT builds by no longer bogusly writing to /METALOG*.
We only need to add databases (spwd.db etc) to METALOG if we're doing
a pkgbase-enabled NO_ROOT build; but we should always do this before
creating the filesystem, not only if we installed extra packages (in
vm_extra_install_packages, where that code was erroneously placed).
This fixes non-cloud VM images, which in 15.0-BETA2 shipped without
password databases.
Reviewed by: ivy
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53194
Theoretically METALOG should include everything which needs to go
into disk images; unfortunately there are still a few bugs which
are resulting in directories not being listed -- and if METALOG
has files in unrecorded directories, the directories end up being
created with 000 permissions.
Oddly enough, systems where / has 000 permissions are not very
usable.
As a temporary hack, compare the staging tree against METALOG and
add entries for any unrecorded directories. This will hopefully
be reverted before 15.0-RELEASE.
Reviewed by: bapt, emaste, ivy
Sponsored by: https://www.patreon.com/cperciva
MFC after: 5 minutes
Differential Revision: https://reviews.freebsd.org/D53153
Include /packages in the METALOG used to create dvd1.iso. Previously
we used an expression ^./packages/ (with a trailing /) which did not
match /packages itself, and then with no METALOG entry /packages on
dvd1.iso ended up with mode d---------.
PR: 290222
Reviewed by: cperciva
MFC after: 1 minute
Sponsored by: The FreeBSD Foundation
This more accurately reflects its purpose, and its contents, since
everything in the package is prefixed with "local-".
While here, add a message on upgrade about regenerating the config.
MFC after: 3 seconds
Requested by: des
Reviewed by: des
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53056
When creating VM images from pkgbase, the METALOG may not be in order;
in particular, files may be listed before the directories which contain
them. This causes makefs to create directories with 000 permissions.
Interestingly, such VM images boot just fine, since root ignores those
permissions; the first sign of trouble was sshd refusing logins with an
error message which said absolutely nothing about /etc/ having
incorrect permissions or being unable to read files inside it.
Immediately prior to running makefs, sort the METALOG file. While
we're here, uniquify as well; this does not guarantee that we do not
have duplicate paths, but if there are duplicate paths with different
settings something else has gone wrong and we don't really have any
good way of solving the problem anyway.
Reviewed by: ivy
Hint from: imp
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53046
