**** BEGIN LOGGING AT Mon Jan 16 02:59:57 2023 Jan 16 07:54:37 good morning Jan 16 09:51:06 I'm trying to build an image based on `meta-amd`with `MACHINE=milan` to build for my zen3 cpu. This works but breaks as soon as I enable `EXTRA_IMAGE_FEATURES += " read-only-rootfs"`. I've enabled `qemu-usermode`and tried `QEMU_EXTRAOPTIONS_milan-amd = " -cpu max"`/`QEMU_EXTRAOPTIONS_milan-amd = " -cpu EPYC-Milan-v1,check=false" but building g-object-introspection-data and the fontcache still fails. Building the readonly rootfs image for Jan 16 09:51:06 the genericx86-64 machine works. My build and target machine are both zen3. I would be grateful for any hints or examples on how to get this to build. Jan 16 09:52:49 AlexanderKrimm[m: is milan-amd the right TUNE_PKGARCH? Jan 16 09:59:01 I'm trying to make a bundle recipe. I don't understand what I should do. I'm trying to depend on 'my-image-recipe:image' or 'my-image-recipe:image_ext4' or 'my-image-recipe:deploy', none of them do anything Jan 16 09:59:07 or rather, all of them are non-existent Jan 16 09:59:32 my image recipe inherits core-image-minimal, which has at least image and image_ext4, so I don't understand what's going on Jan 16 10:01:18 oh, apparently you do use the 'do_' prefix here Jan 16 10:04:37 JaMa: i've actually tried multiple combinations of ' milan-amd', 'zen3-amd', `zen3` and `milan` (for the QEMU_EXTRAOPTIONS) (`ls /work/build/tmp/work/` gives `all-amd-linux milan-amd-linux x86_64-linux zen3-amd-linux`) and without that option i get `illegal instruction` errors in the postinstall scripts. the machine type milan is defined int [meta-amd](https://git.yoctoproject.org/meta-amd/tree/meta-amd-bsp/conf/machine/milan.conf) Jan 16 10:04:37 which should fit my [EPYC 7443P](https://en.wikichip.org/wiki/amd/epyc/7443p). Jan 16 10:07:59 when you do depend on some-image-recipe:do_image, are you just supposed to reach into ${DEPLOY_DIR_IMAGE} and find the files it produced, or is there a better way? Jan 16 10:13:38 * I'm trying to build an image based on `meta-amd`with `MACHINE=milan` to build for my zen3 cpu. This works but breaks as soon as I enable `EXTRA_IMAGE_FEATURES += " read-only-rootfs"`. I've enabled `qemu-usermode`and tried `QEMU_EXTRAOPTIONS_milan-amd = " -cpu max"`/\`QEMU\_EXTRAOPTIONS\_milan-amd = " -cpu EPYC-Milan-v1,check=false"` but building g-object-introspection-data and the fontcache still fails. Building the readonly rootfs Jan 16 10:13:38 image for the genericx86-64 machine works. My build and target machine are both zen3. I would be grateful for any hints or examples on how to get this to build. Jan 16 10:13:54 * I'm trying to build an image based on `meta-amd`with `MACHINE=milan` to build for my zen3 cpu. This works but breaks as soon as I enable `EXTRA_IMAGE_FEATURES += " read-only-rootfs"`. I've enabled `qemu-usermode`and tried `QEMU_EXTRAOPTIONS_milan-amd = " -cpu max"`/`QEMU\_EXTRAOPTIONS\_milan-amd = " -cpu EPYC-Milan-v1,check=false"\` but building g-object-introspection-data and the fontcache still fails. Building the readonly rootfs Jan 16 10:13:54 image for the genericx86-64 machine works. My build and target machine are both zen3. I would be grateful for any hints or examples on how to get this to build. Jan 16 10:14:44 * JaMa: i've actually tried multiple combinations of `milan-amd`, `zen3-amd`, `zen3` and `milan` (for the QEMU\_EXTRAOPTIONS) (`ls /work/build/tmp/work/` gives `all-amd-linux milan-amd-linux x86_64-linux zen3-amd-linux`) and without that option i get `illegal instruction` errors in the postinstall scripts. the machine type milan is defined int [meta-amd](https://git.yoctoproject.org/meta-amd/tree/meta-amd-bsp/conf/machine/milan.conf) Jan 16 10:14:44 which should fit my [EPYC 7443P](https://en.wikichip.org/wiki/amd/epyc/7443p). Jan 16 10:17:57 mort: If you are working on a RAUC-bundle for your image, take a look at https://github.com/rauc/meta-rauc/blob/master/classes/bundle.bbclass which takes most of the work out of your hands. Jan 16 10:18:36 OnkelUlla: this isn't using rauc, it's using something more custom sadly. I have another project which uses rauc though, where I use meta-rauc's bundle.bbclass Jan 16 10:21:15 I'm having a hard time figuring out what target generates the .ext4 file, neither rootfs nor image seem to Jan 16 10:26:48 right, it's the do_image_ext4 target of course. I thought I had tried that before and found it to not work but I probably tried image_ext4, not do_image_ext4 Jan 16 10:28:39 hmm no do_image_ext4 doesn't make a .ext4 or .ext4.gz file in the deploy dir Jan 16 10:36:09 mort: It should. Your bundle recipe should add a dependency to the images "do_image_complete" task, IIRC. Jan 16 10:36:30 AlexanderKrimm[m: use bitbake-getvar to see TUNE_PKGARCH value in your build, most likely it will be zen3 (in milan-amd, milan is MACHINE and amd is VENDOR) Jan 16 11:14:26 JaMa: you are right and thanks for pointing me to the right command, which indeed returns zen3. I guess the milan-amd-linux directory is for the packages which explicitly set ARCH=MACHINE i read about somewhere in the documentation. Now I can clean up my configuration a bit, but the original issue still persists. But I'm also not sure if that is an openembedded, meta-amd or qemu issue. I've also seen that the amd layer [disables qemu Jan 16 11:14:26 usermode](https://git.yoctoproject.org/meta-amd/tree/meta-amd-bsp/conf/machine/include/amd-common-configurations.inc#n15) which I had to reenable because meson will do some checks to see if it can execute the compiled binaries which will fail if qemu is not available or has the wrong cpu configured. I think I'll first fokus on getting everything else working on the generic machine target and revisit this later. Jan 16 11:29:58 AlexanderKrimm[m: with QEMU_EXTRAOPTIONS_zen3 = " -cpu EPYC-Milan-v1,check=false" ? Jan 16 11:32:14 it might be useful to debug which instruction is the illegal one and go from there, maybe the qemu support for Milan-v1 is not perfect, but first tripple check that the qemu params are correct and debug it by hand Jan 16 12:28:04 sorry, maybe that was maybe written misleadingly. Jan 16 12:28:04 without QEMU_EXTRAOPTIONS -> meson builds fail pre-build (it compiles a zen3 testbinary and fails executing it with illegal instruction, same for the post-install scripts if I enable ro-rootfs). Jan 16 12:28:04 with `QEMU_EXTRAOPTIONS_zen3 = "-cpu EPIC-Milan-v1" -> meson check passes, but gobject-introspection-data and fontcache postinst steps fail. QEMU prints a list of unsupported instructions on startup and then starts the binary. gobject-ir-compiler fails complaining about illegal characters in a namespace, but the namespaces it complains about look completely unsuspicious. fontcache complains about not being able to write into the Jan 16 12:28:04 font-cache Jan 16 12:29:53 with QEMU_EXTRAOPTIONS_zen3,check=false: same as above, but does not print the warning about the missing instructions, saw that parameter being used for some other architectures and wanted to try if it helps Jan 16 12:31:34 EPIC-Milan-v1 is a typo, right? Jan 16 12:33:22 yes, this would give an error when launching qemu. in my config i got the correct one (or at least a valid one) Jan 16 12:44:15 is there a way to delete everything temporary about a recipe? Its sstate, the stuff in `downloads` that was downloaded by the fetch step, etc Jan 16 12:58:07 mort: -c cleansstate deletes WORKDIR and sstate, -c cleanall deletes fetched sources in addition to that Jan 16 13:00:05 hmmm Jan 16 13:06:37 even though I've ran cleanall on everything it still seems to be using an outdated version for one recipe's -native dependency Jan 16 13:07:22 or maybe not Jan 16 16:51:30 3/3 Jan 16 16:51:31 woops Jan 16 18:35:31 AlexanderKrimm[m, https://gitlab.com/qemu-project/qemu/-/issues/1370 Jan 16 18:35:37 are you on qemu 7.2 ? Jan 16 18:36:57 JaMa, ^^^ Jan 16 18:40:30 AlexanderKrimm[m, can I see the layer which hosts the machine definitions you are using? Jan 16 18:41:24 https://git.yoctoproject.org/meta-amd/tree/meta-amd-bsp/conf/machine/milan.conf Jan 16 18:41:31 is what he mentioned Jan 16 18:48:49 with older qemus qemu usermode isn't going to work at all due to missing instruction support. Jan 16 18:49:15 with 7.2 it works, but there are bugs in some instructions, so if your compiler generates them, you may run into those bugs, e.g. fontconfig stuff Jan 16 18:50:00 I thought this is pretty clearly stipulated here https://git.yoctoproject.org/meta-amd/tree/meta-amd-bsp/conf/machine/include/amd-common-configurations.inc#n12 Jan 16 18:50:59 unfortunately read-only rootfs does require functional qemu usermode (otherwise it's possible to defer to first boot) Jan 16 18:51:25 address your concerns to AMD and Intel for not lifting a finger for years :) Jan 16 18:52:12 and even recent haswell/bulldozer era support is written by red hat and linaro I think Jan 16 18:53:12 so those recent zen3 targets may use even newer instructions which just aren't in qemu Jan 16 18:55:11 JaMa, ^^^ might be interesting to you too Jan 16 19:04:07 kanavin: I don't build for zen3, my builder is zen2 based, but that doesn't affect this Jan 16 21:31:28 kanavin: Did this one get merged to oe-core? https://patchwork.yoctoproject.org/project/oe-core/patch/20220907085552.1171821-1-alex@linutronix.de/ Jan 16 21:58:37 kanavin: sorry, offline stuff. i'm using qemu 6.2.0 which seems to be the default for kirkstone. i've seen the comment, but i also saw that some older qemus do not provide milan support at all and the support in 6.2.0 seems to be sufficient to at least get meson's prebuid checks to pass, so i gave it a try to see if support has improved in the meantime. Thanks for the detailed description of the problem and the current state. I have a one Jan 16 21:58:37 more ideas that i'd like to try, but do not know if it's possible: my build host is also zen3, so theoretically i shouldn't even need qemu, all it has to do is set the correct sysroot, paths, environment. something like a changeroot, maybe. I was kind of hoping that there was a switch for qemu to behave in that way, but it seem's it's not that simple :) Jan 16 21:58:37 But other than that i can probably also just compile performance critical packages for zen3 and leave the problematic packages with the generic arch or something like that. **** ENDING LOGGING AT Tue Jan 17 02:59:56 2023