Comment 24 for bug 1811580

On Tue, 26 Feb 2019 at 18:05, Matt P <email address hidden> wrote:
>
> Okay. I guess I would have expected that if there was a dependency on a
> specific kernel version, that I wouldn't be able to install a package
> that wasn't compatible and breaks the system by installing a security
> update. It would be preferable to be informed there is a security

The kernel you are running is not an Ubuntu one. There is no package
for it known to either apt nor dpkg, thus there is no possible
dependency we could express.
How can we express a dependency, on something that is unknown to us?
After all, one can prepare installs using chroots, to then later run
the system on an incompatible kernel.

> update but that I can't install it because I am running an out of date
> kernel...then I know I am insecure and that the kernel is the issue.

Escalate to your provider. Who is your provider? Maybe Canonical can
get in touch with them?

> But I guess that is a topic for the package management guys. The error
> message from systemd-tmpfiles about too many symlinks isn't particularly
> helpful either since in this case the problem (apparently) has nothing
> to do with symlinks but rather filesystem apis in the old kernel (I
> guess?).
>
> Yes of course I can contact the hosting provider and ask them to provide
> an updated kernel and the likely result may be that I just have to use
> an alternate provider if I want this to work. Perhaps I should anyway
> since the hosting provider having such old kernels isn't a good sign.
>
> I also saw this comment:
> https://github.com/systemd/systemd/commit/6a89d671dfdd92c0b1b703d7fcb5b0551cafb570
>
> For now I have worked around this issue by just updating the paths to
> point to /run instead of /var/run so systemd-tmpfiles doesn't barf on
> the symlinks.
>
> sed -i -e 's;/var/run;/run;g' /usr/lib/tmpfiles.d/*.conf

I wonder if we should SRU that. Which might not help for all instances
of this issue, but maybe at least some.

--
Regards,

Dimitri.