product_flavour is embedded in the release package but the
package itself does not insist on a particular flavour other
than having knowledge about the flavour the package was
built for originally. This is ok and direct crypto deps
seem to have failed to produce reliable upgrade / sidegrade
results in recent tests anyway.
Long story short: find out the real crypto flavour installed
from the OpenSSL binary or fall back to the metadata if said
binary cannot be found.
Otherwise we try to unload when it's there. Logic was
correct but -b assumtion was incorrect as we do not touch
drivers there or require any pool listing.
/dev/zfs/pool does not exist so we can do a "zfs/pool" input
in alignment with gmirror and graid inputs. Move the probing
after zfs load to be able to unload again also.
If the user's existing subnet isn't 192.168.1.1/xx, then telling the user to use this IP will fail. So tell the user how to set a different IP after reboot, rather than just telling them to use an IP that won't work for them.
Kept short this time - 1 line only :)
Also edited wording re certificate, to be clearer about this as well, by starting with what they will actually see (*"Your browser may..."* rather than *"You might need to..."*). Added just 1 line there as well.
Sorry for these - hopefully not overdoing it. (I'm a fan of making life fun for newcomers, and install is where newcomers first see if a thing works for them!) Perhaps they can be squashed down to save text space. If so please do.
For now only trigger on an explicit "zpool" input, because
otherwise we have to load ZFS earlier to probe for a particular
pool. There is no nice way to list all pools available for
input, at least not in a single, script friendly line per pool.
PR: https://github.com/opnsense/bsdinstaller/issues/12
The funny thing is su -m foobar -c "sh -c '$cmd'" could be as
short as su -m foobar -s /bin/sh -c "$cmd" but why bother selecting
a shell when you need to rely on a proper root shell to be set?
People ask for this sporadically, so we should weave this back
in a way that doesn't break the ncurses view and properly sets
up loopback when needed this early.
We have successfully decoupled rc.installer from other components
so now we can merge both utilities. We use opnsense-installer for
user support, which is easier to invoke and remember.
".ext" came to be because dhclient-script from BSD is also under sbin/,
but since we always explicity use this one just move it to a neutral
location and point to it.
Simplifies and alignes the code, although that is a backwards-
incompatible change that should never have happened. Still a
few things to do and extensive testing.
