Как найти / sbin / init во время загрузки lilo

694
Martin Drautzburg

Я просто клонировал свой корневой раздел (в ожидании dist-upgrade), изменил lilo.conf и fstab (в клонированном разделе) и запустил lilo.

Но, увы, система не загрузится с клонированного раздела. Я вижу несколько страниц не подозрительных сообщений ядра, а затем просто останавливается.

По какой-то причине я попытался загрузиться с хорошего раздела, добавив init=/bin/shи снова система не загрузилась и остановилась на том же сообщении ядра. Это заставило поверить, что «с init что-то не так».

Поэтому я решил перевернуть таблицы и прошел init=/sbin/initпри загрузке с «плохого» раздела, и это действительно сработало - система загрузилась просто отлично.

Но я не понимаю, что здесь происходит. У кого-нибудь есть объяснение этому?

Вот мой лило, конф

# Automatically added by lilo postinst script large-memory  lba32 boot=/dev/sda root=/dev/sda3 install=/boot/boot.b prompt delay=30 timeout=30 vga=normal  default="Linux-3.8.2"  image=/boot/vmlinuz-3.8.2-ext4 root=/dev/sda3 label="Linux-3.8.2" vga=0x317  image=/boot/vmlinuz-3.8.2-ext4 root=/dev/sdd3 label="Linux-3.8.2-bak" vga=0x317

Изменить: это сообщения ядра

[ 3.258242] sd 6:0:0:1: [sdf] Assuming drive cache: write through [ 3.262845] sd 6:0:0:1: [sdf] Attached SCSI removable disk

если это останавливается, то в этот момент, и я не вижу ничего из этого:

[ 3.490096] firewire_core 0000:07:06.0: created device fw0: GUID 00ca308600001a4d, S400 [ 3.513091] nvidia: module license 'NVIDIA' taints kernel. [ 3.517657] Disabling lock debugging due to kernel taint [ 3.818951] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [ 3.823236] NVRM: loading NVIDIA UNIX x86 Kernel Module 310.40 Sun Mar 3 20:44:11 PST 2013
2
Если изменение параметра `init = ...` не приводит к изменению поведения, скорее всего, процедура загрузки завершится неудачно ** перед ** запуском init ... Levans 11 лет назад 0
Но Мартин написал, что изменение его на `init = / sbin / init` заставляет систему загружаться правильно. Поведение странное. Ядро Linux должно искать `/ sbin / init` по умолчанию, и если оно не может выполнить` init`, оно должно заканчиваться паникой ядра. pabouk 11 лет назад 0
Передача init = / bin / sh также не приводит к панике ядра. И при этом это не запускает раковину. Martin Drautzburg 11 лет назад 0
@MartinDrautzburg: Какие последние сообщения перед остановкой инициализации ядра? Что показывает после этих сообщений, когда система загружается правильно? Чтобы увидеть сообщения, вы можете попытаться прокрутить назад, используя Shift + PgUp, или вы можете попробовать параметр ядра `boot_delay = 500`. Также относительно `/ bin / sh`: вероятно, он динамически связан. Если да, находятся ли динамические библиотеки в корневой файловой системе? pabouk 11 лет назад 0
@MartinDrautzburg: Считаете ли вы, что до точки замораживания обе системы имеют одинаковые загрузочные сообщения? Я бы попробовал следующее: ** в рабочей системе **: `dmesg | grep 'Командная строка:'` и `cat / proc / cmdline`, чтобы увидеть действительные параметры загрузки. `mount` и` ls -l / proc / 1 / exe`, чтобы увидеть фактический двоичный файл процесса `init`. `ldd / proc / 1 / exe` и` cat / proc / 1 / maps | grep -o '/.*\.so.*$' | сортировать | uniq`, чтобы увидеть динамические библиотеки `init`. ** На проблемной системе: ** Перед загрузкой я бы попытался удалить ненужные диски, такие как `/ dev / sdf`. pabouk 11 лет назад 0
@MartinDrautzburg: Также: какой дистрибутив и версию вы используете? Ядро по умолчанию? pabouk 11 лет назад 0

0 ответов на вопрос

Похожие вопросы