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
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

Du könntest mal mit $ systemd-analyze blame und $ systemd-analyze critical-chain schauen wo es hakt, und dann das jeweilige log anschauen

Zeigt sich nichts Auffälliges.

  • schard hat auf diesen Beitrag geantwortet.

    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?