[kwlug-disc] linux distro for nontech windows user

Mon Oct 20 09:25:19 EDT 2025

I didn't try virtualbox. I installed Kinoite yesterday on the bare metal of my T14 Thinkpad, no VM.

Getting the install to work took some experimentation. I downloaded the ISO and tried to "dd" it onto a USB stick. This didn't work, something was corrupted. So I followed the official instructions and used the "Fedora Media Writer" GUI program to make a bootable USB stick, and that worked fine. This program is specifically designed to make bootable media for a Fedora distribution, that's all it does. You can select the Fedora edition or spin that you want, and it will download the iso, or you can give it an iso file. It is available for all Linux distros, as well as Macos and Windows.

I'm not experiencing the same problems that you are having in Virtualbox.

I just upgraded my system using the GUI (Discover) and no errors were reported.

Then, from the shell,
$ rpm-ostree status
State: idle
Deployments:
 fedora:fedora/42/x86_64/kinoite
                 Version: *42.20251020.0* (2025-10-20T00:39:01Z)
                  Commit: a2093b4d7c872106baaea2a4f6810747c8828d51b06833b43cd30ab70bb493ef
            GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944
                    Diff: 791 upgraded, 15 removed, 37 added

● fedora:fedora/42/x86_64/kinoite
                 Version: *42.1.1* (2025-04-09T11:06:54Z)
                  Commit: 0dcb91a4a626facc4c440c5a95926e5591e83fb56ca7b13408275472fac9bd28
            GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944

This is showing that I am currently running version 42.1.1. The new version, 42.205... is staged and will run after I reboot.
Running this command with --verbose shows a ton more information, including every package upgrade.

After rebooting,
$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/42/x86_64/kinoite
                 Version: *42.20251020.0* (2025-10-20T00:39:01Z)
                  Commit: a2093b4d7c872106baaea2a4f6810747c8828d51b06833b43cd30ab70bb493ef
            GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944

 fedora:fedora/42/x86_64/kinoite
                 Version: *42.1.1* (2025-04-09T11:06:54Z)
                  Commit: 0dcb91a4a626facc4c440c5a95926e5591e83fb56ca7b13408275472fac9bd28
            GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944

The 42.1.1 deployment is still there, but I'm now running the latest version.

There are two ways to switch to the previous version.

If I reboot, and hit Tab a bunch of times while the reboot is occurring, then I get put into a Grub menu where I can select one of the two above deployments to reboot into.

The command "rpm-ostree rollback" should roll back to the previous OS "deployment". 

Each deployment has its own copy of /etc. However, the /var filesystem is shared by all deployments. The /var filesystem includes the contents of /home and /usr/local.

The raw data is stored in /ostree. The contents look vaguely like the contents of the .git directory within a git repository.

Doug.

On Mon, Oct 20, 2025, at 9:34 AM, William Park wrote:
> I tried Fedora Kinoite 42-1.1 and 43-beta in VirtualBox (7.2.2).
>  • Both installed OK.
>  • Right after, they show 12 updates waiting.
>  • I click "Update All".
>  • I get 10 errors, and they're unusable after that.
> Maybe it's my VirtualBox, I don't know.  At least, *Mint* (XFCE + KDE) is standard layout.
> 
> By the way, doesn't *Fedora* have ability to "revert" back to last snapshot?  I remember, reading about it.
> 
> 
> On 2025-10-20 00:20, Doug Moen wrote:
>> William, probably just ignore what I said earlier. I've upgraded my Thinkpad from Mint to Kinoite now, and I'm still trying to understand how it works.
>> 
>> The underlying filesystem is btrfs. The root file system is mounted as a readonly composefs file system. The "OSTree" system, which appears to be a git-like version-controlled package manager, implements a "content-addressable object store", where multiple versions of the same file can exist. These files are immutable and are addressed using their content hashes (which is roughly how I believe git works). Multiple different versions of the same package can coexist in the object store. Multiple releases of the operating system can co-exist in the object store. Metadata is used to describe a particular version, which then corresponds to a particular tree of files and file content (which, note, is immutable). This metadata is interpreted by the composefs file system driver to materialize an immutable tree of files for a specific OS release.
>> 
>> With this system, you can't directly modify the files of the core operating system in the usual way, eg by editing a text file. The root filesystem is readonly. Instead, the way you modify it is by installing, upgrading, or removing a package (together with its dependencies). (Note that you can edit files in /etc.)
>> 
>> I am free to install any package I want into the core OS. I'll be installing RPMs, since this is Fedora. The core OS package manager is called rpm-ostree. OSTree keeps track of the history of package installs as a sequence of git-like commits, or layers (like in a container repository).
>> 
>> Until now I've mainly used Debian based distros: Ubuntu and Mint. My typical habit is to install all sorts of weird software from 3rd party repositories. Eventually the package system somehow gets corrupted and a bunch of things break when I upgrade the operating system. OSTree is supposedly more resistant to this kind of corruption to due the additional structure it keeps track of. One big benefit is that if you install a package and all its dependencies, that change will be applied as a single atomic transaction, either all or nothing. And then you can cleanly revert this change later, without ending up with packages that are no longer referenced and must be garbage collected.
>> 
>> One thing I managed to do a while back was corrupt the C compiler, clang, after an OS upgrade. I have no way of knowing how this happened, and there's no way to fix it other than wipe the disk and do a clean OS install. The Mint documentation warns you that this can happen, and tells you to do a fresh install as the solution, so it's not just me. It must be inherent in the way that the Debian apt package manager works. The Mint docs say you are particularly at risk when you use 3rd party package repositories.
>> 
>> With Kinoite, you are encouraged to be choosy about what packages you install in the core OS. For development work, you are recommended to work in a container. You can have multiple containers with different versions of the same languages, and they don't conflict with each other. Upgrading the operating system won't break any of your containers. You can delete a container without modifying the core operating system or interfering with any of the other containers. Kinoite pre-installs a container tool called "toolbox", which allows you to create a custom environment in which you can install packages, then you can run a shell in this container.
>> 
>> For GUI apps, you are encouraged to install flatpaks, instead of installing apps directly into the core OS (although either will work). The new install of Kinoite came with an old version of Firefox in the core OS. I don't use firefox anymore, because it is riddled with advertising and spyware. I installed LibreWolf and Ungoogled Chromium from flathub, and they work flawlessly. They were a bit buggy on Mint, which had soured me on the use of flatpaks, but on Kinoite, it appears that flatpaks just work.
>> 
>> Instead of Cinnamon, I'm using KDE. They are very, very similar; both are essentially clones of the classic Windows desktop environment. On my previous Cinnamon install, the desktop magnification feature was buggy and flaky. I rely on this due to my eyesight. On my new system, it is so far rock solid.
>> 
>> I'll need to use the system for 6 months and go through a few upgrade cycles before I know if I like this, but so far it is my best experience yet for desktop linux.
>> 
>> The installation process is not beginner friendly, and setting up dual boot correctly in particular is claimed to be tricky, but once installed, it is quite beginner friendly. LIbreOffice is not preinstalled, but it's in the app store, which is pinned to the dock. A beginner would just be installing flatpaks from the app store, and not messing with the command line tools that I mentioned.
>> 
>> There are other distros that work this way, not just Fedora. Eg, Vanilla OS <https://vanillaos.org/> is debian based. Search for "immutable linux".
>> 
>> Doug.
>> 
>> On Fri, Oct 17, 2025, at 8:38 PM, William Park via kwlug-disc wrote:
>>> 
>>> On 2025-10-17 07:04, Doug Moen wrote:
>>>> The system doesn't switch over to the new release until you reboot, when it will atomically switch over to the new release. Internally, the atomic switchover doesn't require moving or copying files, it's just a single file that changes to point to the new release. If the new release has problems, you can roll back to the previous release, either in the boot menu, or in the GUI app store.
>>> 
>>> Single file?  Ahh, mount this "os file" read-only, and then do overlay.  If "os file" can be selected like "kernel" now, then it would be easier for users.  My only concern would be speed.
>>> 
>>> But, having separate /home partition, and 2 root partitions (current and old) would be same thing, no?  Just don't wipe the *whole* disk, when installing distro. :-)
>>> _______________________________________________
>>> kwlug-disc mailing list
>>> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
>>> with the subject "unsubscribe", or email
>>> kwlug-disc-owner at kwlug.org to contact a human being.
>>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20251020/eb50748d/attachment-0001.htm>