freebsd-rustdate install

install will go ahead and… well, install, whatever pending fetch or upgrade you have waiting. Note that it won’t proceed if you’re doing an upgrade and haven’t resolved any merge conflicts with resolve-merges.

If you have the proper freebsd-update and system layout config, freebsd-rustdate will setup ZFS boot environments on each invocation, like freebsd-update.

Like freebsd-update, this will just do all the things on a fetch, but will multi-step an upgrade. When doing upgrade, install will first install a new kernel, and expect you to reboot before coming back and running install a second time to install the world. Then expect you to rebuild or reinstall any necessary packages, and run install a third time to remove obsolete shared libraries.

If you’re upgrading your working system, that’s what you want. But if you’re updating a jail or subdirectory, you may want to just go ahead and do it all at once. For that, there’s the --all (-a) argument, to just go ahead and do all the steps in one go.

install accepts a --dry-run (-n) argument to not do any of the steps, but just give a summary of what will happen. This implies the behavior of the --all flag, telling you about all the steps that would be taken, not just the next one.

As further possible optimization, upgrade has a --no-sync (-s) argument to not do a fsync() on the files as they’re installed. This can provide a pretty significant speedup to the process (especially if you have things like the src/ tree installed, which adds up to a ton of tiny files). Of course, it’s also potentially dangerous; if you get a crash partway through the upgrade, you might end up with empty files that you really wish were present (libc.so, say).

If you’re upgrading a jail or subdir, that’s probably perfectly fine. If it blows up partway, you can just try again. On the system you’re trying to boot, it’s rather more dangerous. On the other hand, even with fsync(), a crash in the middle could leave you with half-upgraded stuff that won’t work well, so it’s not “completely safe” vs “totally dangerous” either. Boot environments probably give you more safety. Choosing to take off your seatbelt is your business :)

As of 0.7.0, install also accepts as -j argument to enable multi-threaded parallel install. Without -s this usually gives a speedup similar to what -s would give, since it can hide the fsync() delays. With -sj combined, there’s further gains since you’re using multiple cores and not waiting on hardware. It’s potentially dangerous if problems are encountered, since it won’t stop right away like non-parallel install would.

Depending on how you look at it, using -j alone could be thought of as less safe than -s (since you’d install the rest of the files anyway if one failed), or more safe (since each file is still getting fsync()’d, so you don’t have the worry about empty files).

See Also

If you’re installing, you must have previously done a fetch or upgrade.

You can see what install will do with show-install, with info about merges in show-merges. Outstanding merge conflicts will be resolved with resolve-merges.

You can throw away the info about a pending install with clean.