Prevent downgrading from apt upgrade?

[MichaIng]

Hi,

is it still the case, that apt upgrade, upgrading the raspberrypi-firmware package family, will overwrite and in case downgrade your firmware, installed via rpi-update?

I remember, two years ago, I regularly ran apt update && apt full-upgrade && rpi-update until I realized that it was even possible, that firmware was overwritten two times by that, first downgraded to "new" package release and then upgraded again to new master branch bump.

I solved that by apt-mark hold libraspberrypi0 libraspbeerypi-bin raspberrypi-kernel raspberrypi-bootloader, but I got tired of the ongoing there is an update available messages from apt update 😄. Is there a more elegant way? I even thought that it might be possible to just purge the firmware packages and run rpi-update afterwards, would that be possible? Are the 4 packages above the right ones, complementary to what rpi-update installs?

Thanks for the great work! 4.14.17 runs great so far on my Pi2.

[popcornmix]

If you runsudo rm /boot/.firmware_revision; sudo rpi-update after running apt upgrade it should always restore the latest firmware/kernel.

[MichaIng]

@popcornmix Thanks for reply. Yes of course via rpi-update I can always recover the latest firmware again. And yeah I was not thinking right. At least the kernel modules do not get overwritten, just put side-by-side, and I guess sudo rm /boot/.firmware_revision; sudo rpi-update will just tell the system to use latest firmware again?

But it would be great, if there was a way to either let APT firmware scripts skip downloading completely by default, if a never firmware is already installed, or if rpi-update could somehow block APT firmware upgrades. Maybe purging affected APT packages on rpi-update installation/run, reinstalling them after rpi-update remove could work? Of course this should not be done automatically, but giving a user hint. I just don't like that back-and-forth of firmware/kernel/bootloader, also that /lib/modules get then filled with many different unnecessary versions, filling my SBCs sd card and wearing it with unnecessary read/writes.

And as said. I am not sure, if many users actually know about this behaviour. At least I did not for ~1 year, running around with sometimes new master branch, sometimes APT release.

[popcornmix]

rpi-update stores the last updated kernel revision in /boot/.firmware_revision, and will skip an update if it believes you have the latest version. Removing that file forces the update to happen.

rpi-update is designed for getting latest testing firmware/kernel. It's not designed to be used by the majority of users - just users who have reported a specific bug and need to test a proposed fix, or users who like running on the bleeding edge to help with the testing effort. I don't think we want to add hooks between apt and rpi-update. Switching back to stable firmware/kernel after an update in apt is probably the desired behaviour for a user testing a specific bug fix (updated apt firmware/kernel is likely to include latest fixes). The bleeding edge testers can probably handle switching between rpi-update and apt, and blocking apt updates may introduce more confusion.

[MichaIng]

@popcornmix Okay, fair enough, thanks for the explanation. I like to stay at bleeding edge, but in the end you are right, it is not too hard to block APT then, I will try, if it is possible to purge the APT packages completely (libraspberrypi0 libraspbeerypi-bin raspberrypi-kernel raspberrypi-bootloader) instead of hold them, and then stay just with rpi-update 😃.

---

Just tested, works fine. One has to take care, that device-tree-compiler stays installed (at least I guess so), but rpi-update safely replaces the mentioned 4 packages.

Thanks for your nice work btw! 🍾

[MichaIng]

@popcornmix I just recognized that, when purging the raspberrypi-firmware APT packages, the vc binaries cannot be executed directly any more, as symlinks of them to /usr/bin are missing and an entry for /opt/vc/lib within /etc/ld.so.conf.d as well: cat /etc/ld.so.conf.d/00-vmcs.conf => /opt/vc/lib

This can be fixed easily, would be maybe also an option to check and in case add this within rpi-update script?

However are you aware of any other necessary steps to fully implement the firmware, that the APT packages do, thus need to be done manually in absence of them?

Thanks in advance and sorry if this should be maybe addressed better to package maintainers/checked oneself.