[Piuparts-devel] Bug#1055508: piuparts: helmut's little wishlist

[Helmut Grohne]

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