I’m working on my transition plan away from Windows and testing out various things in VMs as I do so, and one big hurdle is making sure the VPN client my work requires can connect. Bazzite is my target distro (primarily gaming, work less frequently), though other more traditionally structured ones like Pop!_OS and Garuda are possibilities.
I’m currently trying and failing to get the VPN client working in a distrobox (throws an error during connection saying PPP isn’t installed or supported by the kernel). However, I can successfully get the VPN connected if I overlay the client and its dependencies via rpm-ostree install,
but I read somewhere that Bazzite’s philosophy is to use rpm-ostree
as sparingly as possible for installing software to preserve as much containerization as possible.
Since I can get it working outside of a container, am I overthinking it? Should I just accept that this might be one of the “sparing” cases? Is Bazzite perhaps a poor fit for my use case? I’ve been trying to make sense of this guide, but I’m having trouble understanding how to apply it to my situation, since I’m not that familiar with Docker or Podman.
Yo OP, this is me @poki@discuss.online from another account. I had intended to leave the Lemmyverse for a while, but had to come back earlier than intended when I read your comment 😅.
So, without further a due.
Thank you for your time!
What do you mean with “work in progress”? You’ve been using it relatively often in this thread (and IIRC even in others) when talking about Fedora Atomic and/or uBlue and its technologies. Like, do you consider
dnf
to be work in progress becausednf5
is around the corner?I don’t recall any mention of deprecating
rpm-ostree
, though I might be wrong. But, yeah; it will definitely lose focus in favor ofbootc
+dnf
.I’m not actually sure if it works out just like that as of right now. Creating your own image or bootable container is definitely a powerful tool that can help bypass some imposed limits; like e.g. populating files in
/usr
or baking in (current)rpm-ostree
actions -some of which actually wouldn’t work otherwise (as of right now)- directly into the image. Finally, it allows one to move from an imperative to a declarative system. However, I’m not aware if it enables one to bake-in the installation of.run
files. My only experience with.run
files myself was with Davinci Resolve, but that’s notoriously difficult to install regardless. Thankfully, it’s a popular piece of software and thus avenues have been created by which one could install it on Fedora Atomic and related projects.So, in short, I don’t see how creating your own bootable container would help you to bypass this.
Exactly.
If you achieve it through legit means (i.e. uBlue’s own documentation on this or through a sister project called BlueBuild), then no.
By either of the two earlier mentioned means, the building is done automatically (on a daily basis) by GitHub. Furthermore, when you update, you just receive the latest image from your own GitHub repository in which your own image resides. Updates continue to be done automatically in the background, so you won’t even notice. Finally, if it wasn’t clear yet, you only have to rebase once.
That’s fine. Please feel free to inquire if you so desire!
Alright, having said all of that, let’s get to the crux!
So, did you try the following methods when installing the
.run
file? If so, how did it go?chmod +x
)../.run
./.run --appimage-extract
and then interacting with the AppImage.If all of the above have absolutely failed, I only see three ways going forward:
.run
file within Toolbx/Distrobox? If so, how did it go?EDIT: 😅. I had hoped you’d return with a reply soon~ish. But alas… Uhmm…, I’ll be off for a couple of days and will return only next week. Just wanted to let you know*. FYI, I’ll probs return with (yet) another account.
Sorry I didn’t get back sooner, but I made some progress.
Their words (second video, I think), and more in reference to how they are still working out how they haven’t yet covered all of the use cases (like maybe my needs can’t currently be met by
rpm-ostree
orbootc
).rpm-ostree
has functional limitations, andbootc
is still being developed. Obviously, both are still useable and useful, and Universal Blue has been using them for quite a while. I may have been reading too much into it with the “depreciation” comment.It can’t work on its own. Running with
sh
or making it executable runs the script, but it fails when it tries to write its icon and.desktop
entry to/usr
(it also doesn’t take an--appimage-extract
argument). You can usesudo rpm-ostree usroverlay
to create a temporary FS overlay for /usr, but it’s wiped on the next boot. Still, that allowed the installation to complete.I discovered that it’s installing all of the necessary components to
/opt
, and they remain functional. I was able to manually run the daemon script required and get a WireGuard tunnel established in the client.Now, I’m trying to get a
.service
module to work so it can run automatically as root on a reboot withsystemd
. So far, it’s giving me a 126 exit code, so I still haven’t figured out how to escalate its privileges automatically, but this is the most progress I’ve made to date.