EndeavourOS users are clever
Otherwise you wouldn’t have chosen a distribution so close to Arch.
If you have chosen EndeavourOS because you have heard so many good things of the community and Arch in general - these tips on updating the system may prove invaluable knowledge on your journey.
A couple of topics [1] [2] [3} have spurred me to rewrite a short article [6] on what to look out for when updating an Arch based system thus avoiding - hopefully - issues on restart.
Using an update notifier
Either when you use your system or shortly after login - a message appears - telling you there is updates available. Almost per instinct you initiate the update - provide credentials and off you go.
Suddenly your screen goes blank - you wait - nothing happens. You press CtrlAltF4 - nothing happens - you wait - nothing happens. You hold the power button until the system powers off and press it again to power on your system - and now you are having a black screen maybe a message …
What now? Could the situation have been avoided?
While - of course there is no guarantee - but the following headlines may help you understand what goes on behind the scenes.
- Know your system
- What happens when you update
- What happens or why when an update stalls
- Updating the smart way
- Conclusion
Know your system
There is a few packages - which when updated most likely will require a restart. A short list of important system packages which probably requires restart
- ucode
- cryptsetup
- linux
- nvidia
- mesa
- systemd
- wayland
- xf86-video
- xorg
Another part of knowing your system is which foreign packages you have installed. Foreign packages is defined as everything not in the official repository so keeping a list of packages installed by an AUR helper or using makepkg -i
will be of help when you update your system.
Before you update - you can query pacman for the list - pipe it to a text file for later referral
pacman -Qm > ~/aur-pkglist.txt && xdg-open aur-pkglist.txt
What happens on update?
Most of us has been using Windows and we know from Windows that system files may be locked an the system must be restarted to the file can be replaced with the updated versions.
Due to the modularity of Linux only needed portions of an application is loaded into memory and the rest is loaded on as-needed-basis - and this includes kernel, kernel modules and drivers.
When you build a package using an AUR helper the package is build using the - at build time - available system libraries. When you update your system - you are potentially replacing those dependencies with new libraries - which in turn may influence your system stability - especially when it comes to a kernel module build for a specific kernel.
When you reboot your system after an update the system will usually use the updated kernel upon reboot - and the device relying on a custom kernel module will fail because the module has not been rebuild.
Only after a successful update and a successful restart you can begin to update your custom modules.
What happens when an update stalls?
The following is a simplified description - of what may happen.
When you run huge updates within the graphical environment - whether you use a terminal or a GUI package manager - the system may end in a state where it needs to load a specific library at a specific memory address pointing at a specific routine in the library - but due to updates - the library is no longer existing - it has been updated to a never version - and your update stalls.
Updating the smart way
Updating the smart way includes knowing which packages may pose a problem if the update is run with the GUI. I showed you a list of packages which by a lot of users experience often requires special attention.
If you are using the eos-update-notifier
- it will tell you if a reboot is required after running the updates.
If you are using other means of updating you can use a small utility script to evaluate the package list.
Utility script
#!/usr/bin/env bash
reboot="(ucode|cryptsetup|linux|nvidia|mesa|systemd|wayland|xf86-video|xorg)"
if [[ $(which yay) =~ (yay) ]]; then
updates=$(checkupdates; yay -Qua)
else
updates=$(checkupdates)
fi
echo "$updates"
if [[ $updates =~ $reboot ]]; then
echo "Updating possibly requires system restart ..."
fi
When you have evaluated the list and found this update to have the potential to stall - the smart way is to update using the console.
Ensure mirror is up-to-date
Before switching to console and executing the update command - ensure your primary mirror is up-to-date and remember to save the new mirror list
$ reflector-simple
Updating
Logout of your GUI and switch to TTY- CtrlAltF4 and run the update.
$ sudo pacman -Syu
If you changed mirrorlist use a double y to force sync of the package database - often necessary when primary mirror is changed by reflector simple
$ sudo pacman -Syyu
When you reboot after a successful update - first thing to do is rebuilding your foreign packages, drivers and kernel modules. This can be done from a terminal in the GUI session - but if you want to ensure you get no problems - TTY is recommended CtrlAltF4.
Depending on your DE you switch back to GUI using CtrlAltF7 or CtrlAltF1
Rebuilding all your AUR packages using a single command e.g.
$ yay --aur
Conclusion
Following a few basic rules will help you keep your system healthy and hopefully you will avoid problems from a stalled update.