7

I'm trying to get used to systemd, because it seems to be the way that Debian is going.

I want to run Xorg in a chroot on hardware, rather than using networking (which seems to be the canonical way of doing it in a systemd container), because I don't want to install an X server on my host system. I want the host to be a thin, low-maintenance OS.

It is my understanding that systemd-nspawn virtualizes /dev, and therefore does not allow access to hardware.

Running a standard chroot seems to work fine in practice, though I am not sure if there will be any subtle problems with this.

Aside from the guest having direct access to the hardware, is running a "real" chroot on a systemd machine a bad idea? If so, what problems will it cause?

If it is bad practice, is there a way to do this with systemd-nspawn; such as some "unsafe" flag? I'm not finding one on the man page, but according to this page, there is a --share-system flag; which doesn't work for me.

  • No. It is the same as on a non-systemd machine. – CameronNemo Sep 30 '14 at 3:32
  • @CameronNemo thanks. Poettering talks about how systemd does some PID isolation, so I wondered if that could cause any problems with a traditional chroot. – transistor1 Sep 30 '14 at 17:54
4

The systemd developers are pretty against allowing nspawn to access real hardware as this quote from Poettering says:

Well, the way we see it containers are really about getting access to virtualized environments only, i.e. /dev should be mostly empty (modulo /dev/null, /dev/random and friends), and the container really never should get access to physical hardware. This will then of course not allow you to run an X server inside the container.

Other container solutions do support passing through hardware from the host to the container, we just believe it's a bit out of focus for the simple tool nspawn is and should stay.

A "standard" install Arch Linux is systemd based and the wiki says nothing about a traditional chroot as being bad. Assuming that a traditional chroot meets your needs on a non-systemd system, then it should be fine on a systemd system. There may be situations in which the additional "virtualization" of nspawn is helpful, but there may be cases where it is limiting.

  • 1
    Thanks. That is kind of the impression I got-- I also hadn't seen anything about a traditional chroot being bad, but I didn't see anything about it being OK, either. Here, Poettering talks about how systemd does some PID isolation, so I wondered if that could cause any problems with a tranditional chroot. The focus of the article is on how chroot is broken, and nspawn is better, but it was unclear to me as to whether he was saying "don't do it at all". – transistor1 Sep 30 '14 at 11:44
  • ... also, the fact that packages like schroot aren't listed as conflicting with systemd is probably an indicator that it's OK, but just wanted to get some more solid confirmation. – transistor1 Sep 30 '14 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.