Debian - keine Verbindung bei eth0? Server offline

- webserver
Guten Morgen,
ich bastle derzeit etwas an meinem Server rum und stoße dort ab und zu auf ein paar Probleme - ist aber alles halb so dramatisch, weil es sich nicht um einen Produktiv-Server handelt ;-)
Nun gut, ich wollte also meinen Server (Debian Sarge) vorhin neu starten (nachdem ich Quotas eingerichtet hatte) und habe einfach reboot
verwendet. Und zack ist der Server natürlich nicht wieder neu gestartet, obwohl eigentlich noch fast alles Ausgangszustand ist, d.h. ich hab noch nicht viel und im Bereich Netzwerk gar nichts an den vorgegebenen Einstellungen meines Providers geändert.
Also den Server über ein Rescue-System gebootet, Festplatten gemountet und ins syslog geschaut - dort steht:
Sep 22 04:18:11 localhost syslogd 1.4.1#17: restart.
[...]
Sep 22 04:18:13 localhost mysqld_safe[1782]: started
[...]
Sep 22 04:18:16 localhost postfix/master[1950]: daemon started -- version 2.2.10, configuration /etc/postfix
[...]
Sep 22 04:18:16 localhost /usr/sbin/cron[1979]: (CRON) INFO (pidfile fd = 3)
Sep 22 04:18:16 localhost /usr/sbin/cron[1980]: (CRON) STARTUP (fork ok)
Sep 22 04:18:16 localhost /usr/sbin/cron[1980]: (CRON) INFO (Running @reboot jobs)
Sep 22 04:18:17 localhost modprobe: FATAL: Could not load /lib/modules/2.6.8-3-k7/modules.dep: No such file or directory
Sep 22 04:34:08 localhost shutdown[2074]: shutting down for system reboot
Sep 22 04:34:08 localhost init: Switching to runlevel: 6
[...]
Sep 22 04:34:15 localhost kernel: Kernel logging (proc) stopped.
Sep 22 04:34:15 localhost kernel: Kernel log daemon terminating.
Sep 22 04:34:15 localhost exiting on signal 15
Sieht also nach einem normalen Start aus - anschließend läuft der Server, jedoch ist er weder per SSH noch per Ping erreichbar. Um 04:34 hab ich ihm dann über den Provider ein Strg + Alt + Entf gesendet und es wurde ein ganz normaler Shutdown eingeleitet.
So siehts für mich zumindestens aus :-)
Ich habe nun die Netzwerk-Einstellungen (/etc/network/interfaces) geprüft und halte diese für vollkommen korrekt, da sie auch mit der Anleitung meines Providers übereinstimmen. Ich habe dann von einem eigenen Script welches ich in /etc/rc2.d eingetragen haben mir die Ausgabe von ifstat
protokollieren lassen:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:42 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3055 (2.9 KiB) TX bytes:3055 (2.9 KiB)
Sieht so aus, als würde eth0 nicht gestartet bzw. eingerichtet werden... Mir ist aufgefallen, dass in /etc/rc2.d kein Link auf /etc/init.d/networking gesetzt ist, weshalb ich einen Link "S15networking" in /etc/rc2.d eingetragen habe.
Restart. Bringt allerdings auch nichts.
Ein manuelles Eintragen von ifup eth0
in meinem Startscript gibt lediglich die Ausgabe
Failed to bring up eth0.
So langsam bin ich jetzt irgendwie mit meinem Latein am Ende... Woran kann es noch liegen, dass der Server zwar zu laufen scheint (nicht nur syslog, sondern auch die anderen Log-Dateien sagen das) aber nicht über SSH und auch nicht über Ping zu erreichen ist?
MfG, Dennis.
Hallo Dennis.
Mein Tipp: wende dich an die d-u-g.
Einen schönen Freitag noch.
Gruß, Mathias
Tach,
Nun gut, ich wollte also meinen Server (Debian Sarge) vorhin neu starten (nachdem ich Quotas eingerichtet hatte)
dazu hast du einen neuen Kernel erstellt?
Sep 22 04:18:17 localhost modprobe: FATAL: Could not load /lib/modules/2.6.8-3-k7/modules.dep: No such file or directory
Hier können die Moulabhängiukeiten nicht geladen werden. Wenn der Netzwerkkartentreiber modular eingebunden wird, ist der Rechner dann natürlich nicht erreichbar.
mfg
Woodfighter
Hi Jens,
Nun gut, ich wollte also meinen Server (Debian Sarge) vorhin neu starten (nachdem ich Quotas eingerichtet hatte)
dazu hast du einen neuen Kernel erstellt?
Nein... allerdings hat aptitude mir da mal eine Meldung wegen dem Kernel gebracht - die dann aber wieder schneller weg war als mir lieb.
Sep 22 04:18:17 localhost modprobe: FATAL: Could not load /lib/modules/2.6.8-3-k7/modules.dep: No such file or directory
Hier können die Moulabhängiukeiten nicht geladen werden. Wenn der Netzwerkkartentreiber modular eingebunden wird, ist der Rechner dann natürlich nicht erreichbar.
Hm, möglich - der Kernel war vom Provider von Anfang an drauf... Das merkwürdige ist, dass werder genanntes Verzeichnis 2.6.8-3-k7 noch die Datei existieren.
MfG, Dennis.
Hi,
ich habe in der Zwischenzeit mal was weiter recherchiert - die Fehlermeldung "Failed to bring up eth0" war nur die Ausgabe auf stdout, ich hab mal noch stderr mit abefangen und folgende Fehlermeldungen bekommen:
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device
Failed to bring up eth0.
Es scheint also tatsächlich der Fall zu sein, dass mir da ein Aptitude-Update den Kernel oder vielleicht besser gesagt das Kernel-Modul für die Netzwerkkarte zerhauen hat.
Ich habe nun mal meinen Provider angeschrieben, was für ein Modul das denn war, dass da im Original verwendet wurde - mal schauen, was da als Antwort kommt ;-)
Falls hier noch jemand Tips hat, was die (Wieder-) Installation des Kernel-Moduls für meine Netzwerkkarte angeht, wie ich da am besten vorgehe, was zu beachten ist oder so - immer her damit :-)
MfG, Dennis.
Tach,
Falls hier noch jemand Tips hat, was die (Wieder-) Installation des Kernel-Moduls für meine Netzwerkkarte angeht, wie ich da am besten vorgehe, was zu beachten ist oder so - immer her damit :-)
Kernel 2.6.7 ist ja nun auch schon älter, also würde ich einfach mal einen neuen Kernel erstellen, da das bei einer Remote Maschine jedoch möglicherweise recht kompliziert wird, wenn man nicht genau weiß, was man da gerade tut, solltest du erstmal deinen Provider um eine .config-Datei bitten, dann kannst du auf deren Grundlage weitermachen. Diese Anleitung erklärt, wie man ein Debian-Kernel-Paket erstellt.
mfg
Woodfighter
Hi Jens,
Kernel 2.6.7 ist ja nun auch schon älter, also würde ich einfach mal einen neuen Kernel erstellen, da das bei einer Remote Maschine jedoch möglicherweise recht kompliziert wird, wenn man nicht genau weiß, was man da gerade tut, solltest du erstmal deinen Provider um eine .config-Datei bitten, dann kannst du auf deren Grundlage weitermachen. Diese Anleitung erklärt, wie man ein Debian-Kernel-Paket erstellt.
Ich hab meinen Provider mal um die .config Datei gebeten, bis jetzt allerdings noch keine erhalten. Die Kommunikation mit Leuten in Europa gestaltet sich für mich, der ich mich in /tmp/kanada befinde[1] etwas schwierig...
Nun ja - ich habe jetzt nach der Anleitung da mal so ein Packet erstellt. Die ganzen vielen Optionen, die man da abgefragt wird sagen mir natürlich nicht alles was - ich hab einfach mal bei den meisten die Default-Werte genommen und dann halt bei meiner Netzwerk-Karte (Realtek 8169 Chipsatz) yes angegeben. Das Kernel-Packet wurde mir auch brav erstellt.
Über das Rescue-System habe ich dann (mit chroot auf dem richtigen System) per dpkg -i
das selbsterstellt Kernel-Packet installiert - das sah auch sehr gut aus, ich bekam eine Success-Meldung. Also Restart ... doch es tut sich immer noch nichts.
Was mich sehr wundert, ist folgende Meldung im Syslog:
Sep 24 07:40:27 localhost syslogd 1.4.1#17: restart.
Sep 24 07:40:27 localhost kernel: klogd 1.4.1#17, log source = /proc/kmsg started.
Sep 24 07:40:27 localhost modprobe: FATAL: Could not load /lib/modules/2.6.8-3-k7/modules.dep: No such file or directory
Sep 24 07:40:27 localhost modprobe: FATAL: Could not load /lib/modules/2.6.8-3-k7/modules.dep: No such file or directory
Huch? Ich hab doch einen 2.6.18 Kernel installiert und /lib/modules/2.6.181 (Ich hab "1" als Versionsnummer angegeben - ich hätte wohl besser "-1" genommen) wurde auch prima angelegt und befüllt. Doch warum sucht der hier immer noch nach den Modulen für den alten Kernel? Oder soll ich lieber direkt fragen: Warum läuft das System immer noch unter dem alten Kernel? (mehr syslog gibts hier)
Mal einen Blick in /boot geworfen:
rescue:/lib/modules/2.6.181# ls -la /boot
total 1756
drwxr-xr-x 2 root root 4096 Sep 24 07:56 .
drwxr-xr-x 21 root root 4096 Sep 24 08:17 ..
-rw-r--r-- 1 root root 643663 Sep 24 07:26 System.map-2.6.18
-rw-r--r-- 1 root root 512 Aug 25 13:51 boot.0800
-rw-r--r-- 1 root root 512 Sep 24 07:38 boot.0802
-rw-r--r-- 1 root root 512 Sep 24 07:38 boot.0810
-rw-r--r-- 1 root root 49696 Sep 24 07:09 config-2.6.18
lrwxrwxrwx 1 root root 21 Aug 25 13:51 initrd.img -> initrd.img-2.6.8-3-k7
-rw------- 1 root root 14336 Sep 24 07:56 map
lrwxrwxrwx 1 root root 18 Aug 25 13:51 vmlinuz -> vmlinuz-2.6.8-3-k7
-rw-r--r-- 1 root root 1045899 Sep 24 07:26 vmlinuz-2.6.18
Wie kann das System so eigentlich überhaupt noch starten?? Die Links verweisen doch auf Dateien, die gar nicht existieren...
Meine lilo.conf (von dpgk erstellt) sieht so aus:
boot=/dev/sda2
root=/dev/sda2
compact
install=/boot/boot.b
map=/boot/map
vga=normal
delay=20
image=/vmlinuz
label = Linux
read-only
MfG, Dennis.
[1] vorübergehend in Kanada *g*
Tach,
Über das Rescue-System habe ich dann (mit chroot auf dem richtigen System) per
dpkg -i
das selbsterstellt Kernel-Packet installiert - das sah auch sehr gut aus, ich bekam eine Success-Meldung. Also Restart ... doch es tut sich immer noch nichts.
hast du dpkg, dann auch lilo ausführen lassen?
Wie kann das System so eigentlich überhaupt noch starten?? Die Links verweisen doch auf Dateien, die gar nicht existieren...
Das sieht in der Tat interessant aus. Du solltest erstmal die Links reparieren und dann nochmal lilo ausführen. Da lilo sich direkt auf die Geometrie der Festplatte beruft, könnte es sein, dass er noch den alten Kernel booten kann.
mfg
Woodfighter
Hi Jens,
hast du dpkg, dann auch lilo ausführen lassen?
Hm, gute Frage ;-) Wenn dpkg das nicht freiwillig gemacht hat, dann nicht - ich habe mich mit "successfully installed" zufrieden gegeben *g*
Ich hab jetzt erstmal lilo.conf angepasst:
boot=/dev/sda2
root=/dev/sda2
compact
install=menu
map=/boot/map
vga=normal
delay=5
image=/boot/vmlinuz
label = Linux
read-only
Anschließend:
rescue:/boot# /sbin/lilo
Warning: COMPACT may conflict with LBA32 on some systems
Added Linux *
Zuvor habe ich die Festplatte des Servers in ein Verzeichnis des Rescue-Systems gemounted und anschließend ein chroot
auf die Platte des Servers ausgeführt.
*restart* Hm, das ist schon mal fehlgeschlagen, also folgendes ausprobiert:
rescue:/# /sbin/lilo.real -M /dev/sda
/boot/boot.0800 exists - no /dev/sda backup copy made.
The Master Boot Record of /dev/sda has been updated.
Ich habe das Gefühl, dass Lilo (weil vom Rescue System ausgeführt) seine Änderungen im Rescue System durchgeführt hat...
Hm, klappt immer noch nicht - das System scheint gar nicht zu starten, es taucht nichts im Syslog auf. Sieht so aus, als wär da mit Lilo was schief gelaufen...
Das sieht in der Tat interessant aus. Du solltest erstmal die Links reparieren und dann nochmal lilo ausführen. Da lilo sich direkt auf die Geometrie der Festplatte beruft, könnte es sein, dass er noch den alten Kernel booten kann.
Unter /boot habe ich jetzt folgende Sachen liegen (u.a.)
-rw------- 1 root root 24576 Sep 27 01:55 map
lrwxrwxrwx 1 root root 14 Sep 27 01:07 vmlinuz -> vmlinuz-2.6.18
-rw-r--r-- 1 root root 1045899 Sep 24 07:26 vmlinuz-2.6.18
Die lilo.conf habe ich nun nochmal bearbeitet und etwas mehr an meine ursprüngliche (funktionsfähige) lilo.conf angepasst:
boot=/dev/sda2
root=/dev/sda2
install=menu
map=/boot/map
vga=normal
delay=5
default=Linux
image=/boot/vmlinuz
label=Linux
vga=0x314
read-only
Unter anderem das mit dem VGA hatte ich nicht drin...
*restart* Immer noch nichts, syslog bleibt leer.
Viele Grüße aus Kanada,
~ Dennis.
Hi again,
Einen Fehler habe ich schon mal gefunden - ich habe ja SATA-Platten (/dev/sda und /dev/sdb), jedoch hatte ich SATA-Support nicht im Kernel einkompiliert.
Ich habe jetzt also in der .config-Datei CONFIG_BLK_DEV_IDE_SATA auf y gesetzt, mit make-kpkg ein den Kernel kompiliert und ein neues Kernel-Packet erstellt - dieses über dpkg installiert und anschließend lilo ausgeführt.
Zur Sicherheit habe ich auch noch mal ./kernel-sources/arch/i386/bzImage nach /boot/vmlinuz-xyz kopiert und nochmal lilo laufen lassen (lief fehlerfrei durch) - trotzdem will der einfach nicht booten.
Irgendwer noch ne Idee woran es liegen könnte? Sonst muss ich wohl meinen Provider mal um ein KVW-Switch oder wie diese Dinger heißen (Remote Zugriff mit Bildschirm und Tastatur) bitten...
Viele Grüße aus Kanada,
~ Dennis.
Tach,
Irgendwer noch ne Idee woran es liegen könnte? Sonst muss ich wohl meinen Provider mal um ein KVW-Switch oder wie diese Dinger heißen (Remote Zugriff mit Bildschirm und Tastatur) bitten...
da er gar nicht bootet, fehlt vermutlich im neuen Kernel ein Treiber, der irgendwo wichtig ist, aber so ohne Fehlermeldung kann man da schlecht was zu sagen.
mfg
Woodfighter
Hi Jens,
da er gar nicht bootet, fehlt vermutlich im neuen Kernel ein Treiber, der irgendwo wichtig ist, aber so ohne Fehlermeldung kann man da schlecht was zu sagen.
Ok, vermute ich auch - mein Provider bietet die Möglichkeit ein KVM-Switch (oder wie heißen die Dinger?) an den Server anzuschließen. Ich hab da gerade mal eine Support-Anfrage gestellt - das dürfte wohl deutlich einfacher gehen als hier rumzurätseln ;-)
Trotzdem danke dir schonmal für deine Hilfe.
Viele Grüße aus Kanada,
~ Dennis.
Hi again,
Ok, vermute ich auch - mein Provider bietet die Möglichkeit ein KVM-Switch (oder wie heißen die Dinger?) an den Server anzuschließen. Ich hab da gerade mal eine Support-Anfrage gestellt - das dürfte wohl deutlich einfacher gehen als hier rumzurätseln ;-)
So, binnen eines halben Tages hat mein Provider mir das Ding besorgt (die sind recht gefragt und es gibt nicht allzu viele davon im Rechenzentrum), angeschlossen und mir gesagt, wie ich es bediene :-) Sehr schönes Teil. Ich durfte also erst mal feststellen, dass beim Booten folgendes kam und danach lediglich noch schwarzer Bildschirm:
Und dann habe ich erst mal Kopfschmerzen bekommen - gewaltige Kopfschmerzen. Wie soll das bitteschön auch funktionieren, wenn ich /dev/sda2 als boot angebe in der lilo.conf?! Der Master-Boot-Record liegt doch auf keiner speziellen Partition - also muss da ein /dev/sda her, und siehe da, das brachte mich auch direkt weiter:
Jetzt hab ich wenigstens eine Fehlermeldung :-) Jetzt kann ich googeln, jetzt kann ich weiterarbeiten.
Viele Grüße aus Kanada,
~ Dennis.
Hi again,
Jetzt hab ich wenigstens eine Fehlermeldung :-) Jetzt kann ich googeln, jetzt kann ich weiterarbeiten.
Nun ja - genau das habe ich jetzt die letzten Stunden gemacht. Erst mal habe ich natürlich überall die Info gefunden, dass die notwendigen Festplatten-Treiber in den Kernel fest einkompiliert werden sollen. Ich habe mehrere Anleitungen befolgt und alles S-ATA oder SCSI mäßige fest einkompiliert, trotzdem diese Fehlermeldung beim Booten:
Unter meinem Rescue-System habe ich folgendes mal noch gemacht:
rescue:~# mkdir system
rescue:~# mount /dev/sda2 system/
rescue:~# mount /dev/sdb1 system/home
rescue:~# mount /dev/sdb2 system/var
rescue:~# chroot system
rescue:/# mount -t proc none /proc
rescue:/# rdev /boot/vmlinuz
Root device 0x000f
rescue:/# rdev /boot/vmlinuz /dev/sda2
rescue:/# rdev /boot/vmlinuz
Root device /dev/sda2
rescue:/#
Da stand was von root device 0x000f - woher das kommt weiß ich nicht genau, jedenfalls hab ich das mal (nachdem es nicht funktioniert hat) auf /dev/sda2 gesetzt, allerdings funktioniert dies auch nicht.
So langsam bin ich etwas verzweifelt... Ich muss mich wohl mal noch an die von Matthias genannte Liste wenden, vielleicht kann man mir ja dort noch weiterhelfen...
Viele Grüße aus Kanada,
~ Dennis.
Einen wunderschönen guten Morgen :-)
(bzw. bei mir ein wunderschönes Mitternacht-vorbei *g*)
Er läuft nun also - mein selbstgebackener Kernel. Und woran lags, dass es jetzt so lange nicht funktionieren wollte?
Daran, wonach es am meisten aussah: Es hat einfach nur ein Treiber gefehlt. Ich hatte wohl die falschen SATA Treiber geladen. Falls jemand später diesen Text hier im Archive lesen sollte hier ein paar Informationen zu meiner .config Datei:
CONFIG_BLK_DEV_IDESCSI=y
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_AHCI=y
CONFIG_SCSI_SATA_SVW=y
CONFIG_SCSI_ATA_PIIX=y
CONFIG_SCSI_SATA_MV=y
CONFIG_SCSI_SATA_NV=y
CONFIG_SCSI_PDC_ADMA=y
CONFIG_SCSI_SATA_QSTOR=y
CONFIG_SCSI_SATA_PROMISE=y
CONFIG_SCSI_SATA_SX4=y
CONFIG_SCSI_SATA_SIL=y
CONFIG_SCSI_SATA_SIL24=y
CONFIG_SCSI_SATA_SIS=y
CONFIG_SCSI_SATA_ULI=y
CONFIG_SCSI_SATA_VIA=y
CONFIG_SCSI_SATA_VITESSE=y
CONFIG_SCSI_SATA_INTEL_COMBINED=y
Desweiteren noch (aber glaube ich für die Funktionalität nicht wirklich relevant):
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
(Hier nicht angegebene SCSI oder SATA Optionen habe ich nicht auf y sondern auf m oder n gesetzt.)
Vielen Dank hiermit noch mal an Jens!
Und damit self.close() ;-)
Viele Grüße aus Kanada,
~ Dennis.