Using a sysrescuecd USB stick to recover a machine with a bad install, i mount the root filesystem of the broken machine to /tmp/drive, and then use systemd-nspawn to chroot into it. systemd-nspawn --directory=/tmp/drive/ --boot The chroot environment has internet access. However, I see > Unable to configure loopback interface: Operation not permitted for ever package that has pre-merge checks run, for example: > Running pre-merge checks for sys-devel/gcc-11.3.1_p20221209 and > Running pre-merge checks for acct-group/nobody-0 It seems there could be some improvements to the logic for these pre-merge checks, so that inability to configure loopback either fails the package or doesn't get printed out. Reproducible: Always
You need to either disable the network-sandbox feature, or enable CAP_NET_ADMIN in systemd-nspawn.
Basic functionality should work out of the box. Portage shouldn't be warning every package for something that can be detected and and predicted to always fail every time. If systemd-nspawn is known to not support this feature, warn once at the top of the log, and then surpress it for subsequent packages.
(In reply to Michael Jones from comment #2) > If systemd-nspawn is known to not support this feature I think you misunderstand the issue. By default, systemd-nspawn removes the permission (CAP_NET_ADMIN) that Portage needs to manipulate network settings. It's arguably more secure by default. It's not really possible to make Portage's network-sandbox feature work "out-of-the-box" in such an environment. In any case, it's just a warning that you can ignore. Or you can disable the feature to make the warning go away. If you would like to supply a patch to make the warning less obnoxious, we would probably accept it.
Some thoughts from IRC: We would need to check if portage.process._configure_loopback_interface() fails and cache that. That's somewhat difficult since that function is invoked in a sandboxed child process specific to each package being built. So we would need IPC of some sort. I suppose we could spawn a very specific "test child" that does nothing but set up namespaces and configure the loopback interface and report success/failure, and cache the result of that in the main emerge process. That would be executed before we attempt any package operations.
