System theme reverts to default (light) after reboot

[realitymolder]

Describe the bug

• Put the system on dark mode
• reboot the system
• System will revert into light mode

What did you expect to happen?

System should respect the selected theme unless the user changes it deliberately

Output of rpm-ostree status

❯ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:39
                   Digest: sha256:884091a7dd38f0b2b75f7f7355829bd855777bc804ac3b9610051b3cfbf114cb
                  Version: 39.20240406.0 (2024-04-07T14:59:41Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:12bf38717e940dc35959781bcb43a94c6b7f1a02a65b20cb1b621bc321eea165
                  Version: 38.20240404.0 (2024-04-07T22:20:45Z)

~

Extra information or context

No response

[m2Giles]

Did you use the toggle in the system menu to change from light mode to dark mode or did you make changes in gnome-tweaks?

[realitymolder]

Did you use the toggle in the system menu to change from light mode to dark mode or did you make changes in gnome-tweaks?

I used the system menu, but seems like it is not constant. It happened to me twice at least.
I restarted now and it seems OK. 😨

[realitymolder]

Update:
I've moved to 39 and now the issue is back, I checked if the issue is only after ujust update but it's not.
So atm after every reboot the theme resets to light theme.
I'm using the system tray (control center) to toggle the theme between dark and light.

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:39
                   Digest: sha256:4703c1c6019cd734c09f01ade8918c628f8f4ae27dc3bbc25d5426e53c99c797
                  Version: 39.20240412.0 (2024-04-12T17:04:47Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:39
                   Digest: sha256:0b5419384e2d87ab109f0ccc606005f43c770c6bb72e8caf89fc5bab9ba7a43f
                  Version: 39.20240408.0 (2024-04-08T18:47:37Z)

[m2Giles]

I'm unsure exactly why this would be occurring. Unless you are resetting dconf, this should remain the same.

[geoffreysmith]

I had weird problems last week (or so?) that suddenly resolved themselves on 39.x. I am having this similar issues. Reformatted from ISO to 40. Ran outside of the bluefin-cli "ujust update", Installed broadcom drivers, nvidia kernel drivers, installed gnome-extensions.. 0id a system clean for good measure. All through ujust.

❯ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest (index: 0)
Digest: sha256:54804a33df44857592b9639a2da8c6d3a9553bb96d78fa7ff6ea21677efecca5
Version: 40.20240423.0 (2024-04-24T14:54:46Z)
Commit: 7768a749ab5edffebfa4f614378a8fbaf4c22709cee93684c0ef87b65f3c6e1f
Staged: no
StateRoot: default

ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest (index: 1)
Digest: sha256:54804a33df44857592b9639a2da8c6d3a9553bb96d78fa7ff6ea21677efecca5
Version: 40.20240423.0 (2024-04-24T14:54:46Z)
Commit: 7768a749ab5edffebfa4f614378a8fbaf4c22709cee93684c0ef87b65f3c6e1f
StateRoot: default

ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest (index: 2)
Digest: sha256:a69003391443a1b1e27940529dc468ba36e8e598f78489826087035e81858a1f
Version: 40.20240423.0 (2024-04-23T14:43:53Z)
Commit: 156b7874a6a7adc9de2b5cf2c2a3f3c9416f1a46d043e9eb9b4b81f6a1b228f4
StateRoot: default
Pinned: yes

I have done nothing else. I'd highly suggest we move to a minimal package install (literally Firefox) and whatever is needed, then use dotfiles and a package config management system to supplement that. For whatever reason Nix was axed but all I used it for was exactly cli packagse and then preferences in dot files, maybe some light pre-commit scripting. I'm not tied to Nix and didn't use the OCaml software.

I go back and forth between machines to SSH into this and with ChezMois and home-manager I can generally use Brew for gui (ironically opposite of what we do), and then Nix for CLI system tools. I'm not tied to the tool set at all. I just generally define packages as generally as I can across environments and if Brew is used for CLI or GUI and Flatpacks are use for GUI it doesn't matter, I install them self contained, export out the dot files and "sync" it up.

In my ideal world everyone would do the same thing but what makes me love Bluefin is that if Nix is off the table or distroboxes are off the table I can setup an environment perhaps better than forking.

VS Junkies who don't touch Linux? Okay put it in a docker file and just expose the source code then let earthly do the build/lint/etc. under the hood.

My usual pattern is small Nix projects (perhaps layered ontop of each other, like connector to a ticketing board then if it is Jira in a huge org that has weird VPN and stuff I can use the same functionality and layer the VPN/weirdness/create another package basically.

I have a generator that scaffolds out big monorepos (think Figma -> Design System doc -> creates ticket or flat file -> creates ephemeral environment -> feature is done and continuous deployment all local).

But I assume that the many external teams will never give me access to their board for webhooks, or use Kubernetes, or even Docker so having a nice "standard library" of DevPod, Distroboxes, Kubernetes, is awesome and I can start small get going internally then adapt to how existing teams work. Maybe I'm doing it "wrong" but I create simple non-container repos using something like Nix + devenv + Earthly then as the project progresses it becomes a game of choosing what works best. I'm already cloud native and I know how people hate that term but it sure is easier to go from a light-weight cloud native environment to figuring out the team structure and as the project progresses figure out what tools work best for big orgs who often have to go through months of legal compliance.

Long-story short I'm working on setting this up this weekend like having a "Bluefin-light" and then add on through ujust DevPods, distroboxes, K8S, etc. That way there's not a lot of heavy often proprietary tools that makes Bluefin great but outside of SaaS/startup/SV companies, most my projects I'd like to have packages and dotfiles configured in a separate repo-"Geoff Megacorp 2" without forking the main.

I dunno I think it'd solve a lot of integration problems in the sense Gnome Extensions doesn't overwrite the dark appearances, etc. And then on startup I'd have something that'd load by project specific environment (similar to a distrobox I guess).

That's just my workflow, I'll get the general project down and get main features out quickly then as it matures move to a more production setup. I might still have Kusk as an API gateway in Kubernetes in Development and switch it out to whatever flavor AWS/Azure uses outside of a true Kubernetes setup. So basically have a dev environment running locally with mocks and use CI pipelines (with Cue and Earthly?) to create the production environment through GitHub Actions basically. I don't work on projects large enough to where simply adding a Redis cluster flavor will save me millions I just need to know the over all solution in my mind, get the logic done then progress into production which is what BlueFin is great at.

My biggest problem is working with a mattress retail store for example and they are so far removed from "cloud native" they want to bring up intellij, springboot, load SQL manually put it on a VM and go as slow as possible. That's fine too your local dev build essentially becomes prod without docker or anything scary like going off enterprise software but you can develop normally and take package management, containers, and all then neat stuff and abstract in the build. You still get 1990s problems like not using Terraform to setup MS SQL on a single machine but you can be cloud native and figure out how to reconcile their branch check-ins with yours.

Sorry for the long rant but I feel as if a lot of issues are installing everything, which runs into conflicting problems like this and things magically fixing themselves probably through an upstream update. I'd rather have an "all-in" distro and a support matrix where you can install things a-la-carte. I rarely assume anything in the beginning will look like the end so I start off with the least and like knowing I can have an official "supported" stack.

I guess I usually scaffold out what I think I know i need into mocks (Salesforce, etc.) then build as simply as possible without worrying about "we have a license for this generic product we must use it" and slowly build up to production once what I've been told and what is real comes together.. But I set things up for to show progress quickly assuming I have full control and make it apparent that if their side gets confused they can't write enterprise Java apps anymore or worse, Docker has some license legal will take months to approve, I can continue building features show progress and having dev separated from production has its own issues that will eventually be reconciled going at it cloud-native/IaC means "just" spending a week writing transformers/connectors because you've abstracted the ops layer and in the interim executives notice their old way of thinking with big architecture diagrams and selection processes doesn't work.

Sorry for the long rant that's just my dev workflow lately and I could be wrong but I see a lot of benefits of Bluefin (all you need ever out of the box!) work well in homelabs/experimenting, where I tend to in reality assume their environments are drastically different and take the approach of using just what you need and add as you know more.

This is not a knock on Bluefin and I went way off tangent but I see a lot of problems stemming from software that's not deterministic and colliding with our better setup. I could be wrong but it is what turned me off in the beginning. :)

Ive been forking and rewriting the main since F40 released and I probably will come into the same problems you have already addressed, but it'd be super awesome to have a stock Bluefin and rather than forking it for things like drivers or low level kernel stuff, turn it into configs to install packages with a primary support base that will be kept up.

Just my two cents from a dummy who passes paperwork around now. 🤕

[ctsdownloads]

I am experiencing the same. Rebased both into ublue-os/bluefin-dx:39 and ublue-os/bluefin-dx:40 for testing. Rebooting seems to undo it.

Going to disable all extensions individually, see if there is a conflict. CCing @castrojo

Didn't work. Going to disconnect from external displays tomorrow and re-test on other machines to see if I might have messed up some conf somewhere.

[castrojo]

I haven't been able to reproduce this but have an eye out.

[ctsdownloads]

Over the weekend, going to try and drill down on where this is happening and why. I will roll back through my list and see if I can spot where it happened for me. Worst case, I will run the known older ISO I have, note what I have, then update tracking changes as we go. I'm pretty good at catching stuff, if I can replicate the point where it happens, I will share it here. Not a big deal, just something for me to poke at over the weekend.

[ctsdownloads]

Okay folks, narrowed it down.

Had night theme switcher extension installed.
Had an update to the night time switcher upcoming. Back when it was in a working state. Updated said extension, the problem presents itself then.

Workaround: Disable night theme switcher..

I confirmed disabling night theme switcher allows dark mode to work as expected and be persistent between reboots.

[geoffreysmith]

Hey wow! I noticed themes didn’t work either. Seems an upstream issue. I got used to turning on night mode and ignored it this explains why some apps obeyed night mode and others didn’t due to how they were built. Something about gtk3 vs gtk4 but I’m not a UI person. As someone who simply doesn’t care I’ve heard KDE solves these problems but not others. Just seems like the bazz people are happy. I spend 99% of my time in terminal so as long as that works.