Hetzner: Nach apt-get upgrade laufen keine Dienste

Lord Gurke

Nur echt mit 32 Zähnen
Hallo zusammen,

habe auf meinem Hetnzer DS 5000 das Problem, dass seitdem ich heute Abend ein apt-get upgrade durchgeführt habe, die Maschine zwar offensichtlich läuft, aber keine Dienste wie SSH gestartet werden. Ich kann den Server also anpingen, mich aber nicht per SSH drauf verbinden.
Bei dem Update wurde mir mitgeteilt, das der Kernel, der installiert wird, bereits drauf ist (sinngemäß). Nach dem Reboot dann dieses Dilemma :rolleyes:

Habe nun die Kiste im Rescue-Modus gestartet und mir die Logfiles angesehen, die sehen für mich aber eigentlich prima aus (siehe Anhang, bei Copy&Paste sind die Zeilen total vernüllert).

Da ich den Kernel wegen dem md0-RAID ein wenig in Verdacht habe, habe ich ins /boot-Verzeichnis der gemounteten Platte geguckt und mir hat sich folgendes Bild geboten:

Code:
drwxr-xr-x  3 root root 4.0K 2009-02-10 22:23 .
drwxr-xr-x 22 root root 4.0K 2009-02-03 16:41 ..
lrwxrwxrwx  1 root root    1 2009-02-03 16:41 boot -> .
-rw-r--r--  1 root root  512 2007-08-31 15:03 boot.0800
-rw-r--r--  1 root root  64K 2008-12-25 22:04 config-2.6.18-6-amd64
drwxr-xr-x  3 root root 4.0K 2009-02-03 16:41 grub
-rw-r--r--  1 root root 5.6M 2009-02-10 22:23 initrd.img-2.6.18-6-amd64
-rw-r--r--  1 root root 5.6M 2008-05-14 13:49 initrd.img-2.6.18-6-amd64.bak
-rw-------  1 root root  85K 2009-01-07 14:48 map
-rw-r--r--  1 root root 952K 2008-12-26 00:01 System.map-2.6.18-6-amd64
-rw-r--r--  1 root root 1.5M 2008-12-26 00:01 vmlinuz-2.6.18-6-amd64
Ich habe keine Ahnung, wie das normalerweise bei Hetzner aussehen sollte, auch ein gegenseitiger Austausch der beiden initrd.img...-Dateien hat nichts gebracht.

Bin für jeden Hinweis dankbar!
 

Attachments

  • messages.png
    messages.png
    58.5 KB · Views: 123
Lass Dir doch morgen Vormittag ne LARA anklemmen, dann kannst Du dem Server beim booten "zusehen", und dann wirst Du auch gleich sehen wo das Problem genau liegt. Die Logfiles sagen teilweise wenig aus, wenn Du z.B. ein Software-Raid hast, aber Du soweit gar nicht kommst beim booten. Dann kann er auch nix schreiben.

Basti
 
Danke für die fixe Antwort, werde ich morgen wohl mal machen lassen.

Mir fällt gerade etwas auf, was äußerst merksam ist:
Der courier-imap scheint zu laufen, zumindest kann ich auf das Postfach zugreifen (per externen Webmailer und Telnet) und Änderungen darin vornehmen :eek::confused:

Das bedeutet, dass auch der MySQL laufen muss, da sich courier dagegen authentifiziert...
Jetzt bin ich vollends platt!
In den /rc*.d/-Verzeichnissen sind SSH und Apache allerdings aufgeführt, es wurde allerdings auch die glibc upgedatet - kann das möglicherweise auch damit zusammenhängen?
 
Was passiert, wenn Du Dich vom Rettungssystem aus in dein FS chrootest und dann den sshd (auf einem anderen Port) mal startest?

Library-Abhängigkeiten müßte mann dann sehen (ggf. auch mit "ldd sshd"), ebenso Absonderlichkeiten in der Config.

Auch kannst Du dann nochmal apt-get machen.
 
Und schau mal was sonst noch so alles läuft, wenn die Kiste "normal" gebootet ist:
Von extern:
Code:
nmap deinhost.de
 
Sooo, habe jetzt gerade ins Rettungssystem gebootet, bin auf einer zweiten Konsole auf mein md0 "gechrooted" und habe dort versucht, SSH (läuft bei mir ohnehin auf einem anderen Port) zu starten.
"sshdPRNG is not seeded" war die Fehlermeldung, bei Apache ähnlich interessante Fehler.
Dann habe ich festgestellt, dass das Verzeichnis /dev komplett leer ist. Keine Ahnung, ob das beim Rescue-System so sein muss, jedenfalls habe ich manuell dort das Device "urandom" erstellt und siehe da, Apache und SSH rennen wieder!

Also vermute ich einfach mal, dass diese Devices beim Booten nicht mehr erstellt werden, aber scheinbar ist das Problem nicht so populär, ich finde nämlich nicht heraus, wie man den Fehler behebt :(
 
1.) Script bauen
Code:
#!/bin/bash
cd /dev ; ./MAKEDEV urandom ; /etc/init.d/ssh start
2.) Beim booten ausführen lassen
3.) *happy*

By the Way: Wie siehts mit dem Packet "udev" aus? Installiert?
 
ins Rettungssystem gebootet, ...auf mein md0 "gechrooted" ... habe ich festgestellt, dass das Verzeichnis /dev komplett leer ist.
Ja, das ist normal. Wenn man /dev in der ChRoot-Umgebung braucht, sollte man diese aus der Boot-Umgebung einbinden:
Code:
mount -o bind /proc /mnt/chroot/proc
mount -o bind /dev /mnt/chroot/dev
chroot /mnt/chroot

huschi.
 
Danke an alle, der Server läuft wieder!
Nachdem ich die Devices jetzt mittels Script in rc1 wieder angelegt habe, bleiben diese weiterhin bestehen und die Dienste kommen auch wieder hoch :)

Mal sehen, ob ich die auch mit ins Backup aufnehmen sollte :D:D
 
Back
Top