systemd-nspawn as a build environment
I've been struggling trying to set this up and i assume others will as well. Would be nice to have an example of a build workflow using this tool on this or on a seperate page. Captaincurrie (talk) 18:32, 19 January 2015 (UTC)
extra-x86_64-build. -- thestinger 18:41, 19 January 2015 (UTC) package implements this for Arch packaging, and is used for building everything in the repositories. It's as simple as replacing
- The workflow is described in DeveloperWiki:Building in a clean chroot, closing. -- Lahwaacz (talk) 13:34, 23 August 2020 (UTC)
- You can also freeze a systemd-nspawn archlinux container that you can reuse later in order to keep the same environment. I used to combine systemd-nspawn with the archlinux archive but it's broken (changing the password returns an error: Authentication token manipulation error). It can be useful to build a kernel or a system with yocto or buildroot which are dependant of the gcc version. Louson (talk) 12:18, 15 September 2020 (UTC)
Missing configuration of allowed devices
The other thing I have not find here is, how can I use devices from the container... Was set up an mpd server which needs network connection and an audio sink. My case the audio sink was ALSA devices (and not pulse socket). Had problem to undersand that I need to bind the device files to the container. (In the
.nspawn file.) And also need
DeviceAllow=char-alsa rwm line in the
.service file. (Or to be precise in the
override.conf of the service file.)
Wayland desktop environment inside nspawn
It would be great if someone with expertise wrote a section regarding starting graphical environments inside nspawn containers. It looks like there is some info on Github. This example shows how to run desktop environments in nspawn containers win kwin_wayland compositor. It should be possible to achieve this with mutter too, as it even supports nested mode with something like mutter --wayland --nested. Also we should be able to open new dbus session with something like eval $(dbus-launch --sh-syntax). Also it would be great if someone explained which packages could be omitted inside the container (like we don't need xorg org wayland installed if I get it right) on some popular distros.
linux-firmware causing issues with systemd-tmpfiles-setup.service - still relevant?
The systemd bug report connected with the issue was closed 27 Apr 2018: https://github.com/systemd/systemd/issues/791 Do issues remain or is the fix good enough to remove the note?
/tmp/.X11-unix contents have to be bind-mounted as read-only - still relevant?
For me (systemd version 239) X applications also work if /tmp/.X11-unix is bound rw. Can anybody confirm that?
- I confirm it works with normal binding. Also the linked bug report is closed and apparently solved since 2017. -- Bonob (talk) 17:36, 27 November 2019 (UTC)
Using machinectl without root permissions
In the Using machinectl without root permissions section of the systemd-nspawn wiki, the two PolKit rules that allow PolKit actions that start with org.freedesktop.machine1. enable the subject user to login as any other user including root without password using the following machinectl command:
$ machinectl shell --uid=root
Most of the default actions of the org.freedesktop.machine1.policy are backed with the auth_admin element which requires the PolKit defined administrator to identify itself. Note that the PolKit defined administrator defaults to any user who is in the wheel group and this is already reasonably flexible.