It is actually possible. You need the debug kernel for that particular distro.
On a seperate host.
- Download the kebug version of that kernel. It will contain a
Open the vmlinux file in gdb.
$ gdb /usr/lib/debug/lib/modules/3.14.9-200.fc20.x86_64/vmlinux
GNU gdb (GDB) Fedora 7.7.1-13.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/debug/lib/modules/3.14.9-200.fc20.x86_64/vmlinux...done.
Judging from the stack output, we can see prior to the panic the most useful function the kernel was in was
In order to determine where we failed, we need to feed in the function name plus an offset into GDB. This is done by de-referencing the address to the function, plus the offset. The stack trace supplies the offset as the first value after the function.
mount_block_root+0x225 means (I was at "mount_block_root" plus 549 bytes (the hexadecimal translation).
Finally, we tell GDB to print the source code of that area. In my Linux system, this results in the following
(gdb) list *(mount_block_root+0x225)
0xffffffff81d26513 is in mount_block_root (init/do_mounts.c:422).
417 "explicit textual name for \"root=\" boot option.\n");
419 panic("VFS: Unable to mount root fs on %s", b);
422 printk("List of all partitions:\n");
424 printk("No filesystem could mount root, tried: ");
425 for (p = fs_names; *p; p += strlen(p)+1)
426 printk(" %s", p);
From here we can tell exactly where we were at the point of the crash. NOTE my kernel is not your kernel, so the offsets are probably off. Based off of the likelihood that both these kernels are nearly the same, I'll hedge a bet that the real panic actually occurs at line 419, not line 422 (as was suggested).
Reading further up the code slightly indicates it was unable to open the block device specified -- but without a crash dump its not possible to tell why from the information. So its probably:-
- You dont want to mount a block device (likely).
- You specified a non-existent block device address (or partition).
- Your initrd, does not contain the proper filesystem module in the initrd to mount it.
- There is no filesystem on the disk.
- The superblock for the filesystem is not at the beginning of that location.
Following on from the link in you're reference, it suggests you are trying to mount with NFS as the root, in which case you should never end up landing in this function at all. In which case:
- Your kernel command line contains multiple root directives.
- You have mistyped your NFS address such that it does not get parsed correctly to go into the real function you want (
So, overall based off of the information in the question I assume you have omitted something or made a typo.