partitions of types other than "freebsd-boot" (in particular, "efi").
This allows the removal of some nasty hacks for supporting PowerPC systems,
in particular aliasing freebsd-boot to apple-boot on APM and an IBM-specific
code on MBR.
This changes the installer to use the correct names, which also breaks a
degeneracy in the meaning of "freebsd-boot" that allows the addition
of support for some newer IBM systems that can boot from GPT in addition to
MBR. Since I have no idea how to detect which those systems are, leave
the default on IBM PPC systems as MBR for now.
an embedded newline appearing within the options string surrounded by
double-quotes. Rework the logic that goes into setting dataset options on
the root pool dataset while we're here -- added two new variables (which
can be altered via scripting) ZFSBOOT_POOL_CREATE_OPTIONS and also
ZFSBOOT_BOOT_POOL_CREATE_OPTIONS for setting pool/dataset attributes at
the time of pool creation. The former is for setting options on the root
pool (zroot) and the latter is for setting options on the optional separate
boot pool (bootpool) implicitly enabled when using either GELI or MBR. The
default value for the root pool variable (ZFSBOOT_POOL_CREATE_OPTIONS) is
"-O compress=lz4 -O atime=off" and the default value for separate boot pool
variable (ZFSBOOT_BOOT_POOL_CREATE_OPTIONS) is NULL (no additional options
for the separate boot pool dataset).
Reviewed by: allanjude
MFC after: 7 days
X-MFC-with: r266107-266109
It starts off being used to track the grammar for the number of disks
(singular vs plural) and then it is reused as the list of available disks.
Replace the variable with disks_grammar and move 'disk' and 'disks' to
msg_ vars so they can be translated in the future.
Submitted by: Allan Jude <freebsd@allanjude.com>
Reviewed by: roberto
MFC after: 2 weeks
Sponsored by: ScaleEngine Inc.
Set compress=lz4 for the entire pool, removing it from the individual
datasets
Remove exec=no from /usr/src, breaks the test suite.
Submitted by: Allan Jude <freebsd@allanjude.com>
Reviewed by: roberto
MFC after: 2 weeks
Sponsored by: ScaleEngine Inc.
encryption for swap, and optional gmirror for swap (which can be combined)
Submitted by: Allan Jude <freebsd@allanjude.com>
Requested By: roberto
Sponsored By: ScaleEngine Inc.
MFC after: 2 weeks
a sysctl to determine what firmware is in use. This sysctl does not exist
yet, so the following blocks are in front of the wheels:
- I've provisionally called this "hw.platform" after the equivalent thing
on PPC
- The logic to check the sysctl is short-circuited to always choose BIOS.
There's a comment in the top of the file about how to turn this off.
If IA64 acquired a boot1.efifat-like thing (probably with very few
modifications), the same code could be adapted there.
GEOM support (thereby adding GEOM support to the disk selection
menu of bsdinstall(8)'s `zfsboot' module updated herein).
MFC after: 1 week
X-MFC-with: 264840
that the slightly older dialog(1) requires --separate-output when using the
--checklist widget to force response to produce unquoted values (whereas in
stable/10 --checklist widget without --separate-output will only quote the
checklist labels in the response if the label is multi-word (contains any
whitespace).
Since these enhancements (see revisions 263956 and 264437) were developed
originally on 10, the --separate-output option was omitted. When merged to
stable/9, we (Allan Jude) and I found during testing that the "always-
quoting" of the response was causing things like struct interpolation to
fail (`f_struct device_$dev' would produce `f_struct device_\"da0\"' for
example -- literal quotes inherited from dialog(1) --checklist response).
To see the behavior, execute the following on stable/9 versus stable/10:
dialog --checklist disks: 0 0 0 da0 "" off da1 "" off
Check both items and hit enter. On stable/10, the response is:
da0 da1
On stable/9 the response is:
"da0" "da1"
If you use the --separate-output option, the response is the same for both:
da0
da1
So applying --separate-output on every platform until either one of two
things occurs 1) dialog(1,3) gets synchronized between stable/9, higher or
2) we drop support for stable/9.
MFC after: 3 days
Reviewed by: Allan Jude
and finish the job. ncurses is now the only Makefile in the tree that
uses it since it wasn't a simple mechanical change, and will be
addressed in a future commit.
NB: If the zfsboot variables ($ZFSBOOT_*) are set, a script is
assumed to want zfsboot module instead of scriptedpart module.
Submitted by: Loïc Brarda <loic.brarda@cern.ch>
Reviewed by: nwhitehorn@
MFC after: 3 days
commit c1acf022c533c5ae27e0cd556977eafe3f5959eb
Author: Brooks Davis <brooks@one-eyed-alien.net>
Date: Fri Jan 17 21:46:44 2014 +0000
Add an option WITHOUT_NCURSESW to suppress building and linking to
libncursesw. While wide character support it useful we'd like to
only need one ncurses library on embedded systems.
MFC after: 4 weeks
Sponsored by: DARPA, AFRL
in the one-line comment associated with the dumpdev setting was not present
for the case where the user deselects the dumpdev service (restoring pre-
r256348 behaviour.
MFC After: 3 days
only allows basic username/password config, and does not provide the
ability to set any of the other WPA options. Regardless, this is
generally sufficient to associate.
Perhaps in the future this could allow full configuring (e.g. being able
to set "anonymous identity", and perhaps some of the more obscure WPA
options), though perhaps that will better belong in bsdconfig when that
grows wlan config ability.
MFC after: 1 week
location of /etc/rc.local on the install media is more appropriate as it
knows serial vs. non-serial and can also do the change earlier (so that
even the initial Install dialog can benefit from the change).
MFC after: 3 days
installation to 3-4+ (depending on vdev type) vdevs would result in odd
error messages where the zpool `create' command appeared to repeat itself
(an artifact of printf when you supply too many arguments -- caused by
neglecting to properly quote the multi-word expansion of $*vdevs when
creating the pool(s)). Example error below (taken from bsdinstall_log):
DEBUG: zfs_create_boot: Creating root pool...
DEBUG: zfs_create_boot: zpool create -o altroot=/mnt -m none -f "zroot" \
ada0p3.nop ada1p3.nopzpool create ada2p3.nop "ada3p3.nop"
DEBUG: zfs_create_boot: retval=1 <output below>
cannot open 'ada1p3.nopzpool': no such GEOM provider
DEBUG: Running installation step: hostname
rm: /tmp/bsdinstall_etc/fstab: No such file or directory
The two lines are unrelated, and the rm is spurious. Let's add `-f' to
that rm(1) so it doesn't confuse us when debugging an install.
MFC after: 3 days
should not have used DIALOG_CANCEL because dialog.subr wasn't included to
define it. The effect of the error was that you could not cancel the
partition dialog. Discovered by checking bsdinstall_log for something else.
MFC after: 3 days
required in such a case). But don't prevent the user from pointing the
gun at his/her foot -- you can disable 4k alignment after enabling geli).
MFC after: 3 days
and subsequent headaches caused by multiple pools with the same name.
Specifically, blast away any labels on the designated swap partition.
Problem was when you install to a given layout *with* swap and then turn
around and re-install the same layout *without* swap (we weren't doing a
labelclear for the swap device, so would end up with an "UNAVAIL" status
zroot pool that may only exist in the pool cache).
MFC after: 3 days
+ For GPT, always provision zfs# partition after swap [for resizability]
+ For MBR, always use a boot pool to relialy place root vdevs at EOD
NB: Fixes edge-cases where MBR combination failed boot (e.g. swap-less)
+ Generalize boot pool logic so it can be used for any scheme (namely MBR)
+ Update existing comments and some whitespace fixes
+ Change some variable names to make reading/debugging the code easier
in zfs_create_boot() (namely prepend zroot_ or bootpool_ to property)
+ Because zroot vdevs are at EOD, no longer need to calculate partsize
(vdev consumes remaining space after allocating swap)
+ Optimize processing of disks -- no reason to loop over the disks 3-4
separate times when we can logically use a single loop to do everything
Discussed on: -stable
MFC after: 3 days
+ De-obfuscate debugging to show actual values
+ Change graid(8) syntax; s/destroy/delete/ [destroy is not invalid syntax]
+ Log commands that were previously quiet
+ Added some new comemnts and updated some existing ones
+ Add missing local for `disk' used in zfs_create_boot()
+ Use $disks instead of multiply-expanding $* in zfs_create_boot()
+ Pedantically unset variable holding geli(8) passphrase after use
+ Pedantically add double-quotes around zpool names and zfs datasets
+ Fix quotation expansion for zpool_cache entries of loader.conf(5)
+ Some limited whitespace changes
MFC after: 3 days
https://communities.vmware.com/thread/107230https://communities.vmware.com/docs/DOC-11677
Basically, ignore the ``function 62'' and ``function 63'' interpretations
of the left/right command key when we're in the lengthiest portion of the
installation (initiated by the `auto' module).
The net effect is that you can now (once you've started the installer from
the media) escape the VM without prematurely terminating the current action
due to spurious escape sequence.
MFC after: 3 days
===
DEBUG: Running installation step: services
local: Not in a function
/usr/libexec/bsdinstall/services: cannot create : Read-only file system
/usr/libexec/bsdinstall/services: /tmp/bsdinstall/etc/rc.conf.services: \
Permission denied
===
The `local: Not in a function' is obvious, and was introduced by myself in
SVN revision 256348.
The latter two are caused by the attempt to use "\" to continue the line
after using the ">>" redirect. This appears to attempt to write a file with
the name " " in the current directory and subsequently attempts to execute
the file that was originally intended for writing (which is not executable;
hence the `Permission denied'). That was introduced in SVN r228192 about
2 years ago, apparently unnoticed until I started going over the debug
outputs very carefully.
MFC after: 3 days
after attempting to install to encrypted ZFS root (caused by a typo in a
variable name -- ZFSBOOT_BOOT_FSNAME -> ZFSBOOT_BOOTFS_NAME).
MFC after: 3 days
