You missed possibly the most important step.
Take a full backup of your root partition before you even think about starting. And make sure you know how to restore from that backup if things go wrong (including a system that won’t boot). Double-check that it’s worked.
Oh, by the way, it’s “Never lose power” not “loose”. 
While we’re spell checking
custom packages
One could do that… but it is not required if you do your due diligence maintaining the system.
I have done so many updates over time - it is really not necessary but…
As I read the topics on updates and the comments - it became clear that a lot of those could be avoided if the system had been properly prepared.
Yes - thank you - that is an easy one to slip. 
Something like - the noose can be loose and you can lose the game.
And thank you - I write customer so often it becomes habit - slipping on custom
Yes, the same thought had occurred to me.
Two more things: have a live usb at hand, and read the FINE announcement. Which is probably the most important preparation.
Something a lot of people obviously don’t do, from the number of new posts about this (and previous) updates, about which the answer is already in the announcement thread.
One thing to add probably: Someone needs to take care about the installation messages, means: you have to look to the output of pamac / pacman and investigate into every message / error.
Sometimes something just does not work (today my evdi-dkms modules did not build, needed manual re-installation). Most of the times not a big deal, but the user needs to see this - this is only possible if you look into the messages and read the echo…
“Unattended installation” is probably often a cause for trouble / pain / … that could easily be avoided.
Im not sure if that should be really recommend way (before we doing a update).
Doesn’t it make more sense, to make a update and wait a certain time (maybe a week) and if you have a stable update, then you create a snapshot and remove orphan’s and foreign’s?
Because if i remove this stuff short time before i update, i can’t be sure if the removing packages orphan’s/foreign lead to new bugs or its related to the new update which leads to new bugs.
First: Removing AUR packages before an update ensures you don’t run into weird dependency issues where packages has been moved to AUR.
Second: Removing unneeded packages and orphans reduce the size of the update.
Example - if you have 5 kernels installed with headers and dkms - your update will consist of 4 kernels and header packages you don’t use.
When you run nvidia - there is all the nvidia modules for every kernel.
Yes - housekeeping is highly recommended.
Yes you can.
Removing AUR from Foreigns was always a safe space, total agree with that. But i always fear to remove orphan’s and other foreign’s because i never can be sure its not has depencies which is still needed.
The problem is that foreigns and orphan’s can also be pure fake and probably still needed.
I have many packages there, but some are 100% no orphans at all… best example like Steam or VLC.
And to check all foreigns and orphan’s is a lot of work with:
Orphan paket check, Important for safety uninstallation:
(depends on/Orphan)
(Required By : None)
(Optional For : None)pacman -Qi “Package name”
If the package is not a true orphan then nothing needs it it will not be removed.
I may have had two sentences in my head - I tried convey the real meaning.
An orphaned packages is not needed.
If you install a standalone application which nothing else requires the install mode will be explicit and the package is not orphan.
An orphan package can be a package installed as dependency for another package - but then you remove the other package using -R which will remove only the package itself but not packages which may have been installed as dependency or optional dependency.
It could also be packages installed as build dependencies for an AUR package e.g. python-setuptools.
Such package instantly becomes an orphan.
So combining --orphans and --unneeeded may be a doubletime but there is no harm done - just never use --cascade it is a real system killer.
Ok, so imagine you install BOG, which needs electron38.
Now you delete BOG. You have a few electron versions, and no idea why…
Why do you have this? You probably can’t remember… and we’re lazy to keep that many notes.
So you open the terminal:
➤ pacman -Qi electron38
Name : electron38
Version : 38.7.2-1
Description : Build cross platform desktop apps with web technologies
Architecture : x86_64
URL : https://electronjs.org
Licenses : MIT BSD-3-Clause
Groups : None
Provides : None
Depends On : c-ares gcc-libs glibc gtk3 libgtk-3.so=0-64 libevent
libffi libffi.so=8-64 libpulse libpulse.so=0-64 nss
zlib libz.so=1-64 fontconfig libfontconfig.so=1-64
brotli libjpeg-turbo libjpeg.so=8-64 flac
libFLAC.so=14-64 libdrm libxml2 libxml2.so=16-64
minizip opus libopus.so=0-64 harfbuzz
libharfbuzz.so=0-64 libharfbuzz-subset.so=0-64 libxslt
libxslt.so=1-64 libpng libpng16.so=16-64 freetype2
libfreetype.so=6-64
Optional Deps : kde-cli-tools: file deletion support (kioclient5)
[installed]
pipewire: WebRTC desktop sharing under Wayland [installed]
qt5-base: enable Qt5 with --enable-features=AllowQt
[installed]
gtk4: for --gtk-version=4 (GTK4 IME might work better on
Wayland) [installed]
trash-cli: file deletion support (trash-put) [installed]
xdg-utils: open URLs with desktop’s default (xdg-email,
xdg-open) [installed]
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 278.25 MiB
Packager : Caleb Maclennan <alerque@archlinux.org>
Build Date : Thu 27 Nov 2025 04:51:35 +07
Install Date : Fri 28 Nov 2025 12:15:24 +07
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
It was installed as a dependency, not explicitly by you.
This means you can wipe it and it won’t rock the boat.
There were quite a few orphans created this month, it’s best to clean them up - we don’t want too much fluff/residue clogging up the pipes.
Once we learn how to deal with orphans, we can keep notes - either as alias commands (orphan-check, orphan-remove) which will then expand so that we can remember the commands.
abbr orphans 'pacman -Qdt --color=always'
abbr orphan-clean 'sudo pacman -Rnsuv $(pacman -Qdtq)'
If you can’t remember - package info is pacman -Qi
Just read carefully and think a second before cleaning - I hear there are risks, but I have snapshots so I don’t worry too much.
also nice, I always use it
sudo DIFFPROG=sdiff pacdiff -f
I’m pretty sure the command to see the installed kernels is:
mhwd-kernel -li
Thank you for spotting this
Some must find paying attention to their updates is very difficult while prioritising Facebook/X/etc chats on their Smart Phones.
ah … I was thinking to write “and not go to the loo while an updates is ongoing, or take your notebook with you to look at ” … but probably you are correct - facebook is even more important than anything else …
The only reason i sometimes do not do the updates through tty: one cannot scroll up like in a terminal. And i want to see everything that happens. And some warnings are not logged to pacman.log
So I gather you have never tried these
Ctrl+Shift+↑ tty oneline up
Ctrl+Shift+↓ tty oneline down
Shift+PgUp tty page up
Shift+PgDn tty page down
Alt← move next tty
Alt→ move previous tty
Hmm - just checking - the location in my memory appear to be corrupted - only the last two will work on Manjaro 
- that is strange …
EDIT: Linux kernel 5.9 ended the TTY scroll buffer.