Leap42.2: Startverhalten ist mau && Networkmanager
- TuxSv748
- Geschlossen
- Erledigt
Hinweis: In dem Thema Leap42.2: Startverhalten ist mau && Networkmanager gibt es 69 Antworten auf 7 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
-
-
Code
Alles anzeigen$:> sudo zypper se -si apparmor audit root's password: Metadaten von Repository 'Hauptaktualisierungs-Repository' abrufen .....[fertig] Cache für Repository 'Hauptaktualisierungs-Repository' erzeugen ........[fertig] Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository --+--------------------------------+--------+---------------+--------+-------------------------------- i | apparmor | Schema | 20150918-25.1 | x86_64 | Haupt-Repository (OSS) i | apparmor-abstractions | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | apparmor-docs | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | apparmor-parser | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | apparmor-profiles | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | apparmor-utils | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | audit | Paket | 2.3.6-4.6 | x86_64 | Haupt-Repository (OSS) i | libapparmor-devel | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | libapparmor1 | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | libaudit1 | Paket | 2.3.6-4.52 | x86_64 | Haupt-Repository (OSS) i | libaudit1-32bit | Paket | 2.3.6-4.52 | x86_64 | Haupt-Repository (OSS) i | patterns-openSUSE-apparmor | Paket | 20150918-25.1 | x86_64 | Haupt-Repository (OSS) i | patterns-openSUSE-apparmor_opt | Paket | 20150918-25.1 | x86_64 | Haupt-Repository (OSS) i | perl-apparmor | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | python3-apparmor | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | yast2-apparmor | Paket | 3.1.3-6.1 | noarch | Haupt-Repository (OSS)
Es wird wohl versucht, sich mit einer SMB-Freigabe smb://x-gnome-default-workgroup/ zu verbinden. Das kostet Zeit.
woher kommt das? dürfte nicht von mir stammen!!!
-
Doch, in deinen Dateianhängen Post 11 (als user) und Post 13 (als root).
Die Ausgabe von journalctl -b -
Code
Alles anzeigen$:> sudo zypper se -si apparmor audit root's password: Metadaten von Repository 'Hauptaktualisierungs-Repository' abrufen .....[fertig] Cache für Repository 'Hauptaktualisierungs-Repository' erzeugen ........[fertig] Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository --+--------------------------------+--------+---------------+--------+-------------------------------- i | apparmor | Schema | 20150918-25.1 | x86_64 | Haupt-Repository (OSS) i | apparmor-abstractions | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | apparmor-docs | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | apparmor-parser | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | apparmor-profiles | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | apparmor-utils | Paket | 2.10.2-10.1 | noarch | Hauptaktualisierungs-Repository i | audit | Paket | 2.3.6-4.6 | x86_64 | Haupt-Repository (OSS) i | libapparmor-devel | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | libapparmor1 | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | libaudit1 | Paket | 2.3.6-4.52 | x86_64 | Haupt-Repository (OSS) i | libaudit1-32bit | Paket | 2.3.6-4.52 | x86_64 | Haupt-Repository (OSS) i | patterns-openSUSE-apparmor | Paket | 20150918-25.1 | x86_64 | Haupt-Repository (OSS) i | patterns-openSUSE-apparmor_opt | Paket | 20150918-25.1 | x86_64 | Haupt-Repository (OSS) i | perl-apparmor | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | python3-apparmor | Paket | 2.10.2-10.1 | x86_64 | Hauptaktualisierungs-Repository i | yast2-apparmor | Paket | 3.1.3-6.1 | noarch | Haupt-Repository (OSS)
woher kommt das? dürfte nicht von mir stammen!!!
Kannst du alles bis auf
löschen, siehe meine Ausgabe.
Und um ThomaS Verdacht zu bestätigen fehlt noch:
-
a) ich meinte dass der Zugriff auf die SMB Freigabe nicht von mir eingerichtet wurde, die scheint systembedingt vorhanden zu sein
b) das Löschen der Armor Pakete würde ich gerne etwas verschieben, wollte zunächst meine andere Platte booten und zum Vergleich posten wie dort gebootet wird
Code
Alles anzeigen$:> zypper se -si gvfs .. Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository --+--------------------+-------+------------+--------+----------------------- i | gvfs | Paket | 1.28.3-2.2 | x86_64 | Haupt-Repository (OSS) i | gvfs-backend-afc | Paket | 1.28.3-2.2 | x86_64 | Haupt-Repository (OSS) i | gvfs-backend-samba | Paket | 1.28.3-2.2 | x86_64 | Haupt-Repository (OSS) i | gvfs-backends | Paket | 1.28.3-2.2 | x86_64 | Haupt-Repository (OSS) i | gvfs-fuse | Paket | 1.28.3-2.2 | x86_64 | Haupt-Repository (OSS) i | gvfs-lang | Paket | 1.28.3-2.2 | noarch | Haupt-Repository (OSS)
-
Nein. Funktioniert ohne Probleme. Also kein Bug.
Code
Alles anzeigensystemd-analyze blame 4.098s systemd-journal-flush.service 3.607s dev-sda3.device 2.030s ModemManager.service 1.837s SuSEfirewall2_init.service 1.582s tpdaemon.service 1.384s display-manager.service 1.275s systemd-udevd.service 1.249s postfix.service 1.154s SuSEfirewall2.service 1.151s polkit.service 768ms alsa-restore.service 715ms ntpd.service 656ms avahi-daemon.service
Wie man sieht, sieht man von apparmor nichts mehr.
-
nicht ganz, aktuell ist:
Code
Alles anzeigen> systemd-analyze blame 27.307s apparmor.service 20.593s dev-sdb3.device 13.663s systemd-udevd.service 9.519s SuSEfirewall2_init.service 9.167s ModemManager.service 6.698s libvirtd.service 6.006s vboxdrv.service 5.825s display-manager.service 5.079s boot-efi.mount 4.805s nscd.service 4.622s systemd-fsck@dev-disk-by\x2duuid-75c2f1b7\x2d9265\x2d4a7a\x2da4 4.504s systemd-backlight@backlight:acpi_video0.service 4.327s polkit.service 4.046s systemd-journal-flush.service 3.736s postfix.service 3.572s SuSEfirewall2.service 1.339s NetworkManager.service 1.291s dev-disk-by\x2duuid-e8bb3e6e\x2d2061\x2d4bc9\x2da565\x2dc7d2e8c 1.132s systemd-logind.service 998ms fstrim.service 859ms ntpd.service 852ms systemd-journald.service 849ms home.mount 820ms boot-grub2-x86_64\x2defi.mount 818ms tmp.mount 817ms usr-local.mount 760ms boot-grub2-i386\x2dpc.mount 739ms opt.mount 659ms var-spool.mount 648ms srv.mount 627ms vboxballoonctrl-service.service 621ms var-tmp.mount 620ms var-lib-mysql.mount 598ms user@1000.service 590ms vboxautostart-service.service 579ms var-cache.mount 556ms var-log.mount 537ms systemd-remount-fs.service 517ms sys-kernel-debug.mount 517ms dev-mqueue.mount 517ms dev-hugepages.mount 514ms avahi-daemon.service 513ms systemd-user-sessions.service 507ms var-lib-mailman.mount 492ms var-opt.mount 490ms var-lib-libvirt-images.mount 466ms var-lib-mariadb.mount 462ms systemd-sysctl.service
-
USB Festplatte beim Start angeschlossen?
Befasse dich mit systemd:
status kann man ersetzen durch:start = starten
restart = neu starten
stop = stoppen
enable = beim Systemstart mitstarten
disable = den Start beim Systemstart nicht ausführen -
es ist eine Platte fest verbaut, eine weitere kann durch einen Einschub mit eingebunden werden, ist momentan aber nicht drin. Des Weiteren boote ich von einer per Einschub eingelegten SSD die ich entsprechend zw. meiner alten und der jetzigen Wechsel.
hab apparmor mal disabled und werde neu booten
Code
Alles anzeigen> systemd-analyze blame 4.541s systemd-journal-flush.service 4.293s libvirtd.service 4.023s SuSEfirewall2_init.service 3.967s display-manager.service 2.947s SuSEfirewall2.service 2.435s dev-sdb3.device 2.347s postfix.service 2.342s nscd.service 2.261s rc-local.service 2.245s avahi-daemon.service 2.016s ntpd.service 1.611s ModemManager.service 1.328s vboxdrv.service 1.236s home.mount 1.160s boot-efi.mount 981ms systemd-fsck@dev-disk-by\x2duuid-75c2f1b7\x2d9265\x2d4a7a\x2da4 780ms var-crash.mount 779ms var-lib-pgsql.mount 778ms var-cache.mount 778ms var-lib-mariadb.mount 765ms systemd-udevd.service 752ms var-log.mount 736ms opt.mount 663ms boot-grub2-i386\x2dpc.mount 645ms boot-grub2-x86_64\x2defi.mount 586ms polkit.service 575ms systemd-remount-fs.service 574ms plymouth-read-write.service 568ms dev-hugepages.mount 567ms dev-mqueue.mount 566ms sys-kernel-debug.mount 563ms usr-local.mount 517ms var-spool.mount 479ms tmp.mount 478ms var-lib-machines.mount 478ms var-lib-named.mount 451ms NetworkManager.service 430ms var-lib-mailman.mount 420ms rtkit-daemon.service 383ms var-lib-mysql.mount 377ms systemd-backlight@backlight:acpi_video0.service 369ms auditd.service 360ms upower.service 358ms systemd-journald.service 336ms var-lib-libvirt-images.mount 335ms srv.mount 295ms \x2esnapshots.mount 268ms systemd-modules-load.service 267ms systemd-udev-root-symlink.service 266ms kmod-static-nodes.service 230ms systemd-logind.service 227ms var-opt.mount 227ms systemd-sysctl.service ...
sieht zahlenmäßig besser aus, gefühlt bringt es nicht so viel, kann immer noch zusehen wie die Animation abläuft ... gefühlt ein paar sek weniger
-
Sieht doch gut aus. Was willst du eigentlich? Booten in 2 Sekunden? Was soll der Unsinn? Hast du so wenig Zeit?
Gesendet von meinem SM-T530 mit Tapatalk