Gut, dann schauen wir doch mal, ich bitte um Beurteilung der Ergebnisse. Allerdings weiss ich nicht, was "sonstige Log-Dateien" sein sollen.

  1. systemd-analyze blame
2.098s systemd-rfkill.service
 809ms dev-sda2.device
 555ms ldconfig.service
 363ms systemd-journal-catalog-update.service
 235ms user@1000.service
 228ms systemd-journal-flush.service
 224ms systemd-udev-trigger.service
 200ms udisks2.service
 181ms systemd-tmpfiles-setup.service
 160ms systemd-tmpfiles-setup-dev.service
 148ms systemd-remount-fs.service
 140ms systemd-modules-load.service
 132ms systemd-udevd.service
 127ms modprobe@loop.service
 118ms upower.service
 118ms modprobe@fuse.service
 117ms systemd-timesyncd.service
 111ms modprobe@drm.service
 103ms systemd-boot-random-seed.service
 102ms modprobe@dm_mod.service
  95ms systemd-vconsole-setup.service
  91ms modprobe@configfs.service
  89ms kmod-static-nodes.service
  86ms cups.service
  85ms systemd-update-utmp.service
  83ms polkit.service
  82ms systemd-sysusers.service
  81ms dev-hugepages.mount
  78ms systemd-tmpfiles-clean.service
  78ms dev-mqueue.mount
  75ms systemd-journald.service
  73ms sys-kernel-debug.mount
  70ms sys-kernel-tracing.mount
  63ms systemd-zram-setup@zram0.service
  61ms accounts-daemon.service
  59ms systemd-sysctl.service
  46ms dbus.service
  46ms NetworkManager.service
  45ms dev-zram0.swap
  39ms systemd-update-done.service
  39ms systemd-logind.service
  32ms user-runtime-dir@1000.service
  29ms systemd-random-seed.service
  26ms boot.mount
  25ms sys-fs-fuse-connections.mount
  23ms systemd-user-sessions.service
  17ms sys-kernel-config.mount
  12ms rtkit-daemon.service
   6ms tmp.mount
  1. systemd-analyze critical-chain

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @3.009s
└─multi-user.target @3.008s
└─cups.service @2.921s +86ms
└─network.target @2.920s
└─NetworkManager.service @2.873s +46ms
└─dbus.service @2.800s +46ms
└─basic.target @2.766s
└─sockets.target @2.766s
└─dbus.socket @2.766s
└─sysinit.target @2.761s
└─systemd-vconsole-setup.service @3.711s +95ms
└─systemd-journald.socket @997ms
└─system.slice @940ms
└─-.slice @940ms

Das Aktivieren der Netzwerkverbindung dauerte in diesem, wie in jedem Fall wie oben im ersten Beitrag beschrieben, so lange.

    Berni341 Allerdings weiss ich nicht, was "sonstige Log-Dateien" sein sollen.

    zB die gewünschte Ausgabe vonjounalctl -h

    Und setze diese Ausgaben bitte in Code-Tags (unter dem Schreibfenster entweder direkt </> anklicken und zwischen die Tags schreiben oder besser den Teil markieren und dann auf </> klicken)

    Zudem wäre für obige Ausgaben noch interessant ob das aktivieren wieder so lange gedauert hat

      Ist das ein Laptop? Brauchst du den rfkill-Service? Sonst diable den doch mal und versuche, das Problem nachzustellen.

      • Berni341 hat auf diesen Beitrag geantwortet.

        stefanhusmann
        Bitte den Befehl gleich mit dazu schreiben. Habe (Arch)Linux erst installiert und kenne es bis dato kaum.
        Es handelt sich um einen Mini-PC von HP.

          Josephus Miller
          Das war bestimmt nicht, was du sagen/sehen wolltest. Ich würde mal journalctl -b probieren (vorausgesetzt, die Netzwerkverbindung wird nicht erst nach dem Boot manuell hergestellt).

          Berni341 Habe (Arch)Linux erst installiert und kenne es bis dato kaum.

          Beim Installieren sollte dir dann aber systemctl enable <service> begegnet sein, logischerweise heißt es dann

          sudo systemctl disable systemd-rfkill.service

          Die Option -h oder --help zeigt dir die Kurzform der manpage eines Befehls oder Programms. Daher hast du dir die Optionen zeigen lassen. ;-) Du könntest zB neustarten und dann alles nach dem aktuellen boot mit journalctl -b anzeigen lassen

          • Berni341 hat auf diesen Beitrag geantwortet.

            Josephus Miller
            Das sind bei "journalctl -b" über 1500 Zeilen und wie ich gerade sah, sind oben in der Konsole bereits Zeilen abgeschnitten. Sind alle nötig und, wenn ja, wie kann das Abschneiden oben verhindert werden?

              Berni341 Sind alle nötig und, wenn ja, wie kann das Abschneiden oben verhindert werden?

              Wenn du die Verbindung nicht nach dem booten manuell herstellst sind alle nötig. Und das Abschneiden verhinderst du über die Einstellung der verwendeten Konsole

              Forum meldet:
              content darf maximal 65535 Zeichen enthalten.
              Kann man den erforderlichen Inhalt nicht irgendwie filtern?

              Ok, verteile die Zeilen über mehrere Beiträge. Ab hier vor Netzwerkzugriff:

              del

              und weiter...

              del
              • brikler hat auf diesen Beitrag geantwortet.

                und weiter...

                del

                Ich sehe da keine Fehler, wenn ich das nicht falsch lese braucht deine Netzwerkkarte nach dem Start aber ca 90 sec bis sie aktiv ist. Allerdings stellt sich mir die Frage, wozu du bei ner kabelgebundenen Verbindung den NetworkManager brauchst. Und den rfkill-service hattest du nicht wie von Stefan empfohlen deaktiviert, oder?

                Danke fürs Drübergucken. Die Daten sind natürlich alle ohne Fehlerbehandlung ausgelesen. Den Networkmanager habe ich für KDE (siehe erster Post). Jetzt kann es dann daran gehen, in der Hoffnung, es ändert sich was. Falls noch jemand Vorschläge hat, bitte reinschreiben.

                Wenn ich sudo systemctl disable systemd-rfkill.service ausführen will, bekomme ich das:

                The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
                Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
                template units). This means they are not meant to be enabled or disabled using systemctl.
                 
                Possible reasons for having this kind of units are:
                • A unit may be statically enabled by being symlinked from another unit's
                  .wants/ or .requires/ directory.
                • A unit's purpose may be to act as a helper for some other unit which has
                  a requirement dependency on it.
                • A unit may be started when needed via activation (socket, path, timer,
                  D-Bus, udev, scripted systemctl call, ...).
                • In case of template units, the unit is meant to be enabled with some
                  instance name specified.

                Ich starte meine Netzwerkverbindung unter Plasma/KDE mit systemct start dhcpcd@enp5s0.service, ohne Networkmanager. Bei dir wäre das wohl dhcpcd@eno1.service, Sicherheit gibt ein Blick auf die Ausgabe von ip link. Du müsstest dann aber den NetworkManager.service deaktivieren.
                Eventuell erledigt sich dann auch das Starten von rfkill

                Werde ich ausprobieren. Was ich auch überhaupt nicht verstehe, ist diese Unregelmässigkeit der Zeit bis zur Netzwerkaktivität. Mal ist das Netzwerk direkt nach Boot da (selten), wie es sein sollte und mal sitzt man da und wartet ca. 3 bis 4 Minuten, bis sich etwas tut. Und alles zeitlich dazwischen ist auch möglich.

                edit: Mit dhcpcd genau dasselbe. Zunächst NetworkManager deaktiviert, dhcpcd aktiviert ("enable" und "start"), beim Neustart dann Wartezeit bis Timeout - danach kein Netzwerk. Habe dann nicht mehr abgewartet, ob es sich nach einer gewissen Zeit wieder selbst aktiviert.

                edit2: vielleicht ist das noch interressant, nach Re-Aktivierung von Networkmanager wirft nmcli folgendes aus:
                Netzwerk nicht aktiv:
                NetworkManager is running
                Nach ca. 2 Minuten warten - ab hier wird Netzwerkverbindung aufgebaut:

                eno1: nicht verbunden
                eno1: Verbindung »Kabelgebundene Verbindung 1« wird verwendet
                eno1: wird verbunden (wird vorbereitet)
                NetworkManager ist jetzt im Zustand »wird verbunden«
                eno1: wird verbunden (wird eingerichtet)
                eno1: wird verbunden (IP-Einstellungen werden ermittelt)
                »Kabelgebundene Verbindung 1« ist jetzt die primäre Verbindung
                eno1: wird verbunden (IP-Funktionalität wird geprüft)
                eno1: wird verbunden (Zweitverbindungen werden gestartet)
                eno1: verbunden
                NetworkManager ist jetzt im Zustand »verbunden (nur Gelände)«
                Verbindungszustand ist jetzt »begrenzt«
                NetworkManager ist jetzt im Zustand »verbunden«
                Verbindungszustand ist jetzt »vollständig«

                Hier ist mir eine Diskrepanz aufgefallen. Erst wenn nach Wartezeit die Verbindung aufgebaut wird, erscheint die Meldung "eno1: nicht verbunden", zuvor ist nur "NetworkManager is running" zu sehen. Es scheint, als ob ein (anderer?) Service/Prozess diese Zeit braucht, bevor die Netzwerkverbindung steht. Sonst stünde doch das "eno1: nicht verbunden" schon von Anfang an da und nicht erst ab dem Zeitpunkt, ab dem die Verbindung aktiv wird. Vielleicht ist das alles aber auch nur Kaffeesatzleserei.

                Ohne konkret zum Problem beitragen zu wollen:

                Am interessantesten wäre wohl ein Logfile von einem Zustand in dem das "Aktivieren" des Netzwerks extrem lange ("mal sitzt man da und wartet ca. 3 bis 4 Minuten") dauerte. Am besten - wenn das wieder mal auftritt - merkst du dir Tag/Uhrzeit. Wenn du dann neu bootest kommst du an das komplette Journal für den vorherigen Boot(mit dem Problem) mittels:
                journalctl --system --boot -1
                (oder -2, -3 noch weiter zurück). Eine Liste der letzten Bootvorgänge bekommst du mit:
                journalctl --list-boots
                (ggf. sudo verwenden für die Kommandos falls nicht als root unterwegs)

                Du hast gesehen welchen Aufwand es bedarf ein Journal zu posten. Außerdem fehlen bei dir Teile (an den "Enden" der Zeilen, da du aus dem sog. Pager rauskopiert hast.
                Einfacher geht das mittels eines sog. Pastebin-Services, siehe im Wiki:
                https://wiki.archlinux.org/title/List_of_applications#Pastebin_services
                Auch lange/komplexe Programmausgaben lassen sich so einfacher für alle handhaben.
                Um z.B. das komplette Journal vom letzten Boot zur Verfügung zu stellen:
                journalctl --system -b -1 | curl -F 'file=@-' 0x0.st
                (//Edit: Das Tool/Paket curl muß evtl. nachinstalliert werden falls nicht vorhanden)
                Du erhältst dann eine URL, die du dann in deinem Post reinstellen kannst nebst ggf. anderen Infos. Keine Notwendigkeit, überlange Texte mühsam zu kopieren.

                Nachtrag zum ersten Post deinerseits:
                Diese "lange Wartespanne": bezieht die sich auf das "visuelle Bereitmelden" vom Networkmanager-Applet? Schonal getestet (ping z.B.) ob die Verbindung nicht doch schon während dieser "visuellen Problemphase" aktiv ist?

                Ggf. auch interessant (obwohl schon mal angesprochen): konkurrierende Dienste. Was sagt:
                find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

                • Berni341 hat auf diesen Beitrag geantwortet.

                  GerBra
                  Danke für die Tipps, werde sie nutzen.
                  Die Wartespanne bis zur vorhandenen, aktiven Verbindung ist kein visueller Fehler, die Verbindung ist tatsächlich so lange nicht da, wie sie auch als visuell "nicht verfügbar" gekennzeichnet ist. Das habe ich bereits mehrfach getestet.
                  Der Aufruf von...
                  find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
                  ... führt zu:

                  cups.path                                | multi-user.target.wants
                  cups.service                             | multi-user.target.wants
                  cups.service                             | printer.target.wants
                  cups.socket                              | sockets.target.wants
                  dbus-org.freedesktop.nm-dispatcher.service | system
                  dbus-org.freedesktop.timesync1.service   | system
                  display-manager.service                  | system
                  fstrim.timer                             | timers.target.wants
                  gcr-ssh-agent.socket                     | sockets.target.wants
                  getty@tty1.service                       | getty.target.wants
                  gnome-keyring-daemon.socket              | sockets.target.wants
                  NetworkManager.service                   | multi-user.target.wants
                  NetworkManager-wait-online.service       | network-online.target.wants
                  nic-speed-fix.service                    | multi-user.target.wants
                  p11-kit-server.socket                    | sockets.target.wants
                  pipewire-pulse.socket                    | sockets.target.wants
                  pipewire-session-manager.service         | user
                  pipewire.socket                          | sockets.target.wants
                  remote-fs.target                         | multi-user.target.wants
                  systemd-timesyncd.service                | sysinit.target.wants
                  wireplumber.service                      | pipewire.service.wants
                  xdg-user-dirs-update.service             | default.target.wants

                  Gut, also - wie du weiter oben schon mal angeführt hast - es gibt keine konkurrierenden Netzwerk-Dienste.

                  Wir bräuchten aber wirklich ein komplettes Journal von einem Boot bei dem das Problem "mit erheblicher Verzögerung" aufgetreten ist. Am besten also wie von mir ausgeführt warten bis das Problem auftritt, rebooten, und dann das letzte Journal (b -1) per pastebin ablegen.
                  Diese Verzögerung sollte - sofern Netwokmanager ggf. die Ursache wäre - im Log ersichtlich sein, hoffentlich mit hilfeführenden Meldungen oder Kontext.

                  Zum "Rumtesten" haben dir ja andere auch schon zu einem anderen Netzwerk-Manager geraten, das wäre sicher eine Möglichkeit, gerade wenn es sich um eine feste, stationäre Ethernet-Verbindung dreht. Ich sehe allerdings bisher keinen Grund, warum Network-Manager das nicht (auch) fehlerfrei können müßte.

                  Als anderen Test (mit dem gleichen momentanen Setup) wäre auch möglich, den LTS-Kernel parallel zum Standard-Kernel zu installieren und mit diesem eine Zeitlang zu testen ob das Problem da auch auftritt.

                  Ich hab mal die von dir geposteten Journalteile überflogen, das war aber ja wohl von einem Lauf ohne das Problem. Was mir darin aufgefallen ist bzw. Fragen dazu:

                  a) Nutzt du aktiv eine Firewall auf dem PC?
                  "Aug 24 17:58:48 archlinux firewall-applet[814]: Traceback (most recent call last):"
                  Kannst du dieses Applet mal deaktivieren und prüfen ob sich am Verhalten bzgl. Netzwerk-Zugriffszeit was ändert?

                  b) Poste bitte mal die Ausgabe von:
                  pacman -Qs xdg-desktop-portal

                  Und zur Sicherheit:
                  Das Paket linux-firmware ist installiert?
                  Verwendest du irgendwelche "Sicherheitskonzepte" wie MAC-Changer, am Router nur bestimmte MAC-Adressen zugelassen o.ä. ?
                  Ist auf dem Rechner auch ein Windows installiert?

                  • Berni341 hat auf diesen Beitrag geantwortet.