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!
I have an alias in bashrc called upgrade. It runs reflector looking for the fastest of the newest 10 near me. Then it upgrades the keyring, then yay -syu and then paccache -r.
I have the journal limited to 100mb so I don't ever bother cleaning house on that.
I probably don't review pacman logs as often as I should, but stuff rarely breaks and is normally pretty easy for me to figure out what when it does.
So I have a note written down that says "keyring" It's unclear to me if that's something I should do regularly, or just if I have a problem. If I'm not mistaken, it is possible for a package to need the updated keyring even if you do pacman -Syu regularly. But I also think it just pitches an error on that package, which will fail to update. Then you can just update the keyring, then rerun pacman -Syu and everything will be fine?
The archlinux-keyring package holds they gpg signatures used for signing the packages and if you go too long between upgrades it's possible you won't have a signature or an outdated one and a normal -syu will fail because of it. So I just upgrade keyring first and it gets ahead of that issue.
@Shortbus @Kongar
On hardware that I don't update often, the problem happens to me and this is the route I normally use. What I'm wondering is why the Arch guys don't implement this "automatically"... for example if the keyring is in the packages to be updated, we update it first and then the rest of the packages.
Probably boils down to the arch ethos of K.I.S.S. not making too many decisions for you.
@Shortbus
Yes it is true it may be for this reason.
Although honestly as a "shortcut" it could be convenient for many people who find themselves in a panic when they see this problem for the first time. Furthermore, adopting this behavior does not seem to me to go against the K.I.S.S.
Be that as it may with the K.I.S.S. you learn more than other distros and that's what I like about ArchLinux.