Garuda // Langsames starten von KDE mit viel RAM?

[Metalveteran]

Hello again!

Nur mal ne Verständnisfrage.....

Ich hab jetzt einiger Zeit Garuda benutzt (Dragonized Edition). Das hab ich sowohl auf Desktop-PC als auf Notebook installiert gehabt.

Beim Notebook dachte ich letzte Woche "Wozu das dicke Paket?" und hab dann die KDE Lite Version installiert. Boot ist deutlich flotter.

Also dachte ich "Ja cool, mach ich auf meinem Desktop doch genauso" (also KDE Lite statt Dragonized), aber ernüchternderweise ist der KDE Start Screen genauso lange zu sehen wie vorher. Also schon so im 20-30 Sekunden Bereich.

Notebook is irgendein Lenovo mit 4xxx Ryzen CPU und nur 4GB RAM. Desktop ist ein 7800X3D mit 64GB RAM.

Kann es sein (evtl. hat jemand anderes auch die Erfahrung gemacht), das KDE beim starten erstmal den RAM füllt bevor der Desktop kommt? Laptop nutzt von seinen 4GB RAM nur knapp 2GB, aufm Desktop werden gut 7GB RAM benutzt.

Hat sowas ähnliches jemand anderes auch beobachtet? Woran liegt das? Evtl. vllt. sogar am nVidia Treiber (erster Boot nach Installation war schon recht flott)

 

[NameHere]

Kannst ja mal schauen woran es liegen könnte wie hier beschrieben
https://www.tecmint.com/systemd-analyze-monitor-linux-bootup-performance/

 

[D.S.i.u.S.]

So lange kann es nicht sein, es sei denn Memory Context Restore ist nicht aktiviert. Mit 7800X3D bin ich nach ca. 14 Sekunden in SDDM.

 

[Metalveteran]

Werde mir mal anschauen, was @NameHere gepostet hat.

@D.S.i.u.S. Nene, ich meine wirklich nur den Screen mit dem KDE-Logo und darunter das Zahnrad. Alles davor geht "normal schnell".


Nachtrag
foo@foo-garuda ~> sudo systemd-analyze
[sudo] Passwort für foo:
Startup finished in 18.482s (firmware) + 6.169s (loader) + 1.049s (kernel) + 5.499s (initrd) + 28.438s (usersp
ace) = 59.640s

Wie Ihr seht..... knapp 30sek "Userspace". Das teilt sich auf in

foo@foo-garuda ~> sudo systemd-analyze blame
25.342s vmware-USBArbitrator.service
22.288s upower.service
... (alles darunter unter 10sek)



foo@foo-garuda ~ [1]> sudo 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 @28.190s
└─multi-user.target @28.190s
└─vmware-USBArbitrator.service @2.846s +25.342s
└─basic.target @2.825s
└─dbus-broker.service @2.788s +34ms
└─dbus.socket @2.442s
└─sysinit.target @2.440s
└─systemd-binfmt.service @1.662s +778ms
└─proc-sys-fs-binfmt_misc.mount @2.271s +166ms
└─proc-sys-fs-binfmt_misc.automount @272ms



Kann man da was fixen?

 

[NameHere]

Du nutzt vmware und reichst wohl USB durch. Die Frage ist ob der ganze im autostart sein muß. Am sinnvollsten wäre es wenn dieses nur aktiv ist wenn auch vmware läuft.

 

[Metalveteran]

Hm, im Autostart find ich nix mit VMWare.

Wo kann ich da noch nachsehen?


Nachtrag Qemu/KVM und wie das heisst.... ist mir noch zu hoch^^, und unter Virtualbox laufen keine Spiele. Daher VMWare. Und NEIN, es muss NICHT im Autostart sein In meinen VMs nutze ich USB garnicht.....

 

[NameHere]

probiere den Dienst so zu deaktivieren und nach dem boot startest vmware und schaust ob es alles läuft wie es soll

deaktivieren

sudo systemctl disable vmware-USBArbitrator.service

wieder aktivieren

sudo systemctl enable vmware-USBArbitrator.service

 

[Metalveteran]

Hm. Fühlt sich jetzt nicht unbedingt flotter an, aber es taucht bei systemd-analyze blame nicht mehr auf.

Und was mach ich jetzt mit dem upower.service? Auch einfach deaktivieren?^^ Ach, ich versuchs mal

Ergänzung (25. Januar 2025)

Okay, taucht jetzt nicht mehr auf. Habs auch mit disable upower.service probiert, das startet aber trotzdem. Also nicht wirklich schneller.

 

[NameHere]

Und was mach ich jetzt mit dem upower.service? Auch einfach deaktivieren?^^ Ach, ich versuchs mal

warum informierst du dich nicht zuerst darüber bei google wofür man diesen service braucht^^

wer bracht schon das Powermanagement

 

[Tanzmusikus]

unter Virtualbox laufen keine Spiele. Daher VMWare.

Warum nicht WINE, Lutris oder HGL nutzen?

 

[Metalveteran]

Ich schau ja schon nebenbei

@Tanzmusikus Hä? Worauf willst Du hinaus? edit Aso. Weil ich Freelancer + Crossfire unter Linux nicht zum laufen bekomme Also nicht mit Multiplayer.

 

[Tanzmusikus]

Warum Spiele per VM spielen, wenn es unter Linux super Alternativen für Windows-Spiele gibt?

Du meinst das Spiel "Freelancer" und möchtest Dual AMD-GPU "Crossfire" in die VM durchreichen, weil Crossfire nicht unter Linux läuft?

 

[D.S.i.u.S.]

@Metalveteran
Hast du auch RAM-Disk?
initrd ist bei mir gar nicht dabei.

Startup finished in 10.676s (firmware) + 1.942s (loader) + 3.321s (kernel) + 2.748s (userspace) = 18.688s 
graphical.target reached after 2.748s in userspace.

 

[JennyCB]

graphical.target @28.190s
└─multi-user.target @28.190s
Bei mir mit Manjaro:
graphical.target @2.610s
└─multi-user.target @2.609s

 

[D.S.i.u.S.]

Funktioniert vielleicht sudo systemctl disable vmware-USBArbitrator.service?

 

[Tanzmusikus]

Bei meinem EndeavourOS:

systemd-analyze
Startup finished in 7.605s (firmware) + 3.808s (loader) + 4.896s (kernel) + 2.250s (userspace) = 18.560s
graphical.target reached after 2.246s in userspace

Funktioniert vielleicht sudo systemctl disable vmware-USBArbitrator.service?

Könnte man mit sudo systemctl status vmware-USBArbitrator.service herausfinden.
Wenn's nach der Deaktiviert wieder aktiviert wird oder nicht ... bzw. wenn der Boot schneller wird.

@Metalveteran
Hast die "Memory Context Restore"-Funktion im UEFI schon mal testweise aktiviert?

 

[Metalveteran]

@Tanzmusikus Crossfire ist eine Mod für Freelancer.

Ich hab Garuda KDE Lite gerade nochmal neu installiert. Offensichtlich war "upower" wirklich das Problem, ich hab im Garuda Assistant "Powertweaks" aktiviert gehabt, und trotz Deaktivierung hat's dennoch ewig gedauert.


Nach nem Fresh Install:
╰─λ sudo systemd-analyze
Startup finished in 18.629s (firmware) + 6.859s (loader) + 2.680s (kernel) + 602ms (initrd) + 4.582s (userspac
e) = 33.354s
graphical.target reached after 4.579s in userspace.

sieht gut aus. Wenn ich dann VMWare neu installiere nicht vergessen, den Arbi.... Arbei........ USB Dienst rauszuschmeissen

@Tanzmusikus EndeverourOS hatte ich auch schon hinter mir, da fehlte mir aber ganz ordentlich Wissen dafür. Aber nachdem ich mich zwinge, nicht mehr in Win11 zu booten, hab ich viel gelernt. Vielleicht geb ich dem auch mal wieder ne Chance

 

[Tanzmusikus]

Naja, AM5 ist bekannt für langsameren Boot (als AM4) wegen dem DDR5-RAM.
Sieht nun aber schon viel besser aus. Ist ja fast doppelt so schnell beim Booten jetzt.

 

[Metalveteran]

Die Zeit bis zum Bootloader, die zähl ich nicht. Jo, AM5 und so, dazu 64GB RAM. Aber das "rein KDE" so lange gebraucht hat..... ich hatte dafür sogar extra ne pennende Katze installiert damit es nicht zu sehr nervt

 

[mibbio]

Naja, AM5 ist bekannt für langsameren Boot (als AM4) wegen dem DDR5-RAM.

Das hat aber für dieses Problem hier eigentlich keine Relevanz. 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.