Garuda // Langsames starten von KDE mit viel RAM?

...plötzlich is upower.service wieder da..... obwohl ich nix gemacht hab, ausser, mein NAS einzubinden Kriese
 
mibbio schrieb:
Die (lange) RAM-Initialisierung läuft ja ab, bevor das UEFI an den Bootloader vom OS übergibt. Hier saß die Bremse zwischen Laden des Kernels und dem Anzeigen des Desktop.
Stimmt. Danke für die Korrektur!

Code:
Vorher:
Startup finished in 18.482s (firmware) + 6.169s (loader) + 1.049s (kernel) + 5.499s (initrd) + 28.438s (userspace) = 59.640s
Nachher:
Startup finished in 18.629s (firmware) + 6.859s (loader) + 2.680s (kernel) + 602ms (initrd) + 4.582s (userspace) = 33.354s
Erst ab dem Kernel gibt es deutliche Unterschiede. Der Userspace macht dann das Meiste aus.
 
Ich find die Zeiten jetzt eigentlich garnicht so schlimm, bei mir siehts so aus.
Code:
╭─alexander@alexander-x370professionalgaming ~
╰─$ sudo systemd-analyze
[sudo] Passwort für alexander:
Startup finished in 25.371s (firmware) + 5.980s (loader) + 12.071s (kernel) + 5.715s (userspace) = 49.138s
graphical.target reached after 5.715s in userspace.
Was ich mich da frage an welcher Stelle hört SystemD da auf zu zählen, wenn alles aus dem Autostart durch ist oder sobald kwin hoch ist? mit Leiste.

(find das mit dem systemd analyze interessant, wusste garnicht, das das dabei ist.)
 
Wie oben geschrieben..... ich hab nix geändert, also keine Dienste oder so installiert.

Bin schon wieder bei 28sek für upower
 
Habe ich jetzt gelesen, dass Kernel Version entscheidend sein kann, ob es schnell oder langsam geht.

@Metalveteran
Teste es mal mit 6.12 oder 6.13
 
Alexander2 schrieb:
Was ich mich da frage an welcher Stelle hört SystemD da auf zu zählen, wenn alles aus dem Autostart durch ist oder sobald kwin hoch ist? mit Leiste.
SystemD zählt nur die Startzeiten der dort eingetragenen Units, mehr nicht. Was die Desktopumgebung in seinen Autostarts interessiert SystemD nicht, sondern das ist rein eine Funktionalität der Desktopumgebung.
 
Kernel ist 6.12.10-zen1-1, und mehr hab ich irgendwie nicht zur Auswahl. Das war unter "Dragonized Edition" anders (zur Erinnerung, ich bin bei Garuda geblieben, bin aber von Dragonized auf KDE Lite umgestiegen. Bei Dragonized waren die KDE-Startzeiten ebenso hässlich)

Auch ein Grund, warum ich gerne bei Garuda bleiben möchte. Es ist zwar Arch, aber -so scheint mir- nicht so heftig "Bleeding Edge". Mit Manjaro z.B. hatte ich nach dem Update durchaus schonmal Probleme.
 
Zuletzt bearbeitet:
Metalveteran schrieb:
Es ist zwar Arch, aber -so scheint mir- nicht so heftig "Bleeding Edge".
Garuda verwendet meines Wissens direkt die Repos von Arch Linux, ist also genauso "Bleeding-Edge", während Manjaro komplett eigene Repos mit teils anderen Versionsständen als Arch hat.

Garuda hat halt zusätzlich noch das Chaotic-AUR, einem extra Repo mit fertig paketierter Software aus dem AUR. Das Repo kann man sich aber auch bei Arch Linux oder jeder anderen arch-basierten Distro hinzufügen.
 
Ist nicht Kernel 6.14 aktuell? Der wird hier noch nicht installiert.

Edit Vielleicht bilde ich mir das ja nur ein mit der Aktualität von Garuda vs. Arch "blank". Bin ja noch nicht so lange Linux-User

Weiterer Edit Und ich will ja auch garnicht groß jammern. Wenn ich ins Win11 boote ist der Desktop zwar schnell da, aber bis Steam, Epic, Nextcloud(...) geladen sind vergeht auch ne Ewigkeit :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Ja, der neueste Kernel ist 6.14.
https://www.phoronix.com/news/Linux-6.14-ACPI

In aktuellen Rolling-Distributionen sind aber erst die 6.12er in Betrieb (bei mir 6.12.10).
Einige wenige Distros bieten vielleicht sogar schon den 6.13er Kernel (CachyOS).
Die neueren Kernel sind noch im Testverfahren.
 
Zuletzt bearbeitet:
Jo, 6.12.10 hab ich auch.

....löst nur das dumme Problem mit dem upower-Dienst nicht. Oder doch? Mit 6.14 wird alles besser?

Vielleicht hat ja noch jemand ne Idee. Ich konnte den langen KDE-Boot auf upower eingrenzen.
 
@Metalveteran
Du kannst doch UPower-Dienst deaktivieren:
sudo systemctl disable upower.service
Oder falls du UPower nicht benötigst und sicher bist, dass keine anderen Pakete davon abhängen, kannst du es deinstallieren:
sudo pacman -Rns upower

Bei mir in NixOS wird /org/freedesktop/UPower/devices/DisplayDevice angezeigt, wenn ich upower -e ausführe.
ChatGPT meint:
DisplayDevice ist ein generischer Eintrag von UPower, der oft eine Art von Energieverwaltung repräsentiert (z. B. einen Monitor). Auf Desktop-Systemen ohne Akku ist das eine Standardausgabe, die keine echte Funktion hat.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
sudo systemctl disable upower

...hab ich bereits durchgeführt. Keine Besserung.

Aber ich hab ja n Rescuezilla-Backup, ich deinstallier das einfach mal. Mehr als platzen kann der Rechner nicht^^



....denkste.
:: Entfernen von upower verletzt Abhängigkeit »upower«, benötigt von solid
:: Entfernen von upower verletzt Abhängigkeit »upower«, benötigt von solid5

und ich hab kein Plan, was solid/solid5 ist.



"upower -e" verweist irgendwie ebenfalls auf ein "DisplayDevice". Ich glaub ja langsam, das es was mit dem nVidia Treiber zu tun hat....?!
 
Zuletzt bearbeitet:
mibbio schrieb:
SystemD zählt nur die Startzeiten der dort eingetragenen Units
Das macht sinn, von daher hat KDE damit nichtmal was zu tun, sondern TTY und LoginManager/DisplayManager. Letzterer startet dann ja erst den Desktop oder was man da nutzt, Ob das nun nen Desktop, nen WM ist.
Ergänzung ()

Metalveteran schrieb:
Das lässt sich tatsächlich mehr Zeit, ist weniger Bleeding Edge, wenn man so möchte. Du bekommst ja grob "nur" 1 mal im Monat nen "Updatehaufen".
Ergänzung ()

Metalveteran schrieb:
Internet Suchwort:
linux solid/solid5
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
@Metalveteran
Ich würde alles in Ruhe durchgehen, ob upower aktiviert sein muss:
Code:
sudo systemctl status upower.service
sudo systemctl disable upower.service
sudo systemctl stop upower.service
sudo systemctl status upower.service

... und wenn's benötigt wird für solid/5, dann
sudo systemctl enable upower.service
sudo systemctl start upower.service
sudo systemctl status upower.service



Infos von Garuda:

The idle RAM usage will most likely be higher than on other distributions as we use ZRAM and some other tweaks to enhance the general system performance. Unused RAM is wasted RAM, it's as easy as that!
Es wird zu Beginn des PC-Starts alles mögliche vorgeladen (Prefetch bzw. Preload).
Sollte also kein Wunder sein, dass der Start etwas länger dauert.

Wo ist da eigentlich das Problem ein paar Sekunden oder gar eine Minute beim Start zu warten?


Don't try to use Wayland (Wayfire and Sway) if running an NVIDIA GPU (we all know what Linus said)
Nutzt Du Wayland, dann probiere mal X11 aus.



Und ja, Garuda nutzt die offiziellen Quellen von Arch - ist also Bleeding Edge.
Wenn man umsteigen möchte, wären also Arch Linux, Manjaro und EndeavourOS sehr ähnliche Kandidaten.
 
Metalveteran schrieb:
und ich hab kein Plan, was solid/solid5 ist.
Ich würde einfach mal die Benutzung einer Suchmaschine empfehlen.
Sorry falls das jetzt irgendwie schnoddrig ankommt, aber random Dinge (ohne Plan) zu stoppen und/oder zu entfernen halte ich für keine gute Idee.
Kannst du natürlich trotzdem tun, denk nur daran, die Entwickler von Plasma oder deiner momentan genutzten Distribution haben sich vermutlich auch darüber Gedanken gemacht welche Services sinnvoll sind.
Mag sein, dass du jetzt irgendwie diese gefühlt lästigen Dinge loswirst dann aber anderswo andere Probleme auftauchen. Gibt einige Abhängigkeiten, aber auch Bugs. Schonmal nach letzterem gesucht?
 
  • Gefällt mir
Reaktionen: mibbio und TomH22
@Metalveteran
KDE Energieverwaltung arbeitet mit upower zusammen.
Es ist nicht möglich, upower zu deaktivieren.
Ich habe bei mir in NixOS ModemManager Service deaktiviert. Ein PC mit ModemManager macht keinen Sinn. Vielleicht 400ms gespart :D

Laut Suchmaschine ist upower nicht die Ursache des Problems, sondern eine virtuelle Maschine bzw. Startparameter des Wirtes (Host).
Laut sudo systemd-analyze blame beträgt die Startzeit für upower.service 68ms in meinem System.
Versuch doch mit QEMU und KVM und lass if=virto weg.
https://debianforum.de/forum/viewtopic.php?t=162860
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Ist das System auf einer HDD oder SSD installiert?
Ich glaub mich zu erinnern das unter
Garuda Linux der Partition Vorschlag eine Verschlüsselte Btrfs Partion ist. Wenn viele Daten zuerst entschlüsselt werden müssen auf einer langsamen HDD könnte das die Performance Probleme erklären. Könnte muss aber nicht, ist nur ein Verdacht.
 
Zurück
Oben