Manjaro Start sehr langsam

[Infect007]

Hi,
meinen wirklich alten, nicht mehr benutzten Laptop nutze ich mit Linux.
Früher Hatte ich immer Linux Mint drauf, gestern habe ich mal Manjaro ausprobiert.
Was mir bei Mint sowie bei Manjaro auffiel ist der sehr langsame Start.
Gestern nach der Installation und der ersten Updatewelle, hatte ich ziemlich genau 2 Minuten gebraucht.

Liegt das einfach an der sehr schwachen Hardware oder könnte ich noch irgendetwas beschleunigen?
Ich habe extra eine ältere nicht mehr benötigte SSD nachgerüstet, jedoch brachte das auch nicht wirklich viel...

Specs:
Manjaro XFCE/Mint Cinnamon
Acer Aspire 5742 (i5-450M, 2x2GB RAM, HD5470, 250GB SSD(nachgerüstet))

 

[tony_mont4n4]

Hi,

also mein Mint braucht auch mit SSD relativ lang zum booten, denke aber eher es liegt am BIOS und den Controllern.

Arch sollte eigentlich schnell booten und sooo schlecht is die Hardware ja nicht.

Hast mal deine SSD geprüft mit den smartctl Tools?

 

[Muffknutscher]

Moin,

nimm ein Bodhi oder Puppy Linux für die den alten Laptop. Man kann alles was man benötigt nachinstallieren. Der Laptop ist 10 Jahre alt, da sollte man keine Wunder erwarten, auch nicht mit Linux.

 

[JimPanse1984]

Ich z.B nutze auf einem Lenovo Ideapad 110 (Pentium mit ATOM Kernen) Manjaro KDE und dem Kernel 5.2-8.1

Boot dauert mit SSD keine 17 Sekunden. Auf dem gleichen Gerät braucht Windows 10 trotz SSD 45 Sekunden bis alles fertig geladen ist. Und generell ist Windows 10 extrem träge und lahm, wegen den 4GB und Manjaro zischt ab wie eine Rakete.

Ich glaube nicht, dass deine CPU soviel langsamer ist, als mein 2016er Pentium, der eigentlich ein Atom ist (Braodwell) Also muss das andere Gründe haben. Am RAM sollte es auch nicht liegen, mein Ideapad hat selbst nur 4GB

Vielleicht hilft ein Kernel wechsel ja schon!

 

[d3nso]

Also 2 Minuten sind schon sehr viel für Manjaro, mein Betagtes Linux Notebook mit T7700, 3GB DDR2 und 500gb SSD ist nach nicht einmal 30sek oben. Nutze ebenfalls XFCE.

 

[Infect007]

Also ich weiß, dass der Laptop einfach schon sehr alt ist und man da auch keine Wunder erwarten sollte, jedoch finde ich 2 Minuten einfach zuviel. Mit HDD okay, aber ne SSD sollte da trotz alter Hardware flotter sein.

Hast mal deine SSD geprüft mit den smartctl Tools?

Werde ich heute Abend mal testen.

Boot dauert mit SSD keine 17 Sekunden.

Also 2 Minuten sind schon sehr viel für Manjaro, ...

Das bestätigt ja irgendwie meine Vermutungen, dass da irgendwas nicht stimmt.

Vielleicht hilft ein Kernel wechsel ja schon!

Also einfach mal auf einen älteren Kernel gehen?
Könnte ich heute Abend mal probieren.

 

[JimPanse1984]

Wenn du den neuesten installiert hast über den Manjaro Manager, dann den LTS testen, oder den 5.3er (Wobei laut der Manjaro Seite gewisse neuere Kernel noch keine AMD Treiberunterstützung bieten).

Ich glaube ja, für deine alte RADEON funktionieren die "neuen" OpenSource Treiber nicht, oder? Du wirst ja auf die Radeon Kernel Module angewiesen sein.
Am besten im Manjaro Forum nachlesen und die Kernel durch-testen.

Bei mir läuft der 5.2er am schnellsten -> Auch auf meinem PC mit Haswell Core i5.


EDIT: Wobei es auch darauf ankommt, ob du die Partitionen mit LUKS verschlüsselt hast, oder nicht. Ich nutze keinerlei Verschlüsselung. Mit dauert der Bootvorgang je nach alter des Geräts natürlich um einiges länger. Aber länger als 1 ;Minute sollte es dennoch nicht dauern.

 

[snaxilian]

Welcher Prozess genau den Startvorgang verlangsamt kannst du gut mit Bordmitteln heraus finden:
sudo systemd-analyze blame zeigt dir an welche Prozesse wie lange benötigten. Willst du dann noch die Abhängigkeiten des Prozesses heraus finden der am längsten benötigst kannst du dies mit sudo systemd-analyze critical-chain. Dann weißt du immerhin, woran es liegt und kannst dich mit der Behebung des "Problems" beschäftigen bzw. gucken ob und wie man dies optimieren kann.

 

[Infect007]

Ich glaube ja, für deine alte RADEON funktionieren die "neuen" OpenSource Treiber nicht, oder? Du wirst ja auf die Radeon Kernel Module angewiesen sein.

Wenn du die neuen AMD Open Source Driver for Vulkan meinst, nein die unterstützen leider erst ab HD7000.

Wobei es auch darauf ankommt, ob du die Partitionen mit LUKS verschlüsselt hast, oder nicht.

Habe keine Verschlüsselung bei mir

Wenn du den neuesten installiert hast über den Manjaro Manager, dann den LTS testen, oder den 5.3er
Am besten im Manjaro Forum nachlesen und die Kernel durch-testen.
Bei mir läuft der 5.2er am schnellsten -> Auch auf meinem PC mit Haswell Core i5.

Werde ich mal testen, danke

Welcher Prozess genau den Startvorgang verlangsamt kannst du gut mit Bordmitteln heraus finden:
sudo systemd-analyze blame zeigt dir an welche Prozesse wie lange benötigten. Willst du dann noch die Abhängigkeiten des Prozesses heraus finden der am längsten benötigst kannst du dies mit sudo systemd-analyze critical-chain. Dann weißt du immerhin, woran es liegt und kannst dich mit der Behebung des "Problems" beschäftigen bzw. gucken ob und wie man dies optimieren kann.

Super, vielen Dank, ich glaube damit könnte ich dem Problem schon mal ein bisschen näher kommen

 

[DickeHupen]

Meistens hängt es an der Netzwerkkarte oder am W-Lan Modul, das systemd beim starten nicht korrekt arbeitet.

Bin gespannt ob du was analysieren kannst.

Ansonsten eine Distribution mit anderer Init software versuchen.

 

[snaxilian]

Genau so gut kann es an unattended-updates hängen oder wenn beim Start entfernte Dateisysteme/Freigaben gemountet werden sollen und diese nicht zur Verfügung stehen oder oder oder, die Liste ist beliebig erweiterbar. Vielleicht sollten wir weniger mutmaßen und irgendwelche Dinge in den Raum werfen und uns auf die Fakten konzentrieren falls der TE diese liefert/liefern möchte.

 

[Infect007]

Genau so gut kann es an unattended-updates hängen oder wenn beim Start entfernte Dateisysteme/Freigaben gemountet werden sollen und diese nicht zur Verfügung stehen oder oder oder, die Liste ist beliebig erweiterbar. Vielleicht sollten wir weniger mutmaßen und irgendwelche Dinge in den Raum werfen und uns auf die Fakten konzentrieren falls der TE diese liefert/liefern möchte.

Danke!
Sobald ich zuhause bin werde ich versuchen die Fakten zu liefern.
Aktuell bin ich leider auf der Arbeit.
Ich werde es mit den Befehlen aus Post #8 versuchen und hoffe dass mich das weiter bringt

 

[lokon]

Mal gegooglet und aus https://wiki.archlinux.org/index.php/Improving_performance/Boot_process

systemd-analyze und systemd-analyze blame
und die anderen Befehle liefern vielleicht genügen echte Informationen über den Zeitverbrauch beim Booten.

Du kannst dann die Ausgabe posten - vielleicht steht etwas interessantes drin.

 

[Ratz_Fatz]

Helfen kann auch folgendes, einfach mal schauen ob da was auffällig ist.

sudo systemctl --failed

oder

sudo dmesg -x -l crit,err,warn

 

[Infect007]

So, hier die versprochenen Ergebnisse

Welcher Prozess genau den Startvorgang verlangsamt kannst du gut mit Bordmitteln heraus finden:
sudo systemd-analyze blame

Spoiler

2.988s upower.service
890ms tlp.service
786ms lvm2-monitor.service
690ms dev-sda1.device
640ms systemd-logind.service
579ms lightdm.service
333ms systemd-udevd.service
289ms systemd-journald.service
289ms ModemManager.service
262ms udisks2.service
178ms polkit.service
152ms user@1000.service
110ms NetworkManager.service
109ms systemd-rfkill.service
104ms systemd-journal-flush.service
102ms systemd-udev-trigger.service
86ms avahi-daemon.service
68ms grub-boot-indeterminate.service
34ms systemd-tmpfiles-setup.service
30ms systemd-user-sessions.service
30ms systemd-modules-load.service
29ms org.cups.cupsd.service
28ms systemd-tmpfiles-setup-dev.service

sudo systemd-analyze critical-chain.

Spoiler

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 @1.933s
└─lightdm.service @1.353s +579ms
└─systemd-user-sessions.service @1.320s +30ms
└─nss-user-lookup.target @1.855s

sudo systemctl --failed

0 loaded units listed

sudo dmesg -x -l crit,err,warn

Eine ganze Menge:

Spoiler

kern :warn : [ 0.342314] core: CPUID marked event: 'bus cycles' unavailable
kern :warn : [ 0.422450] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
kern :warn : [ 0.462299] #2 #3
kern :warn : [ 0.512426] mtrr: your CPUs had inconsistent variable MTRR settings
kern :warn : [ 1.007316] pnp 00:00: disabling [io 0x164e-0x164f] because it overlaps 0000:00:1c.1 BAR 13 [io 0x1000-0x1fff]
kern :warn : [ 2.020645] ata1.00: supports DRM functions and may not be fully accessible
kern :warn : [ 2.045853] ata1.00: supports DRM functions and may not be fully accessible
kern :warn : [ 4.173508] wmi_bus wmi_bus-PNP0C14:00: WQXM data block query control method not found
kern :warn : [ 4.260647] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20180810/utaddress-204)
kern :warn : [ 4.260675] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20180810/utaddress-204)
kern :warn : [ 4.260890] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20180810/utaddress-204)
kern :warn : [ 4.260896] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000053F (\_SB.PCI0.GPIO) (20180810/utaddress-204)
kern :warn : [ 4.260902] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20180810/utaddress-204)
kern :warn : [ 4.260907] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000053F (\_SB.PCI0.GPIO) (20180810/utaddress-204)
kern :warn : [ 4.260912] lpc_ich: Resource conflict(s) found affecting gpio_ich
kern :warn : [ 4.802450] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround
kern :err : [ 4.885676] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could not read FW version
kern :err : [ 4.885680] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW version command failed -5
kern :warn : [ 5.007172] uvcvideo 1-1.1:1.0: Entity type for entity Extension 4 was not initialized!
kern :warn : [ 5.007176] uvcvideo 1-1.1:1.0: Entity type for entity Processing 3 was not initialized!
kern :warn : [ 5.007178] uvcvideo 1-1.1:1.0: Entity type for entity Camera 1 was not initialized!
kern :warn : [ 5.796948] kauditd_printk_skb: 7 callbacks suppressed
kern :warn : [ 30.651398] kauditd_printk_skb: 10 callbacks suppressed

edit: Habe gerade nochmal gestoppt.
Nach einem Neustart habe ich 1min50sec einfach einen schwarzen Bildschirm und dann kommt eben auf einmal der Manjaro Startbildschirm.
Login mit PW habe ich deaktiviert, also er startet dann direkt auf dem Desktop

 

[Ratz_Fatz]

Viel kann ich dir dazu nicht sagen. Ich würde erstmal mit dem Bios anfangen und dann schauen ob sich etwas ändert.

MDS ist wohl der "Zombieload-Bug". Da würde ich im Bios schauen, was du an Prefetch der CPU und Hyper-Threading abstellen kannst. (bei mir z.B. Hardware Prefetcher, Cache Linien Prefetch...).

Mtrr ist auch ein Fehler der CPU, die der Kernel wohl behoben haben sollte. Gibt ein Program um das zu überprüfen, unter Fedora war das meine ich das Paket "fwts". Terminal: "sudo fwts mtrr -"

ata Meldungen sind soweit okay. Das haben ich auch.

ACPI Warning deutet auf Bios-Bugs hin.

KVM. Kannst du im Bios deaktivieren. Virtualisierung auch, VT-x und was davon noch alles vorhanden ist.

mei. Intel Managment Engine. Da hilft vielleicht nur ein Bios-Update.

Ich kenne das mit dem langen warten nur von einer defekten NVME, da erschien erst nach über 1Minute 40sek. das Bios, vorher blieb alles schwarz.

 

[snaxilian]

Ist jetzt nix dabei was deutlich das System verlangsamt oder atypisch aussieht. Du kannst per Bootoption noch mittels pci=noaer das erweiterte Fehlerreporting abschalten aber das macht das Log auch nur leerer da Fehler versteckt werden^^
Der "langsamste" zusammenhängende Prozess ist der Start der grafischen Umgebung und der Anmeldung und da eben nss-user-lookup aber der Wert ist absolut kein Beinbruch.

 

[Infect007]

Okay, vielen Dank schon mal für eure Hilfe.
Im BIOS gibt's leider kaum Einstellungsmöglichkeiten. Ich muss mal schauen ob es da noch ein verstecktes erweitertes BIOS/Einstellungen gibt.
Ansonsten bügel ich einfach mal das neuste BIOS drüber und hoffe, dass das schon einiges verbessert...

Ich glaube es liegt auch weniger an Manjaro/Mint selbst, weil mir kommt es vor als ob der schwarze Bildschirm noch vor dem eigentlichen Linux schwarz bleibt, als ob er einfach irgendwelche Initialisierungsprobleme hat

 

[aki]

Nach dem Start mal dmesg ausführen in einer Konsole. Ich denke da gerade an das Thema Entropie-Pool. In dem Fall sollte ganz unten etwas wie random: crng init done stehen mit deutlicher Verzögerung.
Wenn du einen schwarzen Bildschirm angezeigt bekommst, kannst du auch mal wild auf der Tastatur rumdrücken. Sollte es dann relativ zügig weitergehen, wird mein Verdacht bestätigt. Das Programm haveged sollte das Problem dann lösen.

 

[Photon]

Laut systemd-analyze dauert der Boot nur wenige Sekunden. Du könntest zum Testen bei GRUB den Timeout abschalten, sodass klar ist, wann das System überhaupt anfängt etwas von der Platte zu laden. Mir kommt es nämlich so vor, als würde hier der Großteil der Zeit vergehen, noch bevor GRUB überhaupt geladen ist, der eigentliche Boot-Vorgang dann aber nur wenige Sekunden dauert.

Sollte das der Fall sein, dann kann man alle Ansätze, die das OS betreffen gleich verwerfen und sich ganz auf das BIOS konzentrieren.