You are not logged in.

#1 2024-05-06 00:08:22

Registered: 2024-04-10
Posts: 2

Should arch-chroot be simplified to systemd-nspawn?

Very long-time Linux user, and I've spent the last several months on Arch. The quality of scripts and pkgbuilds is really impressive. However, I'm left wondering why arch-chroot remains such an important and complex script. Arch is a first-class systemd distro, and manually doing the setup of a chroot in a shell script feels pretty outdated.

systemd-nspawn -D /mnt

seems clearly better (or at least equivalent) and lessens the maintenance burden. I'm almost inclined to add the `--boot/-b` argument there, but that would require a more complex user setup before the pivot, even though it offers more capabilities. Setting up systemd units is easier in a nspawn environment than chroot.

The only thing that stands out to me is that systemd-nspawn doesn't automatically mount efivars, which is useful for some of the advanced setups that I utilize (secure boot key enrollment and setting static uefi boot variables). That's easily solved with a bind argument to systemd-nspawn, though.

Does the current bash script and chroot(1) method offer advantages that I'm missing?

Last edited by fandingo (2024-05-06 00:11:26)


#2 2024-05-06 09:17:12

From: London
Registered: 2014-02-20
Posts: 7,771

Re: Should arch-chroot be simplified to systemd-nspawn?

~# systemd-nspawn -D /mnt /usr/sbin/grub-install --target=i386-pc /dev/nvme0n1       
Spawning container mnt on /mnt.
Press Ctrl-] three times within 1s to kill container.
Installing for i386-pc platform.
/usr/sbin/grub-install: error: failed to get canonical path of `/dev/nvme0n1p3'.
Container mnt failed with error code 1.
1~# arch-chroot /mnt /usr/sbin/grub-install --target=i386-pc /dev/nvme0n1
Installing for i386-pc platform.
Installation finished. No error reported.

Last edited by Head_on_a_Stick (2024-05-06 14:16:22)


#3 2024-05-06 09:19:46

Forum Moderator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 12,159

Re: Should arch-chroot be simplified to systemd-nspawn?

arch-chroot is part of arch-install-script which describes itself as "This is a small suite of scripts aimed at automating some menial tasks when installing Arch Linux."

These packages depend on arch-install-scripts :

$ pactree --reverse --sync --depth 1 arch-install-scripts

Have you looked at how those use arch-chroot / chroot and whether they could use systemd-nspawn instead ?

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

(A works at time B)  && (time C > time B ) ≠  (A works at time C)


#4 2024-05-06 16:07:38

Registered: 2012-09-03
Posts: 53,138

Re: Should arch-chroot be simplified to systemd-nspawn?

systemd-nspawn limits access to various kernel interfaces in the container to read-only, such as /sys, /proc/sys or /sys/fs/selinux. Network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and kernel modules may not be loaded from within the container.

chroot and nspawn are simply not the same thing, arch-chroot is a convenience wrapper around chroot when you want to chroot, not to nspawn.
There's maybe overlap in the unshare mode, but arch-chroot mostly serves users to chroot into the system during or to unfuck an installation and not having to setup binds and DNS manually - a container that filters access to the sysfs isn't necessarily helpful in those cases.

Fwwi, there's … spawn.1.en


#5 2024-05-06 17:09:21

Registered: 2024-04-10
Posts: 2

Re: Should arch-chroot be simplified to systemd-nspawn?

I guess my point was more that nspawn does a lot of the heavy lifting, although not all of it. It seems like hundreds of script lines could be removed by changing arch-chroot to use nspawn.


#6 2024-05-06 17:31:20

Inspector Parrot
Registered: 2011-11-29
Posts: 29,714

Re: Should arch-chroot be simplified to systemd-nspawn?

And thousands of lines of systemd code could be removed by changing systemd-nspawn to arch-chroot.

Two tools partially overlapping in their use is only one of two necessary preconditions for ruling that one is better than the other.

To Be A Dev: propose idea; invite feedback; mock, ridicule, and ostracize any critical feedback; but be warm and kind to those who kiss your ring.


Board footer

Powered by FluxBB