Created attachment 1077585 [details] picture of my laptop screen ater selecting kernel 4.1.7-200.fc86_64 for boot Description of problem: After performing a dnf update on my Fedora 22 Desktop, if I select kernel 4.1.7-200.fc22.x86_64 I get kernel panic. If I select the previous kernel 4.1.6-201.fc22.x86_64 it boots fine. Version-Release number of selected component (if applicable): kernel 4.1.7-200.fc22.x86_64 How reproducible: Each boot if I select the 4.1.7-200.fc22.x86_64 kernel version Steps to Reproduce: 1.boot 2.select 4.1.7-200.fc22.x86_64 Actual results: Attached screen shot shows call stack and kernel panic. Final message is: [Kerel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)] Expected results: Normal boot. Which I can get if I select any of the previous kernels at boot time.
99% of the time this is a result of one of 2 things: 1) There is no corresponding initramfs file in /boot for this kernel. Please verify it exists and is of similar size to the others. 2) The file exists, but is not specified in the grub configuration file. Please verify there is an "initrd initrams-<version>" line in the stanza for this kernel entry in the grub configuration file.
Thank you for the reply. As you suspected, there is no corresponding initramfs file present. [root@localhost boot]# ls -ltr initram* -rw-rw-r--. 1 root root 48004593 Sep 9 11:27 initramfs-0-rescue-d54d7dfac5f140cea416d7d4929d659f.img -rw-r--r--. 1 root root 19579536 Sep 9 12:23 initramfs-4.1.6-200.fc22.x86_64.img -rw-r--r--. 1 root root 19590831 Sep 12 14:53 initramfs-4.1.6-201.fc22.x86_64.img [root@localhost boot]#
Please attach /var/log/grubby and /boot/grub2/grub.cfg as individual text/plain attachments. Also the output of ls -l /boot/
Created attachment 1079048 [details] /var/log/grubby as requested
Created attachment 1079049 [details] grub.cfg grub.cnf file as requested.
Created attachment 1079050 [details] listing of /boot/ dir ls -l /boot/ as requested.
It looks like the initramfs creation failed for some reason so grubby didn't add it to the boot entry. Check dracut errors in /var/log/
I'm only seeing messages that refer to starting and stopping dracut or services with dracut in the name. No obvious errors. Please excuse my ignorance, but can I ask you when is the initramfs supposed to be created? Should this happen when I upgrade to a new kernel with dnf, or is there some command that should be running periodically or at boot time which is failing on my machine? I'm trying to determine whether this was just a fluke or will it happen for subsequent upgrades. Thank you very much for your help!
It should be created when installing a new kernel. I'm not sure what happened here, there just isn't enough info. You can try removing the kernel and reinstalling it with 'dnf reinstall kernel'
Since I created this post several dnf updates resulting in new Kernels seems to have resolved the problem described, however with the latest upgrade which brought in Fedora (4.2.7-200.fc22.x86_64) 22 (Twenty Two) the problem is back. I'm attaching a screen shot showing my available Kernel choices upon boot and only the top one causes the panic. And the second screen shot shows the screen after selecting the top Kernel. Do you know what might be causing this problem to occur on some releases on others it does not? Thank you, Chris Kaltwasser
Created attachment 1108030 [details] Screenshot of Fedora boot choices-the top one of which leads to panic This screenshot shows the available selections on boot for Fedora versions, only the top one of which leads to a Kernel panic.
Created attachment 1108032 [details] Screenshot of kernel panic after booting
(In reply to ChrisKalt from comment #12) > Created attachment 1108032 [details] > Screenshot of kernel panic after booting This looks like a missing initrd in /boot. Make sure you have "grubby" installed and not removed by accident. # rpm -q grubby Please also attach the output of: # journalctl -t dracut # ls -l /boot and attach /boot/grub2/grub.cfg
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days