Upgrade

Untested

admin upgrade has not yet been run by the test VM, which installs from the current repositories and has nothing to upgrade.

Run this on the new machine:
admin upgrade

One command for the thing you will do most often, in an order worth not having to remember:

  1. Refuse to start if admin diff reports drift. Upgrading a machine you cannot describe makes it harder to describe. admin save or admin apply first.
  2. pacman -Syu. snap-pac takes a snapshot of / just before the transaction and another just after (see Snapshots).
  3. admin apply, so that anything a package update reset comes back.
  4. List any new .pacnew files.
  5. Say whether a reboot is needed: when the running kernel’s modules are gone from /usr/lib/modules, the kernel was upgraded.

admin upgrade --yes passes --noconfirm to pacman and --yes to aconfmgr.

.pacnew files

When a package updates a configuration file you have changed, pacman keeps yours and writes its new version alongside as <file>.pacnew. That is how new options arrive on Arch – the Pi’s cmdline.txt is one – and pacman never merges them for you. admin upgrade lists them:

(stdout)
New .pacnew files (merge them, then 'admin save'):
  /etc/pacman.conf.pacnew

Compare the two, carry over what you want, and delete the .pacnew:

Run this on the new machine:
sudo vim -d /etc/pacman.conf /etc/pacman.conf.pacnew
sudo rm /etc/pacman.conf.pacnew
admin save

If the file is one the repo provides (under ~/arch/etc/), merge into the repo’s copy instead and admin apply. A .pacnew left lying around is drift too, so admin diff reports it until you deal with it.

What this is not

This is not NixOS. The host repo reproduces your package list and your files, not the versions pacman installed on the day. Two machines built from the same repo a month apart will differ in every package that moved. A snapshot is a way back from a bad upgrade, but not an atomic one. That is the trade the introduction described, made smaller – not made to go away.

// settings
theme:
fx: