LINUX.ORG.RU

kernel panic - not syncing: no init found. Линух на Спарке


0

0

Добрый день.

Имеется Linux c initrd, загружается нормально на Sparc процессоре. Захотелось выкинуть initrd. Пересобрал новое ядро, вкомпилил в него драйвер Сановского prom (диск с образом ядра и ФС располагается в prom), теперь выдает сообщение

kernel panic - not syncing: no init found. Try passing init = option to kernel

Кто может подсказать, в какую сторону рыть? Каким образом ядро подмонтирует диск (sunhv_disk), если проги типа udev ещё не запущены?


Ответ на: комментарий от nnz

#!/bin/sh

echo «Loading, please wait...»

[ -d /dev ] || mkdir -m 0755 /dev
[ -d /root ] || mkdir --mode=0700 /root
[ -d /sys ] || mkdir /sys
[ -d /proc ] || mkdir /proc
[ -d /tmp ] || mkdir /tmp
mkdir -p /var/lock
mount -t sysfs none /sys -onodev,noexec,nosuid
mount -t proc none /proc -onodev,noexec,nosuid

# Note that this only becomes /dev on the real filesystem if udev's scripts
# are used; which they will be, but it's worth pointing out
mount -t tmpfs -o mode=0755 udev /dev
[ -e /dev/console ] || mknod /dev/console c 5 1
[ -e /dev/null ] || mknod /dev/null c 1 3

/dev/.initramfs-tools

mkdir /dev/.initramfs

# Export the dpkg architecture
export DPKG_ARCH=
. /conf/arch.conf

# Export it for root hardcoding
export ROOT=

# Bring in the main config
. /conf/initramfs.conf
for i in conf/conf.d/*; do
   [ -f ${i} ] && . ${i}
done
. /scripts/functions

# Parse command line options
export break=
export init=/sbin/init
export quiet=n
export readonly=y
export rootmnt=/root
export debug=
export cryptopts=${CRYPTOPTS}
export panic

for x in $(cat /proc/cmdline); do
   case $x in
   init=*)
      init=${x#init=}
      ;;
   root=*)
      ROOT=${x#root=}
      case $ROOT in
      LABEL=*)
         ROOT=«/dev/disk/by-label/${ROOT#LABEL=}»
         ;;
      UUID=*)
         ROOT=«/dev/disk/by-uuid/${ROOT#UUID=}»
         ;;
      /dev/nfs)
         BOOT=nfs
         ;;
      esac
      ;;
   rootflags=*)
      ROOTFLAGS="-o ${x#rootflags=}"
      ;;
   rootfstype=*)
      ROOTFSTYPE=«${x#rootfstype=}»
      ;;
   rootdelay=*)
      ROOTDELAY=«${x#rootdelay=}»
      ;;
   loop=*)
      LOOP=«${x#loop=}»
      ;;
   loopflags=*)
      LOOPFLAGS="-o ${x#loopflags=}"
      ;;
   loopfstype=*)
      LOOPFSTYPE=«${x#loopfstype=}»
      ;;
   cryptopts=*)
      cryptopts=«${x#cryptopts=}»
      ;;
   nfsroot=*)
      NFSROOT=«${x#nfsroot=}»
      ;;
   netboot=*)
      NETBOOT=«${x#netboot=}»
      ;;
   ip=*)
      IPOPTS=«${x#ip=}»
      ;;
   boot=*)
      BOOT=${x#boot=}
      ;;
   resume=*)
      RESUME=«${x#resume=}»
      ;;
   noresume)
      NORESUME=y
      ;;
   panic=*)
      panic=«${x#panic=}»
      ;;
   quiet)
      quiet=y
      ;;
   ro)
      readonly=y
      ;;
   rw)
      readonly=n
      ;;
   debug)
      debug=y
      exec >/tmp/initramfs.debug 2>&1
      set -x
      ;;
   debug=*)
      debug=y
      set -x
      ;;
   break=*)
      break=${x#break=}
      ;;
   break)
      break=premount
      ;;
   esac
done

if [ -z «${NORESUME}» ]; then
   export resume=${RESUME}
fi

depmod -a
maybe_break top

# Don't do log messages here to avoid confusing usplash
run_scripts /scripts/init-top

maybe_break modules
log_begin_msg «Loading essential drivers...»
load_modules
log_end_msg

maybe_break premount
[ «$quiet» != «y» ] && log_begin_msg «Running /scripts/init-premount»
run_scripts /scripts/init-premount
[ «$quiet» != «y» ] && log_end_msg

maybe_break mount
log_begin_msg «Mounting root file system...»
. /scripts/${BOOT}
parse_numeric ${ROOT}
mountroot
log_end_msg

maybe_break bottom
[ «$quiet» != «y» ] && log_begin_msg «Running /scripts/init-bottom»
run_scripts /scripts/init-bottom
[ «$quiet» != «y» ] && log_end_msg

# Move virtual filesystems over to the real filesystem
mount -n -o move /sys ${rootmnt}/sys
mount -n -o move /proc ${rootmnt}/proc

while [ ! -x ${rootmnt}${init} ]; do
   panic «Target filesystem doesn't have ${init}»
done

# Confuses /etc/init.d/rc
if [ -n ${debug} ]; then
   unset debug
fi

# Chain to real filesystem
maybe_break init
exec run-init ${rootmnt} ${init} «$@» <${rootmnt}/dev/console >${rootmnt}/dev/console

alexvm
() автор топика
Ответ на: комментарий от alexvm

Вот, собственно..

SILO запускается с параметром root=/dev/sunhv_disk

alexvm
() автор топика

kernel panic - not syncing: no init found.

Обычным образом, на x86 используется модули для контроллера ATA (обычно в initrd), выбранной системы разделов, драйвер fs. Без инитрд надо добавить опции root=/dev/xxx, инит должен находиться на rootfs где надо (/sbin/init), файлы создаются вручную статически с помощью mknod.

gena2x ★★★
()
Ответ на: комментарий от gena2x

# which init /sbin/init

/kernel root=/dev/xxx init=/sbin/init

как-то так это должно выглядеть в загрузчике.

azure ★★
()
Ответ на: комментарий от alexvm

Нда, долбаный дебиан. Все раскидано по сотне скриптов.

Тогда смотри модули, которые подгружаются из initrd (grep --with-filename --line-number modprobe `find initrd/scripts/ -type f`) и попробуй их всех вкомпилить монолитно.

Убедись, что root (устройство с корневым разделом) и init (путь до init в корневом разделе) в параметрах ядра указаны правильно.

nnz ★★★★
()
Ответ на: комментарий от nnz

Всё сделал, как советовали умные люди - результат тот же. Походу, до драйвера даже дело не доходит, зависает раньше. Интересно, как ядро прошаривает, что надо использовать драйвер sunhv_disk?

alexvm
() автор топика
Ответ на: комментарий от alexvm

Если у вас ядро зависает и вы не можете прочитать все его сообщения, попробуйте дать «rootdelay=100» в параметры загрузки ядра, тогда можно будет почитать, какие драйвера в ядре загрузились и какое оборудование нашли.

Потом попробуйте добавить в ваше ядро поддержку initrd, и загрузиться с существующим initrd, может вы выключили поддержку нужного формата исполянемых файлов или ещё чего. Потом попробуйте создать свой initrd без модулей. Может на вашей корневой ФС не хватает каких-нибудь файлов-устройств.

mky ★★★★★
()

Была аналогичная проблема, в моем случае оказалось, что в ядро не была вкомпилена поддержка моего сата-контроллера. аналогичные симптомы может давать не вкомпиленная в ядро поддержка ФС, в которой отформатирован корневой раздел

WizardOfOz
()
Ответ на: комментарий от mky

> Потом попробуйте добавить в ваше ядро поддержку initrd, и загрузиться с существующим initrd, может вы выключили поддержку нужного формата исполянемых файлов или ещё чего. Потом попробуйте создать свой initrd без модулей. Может на вашей корневой ФС не хватает каких-нибудь файлов-устройств.

Проблема в том, что проги на старом initrd компилировались с ядром 2.6.22 под Ubuntu, а я собираю систему clfs на ядре 2.6.30. Могут ли проги со старого initrd запускаться с более свежими библиотеками и ядром? Я в сасмом начале так и сделал, но Линух зависал после загрузки без паники.

alexvm
() автор топика
Ответ на: комментарий от alexvm

Проблема в том, что проги на старом initrd компилировались с ядром 2.6.22 под Ubuntu, а я собираю систему clfs на ядре 2.6.30. Могут ли проги со старого initrd запускаться с более свежими библиотеками и ядром? Я в сасмом начале так и сделал, но Линух зависал после загрузки без паники.

Могут, почему нет. Только основная фишка initrd в том что он загружает драйверы и всё, больше ничего не должен делать. Вообще зачем был сделан initrd? чтобы не висела в памяти куча модулей которые могут понадобиться ДО монтирования rootfs и потому не могут быть положены на rootfs в виде модулей. Если своё ядро собираешь проще обойтись без initrd вообще, или сделать своё. Но вообще надо его распаковать и посмотреть что там linuxrc.

gena2x ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.