Ubuntu Server Rescue Mode

ties0

New Member
Moin,

hab eben den Server rebootet. Danach ist er laut Hoster in den Rescue Mode gegangen.

fdisk -l ergibt folgendes:

Code:
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1275    10241406   83  Linux
/dev/sda2            1276       30336   233432482+  83  Linux
/dev/sda3           30337       30401      522112+  82  Linux swap / Solaris

Hab dann mal gemountet.

cat /mnt/etc/fstab erhalte ich anschließend folgendes:

Code:
# <sys.fichiers><pt de montage><type> <options>  <dump> <pass>
/dev/sda1       /       ext3    errors=remount-ro       0       1
/dev/sda2       /home   ext3    defaults        1       2
/dev/sda3       swap    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Kann mir hier vielleicht jemand weiterhelfen, wie ich den Server wieder dazu bekomme normal zu booten? :confused:
 
Als nächstes solltest Du in /mnt/var/log Dir die Logfiles zu Gemüte führen um rauszufinden, warum das System nicht booten will.

Hast Du bereits geprüft, ob eine der Partitionen einen Filesystemcheck braucht?
 
Hm ja die Logs.. ist so eine Sache, wenn man sich noch nie so wirklich damit auseinandergesetzt hat. Da sind eben schon recht viele Logs.

Wie kann ich prüfen ob eine Partition ein Filesystemcheck braucht?

In der checkfs steht nichts weiteres drin:

Code:
Log of fsck -C -R -A -y 
Sat Jun 27 18:04:25 2009

fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
/home: clean, 266/29179904 files, 53408898/58358120 blocks

Sat Jun 27 18:04:25 2009
----------------
 
Last edited by a moderator:
Umounte die Laufwerke und mach den Check mit e2fsck für alle Dateisysteme (sda1 und sda2), dann wirst ja direkt feststellen, ob ein Problem vorliegt. Einfache Probleme werden direkt behoben, größere werden moniert und müssen manuell (entsprechende Parameter) behoben werden.

Ein Blick ins Log, hier /var/log/kern.log zeigt, ob er die Festplatten mounted und die Netzwerkkarte startet:

Code:
EXT3 FS on sda1, internal journal
und
Code:
eth0: link up

Nun, die Frage, warum Rescue-Modus? Ist der Server mit einem Mal down gewesen und liess nicht rebooten? Oder wurde an der Konfiguration des Netzwerks etwas geändert, so z.B. an der /etc/network/interfaces

Unabhängig vom Umstand, dass der Server zwar im Rescue-Modus gebooted werden kann und im normalen Betrieb nicht, stellt sich eben die Frage, was war der Auslöser.
 
Ich erhalte hier dann folgendes:

Code:
rescue:~# fsck /dev/sda1
fsck 1.37 (21-Mar-2005)
e2fsck 1.37 (21-Mar-2005)
/: clean, 182106/1281696 files, 861597/2560351 blocks
rescue:~# fsck /dev/sda2
fsck 1.37 (21-Mar-2005)
e2fsck 1.37 (21-Mar-2005)
/home: clean, 266/29179904 files, 53408898/58358120 blocks

Die Überprüfung ist direkt nach der Eingabe ersichtlich. Hoffe das war der richtige Befehl.

Ich hab den Server bei OVH. Ich hab diesen rebootet. Nach dem reboot stell ich fest das ich über SSH Port 17 nicht mehr reinkomme. Schaue ob der Standartport 22 geht, hier geht es. Mit den sonst genutzten Daten geht es nicht. Ich schreib den reseller an. Dieser teilt mir mit, dass der Server im Resue Mode gebootet ist und gibt mir auch das Passwort hierfür. Mehr hab ich da auch nicht gemacht. Kam eben gleich nach dem reboot das Problem.

Ich habe mal in der kern.log geschaut.

Code:
EXT3 FS on sda1, internal journal

Steht dort.

Code:
eth0: link up

Konnte ich dort nicht finden.

Das einzigste was zu eth0 steht ist folgendes:
Code:
IP-Config: Complete:
device=eth0, addr=.....
 
Last edited by a moderator:
Zum Mitdenken:
Du lässt den Server rebooten - via Kundeninterface bei Deinem Provider?
Der Befehl reboot auf der Rettungskonsole lässt den Server erneut in den Rescue-Modus laufen, oder wie verstehe ich dies?

Grundsätzlich wäre es denkbar, dass der Netzwerkadapter wegen fehlerhafter Konfiguration nicht geladen wird.
Überprüfe doch mal die Einträge in /etc/network/interfaces
Aber grundsätzlich kommt so ein Problem nicht einfach daher, bei einem bis dato laufenden System muß hier eine Änderung erfolgt sein.

Wenn der Server allerdings bei jedem reboot in den Rescue-Modus läuft, stimmt etwas anderes nicht. Da mußt Du Dich nochmal mit Deinem Hoster in Verbindung setzen.
 
Also ich hab den Server rebooten lassen, nicht über das interface des Providers. Mir steht hier keins zur verfügung, da ich bei einem reseller bin, der dieses mir nicht anbietet über ovh. Hab den Server wärend des betriebes über die Konsole einfach rebooten lassen. Es dauert und dauert, bis der Server wieder erreichbar ist, zu meinem verwundern, ist dieser aber per SSH nicht über mein eingerichteten Port 17 zu erreichen, sondern über Port 22 und er befindet sich im Rescue Mode. Wenn der Server nicht mehr richtig booten kann wird er wohl automatisch in diesen Modus gesetzt. Der Reseller hat hier in der Richtung wohl nichts gemacht. War auch direkt der Fall, nachdem ich den reboot ausgeführt habe. Das ganze ist jetzt schon das 2 mal passiert. Letztes mal habe ich den Server neuaufsetzen lassen, nur diesmal möchte ich dies eben umgehen.

Ich hab mal die Partition gemountet und unter /etc/network/interfaces geschaut, hier sieht für mich alles normal aus. Ich hab auch sonst an dem Server eig nichts verändert. Ich hab die Kiste nur rebooten lassen, weil lighttpd eine sehr hohe CPU Auslastung hatte und die Page nicht mehr richtig zum laufen ging. Dachte ein reboot könnte nicht schaden. Tja hat es nun doch und nun steh ich da..

Der Reseller sagt mir nur ich soll den Server über den Rescure Mode retten damit er wieder normal booten kann oder er kann eine neuinstallation des OS veranlassen.
 
Also, ich bin ein wenig verwundert, warum der Server immer wieder autom. im Rescue-Mode startet.

Wenn die Serverkonfiguration fehlerhaft ist, dann bliebe der Server während des Boot-Vorgangs entweder einfach mit einer Meldung stehen oder würde zwar bis zum Login fortfahren, jedoch bestimmte Dienste, wie z.B. die für das Netzwerk wären schlicht nicht gestartet. Nur mit einer seriellen Konsole könnte man dann noch sehen, was hier das Problem ist. Der Zugriff via ssh wäre dann nicht mehr möglich.

In jedem Fall müsste man den Rescue-Mode beim Hoster wie auch immer jedes Mal neu anfordern.

Könnte es auch sein, dass in /boot/grub/menu.lst eine anderer Startmodus als der übliche als default gesetzt ist?
 
Hm sieht bei mir wie folgt aus:

Code:
# menu.lst - See: grub(8), info grub, update-grub(8)
#            grub-install(8), grub-floppy(8),
#            grub-md5-crypt, /usr/share/doc/grub
#            and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not use 'savedefault' or your
# array will desync and will not let you boot your system.
default		0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout		3

## hiddenmenu
# Hides the menu by default (press ESC to see the menu)
hiddenmenu

# Pretty colours
#color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line)  and entries protected by the
# command 'lock'
# e.g. password topsecret
#      password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title		Windows 95/98/NT/2000
# root		(hd0,0)
# makeactive
# chainloader	+1
#
# title		Linux
# root		(hd0,1)
# kernel	/vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=5d6adfea-7032-4a8e-9e79-738466a90ecf ro

## Setup crashdump menu entries
## e.g. crashdump=1
# crashdump=0

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
##      alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
##      lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet splash

## should update-grub lock old automagic boot options
## e.g. lockold=false
##      lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(recovery) single
# altoptions=(recovery mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
##      memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## should update-grub add savedefault to the default options
## can be true or false
# savedefault=false

## ## End Default Options ##

title		Ubuntu 8.04, kernel 2.6.24-16-server
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.24-16-server root=UUID=5d6adfea-7032-4a8e-9e79-738466a90ecf ro quiet splash
initrd		/boot/initrd.img-2.6.24-16-server
quiet

title		Ubuntu 8.04, kernel 2.6.24-16-server (recovery mode)
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.24-16-server root=UUID=5d6adfea-7032-4a8e-9e79-738466a90ecf ro single
initrd		/boot/initrd.img-2.6.24-16-server

title		Ubuntu 8.04, memtest86+
root		(hd0,0)
kernel		/boot/memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST
 
Die menu.lst sieht auf den ersten Blick ganz normal aus. default ist 0, also wird der erste Eintrag der mit title beginnt genommen. timeout und hiddenmenu regeln, dass mit dem Boot-Vorgang ohne Menü und nach 3 Sek. fortgefahren wird, das ist auch OK.

Hast Du einen VServer bei Deinem Reseller gemietet?

Du kannst ja nach dem Reboot mal ohne jegliches mounten einfach das Passwort von Root ändern, rebooten und dann mal schauen, mit welchem Kennwort Du Dich anmelden kannst. Wenn die Änderung tatsächlich greift, dann wird sicher nicht der Rescue-Mode geladen, sondern der Server normal gestartet.

Im anderen Falle mußt Du Dich mit Deinem Reseller in Verbindung setzen, denn dann liegt die Problemlösung nicht mehr in Deiner Hand.
 
Ist kein vServer. Ist ein Rootserver. Hm ja. Also ich hab ihm gerade gesagt, er solle den Server mal im normalen Modus booten lassen. Hat er gemacht hat er geschrieben, nun ist der Server nicht pingbar/down. Hm.. :/

Ok so wie es aussieht wird es länger versucht und dann geht er automatisch in den Rescure Mode.. Server ist nun wieder Pingbar und SSH geht auch mal wieder im Rescue Mode.
 
Last edited by a moderator:
Mal zum Mitschreiben:
  • Dein Root-Server ist up and running
  • Tag X, der Root-Server bockt.
  • Du forderst bei Deinem Hoster einen Reset an.
  • Dein Hoster macht einen Reset.
  • Er, also Dein Hoster stellt fest, dass auf den Server nicht zugegriffen werden kann. z.B. ein Ping
  • Als Folge hieraus startet er den Server wieder in den Rescue-Mode und fertig.
  • Und alles was Dir bleibt, ist quasi ein Server, der nur noch in den Rescue-Mode fährt.
War das jetzt so richtig?

Welches Ereignis bzw. Timeout ist für Deinen Hoster Anlass, den Rechner in den Rescue-Mode zu versetzen? Ich frage deshalb, weil ich das ungewöhnlich finde.

Einen Hoster interessiert doch üblicherweise doch nur die pünktliche Überweisung der Miete für den Server. Alles andere ist zunächst mal Dein Bier. Vielleicht gibt es dann noch ein paar Addons, wie z.B. fertige OS-Images, Monitoring-Tools, usw.

Nun das Fischen im Trüben:
Prüfe mal die /var/log/dmesg. Welches Datum und Uhrzeit hat diese Log-Datei? Die vom letzten Reboot, oder älter?
Wenn diese Datei älter ist, dann wird entweder dieses System nicht gestartet oder während des Boot-Vorgangs kann das Laufwerk mit dem Verzeichnis /var nicht gemounted werden.
Entspricht Datum und Zeit dem des letzten regulären Versuchs, dann sind wir ein Stück weiter.

Auch hier taucht im Protokoll in der Regel relativ spät das Starten der Netzwerkkarte auf (eth0: link up). Fehlt dieses, wird die Netzwerkkarte nicht gestartet.
Vergleiche mal die /etc/network/interfaces des Rettungssystems mit der Deines root-Server. Gibt es hier Abweichungen. Wenn ja, welche?

Im anderen Fall liegt das Problem bei Deinem Hoster, denn die grub sieht so aus, dass von /dev/sda1 und dem Verzeichnis /boot/ aus auch gebootet wird.

Mehr fällt mir im Moment auch nicht ein. :(
 
Back
Top