Talk:Systemd-nspawn

From ArchWiki
Jump to navigation Jump to search

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)

The devtools package implements this for Arch packaging, and is used for building everything in the repositories. It's as simple as replacing makepkg with extra-i686-build + extra-x86_64-build. -- thestinger 18:41, 19 January 2015 (UTC)
Cool, i'll give that a try. Thanks :) Captaincurrie (talk) 10:05, 20 January 2015 (UTC)
The workflow is described in DeveloperWiki:Building in a clean chroot, closing. -- Lahwaacz (talk) 13:34, 23 August 2020 (UTC)
That's for building on arch. What about creating an environment that will be used by other platforms ? (reopen) Louson (talk) 11:48, 15 September 2020 (UTC)
There is systemd-nspawn#Build and test packages with a link. Of course there are not such nice wrappers as devtools provides. -- Lahwaacz (talk) 11:55, 15 September 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.)

--Rizsotto (talk) 13:40, 26 September 2017 (UTC)

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.

—This unsigned comment is by Unb0rn (talk) 20:07, 23 June 2018‎. Please sign your posts with ~~~~!

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?

—This unsigned comment is by Buovjaga (talk) 09:12, 25 October 2018‎. Please sign your posts with ~~~~!


/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?

-- Chleh (talk) 22:51, 2 January 2019 (UTC)

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.

Nicolas Bouchinet (talk) 10:49, 18 March 2021 (UTC)