The framework do not support multiple format images, so this last minute
addition of qcow2 format was clearly not a good idea.
while here fix a typo
Reported by: cperciva
This is made in order to be able to find add the post-install scripts
for the kernel, where PKGNAME varies for each KERNCONF but we don't want
to dynamically duplicated the kernel.ucl file.
At the same time we don't want the *-dbg* packages to actually include
those post-install scripts
Rework how ucl manifest are generated leveraging ucl features and flua
now the ucl generation is done via a lua script which uses libucl to
ingest the template and use variables as defined in its command line.
the template will include only if it exist a ucl file named after the
package name which will complement the template or overwrite what was
defined in the template if defined in this specific ucl file
this allows to overwrite license, but add script only to the packages
who actually needs them.
As a results the post install scripts are now only added to the right
package and not also added to the subpackages like -man or -dev
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44374
Provide both zfs and ufs images which a 1MB partition reserved for the
config drive wearing a GPT Label "config-drive" to allow consumer to
know where they should push the config drive on the provided image.
2 formats available: qcow2 and raw
This has been tested on OVHCloud baremetal via "bring your own image"
Also tested on openstack
Reviewed by: emaste
Sponsored by: OVHCloud
Differential Revision: https://reviews.freebsd.org/D44369
GDB was the final GNU binutils component included in the base system,
but was removed in 2020. Nothing provides a pkgbase binutils package
any longer.
Fixes: 1c0ea326aa ("Retire obsolete GDB 6.1.1")
Sponsored by: The FreeBSD Foundation
Currently there is no support for generating armv7 vm images in the
release artifacts. In fact in terms of release artifacts and
architecture there is no good reason to have a vm release artifact for
armv7 as those are mostly used in SOCs or embedded boards. However
considering that developers actually do need an easy way to test armv7
with a vm running this is really important. As part of pre-commit ci for
developers this can be really helpful for the end developers.
Approved by: cperciva, imp, re
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43952
Create two partitions in the existing space at the beginning of the
image (8MB). These are intended to hold u-boot SPL and u-boot proper.
The partition types selected are compatible with SiFive boards, e.g. the
HiFive Unmatched. They can easily be overridden for a platform that uses
the same scheme but different partition types, e.g. the StarFive
VisionFive v2. Firmware is not actually installed, this too is left for
the user.
It is not as simple to create the firmware partitions after the fact,
e.g. with partition indices 3 and 4. It is a shortcoming of current day
u-boot that the SPL loader looks for a specific partition index, rather
than the partition type, meaning that we will fail to boot if partition
2 doesn't contain u-boot.
Thus, our GENERICSD images become more generically usable with current
RISC-V hardware/firmware platforms.
Reviewed by: manu, karels, imp
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43849
Currently the partition layout is hardcoded to create an EFI/FAT
partition and a UFS root partition, with some logic to handle GPT/MBR
differences.
On RISC-V platforms we are seeing the emerging pattern that firmware
should be placed in a partition of a known type, rather than just a
known sector of the disk. Thus, some functionality is needed to
customize the layout for SD card images.
Add a hook, arm_create_partitions(), which can be overridden to insert
additional platform-specific partitions, possibly preceding the standard
EFI and UFS ones. A couple of new variables are added to track the
indices, e.g. ROOTFSPART_SUFFIX=p2.
In a couple places this de-duplicates the GPT/MBR logic.
Reviewed by: manu, karels, imp
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43848
These days, the entries are the identical for GPT and MBR.
Reviewed by: manu, karels, imp
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43847
Let Azure use the image directly built by the release engineering team.
Reviewed by: emaste
Approved by: cperciva (re)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41906
This reverts commit 9bbe06b004.
Before that dtbs where included in each kernel packages which prevents
us to install multiple kernels.
Fix mtree-to-plist.awk to only generate a dtb.plist when we create
the kernel one (because dtb are installed during make installkernel).
Sponsored by: Beckhoff Automation GmbH & Co. KG
When only the user (ALL) is specified explicitly, and the group is
implied, only sudo -u works. Specifying both the user and group, like
(ALL:ALL), is required to:
1. Use sudo -g by itself (with no -u user)
2. Use sudo -u and -g together, with a -g group that is different from
the -u user's primary group
Obtained from: 1d13533ea3
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/835
Somehow this doesn't work iwth make packages due to some kind of a race.
The package is first created correctly but later in the process it is
overwritten by a badly created empty package.
Revert in the mean time so we can have working pkgbase on arm/arm64
This reverts commit a5afd7920d.
Before that dtbs where included in each kernel packages which prevents
us to install multiple kernels.
Differential Revision: https://reviews.freebsd.org/D43632
Reviewed by: bapt
Sponsored by: Beckhoff Automation GmbH & Co. KG
The `make release` command now creates VM and cloudware images (if
enabled) in addition to disk images; this results in a very large
number of 'make installworld' commands running sequentially. Adding
-jN should speed this up significantly.
MFC after: 1 month
X-MFC-to: stable/14
The amd64 and arm64 images supported UEFI, mark it as so users can take
advantage of UEFI boot on GCE. This is already done on FreeBSD
14.0-RELEASE but never codified into the release tools (and should).
PR: conf/276532
Reviewed by: lwhsu
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43557
Components like base.txz and ports.txz are called distributions in the
installer, and with the introduction of pkgbase we will start dealing
with normal pkg packages in the installer. Rename EXTRA_PACKAGES to
DISTRIBUTIONS, and move base.txz and kernel.txz to that list.
This introduces no functional change but is a small cleanup in advance
of some pkgbase experimentation.
Reviewed by: cperciva
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43544
The stable/13 snapshot this week failed to build the riscv GENERICSD
image because it ran out of space. Checking main and stable/14
snapshots, they are also low on space, around 100% or more of
capacity. Increase them all from 5 GB to 6 GB. Note, this is the
only riscv image configuration.
Discussed with: cperciva
This marks FreeBSD GCE images as gVNIC capable by adding the
--guest-os-features=GVNIC flag at creation time as suggested in GCE
documentation[1]. This allows Generation 3 and newer GCE instances
to leverage advanced networking capabilities and performance
enhancements provided by gVNIC. Users will benefit from these
improvements without needing to create custom images.
[1] https://cloud.google.com/compute/docs/networking/using-gvnic#create_a_vm_with_gvnic_support
Reviewed by: cperciva
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43411
Most 64-bit Raspberry Pi models have a variable processor clock
speed that defaults to a slow speed (e.g. 600 MHz for a nominal
1.5 GHz clock). This results in everything running slowly unless
or until powerd is started, and FreeBSD is then thought to be slow.
Enable powerd by default in /etc/rc.conf on the arm64-aarch64-RPI
images. Tested on Raspberry Pi 3B+ and 4B so far.
PR: 256836
MFC after: 1 month
Reviewed by: rgrimes
Differential Revision: https://reviews.freebsd.org/D43296
Allow the cloudware *_FLAVOURS and *_FSLIST values to be overridden
at the command line, to assist users who want to e.g. build only one
of the many EC2 AMIs available.
FreeBSD-src for all the sources but the kernel
FreeBSD-src-sys just for the kernel
MFC After: 3 days
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D42651
The emulator-portinstall target now unconditionally ensures that qemu
is installed; but is only invoked if needed (aka. when cross building
VM images).
MFC After: 3 days
MFC With: 97bd53ef4d ("Fix duplicate rc.conf files")
Two bugs in Makefile.vm resulted in disk images being "built" multiple
times, resulting in lines added to /etc/rc.conf being duplicated:
1. The vm-image target reused the same "staging tree" directory for all
of its builds (multiple disk image types and multiple filesystem types).
2. The cw-type-flavour-fs target depends on emulator-portinstall, which
did not have a 'touch ${.TARGET}' and thus re-ran every time -- and
caused the cw-type-flavour-fs target to be re-run. This was triggered
by release builds running `make cloudware-release` (creating the disk
images) followed by `make ec2amis` (which re-created the disk images
prior to uploading them).
MFC After: 1 week
Sponsored by: https://www.patreon.com/cperciva
Unbloat a bit FreeBSD-utilities.
The only package that will depends on this new one is FreeBSD-ssh
which not anyone have in some setup.
And this will allow to have small pkgbase setup with ssh without
having to bring the bloated FreeBSD-utilities package
Name the package blocklist to reflect upstream futur changes.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D42148
Known issues:
1. The ec2-user user is created with a homedir of /usr/home/ec2-user
instead of /home/ec2-user; this appears to be a bug in cloud-init's
FreeBSD support.
2. Cloud-init configures IPv4 networking but not IPv6 networking.
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Relnotes: yes
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41793
Split ec2-base.conf into ec2-base.conf and a reusable ec2.conf,
similar to how Vagrant flavours share a common vagrant.conf.
releng/14.0 candidate.
Discussed with: gjb
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41792
Using the recently-added "cloudware flavours" mechanism, turn the
existing EC2 AMIs into a new "base" flavour. The only user-visible
change is that AMI names now include the word "base".
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41791
There are two "Vagrant" images right now: "Vagrant Image for VirtualBox"
and "Vagrant Image for VMWare". Rather than listing these separately in
a CLOUDWARE list, place "VAGRANT" into a CLOUDWARE_TYPES list and then
use a VAGRANT_FLAVOURS variable to identify the two versions. Add make
logic to allow defaults (in this case, image format and filesystem) to
be specified once for VAGRANT and inherited by both flavours.
This will make future work to add flavoured EC2 images simpler.
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41790
The cw*-package targets were introduced in February 2015 as part of
adding support for building GCE images; but GCE support was reworked
in June 2015 and the cw*-package targets were in fact never used.
Remove them.
The *_DISK variables were introduced in February 2015 as part of
adding the cloudware-install target; this was removed in May 2016 as
the cloudware images are published via the respective cloud systems
and not published as disk images via the FreeBSD FTP site. As such,
the *_DISK variables are not unused; remove them.
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41789
We no longer install a default portsnap.conf, so the sed invocation just
generates an error.
Reviewed by: cperciva
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42003
mergemaster was deprecated some time ago and will be removed from
FreeBSD 15.
Reviewed by: imp
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41797
Headers from src/include were in the runtime-dev package but
subdirectories of src/include ended up in utilities-dev by default.
Neither package is a good choice - the headers in src/include are not
useful without the libraries contained in clibs-dev.
This moves the standard C headers to clibs-dev (C++ headers are already
in this package). While working on this, I found that various clang
libraries and headers were also bundled into utilities-dev by default
so these are also moved to clang-dev.
I also added a FreeBSD-build-essential meta package to make it simple to
install all the toolchain parts.
PR: 254173
Reviewed byb: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41815
Other cloud images do not do this, and it can produce confusing results.
Reviewed by: Jose Luis Duran, delphij
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41751
To overcome package name changing on default Python version updates.
Approved by: gjb (re)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41453
