cachyos systemd probleem.

[Robin4]

Ik heb wat zitten rommel, doordat ik dacht dat het nodig was door te voeren.

Ik heb iets gedaan waardoor ik 2 nieuwe boot entries in systemd heb gekregen.

eentje is met linux.conf en de andere is met linux-zen.conf.

Dus dacht google het even hoe ik dat kon oplossen.

Ik vond deze `website`

https://bbs.archlinux.org/viewtopic.php?id=250311

Ik heb gedaan wat greensam88 daar zegt.

sudo rm /boot/loader/entries/linux.conf
en
sudo rm /boot/loader/entries/linux-zen.conf

Let op ben beetje beginner met arch (ben niet dom en heb zeker nog wel wat te leren hier en daar)
Maar probeer het beetje met beetje het langzaam op te pakken.

Goed heb die bovenstaande verwijderd. Eindelijk eraf..

Dacht ik, sinds ik de update weer uitgerolt heb. (uiteraard die boot entries weer terug zoals het was)
Dus ben blijkbaar iets vergeten weg te halen zodat die die boot entries niet opnieuw kan configureren.

Kan natuurlijk opnieuw die sudo rm doen en blij zijn met het goede effect.
Maar denk niet dat dit de manier van doen is.

Iemand een idee hoe ik daar compleet van af kom.

[Robin4]

Ik denk dat ik het al gevonden heb.
Moest in de kernel manager die 2 kernels uninstalleren.
Had totaal geen enkel idee, toen ineens in me op kwam om even bij de kernel manager te gaan kijken.
En toen zag ik ineens linux core en linux-zen daar in staan. (wist dat ik eerder alleen znv4 LTS en die andere erin had staan) Dus dacht he gek er staan nog 2 extra kernels geinstalleerd die er eigenlijk niet horen geinstalleerd te staan.

Misschien verklaarde dit ook dat soms het systeem ineens vast stond en niks meer deed.

[ Voor 9% gewijzigd door Robin4 op 21-03-2026 01:18 ]

[Hero of Time]

Ik zou ook niet zomaar bestanden in /boot gaan verwijderen zonder te weten waar ze voor zijn. In het geval van het Arch forum topic dat je linkt was het prima, want het was een restant dat niet opgeruimd was. De kernel waar het naar verwijst bij die gebruiker waren al niet meer op het systeem aanwezig, getuige deze twee regels bij de betreffende entries:

code:

linux: /vmlinuz-linux-lts (No such file or directory)
initrd: /initramfs-linux-lts.img (No such file or directory)

Bij jou waren de kernels nog wel aanwezig op dat moment, dus is het logisch dat de configuratiebestanden opnieuw gemaakt worden als het boot menu (opnieuw) gegenereerd wordt. Voor die in het gelinkte topic was het eerder de vraag waarom het niet was verwijdert tegelijk met het verwijderen van de kernel.

[Robin4]

Zou ik mogen door vragen in dit zelfde topic.
Want draai al een tijdje 6.19.x kernel van cachyos.

Als ik deze draai staat continu het systeem ineens helemaal vast.
Draai ik de LTS dan gaat het verlopig nog gewoon goed.
Ik snap dat de LTS de eigenlijke stabiele kernel versie is van het OS.
en die andere soort van test versie.

Hoe kan ik er achter komen waar het fout gaat?
Ik zou uiteraard in de logs kunnen kijken. Maar heb geen enkel idee ik dit moet doen.

En is er ergens in cachyos waar ik eventueel een fout / bug rapport kan verzenden naar de maker.?

[Hero of Time]

Er is niet echt een directe verschil in stabiliteit tussen LTS en normale kernel. Zie kernel.org voor de status van de kernels. Kernel 6.19 is de huidige mainline en 6.18 is de meest recente longterm. De volgende kernel na 6.19 wordt 7.0 alweer.

Dan om uit te zoeken waardoor je systeem vastloopt is het bekijken van de systeem logs met het 'journalctl' commando de eerste stap. Sinds systemd zijn de logs in de Journal te vinden en die zijn helaas geen plain-text log bestanden meer, maar binaire blobs.

Als je weet hoe laat je systeem is vastgelopen, kan je met de optie '--since <tijd>' sneller het log bekijken vanaf een bepaald moment, ipv het begin van het journal of tot het verste punt het terug kan gaan. Het vooruit bewegen kan dan wat lang duren, afhankelijk van hoeveel er gelogd is. Voor het idee, mijn systeem draait al een paar jaar en de oudste log regel is van 14 januari dit jaar. Spring ik naar het einde via 'G' (dus shift+g) zoals ook met less e.d. werkt, duurt het al snel 30 seconden voordat het er eindelijk is. Voer ik echter 'journalctl --since 17:00' uit, dan ben ik direct op het punt van een klein half uur geleden.

[Robin4]

mrt 21 23:38:28 cachyos-x8664 plasmashell[2045]: qrc:/qt/qml/plasma/applet/org/kde/plasma/taskmanager/ToolTipDelegate.qml:63: TypeError: Cannot read property 'containsMouse' of null


mrt 21 23:38:29 cachyos-x8664 accounts-daemon[3898]: Unable to open /etc/tcb: Bestand of map bestaat niet

mrt 21 23:38:29 cachyos-x8664 accounts-daemon[3898]: couldn't list homed users: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.freedesktop.home1': activation request failed: unknown unit

mrt 21 23:39:55 cachyos-x8664 kernel: [UFW BLOCK] IN=eno1 OUT= MAC= (mac adres weg gehaald )SRC=Ip adres weg gehaald DST= adres weg gehaald/ LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=17626 DF PROTO=2


Enig idee wat voor foutmeldingen dit zijn.

[Hero of Time]

Het is allemaal niet zo heel spannend dat het een vastloper zou verklaren/veroorzaken. Eerste is alleen maar dat er een eigenschap niet gelezen kan worden omdat het geen waarde heeft.

De tweede is ook wel duidelijk, bestand bestaat niet. Maar die zou je vaker moeten zien. Ik heb het package en die daemon ook op m'n Debian omgeving (dependency van KDE plasma-desktop), maar niet die melding ondanks dat het bestand op mijn systeem er ook niet is.

De derde, accounts-daemon van de regel erboven wil nog wat doen via dbus en faalt. Het zegt mij verders niks.

Die laatste is de firewall die wat blokkeert, niks speciaals, gewoon wat het moet doen als dat is ingesteld. Heb je andere apparaten op je netwerk, zoals een Windows machine of een NAS? Zou het moeten opzoeken wat PROTO 2 is, maar zou best een broadcast dingetje kunnen zijn.

Random foutmeldingen zoeken heeft weinig nut als het systeem niet vastloopt. Ga kijken naar een gemene deler tijdens alle keren dat het vastloopt.

[Robin4]

Heb daarvoor nog eens sudo pacman -S plasma gedaan..

En de problemen lijken voor nou wel opgelost te zijn.