Description of problem: Kernel-panic VFS: Unable to mount root fs on unknown-block(0,0) But it works fine when I boot in recovery mode. Version-Release number of selected component (if applicable): kernel-server-4.4.22-1 (i686) How reproducible: Always Steps to Reproduce: 1. 2. 3. I am mounting root on a btrfs. Is this a problem?
CC: (none) => marja11Assignee: bugsquad => kernel
Could me a missing initrd What bootloader are you using?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
I forgot to mention that the same thing happened to kernel-server-4.4.21-1 But then shortly after came kernel-server-4.4.21-2 and the default boot worked again. I have now made soft links from 4.4.21-2 to vmlinuz-server and initrd-server.img and I am now booting from 4.4.21-2. grub2
CC: (none) => zen25000Assignee: kernel => bugsquadSource RPM: kernel-server-4.4.22-1/i686 => kernel-server-4.4.22-1/i686, grub2
What is the output of ls -al /boot | grep initrd
-rw-r--r-- 1 root root 10203324 Sep 20 22:33 initrd-4.4.21-server-2.mga5.img -rw-r--r-- 1 root root 10202648 Sep 25 05:09 initrd-4.4.22-server-1.mga5.img lrwxrwxrwx 1 root root 31 Sep 27 05:51 initrd.img -> initrd-4.4.21-server-2.mga5.img lrwxrwxrwx 1 root root 31 Sep 27 05:50 initrd-server.img -> initrd-4.4.21-server-2.mga5.img I did change the links this morning. But now I have just tried to boot specifically 4.4.22-server-1 and it worked! I do not understand what is going on. I am going to create the original links.
I used the MCC to re-create the boot loader. It crashed again when doing a default boot. But, as before, it booted fine when I specifically selected the 4.4.22-server kernel in the boot menue. -rw-r--r-- 1 root root 10203324 Sep 20 22:33 initrd-4.4.21-server-2.mga5.img -rw-r--r-- 1 root root 10202648 Sep 25 05:09 initrd-4.4.22-server-1.mga5.img lrwxrwxrwx 1 root root 31 Sep 27 20:27 initrd.img -> initrd-4.4.22-server-1.mga5.img lrwxrwxrwx 1 root root 31 Sep 27 20:27 initrd-server.img -> initrd-4.4.22-server-1.mga5.img So, what is the difference from the previous case?
It does NOT reproduce! This time it crashed when I specifically selected the 4.4.22 kernel. Recovery still works.
So, regardless of whether kernel 4.4.22 is booted as default, or booted because manually selected: sometimes there's a kernel panic and other times there isn't. Please reproduce the crash and then boot up again with the _same_ kernel-server-4.4.22, until it doesn't crash and you can log in. Then, as root, do: journalctl -ab > NOcrash.txt and journalctl -ab -1 > panic.txt and attach both files to this bug report.
Assignee: bugsquad => kernel
the second command might not do what I want: if it was impossible to mount /, then no logs were written :-(
Created attachment 8458 [details] journalctl -ab > NOcrash.txt an OK boot after a panic I have never seen a correct boot after letting it boot by itself. To obtain a correct boot I moved many times betwen "Mageia" and "Advanced options" before I finally pressed "Mageia". Is this a timing problem?
Created attachment 8459 [details] journalctl -ab -1 > panic.txt This journalctl took about 20 m.
(In reply to Bjarne Thomsen from comment #10) > Created attachment 8459 [details] > journalctl -ab -1 > panic.txt Most likely from the one-but-last succeeding boot, as I feared (i don't see a crash) > > This journalctl took about 20 m. I don't understand, what exactly took 20 minutes? Those logs start at Sep 28 13:04:14 and end at Sep 28 13:16:26, the end time is slightly more than two minutes before the last succeeding boot log (which starts at Sep 28 13:18:42) I assume the kernel panic boot was in between 13:16:26 and 13:18:42?
journalctl won't help here indeed as the boot process hangs before mounting / Can you attach your /boot/grub2/grub.cfg file?
Created attachment 8461 [details] /boot/grub2/grub.cfg
I have installed the desktop i686 version of 4.4.22 on 3 old netbooks with 1GB and 2GB of memory. These 3 i586-systems boots fine using grub2. The system with the boot problem is an Intel MB with 8GB of memory, so the server kernel was selected. Note: The grub2 boot works with 4.4.21-server-2.
Just noticed that you filed bug 17966 for the same issue, with earlier kernels. That wasn't what I was looking for, though, I thought someone had switched all his 32bit kernel-server installs to 64 bit installations. If he filed a bug report, then I'm looking over it. I'll close that one, because this one contains more recent information
*** Bug 17966 has been marked as a duplicate of this bug. ***
I had forgotten about this old report. The reason is that it went away after an update.
It works now with kernel-server-4.4.30-1.mga5
I am sorry, this bug is back again with kernel-server-4.4.30-2.mga5.
As usual kernel-server-4.4.36-1.mga5 boots korrectly, however kernel-server-4.4.36-2.mga5 gives kernel panic. what is actually done between *-1 and *-2 ?
History repeats itself. New kernals have booted correctly until now. This bug is now back in kernel-server-4.4.59-1.mga5
Actually I a solution. I keep one kernel installed, only. After the next kernel install I remove the old kernel. Now, this problem never happens. I have no idea why.
(In reply to Bjarne Thomsen from comment #22) > Actually I a solution. I keep one kernel installed, only. > After the next kernel install I remove the old kernel. > Now, this problem never happens. I have no idea why. Do you still need to do that in Mageia 6, to avoid hitting this bug? If so, then please reopen this report and change Version: to 6 Closing as OLD, because Mageia 5 is no longer maintained at all.
Resolution: (none) => OLDStatus: NEW => RESOLVED