Hilfe! Server steckt beim Start von Runlevel S fest!

[str]

Hallo Forum!

Nachdem ich den gesamten gestrigen Tag mit der erfolglosen Fehlersuche in meinem Server verbracht habe, hoffe ich jetzt einen hilfreichen Hinweis zu bekommen, was zwischen dem Init-Start und den ersten Scripts aus Runlevel S schief laufen kann.

Der Reihe nach:
1. Server mit einem direkt nach der Veröffentlichung frisch aufgesetztem Wheezy.
2. Vorgestern habe ich im Laufe des Tages LDAP und cryptsetup-LUKS installiert. Mit letzterem habe ich dann noch eine verschlüsselte Partition erstellt. Allerdings NICHT die System-Partition. Nicht mal auf derselben physikalischen Platte. Am Abend beim runterfahren war noch alles bestens...
3. Seit gestern steckt der Bootprozess bei dieser Meldung fest:

Code: Alles auswählen

INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.

Was habe ich seither unternommen:
1. Mit der PartedMagic Live CD kann ich auf meine Platten zugreifen und Änderungen vornehmen.
2. Bei der Installation von cryptsetup war mir die lapidare Meldung aufgefallen, dass die initramdisk neu erstellt wurde. Also habe ich zu Testzwecken mal in der Datei /etc/default/cryptdisks die Variable CRYPTDISKS_ENABLE=No gesetzt und nach einem chroot update-initramfs-update -u und update-grub ausgeführt. Letzteres schlug fehl, weil der Platten-Bootsektor nicht an derselben Stelle lag wie bei der ersten Installation (oder so ähnlich, die Fehlermeldung habe ich nicht mehr genau im Kopf). Die PartedMagic Live CD bietet aber einen "grub-doctor", der das Update angeblich erfolgreich vorgenommen hat. Ergebnis: genau so wie vorher!
3. Im grub Menü habe ich die Kernel-Zeile mal um break=init erweitert um zu sehen wie weit ich komme. Alles bestens. Die Ausgabe von dmesg an der Stelle habe ich als Anhang beigefügt 37346. Für mich keine Auffälligkeiten zu sehen. Nach der Eingabe von exit kommt dann wieder genau die oben dargestellte Ausgabe und Ende ist.
4. Um festzustellen ob im Start der Scripts von Runlevel S etwas hakt, habe ich herausgesucht welche Scripts die niedrigste Startnummer haben (hostname und mountkernfs) und diese dann um echo-Befehle am Anfang ergänzt, nur um zu sehen das der Boot Prozess bis dahin überhaupt kommt. Ergebnis: Nein, kommt er nicht!

Jetzt weiß ich nicht mehr wo ich noch suchen soll. Forensuche und Google haben auch nix ergeben, dass irgendwo schon mal ein ähnliches Problem auftauchte. Kann mir BITTE jemand einen Tip geben, wo es zwischen dem Init-Start und den ersten Scripts aus Runlevel S noch haken kann?

Mit verzweifeltem Gruß
Stephan

[rendegast]

Für das Erstellen der Datei /var/log/boot ist das in wheezy separate Paket bootlogd verantwortlich,
was eventuell nicht automatisch installiert ist (bei mir).

Kannst Du den 'recovery mode' für den Kernel starten? (single)
Alternativ der Kernel-Zeile eine "1" anhängen. grub-shell/Edit-Modus, in der Art:

Code: Alles auswählen

....
linux   /boot/vmlinuz-3.10-0.bpo.2-amd64 root=..... ...... 1
....

Da die Installation nicht alt ist, einfach nochmal aufsetzen.
Vor dem Schritt mit cryptsetup ein Backup/Image.
(Bei einer crypt-Partition ausprobieren/üben,
ob und wie der Zugriff mit einer Live/Rettungs-CD funktioniert.)

...und nach einem chroot update-initramfs-update -u und update-grub ausgeführt. Letzteres schlug fehl, weil der Platten-Bootsektor nicht an derselben Stelle lag wie bei der ersten Installation (oder so ähnlich, die Fehlermeldung habe ich nicht mehr genau im Kopf).

Existiert eine separate /boot-Partition?
Diese müßte auch in der chroot-Umgebung an der richtigen Stelle gemountet sein.

Evtl. die PartedMagic als usb-Stick?
Dann wäre die eingebaute Platte wohl sda->sdb, und irgendwo hinterlegte sdaX-Anweisungen führen ins Leere.

[str]

Hallo rendegast, Danke für die schnelle Antwort!

Für das Erstellen der Datei /var/log/boot ist das in wheezy separate Paket bootlogd verantwortlich,
was eventuell nicht automatisch installiert ist (bei mir).

Keine Datei /var/log/boot. Apt läuft in der "gechrooteten" Umgebung auch nicht, hatte schon versucht cryptsetup wieder zu deinstallieren. Kann also auch keine Pakete nachinstallieren.

Kannst Du den 'recovery mode' für den Kernel starten? (single)

Zusätzlich zu den Ausgaben in dem dmesg-Anhang oben nur noch diese hier: (vom Bildschirm abgetippt, könnte ungenau sein)

Code: Alles auswählen

Begin:Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ...done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.

...und dann wieder INIT:... wie oben

Alternativ der Kernel-Zeile eine "1" anhängen

Was sollte die 1 tun? Ich kann keine Änderung feststellen...

Da die Installation nicht alt ist, einfach nochmal aufsetzen.

Das wollte ich natürlich vermeiden, weil es geschätzte 3 Tage dauern würde...

Existiert eine separate /boot-Partition?

Nein

[rendegast]

apt läuft im chroot, dafür sind gegebenenfalls weitere Vorbereitungen nötig,
meistens einige Mounts, zBsp. devpts.
Oder eine separate /var-Partition muß erst gemountet werden.

Code: Alles auswählen

func2() {
mount /proc     ${chr_path}/proc                --bind
mount /sys      ${chr_path}/sys         --bind
mount /dev      ${chr_path}/dev         --bind
mount /dev/pts  ${chr_path}/dev/pts     --bind                  # dev/pts/ wird von apt benutzt
#mount /dev/shm ${chr_path}/dev/shm/    --bind

#mount tmpfs    ${chr_path}/dev/shm/    -t tmpfs                # mittlerweile ein Link ->/run/shm
#mount tmpfs    ${chr_path}/run/                -t tmpfs
mount /run      ${chr_path}/run/                --bind                  # 'rbind'?, wegen lock/ und ..?
}

ist jedoch mit Vorsicht zu genießen, da das chroot damit im Wirtssystem herumfuhrwerken kann.

Nervenden LOCALE-Warnungen kann durch Wahl einer solchen im chroot begegnet werden.

Was sollte die 1 tun?

'Boote in Runlevel 1'
entspricht grob dem recovery-Eintrag.

[str]

OK, hatte vor dem chroot nur proc und sys gemountet. Jetzt hat es geklappt, bootlogd ist installiert und cryptsetup entfernt. Fortsetzung folgt nach dem nächsten Boot-Versuch und dem hoffentlich aussagekräftigen Log...

[str]

/var/log/boot

(Nothing has been logged yet.)

[rendegast]

Stirbt wohl beim Übergang von der initrd.

Erstelle die initrd im chroot neu, vergleiche deren Inhalte.
(initrd sind *.cpio.gz-Archive)

Anweisungen für (grub-)root und linux-root können in der grub-shell beim Booten kontrolliert/angepaßt werden, zBsp.

Code: Alles auswählen

grub> foobar ( <TAB>

sollte eine Liste von Devices zeigen.

Code: Alles auswählen

grub> lsmod

zeigt eine (nichtblätterbare?, '| more' o.ä.?) Liste geladener Module,
eventuell fehlt ein (grub-)Modul für den Zugriff auf ein ungewöhnliches Dateisystem?
Wobei Kernel/initrd ja wohl geladen werden,
deren Dateisystem (für grub) also auch verfügbar ist,
'set root=(...)' in grub wohl valide ist.

[str]

update-initramfs -u und update-grub liefen in der chroot Umgebung ohne Fehlermeldung durch. Die initrd ist jetzt geringfügig größer als zuvor, was daran liegen könnte dass ich gestern vor dem chrooten auch nur proc und sys eingebunden hatte. Das Ergebnis beim booten bleibt jedenfalls dasselbe

Wie man zwei cpio.gz vergleicht weiß ich nicht, aber das würde doch auch nur sinnvoll sein wenn man es mit einer funktionierenden initrd vergleicht? In meinen Datensicherungen ist zwar alles mögliche drin, aber kein boot Verzeichnis

lsmod in der grub shell ist nicht nur unblätterbar, das Pipe Zeichen verursacht auch einen Syntax Error, also auch hier keine brauchbaren Informationen. Die / Partition ist ext4, also auch nicht so exotisch. Außerdem wird es ja gefunden wie die Ausgabe von dmesg bei break=init zeigt:

Code: Alles auswählen

EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)

Keine Ahnung wo ich jetzt noch suchen soll