**** BEGIN LOGGING AT Mon Jan 11 03:00:17 2021 Jan 11 07:27:32 khem, afais gold is disabled, kodi-recipe was activating it. I think there is another culprit Jan 11 07:27:35 recipes-support: added older version of fmt, fixed compilation for kodi Jan 11 07:28:00 it seems libfmt/fmt could also lead to miscompiled bins Jan 11 07:58:13 Hello guys ! Does anybody know wich is the correct approach to build a minimal ramdisk to be used as "recovery boot method" given an already set up yocto project distribution ? I am able to build and burn a whole image (kernel/dtb/rootfs) that I usually burn on a SD card or run by a tftboot/nfs server. How can I add a minimal ramdisk ? thanks Jan 11 08:13:24 how can I create fat32 partition with WIC? I am using --fstype=vfat and it gives me fat16... Jan 11 08:36:56 Did something change about how ptest should be enabled if I update thud->dunfell? According to mega manual, I see no changes, but I'm getting "nothing RPROVIDES my-package-ptest" when building image. Local.conf has ptest in distro features, and my-package inherits ptest Jan 11 08:39:48 howdy dudX Jan 11 08:41:42 dv: maybe use --mkfs-extraopts to pass "-F 32" to mkfs.vfat? Jan 11 08:42:22 hi LetoThe2nd Jan 11 08:42:47 morning all.. and hny 2021. Jan 11 08:44:25 erbo, thanks! ... --fstype=vfat --mkfs-extraopts="-F 32" ... - is it correct? Jan 11 08:51:11 dv: that's what I would try at least :) Jan 11 09:09:49 Morning everybody Jan 11 09:12:39 good morning :) Jan 11 09:19:38 good morning everybody Jan 11 11:10:14 Am I assuming correctly that I don't need to do https://www.yoctoproject.org/docs/2.2.1/dev-manual/dev-manual.html#selecting-systemd-boottarget Jan 11 11:10:29 when I'm trying to test with QEMU? Jan 11 11:37:10 Sponge5: Are you using Yocto 2.2 (morty)? If not, it's worth looking at the more recent docs Jan 11 11:37:52 oh sorry, this was linked to me, didn't bother to check Jan 11 11:38:42 Other than that, tbh I don't know if that is needed for qemu or not. Maybe try with and without, see what works, submit a patch to the docs to make it clearer once you know :) Jan 11 11:39:20 which docs version is for dunfell 22.0.4? Jan 11 11:40:51 Sponge5: You can look up the release numbering here: https://wiki.yoctoproject.org/wiki/Releases Jan 11 11:41:25 (I do find the yocto version, poky version and bitbake version numbering confusing myself) Jan 11 11:41:43 Ah I see, I went by the git tags Jan 11 11:41:54 thanks! Jan 11 11:43:28 https://docs.yoctoproject.org/ Jan 11 11:43:41 and now... I think we should probably add the release name in the dropdown menu too Jan 11 11:45:52 Hello guys ! Does anybody know wich is the correct approach to build a minimal ramdisk to be used as "recovery boot method" given an already set up yocto project distribution ? I am able to build and burn a whole image (kernel/dtb/rootfs) that I usually burn on a SD card or run by a tftboot/nfs server. How can I add a minimal ramdisk ? thanks Jan 11 11:50:12 thekappe: "minimal ramdisk" in terms of initrd? should probably be enough to set IMAGE_FSTYPE to something supported, and tweak the kernel cmdline Jan 11 11:50:49 initramfs is usually a different bast. Jan 11 11:50:53 *beast Jan 11 11:51:24 and if you want to combine everything into a single build including bootloader etc, then you're off into wic/multiconfig land Jan 11 11:52:06 LetoThe2nd, thanks Jan 11 11:53:54 I am taking a look Jan 11 11:59:16 LetoThe2nd, it seems that initrd is deprecated (maybe unnecessarily) so I would prefer to go with initramfs Jan 11 11:59:46 rburton: if i wanted to be nitpicking - you mangled a whitespace fix into the libmicrohttp patch :) Jan 11 11:59:57 thekappe: "it depends" :) Jan 11 12:00:17 What would you suggest ? I am pretty new to the world Jan 11 12:01:12 I need it as a "first time boot method" in order to blank emmc  on the board Jan 11 12:01:29 "it depends" Jan 11 12:01:33 in order to burn the blank emmc on the board Jan 11 12:01:59 So I will boot unti uboot via jtag, upload kenrel/dtb/ramdisk, boot and burn Jan 11 12:03:30 an example: one of our targets supports booting through a SPL-UBoot-FIT chain from sd card. so while the fit image technically is a "minimal ramdisk" as you worded it, the approach one would take differs substantially from an initramfs. Jan 11 12:04:03 so, it really depends on what your systems boot mechanisms support, and what your manufacturings requirements are. Jan 11 12:05:50 I'm not using SPL-Uboot, I am working with a zynqmp and for now the boot sequence (simplified is) ZYNQMP-FSBL->UBOOT->SDCARD Jan 11 12:06:40 The final board won't have an sd card but a blanked emmc, so I need a procedure to burn it the first time the board is powered on. Jan 11 12:07:19 In order to do that I planned to load through tftp a .wic image and write it directly to the emmc Jan 11 12:07:21 you could also ramload uboot, and that in turn tftp/nfsbootfs Jan 11 12:07:37 many options. Jan 11 12:07:56 it's what i am doing now Jan 11 12:08:20 when the I don't want to burn a new sd card Jan 11 12:08:43 but i was told that a mechanism without tftp/nfs would be preferred Jan 11 12:09:01 so I started looking ramdisks Jan 11 12:13:15 Where do I extend BBPATH? In local.conf, or in a recipe? Jan 11 12:13:26 https://www.yoctoproject.org/docs/3.1.4/dev-manual/dev-manual.html#qemu-image-writing-new-tests Jan 11 12:14:18 wait, I didn't read it correctly Jan 11 12:14:49 Sponge5: usually in layer.conf Jan 11 12:15:10 thekappe: probably you actually want a fitimage then. thats basically kernel+dtb+"ramdisk" as uboot can directly use it. Jan 11 12:15:44 LetoThe2nd, it seems nice Jan 11 12:15:57 (you need fitimage support in U-Boot though) Jan 11 12:16:15 (one uses bootm to boot a fitimage) Jan 11 12:16:17 qschulz: sry, I noticed the moment I hit send - read layer as local Jan 11 12:16:23 Sponge5: :) Jan 11 12:16:33 qschulz, it's already there Jan 11 12:16:58 I can use a image.ub file with bootm Jan 11 12:17:19 thekappe: well... bootm supports uImage and fitImage but they are different things underneath Jan 11 12:17:23 but I don't really know who is building it and with wich parameters Jan 11 12:17:35 ah Jan 11 12:17:39 (and handled differently) Jan 11 12:17:44 ah Jan 11 12:17:50 so you really need fitimage support in U-Boot :) Jan 11 12:17:53 qschulz thanks man Jan 11 12:18:01 and creating a fitimage from yocto too Jan 11 12:18:11 look into kernel-fitimage bbclass Jan 11 12:18:17 there is a template somewhere ? Jan 11 12:18:19 it supports initramfs Jan 11 12:18:35 it works nice until you need to implement secure boot, but you're not there yet :) Jan 11 12:18:48 but I will and that's scaring Jan 11 12:18:55 thekappe: first things first Jan 11 12:19:36 once you need secureboot, you'll need to create your own fitimage class which is not inherited by the kernel but by the image recipe Jan 11 12:20:16 Am I expected to create a new recipe or append to any already existing ? Jan 11 12:20:28 well... that is if you plan to verify the rootfs integrity/authentication at boot Jan 11 12:20:44 it seems a good nice to have Jan 11 12:20:49 thekappe: there was patches sent by Bartosz from Baylibre on the mailing list some time ago Jan 11 12:21:10 don't remember if they were ever merged or not Jan 11 12:21:31 but yeah... I needed to write my own class/recipe for that Jan 11 12:22:04 why is it always so complicated uff... :D Jan 11 12:22:05 don't have it anymore (switched companies since I implemented it for a former customer, and I stupidly enough didn't share it publicly /ne shrugs) Jan 11 12:22:35 thekappe: secure boot is specific to the hardware, so it's hard to implement something generic enough Jan 11 12:22:50 and secure boot isn't easy too :) Jan 11 12:23:20 I know that the source file for a fitimage is a .its file, that's like a dts file Jan 11 12:23:48 yup Jan 11 12:24:16 thekappe: https://www.youtube.com/watch?v=jtLQ8SzfrDU Jan 11 12:24:26 if I create manually this .its file, who is expected to parse it and generate its .fit equivalent ? Jan 11 12:24:29 might help you get started with the secure boot stuff Jan 11 12:24:41 thanks man Jan 11 12:24:44 and explain where the kernel-fitimage bbclass is failing Jan 11 12:24:54 thekappe: the output will be a .itb Jan 11 12:25:04 it's created by mkimage Jan 11 12:25:35 but is it already there a recipe/class to parse these kind of files ? Jan 11 12:25:58 thekappe: what do you mean by parsing? Jan 11 12:26:01 I mean, once I have this .its, how can I use it inside my yocto/petalinux project ? Jan 11 12:26:14 what am I supposed to do ? Jan 11 12:26:39 kernel-fitimage bbclass creates the its and calls mkimage on it to get the itb Jan 11 12:26:58 so until you need to work the secure boot thingy, everything is "magic" Jan 11 12:27:05 mmm Jan 11 12:27:12 then you need to reimplement kernel-fitimage by yourself Jan 11 12:27:15 I like it Jan 11 12:30:08 RP: ndec: any reason to keep switchers.js in sync between bitbake docs and yocto-docs? Or can I fix it so that bitbake's dropdown menu works as intended? Jan 11 12:31:29 what about having the following in bitbake-docs: (; Yocto ())? Jan 11 12:31:37 (for the dropdown menu) Jan 11 12:32:19 qschulz, I'm currentrly using this one https://github.com/Xilinx/poky/blob/rel-v2019.1/meta/classes/kernel-fitimage.bbclass Jan 11 12:35:06 So to enable the generation I need to set: Jan 11 12:35:06 KERNEL_IMAGETYPES += fitImage Jan 11 12:35:07 INITRAMFS_IMAGE = petalinux-user-initramfs Jan 11 12:35:17 is that all ? Jan 11 12:36:20 qschulz: I don't think they have to match Jan 11 12:36:38 qschulz: we could indeed add the bitbake version in the bitbake switcher.js code. however I think that when we deploy to docs.yp.org, we override all switchers.js with the one from yp-docs/master branch Jan 11 12:37:31 i think we should still try to have all the versions information (metadata) split into a config file, which would be read by the website. Jan 11 12:37:58 switcher.js knows if we are looking at bitbake or yp (by looking at the url), so it could behave differently. Jan 11 12:37:58 Yes, one config would be ideal Jan 11 12:38:16 that config file would be maintained by the 'release managemer'. Jan 11 12:38:42 ndec: the switchers come from https://docs.yoctoproject.org/bitbake/_static/switchers.js though according to Firefox's network debug tab Jan 11 12:38:52 so it is possible in some way to have two different Jan 11 12:38:56 i had tried to do that, but couldn't get it to work. the problem was fetching an external yaml file (and the need for a proxy) Jan 11 12:39:28 yes, they are different files, so they can be different. i was just saying that today we override them all. Jan 11 12:40:13 http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/scripts/run-docs-build#n84 Jan 11 12:40:18 ndec: mmmm... i\m not so sure the switchers.js should be handled in releases Jan 11 12:40:36 in which case once a release is EOL, the dropdown menu won't be updated :/ Jan 11 12:40:44 not the switchers.js but the list of releases and the one we want to display on the website Jan 11 12:41:21 mmmm I see Jan 11 12:41:35 so the config file wouldn't be versioned in yocto-docs or bitbake-docs? Jan 11 12:42:09 like something on the side that is then modified by halstea d or others every release? Jan 11 12:42:16 yes, that's what I mean. Jan 11 12:42:21 gotcha Jan 11 12:42:47 well, time for a docs.yaml :p Jan 11 12:42:59 yes. Jan 11 12:43:32 but loading the docs.yaml failed for me, the browser refused to do it, i forgot the exact error now.. Jan 11 12:46:22 ok so the patch I just sent should probably not be merged and have us just look into making this into a configruation file instead Jan 11 13:05:30 qschulz: i have an old change that has something like this Jan 11 13:05:35 https://www.irccloud.com/pastebin/CqucwctQ/ Jan 11 13:06:02 with attributes for each release, that we can then use in the java script. Jan 11 13:06:37 unfortunately.. i never completed that, so it's not working as i wanted. Jan 11 13:15:08 ndec: https://stackoverflow.com/a/38404878 Jan 11 13:16:53 requires the requirejs script though Jan 11 13:57:03 qschulz, so far so good.. Jan 11 13:57:19 I've generated and compile the .its fit image Jan 11 13:57:45 I uploaded it with tftpboot in uboot Jan 11 13:58:11 tftpboot 0x0 192.168.99.254:/tftpboot/at-javelin-fe/fitImage Jan 11 13:59:53 bootm 0 Jan 11 13:59:54 ## Loading kernel from FIT Image at 00000000 ... Jan 11 13:59:54    Using 'conf@system-top.dtb' configuration Jan 11 13:59:55    Trying 'kernel@1' kernel subimage Jan 11 13:59:55      Description: Linux kernel Jan 11 13:59:56      Type: Kernel Image Jan 11 13:59:56      Compression: uncompressed Jan 11 13:59:57      Data Start: 0x00000104 Jan 11 13:59:57      Data Size: 18283008 Bytes = 17.4 MiB Jan 11 13:59:58      Architecture: AArch64 Jan 11 13:59:58      OS: Linux Jan 11 13:59:59      Load Address: 0x00080000 Jan 11 13:59:59      Entry Point: 0x00080000 Jan 11 14:00:00      Hash algo: sha1 Jan 11 14:00:00      Hash value: 281aa72e1fbe86d373a80e9c18b326cc01f3b5b9 Jan 11 14:00:01    Verifying Hash Integrity ... sha1+ OK Jan 11 14:00:01 ## Loading ramdisk from FIT Image at 00000000 ... Jan 11 14:00:02    Using 'conf@system-top.dtb' configuration Jan 11 14:00:03 thekappe: aaaaaaaaaaaaah use a pastebin! Jan 11 14:00:13      Architecture: AArch64 Jan 11 14:00:13      Hash algo: sha1 Jan 11 14:00:14      Hash value: a981fe162778cf7483b0bec8fc7b718c0928a046 Jan 11 14:00:14    Verifying Hash Integrity ... sha1+ OK Jan 11 14:00:15    Booting using the fdt blob at 0x116fc08 Jan 11 14:00:15    Loading Kernel Image ... OK Jan 11 14:00:58 ERROR: new format image overwritten - must RESET the board to recover Jan 11 14:01:07 resetting ... Jan 11 14:01:26 qschulz, what's pastebin ? Jan 11 14:01:52 thekappe: a place where you copy your text and can send a link so you don't flood the channel :) Jan 11 14:02:07 it seems a nice option Jan 11 14:02:16 any works, there are plenty available Jan 11 14:03:14 otherwise... are you sure 0x0 is a valid RAM address (see where the RAM starts on your CPU datasheet) Jan 11 14:03:24 nope Jan 11 14:03:37 '=D Jan 11 14:03:40 do you happen to have a variable named loadaddr in your u-boot environment? Jan 11 14:04:13 I thought that I could use any addr while in uboot Jan 11 14:04:42 and that the important thing is that I don't load different files overlapping Jan 11 14:04:47 honestly, that is probably more a question for #u-boot or some linux channel, you probably would need to give the its and the output of mkimage -L (or iminfo in u-boot) Jan 11 14:05:04 iìll check the loadaddr Jan 11 14:05:08 thanks man Jan 11 14:20:18 qschulz, your supposition was right, I changed the loadaddr and now I can boot the kernel with the following bootargs Jan 11 14:20:51 setenv bootargs "console=ttyPS0,115200n8 earlycon cpuidle.off=1 clk_ignore_unused root=/dev/ram rw ip=${ipaddr}:${serverip}:${gatewayip}:${netmask} rootwait" Jan 11 14:21:24 BTW the kernel panics as it can't find any fs Jan 11 14:21:58 "No filesystem could mount root, tried:" Jan 11 14:22:16 Is there a way to specify that I want only layer specific tests to be run with "bitbake -c testimage core-image-minimal"? Jan 11 14:22:18 17.4MiB might be small for kernel + initramfs if you don't have a very small initramfs or have worked on making the kernel smaller Jan 11 14:22:41 sorry for interrupting Jan 11 14:23:37 also the kernel lists 15 ram partitions Jan 11 14:23:43 from ram0 to ram15 Jan 11 14:24:03 I've tried also root=/dev/ram0 Jan 11 14:24:14 but I'm still facing the same issue Jan 11 14:24:37 @thekappe did you configure the kernel to support ramdisk and set some proper size? Jan 11 14:25:31 I've set the following variables Jan 11 14:25:34 INITRAMFS_IMAGE_BUNDLE = "1" Jan 11 14:25:57 INITRAMFS_MAXSIZE = "524288" Jan 11 14:26:10 root=/dev/ram rw should be fine Jan 11 14:27:17 thekappe: in your kernel defconfig you also should add support for initramfs, and probably the filetype you're using for your initramfs (cpio, cpio.gz, etc...) Jan 11 14:27:40 thekappe: how big is your kernel (without initramfs)? Jan 11 14:27:57 and how big is your cpio image? Jan 11 14:28:35 cpio image is 41M Jan 11 14:28:55 (not compressed) Jan 11 14:29:44 or 7.2M compressed Jan 11 14:31:55 mmm, 17MiB might actually be enough then, please check that your kernel supports compressed cpio Jan 11 14:32:48 one thing is that I have two image recipes Jan 11 14:32:58 one with initramfs and one without it Jan 11 14:33:44 because I have a circular dependency problem with the .wic image if I enable the initramfs Jan 11 14:34:28 so I setup another recipe that basically removes the .wic image_fs_type and add the cpio.gz instead Jan 11 14:36:02 BTW i have only one linux.bin file inside the kernel ${B} dir Jan 11 14:41:25  # CONFIG_BLK_DEV_INITRD is not set Jan 11 14:41:31 perfect Jan 11 14:41:55 thekappe, ouch...ah, instead aof root=/dev/ram I'd use rdinit= Jan 11 14:44:32 actually, none matters Jan 11 14:44:54 when you have an initrd inside the kernel, there is no way to not boot the initrd so the root arguments are just ignored Jan 11 14:45:37 well, depends how is called his init :) Jan 11 14:46:36 if any Jan 11 14:46:43 whatever the init is, it still needs to be in the initrd Jan 11 14:46:55 in the initramfs Jan 11 14:47:07 initramfs != initrd Jan 11 14:47:26 initrd is directly embedded in the kernel binary Jan 11 14:47:27 aren't you using initramfs? Jan 11 14:47:49 initramfs can be loaded manually via the bootz/booti command or via fitimage Jan 11 14:48:26 don't know exactly to be honest, haven't dug in the kernel-fitimage.bbclass enough Jan 11 14:48:33 yes, I know very well and can help with it Jan 11 14:48:54 no idea about fit images though :) Jan 11 15:05:28 Hi, I had a question on the git structure of a typical Yocto project. I understand that you should create a new meta-* layer with your configurations recipes etc there and use git there. However for things like local.conf and the bblayers.conf that are created for us in the build directory what do you do with those ? Do you not put those in git and Jan 11 15:05:28 instead have everyone recreate it after cloning your repo ? If anyone has a open source yocto project example that they would be willing to link to I would be much obligied. Cheers! Jan 11 15:05:43 ant__, changing root=/dev/ram to rdinit=dev/ram halts the kernel to Jan 11 15:05:44 [ 12.023210] Waiting for root device ... Jan 11 15:06:35 PS: I've enabled the INITRD and compressed archive Jan 11 15:07:40 medo: one of the standard approaches these days is kas (see https://youtu.be/KJHJlOtTdaE) Jan 11 15:08:18 medo: others are, depending on your use case, repo, git submodules, the combo-layer script, and being inspired by the yoe-distro Jan 11 15:08:44 medo: "du -sh build" Jan 11 15:09:54 LetoThe2nd thanks so much didn't realize you made a video about it have only watched the first 5. Thanks ! Jan 11 15:10:01 \o/ Jan 11 15:12:14 thekappe, once you have CONFIG_BLK_DEV_INITRD=y and CONFIG_RD_GZIP=y at least you are ok Jan 11 15:22:31 hello! Any idea how can I insert a task right before the rootfs_reproducible call? Jan 11 15:23:25 using ROOTFS_POSTPROCESS_COMMAND inserts the task before sort_passwd and my task should be after sort_passwd Jan 11 15:28:23 addtask? Jan 11 15:31:55 ant__, qschulz I don't know how but I got it working Jan 11 15:32:24 \o/ Jan 11 15:33:12 thekappe: quick quick quick: git add -A; git commit -sm "got it working, don't know how it works" Jan 11 15:33:23 at least you have something in your git history :) Jan 11 15:34:02 he he Jan 11 15:34:31 =D Jan 11 15:35:32 is overriding the rootfs-postcommands.bbclass a way to get some logic just before the rootfs_reproducible call? Jan 11 15:35:47 thekappe, once yu get accustomished with it, you can discover the meta-initramfs layer and the small-small images you can get with it Jan 11 15:37:59 any ideas? any thoughts? Jan 11 15:39:08 sesom: how did you add your command to ROOTFS_POSTPROCESS_COMMAND exactly? Jan 11 15:39:30 in the image recipe Jan 11 15:39:47 sesom, you can add your own task or maybe use [postfuncs] Jan 11 15:40:20 no, the actual line I mean Jan 11 15:40:26 I'm able to add it, only that is executed too early Jan 11 15:40:58 ROOTFS_POSTPROCESS_COMMAND += " custom_logic; " Jan 11 15:41:09 yeah, try _append Jan 11 15:41:33 ouch! Jan 11 15:42:18 c.f. https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/rootfs-postcommands.bbclass#n56 Jan 11 15:42:45 which is then added to ROOTFS_POSTPROCESS_COMMAND with: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/rootfs-postcommands.bbclass#n58 which IIRC is the python way to use _append Jan 11 15:45:36 or if it's something that has to do with sort_passwd, then just += or _append SORT_PASSWD_POSTPROCESS_COMMAND Jan 11 15:49:26 ROOTFS_POSTPROCESS_COMMAND_append = " custom_logic; " didn't do trick. I'll try the SORT_PASSWD_POSTPROCESS_COMMAND_append trick now Jan 11 15:49:43 wouldn't sort_passwd[prefuncs] = also work? Jan 11 15:51:06 err [postfuncs] it seems in your case Jan 11 15:51:16 as you like it :) Jan 11 15:51:34 prefuncs: List of functions to call before the task executes. Jan 11 15:52:54 ant__: I'll try the SORT_PASSWD_POSTPROCESS_COMMAND_append trick now Jan 11 15:53:05 let's see which works! Jan 11 15:53:22 I have a test at "meta-mylayer/lib/oeqa/runtime/mytest" and I set "TEST_SUITES = "mytest"" in build/conf/local.conf ... "bitbake -c testimage core-image-minimal" gives me error: Empty TEST_SUITES, so I looked into testsuite.bbclass and apparently test_modules has "mytest", but getSuiteCases has empty return... I have set the layer BBLAYERS in bblayers.conf, so that is not the problem... Jan 11 15:53:24 yes, can be tricky Jan 11 15:54:49 I'm stumped on this one for a while so if you have an idea lmk... I'm trying to do Automated Runtime Testing in QEMU Jan 11 15:54:57 ant__: not sure, because sort_passwd isn't a task but a function Jan 11 15:56:23 ROOTFS_POSTPROCESS_COMMAND = ... set_systemd_default_target; systemd_create_users; empty_var_volatile; sort_passwd; custom_logic; rootfs_reproducible; Jan 11 15:56:40 SORT_PASSWD_POSTPROCESS_COMMAND_append worked! Jan 11 16:08:27 Hi, is there an easy way how to see how the final task (e.g. "do_install") looks like after parsing all append recipes? Jan 11 16:09:47 ondra68: in ${WORKDIR}/temp/run.do_install you'll have the exact content of your task Jan 11 16:12:24 if its a shell task then bitbake -e recipe should show you Jan 11 16:14:25 Hello ! First, I wish you all a good and prosperous Years :) I'm here for asking you some support as i'm noobish to Yocto !    Here the situation : In my highest level of layer, i've removed a package. On a lower layer, i'have the bbappend of the recipe which is responsible of that package. When i generate my image, it tells me that the package Jan 11 16:14:25 is missing. What can cause that? Instead of giving me a possible answer, would be appreciate to know how can be debug to find my self. Doesn't want to ask lot of times !  According to the bitbake -g , nobody ask for that package... Jan 11 16:17:56 qschulz, rburton I will try, thx Jan 11 16:20:48 I've managed to create a situation where the base hash for a task is deterministically non-deterministic Jan 11 16:20:56 qschulz: if the function is appended through the SORT_PASSWD_POSTPROCESS_COMMAND_append way, the ${IMAGE_ROOTFS} variable is not available anymore, as it was with when the ROOTFS_POSTPROCESS_COMMAND tactic was employed Jan 11 16:21:23 I have the error saying the bashash value has changed from value A to value B. Running the build multiple times those values always stay the same Jan 11 16:21:35 sesom: impossible as your custom_logic is still part of ROOTFS_POSTPROCESS_COMMAND Jan 11 16:23:56 and sort_passwd and rootfs_reproducible are using it too, so you did something wrong in your custom_logic Jan 11 16:24:04 what is exactly your error? can you send us a log? Jan 11 16:24:10 yeah, I saw that in the code Jan 11 16:24:36 It might be that I'm using it in a wrong way. Now I noticed that this is an absolute path Jan 11 16:24:53 I always treated it as a relative to the build dir Jan 11 16:25:03 which I guess it's wrong Jan 11 16:25:35 sesom: what exactly are you trying to do :)? Jan 11 16:26:20 do some particular analysis of the output rootfs before packing it Jan 11 16:33:18 just use IMAGE_ROOTFS as is I guess then Jan 11 16:35:39 I tried following the instructions to run bitbake with `-Snone` then `-Sprintdiff` but got no useful output: https://pastebin.com/4SdD8bvA Jan 11 16:36:05 I see the basehash changed but it's unclear why Jan 11 16:56:13 paulbarker: sadly that option doesn't often help :( Jan 11 16:58:41 RP: I think I may have fixed my own problem though I don't fully understand the details Jan 11 16:59:09 I had some code in an anonymous python block setting a variable Jan 11 17:00:17 paulbarker: the dependency parsing code has no insight into what anon python is doing Jan 11 17:00:32 Defining a new python function (which returns a string) and calling that in a variable assignment works Jan 11 17:02:09 RP: This is messing with dependencies yes. It's a messy attempt at working around bug #13994 until it's fixed on dunfell Jan 11 17:02:13 RP: Hi, have you had a chance to look at the QMP patches I sent last week? Jan 11 17:07:00 sgw: no, sorry. Can barely just keep the builds going :/ Jan 11 17:09:00 RP: https://pastebin.com/sDtLBA3P shows the working & non-working way of setting the variable if you're interested Jan 11 17:09:10 The goal is to set task deps for do_image_wic so that do_image_tar & do_image_ext4 do not run at the same time as it Jan 11 17:10:51 paulbarker: every time the recipe is parsed, your appendvar is run Jan 11 17:11:00 and recipes are parsed multiple times Jan 11 17:11:48 qschulz: Every time it's parsed the variable is reset to the value set elsewhere though. I've added `bb.note` calls, the anonymous block only runs once per recipe Jan 11 17:12:49 mmmm, probably mixed up things sorry :/ Jan 11 17:13:46 qschulz: For example, image-live.bbclass uses `d.appendVarFlag` in an anonymous python block and it clearly works ok Jan 11 17:39:20 Is there any way to "wrap" a task? As in I want to call an unmodified do_compile task as normal but I want to call it myself. Jan 11 17:39:53 The reason I want to call it myself is I want to call it with "bear" to build a compile_commands.json database. Jan 11 17:47:51 rabbit9911: I believe you can call foo_do_compile of the foo.bbclass in your own do_compile, assuming it follows the usual naming convention Jan 11 17:51:03 that only works if the class uses EXPORT_FUNCTIONS, which isn't always the case. if it's not, you can always use anonymous python to alter/rename it Jan 11 17:52:45 kergoth: okay, gotcha Jan 11 18:17:50 paulbarker: that makes sense as the code can't "see" into that anon python block Jan 11 18:19:15 I'm getting "login: can't set groups: Operation not permitted" after trying to log as root with debug-tweaks added to EXTRA_IMAGE_FEATURES. Jan 11 18:19:29 It seems to be related to core-image-minimal, any idea? Jan 11 18:20:00 v0n: That implies permissions aren't set correctly in your rootfs Jan 11 18:20:08 sgw, RP: I'll try to take a look at the QMP patches in the next few days. Jan 11 18:20:17 v0n: I had that issue when I was messing around with wic internals Jan 11 18:20:30 v0n: Are you using wic? Anything special in the wks file if you are? Jan 11 18:20:34 yes Jan 11 18:21:10 I tried my own .wks file, then went back to the ti beaglebone one Jan 11 18:21:33 v0n: Are you on the master branch of poky/openembedded-core? Jan 11 18:21:51 paulbarker: dunfell Jan 11 18:22:25 v0n: Ok, that's before the major changes involving pseudo so I doubt it's the same issue I saw Jan 11 18:22:36 Could you share the wks file via a pastebin? Jan 11 18:23:42 paulbarker: I tried yours actually (rawcopying the MLO and u-boot.img files), but I went back to meta-ti/wic/sdimage-2part.wks because u-boot didn't boot Jan 11 18:26:06 v0n: U-boot didn't boot? Or u-boot couldn't find a kernel? Jan 11 18:26:49 paulbarker: nothing happened, like picocom was printing 'C's every few seconds and that's all Jan 11 18:27:20 v0n: Ah yes, that means it didn't even find u-boot Jan 11 18:28:14 I know the BBE images do boot on BBB devices (last time I checked). I guess something else from the meta-sancloud layer may be needed as well as the wks file to get a usable single partition image Jan 11 18:28:25 paulbarker: is it the same MLO to both from either the first vfat partition or from raw sd card? I don't understand why there's a difference in the behavior Jan 11 18:29:09 v0n: I'd have to look into it in more detail to answer that confidently Jan 11 18:29:26 Not got the time to get too deep into it right now Jan 11 18:29:26 but that said, I'm fine with a single partition containing the MLO, u-boot.img, kernel, dtb and initramfs. Jan 11 18:30:37 what's bothering me is that adding EXTRA_IMAGE_FEATURES ?= "debug-tweaks" to my machine conf doesn't seem enough to get a passwordless root login :/ Jan 11 18:33:16 JPEW_: thanks Jan 11 20:26:15 I used IMAGE_BOOT_FILES += "${UBOOT_ENV_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}" but I get: "output: install: cannot stat '.../build/tmp/deploy/images/.../UBOOT_ENV_BINARY': No such file or directory Jan 11 20:26:20 Am I missing something? Jan 11 20:35:15 isn't this variable available ? Jan 11 21:40:01 khem, forgive my ignorance but how would CMake refuse to link the damned libs (missing soname)? I see apparently the extra libs needs to be specified to the linker.. Jan 11 21:40:22 not working https://tinyurl.com/yyhgl3oz Jan 11 21:40:56 working (elsewhere...) https://tinyurl.com/y5mv2z6g Jan 11 21:41:16 well, the patch is a bit different too, not to much :) Jan 11 22:51:39 login as root with debug-tweaks still says: login: can't set groups: Operation not permitted. Any idea? **** ENDING LOGGING AT Tue Jan 12 02:59:57 2021