Mike (12024-07-21):

1) lsmod | grep <driver>

I conceed that doesn't actually indicate the kernel has changed, just
that the kernel module is missing. However, so far, it being missing
has consistent indicated a kernel change and rebuilding the driver on a
false positive isn't really an issue

If the module is not loaded even though the kernel did not change, it
still is an issue you need to investigate, is it not? So this is the
version I would recommend.

You can double that with testing if
/lib/modules/$(uname -r)/path/to/the/module.ko exists.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

I have a TV card in one of my boxen, which requires a kernel module to
be built. I've got that all nicely scripted and so I can kick it off
with relative ease.

The issue is detecting when it needs to be done. ie after a change in
the running kernel. At the moment, it's detected by the TV guide
running out of data and triggering an Icinga alert, which then causes me
to investigate and rebuild the kernel module. I was hoping for
something a little more automated. I'm envisioning something which
starts on boot checking if the kernel has changed and if so, kicking off
the kernel module rebuild script.

The question is: how to detect if the kernel has changed. Off the top
of my head I'm thinking:

1) lsmod | grep <driver>

I conceed that doesn't actually indicate the kernel has changed, just
that the kernel module is missing. However, so far, it being missing
has consistent indicated a kernel change and rebuilding the driver on a
false positive isn't really an issue

2) last | grep "system boot" | head -n 2; then diff the values

Probably a bit of a faff to extract the necessary information and
probably not wholey robust either.

I thought that I'd just run it past the hive mind and see if anyone has
any better ideas?

Kind regards,
Mike.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEELLIsu3X0rLdOylbZ4Vi9eUgjvvMFAmac9HoACgkQ4Vi9eUgj vvPwrQ/9FdmAVqhRbDWfHDbeZ6dX+Bj+NSLhRHMfeDk5nvvMAsUsaeup5LZXGEAn 6WUX8T7yFh3m1QRu4YKdVT/Rype9g4nzEQEAk/Ko+mK3GX+guptA1XNgfjKWXCuh 1yOWGNYKWbScy/TiOq5ZiYjvnAjU8a/FQ9AFsh9xHnc8GnJdl6O2j3QwvU+YmLcn NZ0dtJLINQcCgrvQ8ophRF2bzf7Tm8LU3XEZtw2UkI8Xre36ZHfBXtGVYpzCaSSc sDBxRUuTDrWf4FWr3f2Q2d7svOmrlxKTT2tuxkajjRA5u+wx6X1O4unTGQRB/9+8 xOSNgpCPe316AdmurRXvsV4UFDz5cFkh1gJ1YyZfjh8VT3kHTKGGhOMPK4lKQxne sRgoIq8UGWxzFbAitBZkfnys0DAomD0zBMXcCb6e3Axlh8/KMmoO0U0ZJMFt3Ky7 bnkWwkn3uP4n/rIahy9kgmkpKwKS5AGOcYdbFv1TBQO6essIemBR24H1Ghhi1xGc QhKC7k8m7WTZUXmqRFyYA0cYha3VGvii7znNyF9VZELXXWTGkjqgLwL8zw7vOdqU U8Cvuwh51NXFMPwF71pxWWlevsCNkBngGNeC3bS4OX2zmQ9/8dAZojMuWkx7gGZO JD59RGI/US9yurx+B0bkHFvJ2uKIECBNecmF7MIkwQB9I+OVTNQ=
=FYH5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21 Jul 2024 12:43 +0100, from debian@norgie.net (Mike):

I have a TV card in one of my boxen, which requires a kernel module to
be built. I've got that all nicely scripted and so I can kick it off
with relative ease.

I thought that I'd just run it past the hive mind and see if anyone has
any better ideas?

This is pretty much exactly what DKMS is for.

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mike wrote:

I have a TV card in one of my boxen, which requires a kernel module to
be built. I've got that all nicely scripted and so I can kick it off
with relative ease.

The issue is detecting when it needs to be done. ie after a change in
the running kernel. At the moment, it's detected by the TV guide
running out of data and triggering an Icinga alert, which then causes me
to investigate and rebuild the kernel module. I was hoping for
something a little more automated. I'm envisioning something which
starts on boot checking if the kernel has changed and if so, kicking off
the kernel module rebuild script.

That's what the DKMS system is for, only it triggers when apt
updates the kernel rather than after a reboot.

https://packages.debian.org/bookworm/dkms

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/21/24 07:43, Mike wrote:

Hi all,

I have a TV card in one of my boxen, which requires a kernel module to
be built. I've got that all nicely scripted and so I can kick it off
with relative ease.

The issue is detecting when it needs to be done. ie after a change in
the running kernel. At the moment, it's detected by the TV guide
running out of data and triggering an Icinga alert, which then causes me
to investigate and rebuild the kernel module. I was hoping for
something a little more automated. I'm envisioning something which
starts on boot checking if the kernel has changed and if so, kicking off
the kernel module rebuild script.

The question is: how to detect if the kernel has changed.

You could run
uname -r
and compare the output to what it was last time, by using a logfile to store the info across invocations. But I think you were correct, what's really important is whether the kernel module is loaded, and then you're back to

1) lsmod | grep <driver>

I conceed that doesn't actually indicate the kernel has changed, just
that the kernel module is missing. However, so far, it being missing
has consistent indicated a kernel change and rebuilding the driver on a
false positive isn't really an issue

--
"That."
-- She

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 21 Jul 2024 12:43:58 +0100
Mike <debian@norgie.net> wrote:

Hi all,

I have a TV card in one of my boxen, which requires a kernel module to
be built. I've got that all nicely scripted and so I can kick it off
with relative ease.

The issue is detecting when it needs to be done. ie after a change in
the running kernel. At the moment, it's detected by the TV guide
running out of data and triggering an Icinga alert, which then causes
me to investigate and rebuild the kernel module. I was hoping for
something a little more automated. I'm envisioning something which
starts on boot checking if the kernel has changed and if so, kicking
off the kernel module rebuild script.

The question is: how to detect if the kernel has changed. Off the top
of my head I'm thinking:

1) lsmod | grep <driver>

I conceed that doesn't actually indicate the kernel has changed, just
that the kernel module is missing. However, so far, it being missing
has consistent indicated a kernel change and rebuilding the driver on
a false positive isn't really an issue

2) last | grep "system boot" | head -n 2; then diff the values

Probably a bit of a faff to extract the necessary information and
probably not wholey robust either.

I thought that I'd just run it past the hive mind and see if anyone
has any better ideas?

These may help:

I always get a notification of a new kernel and therefore necessary
reboot during an apt upgrade. needrestart -k can be parsed to detect a
newer kernel available, though obviously only until the next reboot.

When apt installs a new kernel, it will typically not remove the
current oldest. apt autoremove will remove all but the current and last kernels, so when it finds a kernel which can be removed, a new one will
have been installed since its last invocation.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 22-07-2024 at 02:35 Joe wrote:

On Sun, 21 Jul 2024 12:43:58 +0100
Mike <debian@norgie.net> wrote:

Hi all,

I have a TV card in one of my boxen, which requires a kernel module to
be built. I've got that all nicely scripted and so I can kick it off
with relative ease.

The issue is detecting when it needs to be done. ie after a change in
the running kernel. At the moment, it's detected by the TV guide
running out of data and triggering an Icinga alert, which then causes
me to investigate and rebuild the kernel module. I was hoping for something a little more automated. I'm envisioning something which
starts on boot checking if the kernel has changed and if so, kicking
off the kernel module rebuild script.

The question is: how to detect if the kernel has changed. Off the top
of my head I'm thinking:

1) lsmod | grep <driver>

I conceed that doesn't actually indicate the kernel has changed, just
that the kernel module is missing. However, so far, it being missing
has consistent indicated a kernel change and rebuilding the driver on
a false positive isn't really an issue

2) last | grep "system boot" | head -n 2; then diff the values

Probably a bit of a faff to extract the necessary information and
probably not wholey robust either.

I thought that I'd just run it past the hive mind and see if anyone
has any better ideas?

These may help:

I always get a notification of a new kernel and therefore necessary
reboot during an apt upgrade. needrestart -k can be parsed to detect a
newer kernel available, though obviously only until the next reboot.

I did not know needrestart could be manually run (shows my ignorance and laziness). I have been using need restart for many years.

Thanks heaps for pointing this out !

man can be helpful, if used, wow ! Who would have thought?. I am feeling a little embarrassed right now.

# needrestart -vlk
[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.6
[main] running in root mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] systemd detected
[Core] #719 is a NeedRestart::Interp::Python
[Python] #719: source=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
[Core] #1535 is a NeedRestart::Interp::Perl
[Perl] #1535: could not get a source file, skipping
[Core] #1637 is a NeedRestart::Interp::Perl
[Perl] #1637: could not get a source file, skipping
[Kernel] Linux: kernel release 6.1.0-23-amd64, kernel version #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15)
[Kernel/Linux] /boot/vmlinuz-6.1.0-23-amd64 => 6.1.0-23-amd64 (debian-kernel@lists.debian.org) #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) [6.1.0-23-amd64]*
[Kernel/Linux] /boot/vmlinuz-6.1.0-22-amd64 => 6.1.0-22-amd64 (debian-kernel@lists.debian.org) #1 SMP PREEMPT_DYNAMIC Debian 6.1.94-1 (2024-06-21) [6.1.0-22-amd64]
[Kernel/Linux] Expected linux version: 6.1.0-23-amd64

Running kernel seems to be up-to-date.

No services need to be restarted.

When apt installs a new kernel, it will typically not remove the
current oldest. apt autoremove will remove all but the current and last kernels, so when it finds a kernel which can be removed, a new one will
have been installed since its last invocation.

Is this a Debian only feature?

How autoremove leaves ' the current and last kernels' is something I really like Debian for.

Debian looks after me, even when I am too lazy to do this myself.

Some distros run into issues because they do not do autoremoves of previous kernels.

George

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)