В чем причина паники ядра?

Это действительно возможно. Вам понадобится ядро ​​отладки для этого конкретного дистрибутива.

На отдельном хосте.

• Загрузите версию этого ядра для kebug. Он будет содержать vmlinux файл.

Откройте файл vmlinux в 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:
<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) 

Судя по выходным данным стека, мы видим, что до паники наиболее полезной функцией ядра была mount_block_root.

Чтобы определить где мы потерпели неудачу, нам нужно ввести имя функции и смещение в GDB. Это делается путем отмены ссылки на адрес функции и смещение. Трассировка стека предоставляет смещение как первое значение после функции.

I.E mount_block_root+0x225 значит (у меня был "mount_block_root" плюс 549 байт (шестнадцатеричный перевод).

Наконец, мы говорим 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);

Отсюда мы можем точно сказать, где мы были в момент крушения. НОТА мое ядро не ваше ядро, поэтому смещения, вероятно, отключены. Основываясь на вероятности того, что оба этих ядра почти одинаковы, я хеджирую пари, что настоящая паника действительно происходит в строке 419, а не в строке 422 (как было предложено).

Дальнейшее чтение кода немного указывает на то, что ему не удалось открыть указанное блочное устройство, но без аварийного дампа невозможно определить причину по этой информации. Так что это вероятно: -

• Вы не хотите монтировать блочное устройство (скорее всего).
• Вы указали несуществующий адрес блочного устройства (или раздела).
• Ваш initrd не содержит соответствующего модуля файловой системы в initrd для его монтирования.
• На диске нет файловой системы.
• Суперблок файловой системы не находится в начале этого места.

Следуя ссылке в вашей ссылке, предполагается, что вы пытаетесь монтировать с NFS в качестве корневого, и в этом случае вам следует никогда в конечном итоге вообще попадают в эту функцию. В таком случае:

• Командная строка вашего ядра содержит несколько корневых директив.
• Вы неправильно ввели свой адрес NFS, так что он не будет правильно проанализирован, чтобы перейти к реальной функции, которую вы хотите (mount_nfs_root).

Итак, в целом, основываясь на информации в вопросе, я предполагаю, что вы что-то упустили или допустили опечатку.

Некоторая часть вывода отсутствует, так как она уже прокручена за пределы экрана, но можно увидеть, что ядро ​​разбилось в mount_root(). Это означает, что у него возникла проблема с монтированием всего, что вы передали в качестве корневой файловой системы. Убедитесь, что вы передали ядру правильные параметры для загрузки с любого носителя, с которого оно должно загружаться.

1. В указанной ссылке отсутствует полный набор параметров (строка добавления), необходимых для загрузки Lubuntu 14.04 с помощью PXE.
2. Паника ядра => монтирование не может быть выполнено правильно из-за 1).

Вы можете увидеть, как Serva решила правильные строки здесь (я связан с разработкой Serva) 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 есть ошибка: если вы загружаете их с помощью PXE, используя CIFS, вы должны добавить дополнительный initrd INITRD_N11.GZ (свободно доступный на странице Serva)
2. Если вы устанавливаете 64-битную версию, прежние параметры требуют, чтобы вы переименовали файл \ casper \ vmlinuz.efi в \ casper \ vmlinuz

Сегодня у меня была такая же проблема с Ubuntu 14.04, и это было довольно неприятно, поэтому я хочу поделиться решением, которое я нашел, со всем миром здесь ...

Я использовал pxelinux.0, NFS для корневой файловой системы и TFTP для обслуживания образа ядра и initramfs. Как упоминалось выше @MatthewIfe, просмотр трассировки стека и вызываемых функций ясно указывает на то, что эта проблема возникла в функции, связанной с блочным устройством, и mount_nfs_root никогда не вызывалась.

Итак, я обратился к журналам TFTP, как указал автор эта почтаи отметил, что мой файл конфигурации был назван так:

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 также искал другие файлы, как в сообщении:

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. Поэтому я решил протестировать и посмотреть, работает ли моя строка APPEND вообще. Поэтому я добавил «panic = 10», опять же, как в связанном посте. И вроде бы не работало. Так что ни одна из моих директив строки конфигурации ядра не использовалась! Думая, я решил сделать две вещи - упростить свой файл, чтобы он соответствовал сообщению.

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 отключается, больше нет проблем с ядром, и NFS правильно монтируется как корневая файловая система с использованием ядра по умолчанию / общего ядра и initramfs. Я уверен, что могу снова изменить метку и т. Д. Я думаю, что на самом деле проблема была в названии файла конфигурации и в том, что ожидает pxelinux.0.

Я сделал это. Проблема оказалась очень простой. Я дал PXE-клиенту ядро ​​3.13.0-30. Но я запускал mkinitramfs на машине с ядром 3.13.0-24.

Я начал давать клиенту PXE ядро ​​3.13.0-24, и оно сработало.