Eher nicht. Wäre ziemlich merkwürdig für ArchLinux oder muss man davon ausgehen, das ist bei euch auch so und als normal anzusehen?

    Berni341 muss man davon ausgehen, das ist bei euch auch so und als normal anzusehen?

    Nein, ist bei uns nicht so. Wenn es so wäre würden wir - falls wir bei systemd-analyze nichts Auffälliges sehen - die Ausgabe plus sonstige Log-Dateien hier posten um zu schauen, ob jemand anderem etwas auffällt. Da du diese Infos für dich behältst kannst auch nur du dir helfen.

    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.