Normally when we want to go back to normal, we just install the next steamos update through gaming mode settings, which erases our changes and gives us a clean installed rootfs in our active slot. however, what if we actually mess up the updater?
if done in such a way that the updater breaks but not much else, it can be a subtle effect that might tempt booting the other rootfs or just plugging in the recovery USB and reinstalling. in my experience though, it's possible to drill down and manually repair the rootfs enough to update without rebooting to anything else! Above is what the update UI might look like while this is happening, and here's an example of what the error might look like internally in the Arch Linux portion of SteamOS:
In my case, i decided to use these commands to fix my rootfs (bearing in mind that i'd already installed a lot of stuff like a few generic compiler toolchains into my rootfs, so if you ever coincidentally get the same error, you'd need more):
paru -Fy
paru -F casync
paru -S devtools
pkgctl repo clone --protocol=https casync
cd casync/
makepkg -siThe strategy behind the solution I used in this case is like this: reading the error message in systemctl status rauc, I could see that I accidentally broke the dependencies of casync's binary by replacing one of them with a different version.
From past experience with GNU/Linux, I know that one of the fastest ways to bypass this type of error without breaking anything else is to recompile casync from source, which will invoke pkg-config and/or other build tools to detect the paths of my currently-installed system libraries and compile those paths into the binary. This is the quick way to do that I used.
After those commands, I touched update again and the newly compiled casync started installing the update. The UI remained frozen at "APPLYING 0%" for a long time, but I was able to watch its activity in /proc/meminfo and iotop. When it finished, the "restart" button appeared and when I touched it the Steam Deck rebooted into the new clean SteamOS 3.5.5 rootfs, ready for me to disable read-only and do it all over again!
I am sorry to everyone who already knows this and thinks of this as a very simple problem to solve, but it's not easy for beginners who have never used any other GNU/Linux before Steam Deck so this might help someone in a similar situation. I think there is a lot of fear for some that disabling read-only can quickly soft brick the steam deck and require using the recovery USB, but I think examples of how Arch Linux repair techniques directly work on SteamOS can dispel some of that.