Kernel Updaten unter Suse 10.0

[feldwebelschulz]

Hi all,
ich möchte auf meinem dedi den Kernel updaten. Stehe momentan auf Version 2.6.13-15.10-default.

Nun meine Frage: Wie am besten upgraden?

1. rpm?
2. yast?
3. selber compilen?

Ich bitte um schnelle Antwort ;)

MFG Feldi

[wgot]

3. :lol:

[feldwebelschulz]

3. :lol:

Naja das ist mir eher nicht so lieb, habe damit keine Erfahrungen und keine Lust mir das System zu zeschiesen.

MFG Feldi

[Roger Wilco]

Naja das ist mir eher nicht so lieb, habe damit keine Erfahrungen und keine Lust mir das System zu zeschiesen.

Warum fragst du dann danach? Im Prinzip bleibt dir dann nur noch die Möglichkeit, einen fertigen Kernel zu installieren bzw. den von deiner Distribution zu aktualisieren.

EDIT: quote-Tag korrigiert.

[feldwebelschulz]

Ich will nur eins: Den Kernel so einfach wie möglich zu upgraden und das ohne mein System zu zerschiesen.

Wie ist mir relativ egal, muss nur laufen ^^

MFG Feldi

[wgot]

Hallo,

Ich will nur eins: Den Kernel so einfach wie möglich zu upgraden

warum schreibst Du das nicht im ersten Beitrag? Viel wichtiger als die Info daß Du die Antwort schnell haben willst, ich hab noch keinen gelesen der um langsame Antwort gebeten hat. :oops:

Yast oder rpm, was Dir sympatischer ist oder womit Du mehr Übung hast. Die Suse-Standardkernel sind auf Desktopanwendung und Portabilität optimiert, genau das Gegenteil von dem was auf einem Server optimal ist, deshalb meine (3) die allerdings nur Sinn macht wenn man eine saubere serveroptimierte Konfiguration vorliegen hat oder zu erstellen bereit ist (das macht richtig Arbeit).

Daneben gibt's als zweitbeste Lösung (4) bei manchen Providern installationsfertige Kernel auf internem Updateserver, z.B. als tar.gz die man nur nach Anleitung auspacken muß und rebooten.

In jedem Fall /boot/ sichern um bei Problemen schnellstmöglich auf den alten Kernel zurückstellen zu können.

Gruß, Wolfgang

[feldwebelschulz]

Ok. Gibt es eine Quelle wo es RPMs für Kernels die mit Suse 10.0 kompatibel sind und schon erfolgreich getestet wurden?

Bei Yast gibt es nur einen uralt Kernel zum updaten, das lohnt sich nicht. Wenn dann gleich richtig, also so neu wie es geht.

Wichtig ist mir noch, das der Kernel mit meinem System läuft und es nicht zerschiest.

MFG Feldi

[thorsten]

Warum magst du den kernel aktualisieren - geht es dir um Treiberunterstützung bzw features, die dein jetziger kernel nicht bietet - oder geht es dir darum Sicherheitslöcher zu stopfen?

=> SuSE pflegt deine kernel-Version mit Sicherheitsupdates weiter. Der Support für 10 wurde noch nicht eingestellt.

Schau mal nach welche Version er dir bei einem You-UpdateLauf (heißt das so?) installieren mag.
Die letzte Ziffer der Kernelversion ist mindestens eins höher als bei deinem installierten Kernel.
Wenn du also mit dem derzeitigen Verhalten deines Kernels zufrieden bist, installier dir einfach den von SuSE zur Verfügung gestellten neuen kernel. Das zerschießt dir auch nicht das System.

[aubergine]

An deiner Stelle würde ich die Arbeit investieren und selbst Hand anlegen.
Da du keine passende Konfigurationsdatei hast, musst du dich halt hinsetzen und eine erstellen.

Falls dann was nicht klappen sollte, kannst du deinen Bootloader so einstellen das er nur beim nächsten Restart deinen neuen Kernel wählt, ansonsten wieder zum alten bootet.

Wenn du dich an eines der vielen Tutorials im Netz hälst, kannst du eigentlich nicht viel kaputt machen, sondern nur dafür sorgen das er dank Bootloader nur beim nächsten Reboot nicht hochkommt.

[mattiass]

3. :lol:

Naja das ist mir eher nicht so lieb, habe damit keine Erfahrungen und keine Lust mir das System zu zeschiesen.

Da kann man nix zerschießen, wenn man den alten Kernel nicht löscht und auch die Einträge in der Bootloader-Konfiguration nicht zerschießt. Wenn der neue Kernel nicht bootet, bootet man nochmal den alten und kompiliert nochmal.

Die Geschichte mit

Code: Select all

gunzip -c /proc/config.gz > .config
make oldconfig
make menuconfig

Kennst Du? Dann einfach die für den Bootnötigen Module statisch einbinden und Du musst auch keine Initrd erstellen...

[wgot]

Hallo,

Gibt es eine Quelle wo es RPMs für Kernels die mit Suse 10.0 kompatibel sind und schon erfolgreich getestet wurden?

bei Suse :roll: oder bei manchen Providern auf deren Updateserver.

Bei Yast gibt es nur einen uralt Kernel zum updaten, das lohnt sich nicht.

Der ist "uralt" bezüglich neuer Features (die auf einem Server meist uninteressant sind) aber aktuell bzgl. Bugfixes. Da Du bisher einen Default-Kernel laufen hast eine schnelle und einfache Lösung den Server wieder sicher zu bekommen.

Wenn dann gleich richtig, also so neu wie es geht.

2.6.17.7 direkt von kernel.org und erntefrisch selbst compiliert.

Ein Kernel der gleichzeitig optimal ist und auf (fast) allen Servern läuft ist ein Widerspruch in sich. "Läuft fast überall" gibt's bei Suse, "auf unsere Server optimiert" ggf. beim Provider.

Gibt es bei Deinem Provider einen vollautomatischen Reset und ein Rescuesystem?

Wenn der neue Kernel nicht bootet, bootet man nochmal den alten und kompiliert nochmal.

Es gibt leider immer noch Provider die für einen simplen Reset 20 Euro pauschal oder eine Arbeitseinheit Hands-On berechnen, wie dort ein Rescueeinsatz abgerechnet wird möchte ich garnicht erst wissen.

Grub kennt für solche Fälle eine Failsafekonfiguration bei der ohne Reset automatisch der alte Kernel gebootet wird wenn der neue nicht hochkommt. Die Einrichtung dieser Konfiguration macht ohne Rescue aber auch keinen Spaß.

Gruß, Wolfgang

[mattiass]

2.6.17.7 direkt von kernel.org und erntefrisch selbst compiliert.

Es gibt Fälle, da ist 2.6.16.27 besser geeignet...

Gibt es bei Deinem Provider einen vollautomatischen Reset und ein Rescuesystem?

Wenn der neue Kernel nicht bootet, bootet man nochmal den alten und kompiliert nochmal.

Es gibt leider immer noch Provider die für einen simplen Reset 20 Euro pauschal oder eine Arbeitseinheit Hands-On berechnen, wie dort ein Rescueeinsatz abgerechnet wird möchte ich garnicht erst wissen.

Ich kenne aber keinen Provider, bei dem sich die alten Rootserver nicht nachträglich für Reset/PXE-Rettungssystem/Affengriff/serielle Konsole einrichten lassen. Wenigstens Affengriff und stromlos schalten ist eigentlich immer drin.

In Fällen, wo das nicht geht (sehr alte Hetzner-Colocation bspw.), kann man immer noch über Nacht eine Lara ordern. Mit dieser hat man auch Zugriff auf das Bootmenü und die Konsole und kann im Bootmenü den anderen Kernel auswählen, wenn der frisch kompilierte nicht hochkommt.

D.h. bitte tatsächlich abklären, welche Zugriffsmöglichkleiten bereitstehen. Blindflug klappt oft, aber nicht immer...

[Anonymous]

Vielleicht gehört Ihr auch zu der Spezies Mensch - genannt "Flink-Klicker". Mir ist es heute so ergangen. Nachdem ich nichts gegenteiliges im Netz gefunden habe, habe ich auf meinem Strato HighEnd Server SR3 (sollte auch für alle anderen Systeme MIT RAID1 gelten) das in YAST angebotene Kernel-Update durchgeführt (von 2.6.13-15.10 auf 2.6.13-15.11).

Nach einem Reboot - könnt Ihr Euch denken - sagte das System keinen Mucks mehr. Alle im Netz angebotenen Lösungen funktionierten nicht - und ja - ich habe vergessen nach dem Update aber VOR dem Reboot den für Lilo/Grub notwendigen Aufruf durchzuführen.

Nach langem Rätseln und Probieren:

1. Ändern im Strato Configbereich: Serverkonfiguration -> RecoveryManager -> Bootmodus: Starten des Rettungssystems
2. Dort Ankreuzen: Reset [X] -> Weiter (Euer System bootet nun neu und startet im Rescue-Modus)
3. Verbindet Euch nun mit Eurem System über die RemoteConsole. Loggt Euch dort entsprechend ein
4. Nach dem Einloggen muss erst die Platte gemountet werden - alle Lösungen mit /dev/hda funktionieren nicht!!!
5. Wie folgt vorgehen:

   Code: Select all

   # 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

6. Unbedingt mit der Remote Console verbunden bleiben! ...dann...
7. Wieder rückändern im Strato Configbereich: Serverkonfiguration -> RecoveryManager -> Bootmodus: Normaler Boot
8. Dort NICHT Ankreuzen: Reset [ ] -> Weiter (Beim nächsten Reboot startet das System ganz normal)
9. Und dann wieder auf der RemoteConsole:

   Code: Select all

   # reboot

10. Alles sollte wieder schön laufen

Die Angaben ohne Gewähr - bin leider kein Experte für *NIX-Fragen. Möglicherweise hat ein qualifizierterer Forumsteilnehmer hier noch ein paar Anmerkungen oder Vorschläge.

[mc5000]

Schon erstaunlich wieviel geballtes Wissen und gute Ratschläge hier in knapp 12 Stunden zusammengetragen wurden. Und das, obwohl ich den Eindruck habe, dass Feldi weder das Wissen noch die Motivation mitbringt die notwendig wäre - möge ich mich irren. :roll:

Da ich aber auch noch was nützlichen beitragen möchte:

@Feldi:
Bei welchem Provider steht die Kiste?
Je nachdem erhälts Du dort auch Unterstützung für eine erste Config zum selber bauen.