Problem mit 1und1 Rootserver nach Yast update

[Rudi96]

Hallo ihr lieben,

ich weiss nicht ob ich hier richtig bin. Wir sind eine kleine Tuningfirma und haben ein riesen Problem. Unser Ansprechpartner (Serveradmin) befindet sich im Urlaub und ist nicht erreichbar, also versuche ich gerade dieses Problem zu lösen.

Es handelt sich um einen Root Server von 1&1 (Suse10.1)) der nach einem Yast online update nicht mehr bootet. Nach Rücksprache mit 1und1 wurde ein anderer Kernel inst. und deswegen bootet er nicht mehr. Wir sollen das Ding im Rescue Modus starten --> kein Problem.........
und jetzt gehts los:

die Partitionen mounten und "auf den alten Kernel" verlinken da dieser vorhanden ist( vmlinuz ?)
dann sollte es wieder gehen. Kann mit jemand verraten was ich im Rescue Modus eingeben muss ? Der 1und1 Supporter meine das wäre eine Sache von 2 Min. Die selber dürfen das leider nicht.

Bin für jede hilfe dankbar.

Viele Grüsse... jemand der keine Ahnung von Linux hat und sich trotzdem kümmern muss

[Janka]

Eigentlich sollte das System ja mit dem neuen Kernel booten. Wenn nicht, liegt es meistens daran, dass vor dem Booten keine neue Initrd erstellt wurde und/oder vergessen wurde, LILO aufzurufen (wenn man denn lilo verwendet). Ich vermute, euer Server verwendet bereits GRUB als Bootlader, daher kommt die zweite Fehlermöglichkeit nicht in Betracht.

Abhilfe:

1. Rettungssystem booten
2. /-Dateisystem des Produktivsystems mounten.
2a. Evtl. /boot-Dateisystem ebenfalls in das gemountete /-Dateisystem einmounten, wenn notwendig
3. chroot in dieses Dateisystem
4. mkinitrd
5. exit
6. umount
7. reboot

Wenn du genauere Anweisungen willst, bootest du mal das Rettungssystem und postest die Ausgabe von

Code: Select all

# mount
# fdisk -l /dev/hd? /dev/sd?

Janka

[Rudi96]

Hallo und einen guten Abend
vielen Dank das sich jemand der Sache annimmt. Wir stehen echt unter Druck

rescue:~# mount
/dev/ram0 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)

rescue:~# fdisk -l /dev/hd? /dev/sd?

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
rescue:~#

[Janka]

Mhm. Ich vermute mal keck, das root-Laufwerk liegt auf einem Software-Raid1, die Node sollte /dev/md0 sein. Ein /boot-Dateisystem scheint es nicht zu geben, dafür sind eure Partitionen einfach zu groß. Aber wofür die ganzen anderen Partitionen da sind, müssten wir sicherheitshalber noch ergründen. Bitte die Ausgabe von

Code: Select all

# mount /dev/md0 /mnt
# ls -al /mnt
# cat /mnt/etc/fstab
# umount /mnt

posten.

Janka