Jetzt wüsste natürlich jeder hier gerne, welches Kuckucksei die Fritzbox 7360 da ins Arch Nest gelegt haben könnte. Sind inzwischen wirklich alle Anwendungen wieder wie vor installiert oder ist das lediglich ein Zwischenbericht?

  • pix hat auf diesen Beitrag geantwortet.

    Archibaldo Jetzt wüsste natürlich jeder hier gerne, welches Kuckucksei die Fritzbox 7360 da ins Arch Nest gelegt haben könnte.

    Ja, das wüsste ich auch gerne. Ja,es waren alle Anwendungen betroffen welche unter X liefen, zb auch Blender bei mir.
    Es lag aber nicht an XFCE4 oder der Anwendung selbst. Hatte den NetworkManager deinstalliert und wieder neu installiert. Kein Erfolg

    Im Moment ist es reine Spekulation oder ein Blick in die Glaskugel woran es lag. Jedenfalls hat es ziemlich viel Zeit und Nerven gekostet

    • forty hat auf diesen Beitrag geantwortet.

      Solche Effekte tauchen mitunter auf wenn die resolv.confnicht passt oder allgemein das "interne" Routing in irgend einer Form seltsam ist. X baut da drauf.
      Ich würde da weniger auf die FritzBox tippen, eher auf die Netzwerkkonfig (wie auch immer die aussah).

      pix

      hallo,

      fast gleiches hab ich hier auch.

      Seit dem Probieren mit openbsd in der kvm mit virt-manager startet nun Thunderbird nur noch extrem langsam. Braucht so um die 4-5 Minuten. Gehe ich Offline startet TB ganz normal. Mit YaY etwas installieren geht nur noch so. yay -S $prog dann off gehen weil es stehen bleibt (offline läuft es dann) und wieder on damit es weiter geht.
      resolv.conf , hosts und übliche Verdächtige sind nicht verändert.

      Alles andere geht so weit...
      Überhaupt keinen Ansatzpunkt wo ich da gucken sollte....
      Am einfachsten wird sein, ich setzte wohl auch alles neu auf.

      Tipps willkommen :-)

        Mach zunächst bitte einen neuen Thread auf. Ein

        forty Probieren mit openbsd in der kvm mit virt-manager

        ist jedenfalls eine andere Ursache als ein neuer Router.

        • forty hat auf diesen Beitrag geantwortet.

          stefanhusmann

          Ja ok.
          Aber gleiches, oder fast gleiches Fehlerbild.

          • forty hat auf diesen Beitrag geantwortet.

            forty

            Problem gelöst.

            ein "jetzt" einfaches

            ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resonv.conf

            hat mein Problem gelöst.
            Sieht tatsächlich nun etwas anders aus als das was sonst drin stand.

              forty

              Hm. Nenn mich kleinlich, aber da ist doch ein Schreibfehler in deiner Befehlszeile, oder?

              Wird die /etc/resolv.conf nicht sowieso automatisch erzeugt? (nicht hauen, wenn das falsch ist; bin mir gerade nicht ganz sicher)

              Ciao,
              Photor

              • forty hat auf diesen Beitrag geantwortet.

                Photor
                Jo, Schreibfehler :-)
                Bei mir wurde die auch vom NetworkManager erstellt, nur klappte die aus unbekannten Gründen nicht mehr.

                • Photor hat auf diesen Beitrag geantwortet.

                  @forty
                  Schön das du einen besseren Weg gefunden hast als ich :-)

                  Den Tipp von @chepaz mit der resolv.conf hatte ich zu spät erhalten, zu dem Zeitpunkt hatte ich mein System schon neu aufgesetzt.

                  forty Genau. So ist das bei mir wohl auch.

                  Also besser nicht direkt drin rum wühlen; wird bei nächster Gelegenheit sowieso wieder überschrieben.

                  PS: mein Lappy holt sich diese ganzen Infos eh mittels DHCP vom Router (= FritzBox oder dem PiHole); wenn da was anzupassen ist, dann da.

                  Ciao,
                  Photor

                  - cat /etc/resolv.conf
                  # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
                  # Do not edit.
                  #
                  # This file might be symlinked as /etc/resolv.conf. If you're looking at
                  # /etc/resolv.conf and seeing this text, you have followed the symlink.
                  #
                  # This is a dynamic resolv.conf file for connecting local clients to the
                  # internal DNS stub resolver of systemd-resolved. This file lists all
                  # configured search domains.
                  #
                  # Run "resolvectl status" to see details about the uplink DNS servers
                  # currently in use.
                  #
                  # Third party programs should typically not access this file directly, but only
                  # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
                  # different way, replace this symlink by a static file or a different symlink.
                  #
                  # See man:systemd-resolved.service(8) for details about the supported modes of
                  # operation for /etc/resolv.conf.

                  Administrativer Edit: Bitte Code in Code-Blöcken im Forum einbinden, ich habs mal angepasst. Ist leider nicht so intuitiv, aber es steht alles hier 🙂