Kinoite Installation with UTC TimeZone breaks KDE

As per the discussion in the old thread, installing Kinoite with a UTC timezone seems to break KDE.

@daveharas has corroborated this, and all credit to @guiltydoggy for digging into the cause.

The workaround discussed in that thread (changing the timezone at install time, then changing it back to UTC) seems to hold for a time, and then the behaviour reasserts itself. I thought it was associated with subsequent runs of rpm-ostree commands, but that doesn’t seem to hold true all the time.

Any help to resolve would be appreciated.


I have Silverblue 35, and yesterday I decided to rebase to Kinoite to give it a look. I saw exactly this issue. It looked like all the apps were missing and those already pinned had missing icons. (I’m in the UK, currently UTC.)

I reverted back to SB pretty quickly on the assumption that I’d messed up the rebasing, but in retrospect perhaps I was seeing what you report here.

1 Like

There are more of us experiencing this concern over in this thread.

So is there a bug logged for this, on bugzilla or wherever? I’d be interested in following this one.

1 Like


Any news on this?
I’ve been having this problem (after rebasing from silverblue) and it’s getting fairly annoying.

Fedora Kinoite 36 has the same issue. Europe/London timezone. Trying to get my brother to switch from popOS after his install exploded after an update. Changing timezone fixes it temporarily but it’s really not a solution.

I spent a little time today to try to track this down some more and I may have found out what’s happening. I’ve only taken 1 class in computer programming 20 years ago, so I may be completely wrong, so take this with a large grain of salt.

I believe the issue to be with the KDE System Configuration Cache. I thought this because there are a number of errors during login that look like: KServiceTypeTrader: serviceType "KCModuleInit" not found KApplicationTrader: mimeType "inode/directory" not found

The different kinds of sycoca (Service, Application, etc) are built and entries in the binary database are added with createEntry. That calls calcResourceHash, which then calls updateHash, which has this:

hash += fi.lastModified().toSecsSinceEpoch();

That will return 0, and thus cause the entries to not be created.

Not sure what should be done about that in the KDE codebase. But I think I have a work-around for Kinoite users - you can temporarily fix your session by running the following commands:

$ timedatectl set-timezone America/Chicago
$ kbuildsycoca5
$ timedatectl set-timezone UTC

Couple things to note:

  1. This isn’t a permanent fix. These commands can be run in case you forget to change your timezone before running an rpm-ostree command for example.
  2. timedatectl needs admin privileges to run, but kbuildsycoca5 needs to run as your own user - it won’t work when run as root/with sudo. So if you want to set up your own systemd service or something for this, keep that in mind.
  3. Unfortunately this is just a hack still, so your system logs will still be spammed with kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated
1 Like

Posted a patch upstream: kbuildsycoca: Ignore last modified time when set to UNIX Epoch (!87) · Merge requests · Frameworks / KService · GitLab

You can try the fix by downloading the RPM from and then running:

$ rpm-ostree override replace ./kf5-kservice-5.93.0-2.fc36.x86_64.rpm

and reboot

1 Like

Good news and bad news.

Good news, it seems that this patch will fix the issue where UTC causes the system to be unusable/no application icons - so it fixes 2021087 – Installation of Fedora Kinoite in a UTC timezone breaks KDE.

Bad news, there still seems to be a bunch of “findInCache with a lastModified timestamp of 0 is deprecated” messages in the journal, so that bug is not addressed by this (I mistakenly thought these issues were related, but it seems they are not - sorry about that).

At least now the system is usable in UTC timezone; just has some extra journal spam.

1 Like

The findInCache issue should be harmless (but annoying I agree).

The general issue here will be fixed once the 5.94 frameworks are pushed to Fedora 36. This should happen soon.

1 Like