Upgrade
admin upgrade has not yet been run by the test VM, which installs
from the current repositories and has nothing to upgrade.
admin upgrade
One command for the thing you will do most often, in an order worth not having to remember:
- Refuse to start if
admin diffreports drift. Upgrading a machine you cannot describe makes it harder to describe.admin saveoradmin applyfirst. pacman -Syu. snap-pac takes a snapshot of/just before the transaction and another just after (see Snapshots).admin apply, so that anything a package update reset comes back.- List any new
.pacnewfiles. - 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:
New .pacnew files (merge them, then 'admin save'): /etc/pacman.conf.pacnew
Compare the two, carry over what you want, and delete the .pacnew:
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.
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.