Created attachment 1515944 [details]
Photo captions of described problem
Description of problem:
Latest kernels 4.19.18 (fixed see below) and 4.19.19 wont boot (after dnf upgrade).
I think that the initramfs is not loaded, because of the describing kernel panic info. The older kernels are in the same partition and have not filesystem error (checked with usb boot linux rescue).
Version-Release number of selected component (if applicable):
Latest kernels after upgrade.
Latest kernel allways in some machines that i have tryed, more one core-i7 ones (with Asus P8Z68 chipset).
4.19.8 fixed by:
mkinitrd and grub2-mkconfig, fixed by booting from 4.19.5
4.19.9 cant boot even recreating initrd and grub2 config.
Steps to Reproduce:
1. Had the system installed (Fedora 29 Server)
2. Upgrade with dnf
1. The computer load the grub2 code and i can enter in editor and select kernels.
--> The latest kernels 4.18.x and 4.19.x needed some freaking grub2-mkconfig to boot (had to select an early one that boots to system and then fix)... but for remote machines that's bad. <--
2. Select newer kernel the grub2 write to console:
"Error: unknown filesystem."
.... several lines repeated until....
"Press any key to continue..."
If i press CTRL+ALT+DEL i can reboot the machine and select other, older, kernel and go.
but if i press "enter" the kernel boots but then it then panics:
Kernel panic - not syncing: VFS Unable to mount root fs on unknown-block(0,0)
CPU 3 PID: 1 Comm: swapper/0 Not tainted 4.19.9-300.fc29.x86-64 #1
Hardware name: System manufacturer System Product Name/P8Z68 DELUXE, BIOS 3304 04/17/2012
Kernel Offset: (....) from (.....) (relocation range: ....)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
Boot the system like the older kernel.
This problem is affecting some machines only. In some of them basically grub2-mkconfig -o /boot/grub2/grub.cfg fixes the problem. But this 4.19.9 version don't want to load.
In other machines (core 2 duos / core 2 quad / core i3) the problem doesn't manifest - i had used in remote console dnf update ... without any problem.
In this 2 machines the problem insists to not go away:
I had to stick with 4.19.8 in one, and other (remote) i cannot do the upgrade from 4.19.6 until i go there because i don't trust the process right now.
During last update for kernel 4.9.10 the problem went away (there were other packages involved in, libc included and other system wide libs) that might fix the issue. I will reopen this bug if the problem returns.
Best regards to all.