Not sure if this is the right place to mention this, but I’m test driving:
in an eLxr Docker container (should that work?), and running a fresh elxrlinux/elxr:latest image, it *appears* there is a mismatch as the running kernel is 6.12.107, but when you follow the instructions and install linux-headers-amd64, the headers are 6.12.95, which eventually causes “depmod -a” to fail, claiming a mismatch.
Doing both “update” and “upgrade” first makes no difference. Or must you be on an actual physical eLxr system, and not in a container?
“uname -a” shows kernel 6.12.107 while /boot now contains:
@nmarguet Fine, make me embarrass myself. I was running this in an eLxr 26.04 Docker container so, of course, it was running the slightly newer kernel on my updated Debian 13 build host, but all of the eLxr 26.04 repo packages still reflect the original kernel release, so that was the (earlier) release of all the kernel headers packages installed. Duh.
This suggests that one should be very careful to identify the hands-on stuff in the docs that can be done in a Docker container, versus the stuff that absolutely requires a running eLxr box.
Oh, I think I understand now, and you are totally making sense! Of course (as you say), the host may be running a completely different version of the kernel vs the one the container “expects” or “was tested with” by default.
But now I realize I never had to deal with kernel modules in a container image, and I don’t think the documentation you mention above had this scenario in mind.
One last caution here regarding the docs that is a potential land mine – there are a lot of hands-on exercises, and it’s now clear one needs to be careful about where these things can be run related to eLxr 26.04:
on a generic Debian 13 build host (lots of exercises work just fine there)
on an actual eLxr target board
in a downloaded eLxr Docker container
It’s really easy for a reader to misinterpret the docs and try something in the wrong place.