oh, you don't need libvirtd and friends in the silverblue host? just virt-manager and deps in a dist
oh, you don't need libvirtd and friends in the silverblue host? just virt-manager and deps in a distrobox container is good enough?
JJlooks like they won't be switching until F39
XBy container-layering I meant not exactly layering by running rpm-ostree installs on the host but installing it in my own rpm-ostree native container image. I don't know if installing in a distrobox would cut it, as as far as I know some of the required deps have some kernel-level interfaces and need to be priviliged on the host.
XSorry for saying it in a bit of a confusing way, I'm not sure what would be a better term for it.
BOk, yes, what you meant is what I would have expected. I was surprised that perhaps one could make it work with what I thought I read.
Bmaybe "host container image"?
it's a new world of terminology
it's a new world of terminology
Xor native container, as that's what they're officially
Xinstalling in native container
adding to native container
adding to native container
BI've been meaning to add libvirtd & virt-manager to my native container image as well, also because the Gnome Boxes flatpak doesn't work well... and really, even when Boxes works, it's still not as good.
Jyou mean just a container right?
J"native container" doesn't seem to make sense in this context to me?
Jyeah the reason I use virt-manager is gnome boxes was just too unreliable for me, flatpak or otherwise. I'll give it a shot next cycle because the ui is nice.
Xnative container as in Ostree Native Container
BI'm going to try, because why not:
C...
BYeah, so, it's what I had assumed... virt-manager is happy to live in a distrobox container as it's just a frontend, but libvirt needs to be on the host
XAhh, cool. I wont be switching to that though as I'd rather just have all the vm-related things on host then.
DGitHub
Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available...
Bah, yes, a rootful container is needed, doable...
thanks for sharing, I knew I'd seen something about it.
thanks for sharing, I knew I'd seen something about it.
XYall didn't really provide any comments about this so I'm publishing a well-documented "demo" version as I can now add repos to the org myself.
XXGitHub
Contribute to ublue-os/images-website development by creating an account on GitHub.
JGitHub![build(deps): bump actions/checkout from 2 to 3 by dependabot[bot] ·...](https://images-ext-2.discordapp.net/external/c6rO7J_VC3SoecMbX8fRlS6n-d_0VWdHWsOaVDACQqw/https/opengraph.githubassets.com/8d5548a5c0d4dd8b4fa682936f7426a753cb549a8c078baee37aad7a3e91ab4a/ublue-os/nvidia/pull/52)
Bumps actions/checkout from 2 to 3.
Release notes
Sourced from actions/checkout's releases.
v3.0.0
Updated to the node16 runtime by default
This requires a minimum Actions Runner version of...
Release notes
Sourced from actions/checkout's releases.
v3.0.0
Updated to the node16 runtime by default
This requires a minimum Actions Runner version of...
JI'm thinking of creating a ublue-os/mainline repo so that I can start to experiment with moving generally useful driver bits from the nvidia image into a general purpose upstream image. Is this a good idea?
JI'm envisioning something like
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/{$FLAVOR}-mainline:latestSounds good to me
CI would enjoy being able to recommend ublue for the QoL instead of a cagey combination of SB and -Nvidia
Рhow would mainline differ from base?
JBase has QoL improvements but also has some first run functionality like installing flatpaks. What I'm proposing is a mainline image intended to be consumed by other images and doing little more than installing additional packages so they don't have to be layered
Рso base would be on top of mainline?
JIn theory, yes. It would be the upstream image in which all other images in the ublue-os organization could derive from
Рlike that?
JYes. Keep in mind that base-nvidia is different from ublue-os/base
Рyeah, gotcha
Рat that point maybe just call mainline amd?
JMainline amd?
РJWhy?
Рactually thinking about it more, nvm
Рnvidia is a patch of mainline
Р(and mainline just happens to be amd, among many other things you could say about it)
JWe could actually have a silverblue-amd now that you mention it, which would be a mainline image with additional amd libraries like rocm
Рis there a planned way to offer composition?
Dfor rocm i don't think that's useful if users use apps with flatpak/distrobox
Dfor example blender
JWe are literally figuring this out as we go along lol
Рyeah sorry I was just wondering, I'm really new to this stuff on top of it being really new
JBut should be fine if layered
Dyes but you need rocm inside flatpak runtime/distrobox container
JThe biggest hurdle is figuring out how to get rocm working at all
