Linux - kein Start nach Prozessor Downgrade

    Muß man eigentlich wenn man unter Linux (Ubuntu 20.4), wenn man einen Prozessoraustausch macht, das irgendwie mitteilen ?

    Oder erkennt der das immer(!) vollautomatisch, daß da jetzt eine neue CPU drin ist ? Gibt es dabei irgendwelche bekannten Stolperfallen.


    Szenario ist ein Austausch einer 4Core CPU gegen eine mit 2 Kernen. Ansonsten alles unverändert (soweit ich weiß).

    Das BIOS ist einmal auf Standardwerte zurückgesetzt, sollte also da was erkannt haben.


    Seitdem startet er zwar in den Loginscreen (sddm)(und meldet auch daß das fsck angeworfen und dann nicht weiter nötig ist) blockt aber manchmal die gesamte Maschine direkt nach Eingabe des Paßworts. Gelegentlich kommt aber auch ganz normal der Desktop.



    Irgendwelche Ideen ? Vorschläge ? Verdächtige bei sowas ? (etwa Plymouth oder sowas)

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Hmm, was steht denn so in dmesg?


    Eigentlich sollte der Kernel sich entsprechend konfigurieren, ich muss ja auch keine spezifischen Konfigurationen bei der Installation machen. Aber vielleicht hat GRUB irgendwelchen besonderen Parameter gesetzt? Was steht denn in der Konfiguration dort? Im Zweifelsfall könnte ein sudo update-grub ja helfen... .

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    Es geht um eine Etage obendrüber: richtig beim Desktoplogin. Grub läuft schön durch, da paßt auch alles. Dann startet auch der Desktop-Login und wirklich erst nach der Paßworteingabe dort, friert die Maschine ein. Mit der 4Core CPU ist die aber vorher nie an dieser Stelle ausgestiegen und kam immer definiert in den Desktop (KDE). Es muß also eigentlich irgendwas zwischen dem Desktop-Login und dem eigentlichen Desktop passieren.


    Ich komme acuh schön auf die virtuellen Konsolen. In den syslog Files steht ja nur noch drin, was systemd so startet. Werde aber morgen nochmal genauer schauen, was dmesg ansagt.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Nur die CPU downgegraded auf demselben Mainboard ?

    Hat der 2kerner evtl. ein paar Features weniger die das installierte System verwendet bzw. erwartet ?

    Vielleicht einfach mal einen neuen Kernel bauen für den 2kerner und es geht wieder...

    Keine Angst vor grossen Eisen !!!

    Das ist keine schlechte Idee (natürlich nicht das mit dem Kernel bauen ...), daß da was nicht vorhanden ist, was erwartet wird. Video-Decoder Einheit oder sowas in der Art. Würde zumindest gut erklären, warum der erst beim Desktop anfängt zickig zu werden. (alles andere läuft ja anscheinend) Dann werd ich mal auch noch nach den Doppel-EEs ("EE") im xorg.log suchen gehen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Die virtuellen Konsolen funktionieren, vorher. Ab der Stelle, wo es dann steht, geht auch das nicht mehr.

    Die Maschine ist dann komplett "zu" und macht nur noch aller ca. 30sec mal das HDD LEDchen an. Es ist aber eben auch kein Totalabsturz mit schwarzem Bildschirm oder irgendwelchen Kernelmeldungen, weshalb ich ja denke, daß das eigentlich schon noch läuft nur eben irgendwie komisch "geblockt" ist. NumLock muß ich mal testen (dahinter steht ja wahrscheinlich die Frage, ob das Keyboard überhaupt noch abgefragt wird).


    Ich dachte halt, jemand hätte sowas schonmal gehabt und könnte gleich einen passenden Begriff liefern - wie etwa dieses plymouth, mit dem ich vor einiger Zeit auch schon mal schwer gekämpft habe, bis es dann das tat, was es sollte.


    Komme aber eh erst heute Abend (frühestens) da wieder ran und vielleicht findet sich ja doch was in den log Files.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Der Kernel funktioniert und muss auch normalerweise bei einem "CPU-Downgrade" nicht neu gebaut werden. Das, was auf jeden Fall eher geschehen sollte, das X-Window-System neu zu konfigurieren, da hier sehr stark auf die Funktionen der CPU zurück gegriffen wird - gerade im zusammenhing mit KDE und der GPU in der CPU. ThoralfAsmussen schrieb ja, das erst nach dem grafischen Logon der Rechner "einfriert".


    PS: es sei denn, du hast einen Kernel mit statisch einkompilierten Geräte-Treibern, wie es gern bei den klassischen UNIXen, wie SINIX oder SUN OS gemacht wurde.

    Unter Linux habe ich schon ewig keinen statischen Kernel mehr gebaut. Das letzte mal, wo ich das gemacht habe, um auf einem IBM Microchannel PC den von IBM kaputt designten NMI zu deaktivieren (der Timer-Wakeup sollte den NMI Triggern, was aber nicht ging), den NOP-Idle-Loop einzuschalten, die SCSI-Suchreihenfolge von aufsteigend auf absteigend und dem SCSI-Kontroller im Linux-Kernel die 0 zu verpassen.

    Zitat von Norbert-97801

    Das, was auf jeden Fall eher geschehen sollte, das X-Window-System neu zu konfigurieren [ ... ]

    Sollte bei einer neueren Linux-Distribution (wie Ubuntu 20.04 oben) durch den X-Server eigentlich automatisch passieren: xorg.conf ist da nicht mehr notwendig, evtl. befinden sich unter /usr/share/X11/xorg.conf.d noch ein paar Dateien, die sind aber meistens "unproblematisch" ... ein Kernel- bzw. Distributions-Upgrade könnte helfen ...

    Also Kernal compilieren habe ich auf so einem Gerät auch noch nie gemacht, das ist einfach schon lange nicht mehr nötig (im Gegensatz zu alten HPs oder sowas).


    Aber, was ich mal kompiliert habe ist tatsächlich (und ohne das hier wäre mir das jetzt auch nicht eingefallen) der nvidia Treiber. Der installiert sich zwar vollautomatisch, aber macht dabei einen Compilevorgang um sich ans System anzupassen. Das wäre tatsächlich was, was man einfach mal wiederholen könnte und dann schauen, ob es damit besser klappt.


    Die logfiles von Xorg, sddm und syslog gegben keine Errors. Das bösartigste was da zu lesen ist, ist daß die Fontdirectories für Fonts, die sowieso nicht gebaraucht werden, nicht vorhanden sind (WW).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Zitat von ThoralfAsmussen

    Die Maschine ist dann komplett "zu" und macht nur noch aller ca. 30sec mal das HDD LEDchen an. Es ist aber eben auch kein Totalabsturz mit schwarzem Bildschirm oder irgendwelchen Kernelmeldungen, weshalb ich ja denke, daß das eigentlich schon noch läuft nur eben irgendwie komisch "geblockt" ist. NumLock muß ich mal testen (dahinter steht ja wahrscheinlich die Frage, ob das Keyboard überhaupt noch abgefragt wird)

    Funktioniert dann der Zugriff per Netzwerk von außen noch? Ping, ssh, ...?

    Ansonsten würde ich auf eine Konsole booten, mich von dort einloggen und dann den X-Server "per Hand" starten. Vorzugsweise auch per ssh, dann kannst du die ganzen Ausgaben nachvollziehen.


    Was für ein linux-image-*** hast du installiert? Insbesondere das Suffix (-amd64, -rt-amd64, -cloud-amd64, ...) könnte interessant sein.

    Was für eine Grafikkarte ist vorhanden? Ist es eine in den Prozessor integrierte GPU?

    Das klingt plausibel- wenn der Compiler Maschinencode produziert hat, der nur für die alte CPU passte, könnte das die Ursache sein. Lass' doch den Rechner eine Weile im Textmodus laufen. Wenn dann nix passiert, hast Du den Übeltäter eingegrenzt.


    How to Boot Ubuntu 20.04 into Text / Command Console | UbuntuHandbook

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    Gefällt mir 1

    Ein paar Sachen kann ich so beantworten: -i686 sollte das sein. Grafik ist nicht onboard, sondern eine kleine Quadro (NVS irgendwas) im PCIe x16 Slot. Treiber Alternativen wären dementsprechend der nvidia Treiber und noveau.


    Wie meinst Du das mit dem "lokalen ssh" ? Ich melde mich an, mache ein ssh Verbindung zu mir selber auf, starte das X (startx ?) und schaue dann wo genau nach ? Direkt am Display ? Find das ja bißchen skurril, klingt aber zumindest interessant. Kann ich gern mal probieren.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Zitat von ThoralfAsmussen

    Wie meinst Du das mit dem "lokalen ssh" ? Ich melde mich an, mache ein ssh Verbindung zu mir selber auf, starte das X (startx ?) und schaue dann wo genau nach ? Direkt am Display ? Find das ja bißchen skurril, klingt aber zumindest interessant. Kann ich gern mal probieren.

    Habe ich "lokal" geschrieben? Kann das gerade nicht finden.

    Ich nehme einen zweiten Rechner (kann im Zweifel auch ein Handy oder Tablett mit ssh-Client sein, wenn kein Rechner zur Verfügung steht) und logge mich von dem aus ein. Das ist immer ein ganz guter Test, ob der Rechner noch da ist und z.B. nur die Grafik spinnt, oder ob mehr im Argen liegt.

    Und man kann von der ssh-Konsole auch ein startx ausführen, wobei ich mich zu erinnern glaube, dass man da vorher noch eine Environment-Variable setzen musste, damit das klappt. Sicher bin ich mir da aber nicht mehr, ich habe zumindest das Problem schon sehr lange nicht mehr gehabt.


    EDIT: Ach so, -i686. Das sollte relativ unkritisch sein. Ist auf jeden Fall nichts neueres, was für mich bekannt Probleme machen könnte.

    Zitat von ThoralfAsmussen

    und gemeint ist bestimmt, daß man unter ssh das X11-forwarding anschalten muß.

    Ne, gerade nicht. Ich will ja einen X-Server auf dem Rechner selbst starten, und nicht, dass du vom zweiten Rechner das Bild des ersten siehst.

    Wobei das X11-Forwarding auch ein guter zusätzlicher Test sein könnte, ob zumindest das funktioniert. Es könnte ja auch sein, dass eines der gestarteten Programme so furchtbar abschmiert.

    Zitat von ThoralfAsmussen

    Die virtuellen Konsolen funktionieren, vorher. Ab der Stelle, wo es dann steht, geht auch das nicht mehr.

    Die Maschine ist dann komplett "zu" und macht nur noch aller ca. 30sec mal das HDD LEDchen an.

    Am besten man hat Zugang zum Linux System über eine serielle Schnittstelle (console). War früher (letztes Jahrtausend) im PC Bereich kein Problem (da immer vorhanden), aber bei modernen Motherboards wurde die on-board serielle Schnittstelle entfernt. Ich habe deshalb eine Schnittstellenkarte (seriell/parallel) in meinem Linux PC. Die Serielle Console ist im Serverbereich viel wichtiger, da hier fast ausschließlich remote administriert wird. Aber auch bei Bare Metal Servern wurde bei einigen Hosting Anbietern die serielle Schnittstelle / Console Server durch ein VNC Web Gedöhns ersetzt, was für einen Linux Admin extrem ärgerlich ist.

    Notfalls sollte man einen SSHD Service laufen lassen, wo man via ssh auf das fehhlerhafte System Shell Zugang bekommt.

    Aber wenn das System total blockiert (z.B. sshd kann nicht gestartet werden, Netzwerk ist nicht verfügbar) ist, hilft das auch nichts. Zumal ein ssh Zugang ein Sicherheitsrisiko ist.

    Zitat von Norbert-97801

    Unter Linux habe ich schon ewig keinen statischen Kernel mehr gebaut.

    In der Vergangenheit hatte ich mir fast immer die Mühe gemacht, einen statischen Kernel für mit dem Internet verbundene Server zu kompilieren. Das war ein großer Aufwand, weil man vorab alles identifizieren muss, was man so an Treibern braucht. Heute ist dieser Aufwand wohl nicht mehr praktikabel und man muss auf eine Reduzierung des Attack Surface (keine bösartigen Kernel Module können geladen werden) notgedrungen verzichten.

    Hast du möglicherweise irgendwann mal mit cpupower "gespielt" und sowas in deine startup-Skripte reingeschrieben? Damit könnte man wirklich Abhängigkeiten erzeugen, die bei weniger cores in den Wald laufen

    Die X11 Remote Diskussion ist jetzt hier:

    Thema
    X11 auf andere Maschine umleiten (Offtopic aus Linux - kein Start nach...)
    Du meinst bestimmt die export display Geschichte - die ist aber nur nötig wenn Du auch das x auf einem anderen Rechner darstellen möchtest...
    Wildfire

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    Zitat von ChaosRom

    ... geschrieben, dass du das BIOS-Setup auf Standardwerte zurückgesetzt hast. Hast du das vor dem Downgrade auch gemacht? Linux-Kernel sind schon lang nicht mehr so spezifisch wie früher. Wird die neue CPU vom Chipsatz und vom BIOS unterstützt?


    Sollte so gewesen sein. Also CPU gewechselt, dann BIOS Default-Reset. CPU müßte eigentlich i.O. sein, da die vorher schonmal auf dem Board war. Ist eigentlich alles keine große Hexerei: ist ein Asus P5K und Intel DualCore bzw vorher QuadCore (Q6600). Es ist ja auch gar nicht so, daß es nicht geht. Das System läuft ja schön, ich komme (Ctrl+Alt+F1 , ...+F2 etc) auch auf virtuelle Konsolen, und kann da alles machen.


    Es ist also wirklich eher was beim Einschalten des X11 oder beim Beenden des xdm (Paßwortabfrage). Bin aber noch nicht weiter - (hint) war grad Weihnachten - und langfristig wird die Lösung wohl sowieso mal ein Upgrade der gesamten Veranstaltung werden (Rechner und OS).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Zitat von ThoralfAsmussen

    Es ist ja auch gar nicht so, daß es nicht geht. Das System läuft ja schön, ich komme (Ctrl+Alt+F1 , ...+F2 etc) auch auf virtuelle Konsolen, und kann da alles machen.

    Eine virtuelle Konsole ist keine echte Konsole, da sie von der Funktionalität der Grafikkarte des zu untersuchenden Systems abhängt. Eine serielle Konsole, bei der der Linux-Kernel nur die serielle Schnittstelle bedienen muss, ist m. M. nach die einzige Möglichkeit, so etwas sinnvoll zu debuggen.