[linux-rpi] and [linux-rpi-legacy] break /boot/config.txt

[rio]

Updating to the RPi Foundation patched Linux kernel and modules provided by the new packages linux-rpi and linux-rpi-legacy replaces the existing /boot/config.txt by a default config and saves the original as /boot/config.txt.pacsave. This potentially breaks installations and therefore should not happen.

Instead the existing /boot/config.txt should be kept as is and the new default config should be provided as /boot/config.pacnew.

[graysky]

That is not how pacman works... since the two packages conflict, the old one is removed first thus creating the .pacsave.

[CounterPillow]

Leaving updated config files in-place and writing the new one as a .pacnew is absolutely how pacman works, but the question is whether that applies to files which exist before a package is installed, rather than updated packages.

[complify]

This looks like an unfortunate effect of the linux-rpi renaming and pacman's package conflict resolution process.
Check out the wiki page about pacsave files:
https://wiki.archlinux.org/title/Pacman ... nd_Pacsave

The process looks like this when installing the new 'linux-rpi' over one of the old 'linux-*' packages:

1. pacman sees that 'linux-rpi' conflicts with the old 'linux-*' so the 'linux-*' package is first removed (equivalent to "pacman -R").
2. "/boot/config.txt" is part of old 'linux-*' and pacman notices the user has modified it, so pacman backs it up and renames it to "/boot/config.txt.pacsave".
3. pacman installs 'linux-rpi' which happens to have its own '/boot/config.txt'.

Thus, installing 'linux-rpi' on a system with old 'linux-*' is not treated like an "upgrade" but more like installing an alternative, conflicting package.

As the wiki page says, the user is expected to handle the pacsave file, manually or otherwise. Yes, this does complicate upgrades on existing installations, especially automated upgrades, but this really is part of how pacman works. You'll just have to watch when pacsave files appear.

[Malvineous]

Just got bitten by this too. Did the upgrade, the kernel package got swapped, reboot and the Pi is dead. Luckily it wasn't a remote Pi so I didn't have to travel anywhere to fix it but it was still annoying having to use another machine to fix it, even if it was just putting the .pacsave files back to where they were before the upgrade.

Thanks for pointing out it was the package rename that did it, as I also was thinking it was a problem with the package itself.

Given how critical it is to having a working Pi, it'd be nice if the linux-rpi package checked for the .pacsave files during the install and gave a warning so unsuspecting users could fix the problem before they reboot, to avoid the need for a physical access fix. Assuming of course it's not possible for the package to just rename the .pacsave files back itself if they are present, so the whole process is automatic.