I have Bazzite running on a BC-250 machine. A few weeks ago, I made some changes using rpm-ostree related to zram and swap. 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.

  • breadsmasher@lemmy.worldEnglish
    231·
    1 day ago

    https://docs.bazzite.gg/Installing_and_Managing_Software/rpm-ostree/

    Layering packages irresponsibly can be destructiveand may prevent updates as well as other issues until the layered packages are removed.

    Use this method as a last resort and for anything at a “system-level” only since it can pause updates, if the package contains dependency issues with future upgrades, until the package is uninstalled.

    MAJOR caveats using rpm-ostree

    Layering packages can cause severe consequences including:

    • Pause system updates until package(s) are uninstalled.
    • Prevent rebasing to different images until package(s) are uninstalled.
    • Conflict with existing packages as part of the image leading to dependency issues.
    • Updates taking longer to download as you layer more packages to your system.

    Youre breaking a core tenant of immutable distros by installing system level packages. i think that might be your misunderstanding?

    • throwaway403@programming.dev
      6·
      1 day ago

      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.”

  • throwaway403@programming.dev
    121·
    1 day ago

    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. ↩︎

    • user_6282638282@sopuli.xyzOP
      2·
      19 hours ago

      The instructions I followed are in the description of the following video. A lot of what happens with this project is hidden away on Discord servers and I suspect what makes it out to the web has gone through the slop filter.

      https://m.youtube.com/watch?v=A6juAoY70aU

      The bottom line is that I thought this might help with random crashes I’d been having with a particular emulator. Unfortunately it had the opposite effect and the same emulator now consistently hard-locks the system after this “fix”.

      • throwaway403@programming.dev
        3·
        1 hour ago

        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.