50
Crapped my system (sopuli.xyz)
submitted 6 months ago by TheMonkeyLord@sopuli.xyz to c/linux@lemmy.ml

This isn't me asking for help or anything, I already replaced it with fedora kinoite. I just felt like talking about this ridiculous venture of mine.

So a couple weeks ago I started hyper focusing on cities skylines, but played on my Xbox. I learned that mods and all kinds of fun custom content was available on PC so I tried to play on my system. Problem, my laptop has an rtx 2070, but I was running fedora kinoite and couldn't figure out how in the world to install nvidia drivers.

So after a bunch of searching around I give up and decide to try installing a "gaming" focused distro in the form of endeavour os. It was awful.

Maybe I am weird but the x11 rendering didn't feel good at all, the lack of some default applications, as well as a bunch of apps I didn't know the purpose of. (This one is my own fault since they have a kde spin, but I remembered why I didn't like gnome) and finally today it froze in the middle of an update and hard rebooted, no longer able to launch.

Worst part, I didn't do a lick of gaming on the thing cause I moved on to Borderlands 3

you are viewing a single comment's thread
view the rest of the comments
[-] Para_lyzed@lemmy.world 5 points 6 months ago* (last edited 6 months ago)

The name "atomic" in the context of operating systems refers to an operation in which all steps are applied without interruption (for instance, atomic operations like locking a file cannot be stopped by system interrupts, and once started are ran to completion regardless of the scheduler). Atomic operating systems take that concept, and apply it to base operating system updates. All changes to the operating system are applied simultaneously without interruption. The methods that different operating systems use for this vary, but since we're talking about Fedora, I'll explain Fedora's image based atomic model using rpm-ostree.

Fedora Atomic is based on an image of the root filesystem that is perfectly consistent across all installs. When you update your system (with rpm-ostree), you fetch the entire root image from the repo instead of fetching individual packages. Updating works similarly to version control software like Git, where each version has a list of changes from the previous one, branches, and a variety of other similar features like rebasing. The operating system essentially runs similarly to a Git repository. rpm-ostree pulls the latest image from the image repository, and creates a new local branch on your system with all the changes in it. The root filesystem covered by the image is immutable (which means it is read-only and cannot be changed), to ensure that the root image is always perfectly consistent with the image from the repo (everything is perfectly reproducible). In order to switch to the new branch, you must reboot into it. This ensures that nothing changes while updating, and since the whole root filesystem is immutable, it's best for stability to load into the new branch through a reboot (to ensure all behavior is consistent). Technically, you can apply changes live, but it is not recommended to do that and requires you to use an additional flag with the rpm-ostree command. This ensures that, in practice, your system is never in a state "between" updates. Once an update starts, it will finish to completion (or it will fail and the update won't be applied), making updating an atomic operation (an update runs to completion, or it essentially doesn't run at all; nothing in between). This is a great safeguard against crashes or power losses during updates.

The benefit of atomic distros is that all installations have a perfectly consistent root filesystem, so the system can be tested by the developers in the exact configuration in which it will be deployed to the end user. Any packages you want to install on top of the root filesystem can be installed in a few ways. Most GUI apps should be installed as Flatpaks where possible (installed to the home folder, which is read-write, so you can do it without rebooting), terminal apps can be installed in a toolbox (a default containerization system installed in Fedora that allows you to emulate a read-write root filesystem by mounting extra folders inside the container), or you can overlay the packages on top of the root filesystem through rpm-ostree. Toolbox has dnf installed in it, so you can install packages inside a container as you would install them in non-atomic Fedora. Package overlays download the packages from the Fedora repos, and mount them read only on top of the root filesystem (hence the "overlay", as the packages are independently mounted over top the root filesystem). Overlays have the highest chance to change the behavior of your system, so they are generally recommended as the last option, since they decrease the benefit of consistent install behaviors, meaning that your extra packages aren't tested as thoroughly as the root filesystem. In practice, overlays don't generally cause any more "instability" than installing a package on a non-atomic distro, but again, it slightly diminishes one of the main benefits of atomic distros.

Essentially, all updates are applied at reboot, which means that you can just have updates running in the background and keep doing whatever you want, and as soon as you reboot, changes are instantly applied (no "installing" to wait for). Your operating system will keep some amount of previous branches (usually the current branch and 2 or 3 most recent branches) so you can boot into a previous branch from GRUB if an update breaks anything without having to restore from a backup. You can then ~~rebase~~ rollback to the previous branch (make the image of the branch you selected your current root image) once you can be sure that everything works properly. You can also rebase into another image entirely at any time (from Fedora Atomic GNOME to Fedora Atomic KDE, or into Bazzite or Aurora for example). The root image will change, but all of your overlays and persistent data will stay. EDIT: Note that rebasing into an image with a different DE might cause config issues, as /etc is mutable, and would be essentially the same as installing a new DE on a non-atomic distro. Some recommend against doing it, whereas some have success at it. YMMV. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example.

Atomic operating systems are emerging as a great option for desktops, as they increase stability, reliability, and recoverability greatly over the traditional model.

[-] root@aussie.zone 2 points 6 months ago

Wow, what a very detailed response. I've only been using Bazzite for about two weeks and still learning about it. Now I have a slightly better understanding of how it all works. 👍

[-] luciferofastora@lemmy.zip 1 points 6 months ago

I asked for a rough description because I didn't wanna bother anyone to take the time for a full, detailed explanation...

...then you come along and write a whole article on it that's most certainly more informative and useful than anything Google would have spat out.

I love that. Thanks so much for taking the time. I also think I'll give Bazzite / Fedora Atomic a shot. The idea of simply rebasing onto a different option to try different things is definitely appealing.

[-] Para_lyzed@lemmy.world 1 points 6 months ago* (last edited 6 months ago)

Bazzite is definitely a great option if you have an Nvidia card or you are looking for gaming performance. It includes some gaming oriented features and optimizations like the System76 scheduler that aren't in the regular Fedora Atomic builds that have the potential to increase performance, and make things easier (such as having a build with Nvidia drivers in the root image). I don't really game at the moment, so I don't have personal experience with Bazzite, but I've been on Fedora Atomic KDE for a while now and it has been a great experience. I've heard lots of great things about Bazzite, so I would expect it to be a similar experience (maybe a bit easier). I feel comfortable recommending both, but the more appropriate choice will depend on what you use your computer for and your own preferences, of course.

While I haven't personally rebased to a different image before, it should be pretty seamless, except for some potential config issues if you are switching to an image with a different DE (i.e. switching from GNOME to KDE). I've seen people in this community mention successfully rebasing to another DE, but Bazzite's documentation recommends against it. I imagine that there may be config issues in /etc or in your home folder from switching DEs, just as may be expected when switching to a different DE on a non-atomic system. Your milage may vary there, essentially; Fedora and uBlue just don't officially test rebasing between different DEs. I usually tend to be cautious in my recommendations, so I generally recommend users to try out different DEs on a VM before deciding on one, and to do a full reinstall when switching DEs. There's a chance that is overkill, but it is certainly safe. Here is a blog post detailing some issues a user had when rebasing from Silverblue to Kinoite as an example. It seems that the issues can be fixed, but since the rebase between DEs is not officially tested, it is prone to small issues like these (though it appears at least some of the ones in that post have been fixed upstream now). The issues in that post were all incredibly minor, so you could likely fix your system in place if you were to try this (maybe you won't even have any issues; half of the post was about an issue caused by the fish shell, which is not the default), though you'd have to know where to look to find any issues (I'd start by checking overlaid packages and seeing if there are any from the old DE). You can always rollback safely, as each previous version the OS saves has it's own unique /etc folder (even though it isn't part of the root image).

Switching between Fedora Atomic and Bazzite is more supported (when you keep the same DE), but different images can add and remove packages from the root image, so you may find that you'll need to overlay packages/remove overlays when switching between them (such as Nvidia drivers). I don't imagine that posing an issue as an end user in most cases (outside of the Nvidia drivers), just thought it was worth mentioning, as it is an edge case that could pop up. That's one of the reasons that adding overlays isn't the first recommendation for installing packages, as they have the potential to make rebasing a bit more complicated for a handful of packages that may be different between different images. I would imagine that an update (or even the rebase itself) would fix any dependency issues (hence why I don't see it being an issue for an end user in most cases), but I don't know that for a fact. None of my information on rebasing is based on experience, except for rebasing to a new major version (i.e. Fedora 39 to Fedora 40), so you should look into that more yourself if you want more concrete details. Also, I mistakenly mentioned rebasing to a previous version of your image from before an update. That is actually called a rollback, and uses the rpm-ostree rollback command, more info here (I've edited my previous comment to reflect that). Bazzite has some good documentation on rebasing here, and I don't see any mention of package conflicts between Bazzite and Fedora Atomic, though you will likely want to remove an Nvidia driver overlay if switching from Fedora Atomic to Bazzite. You very likely won't need to make any other changes. There are people in this community with far more rebasing knowledge than I can provide/find from searching, so you can always make a post asking about it if necessary, and someone should be able to help.

It's also helpful to note that documentation for Fedora Atomic (sometimes you get better search results by using "Silverblue", as that was the original project name), Bazzite, and Bluefin are often interchangeable, as they are all based on Fedora Atomic. You may find some things more easily documented in Bazzite/Bluefin than on Fedora Atomic or vice versa, but much of that documentation applies exactly the same to any version. For any additional information about rpm-ostree, I would unironically suggest reading the manual page through man rpm-ostree or online at a site like this if you aren't comfortable with the terminal interface for man pages (quick tip: you can search for a term in man by typing / followed by the search term, and you can use n and N to go to the next/previous occurance).

I'm just here to help people out when I can, so if my comments are able to help anyone, I see it as time well spent. Sometimes it even helps me learn new things myself, and cements concepts I was already familiar with, so it's mutually beneficial!

this post was submitted on 15 May 2024
50 points (86.8% liked)

Linux

48334 readers
644 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS