A vulnerability  has been discovered in the Linux kernel's approach to memory management which could allow an application to access a region of memory that is not allocated to it. The vulnerability is also referred to as Stack Clash.
This update caused me some headache. Tho I don’t know if the update is causing this or my osmc installation had some earlier issues which hit the update.
Problem is, that the new kernel 4.9.29-7-osmc fails to install, because the post-install hook /etc/kernel/postinst.d/apt-auto-removal-osmc is exiting with exit code 1.
After looking what’s going on, I found out that it cannot get the list of kernels from apt setting “APT::OSMCKernelPackages”. As far as I can see, this config should be set in /etc/apt/apt.conf.d/01autoremove-osmc. Sadly in my case, this file is missing and I cannot find out how to recreate it. dpkg -S shows that this is not part of any package.
So well… how can I now break this deadlock? How can I recreate a usable 01autoremove-osmc?
EDIT: I got puzzled with 01autoremove-osmc and 01autoremove-kernel-osmc. Corrected.
The list of kernels is device specific, and as such, is provided by the *-device-osmc package. But we don’t PreDepend on a new version, so there’s no guarantee the file would be there at the time of kernel upgrade. I suspect the majority of users have been OK because they’ve updated from a recent version and we didn’t push a new kernel in this update.
However had this been our June update this could have caused a lot of problems for users, so thank you for the report. For now – it’s fine for us to bail gracefully and skip the autoremoval process until we have the file brought in from *-device-osmc
I’d appreciate it if you could run the above commands and report back
In the meanwhile I already finished the install by adding an “exit 0” to the post hook script temporarily. So this did basically the same as your commit, just in a very crude way that I immediately removed afterwards. With that the update ran without further issues. So this way I am sure your change will do the trick, but I cannot test it natively anymore, sorry about this.
Now everything is clean again and up-to date. I have rbp1-device-osmc 1.1.9 but this did seemingly not bring back the missing /etc/apt/apt.conf.d/01autoremove-osmc. I even tried reinstalling rbp1-device-osmc in case it creates the file via postinstall script, but it did not.
So the remaining question is: How is osmc supposed to get this 01autoremove-osmc file in first place?