Deprovision feature of waagent is used for preparing to capture a
running VM and turn it into a VM image. Using it in the process of
building a VM image from scratch will cause some side effects such as
the hostname of the building host getting reset.
Remove calling the deprovision command and use a simpler way to fulfill
the requirements of the Azure VM image.
Sponsored by: The FreeBSD Foundation
The change extends vmimage.subr to handle a new parameter, VMFS, which
should be equal to either "ufs" or "zfs". When it is set to ZFS, we use
makefs to create a bootable pool populated using the same dataset layout
as bsdinstall and "poudriere image" use. The pool can be grown using
the growfs rc.d script, just as in UFS images.
This will make it easy to provide VM and cloud images with ZFS as the
root filesystem. So far I did not do extensive testing of cloud images;
I merely verified that creation of ZFS-based AWS AMIs works and allows
me to create amd64 and arm64 EC2 instances with ZFS as the root
filesystem.
Reviewed by: emaste, gjb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34426
devmatch is useful on standalone machine but not on jails.
Put devinfo(8) and libdevinfo there too.
Differential Revision: https://reviews.freebsd.org/D36229
It's not really useful in a jail or in a mdroot or even if a users
wants to do a full zfs machine.
Reviewed by: mckusick
Differential Revision: https://reviews.freebsd.org/D36227
It is useful to have zfs utilities and lib in a separate package as
it allow users to create image that can support ZFS (i.e. not with
WITHOUT_ZFS in src.conf set) without bloating the default image with
all zfs tools (for example for jails).
Differential Revision: https://reviews.freebsd.org/D36225
For most users it's not needed to boot and they are also
available in the FreeBSD-rescue package in case an update
break and FreeBSD-geom package isn't updated correctly.
Differential Revision: https://reviews.freebsd.org/D36224
It doesn't really make sense to have it in runtime and let's not
bloat utilities more.
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D36222
It doesn't really make sense to have it in runtime and let's not
bloat utilities more.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D36221
We need to do a relative link to efi instead of an absolute link into
the build tree.
Sponsored by: Netflix
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D36941
I somehow introduced the typo when extracting one part of D34598.
Reported by: Jose Luis Duran <jlduran@gmail.com>
Fixes: 9871ae6aa9 ("Track kern.ipc.somaxconn -> ...")
Currently the installer is only started on the primary ("high level")
console. For systems where this is the video console and serial consoles
aren't of interest, and headless systems with just a serial console,
this works just fine, but for systems where both video and serial
consoles are present and meaningful this requires the user to select the
right primary console in loader, with the poor user experience of the
system appearing to hang if they leave the wrong one selected. This
notably differs from our multi-user behaviour of spawning getty on every
console, where the only issue with selecting the wrong primary console
is a quieter boot process until the login prompt appears (or the system
crashes).
Instead, use the newly-added runconsoles helper to run the installer on
every console (except for ttyv*, where only ttyv0 will be used). For
interactive installations, any of the consoles can be used, though only
one should be used at a time as no effort is made to avoid multiple
installations running at the same time clobbering each other. If the
Live CD option is selected, the other installers (which should, if the
user is well-behaved, be sitting at the welcome screen) will be killed.
If an automated install is in use, the primary console will be used to
display its output, and the others will direct the user to the primary
console.
Reviewed by: brooks, gjb
Differential Revision: https://reviews.freebsd.org/D36805
This separates out the install media-specific environment (creating
bsdinstall_etc) from actually running the installer on a given console.
This will be used by a future change to start the installer on multiple
consoles.
Reviewed by: brooks, gjb
Differential Revision: https://reviews.freebsd.org/D36803
The cons25w line was added in c991a64747 for pc98, along with reading
MACHINE in order to determine what terminal type to use for VTYs. Commit
2b375b4edd removed this condition, leaving it as always using xterm
for VTYs, but left behind the now-unused MACHINE variable and the
cons25w list entry. Clean these up to be how they were before pc98
support was added.
Note that anyone who really needs a cons25w terminal can still request
it, it's just not listed as a common option.
Reviewed by: imp, brooks
Differential Revision: https://reviews.freebsd.org/D36587
Traditionally, we've used /boot/msdos for the MBR mount point for the SD
images that we produced. For GPT and bsdinstall, we've used
/boot/efi. Migrate to using /boot/efi for MBR as well and add a
/boot/msdos -> /boot/efi symlink for compatibility (which may disappear
before 14.0, but will remain on the stable branches).
When we first created the arm images, there was no EFI booting and the
FAT partion on an MBR image was used to hold the firmware, uboot.bin,
SoC config files and ubldr. When we transitioned to uboot with EFI, we
put the loader files in the same partition. Later we standardized on
/boot/efi at about the same time we added GPT support to the RE produced
images. We left the MRB case as /boot/msdos for legacy reasons and since
it wasn't always EFI. Later, we dropped support of non-EFI booting on
the RE produced images, so the duality of /boot/msdos diminished even
more. Since so little secondary meaning remains, putting it all in
/boot/efi standardizes the location and reflects the RE images
better as using efi-only booting.
In addition, always label the msdosfs partion 'efi'. While a small
misnomer on some systems that store other files in the ESP, it was
requested in review for more consistency for similar reasons to the
mountpoint rename. There was no way to have an 'alias' or 'second label'
here, so this breaks compatibility. Since the images are self-contained,
this was judged to be an acceptable change.
Sponsored by: Netflix
Reviewed by: manu, allanjude, emaste, gjb
Differential Revision: https://reviews.freebsd.org/D36635
This can be useful instead of reboot if installing in a virtual machine,
and the user wants to modify the VM hardware or virtual media mounts
prior to booting into the newly installed system.
Reported by: Juan Manuel Palacios (@jmp_imaginarium on Twitter)
Approved by: philip
Differential Revision: https://reviews.freebsd.org/D36560
This makes it more obvious that the media being booted is an installer
rather than an installed system, which is otherwise hard to distinguish.
It also provides a more user-friendly, and more accurate, prompt.
Reviewed by: gjb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36419
This makes use of the new -N etcupdate flag and merges the resulting
METALOG into base.meta re-rooted to /var/db/etcupdate/current.
Reviewed by: gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35858
This is in preparation for non-FreeBSD builds where make is GNU make and
so etcupdate needs to know the name of or path to the bmake binary to
use for its own builds.
Reviewed by: gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35855
This is in preparation for non-FreeBSD and -DNO_ROOT builds. On
non-FreeBSD there is no host etcupdate to use, and -DNO_ROOT will
require additional flags that may not be supported by the host's
etcupdate when building on FreeBSD. Moreover, there's no guarantee
anyway that the host's etcupdate is quite right for the current tree;
upgrading from source only requires that the host's is good enough for
-p which just manually copies master.passwd and group, the rest of the
upgrade is done post-installworld. For example, should a new set of
autogenerated files be added that etcupdate is taught about, the host
won't know about them and so the bootstrapped current tree will
incorrectly contain them, leading to spurious diffs on the installed
system.
Reviewed by: gjb, delphij
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35853
We do not want CHS-based alignment for VM or SD card release images.
(Other images use makefs/mkimg, not kernel gpart and so do not depend
on this sysctl.)
Sponsored by: The FreeBSD Foundation
Approved by: re (gjb)
MFC after: 1 week
Summary:
This allows installing packages that depend on kerberos libraries
without pulling in all the binaries. It also moves libgssapi to runtime
to allow installing kerbereos libraries without adding a dependancy on
the large utilities package. It makes sense to put libgssapi in runtime
rather than kerberos-lib since this is a plugin layer which is intended
to support any GSS-API mechanisms, not just kerberos.
A good example of a package which uses kerberos libraries without
needing the kerberos utilities is sshd. This uses the kerberos GSS-API
libraries to implement its GSSAPIAuthentication option.
MFC after: 2 weeks
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D36028
BSD stat and GNU stat differ significantly when it comes to using a
custom format string, both in the option name and in the format string
itself. Handle both here (assuming Linux means GNU stat rather than BSD
stat).
Reviewed by: brooks, gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35814
Our uses of tar rely on BSDisms, and so do not work in environments
where GNU tar is the default tar. Providing a TAR_CMD variable like
some other commands allows it to be overridden to use bsdtar in such
cases.
Reviewed by: brooks, delphij, gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35813
For some reason, while 3072M is sufficient for 14-CURRENT, it is not
for 13-STABLE. Notably, previous investigations suggest that there
are changes to makefs(8) in main that do not exist in stable/13,
in which 14-CURRENT seems perfectly happy to ignore the target image
size is smaller than the data being populated to it.
I have no futher investigative details at the moment, but as this had
caused arm failures for the past three weeks, this is the more hasty
measure, hence the MFC timeframe noted.
MFC after: 10 minutes
Sponsored by: Rubicon Communications, LLC ("Netgate")
The latest version of the ec2-scripts package includes a completely
rewritten "use EC2 ephemeral disks for swap space" script. Now that
we have something which works on recent versions of FreeBSD, turn it
on since it's a great way to use the ephemeral disks.
Note that the option for controlling this, ec2_ephemeral_swap_enable,
is not the same as the option (ec2_ephemeralswap_enable) used with the
previous ephemeral-swap script; this change was deliberate to avoid
astonishment for users who upgraded their ec2-scripts package and had
a setting left behind in rc.conf.
I assume the original reason for Subversion's inclusion was to checkout
the base system. But now we use git for that.
Reviewed by: gjb
Sponsored by: Axcient
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35329
When running over a serial line we end up defaulting to 80x24, which is
rather cramped for many dialog boxes and occupies very little screen
space for most modern terminals. Thus, run resizewin -z to set the
terminal size if not already known before starting the installer, just
as we do for csh and sh login shells already in their default dotfiles.
Reviewed by: jhb, gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D34414
This sshd_config keyword was replaced by KbdInteractiveAuthentication in
openssh 8.7, though ChallengeResponseAuthentication is silently accepted
as an alias. However, this means that the code in ec2.conf which
modifies a commented-out line no longer does anything. Apply a minimal
fix.
Reviewed by: cperciva, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34400
This requires two sets of changes. Firstly, for non-FreeBSD, we do not
know where tools are in PATH (and it is likely that some are not in
system directories and have been built as bootstrap tools during the
build), so we should leave PATH alone and trust the user. Secondly,
makefs needs a master.passwd for building images from a METALOG file, so
pass the directory in the image tree to makefs's -N option in order to
pick up a valid FreeBSD master.passwd; this is unnecessary on FreeBSD
(except in the edge case of building an image that refers to users or
groups not present in the host's database, which is unlikely but
technically possible) but harmless so can be done unconditionally.
Reviewed by: brooks, emaste, gjb
Differential Revision: https://reviews.freebsd.org/D34001
This requires a bunch of METALOG mangling to include the files we inject
into the tree. The mkisoimages.sh and make-memstick.sh scripts are now
called with the current directory inside the tree so that the relative
paths in the METALOG match up with the current directory. The scripts do
not require this when not using a METALOG, but for simplicity we always
do so. The Makefile mangles the real METALOG created from the install,
as those files are shared across all uses of the tree, but the shell
scripts create a temporary copy of the METALOG that they mangle as their
tree modifications are specific to that image. We also need to pass -D
to makefs to turn any duplicate METALOG entry errors into warnings, as
we have many (harmless) instances of those.
Whilst dvd1.iso should work, the !NOPKG code will need more work to
support this.
All media will also lack mergemaster and etcupdate trees, since more
work is needed to add -DNO_ROOT modes to them. Users of install media
built this way will have to manually bootstrap them.
Reviewed by: brooks, gjb
Differential Revision: https://reviews.freebsd.org/D33999
Currently the current directory is the parent of the rootfs directory,
but this will change in order to support NO_ROOT builds that use a
metalog manifest, since those need to have the current directory be the
rootfs itself in order for the relative paths to be correct, and we do
not want the non-METALOG case (which passes the directory to makefs) to
pick up leftover temporary .img files from a previous failed build.
Reviewed by: brooks, emaste, gjb
Differential Revision: https://reviews.freebsd.org/D33998
ubldr.bin was obsoleted by our uboot ports last year, so this is
completely unused in the default config (some customers still use
it, but that's not relevant to this script). Don't copy it at all
since it won't be used for re@ produced images.
Sponsored by: Netflix
Reviewed by: kevans, gjb (re@)
Differential Revision: https://reviews.freebsd.org/D34192
It isn't needed and will cause problem when upgrading to a newer release.
Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33878
Now that root uses /bin/sh as the default shell no need to have csh part
of runtime.
Put it in its own package.
MFC after: never
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33471
And put pkg and its keys in it.
It's easier for small image to depend on this package rather than the
larger utilities one.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33458
It's useful for small image to fetch some data but we don't want to
install utilities nor bloat runtime.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33463
There is no reason that this shouldn't be there.
Change the dependency of caroot from utilities to openssl as it's
the only command that it uses not in runtime.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33458
This allow one to install it without having to install FreeBSD-utilities.
While here put some newsyslog.d file in their own package.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33456
This allow one to not install syslogd and use syslog-ng or any other
syslog daemon.
While here put some syslog.d file in their own package.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33455
While here put the periodic files for some utilities in their own
packages.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33454
And put the mtree binary and files in it.
Useful to create small mfsroot using /etc/rc.d/var without
having to install FreeBSD-utilities.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33442
And put the tcp-wrapper utilities in it.
Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33439
YP is less and less used, split them to users have the choice to not
install them.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33441
Disable Duplicate Address Detection in EC2 instances. The networking
configuration in EC2, with IPv6 addresses assigned by DHCPv6 and
host egress filtering, makes "duplicate addresses" impossible.
This speeds up the boot process in EC2 by 2 seconds.
Reviewed by: kp, imp, bz
MFC after: 2 weeks
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D33091
Imports the changes for building official images on Azure Marketplace,
which fulfill the requirements of Azure and FreeBSD cloud images like
disk layout and UEFI for Gen2 VM, along with some minor improvements like
configurations to speed up booting.
"CLOUDWARE" list will be updated after some more collaborations with re
completed.
Reviewed by: re (gjb)
Sponsored by: The FreeBSD Foundation
Technical assistance from: Microsoft
Differential Revision: https://reviews.freebsd.org/D23804
This reduces the FreeBSD boot time by approximately 5 seconds,
roughly equally divided betwenn two factors:
* Disk I/O is faster in the EFI loader since it can perform larger
I/Os. (The BIOS loader is limited due to the use of bounce buffers
in sub-1M memory.)
* The EFI console is much faster than the VGA console.
Note however that not all EC2 instance types support UEFI; as a
general rule the newer instances (based on Amazon's "Nitro" platform)
support UEFI but the older instances (based on Xen) do not.
X-MFC: TBD based on tradeoff between performance and compatibility
Relnotes: yes
Sponsored by: https://www.patreon.com/cperciva
The default boot method for amd64 AMIs is BIOS, but at AMI creation
time a flag can be set to specify that UEFI should be used instead.
This commit adds a variable AMIBOOTMETHOD which, if set to "UEFI",
causes the appropriate flag to be set during AMI creation.
The only boot method supported by EC2 for arm64 is UEFI.
The names of AMIs are also amended to include the boot method; they
now look like "FreeBSD 14.0-CURRENT-amd64-20210915 UEFI".
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
ftp tools aren't that useful nowadays but some might want them.
Create a FreeBSD-ftp package so users have a choice to have
them or not.
Differential Revision: https://reviews.freebsd.org/D31794
vt files for either keyboards and fonts are totally optional
so create a separate package for them.
Differential Revision: https://reviews.freebsd.org/D31797
mlx* are only useful for users who have a Mellanox card.
Create a package for it so users that don't have this card can
avoid having this program.
Differential Revision: https://reviews.freebsd.org/D31795
cxgbetool is only useful for users who have a Chelsio card.
Create a package for it so users that don't have this card can
avoid having this program.
Differential Revision: https://reviews.freebsd.org/D31793
both telnet and telnetd aren't that useful nowadays but some
might want them.
Create a FreeBSD-telnet package so users have a choice to have
them or not.
Differential Revision: https://reviews.freebsd.org/D31791
Reviewed by: emaste
If SSMPREFIX is specified, AMI Ids will be recorded in the SSM
Parameter Store under the name
${SSMPREFIX}/${ARCH}/${FLAVOUR}/${ROOTFS}/${REVISION}/${BRANCH}
where ARCH is "amd64" or "arm64", FLAVOUR is "base" (but may have
other options in the future), ROOTFS is "ufs" (but may have other
options in the future), and REVISION and BRANCH have their normal
meanings.
FreeBSD will be using the public prefix "/aws/service/freebsd",
resulting in SSM Parameter names which look like
/aws/service/freebsd/amd64/base/ufs/14.0/CURRENT
Relnotes: yes
Sponsored by: https://patreon.com/cperciva
MFC after: 2 weeks
This is useful for adding extra packages to the build of an AMI.
For example:
env VM_EXTRA_PACKAGES="zsh" make -C release ec2ami
Approved by: gjb
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Currently pkg(8) will fail to install any package if one is missing, so
make this a loop to prevent one missing package from preventing the rest
from installing. Seen building an AWS AMI for aarch64 on main and
ebsnvme-id is not available in the repo at the moment.
Approved by: gjb
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Per [(1), i.e. test(1), the string comparison operator should be `=`,
not `==` in sh(1) scripts.
No functional change. FreeBSD's test accepts `==` as an alias for `=`
for compatibility with gnu test's `==` extension.
Reviewed by: imp@, gjb@
Pull Request: https://github.com/freebsd/freebsd-src/pull/485
And move all the nfs related commands there.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D30754
Sponsored by: Diablotin Systems
This allows to boot out of the box on the RPI COmpute Module 3 with 32G
of eMMC.
Tested by: imp confirmed .dtb is in the rpi-firmware pkg
Reviewed by: gjb@, imp@
Pull Request: https://github.com/freebsd/freebsd-src/pull/452
Sponsored by: Netflix
While here, fix all links to older en_US.ISO8859-1 documentation
in the src/ tree.
PR: 255026
Reported by: Michael Büker <freebsd@michael-bueker.de>
Reviewed by: dbaio
Approved by: blackend (mentor), re (gjb)
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D30265
This is useful for upgrade and also to make tiny jail so they won't
depend on FreeBSD-utilities (where openssl was packaged before).
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D30081
We do not currently generate armv7 distribution sets, because we don't
build any installer images. However, having such sets available can be
useful for quickly installing a base system, particularly in the case
of creating an armv7 poudriere jail on arm64.
Add a configuration file for the generation of these distribution sets.
Reviewed by: manu, imp, gjb
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D29923
The mangling was present in the initial revision of the script, but its
purpose is not clear. It may have been to avoid defining make(1)
variables with a dash in the name, but this is permitted. Furthermore,
it results in invalid dependency information if a dependency's name
contains an underscore, causing e.g., libcompiler_rt-dev to depend on
libcompiler-rt, and resulting in warnings when installing base system
packages. Remove the mangling.
Reviewed by: manu
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29883
To support -DNO_ROOT work. The top-level installworld target creates a
new METALOG starting with `#mtree 2.0` so it needs to be first, to avoid
overwriting installkernel METALOG entries.
Reviewed by: gjb
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29582
make "vital" a replaceable, which defaults to "false" and only set it for
the main clib, utilities and runtime packages, not their sub-packages
PR: 254174
Differential Revision: https://reviews.freebsd.org/D29224
Recent mkimg changes forces to have partitions given in explicit order.
This is so we can have the first partition starting at a specific offset
and the next ones starting after without having to specify an offset.
Switch the partition in the mkisoimage.sh script so the first one created
is the isoboot one.
PR: 254490
Reported by: Michael Dexter <editor@callfortesting.org
Tested by: Vincent Milum Jr <freebsd@darkain.com>
MFC after: Right now
Sync determining the git count with newvers.sh by adding the
--first-parent argument. This ensures uname(1) reflects the
file name for snapshots.
Reported by: Mark Millard
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
Remove tmpfs size limitation, this breaks make installworld and installation of some packages
Format generated fstab using tabs to make it consistent and readable
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29283
Man pages can be big in total, add an options to split man pages
in -man packages so we produce smaller packages.
This is useful for small jails or mfsroot produced of pkgbase.
The option is off by default.
Reviewed by: bapt, Mina Galić <me@igalic.co>
Differential Revision: https://reviews.freebsd.org/D29169
MFC after: 2 weeks
They aren't needed and produce wrong package comments :
We use to have "runtime-dev package" instead of
"FreeBSD Base System (Development Files)" for example
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D29168
MFC after: 2 weeks
Pass UNAME_r override to make(1) for ports builds when building
ports for another branch.
MFC after: 3 days
MFC with: 0be274d373, 80ab50e1de, c883b6fd8c
Sponsored by: Rubicon Communications, LLC ("Netgate")
truncate(1) is not case-sensitive with regard to setting the size
of a file. makefs(8), however, does not honor upper-case values.
Update release-specific files and the release(7) manual page to
reflect this.
MFC with: 1ca8842f3a
Submitted by: ehem_freebsd_m5p.com (original)
Differential Review: https://reviews.freebsd.org/D28979
Sponsored by: Rubicon Communications, LLC ("Netgate")
This had prevented the bootconfig step from determining if an ESP exists,
resulting in its unconditional setup. On BIOS-booted amd64, this wasn't
harmful, just unnecessary, but it resulted in failed installations on
non-EFI-supporting platforms like powerpc64.
MFC after: 3 days
In followup to 80ab50e1de,
export UNAME_r in Makefile.inc1 instead of Makefile.vm.
MFC after: 3 days
MFC with: 80ab50e1de
Sponsored by: Rubicon Communications, LLC ("Netgate")
Using makefs instead reduces the privileges needed to build VM images,
simplifies the script (no need to copy files to a fresh image at the end),
and improves portability by allowing generation of cross-endian images.
As a result of the last, this patch also adds support for generation of
powerpc64 and powerpc64le VM images.
No other changes to the output. Tested and working for both amd64 and
powerpc64 targets.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D28912
These images only ever worked on Apple Powermacs, which are now a very
old platform, and did so only for a very loose definition of "worked"
(they booted on a small subset of supported machines). Moreover, all
the machines they *did* boot on also would boot from a memstick made
by dd'ing an CD image to a flash drive. Since a flash drive prepared
in this way would also boot all the newer systems we support, the
memstick images were strictly less functional than the CD images, even
for booting from memory sticks.
Reviewed by: jhibbits
MFC after: 1 week
Following 7b1d1a1658, the structure
for the reldoc target has significantly changed as result of the
ASCIIDoctor/Hugo migration. As the release notes related files
on the installation medium are inherently out of date, purge them
entirely.
Discussed within: re, doceng
No objection: re (silence), doceng (silence)
Timeout: 2 weeks
MFC after: 1 week
MFC to: stable/13, stable/12, and stable/11 only
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add PBUILD_FLAGS and UNAME_r overrides to extra_chroot_setup()
to fix building ports for 14-CURRENT builds on 13.x.
MFC after: 3 days
MFC with: c511a5ab53
Sponsored by: Rubicon Communications, LLC ("Netgate")
The 'reldoc' target includes release-related documentation on
installation medium. Since the switch from XML to ASCIIDoctor,
the file locations have moved, and it will take some time to sort
out how this target should work now.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
The ports tree is scheduled to be converted from Subversion to Git
after the currently-scheduled 13.0-RELEASE, so the source of truth
will be Subversion for the ports tree.
Implement a hack specifically for this case.
Sponsored by: Rubicon Communications, LLC (netgate.com)
Hard-code the GITROOT for the ports tree to use cgit-beta
until the ports repository is converted.
While here, remove $FreeBSD$ RCS IDs.
Sponsored by: Rubicon Communications, LLC (netgate.com)
We now have a u-boot port and config.txt for booting on all 64bits
variant of the RPI boards (RPI2v1.1, RPI3* and RPI4*) so use
the new u-boot-rpi-arm64 and the config_arm64.txt files.
Discussed with: karels, kevans
For platforms that don't have any of the memstick, cdrom, or dvdrom
release images (i.e. riscv64), the release-install target will trip up
when invoking md5(1) on the non-existent image files. Skipping this
allows the install to complete successfully.
Add two release flavors for RISC-V. First, the traditional "big-iron"
images, capable of generating distribution sets and VM images. Installer
images won't be built yet, but can be trivially enabled in the future
with the addition of riscv/make-memstick.sh.
Second, a GENERICSD embedded image. I've opted for this instead of
board-specific SD card images as it allows users to just dd the u-boot
they want. The RISC-V hardware ecosystem is still young, so a
configuration for e.g. the new PolarFire SoC Icicle Kit would likely see
very few users.
Reviewed by: gjb
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27045
RISC-V has the same booting requirements as arm64 (loader.efi, no legacy
boot options), so generated images for both architectures have the same
partition layout.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D27044
Since the few existing RISC-V hardware platforms are single board
computers, we can piggyback off of arm/arm64's embedded build support
for generating SD card images.
I don't see a pressing need to change the naming in this file at this
time.
Reviewed by: gjb, manu
Differential Revision: https://reviews.freebsd.org/D27043
Both RPI2 and BEAGLEBONE are still popular and used arm boards.
Both u-boots can coexist as they are named differently and live in the
fat partition.
This leave us with only one image that can be used for both of those
boards and all the other ones supported by FreeBSD provided that you
install the correct u-boot on it.
Reviewed by: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27283
All those board are impossible to buy nowadays and could boot using the
GENERICSD image after putting the correct u-boot on them.
Reviewed by: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27282
Allwinner bootrom have an alternate location for u-boot at 128k.
Work was made recently in u-boot to relocate correctly if loaded from
there.
The advantage of this offset is that we can now use a GPT scheme.
A lot of projects CI can't do FreeBSD tests currently.
The main reason is that the project CI infrastructure is runned on Linux
and that our images aren't modifiable from a Linux hosts.
Add a basic image specific for this case (called BASIC-CI for a lack of a
better name).
The image have no package pre-installed.
It only have a few modification to have dhcp client runned on the default
interface and sshd started with option to be able to log on without a password
as root.
Sponsored by: The FreeBSD Foundation
Reviewed by: re (gjb@)
Differential Revision: https://reviews.freebsd.org/D25598
We create a UFS root filesystem using makefs(8), and later pass it to
mkimg(1) when creating the final image. The correct partition type is
freebsd-ufs; the freebsd parition type is for partitions containing a
BSD disklabel.
Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26987
These images were switched to MBR in r281876 as a way to cope with a
hard-coded partition GUID in QEMU's default EFI firmware. Enough time
has passed that this is no longer a problem; QEMU versions >= 4.0
include a copy of edk2 EFI firmware that can detect the root filesystem
properly. Alternatively, sysutils/u-boot-qemu-arm64 can be used.
Switch back to building these images with a GPT partition table, and
re-enable the swap partition.
Reviewed by: gjb, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26986
The return code of write_partition_layout() doesn't bubble up, so an
invocation of make vm-release for an incorrect/unsupported target will
appear to succeed while make vm-install will fail due to missing
files. This isn't a common point of failure, but is worth handling
properly.
Upgrade this case to print a message to stderr, and exit in place. This
is okay to do since at this point in the execution of mk-vmimage.sh,
cleanup() has already been run.
Reviewed by: gjb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26985
De-duplicate the invocation of mkimg(1). No functional change.
Reviewed by: gjb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26984
At some poing over the last week, the bootx64.efi file has grown
past the 800KB threshold, resulting in being unable to copy it to
the EFI/BOOT directory.
# stat -f %z efiboot.znWo7m
819200
# stat -f %z stand-test.PIEugN/EFI/BOOT/bootx64.efi
842752
The comment in the script that creates the ISOs suggests that 800KB
is the maximum allowed for the boot code, however I was able to
boot an ISO with a 1024KB boot partition. Additionally, I verified
against an ISO from OtherOS, where the boot EFI partition is 2.4MB.
Sponsored by: Rubicon Communications, LLC (netgate.com)
This was originally part of the initial commit, but after discussion in
D26399, I split it out into its own commit after the kernel config file.
Sponsored by: Tag1 Consulting, Inc.
Some IPMI implementations on arm64 are reportedly unable to load our
memstick installer images, but support the older ISO format. Start
generating these for arm64.
Unlike installer ISOs for other platforms, these images are UEFI-only.
Reviewed by: emaste
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26452
Everywhere else we use objects ("scripts", generally) we do sepcify the
optional colon. Be consistent and do the same for directories.
PR: 249273
Submitted by: Martin <martin.jakob gmx com>
MFC after: 1 week
Prior to this commit, EC2 AMIs used a "dual-dhclient" tool which was
launched in place of dhclient and spawned both the base system dhclient
for IPv4 and the ISC dhclient from ports for IPv6.
Now that rtsold supports the "M bit" (managed configuration), we can go
back to having the base system dhclient spawned normally, and provide a
script to rtsold which spawns the ISC dhclient from ports when rtsold
decides that it is appropriate.
Thanks to: bz
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
The FreeBSD base system continues to expand. 4GB is now insufficient;
we passed 3 GB in May 2019; we passed 2 GB in August 2017. Over half
of the disk space used is in /usr/lib/debug/.
Without this change, instances boot but are unusable, since the first
thing which breaks when VM filesystems are too small is the "pkg install"
in the VM building process.
the '-C <directory>' after the subcommand.
Meanwhile, hard-code 'git -C <...> pull' for now.
Reported by: Michael Butler
Sponsored by: Rubicon Communications, LLC (netgate.com)
on the system. Set a null branch/hash in this case, to avoid
undefined GITREV/GITBRANCH variables from falling over in other
areas.
Reported by: many
Sponsored by: Rubicon Communications, LLC (netgate.com)
Makefile.* (cloudware):
- Consistify setting the BUILDDATE for snapshots.
release.conf.sample/release.sh:
- Run 'git clone' in 'quiet' mode.
Makefile.inc1:
- Set BUILDDATE and export the variable.
Sponsored by: Rubicon Communications, LLC (netgate.com)
release.sh:
- Bump the version number.
- Default VCSCMD to '/usr/local/bin/git clone'.
- Rename SVN* variables to GIT* equivalents.
- Remove dead code to inject a trailing '/' between two variables.
- Remove SRC_FORCE_CHECKOUT.
- Exit if the build host does not have devel/git installed.
- Install devel/git in the build chroot(8) for newvers.sh.
release.conf.sample:
- Update sample configuration variables to the git equivalent.
relnotes-search.sh:
- Remove script. It is specifically for use with svn.
Sponsored by: Rubicon Communications, LLC (netgate.com)
- New file. Adds logic to search for the git binary, as well
as determining the branch and revision, used in various
places.
Makefile:
- Remove searching for the svn{,lite} binary.
Makefile.ec2:
- Reduce duplicated code, removing searching for the svn{,lite}
binary, in addition to EC2_SVN{BRANCH,REV}.
- Rename EC2_SVN* with GIT* for consistency.
Makefile.mirrors:
- Remove the SRCBRANCH declaration, replaced with the exported
GITBRANCH variable.
- Update _SNAP_SUFFIX from SVNREVISION to GITREV, and remove
the leading 'r' from it, since it will break git hashes.
- Remove yet another instance of duplicated code to search for
the svn{,version}lite binary.
Sponsored by: Rubicon Communications, LLC (netgate.com)
EFI support is a hard requirement for generating Hyper-V Gen2 VM images.
Reviewed by: gjb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25655
This adjusts freebsd-update.conf and portsnap.conf files in EC2 AMIs to
point at the new AWS-hosted mirror network.
Approved by: re (delphij)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D25498
This reverts the i386 part of r342283, "Rework UEFI ESP generation", and
the followup commit in r342690.
r342283 added an ESP to the i386 memstick image, and as a side effect
made the ESP the active partition, not the bootcode-containing UFS
partition. As a result the i386 memstick images would not boot in
either UEFI or legacy mode - UEFI failed because we do not support i386
UEFI booting, and legacy mode failed because the partition with legacy
bootcode was not active.
The bootcode-containing UFS partition is again the only, and active,
partition.
PR: 246494
Reported by: Jorge Maidana
Differential Revision: The FreeBSD Foundation
-development is long and awkward, and is also inconsistent with prior art
from the Linux world, which uses -dev (Debian) or -devel (Red Hat). Follow
the Debian convention, and similarly for debug info packages.
Also remove redundant pkgbase development tag from includes. We already tag
include files with package=runtime,dev; there is no need to separately tag
them as dev.
Discussed with: bapt
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24139
The ebsnvme-id utility exposes information about EC2 disks -- for
Elastic Block Store volumes, their volume IDs and "linux device
names", and for Instance Store (aka "Ephemeral") disks, their
serial numbers.
The dev_aws_disk rc.d script and associated devd.conf rule maintains
a tree under /dev/aws/disk:
/dev/aws/disk/ebs/<volume ID>
/dev/aws/disk/linuxname/<linux device name>
/dev/aws/disk/ephemeral/<serial number>
which are symlinks to the corresponding nda or nvd devices.
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Since Amazon Elastic File System is only available within AWS, it seems
more appropriate to have this added only in EC2 AMIs rather than
"polluting" non-EC2 images with it.
Reviewed by: gjb
MFC after: 7 days
Relnotes: Amazon EFS filesystems can be automounted by enabling autofs
and placing "/efs -efs" into /etc/auto_master.
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D24791
FreeBSD is in the process of switching from nvd(4) to nda(4) as the disk
device front-end to NVMe. Changing the default in the kernel is tricky
since existing systems may have /dev/nvd* hard-coded e.g. in /etc/fstab;
however, there's no reason to not change the default in HEAD for *new*
systems.
At present I have no intention of MFCing this to stable branches, since
someone might reasonably expect scripts they use for launching and
configuring FreeBSD 12.1 instances to work with FreeBSD 12.2 AMIs, for
example.
Reviewed by: gjb, imp
Relnotes: NVMe disks in EC2 instances launched from 13.0 and later
now show up as nda(4) devices.
Differential Revision: https://reviews.freebsd.org/D24583
Also mark it as config file so if a user changes this file pkg will attempt
to merge the new file upon an update.
device.hints is neither related to runtime or loader but it make more sense
to have it in loader in case some user delete /boot/ and wants to recreate it,
now only two packages are required FreeBSD-bootloader and the kernel package.
While here change where we override the package for files installed in /boot,
this allow us to keep other tags (such as config).
Reported by: pizzamig
Reviewed by: bapt pizzamig emaste
Differential Revision: https://reviews.freebsd.org/D24159
autofs was introduced with FreeBSD 10.1 and is the supported method for
automounting filesystems. As of r296194 the amd man page claimed that it
is deprecated. Remove it from base now; the sysutils/am-utils port is
still available if necessary.
Discussed with: cy
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
We don't produce these anymore as of r356797, remove the remnant in
generate-ucl.sh that accounted for them. This isn't strictly necessary, but
future work is needed for the various packages that can be generated on a
lib build.
Namely, we may produce -development packages for private/internal libs that
should be installed but won't have the base FreeBSD-libfoo pkg to depend on
because it's internal (e.g. liby, libpmcstat, libifconfig) but we want the
headers installed. It may be a better move to just shove these into
-runtime-development instead, but if not then we've just simplified the
cases that need to take private/internal libs into account.
