On my laptop the above kernel prevents booting. I get three lines of text and nothing. Can walk away and wait hours still nothing happens. Has to do with password and passing data to anaconda (the GUI controller for Fedora), i think that is the point...

In short I want to remove that kernel and all packages attached to it and lock this laptop to the older:

kernel-5.3.11-300.fc31.x86_64

or 5.3.x or 5.4.x kernel so i do not have to format reinstall this laptop again. Yes it is old, yes it is slowing starting to fall apart, but I want to keep it running as long as possible.

Yes I am aware of the security implications by not updating my kernel, but if it does not boot, all security is worthless as the laptop is unusable at that point.

Yes it is my laptop, not the kernel. My wife has the same vs of laptop (1 year older) and she is able to run the 5.5 kernel without issue.

My google foo has failed. I can find commands for removing OLD kernels, but not newer ones. I also looked into versionlock command for dnf and am not 100% sure that is the correct path for me.

Thank you in advance.

Provide a link for those instructions. There is no basic difference removing an old kernel or a new one, but we can look over those instructions to make sure there is nothing obvious that you should not do.

If you have the option, you might try installing a newer kernel. Your issue may be with that SPECIFIC version alone, and it might be good to find out.

If you are able to boot any older kernel, then you can easily remove the problem kernel thus:To prevent installation of newer kernels, edit /etc/dnf/dnf.conf to include this line:If an exclude line already exists, append a space and kernel* to it. This will prevent dnf from adding or removing any package containing the string "kernel" at the beginning of its name. If you wish to block only the 5.5.9 kernel, instead use kernel*5.5.9* on the exclude line.

Anaconda is Fedora's installation program. What you think is Anaconda is likely GDM, the display manager. You're probably better off simply booting a prior kernel than removing the offending kernel and blocking installation of other kernels. Did you try booting an older kernel and then rebuilding the 5.5.9 initramfs? That may be all that's needed to fix the problem.

Have you tried booting without starting the display manager? If you strike the E key when the Grub menu appears and append a space and a 3 to the end of the line that begins linu (which likely wraps to the next line) before proceeding to boot as instructed on the bottom of that screen, you may be able to reach a login prompt while running on the 5.5.9 kernel from which the initramfs can be rebuilt, or any other action performed required to solve the problem, such as examining the journal for the previous boot for errors causing the problem.

Ill work on getting those links for removing old kernels in a bit, but here are some links to the errors and kernels im seeing/using

https://drive.google.com/open?id=1ql...lSu0WL4YrWzUR0

https://drive.google.com/open?id=1NF...dWpKWM3YWXHUvb

hope those links work.

https://www.if-not-true-then-false.c...-red-hat-rhel/

https://www.tecmint.com/delete-old-k...el-and-fedora/

Possibly Plymouth is the problem here. You can bypass it via Grub by appending plymouth.enable=0 or noplymouth or plymouth=0 to the linu line. Which I don't remember, as I don't use Fedora's Grub.

From there:
I set the limit to 5 or 8 and delete kernels as in comment #3 when I choose, or let dnf autoremove the old ones only when they have gotten rather more stale.

Thank you mrmazda,

I followed https://robbinespu.github.io/eng/201...ot_faster.html

directions, no luv still no boot plus now i have no display during the lockup. I still have to ctrl+alt+del to get access to the grub selection screen to choose the older kernel.

Did you also try simply appending 3 (see comment #3) in Grub?

I will try that after 2:30pm EST, have to complete work day. nice and bad working from home.

Was unable to resolve the issue. Ended format install of Ubuntu 18.04 *sad face*

Things up and running at least.

Notes on the install

1. One of the fastest installs I have performed for any Distro/OS
2. apt-get is faster than in the past. Seems like a good updates to the code.
3. Still do not like sudo as the default process for accessing root level commands. Yes set a p/w asap for root to provide correct access to the root level commands.
4. Runs lighter than Fedorda did on the system.
5. Some basics that I am accustom to being in a distro were missing and had to be manually installed. vim as an example.
6. note* the CLI command convert requires editing to the configuration in order to merge PDF files.
7. VirtualBox & F@H both work without issues, fussing, editing, tweaking, etc...
8. Citrix Receiver installs without issue, but refuses to connect to any site I need it for. Still have to use the Chrome addin to access works VDI's.

All-in-all i am happy with what Ubuntu has become over the past decade plus.

mrmazda, thank you for attempting to help with the bad install i had on this laptop. I think when I last installed Fedora on this laptop I still had the SD card in the slot and that could have caused issues with stability as that SD card is both old and no longer stable.

I have been using Fedora for well over a decade, I am still happy with that distro, but for now I will keep my laptop on Ubuntu and might replace Fedora with Ubuntu on my workstation when I am able to return to my house. Stupid COVID-19

negative note: /etc/profile.d/ does not seem to work the way I am accustomed. Will make a new post on this issue for help.

edit to add:

Seems that Ubuntu does not properly handle freeing up RAM. This is an older laptop with only 8G RAM. After less than 48hr uptime the RAM would not clear and free up for new programs that needed access to RAM. I closed Chrome (memory hog to say the least) and paused F@H (Folding @ Home) to free up both RAM and CPU ticks. Attempted to start a VM (VirtualBox) and the system just locked hard. After roughly 30min I was able to issue shutdown -r now in a terminal to regain control over my system. After the reboot everything ran fine as the RAM was released from use. Bad on Ubuntu memory management.