Wie wird / sbin / init beim lilo-Boot gefunden?

817
Martin Drautzburg

Ich habe gerade meine Stammpartition geklont (in Erwartung eines dist-Upgrades), die lilo.conf und die fstab (in der geklonten Partition) geändert und lilo ausgeführt.

Aber das System startet nicht von der geklonten Partition. Ich kann ein paar Seiten mit unauffälligen Kernel-Nachrichten sehen, dann hört es einfach auf.

Aus irgendeinem Grund habe ich versucht, von der guten Partition aus zu booten, init=/bin/shund das System startete nicht und stoppte bei derselben Kernel-Nachricht. Dies lässt vermuten, dass "mit init etwas nicht stimmt".

Also entschied ich mich, die Tabellen umzudrehen und init=/sbin/initbeim Booten von der "schlechten" Partition aus bestanden zu haben.

Aber ich verstehe nicht, was hier los ist. Hat jemand eine Erklärung dafür?

Hier ist mein lilo, conf

# 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

Bearbeiten: Dies sind die Kernel-Nachrichten

[ 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

Wenn es an dieser Stelle aufhört und ich keine davon sehe:

[ 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
Wenn das Ändern der Option "init = ..." das Verhalten nicht ändert, ist es höchst wahrscheinlich, dass der Startvorgang ** vor dem Starten von init ... fehlschlägt. Levans vor 10 Jahren 0
Martin schrieb jedoch, dass das System durch das Ändern in `init = / sbin / init` richtig gestartet wird. Das Verhalten ist merkwürdig. Der Linux-Kernel sollte standardmäßig nach `/ sbin / init` suchen. Wenn er` init` nicht ausführen kann, sollte er mit Kernel-Panic enden. pabouk vor 10 Jahren 0
Das Übergeben von init = / bin / sh führt auch nicht zu einer Kernel-Panik. Es fängt auch keine Schale an. Martin Drautzburg vor 10 Jahren 0
@MartinDrautzburg: Was sind die letzten Meldungen, bevor die Kernel-Initialisierung beendet wird? Was zeigt nach diesen Meldungen, wenn das System korrekt startet? Um die Meldungen anzuzeigen, können Sie versuchen, mit Shift + PgUp zurückzublättern, oder Sie versuchen den Kernel-Parameter `boot_delay = 500`. Auch in Bezug auf `/ bin / sh`: Es ist wahrscheinlich dynamisch verlinkt. Wenn ja, befinden sich die dynamischen Bibliotheken im Root-Dateisystem? pabouk vor 10 Jahren 0
@MartinDrautzburg: Glaubst du, dass beide Systeme bis zum Freeze-Punkt die gleichen Boot-Nachrichten haben? Ich würde folgendes versuchen: ** auf dem Arbeitssystem **: `dmesg | grep 'Befehlszeile:` `und` cat / proc / cmdline`, um die tatsächlichen Boot-Parameter anzuzeigen. `mount` und` ls -l / proc / 1 / exe`, um die tatsächliche Binärdatei des `init`-Prozesses zu sehen. `ldd / proc / 1 / exe` und` cat / proc / 1 / maps | grep -o '/.*\.so.*$' | sortieren | uniq`, um die dynamischen Bibliotheken von `init` zu sehen. ** Auf dem problematischen System: ** Vor dem Start würde ich versuchen, nicht benötigte Festplatten wie `/ dev / sdf` zu entfernen. pabouk vor 10 Jahren 0
@MartinDrautzburg: Auch: Welche Distribution und Version verwenden Sie? Der Kernel ist der Standardkern? pabouk vor 10 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme