(Gelöst) - Opensuse Leap 42.1 bootet nicht immer

    (Gelöst) - Opensuse Leap 42.1 bootet nicht immer

    Hallo,

    muss mich an die community wenden, weil ich selber überhaupt nicht mehr weiterkomme.

    Habe ein aktuelles Opensuse Leap 42.1-System mit allen updates. Im PCIe-Slot steckt eine Nvidia-Graka.
    Bei Booten fährt das System manchmal hoch, manchmal nicht - etwa jedes zweite Mal klappt es - durchschnittlich gesehen. Das ist unabhängig davon, ob ich den Strom abschalte oder das System geregelt herunterfahre. Das ist unabhängig von der Kernel-Version oder den Nvidia-Treibern. Seltsamerweise hatte ich genau dieses Phänomen auch auf einem anderen Rechner, auf dem ich Leap 42.1 installiert hatte. Beide Rechner haben SSDs.

    Wenn es nicht klappt, lande ich im emergency-mode. Dort kann ich mich als root einlopggen, und kann auch mit

    Quellcode

    1. journalctl - xb
    eine Ausgabe sehen. Leider kann ich deren Inhalt nicht posten, da ich keine Möglichkeit habe, die Ausgabe in eine Datei zu packen, die ich beim nächsten Start zur Verfügung habe. In der Ausgabe sind ein paar Sachen rot markiert, die ich mit aufgeschrieben habe und jetzt möglichst unverfälscht abtippe.

    Quellcode

    1. Failed to lookup alias "sg", funktion not implemented.
    2. Failed to lookup alias "tuxedo-wmi", funktion not implemented.
    3. Failed to start load Kernelmodules
    4. Systemmodules loadservice: main process exited, code=exited,status=1/failure
    5. Error calling EVIOCSKEYCODE on device node /dev/input/event4: invalid argument
    6. nvidia: module licence "nvidia" taints kernel
    7. Disabling lock debugging due to kernel exit


    Ich weiß überhaupt nicht, wo ich ansetzen soll!

    Es wäre ganz toll, wenn Ihr Lösungsvorschläge hättet, das Problem ärgert mich schon monatelang und ist bei der täglichen Arbeit sehr lästig!

    Markus

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „glako“ ()

    Hallo Sauerland,

    danke für die schnelle Antwort!

    Quellcode

    1. zypper lr -uP


    Brainfuck-Quellcode

    1. # | Alias | Name | Aktiviert | GPG-Überprüfung | Aktualisierung | Priorität | URI
    2. --+--------------------------+-----------------------------------+-----------+-----------------+----------------+-----------+------------------------------------------------------------------
    3. 1 | Runterlad | Runterlad | Ja | ( p) Ja | Ja | 99 | dir:///home/markus/000MeineDaten/Eigenes/Runterlad
    4. 2 | download.nvidia.com-leap | nVidia Graphics Drivers | Ja | (r ) Ja | Ja | 99 | [url]http://download.nvidia.com/opensuse/leap/42.1[/url]
    5. 3 | ftp.gwdg.de-suse | Packman Repository | Ja | (r ) Ja | Ja | 99 | [url]http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_Leap_42.1/[/url]
    6. 4 | opensuse-guide.org-repo | Libdvdcss Repository | Ja | (r ) Ja | Ja | 99 | [url]http://opensuse-guide.org/repo/openSUSE_Leap_42.1/[/url]
    7. 5 | repo-non-oss | openSUSE-Leap-42.1-Non-Oss | Ja | (r ) Ja | Ja | 99 | [url]http://download.opensuse.org/distribution/leap/42.1/repo/non-oss/[/url]
    8. 6 | repo-oss | openSUSE-Leap-42.1-Oss | Ja | (r ) Ja | Ja | 99 | [url]http://download.opensuse.org/distribution/leap/42.1/repo/oss/[/url]
    9. 7 | repo-update | openSUSE-Leap-42.1-Update | Ja | (r ) Ja | Ja | 99 | [url]http://download.opensuse.org/update/leap/42.1/oss/[/url]
    10. 8 | repo-update-non-oss | openSUSE-Leap-42.1-Update-Non-Oss | Ja | (r ) Ja | Ja | 99 | [url]http://download.opensuse.org/update/leap/42.1/non-oss/[/url]

    Quellcode

    1. uname -a

    Quellcode

    1. linux linux-40uq 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20 08:03:29 UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux


    Tuxedo hat nur ein Script, das man drüberlaufen lassen kann, aber keine eigenen Repos: linux-onlineshop.de/forum/inde…ghlight=tuxedo.sh#post353

    Nach Anwendung des Scripts trat der Fehler - soweit ich mich erinnern kann - das erste Mal auf. Das dort veröffentlichte Script ist nicht mehr ganz aktuell ... Deswegen will ich es auch vorsichtshalber nicht drüberlaufen lassen, sondern das Übel an der Wurzel bekämpfen ...

    Schöne Grüße!

    Markus

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „glako“ ()

    Hallo Sauerland,

    das ist die Ausgabe von zypper se -si nvidia. Es handelt sich um einen Desktop PC, also sind wohl keine weiteren tuxedo-Treiber nötig. nvidia-xconfig wurde ausgeführt.

    Brainfuck-Quellcode

    1. S | Name | Typ | Version | Architektur | Repository
    2. --+---------------------------+---------+-----------------------+-------------+------------------------
    3. i | nvidia-computeG04 | package | 367.57-28.1 | x86_64 | nVidia Graphics Drivers
    4. i | nvidia-gfxG04-kmp-default | package | 367.57_k4.1.12_1-28.1 | x86_64 | nVidia Graphics Drivers
    5. i | nvidia-glG04 | package | 367.57-28.1 | x86_64 | nVidia Graphics Drivers
    6. i | x11-video-nvidiaG04 | package | 367.57-28.1 | x86_64 | nVidia Graphics Drivers


    Hoffe, dass das mit den Code-Tags so in Ordnung ist.

    Herzlichen Dank!
    @Sauerland

    Deinen Vorschlägen kann ich zwar nur zustimmen und der TE sollte diese auch umsetzen, aber eines passt dann eben doch nicht so ganz ins Schema, denn selbst mit einer komplett verbaselten xorg-Konfiguration sollte das System eigentlich nie im Rescue landen sondern eben "nur" im multiuser.target (=alles da ausser X) stecken bleiben.

    Sofern -nachdem die vorgeschlagenen Änderungen durchgeführt wurden- das Problem wieder auftritt, sollte sich der TE also um das hier kümmern.

    Suserl schrieb:

    Leider kann ich deren Inhalt nicht posten, da ich keine Möglichkeit habe, die Ausgabe in eine Datei zu packen, die ich beim nächsten Start zur Verfügung habe.


    Dem muss ich hier mal widersprechen, selbst im Rescue Modus geht das mit ein wenig Nachhelfen.

    Das Besondere am Rescue dürfte sein, daß die Rootpartition "read.only" gemountet wurde, um z.B. zuerst fsck laufen lassen zu können und dann mit ggf. nötigen, restlichen Reparaturen fortzufahren.

    Das bedeutet aber nicht, daß man nicht einfach eine andere Partition (ggf. auch ein externes Medium, Stichwort USB-Stöpsel) händisch mounten und die entsprechenden Daten dann auch auf dieses Medium übertragen könnte.

    In sofern, mehr Daten und dann stehen die Chancen auf Hilfe besser, bisher ist das bestenfalls "gutes Raten", was das wirkliche Problem sein könnte, auch wenn zunächst mal das Beheben der von Sauerland angemerkten Probleme sicher kein Fehler ist.

    Greetz,

    RM
    "Programming today is a race between software engineers striving to build better & bigger idiot-proof programs and the Universe trying to produce bigger & better idiots. So far, the Universe is winning." (Rick Cook)

    Dies ist ein _öffentliches_ Supportforum, keinerlei Support per PN, EMail oder Instant Messenger.

    openSUSE Leap 42.2 - Kernel 4.11.x - fluxbox 1.3.7

    Bitmessage: BM-2D8h8QZmvHfgbixWeiG1NDZHG1iXAhBz8K
    Hallo,

    dank des Hinweises von Sauerland (Hinweis auf tuxedo) und Rainmaker (Hinweis, dass es wohl nicht an X liegt) bin ich auf die richtige Spur gekommen. Ich hätte schon früher alleine drauf kommen können ... das Problem liegt an einer ganz anderen Stelle.
    Ich habe auf der entsprechenden Festplatte unter anderem zwei Partitionen: sda 2 und sda 3. Auf sda 2 war das Root-Verzeichnis der tuxedo-Original-Installation mit dem Tuxedo-Script, das bei mir leider nicht funktionierte, also hatte ich hier ein zerschossenes System. Also habe ich auf sda 3 Leap nochmal installiert, diesmal vom iso-Image. Im Yast-Partitionierer stellte ich ein, dass sda 2 nicht gemountet werden sollte, im Yast-Bootmanager stelle ich den Ort der Boot-Partition auf sda 3 ein.
    Offenbar bootete das System ohne erkennbare Regelmäßigkeit je nach Lust und Laune einmal von sda 2 (dann ging es in den rescue-mode) oder von sda 3 (dann funktionierte es). Habe sda 2 gelöscht, und jetzt startet das System einwandfrei!!!
    Herzlichen Dank für Eure Hilfe, wollte mich schon von Opensuse verabschieden (nach 10 Jahren), aber habe gesehen, dass mir hier schnell und kompetent geholfen wird.

    Viele Grüße!