Custom new images with general improvements

[boredsquirrel]

Hi!
I just discovered your project and it seems awesome!
We are trying to do something similar but at the moment client-side, which is not really great for user-friendliness of course.

I was wondering what is your focus, only NVIDIA? Are you open for a new image with custom mods?

Our changes currently would be (Kinoite):

• install RPMs: rustc cargo fish lm_sensors cheat distrobox gdb kate pandoc perl-Image-ExifTool pip powertop qemu qemu-kvm virt-manager stacer tlp unrar
• remove RPMs: firefox firefox-langpacks kwrite toolbox kmag
• custom settings:
  • autoupdates including firmware
  • restore copr command
  • remove Fedora Flatpak, install Flathub
  • add SDDM themes as RPMs
  • add a grub theme, fix grub double entry issues
  • add fish as standard Terminal shell but not user shell
  • add lots of fish/bash aliasses for easier use
  • adding an "autostop" folder working like an autostart folder, where you put scripts that should run on shutdown
  • integrating some KDE templates
  • adding some useful desktop appstarters
  • setting up waydroid
  • removing a few systemd services
  • setting up systemd-resolve for security and privacy
  • remove the KDE splash screen
  • unify Flatpak and system style
  • disabling Baloo
  • add MSFonts, fix NotoSans ColorEmoji not displaying correctly
  • disable power-profiles-daemon and replace with TLP
  • maybe setting up custom energy saving scripts for laptops using KDEs profiles
  • enable wayland rendering in Firefox
  • fixing keyboard backlight
  • setting battery threshhold on Laptops
  • disabling workqueue on SSDs
  • link useful folders for users to edit,
  • maybe have an option to use the hardened kernel once installing is working
  • fix fan courves not working
  • installing hardened Firefox and Thunderbird profiles based on Arkenfox with custom softening and hardened Thunderbird with custom softening (not yet published)

for Gnome mostly the same but with some differences, probably preinstalled Tweaks

[castrojo]

Hi there! My first foray into this was also doing it as a post-install script, the nice thing is you don't have to throw any of that away, mostly adapting it to the workflow, it didn't take as long as you'd think.

Right now the focus is on the main and nvidia images -- generally speaking we're keeping those as close to vanilla as we can keep them but with just enough quality-of-life to make them suitable as drop in replacements for people that want the hardware enablement and codecs.

The main issue with having more custom images in the core is builder time, which we carefully coordinate across builds so we're not resource starved when making the images. We're not really set up to host a ton of images in this org due to that. However these limitations are due to the way github does it's free plans and builders, we can work around that. 😄

I think the way to do this is , you could set up a structure just like we have here, and then just start with kinoite-main, and kinoite-nvidia as your base images, then you can concentrate on building what you want on top. Having it in a separate github org will give you your own runners for builds and then you'll be self sufficient.

I'd be happy to lend a hand setting you up (the cosign part is the one people have the most trouble with) and then just hang out in the Discord, most of the coordination that needs to happen is around sharing improvements to the github actions and learning how all of this works, and those parts will apply no matter where the images end up living. I'd be happy to help!

[boredsquirrel]

Awesome project!

I just forked your older ublue repo, may update it to the new one. Locally I made most of my configs, and its a lot more detailed stuff like adding polkit rules, custom scripts and all, having it as an image is so useful.

I am really happy that this works, no experience at all with this topic, how Github builds images and so on, but it sounds great!

I will probably just maintain my own repo and builds, to decentralize the load.

At the moment I just use plain Kinoite as I know the tweaks and weird issues it has, for example no zenity preinstalled.

Thanks a lot for your initiative! Its a huge kickstart. In our repo we collected looots of issues and all the commands needed to solve these, have a look at them and maybe profit from them. Many are great for usability. And your framework is perfect to use these fixes.

An understanding question: the Containerfile runs on Github, but as Fedora? And you can execute Fedora commands in there? All the rpm-ostree and other commands will be there and not at the users side, not even displayed to them? That would be great! Also I have a var/home/user directory with many presets like bash aliasses and a few flatpak configs carefully selected out, can this Github Container build copy them to a user or is that out of reach of the image itself?

[castrojo]

An understanding question: the Containerfile runs on Github, but as Fedora? And you can execute Fedora commands in there?

The runners are actually normal github hosted ubuntu runners, they just execute a podman build of the thing in the repo. If you clone the main repo and do a podman build . in that directory it's basically doing that but in a github runner, then our actions take that image and push it to the github registry (ghcr.io), which the clients then use to boot off of. You're correct in that, the user never sees the rpm-ostree composition, which means, when there's an error, it's in github and not on the client PC. Here's an example of something that broke in Fedora 38:

https://github.com/ublue-os/nvidia/actions/runs/4527461422/jobs/7973413534

Instead of that error showing up on the clients the build just fails here (but the 37 ones succeeded, so those get pushed). Then as things resolve themselves the new images get pushed and the user would never see the transient error.

EDIT: Also check out the coreos layering examples: https://github.com/coreos/layering-examples -- and as you play with them you'll start to find out how the rpm-ostree part works.

Also I have a var/home/user directory with many presets like bash aliasses and a few flatpak configs carefully selected out, can this Github Container build copy them to a user or is that out of reach of the image itself?

Here's where it gets tricky, part of the reason this model works is a clean separation between the system and the user's data. Right now we only do what we have to so we're not stomping in the user's space. One is to add a oneshot service to allow yafti to run for flatpak installation: https://github.com/ublue-os/yafti - that way the user can determine what they want installed in their area. If you want to do goodies in bashrc, etc, you need to think like a distro and put it in places like /etc/skel and not manually try to append or write to the user's dotfiles. So far nothing bad has happened but we're still figuring out best practices!