• 1 Post
  • 43 Comments
Joined 2 months ago
cake
Cake day: July 7th, 2026

help-circle



  • I don’t agree with the sentiment that Linux Mint is underrated either. As you note, it is quite popular and is mentioned a lot in the discourse.

    However, I don’t think that CachyOS and Linux Mint are the most popular distros; that undoubtedly goes to Ubuntu. And, if anything, I’d think that Linux Mint is more popular than CachyOS.

    Yet, if we’d limit it to the distros used by gamers, then CachyOS probably does take the crown for most used distro (aside from SteamOS). At least, there are metrics that suggest as such.


  • Sorry for the late reply

    No worries fam 🙂.

    thank you for taking your time!

    It has been my pleasure 🙂.

    I have “defaulted” back to Artix, having fixed the NIC issue.

    Glad to hear that you were able to return back to your home.

    And I agree, Gentoo is what I dream of being able to handle, but all the USE flags KILLED me when I set it up for the first time a month or so ago. xD I do want to get back to it at some point though.

    Good mindset! I’m sure you’ll manage whenever you get back to it 😉.




  • Others have basically already pointed out how you should go about diagnosing the problem. Which, by itself, is already very valuable.

    Below, I will try to touch upon some tips and tricks that are worth noting in this context, assuming Bazzite*.

    • Pinning a specific deployment to return back to. As we’ll be doing some time traveling in a bit, it’s definitely recommended to pin your latest deployment (just in case) before you do anything else. See this entry in Bazzite’s documentation on that.
    • Rolling back to images from a certain day. So, IIRC, all of the uBlue products keep around 90 days worth of images you can rollback to. See Bazzite’s documentation on brh for more information. With this (and some effort), you can literally pinpoint the exact date from which you started to have problems with gamescope/game mode.
    • Looking into the exact changes between two deployments. So, after you’ve identified the last properly working deployment and the first deployment that started misbehaving, you can invoke the rpm-ostree db diff command to see what has changed between the two deployments. Note two things on this:
      • That the hashes coincide with the ones you actually want to compare.
      • The command catches only changes in packages. However, a config diff applied by Bazzite’s maintainers will not be shown here.
    • Asking help from community channels. You can even start here. But basically, a project’s discord/discourse is undoubtedly better equipped in helping you out. See this entry on Bazzite’s documentation for links.

    Wish ya good luck fam 😉!


  • Alright, excellent. Thank you for the reply!

    So, IIUC, you want a clean slate. Furthermore, you want plenty of tinkerability. And, finally, OpenRC enjoys a preference.

    Still, I want to limit our search (for now) to (relatively) upstream distros on which OpenRC is known to work pretty well. We have to start our search from somewhere and this seems to be the most sensible starting point at this point.

    If you’ve dismissed Artix, that basically leaves us (in alphabetical order) with:

    • Alpine
    • Debian
    • Devuan
    • Gentoo

    IIRC, most (if not all) of these offer very minimal images. So, hopefully you’ll enjoy those.

    Thankfully, these are meaningfully different from eachother (for the most part). So choosing between these shouldn’t be too much to ask.

    FWIW, Gentoo comes undoubtedly with the least amount of defaults and thus behaves the most like a blank slate.


  • I am most fond of Arch

    But what is it that you like about Arch in the first place?

    I found that I’m more comfortable with OpenRC as init and process management.

    Like, do you want to limit your options to distros that are well supported by OpenRC? Or, is this simply a preference kind of thing?

    the Artix forums also seem to house at least some transphobia

    Do you want to engage in distro-specific forums or was your engagement in there mostly out of necessity?

    as opposed to configured by me.

    Excellent, so you’re a builder/tinkerer that prefers a clean slate to work from.


  • Assuming you’re involved with the development on AstrOS, thank you first of all for your efforts and secondly for providing your perspective on the matter!

    Imo it generally does too much.

    Oh, I can definitely see that; probably the consequence of retrofitting an OCI/Docker image into an OS 😅. I suppose that its relation with (rpm-)ostree doesn’t help either.

    Systemd-sysupdate being simple as hell makes it just way more solid.

    That’s some cool insight. Thank you.

    I think it also depends on grub and stuff

    I believe it did, yes. But, AFAIK, systemd-boot has been supported since earlier this year. I believe that change has also been instrumental in the relatively recent activities surrounding so-called sealed images.





  • Thank you! This is actually very helpful! And we can definitely reverse some of their doing 😉. Below I will repeat the invoked commands and provide some context/explanation. So, without further ado.


    sudo rpm-ostree kargs --append-if-missing=zswap.enabled=1
    sudo rpm-ostree kargs --append-if-missing=zswap.max_pool_percent=25
    sudo rpm-ostree kargs --append-if-missing=zswap.compressor=lz4
    sudo rpm-ostree kargs --append-if-missing=systemd.zram=0
    

    The commands found above were used to change the kernel arguments through rpm-ostree. You can still find these back with rpm-ostree kargs --editor. You can even outright remove them, then and there. It’s also possible to literally revert those commands by invoking the following:

    sudo rpm-ostree kargs --delete-if-present=zswap.enabled=1
    sudo rpm-ostree kargs --delete-if-present=zswap.max_pool_percent=25
    sudo rpm-ostree kargs --delete-if-present=zswap.compressor=lz4
    sudo rpm-ostree kargs --delete-if-present=systemd.zram=0
    

    sudo rpm-ostree initramfs --enable --arg=--add-drivers --arg=lz4

    Unfortunately, I don’t have any experience with this.


    sudo swapoff -a
    sudo rm -rf /var/swap
    sudo semanage fcontext -a -t var_t "/var/swap(/.*)?"
    sudo restorecon -Rv /var/swap
    sudo btrfs filesystem mkswapfile --size 32G /var/swap/swapfile
    sudo semanage fcontext -a -t swapfile_t "/var/swap/swapfile"
    sudo restorecon -v /var/swap/swapfile
    sudo swapon -a
    

    Basically, the commands found literally above affect the contents of /var. As such, they’re outside of the ‘jurisdiction’ of rpm-ostree. Reverting these is the same as on any other Linux system.


    The following commands change the contents of /etc. As such, they’re being tracked and can be reverted to their original states. Though, I’m not sure if it’s possible to revert them back to their respective versions without those changes.

    sudo sed -i '\|/var/swap/swapfile|d' /etc/fstab

    I’ll be honest with ya. I don’t know what this one does 😅. I have used sed in the past but wasn’t able to decipher this one. FWIW, it tries to make some changes to /etc/fstab . And, if I’d have to make a guess, I think it deletes any lines that contain /var/swap/swapfile.

    echo "/var/swap/swapfile none swap defaults,nofail 0 0" | sudo tee -a /etc/fstab

    This added some text to /etc/fstab. To revert it, go to /etc/fstab, and remove /var/swap/swapfile none swap defaults,nofail 0 0

    echo "vm.swappiness=120" | sudo tee /etc/sysctl.d/99-swappiness.conf

    This created a file named 99-swappiness.conf and placed it to /etc/sysctl.d/. As such, a simple sudo rm -rf /etc/sysctl.d/99-swappiness.conf suffices.


    sudo rpm-ostree install policycoreutils-python-utils

    This was an optional command. If you did have to invoke it, then you should find policycoreutils-python-utils when invoking rpm-ostree status. It should be mentioned as a layered package.

    To undo it, simply invoke rpm-ostree uninstall policycoreutils-python-utils.


  • Bazzite’s messaging has merit, but we’d be making a mistake by regarding it as absolute. It makes more sense to take them as carefully written guide lines for a specific audience.

    Furthermore. with all due respect, but OP’s writing doesn’t imply installing/managing software with rpm-ostree. Which, is actually the subject of the documentation entry you quoted. As such, I think you might have misunderstood them.

    Youre breaking a core tenant of immutable distros by installing system level packages.

    Finally, FWIW, I absolutely disagree with the above. The page you quoted from seems to agree with me on this: “Layering packages are mostly intended for system-level applications, libraries, and other dependencies.”


  • I made some changes using rpm-ostree related to zram and swap

    Could you be more transparent and/or elaborate in this regard? Like, what did you actually do?

    FWIW, I’ve been on Fedora Atomic since before Bazzite’s existence, but I’ve never once considered using rpm-ostree to make changes to zram and swap. So, I’m a bit confused. To be clear, it’s perfectly possible that what you did is 100% legit, but that it just happened to expose a gap in my knowledge.

    I had assumed that, because I used rpm-ostree, the changes would become part of the “tree” and I could rollback to the original settings. But when I went to look at Bazzite’s rollback tools, it seemed solely focused on rolling back to previous official releases, and I couldn’t find any reference to the specific changes I made.

    Basically, while rpm-ostree does offer git-like control on your base system; hence, why it’s so powerful to begin with. It does not keep more than two deployments around; at least, by default.

    If you would like to keep around a specific deployment (for whatever reason), you can do so with the ostree admin pin <insert number> command. The git-like control also enables you to keep track of:

    • the changes applied to /etc; invoke ostree admin config-diff to see what files have been added or modified since installation
    • layered packages; simply invoke rpm-ostree status

    Keeping track is cool and all, but its usefulness is in full display with powerful applications such as:

    • rpm-ostree reset; this basically removes all permutations. That is, two people on the same image, will have the identical base system after this. (Note that this still isn’t as powerful as a factory reset. For that, refer to this issue tracker on bootc[1].)

    Finally, the git-like structure ensures actual reversibility. On most other systems, installing A -> installing B -> uninstalling A will yield a different state than just installing B. With rpm-ostree, the base system between the two will be identical.


    For completeness’ sake, I’ve used “base system” above to just mean the contents of /usr and /etc (and maybe some other subdirectories of /). Crucially, the contents of /var are not part of the “base system”.


    1. On that note, bootc’s model is arguably better suited if you’re just interested in finding back references to changes you made in the past. Granted, bootc offers a hefty amount of freedom in how you’d approach this and might be overwhelming for now. FWIW, both Bazzite and this are products of this. ↩︎



  • Aight. We seem to have found the culprit. Hopefully it will be fixed soon.|

    I mean why would it say a stable image has a testing id and bootloader if its not testing

    I’m not familiar with the Bazzite Update Tool. I tried to find it on GitHub, but failed 😅. But, if I’d have to guess, it looks at the same wrong place that fastfetch does.