How to disable unattended automatic updates? (Was:Any idea how my Ubuntu 24.04.02 LTS Server installation polymorphed into something "Kubuntu"?)

[kaelis]

Thank you.
This sort of information is exactly what I need in order to resolve a fairly obvious problem with the “unattended update” architecture.

I have been dealing with a fatal system error for the past week, stemming from a forced, unattended update of the Linux HWE modules on 26 Jun 25.

To the “experts know best” crowd:
Regardless of the notion of “best practices” and concerns over “zero day exploits,” the best practice when engaging online has ALWAYS been to practice good internet hygiene: do not download or visit materials from questionable sources in the first place. If you don’t care to engage in basic common sense on the internet, you truly deserve to have someone else remotely own your system - because that is what will ALWAYS happen, regardless of a central author trying to shield you from that outcome.

Anonymity and good user hygiene is THE best practice.
Make yourself a target and you WILL be hacked by a determined perpetrator, regardless of “security” updates.

In my case, the “security feature” called “unattended updates” has always been a DETRACTOR to system security by forcing centralized spyware (Microsoft) or incompatible, and unauthorized, software packages upon my OS (my current issue).

In this case, the three HWE module updates which were pushed out on 26 Jun 25 [linux-generic-hwe-24.04 / linux-headers-generic-hwe-24.04 / linux-image-generic-hwe-24.04] are INCOMPATIBLE with AMD64 drivers and cause a display output failure upon boot handoff to the OS. This is catastrophic and unrecoverable, in part due to the OS security architecture.

So I have gone from a stable system to a bricked system just based on these modules being forced into my configuration. What’s worse, they corrupt both the user and the root configuration. I know this because I have my /home set to a separate drive in order to prevent a total loss from this exact sort of issue, yet a fresh root system with the forced config changes residing in the /home directory simply repeats the failure, even when those modules are no longer physically present. Thus, if I were a leser experienced user, I would have lost the entirety of my user data due to the requirement to wipe my partitioned /home directory as well as the root in order to resolve this problem.

Now, today, after having fully resolved the issue through extensive testing concluding last night, I came home to find that those modules were forced back onto my system configuration with a notice that a reboot is required to complete installation.

• a reboot right now bricks my system with those modules installed -

So this issue led me here, to learn how I can prevent this intrusion and destabilization from occurring yet again the moment I step away from my computer (for literally an hour). Countless hours wasted for the sake of an ill-conceived and unasked-for nanny-state approach to personal computing.

So, @vidtek99, thank you for posting very relevant and useful information for the benefit of the other adults in the room.

[ogra]

@kaelis

In this case, the three HWE module updates which were pushed out on 26 Jun 25 [linux-generic-hwe-24.04 / linux-headers-generic-hwe-24.04 / linux-image-generic-hwe-24.04] are INCOMPATIBLE with AMD64 drivers and cause a display output failure upon boot handoff to the OS. This is catastrophic and unrecoverable, in part due to the OS security architecture.

Well, it is a known fact that the amdgpu-pro driver has generally more issues with mesa as well as the kernel headers than the in-kernel shipped one simply because it is maintained outside of the archive, AFAIK there are only two use-cases why you should actually use these drivers at all (they are actually much less performant for most tasks (especially gaming) BTW because they can only make use of latest mesa features in a delayed fashion), here is a statement about this from an AMD engineer maintaining that proprietary module.

Generally, though, if you did not change the defaults, Ubuntu always keeps the last kernel available and accessible in your grub menu so in case such an issue happens to you you simply hit ESC during boot and pick the last kernel … perhaps that is something to keep in mind the next time your kernel update (or mesa libs update) makes these drivers clash again …

@kaelis

So this issue led me here, to learn how I can prevent this intrusion

You simply tweak it in your system settings, the middle four pull-down menus are managing the unattended-updates config file, nothing is “forced” on you it is just a default the distro picked because it is the safe option for 95% of the users and you can easily change it …

@kaelis

If you don’t care to engage in basic common sense on the internet, you truly deserve to have someone else remotely own your system

While internet hygiene is indeed always good practice it sadly has rarely anything to do with zero day exploits that leave a barn door open to your system in your https stack or network layer without you knowing about it at all …

[rubi1200]

We believe this topic has run its course.

@psychotux if you believe your issue has not been fully resolved and would like the thread reopened, please reach out to the moderators.

To all users and participants:

The moderating staff who volunteer here on Discourse reserves the right to request that advice which is offered that is contrary to recommended security practices for your Ubuntu install be edited to include a caveat or warning.

If you are unwilling to do so, we will take action to either edit or delete the post.

Any user has the right to decide how they manage their systems. However, you do not have the right to suggest practices that expose others to potential vulnerabilities, especially if no warning is given or steps to re-enable.

Thanks to all those who participated.