Fedora new kernel not working after dnf upgrade --refresh

Hi everyone!
I state I’m new in Linux world and there are a lot of basilar things I didn’t learn yet, so sorry for my ignorance. Moreover I’m Italian, so sorry again for the bad English :pensive:

Yesterday I installed Fedora 30 on my Asus VivoBook S14 with Intel Core i7-8565U CPU, Intel HD Graphics (Whiskey Lake), 8GB RAM and 1,0 TB HDD.
Once installed, I launched the command sudo dnf upgrade --refresh. It worked a couple of hours, apparently with success, then I restarted my PC. So it turned off, then the screen became black, than the “ASUS” logo came out, as usual, but then the OS never started. So I forced the turn off and after few seconds I restarted again. In that case “ASUS” came out and then appeared the menu with all the kernels, as in the picture:

I tried the first one (5.1.12-300) and the screen stayed black.
The second one (5.0.9-301) instead still work correctly.

Every time I try to turn on the pc I have to do it: i turn on, it gets stuck, I force the turn off, I turn on again, that menu appears and I select the 5.0.9-301.

The last week I already tried to install Fedora, but I had the same probem: I installed Fedora, then upgraded and the new kernel (in this case 5.1.7-300) got stuck so I had to return every time in 5.0.9-301. A friend suggested me to reinstall the OS so I tried, but the problem still remains.

So, my questions are:

  • Can I (and how) de-stuck the upgraded kernel?
  • If I can’t, can I (and how) set the 5.0.9 as the default kernel, so I don’t have to force the turn off every time?
  • Alternatively is possible (and how) to set something in way to make the menu appear whenever I turn on the PC?

Thanks to everyone for the help and the patience! :blush:

If it can help, this is the log file about yesterday evening:


(the forum didn’t allow me to put it in the topic because I’m a new user)

Ciao @vaffer
Sorry but such issue could be hard to debug. Do you have NVIDIA as a graphic card?
Maybe it could be useful to file a bug?
In addition, there is a newer version of the kernel (5.1.15-300) in the updates-testing repository: maybe it solves your issue? How to install it without permanently enabling the updates-testing repository? Issue this command:

sudo dnf update --enablerepo=updates-testing kernel

But pay attention! Check if the dnf transaction doesn’t want to remove the working kernel! In such case, stop the update (say no when asked to continue) and consider to raise the installonly_limit option in /etc/dnf/dnf.conf: more info in this other post.

You can use grubby.
To get the currently default kernel that will be loaded on boot:

sudo grubby --default-kernel

To set the 5.0.9 as the default one:

sudo grubby --set-default /boot/vmlinuz-5.0.9-301.fc30.x86_64

References: Working with the GRUB 2 Boot Loader

By default the grub menu doesn’t appear on Fedora 30. It only appears if something in the previous boot has gone wrong. References: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

You can let the menu appear by keeping SHIFT key pressed during the boot (at the early stages, just after the BIOS messages). Or you can permanently unhide the grub menu issuing this command from the Fedora terminal:

sudo grub2-editenv - unset menu_auto_hide

References: https://hansdegoede.livejournal.com/19081.html

Hello @vaffer, and sorry you are having this inconvenience. To answer your question about the default kernel that boots, I’ll just CP something from the Administrators Guide…
`
Listing the Default Kernel

To find out the file name of the default kernel, enter a command as follows:

~]# grubby --default-kernel
/boot/vmlinuz-4.2.0-1.fc23.x86_64

To find out the index number of the default kernel, enter a command as follows:

~]# grubby --default-index
0

Changing the Default Boot Entry

To make a persistent change in the kernel designated as the default kernel, use the grubby command as follows:

~]# grubby --set-default /boot/vmlinuz-4.2.0-1.fc23.x86_64

Viewing the GRUB Menu Entry for a Kernel

To list all the kernel menu entries, enter a command as follows:

~]$ grubby --info=ALL

On UEFI systems, all grubby commands must be entered as root.`

The entire doc is here …Working with Grub2.

You likely will find your (?broken?) kernel is index 0 and the one you can boot (the previous one) is index 1. In any case I see you have an Intel Graphics chip, and I don’t think that is the issue. There is also a magazine article about the dracut shell that is probably where you find yourself in the kernel that doesn’t complete bootup. It is here. If you boot into the working kernel, there is a lot you can do to get the new one working, and it starts with grubby with grubby --info=ALL (add sudo at front if your PC is EFI, which it very likely is). That will list all the kernels then merely use grubby --set-default /boot/your kernel choice. I hope this helps you solve this issue.

Thanks both, now I see the GRUB everytime I turn on, so at least is easier.
I removed the ‘broken’ kernel, so I don’t risk to lost the working one doing the new update. I’ll make you know very soon, but in every case I dubit the problem will be resolved in this way. The last week I installed, upgraded and the 5.7.1-300 didn’t work, then upgraded again and 5.1.12-300 didn’t work, so reinstalled all, upgraded again and still not working. I think it’s impossible that depends on something I did wrong (the last time I only upgraded) , but maybe on something depending by the hardware (drivers?).
Anyway I’m going to upgrade again to 5.1.15, let’s see what happens.

Thanks for the advices :blush:

1 Like

Just installed 5.1.15-300 but nothing changed: I did the reboot, selected 5.1.15 from the grub (that now is always shown) and then black screen forever, so I had to force the shut down.

Still need help :pensive:

Another thing you can do to have a better view of what it is happening, it is to remove quiet and see the boot messages.
You can do that hitting ESC while Fedora is loading. Or you can remove from the kernel options, editing the grub menu entry at runtime, or permanently by issuing this command from the Terminal (you can re add them later):

sudo grubby --update-kernel=ALL --remove-args="rhgb quiet"

BTW, probably the boot process completes, but the black screen pops up when starting the graphical interface.

And you can inspect the logs
This command show you the previous boot logs (supposing that now you booted whit the working kernel, while the previous boot was the unsuccessful one).

journalctl -b -1

Maybe, supposing that the problem is related to GDM, try to limit the logs to it

journalctl -b -1 -u gdm

Viewing logs on Fedora

I removed quiet and discovered that when I select the 5.0.9-301 it comes out the long list of green [OK] on the left and white descriptions on the right (so everithing ok), while if I select the 5.1.12-300 the message is:
" EFI stub: UEFI Secure Boot is enabled
_"

and then it gets stuck.

About the log, them start from the boot in 5.0.9, there is no trace about the previous boot.

Interesting.
So, booting whit a kernel other than 5.0.9, the boot process not even start. It stops right with this “EFI stub” message, I understand you correctly?

Exactly. If it can help, it seems this same bug: 1500057 – Boot crash after "EFI stub: UEFI Secure Boot is enabled." on Surface Book
Comment 5 proposes a solution, but I have no idea about how can I do that and what it means :thinking:

When you have updated the kernel, you updated only this package or did you upgraded all the packages with sudo dnf update?

This is also interesting Bug #1829620 “i7-8565U, sig=0x806eb/20190514, intel-microcode on...” : Bugs : linux package : Ubuntu even if it is related to Ubuntu. And it seems a little bit complicated from my point of view. :confused:

The first time I did sudo dnf update --refresh, the second time (today) I used sudo dnf update --enablerepo=updates-testing kernel as you suggested in the first reply.

To be honest it goes completely out of my ability to understand and adapt it to my situation. Can you translate in a more basic sequence of things I should do?

1 Like

So, a temporary workaround seems to pass dis_ucode_ldr to the kernel:

sudo grubby --update-kernel=/boot/vmlinuz-5.1.12-300.fc30.x86_64 --args="dis_ucode_ldr"

Check if “/boot/vmlinuz-5.1.12-300.fc30.x86_64” is the right syntax.
Then, on boot, select this kernel.

(--update-kernel=/boot/vmlinuz-5.1.12-300.fc30.x86_64 will configure this option only for this specific entry, leaving untouched the working 5.0.9)

What do you think? Can you try?

1 Like

Wooo nice job, I’m writing from kernel 5.1.15-300 now! I’ll need to do this thing every time I update?

1 Like

Now this option is passed only to 5.1.15-300
I’m not pretty sure how to automatically add this argument to the future kernels.
Maybe issuing the grubby command with --update-kernel=ALL it will modify the current ones, as well as the future ones. BTW it will also affect the working 5.0.9
In any case, you can also modify kernel arguments when the grub menu appears (in this case they will not be persistent).

At this point I would open a bug: how to file a bug. Specifying the computer model, and the fact that whit 5.0.9 it works, while with 5.1.7, 5.1.15 and so on (try to be more precise than me with the version numbers) it doesn’t work, it stay stuck at EFI stub: UEFI Secure Boot is enabled. And what is the workaround. I can’t find a similar bug on bugzilla; however if someone else already reported such issue, your bug will be marked as duplicate: it matters little.

There is another thing I would like to try, if you want.
Revert to the previous status:

sudo grubby --update-kernel=ALL --remove-args="dis_ucode_ldr"

And then

sudo dnf  distrosync microcode_ctl --disablerepo=updates

Finally, reboot and select the latest kernel (5.1.15-300 in your case).

If the problem persists, reboot to 5.0.9 and apply again the workaround:

sudo grubby --update-kernel=/boot/vmlinuz-5.1.15-300.fc30.x86_64 --args="dis_ucode_ldr"
1 Like

Just tried various combinations, at least I concluded that:

sudo grubby --update-kernel=ALL --remove-args="dis_ucode_ldr"
sudo dnf  distrosync microcode_ctl --disablerepo=updates

Doesn’t work, the same problem reappears.
Indeed with:

sudo grubby --update-kernel=ALL--args="dis_ucode_ldr"

all the kernels works fine, also 5.0.9-300.

I opened a bug: 1724262 – Fedora doesn't boot in ASUS VivoBook after update

Thanks a lot for the help, I’d never have made it out by myself.
Have a nice day :blush:

1 Like

Thank you all for your help, I have been researching/fighting this for almost 3 weeks now. I installed fedora on my Vivobook and have experienced the exact same issues. The grubby fix resolved this for me and I will continue to watch the bug. I just wanted to say thanks for the help!