Put Fedora kernel on HOLD to prevent its removal on updates

That is a very old BIOS, likely to cause all sorts of issues with recent kernels and your CPU.

See if you can find a newer BIOS to upgrade to.

Old machine, old kernel, running Ubuntu 24.

 Distro: Ubuntu 24.04.3 LTS (Noble Numbat)

oops, my bad… added the output using Fedora above

:flushed_face:

Gateway was bought out by Acer, who does not support it… just like HP bought out Compaq and stopped support… so no upgrade for BIOS available

:woozy_face:

6.8.0-111 is the latest kernel for Ubuntu 24.04.3lts (the next lts is 26.04 which just came out last month…) - just got installed in yesterday’s update package… but normally I use 6.8.0-85 as it is more stable and has no bugs like the newer ones coming out of ubuttu :face_without_mouth:

Old computer? My BEST two computers is one that runs WinXP (32 bit quad SP3) and the other runs Win98 (1st ed - never updated) - neither have ever been exposed to the interferenet… work flawlessly with my autocad, computational fluid dynamics fire simulator, flightsims, etc. Also got win10 on old Dell Latitude for secure online stuff w/ESET.

Hi,

you could use parameter exclude=”name of your kernel” in /etc/dnf/dnf.conf. The name and version of kernel (or another SW package) must by exactly…

You can use wildcards in the value of that exclude= option. exclude=kernel* should work to prevent the kernel (kernel-core, kernel-modules, etc.) from updating.

Yes, but it mean, that you will not upgrade any new kernel - I think, that it is not good idea…

OK, but if you don’t use the wildcard, be sure to list all of the kernel packages (comma delimited). You don’t want to break your system by accidentally removing kernel-devel or kernel-modules-extra or whatever. You can use something like rpm -qa | grep '^kernel*' to get the full list of kernel packages and then list all the ones with the specific version that you want to prevent dnf from removing.

I’m not sure how you would handle kernel-headers in that case. It doesn’t track exactly with the version(s) of the other kernel packages. I think it is guaranteed backwards compatible, so you should probably just let that one upgrade every time (i.e. don’t list it on the exclude= line).

I don’t remeber the excatly parameter of exclude, but man dnf and man dnf.conf would explain it. The second way is boot the old kernel every time = it means that it will stay there, or try it on not importand SW - which is possible update again.

I put installonly_limit=0 in my /etc/dnf/dnf.conf to make sure the ‘good’ kernels are ON HOLD so to speak and never get ‘lost’, and will just dump the ones that I have issues with…

my /boot is 2Gb w/1.5Gb free, so plenty of room for now - will keep watch on it.

Currently my Ubuntu grub’s Fedora part of the list has 6.19.11-200.fc43.x86_64 as default, and the newer Fedora kernels are now in the Fedora submenu via Ubuntu Grub Customizer as will any new kernel Fedora puts at me will land after getting tested and failing.

I’ve already used sudo dnf remove kernel*6.19.9* kernel*6.19.12* kernel*6.19.13* to get rid of the problem ones and shall include any other newer kernel that tries to break my Fedora later on… That latest 6.19.14 kept giving me the ‘kernel panic’ black screen of death, so it failed, got placed in the submenu, and will soon be removed ~ just using my 1911 for now (also a great caliber).

Maybe you would want to stick to longterm kernels 6.8, 6.12 or 6.18. Instructions for 6.12 are there : Kwizart/kernel-longterm-6.12
Install those for your Fedora distro. I’m still on F42 so I’ve got:

$ LANG=C sudo dnf list installed "kernel-core*" "kernel-longterm-core*"
Updating and loading repositories:
Repositories loaded.
Installed packages
kernel-core.x86_64          6.18.13-100.fc42 updates
kernel-core.x86_64          6.19.14-100.fc42 updates
kernel-longterm-core.x86_64 6.12.84-200.fc42 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-6.12

Are you sure? “Value 0 means unlimited number of installonly packages.” Sorry, by the my opinion it is not solution…

man page: installonly_limit
integer

Number of installonly packages allowed to be installed concurrently. Defaults to 3. The minimal number of installonly packages is 2. Value 0 means unlimited number of installonly packages. Value 1 is explicitly not allowed since it complicates kernel upgrades due to protection of the running kernel from removal.

To prevent a specific kernel from being removed on Fedora, mark it as “user-installed” using sudo dnf mark install kernel-<version>, which protects it from automatic cleanup.

Well, but it is the same as exclude (you could changes of grub environmet and it not will automatic changes of your grub - only manually). But it is the final solution of the question? Why he don’t want upgrade of kernel? O.K. I understand that newer kernel has error of something a special device or (?). But it is not solution, better, but only temporarily is wait for new kernel and new solution - stay with old kernel is nonsens…

His solution isn’t the best.

it never cleans up the old kernels he doesn’t want anyway. It just endlessly installs kernels. Then he has to manually clean them up.

It isn’t the same as exclude. Excludes means don’t update at all.

This just marks it to be excluded from cleanup so it does actually update the kernel packages, it just doesn’t remove the ones marked as user installed. IIRC it doesn’t count in the limit. You can still have the install_limit=3, so you will have 3, plus all the ones marked as user installed.

I agree, it would be better to solve the issue with the kernels he is having issues in the first place. I haven’t had any kernel issues in a long time.

Parameter dnf.conf exclude=” something” means, that SW version of package you don’t want to upgrade it. But it must be named exactly: “It isn’t the same as exclude. Excludes means don’t update at all.” = is nonsens. New version of this SW will upgrade. You should read man pages. Sorry, I don’t want to argue about it. Finish.

I should but ill take your word for it. I have used exclude before, but I haven’t needed in a long time. Mark easily could just be an easier way to do the same thing.
.
I probably should start compiling the kernel with the v3 extensions though so the information is handy.