这个内核恐慌的原因是什么？

有些输出是丢失的，因为它已经从屏幕上滚动了，但是可以看到内核在mount_root()崩溃了。 这意味着它在挂载根文件系统时遇到了问题。 检查以确保您已将正确的parameter passing给内核，以便从应该从其引导的任何介质启动。

这实际上是可能的。 您需要该特定发行版的debugging内核。

在一个单独的主机上。

• 下载该内核的kebug版本。 它将包含一个vmlinux文件。

在gdb中打开vmlinux文件。

 $ 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: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. 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. (gdb) 

从堆栈输出来看，我们可以在panic之前看到内核最有用的函数是mount_block_root 。

为了确定我们失败的地方，我们需要在GDB中join函数名和偏移量。 这是通过取消引用地址到函数，加上偏移量来完成的。 堆栈跟踪将该偏移量作为函数之后的第一个值。

IE mount_block_root+0x225意思是（我在“mount_block_root”加上549字节（hex翻译）。

最后，我们告诉GDB打印该区域的源代码。 在我的Linux系统中，结果如下

 (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"); 418 #endif 419 panic("VFS: Unable to mount root fs on %s", b); 420 } 421 422 printk("List of all partitions:\n"); 423 printk_all_partitions(); 424 printk("No filesystem could mount root, tried: "); 425 for (p = fs_names; *p; p += strlen(p)+1) 426 printk(" %s", p); 

从这里我们可以确切地知道我们在坠机的那一刻。 注意我的内核不是你的内核，所以偏移量可能是closures的。 基于这两个内核差不多相同的可能性，我会对冲一个赌注，真正的恐慌实际上发生在419行，而不是行422（正如所build议的）。

进一步阅读代码稍微指出，它是无法打开指定的块设备 – 但没有崩溃转储它不可能告诉为什么从信息。 所以它可能： –

• 你不想挂载一个块设备（可能）。
• 您指定了一个不存在的块设备地址（或分区）。
• 你的initrd在initrd中不包含正确的文件系统模块来挂载它。
• 磁盘上没有文件系统。
• 文件系统的超级块不在该位置的开头。

接下来从你的参考链接中，它表明你正在尝试以NFS为根来挂载，在这种情况下，你永远不应该最终登陆这个函数。 在这种情况下：

• 您的内核命令行包含多个根指令。
• 你错误地input了你的NFS地址，以至于它不能被正确parsing到你想要的真实函数（ mount_nfs_root ）中。

所以，总的来说，根据问题中的信息，我假设你已经省略了一些东西或者input了错字。

1. 引用的链接没有完成PXE引导Lubuntu 14.04所需的全部参数（追加行）。
2. 内核panic => mount因为1）无法正确执行。

你可以看到如何塞尔瓦在这里解决了正确的线（我与塞尔瓦发展有关） http://vercot.com/~serva/an/NonWindowsPXE3.html

Serva使用CIFS共享而不是NFS，但是如果您愿意，您可以很好地使用NFS。 当然你不需要使用Serva; 您可以在自己的PXE服务器中使用其参数

 [PXESERVA_MENU_ENTRY] asset = Lubuntu 14.04 Desktop Live platform = amd64 kernel = NWA_PXE/$HEAD_DIR$/casper/vmlinuz append = showmounts toram root=/dev/cifs initrd=NWA_PXE/$HEAD_DIR$/casper/initrd.lz,NWA_PXE/$HEAD_DIR$/casper/INITRD_N11.GZ boot=casper netboot=cifs nfsroot=//$IP_BSRV$/NWA_PXE_SHARE/$HEAD_DIR$ NFSOPTS=-ouser=serva,pass=avres,ro ip=dhcp ro 

请考虑

1. Ubunu / Lubuntu有一个错误，如果您使用CIFS进行PXE启动，则必须添加补充initrd INITRD_N11.GZ（可从Serva页面免费获得）
2. 如果您正在安装64位版本，则以前的参数要求您将文件\ casper \ vmlinuz.efi重命名为\ casper \ vmlinuz

我今天遇到了与Ubuntu 14.04相同的问题，而且相当令人讨厌，所以我想分享一下我在这里find的解决scheme…

我使用的是pxelinux.0，NFS用于根文件系统，TFTP用于提供内核映像和initramfs。 正如@MatthewIfe所提到的，查看堆栈回溯和被调用的函数清楚地表明这个问题发生在一个块设备相关的函数中，并且mount_nfs_root永远不会被调用。

所以我转向TFTP日志，正如这篇文章的作者所指出的 ，并指出我的configuration文件被命名为：

 tftproot/pxelinux.cfg/default 

也看起来像这样：

 DEFAULT vmlinuz LABEL Ubuntu 14.04 Blah Blah KERNEL vmlinuz APPEND initrd=initrd root=/dev/nfs nfsroot=192.168.1.123:/path/to/exportfs 

另外我的iPXE加载程序也在寻找其他文件，就像在post中：

 pxelinux.cfg/40709cda-a8e0-d411-8c6c-001e68e210ae pxelinux.cfg/01-00-1e-68-e2-10-ae pxelinux.cfg/C0A8010E pxelinux.cfg/C0A8010 pxelinux.cfg/C0A801 pxelinux.cfg/C0A80 pxelinux.cfg/C0A8 pxelinux.cfg/C0A pxelinux.cfg/C0 pxelinux.cfg/C pxelinux.cfg/default 

但是我没有看到initrd的日志被logging下来。 所以我决定testing一下，看看我的APPEND行是否有效。 所以我又添加了一个“恐慌= 10”，如同在post中一样。 而且它似乎不工作。 所以没有我的内核configuration线指令正在使用！ 在预感上，我决定做两件事 – 简化我的文件以匹配post

 DEFAULT linux LABEL linux KERNEL vmlinuz APPEND root=/dev/nfs nfsroot=192.168.1.123:/path/to/exportfs initrd=initrd panic=10 

并重新命名为类似的东西

 tftproot/pxelinux.cfg/01-00-1e-68-e2-10-ae 

而且 – initrd被拉下来，没有更多的内核恐慌，并且使用默认/通用内核和initramfs正确地挂载NFS作为根文件系统。 我确信我可以更换标签等。我认为实际的问题是configuration文件的命名和pxelinux.0的期望。

我做到了。 问题变得非常简单。 我给了PXE客户端一个3.13.0-30内核。 但是我在运行3.13.0-24内核的机器上运行mkinitramfs。

我开始给PXE客户端3.13.0-24内核，它的工作。