Re: No graphical environment with nvidia after upgrade to Trixie 13.2 due to not-installed linux headers package
On 29/11/2025 03:38, Matthew Todd wrote:
linux-headers-amd64 in /var/log/apt/history.log* and
examining any files that match.
Start-Date: 2025-09-25 12:25:02
Commandline: apt autoremove
Requested-By: matthew (1000)
Remove: ..., linux-headers-amd64:amd64 (6.12.48-1), ...
End-Date: 2025-09-25 12:27:31
So you confirmed that you were bitten by the change in dkms
dkms (3.0.12-4) unstable; urgency=medium
* Stop recommending linux-headers-*.
(Closes: #1059895, #918918, #968763, #637877, #755942, #762061,
#951404)
-- Andreas Beckmann <anbe@debian.org> Wed, 03 Jan 2024 20:16:57 +0100
A link to <https://bugs.debian.org/1091428> has been posted to this
thread already. I have not read other merged bugs. I believe, partially
it is a documentation bug. The change should be more prominent by adding
a note to NEWS.Debian. Has anybody filed a bug against release notes to
add "apt-mark manual linux-headers-amd64"? (It may be better to
cross-link it with #1091428.)
For me it is not clear how to ensure smooth upgrade for most users
without causing issues for those who relies on cross-compiling. Perhaps
a dependency-only dkms-local helper package that depends on dkms and
kernel headers for machine architecture may relieve the issue. Users who
need more complicated configuration may skip it. The question is
migration for existing users and modules compiled just for current
machine. Renaming dkms to e.g. dkms-bin and making dkms a dependency
helper might be more friendly to upgrades.
I run autoremove manually periodically, and linux-headers-amd64 was
included in this one. I didn't notice the removal of this package when
skimming the "to be removed" list or realize the impact of removing it
at the time.
I agree that it is easy to miss an important package during autoremove
after upgrading to next stable release.
If you were following
<https://www.debian.org/releases/trixie/release-notes/upgrading.en.html>
For the record, I was not. Except for upgrading to a new stable release,
I generally just run the apt commands without checking any release
notes. I assume this is how most people approach it.
I wrote it expecting that the package was removed during upgrade to
trixie. It does not exclude the case that actual failure happened during
routine upgrades within stable release. Having the log entry you found,
packages state (before upgrade to trixie) unlikely will reveal something
interesting.
Reply to: