On some platforms (e.g. powerpc) we don't have packages, so we can't
install them onto the ISOs. Proceed with building the images anyway.
Reported by: Weekly snapshot builds
Fixes: 7e2996c1f5 ("release: install wireless firmware onto disc1 and dvd")
MFC after: 1 minute
Wireless driver firmware is no longer added to the src tree.
In order to have wireless support in the installer for the new drivers
we install the firmware packages onto disc1 (and memstick) and dvd
if built on FreeBSD and NOPKG is not defined (to not break cross-builds
from Linux or OSX and to allow people to opt-out).
Sponsored by: The FreeBSD Foundation
Submitted by: cperciva (the orig. commands and where to place them)
Reviewed by: jrtc27
MFC after: 6 hours
Differential Revision: https://reviews.freebsd.org/D47407
For "release" builds (as opposed to "snapshot" builds -- in this
context BETAs and RCs are "releases") ${SNAP_SUFFIX} is empty; but it
stuck into some ociimages filenames via a copy-and-paste error.
The final filenames on the download mirrors were not affected, so
this does not need to be merged to releng/14.2.
MFC after: 3 days
Sponsored by: Amazon
These are installed into /ociimages/ and stage onto the download site
at /OCI-IMAGES/; they don't belong in the same directory as the
"distribution" .txz files.
Fixes: d03c82c28d ("release: add optional OCI images")
MFC after: 1 minute
Sponsored by: Amazon
We use a *.txz glob to get all of the "distributions" which comprise
the FreeBSD release, but we now (optionally) also build container
images which are .txz files. Grep those out from the distribution
lists.
A better long-term fix would probably be to generate an explicit list
of the .txz files we want rather than using an overbroad glob and
filtering out the files we *don't* want.
Fixes: d03c82c28d ("release: add optional OCI images")
MFC after: 1 minute
Sponsored by: Amazon
If WITH_OCIIMAGES is set, "make ftp-stage" will now publish those bits
into a directory under /OCI-IMAGES/, similar to how we publish CI and
VM images.
MFC after: 1 minute
It was disabled by default in fe52b7f60e. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.
Relnotes: Yes
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31558
Rather than adding the rtw88 package add the flavored port for all the
supported wireless drivers we recently added support for.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Pointed out by: cperciva (as part of the set of changes)
Reviewed by: cperciva (#releng)
Differential Revision: https://reviews.freebsd.org/D47406
This adds three OCI archive format files to the release containing
FreeBSD base images suitable for static linked, dynamic linked and shell
workloads. The shell image also contains pkg-bootstrap and can be easily
extended by installing packages (including pkgbase packages).
Reviewed by: dch, cpersiva, jlduran, zlei
Differential Revision: https://reviews.freebsd.org/D46759
MFC after: 2 days
In 2016, commit 8834318685 reworked the code for excluding -dbg
files from install media, and in the process accidentally broke it
for dvd images ('grep -v' should have been 'grep -vE').
FreeBSD Update builds later began to depend on this, and in any case
since DVD images are intended as "include everything" images there's
no point excluding those; so remove the (broken) filtering from DVD
image builds.
Sponsored by: Amazon
MFC after: 2 days
While OK for 14.x, both 13.x and 15.0 are failing in snapshot
builds.
Reported by: cperciva
Sponsored by: SkunkWerks, GmbH
Reviewed by: emaste
Approved by: cperciva
Differential Revision: https://reviews.freebsd.org/D47285
AWS Graviton [1234] systems have a bug in their ACPI where they mark
the PL061's GPIO pins as needing to be configured in PullUp mode (in
fact the PL061 has no pullup/pulldown resistors); this flag needs to
be removed in order for _AEI objects to be handled on these systems.
Reviewed by: Ali Saidi
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47239
- use raw image disk type and enable zfs, this yields smaller
images for upload after using native qcow2 + zstd compression
Reviewed by: lwhsu, emaste
Differential Revision: https://reviews.freebsd.org/D47055
MFC after: 3 days
Approved by: emaste
This allows future releng tooling to use OCI for the industry
standard Open Container Initiative tooling, reducing potential
for confusion.
Approved by: cperciva
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46975
MFC after: 3 days
Sponsored by: SkunkWerks, GmbH
- Add the firstboot-freebsd-update package, as long as we do not have
pkgbase, this is needed
- Support SLAAC by default to complement DHCPv4 (use SYNCDHP instead)
Signed-off-by: Jose Luis Duran <jlduran@gmail.com>
This handles copying in install-boot.sh and bsdinstall's bootconfig.
install-boot.sh:
make_esp_file now optionally takes extra arguments so it can copy
multiple files. This is used by the amd64 release scripts.
make_esp_device also takes an extra optional argument for efibootname.
This is currently unused, but it can be used in the future to do
something like:
make_esp_device loader.efi bootx64
make_esp_device loader_ia32.efi bootia32
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
These are largely obsolete, and generating them is responsible for
over 10% of the total boot time of EC2 instances.
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46638
These are the same as the standard "base" images except:
* They don't have kernel or world debug symbols,
* They don't have FreeBSD tests,
* They don't have 32-bit libraries,
* They don't have LLDB,
* They don't have the Amazon SSM Agent pre-installed,
* They don't default to installing the awscli at first boot.
This reduces the amount of disk space in use when the EC2 instance
finishes booting from ~5 GB to ~1 GB.
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46509
Move it from VM_EXTRA_PACKAGES in ec2.conf to VM_EXTRA_PACKAGES in
ec2-{base,cloud-init}.conf
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46508
Having the "base" FreeBSD network configuration (aka. what is used
when not using cloud-init) in ec2.conf will allow us to reuse it in
other AMIs.
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46507
This makes it possible for a VM build configuration file to pass
options to make installworld/installkernel/distribution, e.g.
WITHOUT_DEBUG_FILES=YES in order to produce smaller images.
Note that these options are only applied at install time, not at
build time (since the same build is installed into many different
VM images), so not all src.conf options are usable here.
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46506
Stop shipping a log file for etcupdate. This is a source of
non-reproducability as it uses mktemp thereby guaranteeing the output is
different each run.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D46317
Starting in September 2021 EC2 AMI names have included the boot method:
"BIOS", "UEFI", or "UEFI-PREFERRED". The third option became available
in June 2023 and allows AMIs to boot via UEFI on EC2 instance types
which support that, but fall back to (much slower) BIOS booting on the
instance types which don't support UEFI.
Since UEFI-PREFERRED is basically a best-of-both-worlds option and is
now the default, there's no point mentioning it in the AMI names. If
for some reason an AMI is built with the boot method forced to BIOS or
UEFI, that will still be included in the AMI name.
This will not be MFCed, in case anyone has scripts which look at the AMI
names on 13.x/14.x.
Sponsored by: Amazon
The DHCP server in EC2 knows exactly which system should be using
which IP address (and in fact EC2 has source IP filtering on by
default) so there's no point ARPing an address before using it.
The preceding commits (changing the ARP wait time from 2 s to 250 ms)
and this one (eliminating the wait entirely in EC2) reduce the time
required for a newly launched FreeBSD/EC2 instance to launch by 2
seconds.
Discussed with: icattard
MFC after: 10 days
Sponsored by: Amazon
The default VM size may depend on the architecture. In particular,
it is currently larged on riscv64 due to a toolchain issue which
results in bloated binaries.
MFC after: 3 days
Fixes: 59c21ed6e8 "release: Bump default VM size for riscv64 to 6 GB"
Sponsored by: Amazon
Due to issues with the riscv64 toolchain, some binaries end up
significantly larger on riscv64 than they should be. This results
in riscv64 VM images -- and at present *only* riscv64 images -- not
fitting within the default 5 GB filesystem size.
Bump the default size for riscv64 to 6 GB until the toolchain issues
can be resolved.
MFC after: 1 week
Sponsored by: Amazon
VM, BASIC-CI, and BASIC-CLOUDWARE images are published with the
filesystem type (UFS or ZFS) in the file name. For backwards
compatibility we have published the UFS images with no filesystem
in the filename (aka with the same file names as we used before we
supported building ZFS VM images); those are going away now.
This will not be MFCed.
If WITH_CLOUDWARE is not set, we didn't build BASIC-CLOUDWARE; don't try
to install it into the /VM-IMAGES/ directory as part of ftp-stage.
Fixes: 4771c2e9d1 "release: Publish non-uploaded cloudware bits"
MFC after: 6 days
While most "cloudware" (AWS, Azure, GCP, Vagrant) images get uploaded
to their respective clouds, we have two images -- BASIC-CI and
BASIC-CLOUDINIT -- which are published via the FTP mirrors. We have
been handling these using a manual and error-prone process of copying
them from the internal build directories into the FTP staging tree,
but they should be handled using the "make install ftp-stage"
mechanism which is used for all the other published images.
This commit 1. Adds a new 'make cloud-install' target which is run as
part of 'make install' and installs BASIC-CI and BASIC-CLOUDINIT images,
and 2. Extends 'make ftp-stage' in Makefile.mirrors to copy those bits
into the FTP staging area.
As a side benefit, this will also make BASIC-CI and BASIC-CLOUDINIT
images available for arm64; until now they have only been available
for amd64.
MFC after: 1 week
This breaks the weekly snapshot builds. We'll try again once Warner has
some time to debug the qemu-user-static-devel port.
This reverts commit a04ecddfc7.
Remove archivers/unzip (now in base) and emulators/linux_base-c7 (old
and unlikely to be useful without other linux packages being installed),
ports-mgmt/portmaster (now largely obsolete and discouraged in favour
of using pkg and binary packages) and x11-drivers/xf86-video-vmware
(questionably useful).
Replace devel/git with devel/git@lite (sufficient for most purposes),
and adjust the "ensure the ports exist to sanitize the list" code to
ignore the @lite part when checking that /usr/ports/devel/git exists.
Add sysutils/seatd and x11-wm/sway for wayland support.
MFC after: 1 minute
Differential Revision: https://reviews.freebsd.org/D45278
For historical reasons, the vm-release and cloudware-release targets
were written as recursive makes of ${VMTARGETS} and ${CLOUDTARGETS};
this worked fine until we started running `make release -jN` and
had both VM and cloud targets depending on ${QEMUTGT}, at which
point things exploded when we tried to build the port twice at the
same time.
Switch vm-release and cloudware-release to have make dependencies on
their individual components; this way a single make process runs and
is aware of the duplicate dependency (and only runs it once).
MFC after: 5 days
The vm_extra_pre_umount function in vmimage.subr served two purposes:
It removed /etc/resolv.conf and /qemu (if cross-building), and it
provided a function for cloudware to override in order to make cloud
specific changes to the filesystem before constructing a disk image.
This resulted in a number of bugs:
1. When cross-building, the emulator binary was left as /qemu in the
Azure, GCE, Openstack and Vagrant images.
2. The build host's resolv.conf was left as /etc/resolv.conf in the
basic-ci and basic-cloudinit images.
3. When building GCE images, a Google-specific resolv.conf file was
constructed, and then deleted before the disk image was created.
Move the bits needed for running code inside a VM staging directory
from vm_install_base into a new vm_emulation_setup routine, and move
the corresponding cleanup bits from vm_extra_pre_umount to a new
vm_emulation_cleanup routine.
Remove the /qemu and /etc/resolv.conf cleanups from the cloudware
configuration files (where they exist) since we will now be running
vm_emulation_cleanup to remove those even when vm_extra_pre_umount
has been overridden.
Override vm_emulation_cleanup in gce.conf since in that one case (and
*only* that one case) we don't want to clean up resolv.conf (since it
was constructed for the VM image rather than copied from the host).
releng/14.1 candidate.
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
For a bit over 5 years, we have used qemu when cross-building cloudware
images; in particular, it's necessary when installing packages which
might include post-install scripts.
Use qemu in the vm-images target too; while "generic" vm images don't
install packages, they still run newaliases and /etc/rc.d/ldconfig,
both of which fail without appropriate emulation.
MFC after: 1 week
When the VM image building code was updated to support building
non-UFS images, the vm-images-stage target was not updated to
install those newly built images to the FTP site. As a result, we
have been sending weekly snapshot announcements since August claiming
that ZFS VM images are available when they are not in fact present
anywhere publicly accessible.
Fixes: 32ae9a6b39 "release: Build UFS and ZFS VM images"
Reported by: Michael Dexter
MFC after: 5 days
A bug in release/packages/generate-ucl.sh causes package dependencies
(other than shlib depends) to not be generated correctly, meaning
packages are missing their dependencies.
generate-ucl.sh creates the UCL file by:
1. copying ${uclsource} (template.ucl) to ${uclfile}
2. appending dependencies to ${uclfile}
3. calling generate-ucl.lua on ${uclsource} to create ${uclfile}
This breaks because the dependencies added in step 2 are overwritten in
step 3.
Fix this by calling generate-ucl.lua with ${uclfile} as both the input
and output file, so anything we added to ${uclfile} is preserved.
Reviewed by: des, imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1203
