Complete downgrade automation

ttshaw1 · 2023-09-05 04:09:28

I have a tablet that stopped working some time in the last year, and I'm trying to figure out what upgrade caused it. There are three or four packages in the stack that could be responsible, so I'm planning to just bisect through possible dates until I can find the day the tablet broke. But I want a script to automate this as much as possible rather than following the instructions at https://wiki.archlinux.org/title/Arch_L … cific_date

I found this script that handles setting the mirrorlist to a specific date, with some modification to change the

yad

date selection line to a text input. Now I'm running into two problems. The first is the PGP signature described at the Arch wiki link. I think I'll solve that by adding a line to the script to downgrade the keyring before trying to downgrade everything, but wanted to see if anyone else had a suggestion for an improvement.

The next is more serious. In my case, I can't downgrade to before about 3/25/23 because downgrading libcamera would break dependencies required by libcamera-ipa, which is currently a dependency of a whole bunch of packages I can't do without. But libcamera-ipa doesn't have a package in the archive before 3/20/23. So from what I gather, pacman doesn't do anything to libcamera-ipa since it doesn't see a package to downgrade to, and libcamera-ipa complains when pacman wants to downgrade libcamera. I think the fix would be to remove libcamera-ipa, along with any other packages that came into existence after my downgrade date. But it's hard to see how I can do that without risking breaking my system. Anyone have a recommendation for the cleanest way to do this?

I checked the script at https://wiki.archlinux.org/title/Downgr … Automation, but it doesn't look like it's intended for downgrading every package.

mpan · 2023-09-05 04:51:35

Rolling back entire updates is not something expected to be done routinely. It is an emergency, manual intervention. Even less likely is rolling back far in time. So do not expect this to be a pleasant ride or something easy to automatize.⁽¹⁾ There will be pain and toil the deeper in past you wish to dig.

For testing or temporary fixes it’s almost always enough to downgrade the suspected packages and, selectively, their dependencies. This may or may not yield an unbootable/unusable system, but this is why having Arch ISO at hand is always a good idea. In case of a total failure (rare) you just chroot and `pacman -Syu` or `pacman -U …` to restore the packages to the most recent versions. Having pacman-static is also useful for a few particular types of breakage.

@keyring
The security of package signing does not happen by merely being in place. It depends on keys, that are not expired, are not revoked, and belong to trusted packagers. A signature from a key, which is revoked, expired or otherwise removed from the keyring, does not provide that security anymore. This is one of the downsides of using ALA for very old packages: you give up strong security. Because usually the keys are not compromised and did not belong to rogue actors, this is still better than not checking signatures at all. But please be aware of the risk and that you are incomparably closer to no signatures than the other end, if revoked/expired/removed keys are in use.

After that introduction: yes, you may want to downgrade archlinux-keyring first before other packages. However at some point this may stop working: if you move far enough into past or in too big steps, archlinux-keyring itself will have invalid signature. At which point the only option remains to turn off signature checking or at least ignore it for archlinux-keyring (with obvious security implications).

@dependencies
Downgrading does not involve only using lower package versions, because upgrading does not mean only version bumps. Upgrading also involves installation of new dependencies, configuration merges (.pacnew), running post-installation scripts and — sometimes — manual interventions. Therefore downgrading also includes:

Removal of these new dependencies, because they may disappear while moving back in the past. This is likely what you observe with libcamera.
Ensuring configuration is valid for the older version. At this point I may suggest backing up your user’s configs before moving far into the past, as older software may assume your newer configs are invalid and happily nuke your settings.
Ensuring the installation post-scripts did their job without an error and investigate warnings. They are written under the assumption, that they work on older state, not something from the future.
Checking if you are not crossing any manual interventions (see Arch Linux news) and, if yes, that they do not affect anything.

I do not say you must observe all these points on each downgrade attempt. Just be aware such a neccessity may arise and these things may give you trouble.

____
⁽¹⁾ Since that may include un-applying manual interventions announced in human language in Arch News, one could even argue it provably can’t be scripted at all.

Last edited by mpan (2023-09-05 04:54:41)

toobig4u · 2024-02-25 20:58:37

here is a script which worked for me.:

https://gist.github.com/raverecursion/2 … 0693d0e3bb

V1del · 2024-02-25 21:22:42

Your script is incredibly simple and for an entirely different usecase, for said usecase you don't need such a script in the first place and can just do

sudo pacman -Syuu

https://wiki.archlinux.org/title/Offici … positories

Last edited by V1del (2024-02-25 21:23:53)

Arch Linux

#1 2023-09-05 04:09:28

Complete downgrade automation

#2 2023-09-05 04:51:35

Re: Complete downgrade automation

#3 2024-02-25 20:58:37

Re: Complete downgrade automation

#4 2024-02-25 21:22:42

Re: Complete downgrade automation

Board footer