Arch Linux

Kernel Panic - No working init found - mein Linux bootet nicht mehr

hawiwo

Hallo,
beim Bootvorgang hängt sich meine archlinuxinstallation mit:

Failed to execute /init (error -2) ...

ich habe schon diverse Dinge erfolglos ausprobiert zuletzt:
von CD gebooted und mit chroot und
Linux Kernel erzeugen: mkinitcpio -p linux # aus der Anleitung_für_Einsteiger.
zuvor hab hab ich noch ein Update gemacht.

leider klappt das (alles) nicht. Ausser regelmäßigen updates (pacman -Syu) hab ich
nichts bewust am System gebastelt.
Wie komm ich da weiter?

sanni

Schau mal nach, ob du in der config-Datei deines Bootmanagers den Eintrag 'init=' findest.
Dort sollte dann, bei einem aktuellen System, 'usr/lib/systemd/systemd' eingetragen sein.
Wenn du Grub installiert hast, ist das die Datei /boot/grub/grub.cfg.

LG, Sanni

Greg

Ich habe mal bei mir den Eintrag in der grub.cfg für systemd weggelassen und neu gebootet.
Dann sieht die Fehlermeldung so aus:

starting version217
arch1_2: clean,....
ERROR: Root device mounted successfully, but /sbin/init does not exist.
Bailing out, you are on your own. Good luck.
sh: can't access tty; job control turned off
[rootfs /]# _

Demanch müßte bei hawiwo der Fehler woanders liegen zumal ganze Speicherabbilder dargestellt werden call trace usw.
Sieht ja schon fast wie Speicherdefekt aus obwohl nach einem update das ausgeschlossen sein müßte.

An hawiwo:
Wie lang ist das letzte update schon her?
Du könntest noch /var/log/pacman.log uns zeigen. Darin werden auch die Meldungen aufgeschrieben über .pacnew Dateien.
Hast du die Warnmeldungen beachtet?

hawiwo

einen init= eintrag gabs nicht. Aber auch mit init=/usr/lib/systemd/systemd:
...
linux /boot/vmlinuz-linux root=UUID=[...] rw init=/usr/lib/systemd/systemd quiet
...
tritt der Fehler unverändert auf. (Pfade und Dateien sind vorhanden)

hawiwo

Hallo Greg, nein in die pacman.log hab ich noch nicht geschaut (->http://waldhof1.de/pacman.log).
Da erscheint eine .pacnew als Warnung...hmmm...kein Fehler nur ne Warnung.

Greg

hawiwo schriebDa erscheint eine .pacnew als Warnung...hmmm...kein Fehler nur ne Warnung.

Genau solche Warnungen sind es denen man zumindest nachgehen sollte. Was für ein pacnew ist denn das?
Wann war das letzte update????

hawiwo

Beim update am 2014-12-18 16:21 wurde die Meldung:
[ALPM] warning: /etc/pacman.d/mirrorlist installed as /etc/pacman.d/mirrorlist.pacnew
und eine mirrorlist.pacnew erzeugt, die Server aus versiedenen regionen (vermutlich eine standard mirrorlist) enthält, die jedoch
alle auskommentiert sind. Jetzt hab ich die mirrorlist.pacnew zu mirrorlist umbenannt (die alte weggeschoben), ein paar .de Server aktiviert und nochmal ein
pacman-db-update und ein pacman -Syu ausgeführt.
...there is nothing to do ... war ja klar. Vermutlich liegt hier auch nicht mein Problem, denn an dem hat sich nichts geändert!

waldbaer59

Kannst Du evtl. nochmal mit von CD booten und mit chroot quasi den Kernel noch mal neu 'installieren'? Sicher ist in Deinem Pacman-Cache auch noch die vorherige Kernelversion drin. Dann könntest Du mit pacman -U [alte_Kernelversion_Datei] den zurückholen und schauen, ob dann der Boot wieder klappt. Vorher in der Config-Datei des Bootmanagers nachsehen, ob irgendetwas 'komisch' aussieht.
Wenn das geklappt hat nochmal pacman -Syu machen und schauen, was passiert ...

VLG
Stephan

hawiwo

ok da liegen noch 2 alte (insgesamt 3) kernels rum.
Jetzt hab ich mal den vorletzten installiert
alle dateien in /boot bis auf /boot/grub gelöscht,
und ein pacman -Syu ausgeführt. Dabei wird wieder der aktuelle Kernel installiert
klappt alles, nur die Meldung: WARNING: Possibly missing firmware for module: aic94xx erscheint, was aber scheinbar halb so schlimm ist bzw. nicht das Problem ist.
letztlich erscheint
==> Image generation successfull
Eben habe ich noch eine andere archlinuxkiste aufgetrieben und die grub einstellungen verglichen, wobei nichts auffällig ist. Die 'linux' zeile ist bis auf die UUID identisch und die stimmt der Partition (blkid) überein.
Immernoch das gleiche Problem!

init=/bin/bash war mein erster erfolgloser Versuch

Greg

TBone schriebWette ich dagegen. Ich würde mal ein
init=/bin/bash probieren. Je nach Ergebnis dann weiter sehen.

Jaja Tbone, ich gebe dir schon recht. Es wird etwas von initfehlern angezeigt. Es wäre schon sehr sehr unwahrscheinlich das ausgerechnet beim update was am Speicher passiert ist. Aber dieser call trace ... hm.

Einen alten Kernel zu installieren wie waldbaer59 schreibt hätte da allerdings wirklich zum Erfolg führen müssen, wenns am kernel liegt.

hawiwo
Boote doch nochmal mit dem Installationsimage und mach ein memtest. (Und wenns nur zur Beruhigung meinerseits dient, grins). Zumindest wäre das wenig arbeit um den Speicher auszuschliessen.

hawiwo

krass, die fstab war leer. Aus irgendeinem Grund ist das beim Update vom 2014-11-23 16:07 (->http://waldhof1.de/pacman.log) passiert,
wobei eine fstab.pacorig (fstab kopie) erstellt wurde:
-----------------fstab.pacorig-------------------------------------------------------------------------------------------
# /dev/sda1 UUID=3b2350b2-3978-4135-940c-33ab6a9fd565
LABEL=arh / ext2 rw,relatime 0 1

efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0

# /dev/sda5 UUID=a9e105a5-7c6d-4470-8f48-647de78b3444
LABEL=swap none swap defaults 0 0
----------------------------------------------------------------------------------------------------------------------
die hab ich mal getestet (Ergebnis=urspünglicher Fehler) dann hab ich die fstab mal geändert und solllte eigentlich ok sein:
----------------fstab------------------------------------------------------------------------------------------------
# /dev/sda1 UUID=3b2350b2-3978-4135-940c-33ab6a9fd565
/dev/sdb1 / ext2 rw,relatime 0 1
##LABEL=arh / ext2 rw,relatime 0 1

##efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0

# /dev/sda5 UUID=a9e105a5-7c6d-4470-8f48-647de78b3444
##LABEL=swap none swap defaults 0 0
/dev/sdb5 none swap defaults 0 0
----------------------------------------------------------------------------------------------------------------------
aber das nützt auch nix.
Hier die blkid und grubcfg.info:

http://www.waldhof1.de/blkid.txt
http://www.waldhof1.de/grubcfg.txt

bei all den Änderungen hat sich am Ursprünglichen Fehler nichts geändert.
Den Hauptspeicher hab ich auch mal getauscht und memtest liefert keinen Fehler.

fs4000

Diese Fehlermeldung kommt erstens vom Kernel und zweitens geht es da um /init und nicht /sbin/init. Das heißt, es wurde ein Initramfs geladen (was nicht falsch ist, weil unser Kernel sonst nicht booten kann), allerdings kann in dem Ding /init nicht ausgeführt werden. Heißt einfach nur, dass das Initramfs, was mkinitcpio erstellt hat, kaputt ist. Also bitte mehr dahingehend suchen. Was auf der Festplatte ist, ist zum Fehlerzeitpunkt völlig egal, weil auf diese gar nicht zugegriffen werden kann.

hawiwo

Das scheint so zu sein. Deshalb war ja mein erster Versuch: mkinitcpio -p linux.
Aber jetzt hab ich mal von einer anderen achlinux installation die /boot/initramfs-linux-fallback.img und die initramfs-linux.img kopiert komme dann zumindest mal auf eine Befehlszeile ([rootfs /]).
2 Fehlermeldungen gehen dem voraus:
ERROR: device 'UUID=3b2350b2-3978-4135-940c-33ab6a9fd565' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=3b2350b2-3978-4135-940c-33ab6a9fd565'.

die UUID ist korrekt, darauf greife ich ja immer mit chroot zu.
Die /etc/mkinitcpio.conf ist identisch mit der, des anderen PCs

Warum produziert mkinitcpio 2 nicht funktionierende /boot/initramfs*.img dateien?

hawiwo

ok ich bin jetzt mal die erwähnte https://www.kernel.org/doc/Documentation/init.txt durchgegangen durchgegangen.

zu D: prüfen ob alle benötigten Module in der /bin/init (welche auf /lib/systemd/systemd gelinkt ist) vorhanden sind:
for a in $(readelf -d /lib/systemd/systemd | grep -i needed | awk '{print $5}' | tr -d "[]"); do find / -name "$a"; done
liefert die gleichen Module wie auf dem anderen archlinux PC. auch die md5sum(en) sind gleich.
zu C: kann ich mir nicht vorstellen. Hab ich trotzdem getestet.

Punkt A ist das Problem. Im Moment hab ich die initramfs-linux-fallback.img und die initramfs-linux.img vom lauffähigen linux.
Mit der SuperGrub2 Disk kann die /boot/grub/grub.cfg von /dev/sdb1 gelesen werden, aber auch hier tritt der ursprüngliche Fehler auf.
Es scheint so als ob beim bootvorgang die Platte bzw. /dev/sdb1 nicht mehr gefunden werden kann.

chepaz

Ich hab das hier nur überflogen aber: Bist du dir sicher das du bei all dem gechroote die initrd in das richtige Verzeichniss/Partition gelegt hast? Nicht das du ständig eine "korrekte" initrd baust und die aber dann am völlig falschen Ort liegt.

hawiwo

das wär natürlich der Supergau aber nicht auszuschließen!
Ich hab trotzdem nochmal das system gecheckt und http://www.waldhof1.de/blkid.txt ist so noch gültig d.h. nur /dev/sdb1 die richtige bzw. einzige Linux Partition.

Von CD-Boote ich und dann:
loadkeys de-latin1
mount /dev/sdb1 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
mount -t proc /proc /mnt/proc
chroot /mnt /bin/bash
ok ich bin etwas tippfaul und spar mir das getippe mit "source <(curl -s waldhof1.de/mchroot)".
Und mein Zeug steht in meinem Home-Verzeichnis.

chepaz

Schreib mal die UUID deiner sdb1 in die fstab. Also kein Device und kein Label. Dann bau die initrd und die grub.cfg neu.

hawiwo

hab ich noch probiert bevor ich die Platte formatiert und das System neu installiert habe!
Und prompt bootet die Kiste auch mit SuperGrub2 und allen sonstigen.
Trotzdem Dank an alle Tipgeber!

Klex

Hey,

ich hab das gleiche Problem nachdem ich ein Update durchgeführt habe, in welchem unter anderem der Kernel auf Version 3.18.2-2 aktualisiert wurde. Lösen konnte ich das Problem bis jetzt noch nicht.

volker_holthaus

Also als Tipp kann ich noch geben, falls der Firebird Datenbank Server manuell installiert wurde, wird das Verzeichnis /usr/lib64 plattgemacht. Beim nächsten Kernelupdate knallt es dann mit mkinitcpio. In diesem Fall einfach mal das Verzeichnis /usr/lib64 anschauen, wenn nur die Bibliotheken vom Firebird erscheinen, dann ist das kaputt. Im Fehlerfall das Paket filesystem (die Symlinks werden dann wieder neugebaut) über arch-chroot installieren, dann mit mkinitcpio -p linux, den Kernel neu bauen und alles ist wieder gut.

Nächste Seite »