Strato dedizierter Ubuntu 14.04 Server bootet nicht richtig

Pestichen

Pestichen

New Member
Freundliches Hallo in die Runde,
war bis jetzt meist nur lesend hier. Nun habe ich leider wirklich ein Anliegen das mit den Kopf etwas mürbe macht.

Betreibe schon seit längeren einen eigenen Rootserver von Strato.
Auf dem Server läuft momentan ein Plesk 12.5.30, und generell bin ich rundum zufrieden mit der Kiste.

Allerdings ist mir beim letzten Update halt aufgefallen das der Server gerne einen Neustart hätte (beim Login gemeldet worden). (btw. das Upgrade beinhaltete Kernel Images)

Nun dachte ich mir nichts weiteres dabei und führe "shutdown -r now" aus.
Nach 30 minütiger Stille vom Server habe ich einmal das ganze nochmal mit dem Recoverymodus versucht. Und nach knapp 3 Minuten war der Server im Recovery erreichbar.

Ich konnte irgendwie nichts feststellen und machte erneut einen Reboot in den "normalen" Modus.
Und "schwups" war der Server wieder erreichbar ?! (dabei habe ich nichts geändert).

Aber wenn ich den Server nun wieder neustarten will geht das nur sobald ich einmal im Recovery war.

Das ist ja nicht der Sinn der Sache, und bräuchte ich einmal Hilfe bei dem Thema da ich mich selber mit den "Bootvorgängen" wenig auskenne.
Ich habe einmal das Ergebnis vom "bootinfoscript" in den Anhang gelegt da ich mir nur etwas mit den Kernelimages vorstellen kann, da sonst das System wunderbar läuft.

Wäre jemand so nett? :)
 

Attachments

Sofern bei deinem Server die serielle Konsole dabei ist, schau beim nächsten Reboot darüber drauf, was der Server die ganze Zeit macht. Kann ja sowas banales sein wie der reguläre fsck, der das Dateisystem prüft (was abhängig von der Größe der Platten und dessen Füllgrad auch schon mal sehr lange dauern kann) oder er hängt beim Initialisieren einer Hardware-Komponente, usw.
 
Das lustige an der Sache ist die, dass die console immer schwarz ist. Man sieht das der Server mit einer Newline antwortet nach dem Login aber Sie bleibt schwarz.

Aber ich probiere gleich nach einem Backup einen normalen reboot und schau in die Serielle Konsole.

Die Platte ist 1TByte groß im Raid 1.
Und das Acronis Backup beträgt ungefähr 35 GB (Systembackup).
 
Last edited by a moderator:
Nach dem Login in der virtuellen Konsole mußt du noch einmal Enter drücken, bevor aus der seriellen Konsole eine Ausgabe erscheint. Steht aber meine ich bei Strato so beschrieben. Wichtig ist auch, dass die Verbindung schon steht, bevor der Server hängt - auf der seriellen Konsole kommen (im Gegensatz zu einem normalen Monitor) nur neue Ausgaben - wenn keine mehr erfolgt, wird in der seriellen Konsole nichts ausgegeben.
 
Kann gut sein da war ich wohl immer zu langsam bis jetzt.
Aber ich habe nun die letzten Updates mal per Seriellen Konsole eingespielt und habe etwas gefunden.

Code: 
update-initramfs: Generating /boot/initrd.img-3.13.0-88-generic
W: mdadm: the array /dev/md/h2530521:0 with UUID a2a88824:5141f83e:b243d2c2:5e5c076a
W: mdadm: is currently active, but it is not listed in mdadm.conf. if
W: mdadm: it is needed for boot, then YOUR SYSTEM IS NOW UNBOOTABLE!
W: mdadm: please inspect the output of /usr/share/mdadm/mkconf, compare
W: mdadm: it to /etc/mdadm/mdadm.conf, and make the necessary changes.
W: mdadm: the array /dev/md/h2530521:1 with UUID 59c2fd3b:90e779e3:86a8d7eb:dc2ecde8
W: mdadm: is currently active, but it is not listed in mdadm.conf. if
W: mdadm: it is needed for boot, then YOUR SYSTEM IS NOW UNBOOTABLE!
W: mdadm: please inspect the output of /usr/share/mdadm/mkconf, compare
W: mdadm: it to /etc/mdadm/mdadm.conf, and make the necessary changes.

Ich meine da stehts ja sogar "YOUR SYSTEM IS NOW UNBOOTABLE!"
Dann habe ich direkt mal die Raidteilnehmer wie folgt unter die Lupe genommen.

Code: 
root@h2530521:~# mdadm --misc --detail /dev/md126
/dev/md126:
        Version : 1.0
  Creation Time : Wed Aug  3 09:05:12 2016
     Raid Level : raid1
     Array Size : 971736896 (926.72 GiB 995.06 GB)
  Used Dev Size : 971736896 (926.72 GiB 995.06 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Wed Aug  3 13:18:31 2016
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : h2530521:1
           UUID : 59c2fd3b:90e779e3:86a8d7eb:dc2ecde8
         Events : 10

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

	   
root@h2530521:~# mdadm --misc --detail /dev/md127
/dev/md127:
        Version : 1.0
  Creation Time : Wed Aug  3 09:05:11 2016
     Raid Level : raid1
     Array Size : 1023936 (1000.11 MiB 1048.51 MB)
  Used Dev Size : 1023936 (1000.11 MiB 1048.51 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed Aug  3 13:15:38 2016
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : h2530521:0
           UUID : a2a88824:5141f83e:b243d2c2:5e5c076a
         Events : 4

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

Sehe ich das nun richtig das ich manuell die letzten beiden Zeilen aus der
"/etc/mdadm/mdadm.conf" die wie folgt aussehen:

Code: 
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

# This file was auto-generated on Tue, 10 Jun 2014 12:42:09 +0000
# by mkconf $Id$
ARRAY /dev/md/0 metadata=1.0 UUID=9bf65271:5b1b59c4:71059bca:c311762b name=h253
ARRAY /dev/md/1 metadata=1.0 UUID=91990b5d:292d4ac3:bec96306:07ee4230 name=h253

Abändern soll mit den aktuellen Werten aus "mdadm --misc --detail /dev/md126" und "mdadm --misc --detail /dev/md17" ??

Musste ich bis jetzt nie machen, wundert mich nun etwas warum da jetzt Handarbeit nötig ist.
 
Die /etc/mdadm/mdadm.conf scheint ja offensichtlich nicht zu deiner RAID-Konfiguration zu passen. Wie du sie neu generieren kannst, ist z.B. hier beschrieben (etwa nach einem Drittel der Seite). Anschließend die Initramdisc einmal neu generieren.
Allerdings glaube ich weniger, dass es daran liegt, denn dann würde der Server auch nicht mehr booten, nachdem er einmal im Recovery gestartet wurde. Sofern der Partitionstypt korreckt auf Linux RAID Autodetect steht, erkennt der Linux-Kernel das RAID automatisch und ließt die Metadaten direkt vom RAID-Verbund und nicht aus der mdadm.conf.
Wichtiger wäre die Ausgabe, sobald den den Server rebootest.
 
Naja ... wie soll ich es sagen.
gerade neu gestartet und es lief sofort alles sauber durch (konnte dies auch in der Konsole sehen).
Ich habe einfach die Einträge wie es da stand angepasst und nun läuft es einwandfrei.

Aber vielen Dank für die Tipps und den Beistand :)
Bin nun wieder fröhlicher Serverpapa. :):)

*Woher das kommt kann ich nur erahnen, denke das hatte wohl mal mit einem gescheiterten Update des Kernelimage zu tun wo meine Wenigkeit zusätzlich gepennt hat.*
 
You must log in or register to reply here.
Back
Top