Server bootet nicht mehr Hilfe!



Ich kann dir bei deinem Problem leider nicht helfen, weil ich nichts sehe, was direkt auf den Fehler hinweist. Man müsste weiterhin den Bootvorgang genau beobachten, Logs lesen, analysieren etc.

Als Alternative: Da du ja noch auf deine Daten zugreifen kannst, nochmal schnell ein aktuelles Backup ziehen (inkl. Konfigurationsdateien in /etc/) und dann den Server neu aufsetzen. Strato bietet ja sicher irgendeinen automatisierten Dienst an, der ein aktuelles und frisches Ubuntu aufspielt.
Sofern dein System nicht extrem kompliziert ist, bist du damit in 1-2 Stunden fertig...
 
Wieso kommt da folgendes:
Code: 
* Stopping configure virutal network devices [OK]
Das sollte normal kommen, wenn man den Server wieder herunterfährt.

Was steht denn in der /etc/network/interfaces ?

Wahrscheinlich bist du schneller, wenn du den Server neu aufsetzt. Ist halt nur ärgerlich, da du dann den Fehler nicht kennst. Erfahrung ist wichtiger als Wissen.
 
Also System neu aufsetzen ist sicher einfachsten aber ich will die Ursache finden... Nachher tritt der Fehler erneut auf und ich stehe wieder vor dem Problem..
Ok ich schau mal was in Interfaces steht und poste es hier wieder..
Das sichern der Daten ist nicht so einfach ich bin beruflich Fotograf und habe einige Galerien für Kunden eingerichtet... Der Speicherplatz ist in /etc ja begrenzt auf 25 Gigabyte aber ich habe zur Not auch einen Backup Server dort könnte ich eventuell auch alles speichern...
Aber wie gesagt ich bin ein Freund von Ursachenforschung...
Mir ist noch eingefallen das ich damals auf einem Suse System ein ähnliches Problem hatte, da löschte ich irgendeine lock-Datei und alles war wieder gut.
Kann eventuell auch ein nicht richtig ausgeführtes Update ein Problem sein? Ich hatte den Server so eingestellt das er Updates automatisch machen soll gerade auch bei Plesk kann es ja manchmal zu Problemen kommen. Kann man irgendwo einsehen ob und wann Updates gemacht wurden?
 
zeusel said:
Kann man irgendwo einsehen ob und wann Updates gemacht wurden?
Click to expand...

Hast du eigentlich Kenntnisse in Sachen Systemadministration?

Zu deiner Frage:
Code: 
/var/log/apt/history.log

Dort würdest du auch Fehlermeldungen finden, sofern Pakete nicht korrekt aktualisiert werden konnten.
 
In /etc/network/interfaces steht:

Code: 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

d3p said:
Hast du eigentlich Kenntnisse in Sachen Systemadministration?
Click to expand...

Also ich habe schon fundierte Kenntnissem bin zwar kein Profi das mit Sicherheit nicht, aber ich habe letztendlich den Server auch selbst aufgesetzt und der lief ja bis dato....da aber die Datei ist leer...letzter Eintrag hier vom 21.10.

Dort habe ich folgende Zeile am Ende entdeckt:

Code: 
Error: Sub-process /usr/bin/dpkg returned an error code (1)

Ich weiß jetzt nicht ob ich den Server neu gebootet habe im Zeitraum bis jetzt...
 
zeusel said:
Also ich habe schon fundierte Kenntnissem bin zwar kein Profi das mit Sicherheit nicht, aber ich habe letztendlich den Server auch selbst aufgesetzt und der lief ja bis dato
Click to expand...

Das mit den fundierten Kenntnissen bezweifele ich nach deinen Versuchen, deine Festplatte im Rescue-System zu mounten, ganz stark.

Code: 
Error: Sub-process /usr/bin/dpkg returned an error code (1)
Click to expand...

Die Meldung deutet darauf hin, dass die Installation eines Paketes auf einen Fehler oder ein Problem gelaufen ist, welche einen manuellen Eingriff erfordert. Das ist auch der Grund, warum man Updates nicht unbeaufsichtigt installiert. Es kann durchaus sein, dass durch das fehlerhafte Update irgendwas essentielles beschädigt wurde. Es kann man evtl. über das Rescue-System korrigieren, indem man dort alle Partitionen passend mountet (und auch Sachen wie /dev und /proc bereitstellt) und dann per chroot versucht, die fehlerhafte Paketinstallation zu korrigieren.
 
Ein Kandidat für "bootet einfach nicht mehr, nix geändert" ist auch immer gerne, dass eine der kleineren Partitionen z.B. durch log Files oder Apt Caches oder sonstiges voll gelaufen ist.

Was sagt denn ein "df -h"?
 
Also das mit dem Update kann nicht das Problem sein. Die Fehlermeldung taucht schon seit Anfang des Jahres auf...und in der Zwischenzeit wurde der Server schon neu gestartet. Das Problem hätte damit schon früher auftauchen müssen.

df -h gibt folgendes:

Code: 
Filesystem      Size  Used Avail Use% Mounted on
rootfs          7.9G  108M  7.8G   2% /
none            7.9G  108M  7.8G   2% /
tmpfs           1.6G  252K  1.6G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            10M     0   10M   0% /dev
tmpfs           3.2G     0  3.2G   0% /run/shm
/dev/md126      1.8T  671G  1.1T  40% /mnt
/dev/md127      1.8T  671G  1.1T  40% /mnt

ABER ich erinnere mich, dass durch ein Backup die Platte des Server voll war... (automatisches Backup von Plesk). Danach löschte ich manuell die Backups und wollte den Server neu starten. Dann tauchte das Problem auf.

Vielleicht hilft das weiter?
Ich erinnere mich auch, dass ich bei einem älteren Server mit confixx ein ähnliches Problem hatte und da löschte ich dann eine lock-Datei und die Kiste lief wieder!? Das ist aber schon 6 oder 7 Jahre her...

Achso System auf dem jetzigen Server ist Ubuntu: 12.04 mit Plesk
 
Achso System auf dem jetzigen Server ist Ubuntu: 12.04 mit Plesk
Click to expand...

Das hätte ja wohl mal in den ersten Post gehört, meinst Du nicht? :rolleyes:

Das "df" ist unglaubwürdig, da Du nicht alle Partitionen gemountet / Partitionen falsch gemountet hast.

Was ist denn mit /dev/md125? Diese Partition ist nur 1GB groß und gehört anscheinend auch zum Raid? Wurde von Dir nicht gemountet.

Was mit der /dev/md126 ? Die sollte eigentlich "Disk /dev/md126: 21.0 GB" sein, bei Deinem df aber identisch zu md127?

Der Rest ist übrigens vom Rescue System, d.h. irrelevant.

Du hast 3 "md" Raid Partitionen, also solltest Du im Rescue System m.E. auch alle drei Partitionen mounten. Erst dann kann Dir df wirklich echte Werte liefern.

Nebenbei: wenn man https://blog.sleeplessbeastie.eu/2012/05/08/how-to-mount-software-raid1-member-using-mdadm/ glauben darf, muss man wohl erst mal ein virtuelles md device erstellen, bevor man mounten kann.

Ich bin nicht gerade ein Linux SW Raid Experte, aber mdadm wirst Du brauchen.
 
Ja sorry mit dem System hätte ich in den ersten Post packen sollen...ich korrigiere da noch den Eintrag.

Hm kann jemand vielleicht für mich da eine Anleitung geben wie ich das genau mounten muss?
 
Hmm, wie siehts mit ein wenig Eigeninititative aus? Wie wärs mit Lektüre von https://wiki.ubuntuusers.de/mount ?

Das Mounten in unixoiden Betriebssystemen läuft doch immer gleich.

Du erstellst einen Ordner irgendwo (z.B. /mnt/ordner1 , /mnt/ordner2 , /mnt/ordner3 ) und dann mountest Du da mit "mount [Parameter] Gerät Einhängepunkt" etwas rein. Der "Einhängepunkt" ist dabei der oben erstellte Ordner, der danach kein Ordner mehr ist, sondern den Inhalt des gemounteten Geräts darstellt.

Bevor Du jetzt hier blind o.g. abtippst, solltest Du erst mal wieder per "umount" Deinen mount Quatsch wieder ent-mounten. Du hast nämlich zwei md Geräte auf den gleichen Mountpoint gemountet, was "ungünstig" ist und von tiefgreifendem Unverständnis hinsichtlich was Du da machst zeugt.
 
Ok...erledigt und ich erhalte das:
Code: 
rootfs          7.9G  108M  7.8G   2% /
none            7.9G  108M  7.8G   2% /
tmpfs           1.6G  252K  1.6G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            10M     0   10M   0% /dev
tmpfs           3.2G     0  3.2G   0% /run/shm
/dev/md125      969M   13M  890M   2% /mnt/md125
/dev/md126       20G  3.3G   15G  18% /mnt/md126
/dev/md127      1.8T  675G  1.1T  40% /mnt/md127
 
Last edited by a moderator:
Okay, ist also nichts zu voll. chroot ins System und schauen, dass du deine Paketverwaltung wieder hinkriegst - apt-get install -f wäre (im chroot) mein erster Ansatz.
 
So ich habe nochmals in die syslog geschaut:

Code: 
Dec  7 14:26:14 h* dhclient: Bind socket to interface: No such device

An der Stelle geht es dann im Syslog nicht weiter und offenbar an der Stelle mache ich einen Neustart.

So dann habe ich die networking.log ausgelesen...dort steht folgendes:

Code: 
Cannot find device "eth0"
Failed to bring up eth0.
 
Last edited by a moderator:
Sieht danach aus, als wenn er die Netzwerkkarte nicht mehr findet - da sie aber in Rescuesystem funktioniert, dürfte es kein Hardware-Defekt sein (oder greifst du über die serielle Konsole auf das Rescue zu?)
Eine mögliche Ursache für das nicht mehr vorhandene eth0 könnte eine falsche udev-Regel sein. MAC-Adresse im Rescue ermitteln und dann mit den udev-Regeln vergleichen (bei meinem Debian die /etc/udev/rules.d/70-persistent-net.rules - dürfte bei Ubuntu ähnlich sein)
 
Also die MAC Adresse stimmt in den udev-Regeln...ich habe auch schon die 70-persistent-net.rules von dem startenden Rescue System mit der 70-persistent-net.rules von dem "normal" startenden System verglichen beide sind gleich.

ABER:

Auf dem Rescuesystem in der resolv.conf steht folgendes:

Code: 
domain stratoserver.net
search stratoserver.net
nameserver ne IP-ADRESSE
nameserver noch ne IP ADRESSE
nameserver noch ne IP ADRESSE

Im "normalen" System ist die resolv.conf ein Link:

Code: 
resolv.conf -> ../run/resolvconf/resolv.conf

Gehe ich nun in das Verzeichnis run gibt es dort kein Verzeichnis resolvconf und damit auch nicht die resolv.conf

Könnte hier das Problem sein? Ich habe die Datei und den Pfad einmal angelegt, gebracht hat es aber leider nichts.
 
Die /run/resolvconf/resolv.conf wird zur Laufzeit dynamisch generiert, das ist normal, dass die im Rescue nicht vorhanden ist. Die ist auch nur für die Namesauflösung zuständig, fehlt sie, funktioniert die DNS-Auflösung nicht, aber das System sollte trotzdem starten.
 
So nochmals ein neuer Syslog von heute:

Code: 
Dec  8 08:55:59 h2096746 kernel: [    9.775865] Bluetooth: HCI device and connection manager initialized
Dec  8 08:55:59 h2096746 kernel: [    9.775867] Bluetooth: HCI socket layer initialized
Dec  8 08:55:59 h2096746 kernel: [    9.775868] Bluetooth: L2CAP socket layer initialized
Dec  8 08:55:59 h2096746 kernel: [    9.775870] Bluetooth: SCO socket layer initialized
Dec  8 08:55:59 h2096746 bluetoothd[520]: Failed to init alert plugin
Dec  8 08:55:59 h2096746 bluetoothd[520]: Failed to init time plugin
Dec  8 08:55:59 h2096746 bluetoothd[520]: Failed to init proximity plugin
Dec  8 08:55:59 h2096746 bluetoothd[520]: Failed to init gatt_example plugin
Dec  8 08:55:59 h2096746 kernel: [    9.820336] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Dec  8 08:55:59 h2096746 kernel: [    9.820337] Bluetooth: BNEP filters: protocol multicast
Dec  8 08:55:59 h2096746 kernel: [    9.867093] Bluetooth: RFCOMM TTY layer initialized
Dec  8 08:55:59 h2096746 kernel: [    9.867096] Bluetooth: RFCOMM socket layer initialized
Dec  8 08:55:59 h2096746 kernel: [    9.867097] Bluetooth: RFCOMM ver 1.11
Dec  8 08:55:59 h2096746 dhclient: Bind socket to interface: No such device

Nach dem letzten Status kein Eintrag mehr in der syslog.
 
Wie wäre es denn mal damit, überflüssiges Zeug rauszuwerfen, wie beispielsweise die Bluetooth-Unterstützung? Ich glaube kaum, dass du die benötigst...
 
Gestartet wird ja alles was in init.d steht richtig? Wenn ich da entsprechende Einträge entferne werden die Dienste nicht gestartet, richtig verstanden?
 
You must log in or register to reply here.
Back
Top