Making my first image

Bazzite
1

Hello!

So I have decided to attempt to make my own image, and I have found the template on GitHub, read documentation etc.

A while ago I posted about having a Ujust script for Affinity and now that I looked at making my own image, it sounds like something I can set up when I make it.

The Ujust script would download the correct Elemental Warrior Wine into the Lutris runners folder, and use the Yaml file to instruct Lutris to use that version of Wine.

I tested a normal script and it worked, so I can potentially integrate that in a new image with ujust.

Then I could also make a ujust script for installing some Flatpaks I want like Discord, GPU Viewer, my browser or choice etc.

I have not decided if I want to layer Goverlay on top (I know at my own risk), or just add MangoJuice to the list of Flatpaks above.

I feel the above isn’t the best of reasons why I should make my own image, but it would allow me to practice making one. Mostly because one can just make scripts to install a bunch of Flatpaks, and could also just make a script to make the Affinity installation a tiny wee faster, and I have done.

Also let me see if I understood this correctly:

When making your own image you ARE still potentially overlaying rpm packages via rpm-ostree, but if there are errors, GitHub is better at telling you what the errors are and you can troubleshoot them before you swap to that image on your machine. GitHub makes a build (which I didn’t know it did, still new at this), and that’s how you troubleshoot it initially.

But if you layer rpm-ostree locally (on your machine), then if there is an error you have to rollback. If you have several rpm layers, you then have to figure out which one is not playing nice and why – info which is not really given to you locally.

The new GitHub image will pull the new changes Bazzite does upstram, and automatically rebuild my image periodically. You then know if your changes still play nice with the new Bazzite updates and if so, you are ready to update your own system.

Have I got this right?

1 Like
2

During the container build, you would install applications like a normal mutable system (i.e., dnf5 install). The result is an OCI container that you know has the applications you want in it and you can rebase your OS to use it.

Your understanding of how this process differs from layering on the client system is correct. When layering, the client itself has to do dependency management which might fail and cause the update to not be applied. Conversely, when you build a custom image, the failure occurs in the build process and the client will never see that failure.

Another key is what happens when the image is used by multiple people. Say there was an issue installing a new package X. Anyone that tries to install it via layering will hit the same problem and will have to solve it independently of everyone else. If instead the image included package X, only the image maintainer would have to resolve the issue and all of the people using the image do not have to worry about manually resolving conflicting dependencies on their own for updates.

1 Like
3

Thank you! It all makes sense.

I’ll have a go soon.

4

Okay, I started to look into this, and I know I can just go on github, copy the template, and carry on as the documentation says.

I was wondering though about making a GUI for those steps (which would include also signing the image eventually).

I started making a very rudimentary app with the bare bone options which allowed me to make a local image in podman.

Build-GUI
Build-GUI1148Ă—851 94.3 KB

I still have to check that the image functions correctly, but I do have 12 GB worth of image sitting on my PC now, so it managed to build something :stuck_out_tongue:

I’ll probably install it on a virtual machine to see if it works, before I start looking at the signing and Github integration. I also need to make sure I am actually pulling from the template.

This might be a fool’s errand, but I just wanted a GUI, maybe if successful it can help other people. If not I will have learned some lessons.

1 Like
5

Not to disuade you but Podman Desktop exists as a flatpak:

image
image2560Ă—1405 133 KB

6

I think a “distrobox extension to podman desktop” is what we’d need to make it specialized for distrobox use cases?

7

Ahh thank you, the pitfalls of being new to this space.

I’ll check it out and see if there is anything I can come up with extension wise, but it might be a bit outside of my abilities.

8

On the contrary, see what they do and learn from it, keep going!

2 Likes
9

This kind of comment is so heartening. It may not seem like much, but it is turning this forum lurker into someone keen to experiment with ublue goodness. Thankyou @j0rge for your good spirits and encouragement - it goes well beyond the people directly commenting!

2 Likes
10

It’s all an ecosystem - the idea that “everyone should work on one thing or we’re doing it wrong” is a myth I’d love to slay on the desktop. I’m waiting for my breakfast to cook so if you bear with me lol:

The standard interface here is the OCI one via podman - the container, the runtime, etc. Both Podman desktop and any tool that anyone rights would use these same interfaces. You always, always want multiple implementations exercising common interfaces, that’s what leads to robustness and diversity to that ecosystem. Here’s an example from Kubernetes:

Those standard interfaces that let’s you swap out components, including those runtimes! https://sysdig.com/learn-cloud-native/what-are-container-runtimes/ - and you can swap out all the network components via a thing called CNI, and you can swap out entire storage engines with CSI.

At first this reads like madness. Shouldn’t everyone just pick one set of things and go? The reality is that when you have multiple implementations of these it let’s people plug in stuff. Everything from pure community driven components to fully commercial ones. There are certain use cases that choose people to use a certain component over another. But it’s that API standardization that leads to success.

This is what I’d love to see evolve in the Linux desktop. Our first real flag to plant on this one is making podman a first class citizen on our desktops so developers can count on it being there. We inherited this from Fedora Silverblue and OpenSUSE has it in Aeon. We take it a step further and include podman desktop in dx mode, and also include docker because people use it.

Whichever one you choose, the images are the same, you’re pulling cgr.dev/python or ubuntu/mysql, etc. That’s the winning pattern. It doesn’t matter how you push to quay.io, docker hub, or ghcr.io. You can use buildah, docker, oras, etc. All different tools, using the same standard!

2 Likes
11

So! I have made my first image after bashing my head against a few walls, but I think I am starting to get the hang of it. I also discovered I rather do it via terminal with the method outlined in the Ublue Template.

  1. I temporarily fixed the problem with KDE’s Google Drive integration (by using the GNOME API) I saw in the KDE forums that apparently they don’t have a maintainer for that, maybe at some point I can reach out to them and see if I can help them with that and get their API to work (if no maintainer, maybe they can’t reach who set up the API?); I won’t keep using the GNOME API, I was just trying to see how to make the fix work via making my own image

  2. I also added a “install-my-flatpaks” ujust script as a test, with Discord, OBS and Mangojuice, as I feel will be relevant to a lot of gamers (especially Discord and Mangohud), and OBS if they stream on Twitch or record videos for YouTube (as I do occasionally), potentially also stops requests for Goverlay;

Still on the to do list:

  1. Ujust install-affinity - this was what spurred all of this, but it’s a more complicated script, and since I was trying to solve more basic problems, I didn’t get around to it - would work a bit like ujust install-resolve

  2. Adding Megasync, I am seeing in forums that a lot of people seem to like it if they don’t want to use Gdrive

  3. Maybe include rclone too/instead, if they want more freedom, that should be easy as it’s available on brew iirc

My repo has a random name as it’s a playground for me atm, but if I get to the point where I am happy with it, I guess I need to come up with a better name than “fluffly-memory” :sweat_smile:

I was trying to make a hyprland version with either nwg-shell or ml4w but I was just failing at it - wayblue does have hyprland but no Bazzite kernel, so I got stuck as removing KDE from the Bazzite image seemed particularly painful and my builds kept failing.

Installing kernels myself is a bit out there given the difficulties I was having with more basic stuff.

1 Like
12

I’ve tried installing a different kernel myself, like kernel-cachyos for the 6.15.x version, but build would fail for me as well. I have a bazzite-hyprland repo myself, though currently not using it. GitHub - ndowens/bazzite-hyprland if you want to use/fork it or whatever to add what you want to it. It’s mostly a basic hyprland setup

13

Thank you :slight_smile: I’ll check it out.