Avoid disabling SteamOS readonly by migrating Waydroid to using Distrobox / Podman
Closed this issue · 22 comments
Distrobox and Podman are included in steamOS 3.5.
With distrobox-host-exec, we should be able to have a rootfull container set up and maintain the install that could auto rebuild the binder modules when it detects a new kernel.
We could build with distrobox ephemeral so it temporary makes a distrobox container that is automatically destroyed once the build is done and modules are exported.
We can use Systemd if we need to overlay any files on the system with a overlayfs like using systemd-sysext
Yes I thought about doing it via distrobox but decided to skip it for now as i want to have a firm understanding first how waydroid works without the added layers. there are other things i want to add to the script to improve it, once that is done i'll try experimenting with distrobox.
Yes I thought about doing it via distrobox but decided to skip it for now as i want to have a firm understanding first how waydroid works without the added layers. there are other things i want to add to the script to improve it, once that is done i'll try experimenting with distrobox.
https://github.com/Vanilla-OS/waydroid-image with some of your scripts to improve audio latency should do it. the only show stopper is figuring out how to deal with the anbox-modules
Hey there, I just wanna say thank you very much for making Waydroid possible for Steam Deck, its been amazing and launching apps from the steam ui is something i always wanted do so thank you very much. Also thanks for answering this question, i've been doing some research and testing on this to see if its possible to run Waydroid inside distrobox, again thank you and hopefully we can get Waydroid running inside distrobox in the future.
Thank you
I have asked this from various people back before waydroid was working at all on the deck... If i recall correctly waydroid will not work correctly through distro box because of how it has to use and interact with the host kernel and have modules built for it.. and a bunch more of technical stuff i don't recall off hand. A minor issue is it would also have to have distrobox run as root.. which i don't remember if you can get it to on the deck.
distrobox run as root - yes - https://github.com/89luca89/distrobox/blob/main/docs/useful_tips.md#run-the-container-with-real-root
execute command on the host, while inside of a container. - Yes - https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-host-exec.md#description
Does waydroid run inside distrobox? - Yes - https://github.com/89luca89/distrobox/blob/main/docs/useful_tips.md#using-waydroid-inside-a-distrobox
Only thing left is compiling the modules if missing for the Host OS current kernel version and then load them to steamOS.
Only thing left is compiling the modules if missing for the Host OS current kernel version and then load them to steamOS.
are you referring to the binder kernel modules?
if need to recompile the binder kernel modules then i think might as well go ahead and install the waydroid outside distrobox.
but if the binder kernel modules is within distrobox and survives an update then that is good its fully contained.
Looks like Changes in /etc/ are preserved in /var/lib/overlays/etc/upper/ via an overlayfs, meaning that they survive updates. Thus we can have a service to check on boot if the kernel changed thus needing new binder kernel modules
first hurdle -
distrobox --root complains of insufficient disk space. i tried to test several containers images and getting the same error -
distrobox-create --name waydroid --image archlinux:latest --root
distrobox-create --name waydroid --image fedora:38 --root
i have ample disk space so i dunno why it complains if i use the --root parameter.
without --root it creates the container fine.
Ah crap... I forgot that I was using a old static install of distrobox and apparently not with the system one.....
Doing this via the native system install would prob be a pain since podman uses “/var/lib/containers" for all rootfull things and steamOS /var is 230M with around 66M free....
Which means to use podman without distrobox and pass the flags or... to make system podman/distrobox work, modify "/etc/containers/storage.conf"
change to a location a bit more spacious like in /opt, /srv, or /home:
graphroot = "/var/lib/containers/storage"
And do a podman system migrate as root after the changes.
Found what I needed to basically sync my binder module builds with my mainline time to go get distrobox waydroid to work and then see about combining this.
https://gitlab.com/popsulfr/steam-deck-tricks#use-podman-to-create-a-steamosarch-development-image
I plan on making a docker/podman image build file that defaults to stable but envs can be set for mainline etc to generate the container image with everything needed to build the modules on the deck or… automatically
For Steam Deck /etc
iwd/ NetworkManager/ sddm.conf.d/ ssh/ systemd/ are the only paths that are persisted through upgrades/downgrades.
+1
SteamOS 3.6.0 Preview
Modified files in /etc are now migrated to new OS versions based on a whitelist
Fixes numerous issues with incidentally touched /etc files becoming 'sticky' and persisting unexpectedly
Now that this blocker is out of the way. I can see about getting that kernel model possibly overlayed and enabled on boot
SteamOS 3.6.0 Preview Modified files in /etc are now migrated to new OS versions based on a whitelist Fixes numerous issues with incidentally touched /etc files becoming 'sticky' and persisting unexpectedly
Now that this blocker is out of the way. I can see about getting that kernel model possibly overlayed and enabled on boot
havent poked around that much on the new 3.6 Preview. kernel module resides on /lib/modules so that will still get wiped on future updates in 3.6?
SteamOS 3.6.0 Preview Modified files in /etc are now migrated to new OS versions based on a whitelist Fixes numerous issues with incidentally touched /etc files becoming 'sticky' and persisting unexpectedly
Now that this blocker is out of the way. I can see about getting that kernel model possibly overlayed and enabled on boothavent poked around that much on the new 3.6 Preview. kernel module resides on /lib/modules so that will still get wiped on future updates in 3.6?
Forget overlaying to /lib/modules.. hello "insmod /path/to/steam-deck-binder.ko"
(we can auto do this with systemd)
oh i like that!
and for the waydroid, cage and wlr-randr binaries just place then somewhere in the home folder so it doesnt get wiped on SteamOS updates, then configure the /etc whitelist and all good! I think thats a good plan and doable.
oh i like that! and for the waydroid, cage and wlr-randr binaries just place then somewhere in the home folder so it doesnt get wiped on SteamOS updates, then configure the /etc whitelist and all good! I think thats a good plan and doable.
We could also probably have a build the latest stable / beta / etc script to spin up a podman container to build that kernel if the users did not want to wait on this project to update.
I don't think there would be a need to run this entirely inside podman / distrobox.
hang on forgot to mention - this is only good when kernel stays the same on each SteamOS update. If there's a new kernel then still need to appropriate build kernel module for it
https://github.com/SteamDeckHomebrew/holo-docker/tree/main
https://steamdeck-packages.steamos.cloud/archlinux-mirror/sources/?C=M&O=A
Should be able to auto build the module with GitHub actions or do it in the deck itself. Could do a version check on start and if matches, start, if not check for the new binder module on git or pull the dev container and build.
The initial version of the script it does that - build everything from the deck itself. With pacman repos going out of sync that's why i decided to just build on my machine and send the package that way. Makes it more cleaner too, faster install and space efficient - no need to install additional packages for building.
With that said - i dont think etc whitelist will be sufficient for this. This project will have to rely on the current method and please create a PR for enhancements.
ETC whitelist should be able to handle this… my free time is almost non existent but I’ll work on a systemd systemd unit that can kick off a one shot user systemd service to run a user container using the built in podman to build the model matching the current kernel, or we do it all from waydroid run scripts…. I’ll make the podman build file to generate the kernel and let you decide from there.
When I said container build file I really mean a simple shell script to build the module on arch and wrap it in a container file to provide arch os for it to run on. If you already have this done then I can use that and we can also see about using GitHub to auto build it (we can from the container file)