Re: make installworld broke / how to recover

On Thu, 22 Feb 2018, at 14:41, tech-lists wrote:
> On Thu, Feb 22, 2018 at 03:10:17AM -0800, Jack L. wrote:
> >maybe try a clean buildworld, update /usr/src to the latest version, rm -rf
> >/usr/obj, then make buildworld && make installworld && make kernel and see
> >if that fixes the issue?
> 
> Is there a documented way of say booting to memstick, starting fixit,
> mounting the zfs from the broken system then building/installing a 
> new world? Is there enough "environment" and utilities to do this on the
> fixit disk?

I can't help from the source/installworld side, but I have a couple of
things to share that may help, apologies if this is already familiar to you.
The email's long enough to be a blog entry...

1. fixing a dead/borked system

I love using mfsbsd[1] by Martin Matuska for this. It's a bootable FreeBSD image
with DHCP support so you can ssh into it from a separate system.

You can then import the zpool and basically do all the cleanup from there.

zpool import -R /mnt -N -f zroot

then mount the datasets you need manually.

2. hacking a semblance of sanity back into the borked current

Try this, after doing a zfs snapshot of your filesystem.

- download the latest CURRENT snapshot and untar kernel + base in place over top
of the above mounted rootfs. Copy back anything "important" from your snapshot like
/etc/ and /boot/loader.conf and the system will probably boot now.

3. use boot environments

I use these all the time, so awesome. basically when you install 11.x the zfs dataset
layout already supports this by default. You can tweak an existing system to fit this
if needed, it's not too hard. Details elided, help available if you need it later on.

install sysutils/beadm-devel and have a go. Briefly, your / is kept in zroot/ROOT/<name>
(called a Boot Environment) and variable data lives outside that namespace, but
overlaid using zfs mountpoints.  You can make multiple copies of these as you go along,
before upgrades, during patches, or major config changes. Real Data like /usr/home,
/var/log or (in my case) /var/db/* are in separate datasets and will always be present
and up to date, irrespective of which boot environment you are currently running under.

For example, I have a 11.1R boot environment, and about 3-4 12.0-CURRENT ones over
the last few weeks, in case something unexpected breaks for me.

At boot time, the loader (thanks Allan Jude IIRC for implementing this) allows you to
choose between those copies so you can simply switch back to the working one and
decide what you want to do with the borked one. see [2] for some really cool tricks
from Michael Dexter about mounting that into bhyve and then "live testing" before
upgrading.


4. beinstall.sh script from Will Andrews

If you're building from source, then you can combine #3 with [3] and have your
next incarnation automatically installed not into your existing working / dataset
but into its own dataset, cloned off your current /, and upgraded, all within the
boot environment. This is so awesome it's changed my world (pun intended), I
install a new CURRENT every 3-4 days now because rolling back is absolutely painless.

I borrowed xmj_at_ [4] tips on using ccache and metamode, which makes incremental
builds pretty quick.
 
I can later on mount the /usr/src and /usr/obj over NFS to other lesser powered
systems like my laptop, and beinstall.sh there too.

LIKE A BOSS.

Here's my current hacky scripts to build world & current, and stash everything into a
boot environment. It works for me, but I'm hardly a build-from-source guru so maybe
that could be improved [5]

[1]: http://mfsbsd.vx.sk/
[2]: http://www.callfortesting.org/bhyve-boot-environments/
[3]: https://svnweb.freebsd.org/base/head/tools/build/beinstall.sh?view=markup
[4]: https://xmj.github.io/articles/sysadmin/builds_ccache_memcached.html
[5]: https://gist.github.com/dch/99a0e3c42e971a08dd922aab20670d7d