pkg_add has been gone since 2013(?). Refer to pkg(8) instead.
Sponsored by: The FreeBSD Foundation
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D44946
(cherry picked from commit ad31d47642)
Only set a default value of 1 if the shell variable is unset. This allows
installer scripts to disable the variable.
PR: 274513
Reported by: Albin "a12l" Otterhäll <bugs.freebsd.org@a12l.xyz>
Differential Revision: https://reviews.freebsd.org/D42319
(cherry picked from commit de82aed119)
Currently we just strip the .txz of the dist name (and add a status_
prefix) to get the shell variable name for its status, but this doesn't
give a valid result for dists like base-dbg, kernel-dbg and lib32-dbg,
or even kernel.KERNCONF (or, combining the two, kernel.KERNCONF-dbg). As
a result, four things go wrong for such dists:
1. If there is a dot and/or a dash in the name, writing to the variable
fails and spits an error out on stderr to the log
3. If there is a dot in the name before any dash, the syntax is always
invalid, reading the variable fails, spits an error out on stderr to
the log, the result is the empty string and that is interpreted as
being 0%
2. If there is a dash in the name before any dot, and there is a dist
whose name is the substring up to that first dash, and it has already
had its status written to, reading the variable instead reads that
dist's variable and so the status of that dist is displayed instead
3. If there is a dash in the name before any dot, and either there is
not a dist whose name is the substring up to that first dash or there
is such a dist but it has not already had its status written to,
reading the varaible instead results in the substring after the first
dash, including any additional string expansion syntax that follows
(i.e. ${status_kernel-dbg:--11}, the expression used to read the
variable, is interpreted as reading status_kernel with a default
value of "dbg:--11")
For example, in a default install with base, kernel, kernel-dbg and
lib32, the following sequence of displays happens:
1. base is In Progress, kernel is Pending, kernel-dbg is 0% (what shows
for the garbage input "dbg:--11") and lib32 is Pending
2. base is Passed, kernel is In Progress, kernel-dbg is In Progress
(since kernel has now had its status written to) and lib32 is
Pending
3. base is Passed, kernel is Passed, kernel-dbg is Passed (again, since
that is the status of kernel, despite that kernel-dbg is being
verified at this point) and lib32 is Pending
4. base is Passed, kernel is Passed, kernel-dbg is Passed and lib32 is
In Progress
Fix this with a crude encoding scheme. More special characters can
easily be added if needed in future.
Note that, prior to bsddialog being used (and thus for branches this is
MFC'ed to where dialog is still used), the same problem existed but
displayed slightly differently due to a combination of different default
values and different behaviour for unintended inputs.
Fixes: b70047d413 ("Add generation of an installation manifest containing SHA256 checksums as ...")
MFC after: 1 week
(cherry picked from commit 47d669f10e)
fetchmissingdists naturally sets BSDINSTALL_DISTDIR to a directory in
the new filesystem that it can write fetched distfiles to. As a result,
BSDINSTALL_DISTSITE was incorrectly set to the scratch space on /mnt for
the call to distfetch when grabbing local distfiles, and it would
subsequently fail.
Switch to using the copy of BSDINSTALL_DISTDIR that we stashed off
coming into fetchmissingdists; this one is in-fact set to the path where
the local distfiles are stored.
Patch suggested by jrtc27.
Reported and tested by: Daniel O'Connor <darius dons net au>
(cherry picked from commit 12b92f3ed8)
If installing from the DVD, mount its packages in the chroot at
/dist/packages. That way they'll be accessible to an install script.
MFC after: 2 weeks
Sponsored by: Axcient
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D35330
(cherry picked from commit 6a02539959)
If the ZFSBOOT_DISKS variable is set to one or more disk names, then
those disks should be preselected in the disk menu. However, the code
wasn't correctly setting the variable, leaving all disks unselected.
MFC after: 2 weeks
Sponsored by: Axcient
Reviewed by: dteske
Differential Revision: https://reviews.freebsd.org/D35331
(cherry picked from commit caf73e5857)
Fix a memory leak from caf73e5857
Don't shadow an already-local variable with another local declaration.
Reported by: dteske
MFC after: 13 days
MFC with: caf73e5857
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D35331
(cherry picked from commit 77d678b7a4)
Otherwise, boot will hang if the numbering of disks has changed since
initial install.
MFC after: 2 weeks
Sponsored by: Axcient
Reviewed by: brd
Differential Revision: https://reviews.freebsd.org/D35309
(cherry picked from commit 7919c76dbd)
This reverts commit 020f411255.
Because now ASLR is enabled by default for 64-bit architectures
and the purpose of the installation menu is to allow choosing
additional 'mitigation'/'hardening' options that are originally
disabled, remove the ASLR knob from bsdinstall.
Discussed with: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
(cherry picked from commit bf410c6eda)
When running zpool export first, boot/efi and dev is still mounted so
zpool export fails. By running bsdinstall umount first the pool can be
cleanly exported.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D35114
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC After: 3 days
(cherry picked from commit 450b4ac23c)
Throughout the bsdinstall script fd 3 is used by f_dprintf (set through
$TERMINAL_STDOUT_PASSTHRU). By closing file descriptor 3 here, the
final f_dprintf "Installation Completed ... does not work anymore.
By putting the code into a subshell, file descriptors can be edited
without interference with the calling script.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D35113
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 3 days
(cherry picked from commit 1f7746d81f)
If one install FreeBSD on multiple disks (say 13 and CURRENT) the first created
pool will always be used.
Prompt the user for a new pool name if we detect that the default or supplied one
already exists.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33331
(cherry picked from commit 9935b0e8ea)
If one install FreeBSD on the same machine multiple times in a row or
on different harddrive they have a lot of 'FreeBSD' efi boot entries added.
With this patch we now do :
- If there is no 'FreeBSD' entry we add one like before
- If there is one or more entries we ask the user if they want to delete
them all and add a new one
- If they say yes we do that
- If they say no we prompt them an inputbox so they can enter a different
entry name if they want, it defaults to 'FreeBSD'
Reviewed by: bapt, imp
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33330
(cherry picked from commit 40c928e7b8)
It's required to specify a default boot option in order to make
petitboot's autoboot feature work.
Tested on Raptor Blackbird
Reviewed by: imp, luporl
MFC after: 2 days
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D32838
(cherry picked from commit b6644f529c)
This is a follow-up to 2697622687,
which fixed 2 out of 3 broken uses of the mirrorselect script.
Reviewed by: emaste
Approved by: emaste (src)
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D32927
(cherry picked from commit 4042b356a0)
After 34766aa8cb we are mounting and
unmounting devfs elsewhere already.
Reviewed by: nwhitehorn
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D30877
(cherry picked from commit b50db44f02)
The bsdinstall script target did not have the infrastructure to fetch
distfiles from a remote server the way the interactive installer does
on e.g. bootonly media. Solve this by factoring out the parts of the
installer that deal with fetching missing distributions into a new
install stage called 'fetchmissingdists', which is called by both the
interactive and scripted installer frontends.
In the course of these changes, cleaned up a few other issues with
the fetching of missing distribution files and added a warning if
fetching the MANIFEST file, which is used to verify the integrity of
the distribution files. We should at some point add cryptographic
signatures to MANIFEST so that it can be fetched safely if not present
on the install media (which it is for bootonly media).
Initial patch by: Vinícius Zavam
PR: 255659, 250928
Reviewed by: dteske
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D27121
(cherry picked from commit 40923b0c81)
Unlike attended installations, scripted installs did not mount non-ZFS
partitions when ZFS root (via zfsboot) was selected. Since this included
the ESP, the EFI loader was not installed. Copy logic from the
attended-install path to make this work.
PR: 255824, 255081
MFC after: 1 week
Obtained from: Mark Huizer
(cherry picked from commit 34766aa8cb)
Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to
extract a directory at that point post-mount when the system is installed.
Normally, this is fine, since tar can happily set whatever properties it
wants. For FAT32 file systems, however, like the ESP, tar will attempt to
set mtime on the root directory, which FAT does not support, and tar will
interpret this as a fatal error, breaking the install (see
https://github.com/libarchive/libarchive/issues/1516). This issue would
also break scripted installs on bare-metal POWER8, POWER9, and PS3
systems, as well as some ARM systems.
This patch solves the problem in two ways:
- If stdout is a TTY, use the distextract stage instead of tar, as in
interactive installs. distextract solves this problem internally and
provides a nicer UI to boot, but requires a TTY.
- If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude
boot/efi from tarball extraction and then add it by hand. This is a
hack, and better solutions (as in the libarchive ticket above) will
obsolete it, but it solves the most common case, leaving only
unattended TTY-less installs on a few tier-2 platforms broken.
In addition, fix a bug with fstab generation uncovered once the tar issue
is fixed that umount(8) can depend on the ordering of lines in fstab in a
way that mount(8) does not. The partition editor now writes out fstab in
mount order, making sure umount (run at the end of scripted, but not
interactive, installs) succeeds.
PR: 254395
Approved by: re (gjb)
Reviewed by: gjb, imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D29380
(cherry picked from commit c2f16c595e)
images.
Per hier(7), the ESP will be mounted at /boot/efi. On UFS systems,
any existing ESP will be reused and mounted there; otherwise, a new one
will be made. On ZFS systems, space for an ESP is allocated on all disks
in the root pool, but only the partition actually used to boot is set up
and mounted.
This makes future upgrades of the EFI loader easier (upgrade scripts can
just change /boot/efi) and also greatly simplifies the parts of the
installer involved in initialization of the ESP. It also makes the
installer's behavior correspond to the documentation in hier(7).
Reviewed by: imp, tsoome, bdragon
Approved by: re (gjb)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D28897
(cherry picked from commit 0b7472b3d8)
(cherry picked from commit 2c26d77d98)
(cherry picked from commit e77cf2a4ab)
(cherry picked from commit e70eb40271)
Reduce copy-paste and use a more typical construct.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D28417
(cherry picked from commit fbc57e2df9)
Make the installer more useful, by allowing it to create a bootable
installation. Also, enable the menu option for ZFS-on-root.
Like arm64, RISC-V boots by UEFI only, so arm64's partedit
implementation is renamed and shared among the two platforms.
Reviewed by: gjb
(cherry picked from commit 7b08a307e8)
If the installer is creating a new ESP, then this directory will not
exist and the subsequent cp will fail silently. This is usually of no
consequence if /efi/freebsd/loader.efi is set up correctly.
Reviewed by: imp
(cherry picked from commit 676b7d077c)
Too many version of UEFI firmware (so far only confirmed on amd64)
don't really support efibootmgr selection of boot. That's the most
reliable, when it works, since there's no guesswork. However, many do
not save, unmolested, the variables that efibootmgr sets, so as a
fallback we also install loader.efi as bootXXX.efi (where XXX is
either aa64 or x64) if it doesn't already exist in /efi/boot on the
ESP. The standard only defines this for removable devices, but it's
almost ubiquitously used as a fallback. Many BIOSes implement a drive
selection feature that takes over the efibootmgr protocol, rendinering
it useless (either generally, or for those vendors not on the short
list). bootxxx.efi works around this. However, we don't install it
unconditionally there, as that breaks some popular multi-boot setups.
MFC After: 1 week
Differential Revision: https://reviews.freebsd.org/D26428
Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall.
All these return NXDOMAIN when trying to resolve them.
Reviewed by: emaste
Approved by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D26535
As of r365829, any given base distribution set will now include the /etc/ssl
symlinks that this rehash would've otherwise installed. This extra step is
no longer required.
MFC after: 1 week
X-MFC-With: r365837
If certctl is installed on the system we're configuring, do a certctl
rehash.
Note that certctl may not be present if the world we've installed was built
either WITHOUT_OPENSSL or WITHOUT_CAROOT. In this scenario, we don't
currently see if the host has a certctl as this may be an indication that
the system *shouldn't* have certs installed into /etc/ssl.
Reviewed by: allanjude, dteske
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D24640
Includes commentary of when ZFS works well by default (>= 8GB RAM),
and where to go for information on ZFS tuning if required.
Also hoist the options text to the top of script as variables
(will help with future international translations).
Reviewed by: philip, dteske, karels, imp, emaste
Approved by: rgrimes
Differential Revision: https://reviews.freebsd.org/D23224
Pass the list of user selected disks from zfsboot to bootconfig so that
the latter doesn't rely on ESP autodetection that apparently fails for
some cases, e.g. memstick installation with nvme (boot) and sata drives.
While here, fix printing of debug messages in bootconfig.
Reviewed by: bcran, imp, tsoome
Differential Revision: https://reviews.freebsd.org/D21930
installer when installing the system on a ZFS root filesystem.
For arm64, zfs_load="YES" does not add opensolaris.ko as a kld
dependency, so add it explicitly to prevent boot-time failures
out-of-box.
PR: 240478
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
When using a gmirror, entries in /dev can be removed. So instead of using
kern.disks, get the list of disks from "gpart status -sg" instead.
We assume that any 'efi' partition that can't be mounted as msdosfs should
be used as an ESP. However, the ESP on the CD/DVD can't be mounted read-write
and so was being treated as if unformatted. Try the mount as read-only
instead, to catch cases like this.
Relnotes: yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18645
Currently, the installer uses pre-created 800KB FAT12 filesystems that
it dd's onto the ESP partition.
This changeset improves that by having the installer generate a FAT32
filesystem directly onto the ESP using newfs_msdos and then copying
loader.efi into /EFI/freebsd.
For live installs it then runs efibootmgr to add a FreeBSD boot entry
in the BIOS.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D17947
