Hi Andreas, On Mon, Feb 26, 2024 at 05:08:09PM +0100, Andreas Beckmann wrote: > can you take a look at #1064350 and #1064842, which may be a regression (not > enough device nodes mounted to /dev) caused by your changes.
I looked, but I'm having difficulties making sense of it. Can you assist with reproducing this somehow? The first bug points at https://salsa.debian.org/nvidia-team/bumblebee/-/jobs/5333059#L218 and line 218 says "Created resolv.conf.". As far as I can see, this is only emitted from create_resolv_conf() which is only called from configure_chroot() and the next thing the function does is to stat self.name + "/dev/null". Given that apt tries to create it later, the most plausible hypothesis is that it raises FileNotFoundError. Then we try to os.mknod it as a character device. If that were to succeed, apt couldn't create it, so it likely raises an OSError with EPERM. Then we try to create it as a regular file. If that were to succeed, apt wouldn't report it as missing. If that were to fail, an exception would unwind configure_chroot and then create and make piuparts crash. Since this is not happening, the most plausible hypothesis seems to be that something deletes /dev/null after this method has concluded. Not much is running there but tmp/scripts/post_chroot_unpack_allow_unauthenticated. Do you see any flaws in this reasoning? Regarding the other bug, I set up incus, launched a debian/sid container and successfully ran piuparts there. The original reports says VM, not container though. I also tried a --vm, but incus didn't like my qemu (probably due to nested virtualization) and refused. I have no idea how to reproduce these failures. The assumption behind your message is that https://salsa.debian.org/debian/piuparts/-/commit/aa916c1eabdc1579fc31e7ff12254df478cc9a14 causes this regression. Before the change, /dev/null is created using the mknod binary. After the change /dev/null is created (also as a character device) using os.mknod (Python function). I have no idea why mknod does not work in these scenarios, but this is not the important part of my change and more of an drive-by optimization (less forks -> more speed was the idea). The important part is handling a failure from mknod and turn it into a bind mount of the original device. From my pov, the change from /bin/mknod to os.mknod can be reverted, but I'd like to understand why it breaks stuff and have no luck at understanding nor reproducing this. Helmut