Server bootet nach update nicht mehr

S

spanier

New Member
Gelöst: Server bootet nach update nicht mehr

Hallo allerseits,

ich bin neu hier, habe seit einigen Tagen einen Root-Server und schon dicke Probleme. Ich hoffe, Ihr könnt mir besser helfen als der inkompetente Support meines Providers.

Was habe ich gemietet:

Einen Server mit SuSE 10.2 und Plesk 8.x

Was habe ich gemacht, als der Server noch richtig lief:

Mit Yast einen Online-Update. Dabei wurde auch der Kernel aktualisiert, was einen Reboot erforderlich machte. Das war's. Seit dem bootet der Server nicht mehr.

Ich kann das Rescue System aktivieren und komme mit der Seriellen Console auch auf den Server. Nach Kontakt mit der Hotline habe ich eine Mail erhalten, was ich tun sollte. Ich bin danach vorgegangen, allerdings ohne Erfolg. Die empfohlene Vorgehensweise der Hotline ist folgende:

- Rescue System starten -> OK
- Login uaf dem Server -> OK
- Mounten der Platten md1, md5 und md8 -> OK
- Danach chroot /mnt --> OK
- Danach Ausführen von lilo --> OK
- Platten unmounten --> OK
- Erneuter Rebbot aus dem Control Center --> wird durchgeführt, aber Server ist nicht erreichbar

Erneutes Telefonat mit der Hotline - erfolglos, die übermittelten Informationen waren unbrauchbar.

Folgendes habe ich festgestellt:

Es gibt noch zwei weitere Platten, md6 und md7 die nicht gemountet werden können. Bei Ausführung des Mount-Kommandos hängt die Session, kann nicht gekillt werden und ein neuer Start des Rescue-System ist notwendig.

fdisk -l gibt folgendes aus:
Code: 
rescue:~# fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         123      987966   fd  Linux raid autodetect
/dev/sda2             124         367     1959930   82  Linux swap / Solaris
/dev/sda4             368       19457   153340425    5  Extended
/dev/sda5             368         976     4891761   fd  Linux raid autodetect
/dev/sda6             977        1585     4891761   fd  Linux raid autodetect
/dev/sda7            1586        4018    19543041   fd  Linux raid autodetect
/dev/sda8            4019       19457   124013736   fd  Linux raid autodetect

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         123      987966   fd  Linux raid autodetect
/dev/sdb2             124         367     1959930   82  Linux swap / Solaris
/dev/sdb4             368       19457   153340425    5  Extended
/dev/sdb5             368         976     4891761   fd  Linux raid autodetect
/dev/sdb6             977        1585     4891761   fd  Linux raid autodetect
/dev/sdb7            1586        4018    19543041   fd  Linux raid autodetect
/dev/sdb8            4019       19457   124013736   fd  Linux raid autodetect

Disk /dev/md8: 126.9 GB, 126989959168 bytes
2 heads, 4 sectors/track, 31003408 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md8 doesn't contain a valid partition table

Disk /dev/md7: 20.0 GB, 20012007424 bytes
2 heads, 4 sectors/track, 4885744 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md7 doesn't contain a valid partition table

Disk /dev/md6: 5009 MB, 5009047552 bytes
2 heads, 4 sectors/track, 1222912 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md6 doesn't contain a valid partition table

Disk /dev/md5: 5009 MB, 5009047552 bytes
2 heads, 4 sectors/track, 1222912 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md5 doesn't contain a valid partition table

Disk /dev/md1: 1011 MB, 1011548160 bytes
2 heads, 4 sectors/track, 246960 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md1 doesn't contain a valid partition table

Wenn das Rescue-System neu gestartet ist, bringt ein mount auf md6 diese Meldung:
Code: 
rescue:~# mount /dev/md6 /mnt
Killed
rescue:~#
Message from syslogd@rescue at Tue Mar 11 00:48:37 2008 ...
rescue kernel: Oops: 0000 [2] SMP

Message from syslogd@rescue at Tue Mar 11 00:48:37 2008 ...
rescue kernel: CR2: 0000000000000008
Das gleiche Ergebnis erhalte ich beim mount von md7. Die Devices m1, md5 und md8 lassen sich ohne Probleme mounten.


Ein xfs_check bringt folgende Meldung:
Code: 
rescue:~# xfs_check -v /dev/md6
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

Das empfohlene xfs_repair -L /dev/md[6|] startet, friert die Session ein und einer neuer Start des Rescue-Systems wird notwendig. Das Kommando kann nicht gekillt werden.

Das ist der Stand heute morgen. Ich hoffe Ihr könnt aus diesen Angaben entwas entnehmen, was mir helfen kann, den Server ohne Neuinitialisierung wieder flott zu bekommen.

Ach ja, noch etwas:

Der Zugriff auf das syslog ist das syslog des Rescue-Systems. Die syslogs des Servers liegen auf md6 oder 7, die ja nicht gemountet werden können.

Schon mal im Voraus vielen Dank für Eure Hilfe.

Spanier
 
Last edited by a moderator:
Hi,

bist Du Dir ganz sicher dass Du nichts außer einem Kernelupdate über yast gemacht hast?

Also Suse benutzt kein Lilo sondern den Grub Bootmanger..also kann das mit dem Support-Tipp nicht funzen.
Die Strato Server benutzen einen Standard.Kernel.. bei mir hat seit 2 Jahren ein Kernelupdate immer ohne Probleme funktioniert.

Ich hatte mir mal vor langer Zeit aus irgendeinem Forum den Tipp von einem anderen Mitglied notiert, vielleicht hilft er Dir:

Wie folgt vorgehen: Code:
# cd /
# mount /dev/md1 /mnt
# mount /dev/md0 /mnt/boot
# cd /mnt/boot
# ls -l
# cd grub
# ls -l
# mv menu.lst menu.lst.kernelUpdate
# cp menu.lst.old menu.lst


Unbedingt mit der Remote Console verbunden bleiben! ...dann...

Wieder rückändern im Strato Configbereich: Serverkonfiguration -> RecoveryManager -> Bootmodus: Normaler Boot

Dort NICHT Ankreuzen: Reset [ ] -> Weiter (Beim nächsten Reboot startet das System ganz normal)

Und dann wieder auf der RemoteConsole: Code:
# reboot
 
... und bevor Du wild mit fschk rumfuhrwerkst und dadurch Partitionen evlt. unbrauchbar machst, solltest Du wissen, ob, wo und wie die Partitionen im "normalen" System gemountet werden (der Support schreibt ja was von md1, md5 und md8).
Daher versuchen, die root-Partition zu mounten und dann in /mnt/etc/fstab nachschauen! (Es schadet auch nichts eine Kopie dieser Datei (und der anderen Festplatteninformationen) zu Hause zu haben, damit man einfacher nachschauen kann)...
 
@RuthServer

ja, ich bin ganz sicher. Es wird definitiv lilo als bootloader verwendet, nicht grub!

@LinuxAdmin

ich weis schon, was ich tue. Leider gibt es für xfs filessysteme keine vernünftige Beschreibung. Die man-pages geben da nicht viel her. Der Support und unter aller s..
Ich habe den Platin-Service beim Server hinzugebucht und wurde nach einem Anruf abgekanzelt. Den vom Provider zu meinem Vertrag angegebene Servicemanager gibt es im Unternehmen angeblich nicht! Hilfe zu Lösung meines Problemes wurde schlichtweg abgelehnt.

Ich werde die Sache so lösen:

Falls bis heute abend der Server nicht in vollem Unfang zur Verfügung steht, mache ich von meinem Rücktrittsrecht gebrauch. Ich zahle für den Root-Server einschließlich Platin-Service 90 Euro im Monat und soll mich dann noch ärgern?

Es gibt sicher andere Provider, die in Frage kommen.

Gruß

Spanier
 
Hallo,

spanier said:
Die Devices md1, md5 und md8 lassen sich ohne Probleme mounten.
Click to expand...
dann mounte mal md1 und zeige was drin ist (ls -al).

Bzgl. Rücktrittsrecht bei Dienstverträgen und bereits erbrachter Leistung mal kräftig googeln oder einen Juristen fragen.
 
Last edited by a moderator:
Hallo Charli,

hier der Inhalt von md1:
Code: 
rescue:~# ls -l /mnt
total 144
-rw-------   1 root root  7168 Nov  2 12:09 aquota.user
drwxr-xr-x   2 root root  4096 Mar 10 19:39 bin
drwxr-xr-x   4 root root  4096 Mar 11 08:34 boot
drwxr-xr-x  10 root root 12288 Dec 13 14:02 dev
drwxr-xr-x  73 root root  8192 Mar 10 23:10 etc
drwxr-xr-x   2 root root  4096 Feb 28 13:39 home
drwxr-xr-x   7 root root  4096 Feb 11 09:48 lib
drwxr-xr-x   5 root root  4096 Mar 10 19:38 lib64
drwx------   2 root root 49152 Feb 28 13:47 lost+found
drwxr-xr-x   2 root root  4096 Sep 18 12:36 media
drwxr-xr-x   2 root root  4096 Nov 25  2006 mnt
drwxr-xr-x   4 root root  4096 Sep 18 12:20 opt
dr-xr-xr-x   2 root root  4096 Dec 29  2006 proc
drwx------   7 root root  4096 Mar 10 17:56 root
drwxr-xr-x   3 root root  8192 Mar 10 19:39 sbin
drwxr-xr-x   2 root root  4096 Feb 28 13:39 srv
-rw-r--r--   1 root root     0 Mar 10 19:45 success
drwxr-xr-x   2 root root  4096 Nov  5 12:11 sys
drwxrwxrwt   2 root root  4096 Mar 10 23:19 tmp
drwxr-xr-x   2 root root  4096 Feb 28 13:39 usr
drwxr-xr-x   3 root root  4096 Feb 28 13:56 var
 
Last edited by a moderator:
Hallo,

danke, hatte was anderes erwartet. :o

Zeig mal den Verzeichnisinhalt von /boot sowie die menu.lst.
 
Das ist der Inhalt von boot:
Code: 
rescue:~# ls -l /mnt/boot
total 17016
-rw-r--r--  1 root root  954130 Feb 11 03:22 System.map-2.6.18.8-0.9-default
-rw-r--r--  1 root root 1290771 Nov  8 13:04 System.map-2.6.20.21-071108a
-rw-r--r--  1 root root 1357460 Feb 11 09:48 System.map-2.6.23.16-20080211a
-rw-------  1 root root     512 Sep 19 10:24 backup_mbr
lrwxrwxrwx  1 root root       1 Feb 28 13:45 boot -> .
-rw-r--r--  1 root root     512 Feb 28 13:47 boot.0800
-rw-r--r--  1 root root     512 Feb 28 13:47 boot.0810
-rw-r--r--  1 root root   64134 Feb 11 03:29 config-2.6.18.8-0.9-default
-rw-r--r--  1 root root   34910 Nov  8 12:54 config-2.6.20.21-071108a
-rw-r--r--  1 root root   35586 Feb 11 09:39 config-2.6.23.16-20080211a
drwxr-xr-x  2 root root    4096 Oct 31 17:17 grub
lrwxrwxrwx  1 root root      27 Mar 10 19:40 initrd -> initrd-2.6.18.8-0.9-default
-rw-r--r--  1 root root 3179727 Mar 10 19:40 initrd-2.6.18.8-0.9-default
drwx------  2 root root   49152 Feb 28 13:47 lost+found
-rw-------  1 root root  147968 Mar 10 23:24 map
-rw-------  1 root root  379904 Sep 19 10:24 message
-rw-r--r--  1 root root   86439 Feb 11 03:30 symsets-2.6.18.8-0.9-default.tar.gz
-rw-r--r--  1 root root  338740 Feb 11 03:30 symtypes-2.6.18.8-0.9-default.gz
-rw-r--r--  1 root root   99320 Feb 11 03:30 symvers-2.6.18.8-0.9-default.gz
-rwxr-xr-x  1 root root 2114871 Feb 11 03:29 vmlinux-2.6.18.8-0.9-default.gz
lrwxrwxrwx  1 root root      28 Mar 10 19:40 vmlinuz -> vmlinuz-2.6.18.8-0.9-default
-rw-r--r--  1 root root 1618433 Feb 11 03:22 vmlinuz-2.6.18.8-0.9-default
-rw-r--r--  1 root root 2875376 Nov  8 13:04 vmlinuz-2.6.20.21-071108a
-rw-r--r--  1 root root 2687416 Feb 11 09:48 vmlinuz-2.6.23.16-20080211a
lrwxrwxrwx  1 root root      25 Feb 28 13:45 vmlinuz.old -> vmlinuz-2.6.20.21-071108a

Da lilo der bootloader ist hier die lilo.conf:

Code: 
rescue:~# cat /mnt/etc/lilo.conf
# Modified by YaST2. Last modification on Mon Mar 10 14:41:10 EDT 2008
boot = /dev/sda
root = /dev/md1
install = /boot/boot.b
vga = normal
timeout = 60
prompt
lba32
read-only
default = Linux
serial = 0,57600n8
append = "console=ttyS0,57600 console=tty0"

image = /boot/vmlinuz-2.6.18.8-0.9-default
###Don't change this comment - YaST2 identifier: Original name: linux###
    label = Linux
    append = " console=tty0 console=ttyS0,57600 panic=30"
    initrd = /boot/initrd-2.6.18.8-0.9-default
    root = /dev/md1

image = /boot/vmlinuz-2.6.18.8-0.9-default
###Don't change this comment - YaST2 identifier: Original name: failsafe###
    label = Failsafe
    append = "showopts ide=nodma apm=off acpi=off noresume edd=off 3"
    initrd = /boot/initrd-2.6.18.8-0.9-default
    root = /dev/md1


image = /boot/vmlinuz
    label = lxser
    append = " console=tty0 console=ttyS0,57600 panic=30"


image = /boot/vmlinuz
    label = lx

Das ist dann die menu.lst aus boot/grub:
Code: 
rescue:~# cat /mnt/boot/grub/menu.lst
# Modified by YaST2. Last modification on Tue Sep 18 10:23:59 UTC 2007
default 0
timeout 8

##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.2
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.18.2-34-default root=/dev/sda7 resume=/dev/sda2 splash=silent showopts console=tty1 console=ttyS0,57000
    initrd /boot/initrd-2.6.18.2-34-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.2
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.18.2-34-default root=/dev/sda7 showopts ide=nodma apm=off acpi=off noresume edd=off 3
    initrd /boot/initrd-2.6.18.2-34-default

Der Kundenservice hat mir versichert, das lilo der bootloader ist.
 
Last edited by a moderator:
Hallo,

Yast hat beim Update die lilo.conf umgeschrieben aber nicht die menu.lst, dann wird wohl wirklich Lilo laufen.

25 Feb 28 13:45 vmlinuz.old -> vmlinuz-2.6.20.21-071108a
Click to expand...
das ist der Providerkernel der bis gestern gelaufen ist, wenn man den wieder aktiviert sollte die Kiste wieder hochkommen (wenn es wirklich ausschließlich am Kernelupdate liegt).

Code: 
cd /
chroot /mnt /usr/bin/env -i HOME=/root TERM=$TERM /bin/bash --login
cd boot
mv vmlinuz vmlinuz.gehtnicht # vorsichtshalber die von Yast erstellten Symlinks aufheben
mv initrd initrd.gehtnicht
ln -sf vmlinuz-2.6.20.21-071108a vmlinuz
Eine alte initrd ist nicht zu finden, scheinbar ist der Providerkernel statisch compiliert.

Die alte lilo.conf hat Dir Yast nicht aufgehoben (lilo.conf.yastsave oder so)?
Ansonsten:

Code: 
image = /boot/vmlinuz-2.6.20.21-071108a
###Don't change this comment - YaST2 identifier: Original name: linux###
label = Linux
append = " console=tty0 console=ttyS0,57600 panic=30"
# initrd = /boot/initrd-2.6.18.8-0.9-default
root = /dev/md1
(# bei initrd nicht übersehen)

Lilo neu aufspielen, danach das chroot verlassen:

Code: 
exit
Umounten und Bootversuch.

Laß mal raten: der Provider ist 1&1, dann ist Lilo und statischer Kernel richtig, außedem kannst Du Dir auch einfach den aktuellen Providerkernel von deren Updateserver holen und auspacken.

Sollte alles klappen:
/boot, /lib/modules und lilo.conf sichern, in Yast den Kernel deinstallieren, lilo.conf und den Symlink in /boot wiederherstellen, prüfen ob Yast sonst noch was bei der Deinstallation geändert hat und testweise rebooten. Dann killt Dir Yast den Kernel nie wieder.
 
Hallo,

ich habe mal auf meinem SuSE 10.3 zuhause in das boot-Verzeichnis gesehen. Die Ähnlichkeit dem dem Root-Server ist ja frappierend. Ob doch wohl Original der grub als bootload eingetragen war und der Kundenservice mir mist erzählt hat. Laut Kundenservice soll ja lilo der Bootloader sein der mir auch noch eine Anleitung per Mail geschickt hat, ie man lilo neu schreibt.

Hier mal das boot-Verzeichnis von SuSE 10.3 mit grub als Bootloader:
Code: 
mail:~ # ls -l /boot
total 9672
-rw-r--r-- 1 root root  843401 Feb 11 04:02 System.map-2.6.22.17-0.1-default
-rw------- 1 root root     512 Feb 27 18:34 backup_mbr
lrwxrwxrwx 1 root root       1 Feb 27 18:22 boot -> .
-rw-r--r-- 1 root root   80417 Feb 11 04:14 config-2.6.22.17-0.1-default
drwxr-xr-x 2 root root    4096 Feb 27 19:47 grub
lrwxrwxrwx 1 root root      28 Feb 27 19:47 initrd -> initrd-2.6.22.17-0.1-default
-rw-r--r-- 1 root root 4164970 Feb 27 19:47 initrd-2.6.22.17-0.1-default
-rw-r--r-- 1 root root  394752 Feb 27 18:34 message
-rw-r--r-- 1 root root  100315 Feb 11 04:15 symsets-2.6.22.17-0.1-default.tar.gz
-rw-r--r-- 1 root root  400576 Feb 11 04:16 symtypes-2.6.22.17-0.1-default.gz
-rw-r--r-- 1 root root  116297 Feb 11 04:15 symvers-2.6.22.17-0.1-default.gz
-rwxr-xr-x 1 root root 2147048 Feb 11 04:13 vmlinux-2.6.22.17-0.1-default.gz
lrwxrwxrwx 1 root root      29 Feb 27 19:47 vmlinuz -> vmlinuz-2.6.22.17-0.1-default
-rw-r--r-- 1 root root 1593936 Feb 11 04:02 vmlinuz-2.6.22.17-0.1-default

Frage: Wie kann man feststellen, welcher bootloader standardmäßig installiert wurde?
 
Last edited by a moderator:
Hallo,

da Yast die lilo.conf bearbeitet hat würde ich mich darauf verlassen, daß Lilo verwendet wird.

Code: 
dd if=/dev/hda count=4 of=test
danach test mit einem Editor öffnen, wenn irgendwo Lilo drinsteht ist Lilo installiert, wenn irgendwo grub drinsteht ist grub installiert. (Funktioniert nicht zuverlässig, wenn der Bootmanager gewechselt wurde.)
 
Hallo Charli,

auf Yast habe ich keinen Zugriff mehr. Ich habe gesterm, als ich md1, md5 und md8 gemountet hatte, Yast mal aufgerufen. Das war erschreckend, viele viele Textausgaben haben die Darstellung zerstört. Konnte Yast dann geradeso noch verlassen. Also wenn, dann alles zu Fuß, ohne Yast.

Übrigens, mit Deiner Vermutung zum Provider will ich Dir nicht widersprechen. Ich bin nur mit meinen Aktionen höllisch vorsichtig, weil ich gestern vor dem Update, noch ungefähr 55.000 Mails auf den Server gemoved habe; und die liegen jetzt auf eins der Filesysteme md6 oder md7.

Ansonstenn wäre die Sache einfach über die Initialisierung neu zu installieren.
 
Hallo,

Du sollst ja auch nicht auf Yast zugreifen. Als Yast das Kernelupdate durchgeführt hat wurde lilo.conf bearbeitet, also hat Yast erkannt, daß Lilo genutzt wird. Aber mach den Test mit dd.
 
Hallo Charli,

das kommt dabei raus:

rescue:/mnt/tmp# dd if=/dev/sda count=4 of=test
4+0 records in
4+0 records out
2048 bytes transferred in 0.007733 seconds (264835 bytes/sec)
rescue:/mnt/tmp# ls
test
rescue:/mnt/tmp# vi test
▒▒!^A▒^ALILO^V^G^

Ist also lilo.
 
Hier die fstab:
Code: 
rescue:~# cat /mnt/etc/fstab.md
/dev/md1        /               ext3    defaults                1 1
/dev/sda2       swap            swap    sw
/dev/sdb2       swap            swap    sw
/dev/md5        /usr            xfs     defaults                1 2
/dev/md6        /var            xfs     defaults,usrquota       1 2
/dev/md7        /home           xfs     defaults,usrquota       1 2
/dev/md8        /srv            xfs     defaults,usrquota       1 2

proc            /proc           proc    defaults                0 0
sysfs           /sys            sysfs   noauto                  0 0
none            /tmp            tmpfs   defaults                0 0

Ich habe den Server in der Zwischenzeit noch einmal versucht zu rebooten und das über die serielle Conole mitgeloggt. Folgende Zeilen dürften interessant sein:
Code: 
Creating device nodes with udev
Loading ide-core
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Loading ide-disk
SCSI subsystem initialized
Loading scsi_mod
Loading sd_mod
Loading processor
Loading thermal
Loading libata
Loading sata_sis
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
Loading sis5513
Loading fan
md: raid0 personality registered for level 0
Loading edd
md: raid1 personality registered for level 1
Loading raid0
Loading raid1
raid5: automatically using best checksumming function: generic_sse
Loading xor
   generic_sse:  6476.000 MB/sec
raid5: using function: generic_sse (6476.000 MB/sec)
Loading raid456
raid6: int64x1   1898 MB/s
raid6: int64x2   2404 MB/s
raid6: int64x4   2436 MB/s
raid6: int64x8   1689 MB/s
raid6: sse2x1    2833 MB/s
raid6: sse2x2    3871 MB/s
raid6: sse2x4    3961 MB/s
raid6: using algorithm sse2x4 (3961 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
md: linear personality registered for level -1

Loading jbd
Loading mbcache
md: md1 stopped.
Loading ext3
mdadm: no devices found for /dev/md1
Waiting for device /dev/root to appear:  ok
/dev/root: unknown volume type
invalid root filesystem -- exiting to /bin/sh
sh: no job control in this shell

Wenn natürlich /dev/md1 nicht gefunden wird und /dev/root unbekannt ist, dann kann's ja wohl auch nicht gehen, oder?
Code: 
rescue:~# ls /mnt/dev/ro*
/mnt/dev/route
rescue:~# ls /mnt/dev/root*
ls: /mnt/dev/root*: No such file or directory
rescue:~#
rescue:~# ls -l /mnt/dev/md*
brw-r-----  1 root disk 9,  0 Nov 25  2006 /mnt/dev/md0
brw-r-----  1 root disk 9,  1 Nov 25  2006 /mnt/dev/md1
brw-r-----  1 root disk 9, 10 Nov 25  2006 /mnt/dev/md10
brw-r-----  1 root disk 9, 11 Nov 25  2006 /mnt/dev/md11
brw-r-----  1 root disk 9, 12 Nov 25  2006 /mnt/dev/md12
brw-r-----  1 root disk 9, 13 Nov 25  2006 /mnt/dev/md13
brw-r-----  1 root disk 9, 14 Nov 25  2006 /mnt/dev/md14
brw-r-----  1 root disk 9, 15 Nov 25  2006 /mnt/dev/md15
brw-r-----  1 root disk 9, 16 Nov 25  2006 /mnt/dev/md16
brw-r-----  1 root disk 9, 17 Nov 25  2006 /mnt/dev/md17
brw-r-----  1 root disk 9, 18 Nov 25  2006 /mnt/dev/md18
brw-r-----  1 root disk 9, 19 Nov 25  2006 /mnt/dev/md19
brw-r-----  1 root disk 9,  2 Nov 25  2006 /mnt/dev/md2
brw-r-----  1 root disk 9, 20 Nov 25  2006 /mnt/dev/md20
brw-r-----  1 root disk 9, 21 Nov 25  2006 /mnt/dev/md21
brw-r-----  1 root disk 9, 22 Nov 25  2006 /mnt/dev/md22
brw-r-----  1 root disk 9, 23 Nov 25  2006 /mnt/dev/md23
brw-r-----  1 root disk 9, 24 Nov 25  2006 /mnt/dev/md24
brw-r-----  1 root disk 9, 25 Nov 25  2006 /mnt/dev/md25
brw-r-----  1 root disk 9, 26 Nov 25  2006 /mnt/dev/md26
brw-r-----  1 root disk 9, 27 Nov 25  2006 /mnt/dev/md27
brw-r-----  1 root disk 9, 28 Nov 25  2006 /mnt/dev/md28
brw-r-----  1 root disk 9, 29 Nov 25  2006 /mnt/dev/md29
brw-r-----  1 root disk 9,  3 Nov 25  2006 /mnt/dev/md3
brw-r-----  1 root disk 9, 30 Nov 25  2006 /mnt/dev/md30
brw-r-----  1 root disk 9, 31 Nov 25  2006 /mnt/dev/md31
brw-r-----  1 root disk 9,  4 Nov 25  2006 /mnt/dev/md4
brw-r-----  1 root disk 9,  5 Nov 25  2006 /mnt/dev/md5
brw-r-----  1 root disk 9,  6 Nov 25  2006 /mnt/dev/md6
brw-r-----  1 root disk 9,  7 Nov 25  2006 /mnt/dev/md7
brw-r-----  1 root disk 9,  8 Nov 25  2006 /mnt/dev/md8
brw-r-----  1 root disk 9,  9 Nov 25  2006 /mnt/dev/md9
 
Last edited by a moderator:
Hallo,

ok, dann würde ich versuchen im Rescue an die Daten zu kommen (und die Kiste danach neu aufsetzen). Da muß Dir aber jemand anderes helfen.
 
Hi!

Gib mal bitte den Befehl mdadm -D /dev/md1 (für details der Festplatte/RAIDs) ein und poste mal bitte die Ausgabe.

MFG
Freefall100
 
Last edited by a moderator:
Das ist md1:
Code: 
rescue:~# mdadm -D /dev/md1
/dev/md1:
        Version : 00.90.03
  Creation Time : Thu Feb 28 13:39:36 2008
     Raid Level : raid1
     Array Size : 987840 (964.69 MiB 1011.55 MB)
    Device Size : 987840 (964.69 MiB 1011.55 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Tue Mar 11 18:57:13 2008
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 457b043b:56b2feee:46883a20:be179eac
         Events : 0.444

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

Da auch die Superblöcke von md6 und md7 nach dieser Überprüfung in Ordnung sind, kristallisiert sich doch meines Erachtens lilo als der Übeltäter heraus.
 
Last edited by a moderator:
... oder der SuSE-Kernel kommt zur Boot-Zeit nicht mit dem RAID zurecht. Hast Du schon wie Charli empfohlen hat, den vorherigen 1&1-Kernel wieder aktiviert?
 
You must log in or register to reply here.
Back
Top