Upgrade von 13.2 auf Leap 42.3

Hinweis: In dem Thema Upgrade von 13.2 auf Leap 42.3 gibt es 11 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hi,


    der Upgrade von 13.2 auf 42.3 hat super funktioniert, aber einige Defaults sollten überdacht (=kommt von denken) werden.
    Wer 13.2 verwendet hat eventuell schon die nicht mehr funktionierenden Repositories deaktiviert mit:


    Code
    zypper mr -d <#>

    wobei <#> für die Nummer des Repositories bei der Abfrage "zypper lr" steht.
    Wie man ein Backup des Repositories erstellt und die 13.2-Einträge auf Leaf ändert steht hier
    Upgrade To openSUSE 42.1 From openSUSE 13.2
    Unter den Leaf Versionen geht es dann immer mit dem gleichen Schema - aber Release für Release - weiter:
    SDB:System upgrade - openSUSE
    Ich hatte rund 8000 Pakete auf einer SDD. Das geht dennoch recht flott, aber ab und an muss man bestätigen.


    VOR dem ersten Upgrade lohnt es sich die noch funktionierende GUI zu nutzen um eine korrekte Schreibweise
    der inaktiven baseurls und der gpgkeys in den Dateien unter file:/etc/zypp/repos.d/ zu erreichen:
    z.B.
    baseurl=http://download.opensuse.org/repositories/artwork/wallpapers/openSUSE_Leap_42.1/
    baseurl=http://download.nvidia.com/opensuse/leap/42.1/
    baseurl=http://download.opensuse.org/repositories/Education/openSUSE_Leap_42.1/
    baseurl=http://download.opensuse.org/repositories/Emulators/openSUSE_Leap_42.1/
    baseurl=http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_42.1/
    baseurl=http://download.opensuse.org/repositories/systemsmanagement/openSUSE_Leap_42.1/


    Dann geht es los; immer auf der command line und wenn jemand fragt ob weitermachen, immer ja sagen:
    # erst mal nach der Anleitung oben arbeiten
    # ich habe "tmux" verwendet, weiß aber nicht, ob das wirklich notwendig war
    sed -i 's/13\.2/leap\/42.1/g' /etc/zypp/repos.d/*
    zypper ref
    zypper dup
    reboot
    zypper up
    sed -i 's/42\.1/42.2/g' /etc/zypp/repos.d/*
    zypper ref
    zypper dup
    reboot
    zypper up
    sed -i 's/42\.2/42.3/g' /etc/zypp/repos.d/*
    zypper lr
    zypper mr -e <#>
    zypper ref
    zypper dup


    Bei dem zypper up sollte normalerweise nichts installiert werden. (Für mich war das zur Kontrolle)


    Umstände hatte ich zuerst mit nvidia, da die erforderlichen modules (lsmod, modprobe, insmod) nicht automatisch gebaut werden. Also
    zypper remove nvidia-gfx... ..-default/..-desktop (am besten alles was mit nvidia beginnt)
    zypper install nvidia-gfxG04-kmp-default
    Es geht sicher einfacher, aber ohne GUI macht Browsen keinen Spass.
    Jetzt sollte x11 für die nvidia-User wieder funktionieren.... sollte


    Jetzt hatte ich interessante Effekte:
    - Mein Rechner hatte die Geräuschkulisse eines Jets nur etwas weniger Fahrt
    - Die Leistung wurde für Core-Dumps genutzt. 8 Cores = 8 Core-Dumps parallel
    - das GUI crasht im runlevel 5 - also Betrieb nach "telinit 3" im runlevel 3 - gui mit "startx" starten
    - Die Menus erschienen meist (interessanterweise nicht immer) wie die Kriegsfahne der Pazifisten: weißer Adler auf weißem Grund
    - aber lesen konnte man nichts, da die Schrift auf dem Display immer wieder verschwamm.
    - Im bewegten Fenster konnte man alles prima lesen, im ruhenden nach 30 Sekunden nichts mehr.


    Was war los:
    - Die CPU ist bei 100%. "ps ax" zeigt eine Reihe 'systemd-coredump' - killen hilft nicht, kommen ca. alle 10 Sekunden wieder
    "zypper remove tracker" und dieser Spuk ist vorüber.
    Merke: "drecks tracker"
    - Die verschwimmende unlesbare Schrift kommt vom "Compositor" (unter Display/Anzeigen), der in den Einstellungen abgeschaltet werden kann und
    erst beim nächsten Login aktiv wird. (Für jeden Haken kommt die Warnung, dass dies nicht sofort aktiv wird, aber nicht für diesen Compositor)
    Merke: "Compositor kompostieren"
    - aus irgendeinem Grund aktualisieren sich die NVidia Pakete nicht nach einem Kernel-Upgrade:



    Meine Frage an die Paketierer:
    - Zu was soll dieser Compositor gut sein. Das Ding scheint praktisch nicht dokumentiert zu sein. Kein Mouseover, keine Online-Hilfe unten rechts.
    Wer in der Welt meint, dass das Auslöschen bzw. die Unlesbarkeit von Size 24+ Buchstaben hilfreich ist ? Und warum ist das Teil im Default aktiv ?
    - Warum kann ich nunmehr im Terminal "Konsole" keinen Font mehr wählen, sondern erhalte die Default Proportional(!)schrift in einer Konsole ?
    - Das Problem mit dem Tracker hatten schon recht viele vor mir. Wenn das Teil schon automatisch implementiert wird, warum dann nicht mit default "off"
    - Kann man einen Call für "make" in die Systemstart-Sequenz der nvidia-Quellen bzw. dessen Integration einbauen ?
    Sind die Pakete für den aktiven Kernel da, geht darüber weg, sonst wird für nvidia-gfxG04-* ein Build der Module aufgerufen.
    Bug 1044816 – kernel 4.4.71 doesn't allow user to install Nvidia blob with nvidia-drm feature enabled das Problem mit dem drm-kmp-default Paket hatte ich übrigens auch.


    Im Großen und Ganzen war alles recht einfach. und die Upgrades gingen solide durch.
    Die paar angemerkten Punkte können jedoch ganz ordentlich nerven. In unlesbaren Menus unlesbare Optionen zu suchen,
    kann Linux schon ein paar Nutzer zurück auf kommerzielle Betriebssysteme senden.


    Keep up the good work, and be (even more) careful


    Danke
    Anders

  • Bitte verwende für Code-Ausgaben auch Code-Tags. Im Editor </>
    So mag das keiner lesen.


    Dein Link zu dem Update Procedere ist fragwürdig.
    Dem Herren scheint der Unterschied zwischen dup und up nicht klar zu sein.


    In case ‘dup’ command doesn’t work, simply run the ‘update’ command. In my case, sypper dup shows too many dependencies issues.


    Frage lieber gleich hier.
    Dann hättest du eine Codezeile gekriegt, die alles auf einmal macht.
    Dafür hinterher aber funktioniert.

  • Alles in einer Zeile wäre schön gewesen, aber selbst hier
    SDB:System upgrade - openSUSE steht, dass jedes
    Release einen einzelnen Update/Upgrade erfordert. ;)


    Ja, über dup vs up bin ich auch gestolpert, da ich den Unterschied
    zu kennen glaube und eigentlich nur distribution upgrades nutze.
    Darüber hinaus fehlte aber eigentlich nichts und der Link steht oben bei Google.


    Was ich vergessen hatte zu erwähnen:
    Der Upgrade baut file:/etc/grub2/grub.cfg etwas merkwürdig um.
    Dass er die Release-Level nicht mehr ersetzt, hätte ich mir denken können,
    aber das hier hat mir Fragezeichen in die Augen getrieben: 90 Sekunden auf UUID warten.
    Beim ersten Mal war das Ganze noch garniert mit wiederholten Fehlermeldungen.

    Code
    [...]
          linux   /boot/vmlinuz-4.4.114-42-default root=UUID=123a4567-2222-4334-1111-789123456789 resume=UUID splash=silent quiet showopts libata.force=noncq
    [...]

    Was ich vergessen hatte zu fragen:
    Gibt es fertige openSUSE_Leap-Pakete, die auf die NVidia-Chips zugreifen ?
    Ich denke an ffmpeg, mencoder/mplayer, hamradio module, tensorFlow, etc.


    Thanks
    Anders

  • Alles in einer Zeile wäre schön gewesen, aber selbst hier
    SDB:System upgrade - openSUSE steht, dass jedes
    Release einen einzelnen Update/Upgrade erfordert. ;)

    Wenn du alles glaubst, was im Internet steht, glaubst du mir ja sicher.


    Wir haben das sehr wohl probiert.
    Es gibt richtig Ärger, wenn an zypper existentielles geändert wird. Das war aber seit 13.2 nicht der Fall.


    Ja, über dup vs up bin ich auch gestolpert, da ich den Unterschied
    zu kennen glaube und eigentlich nur distribution upgrades nutze.
    Darüber hinaus fehlte aber eigentlich nichts und der Link steht oben bei Google.

    Ach, na dann kann das ja nur die reine Wahrheit sein. So wahr ich mir helfe.



    Was ich vergessen hatte zu erwähnen:
    Der Upgrade baut file:/etc/grub2/grub.cfg etwas merkwürdig um.
    Dass er die Release-Level nicht mehr ersetzt, hätte ich mir denken können,
    aber das hier hat mir Fragezeichen in die Augen getrieben: 90 Sekunden auf UUID warten.
    Beim ersten Mal war das Ganze noch garniert mit wiederholten Fehlermeldungen.

    Code
    [...]
          linux   /boot/vmlinuz-4.4.114-42-default root=UUID=123a4567-2222-4334-1111-789123456789 resume=UUID splash=silent quiet showopts libata.force=noncq
    [...]

    Wie meinen?


    Ich kenne da keine Merkwürdigkeiten. Was meint "Release-Level ersetzen"?
    Geht nun die Root-Partition mit UUID Mount, oder nicht?


    Was ich vergessen hatte zu fragen:
    Gibt es fertige openSUSE_Leap-Pakete, die auf die NVidia-Chips zugreifen ?
    Ich denke an ffmpeg, mencoder/mplayer, hamradio module, tensorFlow, etc.


    Thanks
    Anders

    Was meinst du damit?
    Rechnen auf der Graphikkarte? Die von dir "gedachten" Pakete haben mit der Graphikkarte erst mal gar nix am Hut.
    Letztlich muss jedes Zeichen auf den Bildschirm "auf Nividia Chips zugreifen"(, wenn es nur eine Graphikkarte gibt).

  • Danke, liebe Berichtigung !
    Es ist nett, mit Dir öffentlich zu unterhalten.
    (Sorry, das mit dem Zitieren werde ich wohl irgendwann in einem anders Thread üben.)


    90 Sekunden auf UUID warten


    Eigentlich wartet die Boot-Sequenz 1:30 Minuten und daneben zählt der Counter bis das Filesystem "UUID" für den Resume (vom Hibernate) verfügbar wird.
    Während hinter dem Eintrag root=UUID=<#> zu lesen war, fehlt das zweite "=" und der Teil danach bei resume=UUID.
    Ich nehme an, die 90 Sekunden verstreichen bei der erfolglosen Suche nach dem File-System mit dem Label UUID. (Merke: "UUID" ist kein gutes Disk-Label )
    Nachdem das System im 2ten Anlauf dennoch startete, dauerte es bei mir noch ein paar Minuten bis ich verstand, dass ein pm-hibernate nun wohl nicht angebracht ist.
    Ja, ich nutze bei Filesystemen meist die UUIDs (Wie kam ich auf diese Idee? vielleicht sollte ich mich mal umstellen). Das ging und geht (noch).


    Beim Boot wird die aktuelle Kernel-Version angezeigt, aber in der Auswahlliste stand aber der Text "SuSE 13.2".
    Logisch, denn in file:/etc/zypp/repos.d habe ich ja auch selbst gewütet und "13.2" durch "Leap_42.1" ersetzt.


    Rechnen auf der Graphikkarte?


    Ich gebe Dir recht, dachte ich vor ein paar Jahren doch genauso (und ich veralbere dich nicht). Was haben diese Anwendungen mit der Graphikkarte zu tun?
    Warum wollen alle diese irren "Gamer" High-End-Graphikkarten mit 10GB+ Memory und einem Bus von 384bit Breite ? (Tipp: hat nichts mit sechs 64-Bit CPUs zu tun)
    Viele dieser "Gamer" sitzen in Hochschulen und Forschungszentren und sie nutzen zum Teil Graphikkarten ohne Videoausgang (HDMI/VGA/DVI/...).
    Hast Du schon mal bemerkt, dass niemand den Crays dieser Welt nachweint? Auch die Grid-Welle ist ziemlich abgeebbt.


    1,Gedanke: Klar, wenn die Karte Videofilme dekodieren kann und auch kodieren, dann kann sie mit der richtigen Software Videofilme auch umkodieren.
    2.Gedanke: Was macht die Karte dabei: Sie führt möglichst viele gleichartige Berechnungen an allen Stellen des Bildes gleichzeitig durch (Theorie).
    3.Gedanke; Welche Software arbeitet noch so ähnlich ? Frequenzanalyse (Fourier-Transformation), Finite Elemente Systeme, Ray Tracer, Neuronale Netze, ...


    Na klar es gibt Bibliotheken. Die kann man doch einfach austauschen. Bis auf das "einfach" richtig. Aus meiner Sicht ist das Problem der Lagerort der Daten.
    Nichts wird schneller wenn die Daten ständig in die Graphikkarte geladen und aus ihr entladen werden. Das sollte schon etwas konsequenter geschehen.
    Mein ffmpeg-Eigenkompilat ist mit cuda z.B. beim Umkodieren von Videos bei meiner antiken 8-Core-Kiste auf der 740er NVidia-Karte ca. 10 mal schneller als ohne.


    Paketverwaltung


    Den "drecks Tracker" will ich doch nicht mehr auf meinem System haben. Beim dist-upgrade will er aber immer unbedingt mit rein.
    Ich habe ihm die Installation mittels zypper al tracker die Installation verboten. Geht das eleganter?


    Alles
    Anders


    --
    Leap: Der Sprung vom Unglück (13) zum Sinn des Lebens (42). Anonymer Numerologe frei nach Douglas Adams

  • Den "drecks Tracker"

    Tracker ist das Gegenstück von Gnome zu baloo aus kDE.
    Die Dateisuche.


    Zum Thema UUID:
    Das Problem mit dem resume Eintrag tritt anscheinend des öfteren beim Upgrade auf.
    Hier hilft meist, den Eintrag zu entfernen oder auf das swap zu setzen.


    Zum Thema Grafikkarte:
    Installiere dir den Nvidia Treiber sowie Cuda.
    Allerdings hab ich das berechnen auf einer Grafikkarte noch nie versucht.

    Für den Inhalt des Beitrages 118539 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Partitionslabel haben mit UUID absolut gar nichts zu tun.
    Du kannst aber nach, wie vor, mit Labels arbeiten.
    (Auch von den Labels gibt es verschiedene Varianten, je nachdem, ob GPT, oder herkömmliche Partition)


    UUID wird hauptsächlich vom UDEV Mechanismus verwendet. Damit hast du die gleiche Leistungsfähigkeit (nämlich Eindeutigkeit), wie mit Labels.
    Sind halt nicht so leicht zu lesen, wie Labels.
    Ich bezweifle, dass du wirklich das richtige OS lädst. Man kann auch einem alten openSUSE einen nigelnagelneuen Kernel reinbasteln. Sogar sehr leicht.
    Zumindest würde ich das mal __wirklich__ prüfen.
    Und die korrekten UUIDs durchgängig einstellen ODER KOMPLETT auf Labels umsteigen. fdisk -l -o +UUID ist dein Freund.
    (Das ist nur ein Rat; man kann sehr wohl auch das Mischen, wenn man auf Verwirrung Wert legt)


    Was wirklich bei deinem Systemstart auf wen wartet, sagt dir ein systemd-analyze blame. Da systemd alles hoch parallelisiert startet, ist es nicht so klar.
    Zeige den Output von blame.


    Wenn die Herren Studenten ein wenig älter mit ein wenig mehr Lebenserfahrung wären,
    wüssten auch sie, dass open source eben so seine Schwierigkeiten mit proprietären Sächelchen hat.
    Wenn du auf deiner GPU rechnen willst, kannst du für Nvidia CUDA installieren. Natürlich das komplette Paket samt Treiber dann auch von NVIDIA,
    bei ATI nennt sich das "ATI Stream". Beides rein proprietär.


    Du kannst es auch mit dem openTK (open Toolkit) versuchen. Das ist ein Wrapper um diese Gebiete.
    Und rein open source wäre openGL. Da sollte man aber vorher peinlich genau gucken, ob die eigene GPU auch unterstützt wird.
    Logisch bringt das nicht soviel Durchsatz, wie die rein proprietären Pakete. (die ihrerseits aber ja auch wieder gebunden sind)


    Übrigens mussten die alten Säcke das alles erst bauen, damit sich später daran junge, unerfahrene Studenten überhaupt erst die Zähne ausbeißen können.
    Tatsächlich haben die sogar alle junge Studenten zusammengebu***.
    Also bitte etwas mehr Respekt.
    Und Fakten, keine Prosa.

  • Ah, systemd-analyze blame kannte ich noch nicht. Alles zusammen 16s Bootvorgang, Das könnte stimmen.


    Zum Ausprobieren: Mit resume=UUID im boot string steht dann dort eine graphisch wirkende Symbolfolge, in etwa <===[color=#FF0000]*[/color]==> ( 0:55 von 1:30 )
    und der Programmierer hat (zu) viel Knightrider gesehen. Wie gesagt 90 Sekunden ASCII-Animation für K.I.T.T.-Fans.


    Das OS, das ich möchte ist aktiv. uname, file:/etc/{os,SuSE}-release file:/proc/version und rpm -ql openSUSE-release-42.3 sagen ich wäre dort wo ich sein möchte.


    Cuda-8 ist natürlich installiert. Graphikpakete habe ich zwar auch installiert, aber ich werde wohl kaum vermeiden können, mir mit Cuda selbst Apps zu kompilieren.
    Die Hersteller kennen ihren Assembler anfangs meist besser (vor allem, wenn sie die Chips ständig umstricken) und die Binärbibliotheken (Assembler) kann gerne
    jemand nachbauen. Aber auch Hersteller wie NVidia(c) haben verstanden, dass sie funktionierende Hardware (und damit auch die Software) anbieten müssen, um
    im kommerziellen Segment erfolgreich zu sein. Betriebssystemreferenzen auf Microsoft(c) und Apple(c) finden sich im Katalog kaum. Theano, PyTorch, Caffe und viele
    andere NNS sind in Python geschrieben. Ich finde es nicht schlimm, dass proprietäre Produkte sich an Open Source anbinden. Schön wäre es, wenn sie beitragen würden.

  • Bitte verwende Code- Tags für Ausgaben. Im Editor: </>


    Genau dein Upower braucht am längsten. Ziemlich das, was zu erwarten war. Dort wird der Resume geregelt. Bei dir geht das nicht, weil du immer noch falsche UUID Einträge fährst. (Und trotz Aufforderung samt korrektem Befehl keine Fakten bringst, damit man dir sagen könnte, was du wohin zu ändern hättest, damit es anständig läuft)
    Bringe dein UUID Chaos unter Kontrolle. Dann ist alles gut.
    Oder lasse es, dann dauert es halt zwei Sekunden länger.


    Deine file: Angaben sind falsch. Du referenzierst damit Unterverzeichnisse etc und proc im jeweiligen cwd.
    Korrekt wäre file:///etc..... In Linux wird nicht geschussert.


    Das, was du "graphisch wirkende Symbolfolge" nennst, sind tatsächlich schlichte ASCII (Escape) Color Codes.
    Wieder einmal teilst du uns die nicht mit. (Wir wollen so etwas in Kopie lesen)
    Nicht dass man sofort sagen könnte, was Sache ist, umschreibst du sie lieber mit eigenwillig junger Prosa.
    Unklar bleibt, ob du tatsächlich Farben siehst. Oder diese Zeichen in Standard Terminaleinstellung erscheinen (scharz/weiß wenn du nicht dran rumgefummelt hast).
    Das wäre der Zweck dieser "Symbolfolgen". Siehst du die wörtlich, statt Farben, dann stimmt mit deinen Terminaleinstellungen etwas nicht.
    systemd zeigt damit seit geraumer Zeit den Status all seiner parallel gestarteten Tasks an.


    Du musst einem Pythonista nicht erzählen, was es alles in Python gibt.
    Wie ich schon schrieb: Fakten, keine Prosa.
    Und wir alten Säcke haben das alles gemacht.

  • Es kann schon mal vorkommen, das der resume Eintrag nach einem Update nicht stimmt.


    Bootet die Kiste jetzt mit 90 Sec. Verzögerung?


    Bitte benutze für Konsolenausgaben Code, nicht Spoiler.

    Für den Inhalt des Beitrages 118569 haftet ausdrücklich der jeweilige Autor: Sauerland