@dmt Interestingly enough, I did spot several (repeated) errors. Here’s a slice:
– Boot 850abb852af64b73aadadf941c8121f3 –
Aug 04 15:15:48 dZenBookj systemd[1049]: Created slice Slice /app/dbus-:1.2-org.kde.KSplash.
Aug 04 15:15:48 dZenBookj systemd[1049]: Started dbus-:1.2-org.kde.KSplash@0.service.
Aug 04 15:15:52 dZenBookj systemd[1049]: plasma-ksplash.service: Consumed 1.533s CPU time over 3.868s wall clock time, 104.8M memory pe>
Aug 05 17:25:37 dZenBookj systemd[1049]: Started dbus-:1.2-org.kde.KSplash@1.service.
Aug 05 17:26:37 dZenBookj systemd[1049]: dbus-:1.2-org.kde.KSplash@1.service: Main process exited, code=exited, status=1/FAILURE
Aug 05 17:26:37 dZenBookj systemd[1049]: dbus-:1.2-org.kde.KSplash@1.service: Failed with result ‘exit-code’.
Aug 05 20:14:01 dZenBookj systemd[1049]: Removed slice Slice /app/dbus-:1.2-org.kde.KSplash.
I am not booting from a snapshot, and I don’t have anything installed from AUR (nor do I have it enabled on pamac).
I’m running a long “smartctl” test right now; the short test passed with no issues.
@tracyanne Thanks for that tool! Learning new things all the time here about Linux.
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-7.1.8-1-MANJARO] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF SMART DATA SECTION ===
Self-test Log (NVMe Log 0x06, NSID 0xffffffff)
Self-test status: No self-test in progress
Num Test_Description Status Power_on_Hours Failing_LBA NSID Seg SCT Code
0 Extended Completed without error 10394 - - - - -
1 Short Completed without error 10393 - - - - -
Yes, but they only install files and/or directories. They do not alter any existing files — unless it’s malware, of course, and now you are specifically mentioning the AUR.
Indeed, but you can’t rely on people not altering pre-existing files, even without malicious intent. There’s a large variation in knowledge and styles.
Indeed, I only mentioned it because lots of people update the AUR at the same time as the repo nowadays, so when they say update it could also pull in AUR packages which vary a lot.
Do you often test interesting Global Themes? Global themes run scripts which may change this specific file - perhaps removing all content instead of removing it?
Do you use btrfs? That file system can cause some weird experience with files that changes often.
That would depend on the file system.
I think btrfs can do an online check, while ext4 requires to be unmounted, thus involving a bootable ISO perhaps having a small partition with an ISO and boot the ISO directly from GRUB - or a small EFI stub loading a small rescue system…
I don’t really touch themes at all, nor do I install any outside / external themes that don’t ship with Manjaro’s KDE DE as a default. I’m using BTRFS, yes. I’ll have to check resources on how to do an “online check”, but if a smartctl scan is what you were trying to point me in, I’ve done those scans.
I appreciate your insights on this, I hope to solve / figure this issue out soon.
I it really poking in the dark - because I cannot think of any, any reason why that particular file would loose content - except for file system haywire.
That and rogue scripts - but as you don’t fiddle with themes - there is no reason to think rogue scripts.
The only idea, I have not used… rename the file ~/.config/ksplashrc like this
mv ~/.config/ksplashrc ~/.config/ksplashrc.org
The reasoning by renaming: if it is a file system error or a disk error - then renaming the file will prevent the spot from being reused by the kernel when writing the same file name later - it is an old test - from the time of floppy disks and platter drives.
Then run
systemctl soft-reboot
Your splash should be reset to the default of your chosen theme.
Optional:
If you want to go really nerd, you can sync the package inotify-tools.
Then create a script to watch the specific file, and when it changes you can use notify-send to push an alert on your desktop.
This approach may be good in troubleshooting - but it can be hard on resources.
It will not tell you why but it will show you when… which in turn may lead you to the source…
#!/usr/bin/env bash
TARGET="/hoem/$USER/.config/ksplashrc"
EVENTS="open"
ACTION="notify-send -u critical -t 5000 ksplashrc was opened"
inotifywait -m -e $EVENTS --format '%w%f' $TARGET | while read FILE
do
$ACTION "$FILE"
done
I had exactly the same. ksplashrc was an empty file causing default persistent Breeze splash screen. Changing in UI did not had any effect. I placed the content:
[KSplash]
Engine=none
Theme=None
in it and thought issue is solved, but no, after last update the file was empty again…
@Wollie by chance, do you have a laptop, and do you often use the sleep mode? I have a slight suspicions this might be related? But of course, I can’t seem to replicate it reliably.
@pwx Please keep in mind, I’ve only really started using Linux since January of this year; which log / how do I find the logs? I’m very quickly learning ins and outs of this operating system, but I still find myself asking what may be very basic questions.
It will show the log of the actual boot with priority 4.
-b [[ID][±offset]|all], –boot[=[ID][±offset]|all]
Show messages from a specific boot. This will add a match for “_BOOT_ID=”.
The argument may be empty, in which case logs for the current boot will be shown.
If the boot ID is omitted, a positive offset will look up the boots starting from the beginning of the journal, and an equal-or-less-than zero offset will look up
boots starting from the end of the journal. Thus, **1** means the first boot found in the journal in chronological order, **2** the second and so on; while **-0** is the last
boot, **-1** the boot before last, and so on. An empty offset is equivalent to specifying **-0**, except when the current boot is not the last boot (e.g. because **--direc‐**
**tory=** was specified to look at logs from a different machine).
If the 32-character ID is specified, it may optionally be followed by offset which identifies the boot relative to the one given by boot ID. Negative values mean
earlier boots and positive values mean later boots. If offset is not specified, a value of zero is assumed, and the logs for the boot given by ID are shown.
The special argument **all** can be used to negate the effect of an earlier use of **-b**.
-p, –priority=
Filter output by message priorities or priority ranges. Takes either a single numeric or textual log level (i.e. between 0/“emerg” and 7/“debug”), or a range of nu‐
meric/text log levels in the form FROM..TO. The log levels are the usual syslog log levels as documented in syslog(3), i.e. “emerg” (0), “alert” (1), “crit” (2),
“err” (3), “warning” (4), “notice” (5), “info” (6), “debug” (7). If a single log level is specified, all messages with this log level or a lower (hence more impor‐
tant) log level are shown. If a range is specified, all messages within the range are shown, including both the start and the end value of the range. This will add
“PRIORITY=” matches for the specified priorities.
That is quite strange - I have never noted strange experience in that regard - but it do point to an upstream issue - where Plasma is messing up it’s own configurations.
