Related: https://pagure.io/koji/issue/3567
:thumbsup:
Wait, what? How did we come to this conclusion?
Metadata Update from @tkopecek: - Pull-request tagged with: testing-ready
Metadata Update from @tkopecek: - Pull-request untagged with: testing-ready
I'm pretty sure this patch will break some classes of image builds. Especially ones that use device-mapper and such.
@ngompa This is what I get when I'm running it with bound /dev:
/var/lib/mock/hyperscale9s-spin_media-experimental-el9s-build-198-95/root/dev is pre-mounted and pre-populated. If a pre-mounted /dev is provided it needs to be an unpopulated file system. mknod(/var/lib/mock/hyperscale9s-spin_media-experimental-el9s-build-198-95/root/dev/null) failed: File exists
Huh, okay. Well I guess try it without and if you can get a build to succeed, then we're good...
To be clear, I'm not sure why it happens in this case and what is different with this exact image. It is first time I was not able to build because of this.
DEBUG util.py:445: [ INFO ]: 07:04:25 | Creating raw disk image /builddir/result/image/gdc-c9s-Cloud.x86_64-0.0.1.raw DEBUG util.py:445: [ INFO ]: 07:04:26 | --> creating root partition [with 0 clone(s)] DEBUG util.py:445: [ INFO ]: 07:04:26 | --> setting active flag to primary boot partition DEBUG util.py:445: [ INFO ]: 07:04:26 | --> setting start sector to: 2048 DEBUG util.py:443: [ ERROR ]: 07:04:26 | KiwiCommandError: kpartx: stderr: /dev/mapper/control: mknod failed: Operation not permitted DEBUG util.py:443: Failure to communicate with kernel device-mapper driver. DEBUG util.py:443: Check that device-mapper is available in the kernel. DEBUG util.py:443: Incompatible libdevmapper 1.02.185 (2022-05-18) and kernel driver (unknown version). DEBUG util.py:443: device mapper prerequisites not met DEBUG util.py:443: , stdout: (no output on stdout)
In our images: OCI image is possible to build only when /dev is unpopulated but installable image is possible to build when /dev is populated. So I thing we would need some knob… =(
1 new commit added
allow to set it by user
rebased onto 65622ad08d32816aeb0cc1090665bff3a9c8d5b7
That would mean Koji would need to be aware of the types of images and decide based on that. I.e., only don't enable it when type is docker or oci.
type
docker
oci
Or... just let the user set it, I guess. That works too. And doesn't require us to go back and figure it out for more image types.
I've started with CLI option (--bind-dev). I'm not sure if we can deterministically choose the right one without inspecting whole profile.
--bind-dev
Yeah, that makes sense to me. Whether it's needed or not might be more determined by the underlying tools invoked.
rebased onto 50089f5233bb3e77fdfaaac305d4934937dfb6fc
Metadata Update from @mfilip: - Pull-request tagged with: testing-done
Commit 56cea9ad fixes this pull-request
Pull-Request has been merged by tkopecek
Related: https://pagure.io/koji/issue/3567