Hello. Please critique how I’m updating / maintaining my new Arch installation so I can fix anything I’m doing wrong. This is mostly what I could gather from the Arch wiki tailored to my system. I think I know what I’m doing - but as I’ve often learned, it’s easy to misunderstand or overlook some things.
Step 1: perform an incremental full system backup so I have something to restore if the update borks anything. I’ve chosen to use the rsync command as laid out on the wiki:
sudo rsync -aAXHv --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /media/linuxhdd/archrsyncbackup
I have a large hdd mounted as a secondary drive under /media/linuxhdd. It is configured to automatically mount from fstab using uuid. Both my root drive and that hdd are formatted ext4. I’m not using the -S option because I don’t think I’ll be using virtual machines (I have other hard drives I can make bootable). --delete is used so I maintain one current set of files for restore purposes. This keeps the copying and transfer time to a minimum. (I maintain disk images offline with a different tool - this is simply one local copy for easy restoration purposes)
Step 2: Check the Arch wiki - follow instructions for any manual steps
Step 3: once every 1-2 months, update the mirror list using reflector
sudo reflector --protocol https --verbose --latest 25 --sort rate --save /etc/pacman.d/mirrorlist
This should sort the fastest 25 mirrors into mirrorlist. Remember to use the -Syyu option in step 6 if this step was done
Step 4: Clean the journal
sudo journalctl --vacuum-time=4weeks
This should keep 4 weeks of files.
Step 5: Clean the cache
sudo paccache -r
This should keep no more than 3 versions laying around. Once and a while, I can clean out all uninstalled packages with -ruk0 options instead.
Step 6: Upgrade Arch packages with pacman
sudo pacman -Syu
I need to watch for pacnew and pacsave files and deal with them (although I haven’t seen any yet)
Step 7: Review the pacman log
nano /var/log/pacman.log
This should tell me about any warnings, errors, instructions, or other things I need to deal with.
Step 8: Remove Orphans
pacman -Qtdq | sudo pacman -Rns -
This could be recursive and needs to be run more than once. Instead, I’ll just run it once every time I update. This should keep things cleaned out.
Step 9: Update AUR packages
Check the build scripts to make sure the package hasn’t been taken over and that it won’t run anything funny.
yay -Sua
This should update just the AUR packages
Step 10: Remove AUR orphans
yay -Yc
The wiki says this “removes unnecessary dependencies” which I believe means AUR-only orphan packages.
Step 11: Reboot
reboot
Step 12: Update flatpaks from the GUI (Gnome–>Software–>Updates)
Any mistakes? Suggestions?
Thanks!
So yeah. If I needed a 12 step process to update my system it would still run kernel 4 :D (I’m lying of course) but i really don’t do as much as you and I don’t do more than necessary manually. Basically I run 2 commands to update:
update
which runs the update process more below.clean
which removes orphans and cleans the cache
So
update
is the alias where the magic happens and it does the following:- It runs
sudo pacman -Syu
checking with the Informant hook if there are any unread news, if so it stops the update. Otherwise it just runs through it. - Then it runs
pacdiff
to check if any config files changed (I ran into an issue with that before where I didn’t check properly and suddenly couldn’t login anymore. - Then, if flatpak is installed it will also update all flatpaks.
So my only manual intervention is “accepting” the news if there are any. Accepting the updates. And (of necessary) merging the pacnews. This way I have kept a fresh and stable system for a couple of years now.
I just run ‘paru’.
Looks interesting and comprehensive though, a few things I should probably implement.
Just so that you have an additional data point, here’s how I do it.
I run a backup first, using
borg-backup
. I usedrsync
in the past, thenrsnapshot
and now borg since it allows for compressed incremental backups, diffing on the “chunk” level, meaning I won’t backup the entirety of a modified file again and safe a lot of space.I used
yay
before, but like you I didn’t want to go into it blindly and do some modicum of sanity-checking the PKGBUILD for changes beforehand. Since it wasn’t obvious on what would be the best way of usingyay
for doing this, I asked around on the ArchLinux Forum, and ultimately decided to try one of the simpler tools suggested in the Arch Wiki,aurutils
.After setting it up (the author helped me migrate), I now use it as follows:
aur repo --upgrades
: Searches for new versions of aur packages and displays themaur sync --upgrades --no-build
: Performs a git-pull under~/.cache/aurutils/sync
and opensvifm
so that I can look at a diff of the PKGBUILD and all the other changes in the affected directory.aur sync --upgrades --no-view
: Builds the package. It is now available as part of the custom (local) repository used only for aur packages, but hasn’t been upgraded yet. That is, apackage.tar.gz
or whatever has been created and put into~/.cache/aurutils/sync/
, where thePKGBUILD
resides as wellsudo pacman -Syu
: Upgrades all packages from all repositories, including the ones from the custom repository
I won’t argue pro or against one aur helper or the other, but I feel like I have a little more insight about what happens under the hood since I made the switch. That being said, in the very beginning, I managed aur packages manually. This works also, but at some point became too tedious for my taste. I am happy with the semi-automatic approach I am using now.
You can update flatpaks by running
flatpak update
.You can automate updating the mirrorlist by enabling reflector.service or reflector.timer.
How often do you do all this?
How long does it take?you can automate some parts of that away or can be combined
most AUR helper will basically invokepacman -Syu
internally before actually upgrading any AUR package (as otherwise this can lead to issues)
yay in particular can just be called viayay
(no arguments) which is an alias ofyay -Syu
Point 3: reflector.timer comes with reflector now and runs weekly by default, you need to configure and enable it though
https://wiki.archlinux.org/title/Reflector#systemd_timerPoint 4: you can restrict the journal size to much smaller than it is by default (10% of the partition size OR maximum 4 GB): https://wiki.archlinux.org/title/Systemd/Journal#Journal_size_limit
or alternativly setMaxRetentionSec
to 2419200 seconds (4 weeks)Point 5: can be done via pacman hook automatically after every upgrade
example: https://aur.archlinux.org/packages/pacman-cleanup-hookthere are also many other useful pacman hooks which tell you if there are any orphans or if AUR packages need to be rebuild or there is a hook which reload kernel modules after a kernel upgrade (which otherwise would warrant a reboot unless you are ready for the issues of many unloaded kernel modules)
Awesome - thank you! I knew about yay, but wanted to understand it in case yay ever disappears like yaourt did. I did not know about the others!
Maybe it is too late because of your filesystem choice but btrfs snapshots delievers enough security if something goes wrong. Rsync seems like a little bit overhead for updating only There is even a pacman hook that makes pre and post snapshots of your filesystem with snapper. Tldr: most of your steps can be automated with pacman hooks. But if you like it this way its fine
Yup you are 100% correct. I didn’t understand what btrfs brought to the table until i started playing around with backups. What I really need is a snapshot since my backups really are handled differently. I may reformat simply for this reason. (Or I’ll switch things up the next time I break something)
i successfully switched an arch install from ext4 to btrfs.
in my case, i had 2 ssd, so i moved from one to the other, but it should work if you use one of the rsync backups.
what i did was:
- boot from a live usb arch
- create a btrfs partition on the new drive with all the subvolumes you need
- mount the btrfs partition and all the subvolumes
- rsync my system from the old drive to the new mount (https://wiki.archlinux.org/title/migrate_installation_to_new_hardware#File_copying)
- than continue to follow the arch wiki guide, fstab will be wrong, the bootloader needs to be reinstalled. while you are chrooted into it, you will need to reinstall linux to rebuild initramfs.
Well you’re being far more in-depth than me. I just run
pacman -Syu
periodically.yay -Syu for me.
Isn’t that the same as
yay
?Yes. TIL.