@EyeCantCU nice work getting the builds working! thanks!
@EyeCantCU nice work getting the builds working! thanks!
B
Jthis one is above my skill level if someone wants to take a look: https://github.com/ublue-os/nvidia/pull/140
GitHub
This makes it possible to run it on arm64 macOS.
JI like the idea of building stuff on fcos so that we can just use the stable channel, the less numbers to keep track of the better, heh.
ENo problem. Glad the ball is rolling again. Want to add the GNOME extension but for whatever reason every time I tried building it COPR failed to remove the chroot environment. Given the same extension compiled just fine for Bazzite yesterday, I'd imagine it's a COPR bug and I'll just try later today or tomorrow
Band success @akdev - I got sudo access by using the podman exec -u 0:0 to add my container user to the sudo group
Bnow it's down to selinux issues.
Aselinux should actually be ok, what issues do you have now?
BBafter gaining sudo in the container I did an apt update & apt upgrade
Bsuccess!
Bi removed
--privileged
B@bketelsen do you know if you can run commands during the pre/post startup of theis container maybe most of distrobox stuff could be implemented to this
Bsince distrobox uses multiple approches to get stuff in some of them are doing mount commands and such
Bi studied the distrobox inits - they are a work of art.
Bthere seem to be two options for running commands. There's
RunInit=trueExec=yea and cold start is also one
Bcold start on these hurts because there's no system cache of containers for rootless podman, so the container will be pulled the first time no matter what
Bthe edge doesn't bleed any harder than this - we're there
Bstill very cool
Jis this replacing the entire shell? like if you ctrl-alt-f3 and login to that tty, that's containerized right?
JI was wondering if we could do it so it's transparent when opening a terminal
Jthat way if you need a host terminal the system is still "normal"
Jalright, 8 watts on the plane with the framework image
Jthis can totally work
ACan you try
--rootfs /:OAIt would be neat
AThis will create a container by using the current system as base
ARuns in an overlayfs
AThis means no disk/network overhead
Jcan someone ack this?
JGitHub
(sorry on a plane will add more detail later) We may have a volunteer to help do this after I announced the project on the framework forums. Just outlining what we'd need to do this. The TLDR i...
Jalright!
JI'm starting notes on this as matt from framework has a friend who is keen on getting started contributing to oss ....
Jso this might be a nice virtuous circle
BI couldn't get that one working.
Asad, it probably needs real root access
Bi couldn't figure out a way to make the :0 part work in the container definition file, everything I tried failed with a parsing error
Band without the overlay bit it failed because it was trying to create stuff in /run
Bi'm curious if all of these examples in the docs
just work in regular fedora and we're bucking the system with the silverblue stuffJGitHub
Since the latest systemd supports "soft reboots", we can distinguish whether there's a kernel update pending and invoke systemctl reboot or systemctl soft-reboot as appropriate.
Jboom shacka lacka!
Buuuu
Dso --apply-live will be applied without reboot soon?
JI am not sure, you have all the info I have
K--apply-live already applies without a reboot wym
Kthat's the point
Kit means now you'll nearly instantly reboot your machine by booting a new ostree image on the same kernel when there's no kernel update
Kfor normal updates
JWe're at 1,242,010 image pulls now
