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 47d669f10ea3eb92a3783376549728b42c9e22b9)
I got a check inverted in a previous cleanup commit and as a result
partedit was only applying GEOM changes (and generating an /etc/fstab)
if it got an error reading the current GEOM mesh. Instead, it needed
to do those actions if it succeeded in reading the mesh.
The lack of /etc/fstab meant that bsdinstall mount didn't mount
anything in a scripted install.
PR: 273723
Reported by: Andrey Fesenko <andrey@bsdnir.info>
Reported by: Michal Nowak <mnowak@startmail.com>
Reviewed by: cognet, brooks
Fixes: 2309909919 bsdinstall: Handle errors from geom_gettree.
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42236
(cherry picked from commit 5307bbcc038f878b4b3714f03a2c824a0caeba4f)
geom_gettree probably never fails, and if it does there isn't much of
a fallback other than aborting partitioning. However, a few places
were checking the return value and not doing anything with it
triggering a unused-but-set-variable warning. Checking the errors
resolves the warning.
While here, check for errors in other places that weren't checking for
them at all, remove a spurious double call (the second call overwrote
the mesh structure leaking all the pointers from the first), and close
a few resource leaks on error paths.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D40779
The old one triggered a false positive -Warray-bounds from GCC (the
compiler assumed len was always 0), but it was also fragile with
manually computed lengths paired with strcat vs using a string
builder.
Differential Revision: https://reviews.freebsd.org/D40658
Now that pw (hence adduser and the initial install) use /home for
user home directories rather than /usr/home, create a dataset for
/home rather than /usr/home. Update the man page to match.
Reviewed by: rgrimes, markj
Differential Revision: https://reviews.freebsd.org/D40086
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
When not doing tree walks, it is bad for sub-dirs to depend on
parents. Move the generation of opt_osname.h to distextract
and have others that need that depend on it.
In usr.sbin/bsdinstall use SUBDIR_DEPEND_ so tree walking still works.
Reviewed by: obrien
Differential Revision: https://reviews.freebsd.org/D39742
The mirrors list is in sync with the Handbook / Mirrors section [1],
which was refreshed a few months ago. Mirrors removed were not
responding or had duplicated addresses (aliases) with another mirror.
1 - https://docs.freebsd.org/en/books/handbook/mirrors/
Reviewed by: philip (clusteradm)
Approved by: philip
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38014
The variable used for the checklist's default value needs to correspond
to the rc.conf variable as that's what's being parsed to determine them.
In the case of local_unbound it's missing the _enable suffix and thus
always defaults to off on revisit.
Fixes: 58eb9abb31 ("Add a line to the post-installation configuration dialog to enable the local_unbound service.")
There are a few issues here, some of which are hiding others. The first
is that we don't use double quotes around the command substitution so
every word in the conf file is treated as a separate argument to eval,
resulting in spaces being used in place of newlines and thus comments in
the file commenting out the rest of the file, not just to the end of
their line. In particular, we insert one comment just before the dumpdev
entry (the final one in the file) and so we never see dumpdev as set,
and thus set a default value of on for the menu.
The second issue is that, for dumpdev, it takes a value of AUTO not YES
when set, but we don't replace this with on when eval'ing, so then end
up giving AUTO to bsddialog which is interpreted the same as off (which
seems to match GPL dialog). Thus handle AUTO like YES otherwise it will
always appear as unchecked on revisit.
The final issue is that our case-insensitive YES/NO (and now AUTO)
replacements have no word boundaries around them so match the middle of
words too. As it happens this doesn't matter in practice at the moment,
but it could in future; currently the only effect is that it rewrites
moused_nondefault_enable to moused_offndefault_enable, but since this
variable is never read, only written based on moused(_enable) this is
harmless, but we should fix it in case a service comes along in future
that does get affected by it.
This installer option is currently totally useless, as it ends up
creating an ntpd_sync_on_start_enable="YES" entry in rc.conf, not an
ntpd_sync_on_start="YES" entry, as is the correct name. This can also be
noticed by revisiting the services menu, which parses the previously
written rc.conf.services file to set variables governing the default
menu entry values so that selecting OK regenerates the same file, as the
menu entry will use the correct variable name and thus think the entry
was not selected last time, defaulting back to off and losing the
setting.
Thus, add a special case in the loop for this option. The only other
entry that doesn't follow the *_enable pattern is dumpdev (even moused
does, it just also sets a second variable), but that also deviates in
terms of being explicitly set either way and using AUTO rather than YES,
hence why ntpd_sync_on_start follows a different pattern here and is
special-cased rather than introducing a whole new variable that governs
behaviour outside the loop.
Fixes: c153a35bfd ("bsdinstall: replace ntpdate by ntpd_sync_on_start")
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>
MFC after: 1 week
Whilst reboot(8) will block whilst it runs, shutdown(8) does not,
daemonizing instead. This means that we must wait after running it,
otherwise we will exit and cause the system to attempt to go multi-user
in parallel with the shutdown daemon killing init. With the new
multi-console support in the installer, runconsoles will immediately
kill this daemon, racing with the daemon being able to signal init as
desired, and I have seen this race be lost in QEMU with a single CPU. In
the past this wasn't such an issue, since shutdown's daemon puts itself
in a new session group immediately after fork (and the parent doesn't
wait until that has happened, so whilst there's technically a race
condition in there where it could receive a SIGHUP from the death of the
parent's session leader, in practice this is very unlikely to be hit.
This means that the only consequence of this oversight before was that
you might get the beginnings of more console output on the way to
multi-user and thus the console would look a little confusing.
Reviewed by: gjb
Fixes: e4505364c0 ("release/rc.local: Provide option to shutdown after installation complete")
Fixes: a09af1b7fd ("bsdinstall release: Start installer on multiple consoles")
Differential Revision: https://reviews.freebsd.org/D36879
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
This helper binary will run a given command on every on console, as
defined by /etc/ttys (except for ttyv*, where only ttyv0 will be used).
If one of the command processes exits, the rest will be killed. This
will be used by a future change to start the installer on multiple
consoles.
Reviewed by: brooks, imp, gjb
Differential Revision: https://reviews.freebsd.org/D36804
* change current NTP services offered by the FreeBSD Installer;
* no longer offer ntpdate to be enabled and started on boot;
* start offering the option to make ntpd set the date and time on boot itself.
The motivation for this change comes from the ntpdate(8) manpage:
Note: The functionality of this program is now available in the ntpd(8)
program. See the -q command line option in the ntpd(8) page. After a
suitable period of mourning, the ntpdate utility is to be retired from
this distribution.
Approved by: cy (src), dteske (src)
Differential Revision: https://reviews.freebsd.org/D36206
Currently we only set canmount=noauto on the root of the BE, this
change makes it so we set it on all datasets under the BE as well.
Reviewed by: allanjude
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D35422
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
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
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
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
Replace (LGPL) dialog utility with (BSD-2-Clause) bsddialog utility.
Add --hline info because bsddialog requires TAB to switch the focus on
buttons for an inputbox, dialog differs.
Delete f_dialog_inputbox_size() using libbsddialog autosizing.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D35285
bsdinstall(8) has an option to enable moused support.
However, if it is not selected, moused is still started
through the configuration of nondefault devices.
So, automatically add the moused_nondefault_enable="NO"
setting to rc.conf unless moused support is selected.
PR: 227999
Reported by: bcran
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D35193
Override OSNAME to change the name of the OS in the installer.
This is a first step, the shell changes will be separate.
Reviewed by: allanjude
Approved by: allanjude
Differential Revision: https://reviews.freebsd.org/D34878
Sponsored by: Rubicon Communications, LLC ("Netgate")
Devices that cannot be opened are most likely the install media and
should not be listed as destinations.
Reviewed by: allanjude
Approved by: allanjude
Differential Revision: https://reviews.freebsd.org/D34879
Sponsored by: Rubicon Communications, LLC ("Netgate")
