You are not logged in.
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)
Offline
~# 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)
Para todos todo, para nosotros nada
Offline
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
arch-install-scripts
├─archinstall
├─archiso
└─devtools
$
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.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
https://wiki.archlinux.org/title/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 https://man.archlinux.org/man/extra/dev … spawn.1.en
Offline
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.
Offline
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.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
There is a discussion on the related project about the switch from arch-chroot to systemd-nspawn: https://gitlab.archlinux.org/archlinux/ … /issues/35
Doesn't look like its progressing very much, could nonetheless be interesting for OP
Offline