Strato: Kernel Update über Yast (geht das gut?)

[ruthserver]

Hi,

habe Suse10 mit einem Strato-Kernel auf meinem neuen Root-Server laufen. Nun wird mir heute über Yast ein Kernelupdate "empfohlen". Laut der Strato-FAQ wird bei einem nicht-strato-Kernel die Netzwerkkarte evtl. nicht als Modul eingebunden und dann wäre erstmal Handarbeit angesagt / tote Hose.

Meine Frage: hat jemand schonmal Erfahrung mit dieser Sitution gesammelt? Ist es GENERELL zum Scheitern verurteilt, ein normales Kernelupdate über Yast zu fahren?

thx und gruß

[blnsnoopy26]

Was spricht gegen selber bauen ausser faulheit vielleicht??

- Sourcen laden
- vorhanden config einlesen lassen und kompilieren
- einbinden und rebooten.

[daemotron]

Und vorher herausfinden, welche Module mit dem Strato-Kernel installiert und geladen sind...

Allerdings geht's beim Strato-Kernel nicht nur um einzelne Module; Strato patcht meines Wissens nach auch an den Sourcen rum. Normalerweise stellen die auf ihren Update-Servern aktuelle Kernel-Versionen bereit - sogar komplett mit einem Installationsskript, das das herunterladen und installieren automatisch erledigt.

[ruthserver]

wie man es anders machen kann, darum geht es mir nicht bei meiner Frage!
Evtl. haben ja Strato-User bereits Erfahrung damit gesammelt. Der Strato-Support weiß jedenfalls nichts von "extra bereitgestellten Kernelversionen" auf den internen Servern und empfiehlt mir dringend ein Komplettbackup meines Systems.
Sobald ich das Update gewagt habe, schreib ich das Ergebnis dann hier rein; evlt. von Interesse.

gruß

[os-t]

Hi,

also vor einigen Monaten hatte Strato mal definitiv ein Kernelupdate zur Verfügung gestellt. Das hatte ich damals noch installiert und dann den Server gekündigt

Gruß Markus

[Joe User]

also vor einigen Monaten hatte Strato mal definitiv ein Kernelupdate zur Verfügung gestellt.

Der letzten Strato-Kernel den ich auf dem Strato-Updateserver finden konnte, datiert auf den 15.02.2005 und ist ein 2.4.29...

[wgot]

Hallo,

Laut der Strato-FAQ wird bei einem nicht-strato-Kernel die Netzwerkkarte evtl. nicht als Modul eingebunden und dann wäre erstmal Handarbeit angesagt / tote Hose.

dann darfst Du das Rescue-System bemühen und auf den alten Kernel zurückstellen. Dauert ein paar Minuten, vorausgesetzt, /boot wurde vorsichtshalber gesichert.

Meine Frage: hat jemand schonmal Erfahrung mit dieser Sitution gesammelt?

Da ich nicht das Modell "dein neuer Rootserver" sondern das Modell "mein gut geplegter Rootserver" habe dürfte Dir meine Erfahrung nichts nützen. Es kommt auf die Hardware des Servers an ob er mit dem Standardkernel grundsätzlich läuft oder nicht.

Ist es GENERELL zum Scheitern verurteilt, ein normales Kernelupdate über Yast zu fahren?

Generell verurteilt nicht, es gibt Server die mit dem Standardkernel laufen. Allerdings ist es generell nicht empfehlenswert weil der Suse-Standardkernel für Desktopanwendungen optimiert ist.

Bei meinem Strato-Server war die Kernelkonfiguration (mindestens nahezu) mit dem Standardkernel identisch, viel zu viel Schrott drin den man auf einem Server nicht braucht. Konfiguration auslesen hätte also nichts genützt, ich mußte selbst eine sinnvolle erarbeiten.

Gruß, Wolfgang

[elvis]

Servus,

ich habe (wohl aus Faulheit) den aktuellen SuSe 10.0 Kernel-Patch über YaST installiert.

Fazit : Kiste bootet nicht.

Da ich noch nie einen Patch deinstallieren musste, nun meine Frage wie setze ich da am besten an?

Für eine Hilfestellung wäre ich sehr dankbar oder aber auch eine Quelle wo ich das nachlesen kann. Habe über Google nichts gefunden.

Gruß,
Elvis

PS: Aktueller Kernel 2.6.13.15

[Joe User]

Wie schon vor vier Jahren hier gepostet: SUSE-Kernel per Rescuesystem vollständig deinstallieren und den Bootloader auf den "alten" Providerkernel setzen, rebooten, fertig.

[elvis]

Das Problem ist, dass kein Provider-Kernel auf dem System ist.

Grub hat 2 Einträge, einmal den ver-patchten Kernel und als alternative einen "gleichnamigen" Kernel, also wieder der selbe.

Auf der Kiste selber finde ich den Providerkernel nicht.

- Einen neuen Kernel zu erstellen (im chroot), wo ich über YaST versucht habe den Standart-Kernel einzuspielen, kann ich knicken. Make, etc. gibts da nicht im Rescue-mod.

Gibts evtl. bei Suse auf einem Update o.Ä. die Möglichkeit den Provider-Kernel zu laden? Habe leider nichts gefunden.

Elvis

[ruthserver]

Hi Elvis,

hast Du es mal über die RemoteConsole versucht?
Welchen Strato-Server hast Du? Ich habe den MR3 und werde morgen in 2 Tagen das Update wagen. Yast zeigt mir einen Suse-Standardkernel an.

Gruß

[wgot]

Hallo,

Das Problem ist, dass kein Provider-Kernel auf dem System ist.

sollte in /boot liegen, zeig mal den Inhalt von /boot

- Einen neuen Kernel zu erstellen (im chroot), wo ich über YaST versucht habe den Standart-Kernel einzuspielen, kann ich knicken. Make, etc. gibts da nicht im Rescue-mod.

Du kannst im Rescue nach korrektem chroot arbeiten wie im Normalsystem.

Gibts evtl. bei Suse auf einem Update o.Ä. die Möglichkeit den Provider-Kernel zu laden?

Den Providerkernel wirst Du nicht bei Suse finden. :roll: Schau mal auf dem Updateserver des Providers, aber AFAIK sieht's da bei diesem Provider schlecht aus.

Welche Hardware hat der Server? CPU? RAID?

Gruß, Wolfgang

[elvis]

Hallo Wolfgang,

Inhalt /boot :

Code: Select all

drwxr-xr-x   3 root root    4096 Jun 18 02:57 .
drwxr-xr-x  22 root root    4096 Jun 18 03:07 ..
-rw-r--r--   1 root root  756397 Sep 13  2005 System.map-2.6.13-15-default
-rw-------   1 root root     512 Feb 22 10:01 backup_mbr
lrwxrwxrwx   1 root root       1 May 11 19:00 boot -> .
-rw-r--r--   1 root root   63888 Sep 13  2005 config-2.6.13-15-default
drwxr-xr-x   2 root root    4096 Jun 18 15:30 grub
lrwxrwxrwx   1 root root      24 Jun 18 01:26 initrd -> initrd-2.6.13-15-default
-rw-r--r--   1 root root 1410262 Jun 18 01:26 initrd-2.6.13-15-default
-rw-r--r--   1 root root   73508 Sep 13  2005 symvers-2.6.13-15-i386-default.gz
lrwxrwxrwx   1 root root      25 Jun 18 01:58 vmlinuz -> vmlinuz-2.6.13-15-default
-rw-r--r--   1 root root 1541719 Sep 13  2005 vmlinuz-2.6.13-15-default
-rw-r--r--   1 root root 1838899 Sep 13  2005 vmlinuz-2.6.13-15-default.gz



GRUB menu.lst :

# Modified by YaST2. Last modification on Mi Feb 22 10:01:14 UTC 2006

color white/blue black/light-gray
timeout  5

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE LINUX 10.0
    root (hd0,1)
    kernel /boot/vmlinuz root=/dev/hda2
    initrd /boot/initrd

Du kannst im Rescue nach korrektem chroot arbeiten wie im Normalsystem.

Ich habe es folgendermaßen gemacht :

Code: Select all

1.) RESCUE:/mount /dev/hda2 /mnt
2.) RESCUE:/mount -t proc proc /mnt/proc
3.) RESCUE:/chroot /mnt

Dann bin ich nur noch im Chroot. Wenn ich aber dann den make Befehl anwenden will, wird der Befehl nicht erkannt.

Welche Hardware hat der Server? CPU? RAID?

Code: Select all

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) XP 2400+
stepping        : 0
cpu MHz         : 1998.754
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
bogomips        : 4006.08

           CPU0
  0:     151849          XT-PIC  timer
  1:         16          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  8:          2          XT-PIC  rtc
 11:      21688          XT-PIC  eth0
 14:        252          XT-PIC  ide0
NMI:          0
LOC:     151821
ERR:         36
MIS:          0

- Kein Raid

Festplatte :
Disk /dev/hda: 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/hda1               1          63      506016   82  Linux swap / Solaris
/dev/hda2              64        9729    77642145   83  Linux

Gruß,
Elvis

[elvis]

Okay, ich denke ich hab jetzt.

Aus irgendeinem Grund war der Bootloader zerschossen, das File war fratze.

Den letzten Bootloader nochmal eingespielt, reboot - läuft.

Aber nun noch eine Frage. Sitze jetzt an dem neuen 2.6.17er dran und benutze meine alte Konfig. Bekomme beim kompilieren immer folgendes angezeigt :

Code: Select all

.. .. "may be used uninitialized in this function"

Sollte ich die alte Konfig. lieber clonen?

Code: Select all

make cloneconfig && make prepare-all

<-- :?:

Gruß,
Elvis

[wgot]

Hallo,

erstmal Glückwunsch daß die Kiste wieder rennt.

Inhalt /boot :

da ist tatsächlich kein alter Kernel drin.

Wenn die Kiste wieder bootet pack Dir /boot samt /boot/grub in ein tar, dann hast Du einen Notkernel für die nächste Panne.

Dann bin ich nur noch im Chroot. Wenn ich aber dann den make Befehl anwenden will, wird der Befehl nicht erkannt.

Code: Select all

mkdir /mnt/hdd 
mount /dev/hda2 /mnt/hdd 
chroot /mnt/hdd /usr/bin/env -i HOME=/root TERM=$TERM /bin/bash --login 
cd /boot 
# beenden mit
exit
umount /dev/hda2

dann sollte alles gehen.

model name : AMD Athlon(tm) XP 2400+
Disk /dev/hda: 80.0 GB, 80026361856 bytes

Auf dieser Hardware läuft der Suse-Standardkernel.

Sitze jetzt an dem neuen 2.6.17er dran und benutze meine alte Konfig.

Was meinst Du mit alter Konfig - eine eigene oder die vom Provider-Originalkernel, letztere ist leider nicht optimiert.

Gruß, Wolfgang

[elvis]

Hallo,

vielen Dank für die Tips!

Was meinst Du mit alter Konfig - eine eigene oder die vom Provider-Originalkernel, letztere ist leider nicht optimiert.

Ja, ich habe die alte Konfig von dem Provider-Kernel genommen.

Hmm,... ich stelle mir das schwierig vor den neuen Kernel von Hand zu konfigurieren wenn ich die Hardware nicht vor mir habe.

Kann ich die alte Konfig vom Provider-kernel denn noch irgendwie benutzen oder welche Alternative habe ich da?

Gruß,
Elvis

[wgot]

Hallo,

Hmm,... ich stelle mir das schwierig vor den neuen Kernel von Hand zu konfigurieren wenn ich die Hardware nicht vor mir habe.

von null an selbst konfigurieren ist ziemlich Arbeit und man braucht eifrig das Rettungssystem. Leichter ist es eine Config zu nehmen mit der der Server grundsätzlich läuft und auf dieser aufzubauen.

Kann ich die alte Konfig vom Provider-kernel denn noch irgendwie benutzen oder welche Alternative habe ich da?

wenn der Server damit bootet und erreichbar ist kannst Du sie nehmen und wenn Du Lust hast später schrittweise optimieren.

2.6.17 hat ein paar neue Features, da wirst Du bei make oldconfig gefragt ob die eincompiliert werden sollen.

Du kannst meine probieren http://www.wgot.de/config-strato-2.6.17-athlon-nonraid sollte Modell aus der gleichen Reihe sein, wenn er damit nicht erreichbar ist, dann hast Du eine Netzwerkkarte die bei mir nicht eincompiliert ist.

Der Kernel läuft ohne initrd, die Zeile

Code: Select all

initrd /boot/initrd 

in /boot/grub/menu.lst muß bei meiner Config gelöscht werden.

Die Config läuft garantiert nicht auf den RAID-Modellen.

Gruß, Wolfgang

[ruthserver]

kleine Zwischeninfo: ich hab eben das Yast-Kernel-Update auf meinem Strato MR3 erfolgreich gefahren + rebootet

happy grüße .)

[elvis]

Hallo Wolfgang,

bin zwar nicht bei Strator oder 1&1, aber von der Hardware sollte es klappen.

Bis jetzt läuft die Kompilierung sauber durch, bis auf einige Einträge die die sagen das die Funktion uninitaialisiert sein wird.

Denke das das kein Problem darstellt, oder?

Ich denke ich werden den Kernel heute Abend einbinden und mich dann melden wie es gelaufen ist.

Gruß,
Elvis

PS: Heißt das, daß bei Dir der Bootloader schon im Kernel ist? Das verstehe ich nicht so ganz.

[elvis]

@ruthserver

Hi Elvis,

hast Du es mal über die RemoteConsole versucht?
Welchen Strato-Server hast Du? Ich habe den MR3 und werde morgen in 2 Tagen das Update wagen. Yast zeigt mir einen Suse-Standardkernel an.

Habe keinen Strato oder 1&1 - Bin bei Fast IT.

Gruß,
Elvis

[wgot]

Hallo,

bin zwar nicht bei Strator oder 1&1, aber von der Hardware sollte es klappen.

oh sorry, der Threadersteller schrieb von Strato.

Hauptrisiko ist die Netzwerkkarte, suche (mit beliebigem funktionierendem Kernel gebootet) in /var/log/boot.msg nach eth0, da steht welche Netzwerkkarte Du hast.

bis auf einige Einträge die die sagen das die Funktion uninitaialisiert sein wird.

Das sind Programmierfehler im Kernel bzw den Modulen, gibt's bei jeder Version. Solange es nur Warnungen sind und der Compiler durchläuft ignorieren.

PS: Heißt das, daß bei Dir der Bootloader schon im Kernel ist? Das verstehe ich nicht so ganz.

nein.

Die Config ist so erstellt daß keine RAMdisk benötigt wird.

Die RAMdisk wird benötigt wenn man Komponenten die für den Zugriff auf das Dateisystem erforderlich sind als Module einbindet, weil er dann ohne das Modul das Modul nicht laden kann. Ausweg ist eine im RAM simulierte Platte mit den Modulen drin dann kann der Kernel die Module beim Booten aus der RAMdisk holen. Geladen wird die RAMdisk aus initrd, da stehen die Module einfach (in speziellem Format) nochmal drin.

Vorteil: wenn man einen Kernel so erstellt daß er auf vielen Systemen läuft (z.B. der Suse-Standardkernel) hat man die Komponenten für die nicht vorhandene Hardware nur auf der Platte aber nicht dauerhaft im Arbeitsspeicher.

Wenn man den Kernel auf bestimmte Systeme optimiert braucht man das nicht, deswegen ist in meiner Config z.B. kein RAID drin.

Da ich Deinen Provider nicht kenne: ich hoffe, der hat ein Rescue-System für den Notfall. :roll:

Gruß, Wolfgang

[elvis]

Hallo,

Da ich Deinen Provider nicht kenne: ich hoffe, der hat ein Rescue-System für den Notfall.

Ja, klar - läuft alles über Weboberfläche.

Okay, habe mit dem neuen Kernel gebootet ... klappte leider nicht. Hab jetzt wieder den alten Kernel drin. Muss dann wohl was mit der Netzwerkkarte auf sich haben,..

Sobald ich von der Arbeit bin, werde ich nochmal schauen wie ich weiter mache.

Danke,
Elvis