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
