36
Have I misunderstood immutable distros? (sopuli.xyz)
submitted 3 months ago by to c/linux@programming.dev
10 comments fedilink hide all child comments
 

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.

all 10 comments

sorted by: hot top controversial new old
[–] 21 points 3 months ago* (last edited 3 months ago) (4 children)

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?

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 7 points 3 months ago* (last edited 3 months 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."

  • permalink
  • fedilink
  • source
  • parent
    • [–] 10 points 3 months ago* (last edited 3 months ago) (2 children)

    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^[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.].)

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

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] [S] 2 points 3 months ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 3 months ago* (last edited 3 months 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.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 9 points 3 months ago (1 child)

    There's even a Doc for that:

    Using Swap for Additional Memory or Hibernation

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •