| Summary: | Kernel-panic VFS:Unable to mount root fs on unknown-block(0,0) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bjarne Thomsen <bjarne.thomsen> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | marja11, thierry.vignaud, zen25000 |
| Version: | 5 | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kernel-server-4.4.22-1/i686, grub2 | CVE: | |
| Status comment: | |||
| Attachments: |
journalctl -ab > NOcrash.txt an OK boot after a panic
journalctl -ab -1 > panic.txt /boot/grub2/grub.cfg |
||
|
Description
Bjarne Thomsen
2016-09-26 19:13:16 CEST
Marja Van Waes
2016-09-27 10:43:32 CEST
CC:
(none) =>
marja11 Could me a missing initrd What bootloader are you using? Keywords:
(none) =>
NEEDINFO 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
Thierry Vignaud
2016-09-27 12:55:34 CEST
CC:
(none) =>
zen25000 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) =>
OLD |