Паника ядра - не синхронизируется: попытка убить init
Я использую buildroot версии-20011.02 для ядра, инструментальной цепочки и файловой системы. Моя настроенная плата ARMV7 cortexA9 SoC. Версия ядра - 3.18.41.
Соберите ядро (uImage), набор инструментов Buildroot, rootfs.tar.gz.
Включите файловую систему tyep ext4 в корне сборки, а также в ядре.
Распакуйте этот rootfs.tar.gz в / export / users / buildroot /.
экспорт этого каталога с помощью exportfs -a, exportfs -rv и перезапустите сервер nfs. Вроде все нормально на стороне сервера nfs.
Здесь я использую конфигурацию системы "make menuconfig" ->
Init system (BusyBox) --->
Даже пробовал с Init system (systemV) --->
с загрузочными параметрами как bootargs console=ttyAM0,115200n8 root=/dev/nfs rw rootwait ip=dhcp nfsroot=192.168.1.40:/export/users/buildroot,tcp,v3 init=/sbin/init
Каждый раз, когда я попадаю ниже журнала:
VFS: mounted fs via nfs
devtmpfs is mounted.
Kernel panic - not syncing:Attempted to kill init, exit code=0x000000b
Пожалуйста, помогите мне решить эту проблему.
Это вся стопка в журнале? Если есть еще, это может быть полезно.
Что такое / sbin / init? Это софтлинк на systemd или просто скрипт?
@AlexBender, я не пробовал использовать другую версию ядра, так как внес изменения в файл платы и другие исходные файлы, чтобы настроить это на нашу SoC. Я хочу придерживаться этого ядра, чтобы решить эту проблему. Если вы предлагаете, я дам попробуйте с другим ядром. Как вы думаете, это проблема с ядром? Да, я читал ссылку, которой вы поделились, похоже, командная строка ядра, т.е. bootargs правильная, поэтому ее установка на сервер nfs из журнала. Тем не менее, если вы чувствуете, что мне чего-то не хватает в bootargs, не стесняйтесь комментировать.
@kabanus, я согласен, было бы полезнее, если бы я поделился полным журналом, но извините, я работаю в такой безопасной среде. То, что я здесь помню, я делюсь. VFS: монтируется fs через nfs. Devtmpfs монтируется. Освобождение неиспользуемой памяти kenel ... Паника ядра - не синхронизация: попытка убить init, код выхода = 0x000000b. Кажется, ядро пытается найти этот init, но не может найти. Я предполагаю, что нам нужно отладить таким образом, что может быть проблемой, когда ядро может найти этот init после монтирования файловой системы nfs.
@ user2699113, это двоичный файл rootfs, это программная ссылка на / bin / busybox
@shaikhkamal, а как насчет того, чтобы не использовать NFS. Возможно ли это для вас?
есть аналогичная проблема: linuxquestions.org/questions/linux-kernel-70/…
@AlexBender, Изначально я пробовал использовать initramfs с включением всей конфигурации в ядре и buildroot для поддержки initramfs, но он вылетал. Пробовал с nfs, по крайней мере, я получаю лучшие результаты, затем я придерживаюсь этого nfs.
@AlexBender, Спасибо, что поделились этой ссылкой, да, это аналогичная проблема, но с одним отличием. Я не получаю никаких ошибок сегментации сразу после «Освобождение неиспользуемой памяти ядра ---». В этой ссылке проблема была решена libc.so .-- повреждение, даже ранее проверяли эту библиотеку зависимостей инициализации с помощью команды префикса компилятора -ldd, она показывала, что исходный libc.so softlink не найден, затем скопировал этот libc.so из buildroot в каталог nfs, затем создал такую же softlink, затем просто пропустил ядро проверка то время. завтра попробую ядро и обновлю вас
Поскольку я не разработчик ядра и не тот, кто знает его на достойном уровне - вам лучше спросить в каналах IRC, связанных с ядром и платами ARM. Это мое предложение. Несмотря на то, что я хочу помочь, у бутона нет необходимого уровня знаний.
Убедитесь, что / bin / busybox статически связан. Попробуйте связать другой статический двоичный файл вместо / bin / busybox (systemd?)
@AlexBender, я проверил arm-linux-ldd init - проверка зависимостей на не найдено. libc.so.0 => not found. (0x0000000), затем я проверил директорию rootfs lib, в которой эта библиотека уже есть, и правильно компоновала. кажется, что что-то пошло не так в двоичном файле инициализации.
@ user2699113, статически строить не хочу.
Ответы 1
Это может вам помочь.
Как вы сказали, есть журнал, как показано ниже.
Kernel panic - not syncing:Attempted to kill init, exit code=0x000000b
Это означает, что init (busybox) закрыт, а код выхода - 0xb.
Итак, ядро впадает в панику.
Возможно, это вызвано проблемой сети. Но пока мы не можем сделать вывод, что это связано с сетью или нет.
Вы сказали, что видели сбой без NFS. Я думаю, что устранение этого сбоя может быть лучшим способом решения этой ситуации.
Поделитесь журналом сбоев без конфигурации NFS. Если поделитесь логом, я его проверю.
Теперь я пробовал с initramfs, у меня все еще была такая же проблема, что и в nfs.
Одна вещь, которую я заметил, когда я отключил I-cache в ядре, он работает нормально, но я проверил с другими платами, такими как beaglebone, они включают этот I-cahe. Мне нужно с включенным I-cache, похоже, некоторая конфигурация ядра должна быть правильной. Кто-нибудь знает, как решить эту проблему с включением I-cache в ядре. Если у кого-то есть рабочая конфигурация ядра ARMv7 cortex a9 для buildroot, поделитесь, пожалуйста, пока я проверяю конфигурацию своего ядра.
Постарайтесь изолировать вашу проблему. Что, если вы соберете другую версию ядра? Полагаю, вы читали это kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt.