Writings on various topics (mostly technical) from Oliver Hookins and Angela Collins. We currently reside in Sydney after almost a decade in Berlin, have three kids, and have far too little time to really justify having a blog.
I have a Zotac ZBox which I use an my HTPC, and generally it works pretty well. One thing that is slightly troublesome is the HDMI audio, which seems to rely on having the ALSA backports modules package installed in order for it to work. Remembering this is key, though, since when the package is installed it does not automatically get updated when you upgrade the kernel package.
Most packaging systems rely on the fact that you only have the one instance of a package around at a time, and as time passes you upgrade these packages between versions (a notable exception is the Gem packaging system). Kernel packages are the exception to the rule and not only can you have several present on your system at a time, but this is usually desirable so that you can test stabliity, rollback etc. For this reason the version number of the kernel creeps into the package name, making it effectively treated as a unique package (and since the file paths differ, it is unique on disk as well). The DEB package format handles upgrades by way of a meta-package which pulls in the latest version of the kernel package. RPM uses some other magic I can't recall right now.
In the case of the linux-backports-modules-alsa package, the same idea
applies. However where the kernel meta-package pulls in the newer kernel
package when there is an update available, it can't do the same for
this package since not everybody wants it installed automatically. Since
I do want it installed automatically but am not in a position to
change the packages, this puts me in a slightly irritating position.
Ideally there would be some hook that I could use to pull in the latest
version of this package whenever a new kernel package is installed (and
in fact there is, in /etc/kernel/postinst.d/) but anything triggered
synchronously with the kernel upgrade will fail since the dpkg
transaction is not yet complete and starting a new one will be blocked.
The trigger could in fact schedule an at job to install the newer alsa
package a few minutes later, but I don't like the asynchronous nature
of this method and the likelihood of failure (what if I reboot
immediately after to activate the new kernel?) although I can't see an
obvious alternative. Does anybody have any suggestions?
The work around for this to prevent having to remember to install the
latest version is to make use of the kernel package maintainer hook
directory: /etc/kernel/postinst.d. Scripts in this directory are
called after installation of a new kernel with the first parameter being
the new kernel version in uname -r style format.