12025 2017-09-01 07:29:24 +0000 Mixing systemd and non-systemd builds for different MACHINEs confuses dnf 2018-07-07 12:57:31 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.2 x86 Multiple RESOLVED FIXED Medium+ normal 4.99 1 richard.purdie richard.purdie meta.mr.watcher meta.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 76437 0 richard.purdie 2017-09-01 07:29:24 +0000 If I enable systemd: DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" $ MACHINE=qemuppc bitbake systemd $ MACHINE=qemumips bitbake systemd <remove above systemd enablement> $ MACHINE=qemux86-64 bitbake core-image-minimal-initramfs I see the rootfs fail: ERROR: core-image-minimal-initramfs-1.0-r0 do_rootfs: Could not invoke dnf. Command '/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/recipe-sysroot-native/usr/bin/dnf -y -c /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/rootfs/etc/yum.repos.d --repofrompath=oe-repo,/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/oe-rootfs-repo --installroot=/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/rootfs --setopt=logdir=/media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/temp -x busybox-syslog --nogpgcheck install initramfs-live-boot udev run-postinsts busybox initramfs-live-install initramfs-live-install-efi base-passwd' returned 1: Added oe-repo repo from /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/oe-rootfs-repo Last metadata expiration check: 0:00:02 ago on Fri 01 Sep 2017 07:17:04 AM UTC. Error: Problem: conflicting requests - package udev-1:234-r0.mips32r2 does not have a compatible architecture - package udev-1:234-r0.ppc7400 does not have a compatible architecture tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/oe-rootfs-repo/rpm$ find -name udev* ./ppc7400/udev-hwdb-234-r0.ppc7400.rpm ./ppc7400/udev-extraconf-1.1-r0.ppc7400.rpm ./ppc7400/udev-extraconf-dbg-1.1-r0.ppc7400.rpm ./ppc7400/udev-234-r0.ppc7400.rpm ./ppc7400/udev-extraconf-dev-1.1-r0.ppc7400.rpm ./mips32r2/udev-extraconf-1.1-r0.mips32r2.rpm ./mips32r2/udev-extraconf-dev-1.1-r0.mips32r2.rpm ./mips32r2/udev-hwdb-234-r0.mips32r2.rpm ./mips32r2/udev-234-r0.mips32r2.rpm ./mips32r2/udev-extraconf-dbg-1.1-r0.mips32r2.rpm ./i586/udev-extraconf-dev-1.1-r0.i586.rpm ./i586/udev-extraconf-dbg-1.1-r0.i586.rpm ./i586/udev-extraconf-1.1-r0.i586.rpm ./core2_64/udev-extraconf-dbg-1.1-r0.core2_64.rpm ./core2_64/udev-extraconf-1.1-r0.core2_64.rpm ./core2_64/udev-extraconf-dev-1.1-r0.core2_64.rpm $ MACHINE=qemuppc bitbake quilt-native $ MACHINE=qemumips bitbake quilt-native [triggers it to clean up unreachable recipes such as systemd which is now not enabled] I can then successfully build core-image-minimal-initramfs as the problematic rpms were removed. tmp/work/qemux86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/oe-rootfs-repo/rpm$ find -name udev* ./ppc7400/udev-extraconf-1.1-r0.ppc7400.rpm ./ppc7400/udev-extraconf-dbg-1.1-r0.ppc7400.rpm ./ppc7400/udev-extraconf-dev-1.1-r0.ppc7400.rpm ./mips32r2/udev-extraconf-1.1-r0.mips32r2.rpm ./mips32r2/udev-extraconf-dev-1.1-r0.mips32r2.rpm ./mips32r2/udev-extraconf-dbg-1.1-r0.mips32r2.rpm ./i586/udev-extraconf-dev-1.1-r0.i586.rpm ./i586/udev-extraconf-dbg-1.1-r0.i586.rpm ./i586/udev-extraconf-1.1-r0.i586.rpm ./core2_64/udev-extraconf-dbg-1.1-r0.core2_64.rpm ./core2_64/udev-extraconf-1.1-r0.core2_64.rpm ./core2_64/udev-extraconf-dev-1.1-r0.core2_64.rpm For some reason its preferring the invalid arch rpms over the one that PROVIDES udev. 77228 1 alex.kanavin 2017-09-29 12:28:26 +0000 After a lot of digging into dnf, libdnf and libsolv, here's the report I submitted to the upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1497188 Let's see what the maintainers think. 78417 2 alex.kanavin 2017-11-30 11:42:41 +0000 I got a comment out of upstream: "But in this particular case we don't have a decision yet. LIBDNF is now under reconstruction and we don't know if new design changes will go in favor of that bug report." https://github.com/rpm-software-management/libdnf/pull/312#issuecomment-347641033 So let's see how their refactoring goes. 79071 3 alex.kanavin 2018-01-15 11:09:17 +0000 As it doesn't seem we'll get a fix from upstream for this soon, and RP has a patch in progress that sidesteps the issue by limiting the set of RPMs visible to dnf only to those actually needed, I guess the bug can be reassigned. 81033 4 richard.purdie 2018-07-07 12:57:31 +0000 The rpm filtering code at least resolves this issue so it doesn't concern us any more, even if there are seemingly problematic issues in libdnf.