Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

stand: Flesh out the zfs image creation

Move the mbr non-geli zfs cases to no-priv creation with makefs / mkimg.
Add comments about the weird thing we do for MBR + ZFS + Legacy. Add
comments about other architectures. Still need to think through how to
leverage a completed universe to do all the architectures...

Sponsored by: Netflix

stand: Make makeroot.sh use makefs for ZFS

Start to use makefs for ZFS. This covers the gpt nogeli variants. ZFS
MBR booting is tricky and complicated, so will need some additional
tweaks that makefs/mkimg isn't able to do at the moment. This means that
all gpt nogeli amd64 combinations can be built w/o root.

In addition, tweak the generated qemu.sh files to use stdio for the
console. We grep the output for SUCCESS and report each of the booting
types. Create a all.sh that will run these automatically. These all can
also run w/o root.

In the future, I'll add support for a make univers followed by this
script to create other architectures' tests and/or generate stand tests
for /usr/tests...

Sponsored by: Netflix

stand: Abstract out fstab creation

Now that all the fstabs are the same, abstract it out into a function.

Sponsored by: Netflix

stand: Update GELI UFS cases to use ufs labels

GELI images are created in a different manner than non-GELI
images. Update them to set the label of 'root' on the UFS partition and
use that in fstab. Drop comments about needing to do this, as well as
the 'dev' variable now that it's unused.

Sponsored by: Netflix

stand: Update testing harness to start to use UFS labels

Minor changes to the non-geli UFS targets: migrate to using ufs labels
so we don't need to know the name of the device we booted off of. This
doesn't change the GELI test cass just yet since I've not tested them.
ZFS doesn't need these changes since we don't need to encode the device
for it.

Sponsored by: Netflix

stand: Update testing script for arch retirement

And catch up to changes in booting methods currently supported. Add
riscv.

Sponsored by: Netflix

Speciy the dev in an easily changed variable

Rather than hard coding ada0 everywhere, use ${dev}. Also, set
dev=vtbd0 since both qemu and bhyve support this. More work
should be done to use labels instead for fstab.

qemu scripts likely need adjustment. And we should also
likely generate byhve scripts too.

Merge OpenZFS support in to HEAD.

The primary benefit is maintaining a completely shared
code base with the community allowing FreeBSD to receive
new features sooner and with less effort.

I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.

Work on merging FreeBSD support in to what was
at the time "ZFS on Linux" began in August 2018.
I first publicly proposed transitioning FreeBSD
to (new) OpenZFS on December 18th, 2018. FreeBSD
support in OpenZFS was finally completed in December
2019. A CFT for downstreaming OpenZFS support in
to FreeBSD was first issued on July 8th. All issues
that were reported have been addressed or, for
a couple of less critical matters there are
pull requests in progress with OpenZFS. iXsystems
has tested and dogfooded extensively internally.
The TrueNAS 12 release is based on OpenZFS with
some additional features that have not yet made
it upstream.

Improvements include:
project quotas, encrypted datasets,
allocation classes, vectorized raidz,
vectorized checksums, various command line
improvements, zstd compression.

Thanks to those who have helped along the way:
Ryan Moeller, Allan Jude, Zack Welch, and many
others.

Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25872

For the geli-gpt-zfs test images, both bios and uefi flavors, add a dummy
ufs partition as p2, and put the zfs partition at p3, to test the ability
of the zfs probe code to find a zfs pool on something other than the first
partition.

The zfs module has grown a dependency on zcl_nfs4.ko, so copy it into all
the test images.

Complain and exit the script if the 'make install' phase fails. Also,
there is no need to install any debug files.

Fix install-boot.sh and rootgen.sh UEFI bugs

tools/boot/install-boot.sh was assuming that if a device was passed in,
it should operate on the current system and run efibootmgr etc. to
update the boot manager. However, rootgen.sh passes a md(4) device and
not a fixed disk.

Add a -u option to install-boot.sh to tell it to update the system
in-place and run efibootmgr etc.

Also, source install-boot.sh in rootgen.sh to allow it to find and
call make_esp_file etc. And pass the loader file to make_esp_file instead
of a directory name.

Reported by: ian
Reviewed by: ian,imp,tsoome
Differential Revision: https://reviews.freebsd.org/D19992

Rework UEFI ESP generation

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

Following r335259, don't copy boot1 from the running system for sparc64
either.

also set multicons for tests

Make generated scripts executable.

Revert r336240, which contained unrelated changes accidentally committed.

More little fixes... fix a function name typo (eps vs esp), and cope with
newer versions of gpart that show mbr efi partition types with the name
'efi' rather than as '!239'.

Fix the fstab entries for tests that have an efi partition in slice 1 and
put the rootfs on s2.

Doh! Commit the proper default values, not my local tweaks.

Move the passphrase and iteration count into variables.

This is purely to make it easier to tweak them locally; the machine I have
for testing takes forever to do 50,000 pw strengthening iterations, and
we're not testing the strength of geli's anti-pw-guessing logic here
(especially given that our test passphrase is "passphrase", except that
I tend to tweak that also, to 'x', because typing is hard).

Some day these should be settable as cmdline args. But then, some day this
whole script should probably get a rewrite. :)

Allow making just one flavor of boot-test image based on cmdline args.

Switch to creating UEFI ESPs using loader.efi instead of boot1.efi.
Cope for the fact that laoder.efi, not being boot1, doesn't read
/boot.config by setting boot_serial and force the serial console.

Also add sysctl so we can display the boot method.

Provide a variable, do_boot1_efi, if you want to use boot1 for
testing. But since it's transient, it's just a variable and not
available on the command line.

rootgen.sh: complete all profiles except GELI+MBR (not supported)

This extends the test suite to generate images for every combination of:
amd64: mbr/gpt geli/nogeli ufs/zfs legacy/uefi/both

Except for mbr+geli, which is not currently possible.

Reviewed by: imp (previous version)
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15846

FreeBSD/amd64 requires 256MiB to boot UEFI, 128MB simply doesn't work.
128MiB still works for Legacy booting, however. Go ahead and do 256MiB
for all amd64 boxes, since the number of such boxes < 256MiB is
vanishingly small.

rootgen.sh: Don't copy various bits of the bootcode from the running system

We want to use the versions of the bootcode we just built, rather than
ones from whatever happens to be in /boot on the test machine

These were incorrectly added by me in r334888

Add ZFS+GPT EFI and LEGACY+EFI to rootgen.sh and installboot.sh

Reviewed by: imp (maintainer)
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15700

Change rootgen.sh to use the default ZFS boot environment name

Reviewed by: imp (maintainer)
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15699

Flesh out the creation of sparc64 UFS images. This has only been verified
to yield working images in a native build as rootgen.sh generally doesn't
support cross-testing so far.

Support more images (but still no geli)
Print a qemu line to a shell script to ease testing each image
Start to support multiple architectures (still very green)
Create /etc/rc that echos success and halts the system for better
automation (also include halt)
Create /etc/fstab on a per-boot type to test loader's passing root
to kernel.

This lets me run a test, connect to it with telnet and get either a
timeout, or a report of success.

Sponsored by: Netflix

Use -h -D in preference to -D so that the serial port gets the
interactive console rather than the video port. qemu has issues with X
on my mac at the moment and this is the easiest path forward.

Sponsored by: Netflix

Be a little verbose and list the loader files we're putting on the
drive when making zfs roots as a sanity check for what's on there.

Script to generate minimal boot images for each of the 24 supported
boot images for x86. This will be enhanced to generate all the other
images (u-boot, powerpc CHRP, etc).

At the moment, it's only generating three of them. zfs+gpt+legacy
works with qemu:
qemu-system-x86_64 --drive file=${file},format=raw -serial telnet::4444,server
but the ufs ones still have issues I'm tracking down.

These images are the boot blocks, /boot/loader, a kernel, maybe a
couple of modules, /sbin/init, /bin/sh, /libexec/ld-elf.so, libc.so,
libedit and libncursesw. This is just enough to get to single user. At
the moment, these come from the host system, but should come from
OBJTOP.

At the moment, this requires root to build since the zfs tools require
it (and GELI will too when we add support for that).

Sponsored by: Netflix