**** BEGIN LOGGING AT Mon Jan 18 02:59:57 2021 Jan 18 08:03:57 good morning Jan 18 08:04:17 greetings Jan 18 08:07:01 morning Jan 18 08:08:12 yo dudX Jan 18 09:58:48 manuel1985: Thanks! Jan 18 10:09:41 RP: We know that creating files under pseudo and then deleting them outside pseudo can cause issues. How about the other way round? Jan 18 10:09:59 Is it safe to delete files under pseudo which were created outside of a pseudo context? Jan 18 10:12:04 paulbarker: Well, thank you ;) Jan 18 10:29:11 paulbarker: that is safe Jan 18 10:29:53 paulbarker: the reason that external deletion causes problems is potential inode reuse. That doesn't happen the other way around Jan 18 10:30:18 RP: Ok, that makes sense. I'm trying to work out how the `tmp-wic` directory ends up in the pseudo db Jan 18 10:31:14 It's created by bitbake as it's listed in `do_image_wic[cleandirs]`, then deleted by wic (still outside pseudo, I missed that the line which runs wic has `PSEUDO_UNLOAD=1`) Jan 18 10:32:01 paulbarker: the creation by bitbake is probably under pseudo then? Jan 18 10:32:50 RP: Doesn't look like it. It's created in `exec_func()` before FAKEROOT is even checked Jan 18 10:34:01 paulbarker: the entire of bitbake-worker for peseudo tasks runs under pseudo Jan 18 10:34:44 RP: I missed that fact! Was just looking at `lib/bb/build.py` Jan 18 10:35:03 paulbarker: right, there is code in bitbake-worker for that Jan 18 10:35:11 That could explain it. Bitbake creates the dir under pseudo, wic runs with `PSEUDO_UNLOAD=1` and deletes it Jan 18 10:35:31 that would be bad, yes Jan 18 10:35:45 I'm not sure we even need that dir in `do_image_wic[cleandirs]` if wic creates and deletes the dir itself Jan 18 10:36:06 My only concern is if wic dies part way through and leaves a junk dir behind Jan 18 10:38:10 RP: I'll modify it so that wic handles that directory internally, drop it from `do_image_wic[cleandirs]` and re-submit the patches Jan 18 10:38:21 That should hopefully do the trick Jan 18 10:38:21 paulbarker: sounds good Jan 18 10:39:06 paulbarker: don't forget about people with a ctrl+c frenziness which stops builds unexpectedly. Making sure the dir is cleaned is not too bad? Jan 18 10:39:29 qschulz: I believe paulbarker will sort internally to wic Jan 18 10:42:16 qschulz: I think wic should bail if the workdir already exists. Then in do_image_wic we can check for an old workdir and delete it if present Jan 18 10:42:48 That avoids the risk of someone shooting themselves in the foot, I don't want wic to unconditionally remove the workdir at startup or `wic -w ~` would become a foot-gun Jan 18 10:43:25 Deleting an old workdir in do_image_wic should be safe as it will have been created outside of a pseudo context Jan 18 10:48:10 Good day! I would like to run a filesystem check on every boot. On a raspbian I could do that by adding `fsck=force fsck.repair=yes` to `/proc/cmdline`. Is that the right thing to do? do I need to enable kernel modules for that or should that run out of the box? Jan 18 10:48:30 I mean I would like to do that on my bitbaked image. Jan 18 11:03:06 emrius: i would rather start thinking about a) why do you expect fs corruption? b) what will you do if the check fails? Jan 18 11:06:15 emrius: and, this https://www.freedesktop.org/software/systemd/man/kernel-command-line.html suggests that you are using a systemd feature. so if the feature is waht you want and your image is using systemd, then it is probably the (most) right thing to do. Jan 18 11:13:11 LetoThe2nd: Thanks! We are currently running our system from an SD card. I thought that enforcing a filesystem repair e.g. after power failure might prevent corrupted root filesystems. Jan 18 11:13:54 We are using systemd thus, that makes it much easier to apply! awesome Jan 18 11:16:45 emrius: depending on the rest of your system archicture that might or might not be a good idea. Jan 18 11:18:53 what would be reasons not to do that? Jan 18 11:19:24 despite longer booting time of course Jan 18 11:20:33 primarily the longer boot time. but also means of actually handling the problems. Jan 18 11:23:53 Boot time is not critical for us. I mean, sure, it's kind of risky to leave it to the system to do that on its own but our devices are running headless very remote. Thus, if anything is fixable I think it might be best to just give it a shot... Jan 18 11:23:58 Let's see how that turns out Jan 18 11:25:52 Ok, but coming back to `/proc/cmdline` :/ I actually have to set other parameters as well such as `isolcpu` to stabilize some acquisition thread running on one core. https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html Jan 18 11:27:45 I could copy the current `/proc/cmdline` and (I think) override the `CONFIG_CMDLINE` kernel option. Or can I append to that kernel option somehow? Or maybe even the classic way: CONFIG_CMDLINE_append = "isolcpus=1" ? Jan 18 11:37:00 emrius: are you using u-boot? Jan 18 11:37:40 if yes, just add your stuff to the bootargs env variable, that's where the kernel parameters are defined before being passed to the kernel Jan 18 12:45:19 qschulz: sorry for the late reply. Lunch break. Yes, I'm using u-boot. Thanks for the clarification! Jan 18 13:00:40 It looks like trace-cmd and perf install the same stuff to ${libdir}/traceevent/plugins Jan 18 13:01:00 Did someone else notice this? Jan 18 15:21:12 hi there Jan 18 15:23:26 v0n: o/ Jan 18 15:23:35 If I'm building an initramfs for preinit things, like mounting squashfs overlays before switching root etc., should I define the image recipe as a depedence for core-image-minimal (or any custom ones) or should I somehow force it in the machine/distro conf? Jan 18 15:26:18 v0n: i would rather go multiconfig to create a build-in-bild Jan 18 15:26:24 *build-in-build, even Jan 18 15:28:09 LetoThe2nd: I'm still not sure to understand the use case for multiconfig Jan 18 15:28:18 LetoThe2nd: does it bring something if the machines are identical? Jan 18 15:28:44 you want to ship a root filesystem which carries a kernel, which in turn has an initramfs bundled, right? Jan 18 15:30:08 hum no, I would have used a single kernel, an initramfs for preinit, which mounts stuffs and switch root to a persistent partition Jan 18 15:30:31 but you have two rootfs involved. Jan 18 15:30:39 yes Jan 18 15:30:49 which will probably run different DISTROs Jan 18 15:31:22 or it can be the same with some root detection logic, but you can imagine having different init systems (sysvinit vs. systemd for example), so yes 2 different rootfs. Jan 18 15:32:10 so yes, two different DISTROs even Jan 18 15:32:12 LetoThe2nd: yeah that's something I'm still not confortable with. Is this case using two different distros, or two images of the same distro? Jan 18 15:32:14 once different inits are involved you are runnind two DISTROs and therefore are in multiconfig land. Jan 18 15:32:27 qschulz: cue #1 please. Jan 18 15:35:33 qschulz: LetoThe2nd: this is targetting the SD card. If I wanted to build a bootable image for the eMMC, would this be a third distro? Jan 18 15:35:58 v0n: probably more like a second machine. Jan 18 15:36:35 Hi, I am struggling with bitbake chosing the wrong recipe version. I have a layer from a client providing a recipe for keyutils in version 1.5.10. In the dunfell version of meta-openembedded, there is a newer recipe for keyutils. 'bitbake-layers show-recipes keyutils' correctly lists both of them: Jan 18 15:36:35 === Matching recipes: === Jan 18 15:36:35 keyutils: Jan 18 15:36:35 meta-client 1.5.10 Jan 18 15:36:35 meta-oe 1.6.1 Jan 18 15:36:35 When I perform 'bitbake keyutils' it still starts to build version 1.5.10 and I don't know why. I was looking for a 'PREFERRED_VERSION_keyutils..' variable set somewhere but no match. Jan 18 15:36:51 v0n: well aren't emmc and sd card more or less the same thing? Jan 18 15:37:02 one is removable and not the other but it's pretty much the same thing Jan 18 15:37:08 so... not sure it matters? Jan 18 15:37:33 (except if you have some scripts/logics/recipes that are different when you are on sdcard vs emmc and you cannot detect this at runtime) Jan 18 15:38:04 in which case as LetoThe2nd said, two machines. Or if the differences are minimal, maybe two image recipes but two machines is cleaner Jan 18 15:38:33 dleppich: look for BBPRIORITY in conf/layer.conf Jan 18 15:38:44 I see Jan 18 15:38:55 the higher the number the highest the priority of the recipes it contains Jan 18 15:39:43 the "flash" machine would have it's own .wic file for the flash layout but the distro image recipe would actually be the same. Maybe even a FitImage or raw squashfs partition on the flash. Jan 18 15:40:48 v0n: sd card and emmc are both flash, they can probably both have support for .wic if I'm not mistaken. Distro image recipe does not really exist so it's a bit confusing what you're saying Jan 18 15:40:53 qschulz: meta-client is a priority of 9, meta-oe has 6. So does the bitbake only chose higher versions when the layer priorities are equal? Jan 18 15:41:04 LetoThe2nd: qschulz: the more I learn about yocto, the more I realize that "distro", "machine", and "image" don't have strong meanings, it's more like building blocks to define the granularity of your own use case Jan 18 15:41:41 v0n: au contraire. MACHINE, DISTRO and IMAGE are (almost) orthogonal. Jan 18 15:41:59 dleppich: yes Jan 18 15:42:00 v0n: you should be able to switch each one in and out at will. Jan 18 15:43:49 I cna understand the difference between distro and image is hard to grasp, it took me some time too. As LetoThe2nd said, see distro as lego vs mechano and image as boat vs car. The distro defines "how" you build something (init system, opengl support, etc...), the image what you build Jan 18 15:44:42 ( qschulz: about distro images, I mean that image recipes are distro specific and go into a distro layer usually, don't they? ) Jan 18 15:45:00 and there is one important thing to remember, recipes cannot share information between themselves. Yes... image recipes too. So when you want to make two recipes have the same configuration, you need a configuration file (distro or "it depends") Jan 18 15:45:57 v0n: there is no such thing as distro images. There are distro configuration files which are nothing without any recipe to build (image and package recipes). Therea re image recipes which are nothing without a distro configuration file for configuring them Jan 18 15:46:33 distro layer only has usually distro specific stuff. meaning the distro configuration file and distro specific bbappends or patches or classes etc. Jan 18 15:48:03 ok Jan 18 15:50:33 qschulz: I talked about "distro images" because in my mind I was imagining that an "ubuntu" distro layer existed, it would provide "ubuntu" and "ubuntu-devel" image recipes for example, while core-image-minimal are the bare image recipes for a functional target Jan 18 15:51:26 so in my case (standard distro vs. the preinit scripts), you guys would defined two distros (e.g. foo and foo-preinit) and build what, core-image-minimal for both of them? Jan 18 15:51:48 v0n: its not something "we would". its somethign that doesn't work in another way. Jan 18 15:52:12 * v0n is still struggling to figure out where to use image recipes vs. extending {IMAGE,PACKAGE}_INSTALL in the distro definition Jan 18 15:52:36 it's highly unlikely that you won't need to create two image recipes anyway, or make some part of the image recipe distro specific (which I don't recommend) Jan 18 15:53:16 can your distro absolutely NOT work without a package in the image? if yes, then IMAGE_INSTALL is fine-ish. If it does not care, it's not where you should put it but in an image recipe Jan 18 15:53:17 I'm having an issue with using devtool for a kernel recipe. I have a local file that doesn't get unpacked into my devtool workspace. Anyone have any ideas? Jan 18 15:53:30 e.g. systemd distro needs systemd Jan 18 15:53:52 cdgarren: did you add this file after having run devtool modify? Jan 18 15:54:13 qschulz No, it was in the recipe beforehand. Jan 18 15:54:54 cdgarren: is it not unpacked or not put into the devtool workspace? Jan 18 15:55:15 (i.e. are we talking about a tarball that is not extracted or a tarball/file that is not available in the workspace)? Jan 18 15:55:55 qschulz it's a plaintext .dts file, and it ends up being extracted into the work-shared/kernel-sources directory Jan 18 15:56:19 My SRC_URI for the file looks something like this: file://project.dts;subdir=${S}/path/to/subdir/ Jan 18 15:57:24 I don't use devtool for kernel so can't really help here :/ Especially since the kernel is such a special recipe (work-shared for example) Jan 18 15:57:30 LetoThe2nd: qschulz: so in my case you would have "fooboard" and "fooboard-emmc" machines, "foodist" and "foodist-preinit" distros and also "foodist" and "foodist-preinit" image recipes, right? Jan 18 15:58:31 v0n: I would triple check that you can't have the same machine for sd card and emmc Jan 18 15:58:52 and if it's only a filesystem issue, just build both from the image recipe for sd card and emmc Jan 18 15:59:04 otherwise, pretty much on point yes Jan 18 16:12:02 qschulz: I think we can have the same machine yes, as you said it's both MMC anyway (the size is different for sure) but I would definitely not use the same layout for both storage Jan 18 16:13:08 v0n: you have to check if you can use two different wks out of the box Jan 18 16:13:22 otherwise, you can probably create a new image type instead Jan 18 16:13:26 it all depends Jan 18 16:13:44 if there are really no differences apart from those, then two machiens might be overkill though cleaner Jan 18 16:14:16 Hey folks, how do you handle yocto repository for multiple projects/machine ? Are you able to only use 1 yocto repository for all your machines/projects? Jan 18 16:14:53 You might want to expand on what you mean by 'yocto repository' Jan 18 16:16:39 roussinm: from what I've understood so far it really depends on what you want to provide. You can have one meta- layer with everything, have one meta- containing meta-, meta-, meta-, etc. or even split all these layers into separated git repositories. It all end up to what you need to publish or not (private vs. public layers, etc.) Jan 18 16:18:38 qschulz: what do you mean by checking if I can use two different wks out of the box? I'd say yes, if let's say for the SD card I want to have a persistent partition for the rootfs while for the eMMC I want to have a raw squashfs partition or even a FitImage containing everthing. Jan 18 16:18:49 roussinm, maybe the answer is as simple as ". ./oe-init-build-env build-A " and in another shell ". ./oe-init-build-env build-B" Jan 18 16:19:22 v0n: thanks! I was wondering that if we take the meta-/meta- approach, we will probably have a meta-/common recipes and that if you change those recipes you have to make sur that all machines are still properly built. Jan 18 16:20:38 paulg: that's what we have been doing so far, just wanted to see what was the workflow somewhere else. Jan 18 16:21:14 paulg: but both build-a and build-b are different git repositories. Jan 18 16:21:57 no build-{a,b} are build directories here, not project repositories Jan 18 16:23:46 v0n: you can only specify one file in WKS_FILE, so how do you pick which one to build if you have the same recipe and the same machine? Jan 18 16:23:46 JPEW, from our last week's discussion: https://lists.openembedded.org/g/openembedded-core/message/146830 Jan 18 16:24:05 v0n: oh right, sorry i was refering to the oe-init-build-env source script. Jan 18 16:24:23 qschulz: you cannot set WKS_FILE in the image recipe instead of globally in the distro conf? Jan 18 16:24:50 v0n: you want two different wks file because you have mmc and sd card -ready artifacts to create Jan 18 16:24:59 and they are different is what you said Jan 18 16:26:41 qschulz: I thought you can specify the WKS_FILE in the image recipe, so a different file for every image recipes if you'd like. I might have been wrong. Jan 18 16:29:37 you would then have foodist-emmc foodist-sdcard foodist-preinit-emmc foodist-preinit-sdcard Jan 18 16:32:25 these are 4 image recipes for a single fooboard and two foodist and foodist-preinit distros, right? Jan 18 16:34:52 v0n: when using meta-/meta- I think it makes sens to use COMPATIBLE_MACHINE in the layer.conf ? Jan 18 16:37:32 roussinm: it might depends if the machine are compatible. For example I have a board based on beaglebone and its dev version, which require conf/machine/beaglebone.conf and does MACHINEOVERRIDES =. "beaglebone:". The "dev" variant simple require conf/machine/myboard.conf Jan 18 16:37:42 roussinm: no, layers shouldn't break anything if they are included but not used Jan 18 16:38:20 qschulz: how could it break anything? Jan 18 16:38:33 why do you need COMPATIBLE_MACHINE in the first place then? Jan 18 16:40:56 well if I use the multi-machine directory approach, when I source the environment, I shouldn't be parsing/building recipes that are not compatible for that build environment. Jan 18 16:41:27 if you don't want to parse recipes, don't include the layer Jan 18 16:41:39 if you don't want to build a recipe, don't add it to your image recipe Jan 18 16:41:56 if some recipes are machine specific, define in those recipes COMPATIBLE_MACHINE Jan 18 16:43:13 (and make them have PACKAGE_ARCH = "${MACHINE_ARCH}") Jan 18 16:43:16 Oh I see, so it's probably easier to use bblayers.conf in the build environment to configure that. Jan 18 16:43:58 yes, but honestly, except soime cases in which the layers have an enormous number of recipes, i don't think it's worth it to make bblayers.conf dynamic or configurable Jan 18 16:44:28 also, I'm afraid anything in layer.conf actually applies to everything since it predates all recipe parsing (same for local.conf) Jan 18 16:47:33 predates = happens before Jan 18 16:47:41 it feels redundant to specify COMPATIBLE_MACHINE in each recipes in a layer named : meta-, no? Jan 18 16:48:21 roussinm: for what it's worth, this made my life easier in terms of code organization: https://github.com/siemens/kas Jan 18 16:49:07 v0n: thanks, I'll take a look. Jan 18 17:35:21 LetoThe2nd: qschulz: last question, with the machine/distro/images distinction we were talking about, how can I organize my layers so that I end up with a boot partition containing my kernel + the preinit initramfs image, and a persistent partition with the "standard" rootfs? in order words, how do I organize my code to have a single .wic image for SD card containing these two rootfs? Jan 18 17:45:53 i'm having trouble running menuconfig inside the official Poky Docker image. is there a correct way to install libncurses-dev inside the image? Jan 18 17:58:01 the crops ones? Jan 18 17:58:10 tell rewitt to add ncurses-dev? :) Jan 18 18:06:08 @BCMM or add to the Dockerfile: RUN apt-get -y install libncursesw5-dev Jan 18 18:16:17 rburton: looks like somebody already tried that https://github.com/crops/poky-container/issues/17 Jan 18 18:17:18 RobertBerger1: i'm not really sure what to do with a Dockerfile. i've managed to get things working with `docker exec -u root raspi_dev apt-get install libncurses5-dev libtinfo-dev`, but that does involve downloading the packages again every time i start a container Jan 18 18:18:17 (also i'm kind of surprised that the image includes package index files; shouldn't i have to run apt update?) Jan 18 18:18:25 @BCMM So you don't built the container, I guess. Jan 18 18:19:44 @BCMM one option is what you do, but this is not going to stick, once you exit the container it's gone. Jan 18 18:19:52 indeed Jan 18 18:20:26 and yes, i'm pretty much just doing docker run at the moment as suggested, not building the image for myself Jan 18 18:21:00 @BCMM another option would be to create your own container, which includes the existing (containers, they are 2 actually) Jan 18 18:21:42 @BCMM a third option would be to git clone the crops stuff, extend the Dockerfile as you like and build it yourself Jan 18 18:23:38 @BCMM I went for the third option: https://github.com/RobertBerger/poky-container/blob/2020-07-26-master-local-gcc-9-gui-ub18/Dockerfile#L59 Jan 18 18:25:15 @BCMM for quick test you could try to pull my container: reliableembeddedsystems/poky-container:2020-07-26-master-local-gcc-9-gui-ub18 Jan 18 18:51:10 How can I get a single wic image with two rootfs (initramfs in a boot partition and a different persistent rootfs partition)? Jan 18 19:05:14 BCMM: if you have docker, easy enough to build your own image Jan 18 19:55:33 v0n: its exactly what i described earlier. you have multiconfig,, where the outer build packages the inner (initramfs) into /boot. Jan 18 20:32:20 Less of a yocto question, more of a design question. I'm looking to implement mender.io as an means of deploying upgrades, and I'm trying to figure a decent way to construct my image to support the upgrade operation. Specifically, I'm a bit locked up thinking about handling database schema changes. The database used by the system I'm developing Jan 18 20:32:20 contains user data, so obviously I want to persist. If the schema changes, how should I handle the schema change? Perhaps just including a database migration script in the upgrade, and use a one-time firing service to have it done on startup after the upgrade? Ideas feeling pretty messy Jan 18 20:52:23 LetoThe2nd: OK I'll try to learn more about multiconfig, I'm still not very used to it. As a first step, I guess I should work on a new distro definition for the initramfs image, correct? Jan 18 21:50:09 I have this in my initramfs recipe to deploy dm-verity hash: do_image[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"  and basically it works Jan 18 21:51:21 however I would like to do some char .replace() on the DM_VERITY_IMAGE_TYPE variable, but if I do \@d.getVar the variable seems not to be set. It is defined in machine configuariton file. Jan 18 21:53:44 Is there something special about this? I thought the variables should be there during recipe parsing. Some variables like MACHINE are there but not this one. Jan 18 21:55:04 How do you choose the kernel modules to be built-in? Jan 18 22:26:16 there's no occurrences of builtin kernel modules in the doc. Is it expected to simply provide a custom kernel config and remove "kernel-modules" from the packages? **** ENDING LOGGING AT Tue Jan 19 03:00:19 2021