Beiträge von Spaceloop

    Tja, ich glaube ich habe eine Antwort...


    Ich wollte eben im NVidia-Repo für Leap 15.6 nachsehen, welche Version der dortige, für die Karte passende 390er Treiber hat. Aber: Der Treiber ist nicht da.


    Recherchen brachten folgenden Thread zu Tage:


    Nvidia 390.157 drivers and 6.6.x kernels – no X
    Is Tumbleweed going to suppoer NVIDIA 390.157 driver with 6.6.x kernels? I can’t switch to newer driver series as my graphics card is not suppoerte by them. $…
    forums.opensuse.org


    Das bedeutet wohl: für Karten, welche auf den 390er Treiber angewiesen sind, ist bei NVidia seit 2022 Schluss. Suse hat noch einige Zeit den Treiber am Leben erhalten für Leap, aber jetzt offenbar nicht mehr.


    Die Upgrade-Installation hat ihn zwar noch gebaut, aber offenbar hat sie einfach den von 15.5 genommen. Er ist nicht mehr für den 6.4er Kernel von Leap 15.6 angepasst.


    Aber: Grundsätzlich läuft er noch bis Kernel 6.6.


    Hier gibt es eine Version zur manuellen Installation mit Patchen für Kernel bis 6.6:

    git.altlinux.org - nvidia_glx_src_390.157.git/tree


    D.h. ich müsste wahrscheinlich vor einem dup auf jeden Fall auf Noveau wechseln. Und dann kann ich versuchen, den gepatchten NVidia-Treiber zu Fuß aufzuspielen.

    Hallo,


    ich habe gerade versucht, meinen Haupt-PC von Leap 15.5 auf 15.6 upzugraden.


    Ergebnis: KDE fährt nicht richtig hoch!


    Ich habe das System so konfiguriert, dass beim Starten die eine Textausgabe erfolgt. Dort ist noch alles grün und erfolgreich, ich konnte kein rot entdecken. Danach erscheint normalerweise die Glühbirne mit dem Zahnrad. Bei meinem System bleibt der Bildschirm schwarz. Es erscheint dann irgendwann der Mauscursor deutlich vergrößert. Zunächst der Default-Cursor, dann der von mir voreingestellte (ebenfalls deutlich vergrößert). Ich habe also einen schwarzen Bildschirm mit vergrößertem Mauscursor, welcher sich auch bewegen lässt (über den Hauptbildschirm, er wandert nicht zum 2. Monitor sondern bleibt beim 1. am Rand hängen)

    Auch interessant: Mit Rechtsklick in die obere linke(!) Bildschirmecke erscheint plötzlich, ebenfalls auf dem sonst schwarzen Monitor, das Menü der Soundeinstellungen (pasystray)(!!) - ebenfalls deutlich vergrößert. Eigentlich sitzt es bei mir aber unten ziemlich rechts... Der Desktop ist also irgendwie da...


    Ich kann im Moment keine Dauerbaustelle gebrauchen. Deswegen habe ich in GRUB wieder den letzten Snapshot von 15.5 gestartet und zurückgerollt. Das hat selbst beim Distributionsupgrade super funktioniert, diese Integration ist wirklich genial. 8)


    Was auch noch geklappt hat: ich bin in die STRG+ALT+Fx-Konsolen gekommen. Dort habe ich zumindest mal zypper lr -d in eine Textdatei gesichert, Ergebnis:


    Soweit ich das beurteilen kann, alles normal?


    Das System ist ein Core i5 4xxx. Die Grafikkarte ist eine NVidia Geforce GT610 mit zwei Monitoren, welche mit dem NVidia-Treiber angesteuert wird. Der Desktop ist KDE.


    Sind für diese Kombination Bugs bekannt?


    Ich würde jetzt einfach noch ein paar Wochen abwarten. Aber falls es wieder passiert: was wäre dann eine strukturierte Herangehensweise? Wie gesagt, die Konsolen sind da und bedienbar..


    EDIT: Ansätze, die mir noch einfallen:

    -Die Einstellungen der Grafikkarte, wie z.B. das Multimonitorsetup etc. für x11 und den NVidia-Treiber zurücksetzen (wie mache ich das?) Entweder vor dem duppen oder bei Misserfolg von der Kommandozeile?


    -vor dem duppen den Opensource-Treiber (Noveau) installieren, und bei Erfolg ggf. wieder den NVidia-Treiber testen...?

    Ich weiss ja nicht, wo ich diese Erkenntnis sonst noch posten könnte, aber vielleicht hilft es ja jemandem weiter.


    Wenn man einen Brother-Scanner im Netzwerk mit dem Linux-Install-Script von Brother installiert, so wie ich eben unter Tumbleweed, und der Scanner dennoch von Anwendungen wie gscan2pdf nicht gefunden wird:


    Die Debug-Ausgabe

    Code
    export SANE_DEBUG_DLL=255 && scanimage -L

    ...brachte zutage, dass die libnsl1.so.1 fehlt. Diese liegt unter Tumbleweed als Extra-Pakete für 64 und 32 Bit vor. Ich habe beide manuell nachinstalliert und seitdem geht es. 8)


    Hinweisen möchte ich zudem darauf, dass manche Drucker die libusb-0_1-4 benötigen, ebenfalls als Extra-Paket. Manche ältere Netzwerkgeräte aus dem Bereich benötigen u.U. diverse 32-Bit-Bibliotheken.

    Hallo,


    wenn man aus Hardware-Resten einen Core2Duo-Rechner aufbauen und unter Linux betreiben möchte... und man findet zwei Grafikkarten in der Grabbelkiste:


    -ATI/AMD Radeon 4550

    -NVidia Geforde GT 210


    Beide aus den Jahren ca. 2008-2010. Das System soll mit den Opensource-Grafiktreibern aus dem Kernel (noveau, ATI-Opensource) mit einem aktuellen Tumbleweed betrieben werden.


    --> Welche Grafikkarte würdet ihr wählen? Gibt es Erfahrungsberichte zur Funktionalität, Stabilität und allgemeinem Code- und Entwicklungszustand von ATI- und NVidia bei den offenen Treibern im Vergleich?

    Hat sich erledigt.



    War mal wieder Eset Endpoint AV für Linux. Update --> alles geht wieder.


    Man kann zwar Eset zugute halten, dass es bereits den ein oder anderen Drive-By-Download erkannt und von der Platte geräumt hat (allerdings waren diese Schädlinge für Windows optimiert und waren unter Linux nicht funktionsfähig). Und offiziell wird seit einiger Zeit Suse nicht mehr unterstützt...


    Aber dennoch: So, wie das Produkt umgesetzt ist, ist es unter Linux ja gemeingefährlich!

    Es ging schon zu Beginn der Nutzung los, dass Flatpak beim Update-Ziehen das System soweit runtergebremst hat, dass nur noch hartes Ausschalten half - solange der Eset-Service eea lief. Und in der Zeit war Suse sogar noch unterstützt. Wurde irgendwann durch ein Update von Eset behoben und sogar in den Changelogs benannt


    Jetzt hat es Python3 beim Linken gestört, sodass am Ende firewalld nicht mehr lief. Also hat es ein schweres Sicherheitsproblem aufgerissen!


    Man hat also eine schöne, openQA-getestete und auf Stabilität getrimmte Distribution wie Leap. Und dann kommt ein Closed-Source-Binary-AV-Programm daher und macht irgendwo in den Bibliotheken, die von den 2000 Paketen installiert wurden, einen Murks. In dem Fall sogar Murks, der sich sicherheitskritisch auswirkt und den man nur per Zufall entdeckt.


    Gerade weil auch der Flatpak-Bug offiziell war, frage ich mich inzwischen, ob es für einen AV-Hersteller überhaupt möglich sein kann, alle möglichen Konstellationen selbst bei nur einer oder zwei unterstützten Enterprise-Distributionen im Griff zu haben bzw. Regressionen zu vermeiden? Man hat ein definiertes und getestetes Distributions-"Gebäude", und durch irgendwelche Umstände reisst einem dann der AV wahllos irgendwelche Wandelemente raus...


    Nun, ich denke ich werde Eset dennoch bis zum bitteren Ende nächstes Jahr weiter nutzen (läuft ja wieder) und das Programm bei künftigen Problemen schneller als Ursache in Betracht ziehen. Dann kommt ja sowieso von openSUSE Leap 16 mit Containerarchitektur und es ist fraglich, ob sich das mit Eset betreiben lässt (evtl. mit hohem Aufwand). Da ich in den Eset-Foren zudem gelesen habe, dass das Tool derzeit nur bis Kernel 6.3 läuft, ist es ebenso fraglich, ob man es bis dahin mit Tumbleweed einsetzen kann.


    Wenn sich an der Virensituation unter Linux bis dahin nicht viel ändert, müsste es ja reichen, gelegentlich mit ClamAV irgendwelche Windows-Schädlingsleichen aus den Firefox-Ordnern zu putzen. Ansonsten wäre ich durchaus bereit, für einen guten und schnell aktualisierten Scanner auch Geld auszugeben. Wobei ich nach diesen Erfahrungen einen einfachen On-Demand-Scanner als Flatpak oder Appimage bevorzugen würde statt etwas, was sich als Service etc. tiefer ins System eingräbt.

    Ja, ich hatte mich mal vor längerer Zeit mit Python befasst und bei den Gehversuchen auch mit pip.


    Offenbar ist python3 insgesamt kaputt.


    Code
    @linux:~> python3
    python3: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

    Allerdings frage ich mich dann


    1. warum man etwaige Änderungen nicht mit einem Force-Reinstall der Pakete mit Zypper wieder Rückgängig gemacht bekommt.

    2. Wie man Python und Lehrbeispiele mit pip im Sinne deren Erfinder so nutzt, dass es einem das libpython-Linking des Systems nicht zersemmelt...? VM?


    Ich frage mich auch, ob folgendes Verhalten normal ist:

    Wenn ich das libpython3.6-Paket per Force-Install installiere, taucht die Datei libpython3.6m.so.1.0.so unter /usr/lib64 auf. Dann rufe ich z.B. python3 oder firewall-cmd im Terminal auf und bekomme einen "failed to map segment from shared object"-Fehler. Im gleichen Zuge verschwindet(!!) libpython3.6m.so.1.0.so aus dem Verzeichnis /usr/lib64.

    Bei nächsten Aufruf ist der Fehler dann logischerweise "cannot open shared object file". Ist das normal, dass ein fehlgeschlagenes Linken beim Aufruf eines Programms mit normalen User-Rechten zum Entfernen der Bibliothek in einem Systemverzeichnis führt? (ld?)

    Beim herumspielen mit firewall-cmd habe ich herausgefunden, dass es offenbar etwas mit Python 3 zu tun hat, und zwar mit libpython3_6m1_0.

    Code
    @linux:~> sudo firewall-cmd
    /usr/bin/python3: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory



    Erzwingt man die Installation von python3, python3-base und libpython3_6m1_0, startet immerhin der Service. Allerdings funktioniert firewall-cmd dennoch nicht richtig.


    Code
    sudo firewall-cmd
    /usr/bin/python3: error while loading shared libraries: libpython3.6m.so.1.0: failed to map segment from shared object

    Er scheint dann zwar die Bibliothek immerhin zu finden, hat aber ein Problem beim Einbinden.


    Wenn man anschließend wieder ein zypper in --force firewalld versucht, steht man wieder am Anfang, d.h. bei cannot open shared object file.

    Hallo,


    ich habe festgestellt, dass derzeit firewalld beim Systemstart mit einer Fehlermeldung abbricht.


    Code
    Jul 22 18:58:07 localhost systemd[1]: firewalld.service: Main process exited, code=exited, status=127/n/a
    Jul 22 18:58:07 localhost systemd[1]: firewalld.service: Failed with result 'exit-code'.
    Jul 22 18:58:07 localhost systemd[1]: Failed to start firewalld - dynamic firewall daemon.

    systemctl status firewalld.service:

    Code
    @linux:~> systemctl status firewalld.service
    × firewalld.service - firewalld - dynamic firewall daemon
         Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
         Active: failed (Result: exit-code) since Mon 2024-07-22 18:58:07 CEST; 12min ago
           Docs: man:firewalld(1)
        Process: 1155 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=127)
       Main PID: 1155 (code=exited, status=127)

    versucht habe ich noch

    Code
    rpm --rebuilddb
    zypper verify
    zypper install --force firewalld

    Die Befehle liefen offenbar problemlos durch inkl. firewalld-post-transaction-scripts und neuer Konfiguration. Aber das Problem besteht leider fort.

    Die Deutsche Flugsicherung war nach eigenen Angaben nicht von den Problemen betroffen:



    Zitat
    LANGEN (dpa-AFX) - Die IT-Systeme der Deutschen Flugsicherung sind nach eigener Aussage nicht von den weltweiten Computer-Problemen betroffen. Das sagte ein Unternehmenssprecher in Langen der Deutschen Presse-Agentur.

    Medienberichten zufolge wurde als Auslöser der Computer-Probleme ein Fehler in einem Programm-Update der IT-Sicherheitsfirma Crowdstrike vermutet. Die Deutsche Flugsicherung nutze aber eine andere Software, sagte der Sprecher weiter.

    Die DFS ist doch ein SUSE-Referenzkunde...


    Deutsche Flugsicherung
    Deutsche Flugsicherung
    www.suse.com


    Zero downtime since implementation gehalten.


    Eine andere Frage die mich im Zusammenhang mit den Clients interessieren würde: Wird im Unternehmenseinsatz SLED in der Regel genau wie Leap mit Snapper und GRUB-Bootmenü ausgerollt, oder stellt man das für Sekretärinnenrechner eher ab?