I’ve been avoiding distrobox (new at immutable distros) but comes out it’s been very smooth experience! since these are not demanding apps i’m less worried about overhead. AFAIK there’s no auto-update yet though.
To create one (i went with default suggested fedora-toolbox)
distrobox create brave-1password
Go in
distrobox enter brave-1password
Do their installers
curl ``https://dl.brave.com/install.sh`` | sh
(for 1pass, use fedora steps manually from their website)
After a lot of fussing, I found Appimage to be ideal for Chromium based browsers. Requires no layering, preserves full sandboxing capabilities (unlike flatpak), and has web apps with no quirks (unlike flatpak and containers).
Currently using Helium with updates and desktop integration handled by Gear Lever.
Yeah, I noticed that as well. There is a way to fix it, but it takes some work (mainly for the icons). A few months ago I went through the process of learning to make my own custom versions of Aurora, and I even uninstalled the Flatpaks for Firefox and 1Password and installed the package versions using Bluebuild. Bluebuild has a specific module to make 1Password work, since there are some post-installation script hooks that 1Password uses that make installing the package in a normal Containerfile/Justfile a bit of work.
That was fun and all, but I REALLY try to avoid having to manage my own repo for Aurora. It’s not that it’s hard, but I already do that for a Fedora CoreOS and a uBlue uCore server I run, and I didn’t want to add a third repo just to install Firefox and 1Password with the browser extension, just to make the extension work correctly.
Thank you, I forgot about AppImage, and it works great when i use it. 1password has supposedly less obvious AppImage (it’s the .tar.gz install option)! Brave doesn’t have official one, so might as well try Helium (so far only thing missing from Helium is sync, but i use that rarely).
Not sure if i’ll stick with it, but I’m definitely going to try making my own version once (probably with bazzite). Props to doing that with CoreOS, i’ve looked at it for a bit for home NAS and was like “uh no too much work”.
Not as hard as you might think. The hardest part is getting past the whole ignition/Butane thing, and of course you have to start with a Fedora CoreOS image. Once you’ve got a good Ignition config, you can serve it with something like copyparty, which is idiot‑simple to use, and then your system bootstraps.
Although that’s a bit out of scope for this forum (better suited for the uCore forum), if you ever need a ready‑to‑go .bu file to run and quickly generate an Ignition file, here it is. This is copied from another source and it works (below).
After that, you could rpm-ostree layer on anything else you might need, but you really shouldn’t have to. I personally maintain my own repo and build my own image, but you don’t need to do that if all you’re planning to do is run containers and maybe set up Samba sharing or something similar.
There’s already a request and some discussion among the devs about providing ready‑to‑go FCOS versions that let people skip the Butane/Ignition step entirely. If they get that working, I’d imagine it wouldn’t be hard for uBlue to offer similarly easy uCore images as well.
variant: fcos
version: 1.4.0
passwd:
users:
- name: core
ssh_authorized_keys:
- [INSERT YOUR SSH KEY HERE]
# password_hash is OPTIONAL - only needed for local console login
storage:
directories:
- path: /etc/ucore-autorebase
mode: 0754
systemd:
units:
- name: ucore-unsigned-autorebase.service
enabled: true
contents: |
[Unit]
Description=uCore autorebase to unsigned OCI and reboot
ConditionPathExists=!/etc/ucore-autorebase/unverified
ConditionPathExists=!/etc/ucore-autorebase/signed
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
StandardOutput=journal+console
ExecStart=/usr/bin/rpm-ostree rebase --bypass-driver ostree-unverified-registry:ghcr.io/ublue-os/ucore:stable
ExecStart=/usr/bin/touch /etc/ucore-autorebase/unverified
ExecStart=/usr/bin/systemctl disable ucore-unsigned-autorebase.service
ExecStart=/usr/bin/systemctl reboot
[Install]
WantedBy=multi-user.target
- name: ucore-signed-autorebase.service
enabled: true
contents: |
[Unit]
Description=uCore autorebase to signed OCI and reboot
ConditionPathExists=/etc/ucore-autorebase/unverified
ConditionPathExists=!/etc/ucore-autorebase/signed
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
StandardOutput=journal+console
ExecStart=/usr/bin/rpm-ostree rebase --bypass-driver ostree-image-signed:docker://ghcr.io/ublue-os/ucore:stable
ExecStart=/usr/bin/touch /etc/ucore-autorebase/signed
ExecStart=/usr/bin/systemctl disable ucore-signed-autorebase.service
ExecStart=/usr/bin/systemctl reboot
[Install]
WantedBy=multi-user.target
- name: cockpit.socket
enabled: true
- name: podman-restart.service
enabled: true
Overall all this sounds like growing immutable distro pains - no user should have to tinker this much (I’m doing it for fun of learning at this point!) Going to give feedback to brave and 1password, and hopefully with rising immutable distro popularity, something will happen at some point.
Its always about the tradeoffs. As long as you accept what you can’t do without a custom image, you can roll right along but if you want to use something that doesn’t quite fit the partially immutable distro dance, then yea, you have to dig a little deeper. I don’t mind doing it, but I do get what you are saying. In some cases there is a little more resistance to get where you want.
Totally, i also can’t go back to mutable distros anymore, immutable is the way for me!
How do you feel about layering vs custom build? I’ve been avoiding layering by design to force me to learn other ways of doing stuff, but think it’s time to consider it (i’ve started with layering everything which was clearly wrong so i paused that for a bit).
This is for 1password, browser is solved with ashleythorne suggestion above with Helium and Gear Lever. I really like Brave browser but there’s way too much clutter, and Helium feels faster!
With the move from OSTree object stores to full native container images with bootc, it seems to me that the long-term best practice is not to rely on rpm-ostree layering. Getting used to building my own image now means I’m ready for whatever comes next. Building a bootc image on GitHub with a regular Containerfile is not that different from how images are built today. BlueBuild isn’t fully ready for native bootc containers yet. If I had known the Fedora-bootc base native bootc image thats available earlier, I probably would have chosen those instead of Fedora CoreOS for my server. I do run a uCore server on the side, but that’s mainly for experimentation, and I found I didn’t need everything Universal Blue ships with uCore.
rpm-ostree layering is a slippery slope: first you layer one package, then another, and another, and before you know it you’ve got a whole bunch of stuff layered. At that point, rebasing or upgrading to new upstream images can take a long time.
So my first approach is to do whatever I can with Flatpaks, Distrobox, Homebrew, and Podman. If I can’t solve it with any of those, then I build my own image with what I need and rebase to that. I’ve basically decided to avoid rpm-ostree layering whenever possible.
The important thing to keep in mind is that Fedora developers are still figuring out how they want to support modifying the running system image in a world of native bootc containers, instead of today’s OSTree-based object stores. I don’t want to be caught flat-footed if they eventually decide that heavy rpm-ostree layering needs to be replaced by some new, dnf-based mechanism for in-place image customization. Universal Blue will be following whatever upstream does.
Last month I went down a deep rabbit hole researching bootc, OSTree, layering, and the current direction of image mode in Fedora. It was very interesting, but it also convinced me not to rely on workflows that are likely to be deprecated, and rpm-ostree layering looks like one of those.
Thanks for the insights! Definitely going to try building my own then - totally get what you mean by Fedora figuring out ostree. I’ve paused KDE Linux because they are in very early stage of figuring stuff out, and what you wrote helped me understand more what NixOS does right.
I had a concern about building images and depending on github/internet/etc, but i realized that ever since i switched to aurora and bazzite, i already do depend on it.
quick mention since it’s off-topic: it took me 2 hours to finish custom aurora image with apps i’ve needed. It’s remarkable how quick it is! Stuff i’m troubleshooting is less of a blocker (ujust scripts, bazaar broken). Thank you for encouragement!
