Schlagwort-Archive: zypper

Wartungsarbeiten am Server abgeschlossen

Veröffentlicht am von

Vielleicht ist es dem einen oder anderen aufgefallen, dass dieser Server für ca. 1 Stunde (23 Uhr bis 0 Uhr) offline war. ;-) Der Grund ist, dass ich vom nicht mehr unterstützten openSUSE 11.2 via zypper dup auf openSUSE 11.4 über SSH hochgehoben habe.

Geplant war eigentlich auf openSUSE 11.3 zu aktualisieren. mkinitrd hat das (Fake) RAID-System unterhalb von /dev bzw. udev nicht gefunden und daher gemeckert. Dem verantwortlichen Perl-Bootloader von openSUSE 11.3 habe ich kein Vertrauen geschenkt und habe daher kurzfristig direkt weiter auf openSUSE 11.4 upgegradet (wohl gemerkt in der gleichen Sitzung ;-) ). Soweit sind keine Komplikationen aufgetreten, was an und für sich ziemlich gut ist. Ein Nebeneffekt hat das Upgraden doch. Der Server ist performanter, wobei man es auf den aktuellen Kernel 2.6.37.6-0.5-default zurückführen kann. Alle andere Server-Software habe ich via Repo aktuell gehalten und kann es von dieser Seite ausschließen.

In der Vergangenheit habe ich andere Erfahrungen (Upgrade von openSUSE 10.3/11.1 auf 11.2) gemacht, in der plötzlich die Netzwerkverbindung mitten im Upgrade zusammengebrochen ist und habe anschließend 2 Stunden im Rechenzentrum an dem Server gehampelt bis es wieder lief. Nein, das Rechenzentrum hat hier keine Schuld. Es war eine fehlerhafte Umstellung der zugeordnete Netzwerkkarte (bnc#546575). Das war nicht so wirklich toll. Downtime von ca. 32 Stunden. :-?

Zum Glück ist dieser Fall nicht eingetreten und so kann es dann mit dem Server noch ein paar Jährchen weiter gehen. :-)

Upgrade auf openSUSE 11.4 / Installationserfahrung

Veröffentlicht am von

Noch wenige Stunden bis zum offiziellen Release von openSUSE 11.4. Ich muss ganz ehrlich gestehen, dass ich gestern ein Upgrade auf openSUSE 11.4 nicht widerstehen konnte und mir die Goldmaster-CD heruntergeladen habe. Schon alleine die Paketliste ist sehr verlockend. ;-) Da ich sowieso ziemlich gerne am System herum bastele, habe ich kurzer Hand ein Upgrade auf meinem Netbook gewagt (Ich bin nach der Upgrade-Anleitung vorgegangen) und habe gleichzeitig eine Neuinstallation über das Netz auf meinem Desktop-PC durchgeführt. Bisher lief es zu meiner Freude recht glatt.

Eigentlich war ich nur neugierig, ob ATI Catalyst 11.2 unter openSUSE 11.4 wohl noch funktionierte. Der Treiber lief 1A. ;-) Die Anspannung der letzten Wochen fielen von mir ab. Da habe ich als Packaging Script Maintainer vom ATI-Installer für openSUSE wohl gute Arbeit geleistet und trage selbstverständlich die Hauptverantwortung. ;-)

Wenn ich mich noch an den Release von openSUSE 11.3 am 15.07.2010 zurückdenke. Bis AMD den Treiber (ATI Catalyst 10.7) für openSUSE 11.3 offiziell am 26.07.2010 freigegeben hat, hat auch nochmal 2 Wochen gedauert. Viel zu lange, wie ich finde, weil ATI Catalyst 10.6 auf openSUSE 11.3 gar nicht lief und der freie radeon-Treiber alles andere als gut war! Diesmal ist es anders. Jeder kann sofort openSUSE 11.4 installieren und den liebgewonnenen fglrx-Treiber dort ebenfalls installieren. ;-)

Das letzte Release Candidate von openSUSE 11.4-RC2 hat mich etwas enttäuscht, weil das Zusammenspiel mit meiner Radeon-Grafikkarte + freien radeon-Treiber + X-Server bei der Installations-CD überhaupt nicht geklappt hatte. Bevor die Installation startete, hatte sich der Bildschirm bis zur Unkenntlichkeit verzerrt und musste daher die Bootoption mit nomodeset=1 ergänzen, um den Kernel-Mode-Setting auszuschalten. Kurz bevor das Installationsprogramm YaST startete, ging mein Monitor in den Standby-Betrieb. So durfte ich ebenfalls den radeon-Treiber auf die Blackliste per radeon.blacklist=yes als Bootoption setzen, dann erst konnte ich installieren. Ich habe es noch als Generalprobe angesehen. Man sagt ja, wenn die Generalprobe richtig in die Hose geht, dann ist die nachfolgende Show viel schöner und läuft reibungslos über die Bühne. Zumindest für die Zuschauer. :-)

Upgrade-Anleitung

  1. Alle eingebundenen Repository deaktivieren und später auf openSUSE 11.4 umstellen (Ich habe es deshalb deaktiviert, weil nur wenige openSUSE 11.4-Repos online waren. Das wird sich mit dem Release im Laufe des Tages ändern.)
  2. Repository (oss, non-oss, update) umstellen:
    oss-Repo:
    von openSUSE 11.3: http://download.opensuse.org/distribution/11.3/repo/oss/
    auf openSUSE 11.4: http://download.opensuse.org/distribution/11.4/repo/oss/

    non-oss-Repo:
    von openSUSE 11.3: http://download.opensuse.org/distribution/11.3/repo/non-oss/
    auf openSUSE 11.4: http://download.opensuse.org/distribution/11.4/repo/non-oss/

    update-Repo:
    von openSUSE 11.3: http://download.opensuse.org/update/11.3/
    auf openSUSE 11.4: http://download.opensuse.org/update/11.4/

  3. Cache bereinigen: 
    zypper clean -a
  4. Repo-Cache aktualisieren: 
    zypper ref
  5. zypper upgraden (Abhängigkeiten auflösen): 
    zypper in zypper
  6. Upgrade starten (Abhängigkeiten auflösen): 
    zypper dup
  7. Sicher gehen, dass auch alles upgegradet wurde. Wenn nicht, so oft wiederholen bis nichts mehr zum Upgraden da ist. 
    zypper dup
  8. Mittels einem von mir geschriebenen Skript prüfen, ob noch veraltete Pakete im System installiert sind. Wenn ja, entweder Paket aktualisieren (deaktiviertes Repo wieder einfügen, vorher noch auf openSUSE 11.4 umstellen) oder entfernen.

    Download: list-old-opensuse-packages.sh
    SHA1: list-old-opensuse-packages.sh.sha1

    sh ./list-old-opensuse-packages.sh
  9. Neue Konfigurationsdateien anzeigen und manuell mit einem Editor ersetzen: 
    find /etc | grep -E 'rpmnew|rpmsave'

    Es sollten zum Schluß keine *.rpmnew und *.rpmsave Dateien mehr vorhanden sein.

  10. Prüfen, ob die Einträge für Grub /boot/grub/menu.lst alle korrekt eingetragen wurden.
  11. Prüfen, ob wichtige Module in der Initramdisk fehlen. Daher einmal folgenden Befehl ausführen und in der Ausgabe nach mögliche Fehlermeldungen Ausschau halten: 
    mkinitrd
  12. Fertig! Rebooten. 
    reboot

Have a lot of fun! ;-)

openSUSE 11.3 wird mit KDE 4.4.4 ausgeliefert

Veröffentlicht am von

Eine großartige Nachricht erreicht mich aus der openSUSE-KDE-Mailingliste. openSUSE 11.3 wird mit KDE 4.4.4 ausgeliefert und nicht wie bisher mit KDE 4.4.3. Ursprünglich sollte in der kommenden openSUSE KDE 4.5 beinhalten. Leider werden die KDE-Entwickler bis zum Release-Termin (15.07.2010) von openSUSE 11.3 nicht mehr rechtzeitig fertig. So wurde mit openSUSE 11.3 RC1 sämtliche Software-Versionen eingefroren, um diese ausgiebig zu testen und vorhandene Fehler zu beseitigen. Neue Versionen finden nur in besonderen Ausnahmefällen doch noch Einzug in openSUSE 11.3.

Folgende Software-Komponenten wurden in KDE 4.4.4 behoben:

  • ark
  • dolphin
  • KAlarm
  • KGpg
  • KHangMan
  • kmines
  • knetwalk
  • kopete
  • kteatime
  • libkdegames
  • lskat

KDE SC 4.4.4 Changelog

Für die bereits veröffentlichte openSUSE 11.3 RC1 wird demnächst über ein Update-Test-Repo die KDE 4.4.4 verteilt. Jedoch muss man dieses Repo in openSUSE 11.3 RC1 hinzufügen, um diesen gesonderten Update-Kanal zu nutzen.

Um dieses Update-Test-Repo zu nutzen, genügt folgender Zypper-Befehl in der Konsole als root:

zypper ar -f -n "Update Test 11.3" "http://download.opensuse.org/update/11.3-test/" "Update_Test_11.3"

Die Mail [opensuse-kde] KDE SC 4.4.4 for openSUSE 11.3 zum Nachlesen. ;-)

openSUSE 11.2 – mehrere Kernels parallel installieren

Veröffentlicht am von

Im Normalfall wird der ältere Kernel unter openSUSE bei einem Update deinstalliert und der neue Kernel installiert. Dieses Verhalten stößt bei manchen Systemadministratoren auf Unverständnis. Das Problem lässt sich mit einem simplen Beispiel verdeutlichen. YaST2 bzw. zypper bietet ein Update zu einem neueren Kernel an. Man installiert daraufhin den neuen Kernel. Nach einem Neustart stellt man fest, dass der neuere Kernel eine Hardware-Komponente nicht mehr richtig anspricht. Auch ein Kernel-Panic ist vorstellbar, was zu einer Unbedienbarkeit des Systems führen kann.

Bevor wir uns ans Werk machen, müssen wir noch herausfinden, welche Kernel-Packages installiert sind. Dazu führen wir einfach in der Konsole folgenden Befehl aus:

zypper se -i kernel*

Bei mir sieht die Liste so aus:

Daten des Repositorys laden ...
Installierte Pakete lesen ...

S | Name                 | Zusammenfassung                                         | Typ
--+----------------------+---------------------------------------------------------+------
i | kernel-desktop       | Kernel optimized for the desktop                        | Paket
i | kernel-desktop-devel | Development files necessary for building kernel modules | Paket
i | kernel-source        | The Linux Kernel Sources                                | Paket

Jetzt öffnen wir die Konfigurationsdatei /etc/zypp/zypp.conf und suchen die Textstelle mit multiversion heraus:

##
## Packages which are parallel installable with
## diffent versions
##
# multiversion = kernel-default,kernel-smp

Und fügen einfach anhand der vorliegenden Liste der installierten Kernel-Packages folgende Zeile ein:

multiversion = kernel-desktop,kernel-desktop-devel,kernel-source

Ab jetzt ist man wirklich auf der sicheren Seite und man kann nach einem Kernel-Update im Bootmenü die Kernels auswählen, die man starten möchte.

openSUSE 11.2 – Überflüssige RPM-Packages aufspüren

Veröffentlicht am von

Das Kommandozeilen-Installationstool zypper ist sehr mächtig. Jedoch hat es leider auch eine Schwäche. Es kann bei der Deinstallation eines Package nicht automatisch weitere verwaiste Packages deinstallieren. (Diese Funktionalität ist für die nächste openSUSE Version geplant)

Im Repo von Packman gibt es ein Tool namens rpmorphan. Dieses Tool spürt verwaiste Packages auf und bietet diese ggfs. zur Deinstallation an. Das Packman-Repo lässt sich leicht über die YaST2-Repoverwaltung hinzufügen. Eine Anleitung gibt es hier: http://de.opensuse.org/YaST/Software/Community_Repositories

Nachdem man Packman eingebunden hat, kann man rpmorphan über YaST2 oder per zypper in der Konsole installieren:

zypper in rpmorphan

Das Tool kann man im GUI-Modus wahlweise über den Menü-Eintrag oder in der Konsole starten (letzteres sollte man besser vorziehen):

rpmorphan -gui

Es lässt sich auch ohne GUI-Modus ausführen, in dem man den Schalter -gui weglässt.

rpmorphan ohne weitere Schalter (Voreinstellung: Libraries) listet alle verwaisten Library-Packages auf und man kann hier nochmal die einzelnen Packages durchgehen, die man löschen kann/will/möchte. Hier ist ein wenig Vorsicht geboten. Da die Auswahl auch Entwicklungspakete und Codecs betreffen, sollte man selber nochmal abwägen, ob das Package doch noch gebraucht wird.

Wir können aber auch unsere Auswahl der verwaisten Packages mit folgenden Schaltern beeinflussen:

-guess-perl
    berücksichtigt Perl-Module
-guess-python
    berücksichtigt Python-Module
-guess-pike
    berücksichtigt Pike-Module
-guess-ruby
    berücksichtigt Ruby-Module
-guess-common
    berücksichtigt gemeinsame Packages
-guess-data
    berücksichtigt Packages, in der Daten für ein Package enthalten ist.
-guess-doc
    berücksichtigt Packages, in der Dokumentationen vorkommen.
-guess-dev
    berücksichtigt Development-Packages
-guess-lib
    berücksichtigt Library-Packages (Voreinstellung)
-guess-all
    berücksichtigt alle oben genannten Packages

z.B. mit folgendem Befehl können wir rpmorphan alle verwaisten Perl-, Python- und Ruby-Module auflisten lassen:

rpmorphan -guess-perl -guess-python -guess-ruby

Wenn man z.B. innerhalb der letzten 2 Tagen ein Package mit all seinen Abhängigkeiten installiert hat, kann man auch mit diesem Schalter -install-time das Zeitfenster definieren:

rpmorphan -guess-all -install-time 2

Auch die Auflistung in einem Zeitfenster, in dem auf eine Datei eines Packages nicht zugegriffen wurde, ist auch hier -access-time möglich. Jedoch muss man vorweg warnen, dass es je nach Anzahl der installierten Packages eine Menge Daten auswerten muss und dadurch eine Weile dauern kann. In diesem Beispiel ist der letzte Zugriff vor 30 Tagen:

rpmorphan -guess-all -access-time 30

Hat man einige Packages ausfindig gemacht, die man löschen will. Dann kann man dies mit zypper bequem ein oder mehrere Packages anhand der Package-Namen löschen:

zypper rm (package)

Welche Schalter es noch gibt, lässt sich wie folgt abrufen:

rpmorphan -help