If the user has no shell then probably `sudo -u $user podman` may still work?
If the user has no shell then probably
sudo -u $user podman may still work?
AYou don't want these ones inside the container because your user can't read them anyway (well /etc/shadow can't be read)
AIf you get sudo working inside the container then we can probably use
nsenter -t 1 to get real root
Bthis worked with some caveats. had to start as root, cd to the user's home, then run it and it worked!
ATry changing the password inside the container with passwd (don't pass /etc/shadow and /etc/passwd through though)
BBhowever ... !
Bpodman exec -it -u 0:0 into the container and then do passwd $youruserincontainer <- that worked
J@EyeCantCU nice work getting the builds working! thanks!
BJthis 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 and removed the /etc/selinux mount
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=true which would execute /sbin/init, and there's the Exec= which runs sleep just to get the container goingByea 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!
