The ARM image builds build the in-tree gcc in order to build u-boot
and gperf is needed to build gcc, but is no longer installed on archs
that use clang.
Invoking the make targets as separate steps is done to work around
a build failure which is not yet fully understood.
Reviewed by: gjb, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D1317
if VM_EXTRA_PACKAGES is empty.
In vm_extra_pre_umount(), cleanup downloaded packages
if pkg(8) was bootstrapped earlier.
Inspired by: cperciva
Sponsored by: The FreeBSD Foundation
into the image and running 'pkg install' from there, use 'pkg fetch' to
download packages into a temporary location and then 'pkg add' to install
them into the image.
This simplifies the code by avoiding the need to copy /etc/resolv.conf
into the image and then delete it later, and makes it possible to cross
build (e.g., to create an amd64 image when running on i386 hardware; or
in the future for building disk images for embedded platforms).
Because pkg was implicitly installed when VM_EXTRA_PACKAGES was non-empty,
add it to VM_EXTRA_PACKAGES in azure.conf and openstack.conf to maintain
the current behaviour.
By default repo-FreeBSD.sqlite is copied into the image, (a) to match
previous behaviour, where the file would be downloaded by the chrooted
pkg invocation; and (b) because it may be useful for testing purposes,
e.g., to see why a package didn't get installed. Because this file is
large (46 MB) and not likely to be useful in -RELEASE images which are
being launched into Clouds several months later, it can be disabled by
setting NOREPOSQLITE.
As far as I know this commit does not change the disk images produced in
any filesystem-visible way.
no swap space should be created in the image. This will be used by EC2
builds, since FreeBSD/EC2 allocates swap space on "ephemeral" disks which
are physically attached to the Xen host node.
the build chroot before attempting to do anything that
requires working DNS (i.e., pkg bootstrap).
In vm_extra_pre_umount(), remove the resolv.conf before
the disk image is unmounted from the backing md(4).
Reported by: cperciva
Sponsored by: The FreeBSD Foundation
have chosen different (and more traditional) stateless/statuful
NAT64 as translation mechanism. Last non-trivial commits to both
faith(4) and faithd(8) happened more than 12 years ago, so I assume
it is time to drop RFC3142 in FreeBSD.
No objections from: net@
final image.
Fix duplicated mkimg(1) call in vm_create_disk().
Add primitive (untested) PowerPC/PowerPC64 VM image
support.
Note: As it is currently written, the /boot/pmbr and
/boot/{gptboot,boot1.hfs} use the build host and not
the target build. Fixing this is likely going to be
a hack in itself.
Sponsored by: The FreeBSD Foundation
There may be some very sharp edges here while refactoring.
- Move amd64/mk-vmimage.sh -> scripts/mk-vmimage.sh.
- Remove vm-base target from Makefile.vm.
- In vm-image target, use getopts flags for argument passing.
- Create tools/vmimage.subr, containing default and prototype
for the following functions that are used to drive the build,
run in this order:
vm_install_base()
vm_extra_install_base()
vm_extra_install_packages()
vm_extra_install_ports()
vm_extra_enable_services()
vm_extra_pre_umount()
vm_create_disk()
vm_extra_create_disk()
- In tools/azure.conf, override:
vm_extra_install_base()
vm_extra_pre_umount()
vm_extra_create_disk()
- In tools/openstack.conf, override:
vm_extra_install_base()
vm_extra_pre_umount()
Sponsored by: The FreeBSD Foundation
openstack images as part of the release build.
This mimics the way Microsoft Azure images are
built, with the addition of installing the
net/cloud-init package and adding a (commented)
rc.conf(5) entry for cloudinit.
Sponsored by: The FreeBSD Foundation
VM images by default.
When WITH_CLOUDWARE is not empty, add CLOUDTARGETS
to the release/Makefile 'release' target.
CLOUDTARGETS is generated from the contents of
CLOUDWARE, which should be a list of all supported
target providers.
Sponsored by: The FreeBSD Foundation
installation ISOs:
- TYPE, BRANCH, and REVISION are only defined if
OSRELEASE is not defined, so in situations where
one might set OSRELEASE for an in-house ISO build,
VOLUME_LABEL would be empty.
- makefs(8) limits the volume label to 32 characters,
which for the powerpc64 case, OSRELEASE expands to
FreeBSD-11.0-CURRENT-powerpc-powerpc64. Even with
removing the prefixing 'FreeBSD-', the string is 30
characters long, leaving zero room for suffixing the
type of ISO media (BO for bootonly, CD for cdrom, and
DVD for dvdrom).
Resolve these by defining VOLUME_LABEL when defining
OSRELEASE if unset. If OSRELEASE is defined by the
builder, use the OSRELEASE from that definition as the
VOLUME_LABEL.
In addition, for cases where both TARGET and TARGET_ARCH
are used for the VOLUME_LABEL, use TARGET_ARCH if it
differs from TARGET.
There are probably a few sharp edges here yet, but these
problems are going to affect the powerpc/powerpc64 builds
for 10.1-RELEASE, so the immediate concern is fixing the
underlying problem at hand quickly, and less so about the
elegance of the fix.
MFC after: 3 days
X-MFC-10.1: yes, asap
Sponsored by: The FreeBSD Foundation
r273076, r273077, r273079, r273095:
r273076:
Add a separate make(1) target to release/Makefile to
build FreeBSD virtual machine disk images for use on
the Microsoft Azure service.
For now, this target is not directly connected to the
build, however can be manually invoked.
The 'vm-azure' target invokes {amd64,i386}/mk-azure.sh,
which does the heavy lifting to produce proper VHDs.
mk-azure.sh uses a configuration file, defaulting to
tools/azure.conf if otherwise unset.
r273077:
Clear VM_RC_LIST.
r273079:
Fix signal list to trigger umount(8).
r273095:
Output an informational message when mkimg(1) runs, so it
does not appear that the process has stopped while waiting
for a 'y/n' response when waagent is deprovisioned.
Tested on: releng/10.1@r272876
MFC after: 3 days
X-MFC-10.1: yes
Sponsored by: The FreeBSD Foundation
