1 & 1 Rootserver startet nach Reboot nichtmehr

fun4teen

Registered User
Hi all,
ich habe seit gestern einen 1&1 Rootserver mit Suse 10 64bit und Plesk. Mein alter Server lief immer ohne probleme- der war auch bei 1 und 1.

Nun habe ich gestern erstmal bisschen in plesk rumgespielt, da ich bis jetzt immer confixx hatte...in der späten nacht hab ich dann (einfach so) einen reboot durchgeführt via Konsole. Seitdem lässt der Server sich nichtmehr erreichen.. weder wie serielle Konsole noch via telnet. Wenn ich ihn im Rescuesystem neu starte kann ich ihn erreichen.

Hat mir jemand eine Idee? Der von der Hotline wollte/ konnte mir auch nicht weiterhelfen. Hat nur gemeint ich sollte mal den lilo kontrollieren...

Merci
 
Im Rescue Mode, falls noch erforderlich, die Platte mounten und dann in {mountpoint}/var/log/ wechseln und die Logs anschauen und hier posten. :)

Lilo Config findest du unter {mountpoint}/etc/lilo.conf
 
So, also ich habe nun den server neu initialisiert, da dort eh noch kaum was drauf war.

Dann über Yast in den bootloader reingeschaut. Auf Lilo umgestellt .. und die bootfestplatte war auf hda1 eingestellt. Das muss aber sda1 sein da der server via raid1 abgesichert wird. Nun funktioniert alles.

Trotzdem danke!
 
Hey,
ich hab jetzt nen Maraton hinter mir mit diesem lilo. Für alle die das nicht durch machen wollen:
(Ist alles für nen 1&1 Server mit SuSe 10.1 / Pesk 8.1 Template geschreiben)

1. Server im Rescue booten.

2. Festlatte Mounten
Code:
mount  /dev/md1 /mnt
mount  /dev/md5 /mnt/usr
mount  /dev/md6 /mnt/var
mount  /dev/md7 /mnt/home

3tens
Code:
chroot /mnt

4tens
Code:
lilo
(Müssten 3 Zeilen bei rauskommen nix bessonderes. Schreibt einfach den Lilo neu wenn ich mich nicht irre. Kann in /etc/lilo.conf beeinflusst werden.)

5tens
Code:
exit
umount /mnt/home
umount /mnt/var
umount /mnt/usr
umount /mnt

6tens im 1&1 Inteface Rescuesystem auf Normal Booten umstellen (ohne Sofortrestart)

7tens
Code:
shutdown -rn now

Nun in die Serielle Konsole schauen ob der Bildschirm Schwarz bleibt, dann nochmal den lilo betrachten. Wenn sich irgend was bootet vom Normalen System kanns schon mal nicht mehr der lilo sein.

Mfg
Daniel

Ps: Warum das ganze? Beim rebooten kanns vorkommen das der Server die Festplatte "neu" entedeckt. Und dann was umstrukturiert und somit der lilo nicht mehr an dem Platz ist wo er zuvor war. Kann öffter vorkommen laut 1&1 Supprt.
 
Last edited by a moderator:
Danke, du hast mir das Leben, bzw. meine Nerven gerettet. Hat einwandfrei funktioniert!
Ich werde in Zukunft vor jedem Reboot (wenn es noch möglich ist) den Lilo neu schreiben lassen.
 
Last edited by a moderator:
Auch mein Dank für den super Beitrag! Mein Server ist gerade wieder auferstanden.

Es ist schon traurig für 1&1, daß man diesen Hinweis vom Support nicht bekommt! Die Symptome sind ja wohl eindeutig und ein Ausnahmefall ist es offensichtlich auch nicht.
 
Es ist schon traurig für 1&1, daß man diesen Hinweis vom Support nicht bekommt!

Kommt immer drauf an wer Support macht. Mich hat der Servicemitarbeiter am Tel darauf hingewiesen wenn nichts zu sehen ist in der Remote dann ist es vermutlich der Lilo. Hätte mir auch erklärt wies geht mit dem Lilo.

Musst immer nachts so ab 23 Uhr anrufen da bekommste den besten Support. Ist zumindest meine Erfahrung.

Gruß
Daniel
 
Hallo,
habe zur Zeit genau das gleiche Problem mit meinem neuen S64
Alle Updates etc.eingespielt.

Komme im rescue nicht weiter:

Code:
mount  /dev/md1 /mnt   ist ok
Code:
mount  /dev/md5 /mnt/usr   ab hier geht nix mehr
fdisk -l gibt dies hier aus:
Code:
rescue:~# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 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        9729    75200265    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        9729    45873576   fd  Linux raid autodetect

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 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        9729    75200265    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        9729    45873576   fd  Linux raid autodetect

Disk /dev/md8: 46.9 GB, 46974435328 bytes
2 heads, 4 sectors/track, 11468368 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
rescue:~#
Neu installieren etc. hilft auch nicht, spätestens der zweite reboot funzt nicht.

Könnt Ihr mir da mal helfen?

Danke

P.S. vor kurzem wurde bereits eine defekte Festplatte ausgetauscht

P.P.S.
mount /dev/md6 /mnt/var gibt folgendes aus:

Code:
rescue:~# mount  /dev/md6 /mnt/var
Segmentation fault

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: Oops: 0000 [#2]

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: SMP 

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: CPU:    0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: EIP is at page_address+0x16/0xc0
rescue:~# 
Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: eax: 00000000   ebx: 00000000   ecx: 00000000   edx: 00000000

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: esi: 00000000   edi: 00800946   ebp: edca4440   esp: edd4f99c

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: ds: 007b   es: 007b   ss: 0068

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: Process mount (pid: 1841, threadinfo=edd4e000 task=dbebca50)

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: Stack: <0>00000010 00000000 00800946 edca4440 c0339c26 00000000 dbda6fe0 c031f453 

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:        edd2b8fc 00000010 002556a0 00000000 00004000 4d5c1500 003d0ac7 00000000 

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:        edd4e000 dbdfc000 00000000 c0475886 c0444940 edca4ac0 dbca1980 00000000 

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: Call Trace:

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0339c26>] xfs_buf_offset+0x46/0x50

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c031f453>] xlog_recover_commit_trans+0xa63/0x1700

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0475886>] ata_scsi_queuecmd+0x76/0x180

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0444940>] scsi_done+0x0/0x30

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0337101>] kmem_alloc+0xc1/0x110

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c03202e1>] xlog_recover_process_data+0x1f1/0x480

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c033b79a>] .text.lock.xfs_buf+0x23/0x59

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c03211e4>] xlog_do_recovery_pass+0x304/0xa20

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c012fb79>] run_timer_softirq+0x39/0x1a0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c012b5c2>] __do_softirq+0x72/0xe0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0103abc>] apic_timer_interrupt+0x1c/0x24

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0323369>] xlog_recover+0x169/0x2b0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c031d8db>] xfs_log_mount+0x47b/0x5c0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0325538>] xfs_mountfs+0xc68/0x1250

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c05441c7>] __down_failed+0x7/0xc

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c033a03c>] xfs_buf_rele+0x2c/0xc0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0339888>] xfs_setsize_buftarg_flags+0x38/0xc0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0337101>] kmem_alloc+0xc1/0x110

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c032e203>] xfs_mount+0x983/0xa80

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c014c4f1>] truncate_inode_pages+0x31/0x40

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c016c1d1>] set_blocksize+0x91/0xa0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0341638>] linvfs_fill_super+0x98/0x240

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c03692eb>] snprintf+0x2b/0x30

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c01a16d5>] disk_name+0xc5/0xd0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c016c1ff>] sb_set_blocksize+0x1f/0x60

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c016ba1c>] get_sb_bdev+0x11c/0x160

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0180997>] alloc_vfsmnt+0xb7/0xf0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0341040>] linvfs_get_sb+0x30/0x40

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c03415a0>] linvfs_fill_super+0x0/0x240

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c016b332>] do_kern_mount+0x52/0xd0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0181c40>] do_mount+0x2b0/0x750

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c016cdb2>] bdev_destroy_inode+0x22/0x30

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0174b36>] do_path_lookup+0xb6/0x270

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0148d43>] __alloc_pages+0x53/0x2f0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c011a830>] do_page_fault+0x0/0x71b

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c014900d>] __get_free_pages+0x2d/0x50

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0180c87>] copy_mount_options+0x47/0x130

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c018217d>] sys_mount+0x9d/0xe0

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel:  [<c0102fe9>] syscall_call+0x7/0xb

Message from syslogd@rescue at Tue Sep 18 07:48:41 2007 ...
rescue kernel: Code: 02 11 11 57 c0 e9 dd fe ff ff 8d 74 26 00 8d bc 27 00 00 00 00 83 ec 10 89 1c 24 8b 5c 24 14 89 74 24 04 89 7c 24 08 89 6c 24 0c <8b> 03 c1 e8 1e 8b 14 85 60 86 65 c0 8b 82 0c 02 00 00 05 c0 06 

rescue:~#
 
Last edited by a moderator:
Re

Hallo Jungs und danke NeoXx!
Bei mir hat es auch so geklappt wie es oben beschrieben, nur bei mir stand
Code:
/dev/sda
und ich habe es in
Code:
/dev/sda1
danach im ser. konsole
Code:
exit
stat
Code:
shutdown -rn now
und im 1&1-CC Reboot sofort ausführen auf ja und Normales System!
nur seltsamerweise im 1&1-CC steht Boot-Modus Rescue-System
Status Bereit.
Was solls der rennt im mom.

Nochmal Danke NeoXx!
 
1und1, oder wie man rootserver kunden zu managed server kunden macht

So. Jetzt hats mich auch erwischt.

Also, dass nach einem Kernel update bei Verwendung von LILO dieselbe neu geschrieben werden sollte, das sollte allgemein bekannt sein.

kann man zb. standardmässig so machen:

you @lilo

Das heisst es wird zuerst das yast online update ausgeführt, und nach beendigung desselben wird lilo ausgeführt.

ABER: Dass in dem 1und1 Dingens LILO drin ist, statt dem GRUB das find ich schon nen richtigen Hammer!
Wieso?

1. GRUB ist neuer
2. Das Problem mit Kernel und OS updates bei LILO ist immanent und weit verbreitet und liegt daran, dass die Informationen über Kernel etc. im MBR abgespeichert werden. Ein Neuschreiben von LILO nach dem Updaten und vor dem Rebooten des Systems vergisst auch schon mal ein echter Linux Crack!
3. Suse kommt standardmäßig mit GRUB daher
4. LILO ist ALT, URALT, GRUB ist neu.
5. GRUB ist ordentlich dokumentiert (eigene Webseite, FAQ etc..)
6. GRUB hat eine wesentlich ausgereiftere commandline

und und und.

Jedenfalls danke für den Hinweis, dass bei 1und1 LILO drin ist, ich hatte nicht genau geschaut, und somit eben die LILO nicht neu geschrieben nach dem Update.

Weiters: man muss nicht vor jedem neustart lilo neu schreiben. andererseits wäre es ja möglich ein alias auf reboot anzulegen:
lilo;reboot

Andererseits: wenn dann nicht mit dem alias neu gebootet wird bringts nix.
daher: vielleicht einfach per cronjob alle stunden aufrufen. macht ja nix, geht schnell und für ungeübte user vielleicht keine blöde idee.

@1und1 Support: dass bei den kosten für die rootserver kein support drin ist (oder eben nur der den sie bieten, also sowas wie telefonische FAQ 0815 standard antworten) ist leider eine unangenehme wahrheit! ;)
 
@1und1 Support: dass bei den kosten für die rootserver kein support drin ist (oder eben nur der den sie bieten, also sowas wie telefonische FAQ 0815 standard antworten)...
Darauf wird ausdrücklich hingewiesen. Jeder Support über die Hardwareebene / Anbindung hinaus, ist schon mehr als Dir (bzw. uns Rootserver-Kunden) zusteht.

Suchst Du Support der über das bekannte Maß hinaus geht, empfehle ich Dir Premium Anbieter, wie z.B. Plusserver, HostEurope und Konsorten.

--marneus
 
1. GRUB ist neuer
Toller Grund. Windows XP oder Vista ist auch neuer als der Linux Kernel...

2. Das Problem mit Kernel und OS updates bei LILO ist immanent und weit verbreitet und liegt daran, dass die Informationen über Kernel etc. im MBR abgespeichert werden. Ein Neuschreiben von LILO nach dem Updaten und vor dem Rebooten des Systems vergisst auch schon mal ein echter Linux Crack!
Also du vergisst es ab und zu.

4. LILO ist ALT, URALT, GRUB ist neu.
LILO wird weiterentwickelt, GRUB Legacy nicht mehr. GRUB 2 ist noch nicht produktiv einsetzbar.

5. GRUB ist ordentlich dokumentiert (eigene Webseite, FAQ etc..)
Was fehlt dir in der Dokumentation von LILO?

Zusammengefasst: Wenn es dich stört, installier eben GRUB. Es ist ja dein Server. Ansonsten bitte nicht rumheulen.
 
Also du vergisst es ab und zu.

Danke dass du mich als linux-crack bezeichnest. Da wär ich jetzt nicht so weit gegangen und eigentlich hab ich nicht mich gemeint, weil ich normalerweise eben grub einsetze, da der eh schon std. daherkommt bei opensuse. ;)

LILO wird weiterentwickelt, GRUB Legacy nicht mehr. GRUB 2 ist noch nicht produktiv einsetzbar.
Ich wage mal die Behauptung, dass grub legacy für 95% der leute die einen 1und1 server betreiben völlig ausreicht. ;)

Zusammengefasst: Wenn es dich stört, installier eben GRUB. Es ist ja dein Server. Ansonsten bitte nicht rumheulen.

Mich stört an LILO überhaupt nix. ich finde es nur seltsam, dass die sonst recht standardmässig daher kommenden 1und1 images ausgerechnet am bootloader was drehen.
Und dass das auch nirgends steht im CC.
Schliesslich ist das nicht irgendein dämliches paketerl sondern eben der bootloader, ohne den halt mal garnix geht.
 
4tens
Code:
lilo
(Müssten 3 Zeilen bei rauskommen nix bessonderes. Schreibt einfach den Lilo neu wenn ich mich nicht irre. Kann in /etc/lilo.conf beeinflusst werden.)

Vielen Dank, NeoXx! Das war der entscheidende Hinweis auf den ich selber nie gekommen wäre; Respekt!

Beim rebooten kanns vorkommen das der Server die Festplatte "neu" entedeckt

ja, sehr schöne Beschreibung für so ein fäkales Problem ... das Gute an der Remote Shell ist, dass man die Kiste nicht aus dem Fenster werfen kann.
 
Back
Top