Tuesday, 2021-09-07

*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto00:08
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds)00:17
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)01:03
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection)01:14
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto01:20
*** RobertBerger <RobertBerger!~rber|res@185-232-103-115.xdsl.philuweb.net> has joined #yocto01:32
*** rber|res <rber|res!~rber|res@185-232-103-115.xdsl.philuweb.net> has quit IRC (Ping timeout: 252 seconds)01:34
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection)01:49
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto02:14
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds)02:21
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…)03:26
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto04:18
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds)04:27
*** amitk <amitk!~amit@> has joined #yocto04:30
*** mischief1 <mischief1!~mischief@wopr.sciops.net> has quit IRC (*.net *.split)04:36
*** ykrons_ <ykrons_!~guillaume@> has quit IRC (*.net *.split)04:36
*** iokill <iokill!~dave@static.> has quit IRC (*.net *.split)04:36
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC (*.net *.split)04:36
*** iokill <iokill!~dave@static.> has joined #yocto04:36
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto04:37
*** ykrons_ <ykrons_!~guillaume@> has joined #yocto04:37
*** mischief1 <mischief1!~mischief@wopr.sciops.net> has joined #yocto04:37
*** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC (*.net *.split)04:41
*** zbr <zbr!zibri@shell.x20.se> has quit IRC (*.net *.split)04:41
*** zibri <zibri!zibri@shell.x20.se> has joined #yocto04:41
*** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has joined #yocto04:41
*** smurray <smurray!sid98062@stonehaven.irccloud.com> has quit IRC (*.net *.split)04:57
*** darknighte <darknighte!sid214177@user/darknighte> has quit IRC (*.net *.split)04:57
*** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (*.net *.split)04:57
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (*.net *.split)04:57
*** r4ge <r4ge!~timp@114-134-7-183.static.lightwire.co.nz> has quit IRC (*.net *.split)04:57
*** beneth <beneth!~beneth@ip208.ip-54-36-198.eu> has quit IRC (*.net *.split)04:57
*** chrysh <chrysh!~chrysh@someserver.de> has quit IRC (*.net *.split)04:57
*** mfe <mfe!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (*.net *.split)04:57
*** michaelo <michaelo!~mike@shells.bootlin.com> has quit IRC (*.net *.split)04:57
*** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto04:57
*** chrysh <chrysh!~chrysh@someserver.de> has joined #yocto04:57
*** michaelo <michaelo!~mike@shells.bootlin.com> has joined #yocto04:57
*** r4ge <r4ge!~timp@114-134-7-183.static.lightwire.co.nz> has joined #yocto04:57
*** smurray <smurray!sid98062@id-98062.stonehaven.irccloud.com> has joined #yocto04:57
*** mfe <mfe!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto04:57
*** darknighte <darknighte!sid214177@id-214177.stonehaven.irccloud.com> has joined #yocto04:58
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto04:59
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:53
*** creich_ <creich_!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has joined #yocto06:09
*** creich <creich!~creich@p200300f6af1cc310000000000000039b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)06:10
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto06:14
user_https://pastebin.com/xKsHDJJB can anyone help me resolving this error,iam trying to build a multimedia image with multilib support06:15
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Ping timeout: 250 seconds)06:16
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto06:24
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 252 seconds)06:32
*** mckoan|away is now known as mckoan06:36
*** frieder <frieder!~frieder@mue-88-130-75-072.dsl.tropolys.de> has joined #yocto06:36
mckoangood morning06:36
*** Guest9959 <Guest9959!~Guest99@host-79-3-92-72.business.telecomitalia.it> has joined #yocto06:50
*** Guest9959 <Guest9959!~Guest99@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Client Quit)06:53
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:55
*** user_ is now known as user_12306:56
user_123I need to enable multilib support in My yoctobuild06:56
*** creich_ <creich_!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)06:57
*** creich <creich!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has joined #yocto06:57
user_123I am getting errors when local.conf is modified as suggested by NXP06:57
user_123 https://pastebin.com/xKsHDJJB i added the error log06:58
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto06:58
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto06:58
mckoanuser_123: no clue. Maybe describe what you are doing06:58
user_123I am running bitbake imx-image-multimedia06:59
user_123I am getting errors06:59
user_123Please see  https://pastebin.com/xKsHDJJB07:00
user_123For error log07:00
RPuser_123: it is really hard to know what the problem is there. If this has the freescale layer involved you probably need to ask NXP as that layer changes a lot. Have you tried to do this with just plain poky?07:07
user_123RP: no, i have not tried with plain poky07:21
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:23
*** Guest39 <Guest39!~Guest39@> has joined #yocto07:23
Guest39Hi, I have a problem with the Freescale ethernet driver, likely dpaa_eth.c. Sometimes I see rotten packets which are not dropped but handled much too late, and such packets have a hardware timestamp in the future then. Is any developer here who wants to see the wireshark recording? I use dunfell for imx8 with a Linux kernel of one year ago.07:35
qschulzGuest39: if it's a HW timestamp, i'm pretty sure it's not an issue with Yocto? so might want to contact your vendor (NXP or the OEM using NXP SoCs and/or the one selling the Ethernet PHY)07:42
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto07:42
Guest39I measure with tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced  ... and I think this switches HW timestamps on.07:48
Guest39Anyway this is how I understand the tcpdump options07:49
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 256 seconds)08:01
*** Xagen <Xagen!~Xagen@2600:1700:211:7e60:5014:2675:6930:a231> has quit IRC (Ping timeout: 245 seconds)08:09
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto08:12
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:12
mckoanGuest39: 99% HW issue08:20
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Read error: Connection reset by peer)08:21
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto08:22
Guest39Is it the PHY which sets HW timestamps on an imx8?08:24
qschulzGuest39: I doubt there's an Ethernet PHY embedded in the i.MX8 so it depends on the board you're using08:25
qschulzyour PHY needs to support it, and the driver driving your PHY needs to support it too08:25
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto08:29
kanavinRP: I have reproduced https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342#c20 with master (Setscene tasks in both covered and notcovered errors at the end of build)08:35
kanavinRP: can you suggest where I could start with figuring out what goes wrong there?08:35
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 265 seconds)08:37
RPkanavin: you can look at the patches I previously added to runqueue around this area. Oddly enough I was planning to take a look at that again today08:41
RPkanavin: there isn't a simple/easy way to even explain where to start on that one :/08:42
kanavinRP: right, if you do that'd be appreciated - a customer is asking me to prioritize this, but I have no idea where to start without a bit of help from you08:42
kanavinRP: but it does reproduce fairly easily, so hopefully that helps you08:42
RPkanavin: there is a logic glitch somewhere. A task should never be both covered and notcovered, it should be one or the other08:43
RPkanavin: the question is therefore which codepath ends up with an item on both08:43
RPkanavin: which reproducer did you use?08:43
kanavinRP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342#c2008:43
kanavinone in that last comment08:44
RPok, the new one. I've not tried that08:44
RPkanavin: I think something in the last patches I merged "regressed" this. Would be interesting to know if this test case worked before that set of patches08:48
kanavinRP: I can try if you point me to suspected good commit08:49
RPkanavin: I say "regressed" as there is a lot I like about that last patchset, so it is a question of trying to fix whatever cornercase broke rather than revert it08:49
RPkanavin: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a15eea5077506111e4167a2361da0306d23543f308:50
*** bps <bps!~bps@> has joined #yocto08:52
RPkanavin: basically revert that, I was thinking it was a set but I think it was just the one08:53
*** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has quit IRC (Quit: You have been kicked for being idle)09:00
kanavinRP: will run before&after test on that now09:00
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection)09:04
*** bps <bps!~bps@user/bps> has quit IRC (Remote host closed the connection)09:16
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Read error: Connection reset by peer)09:29
*** zyga <zyga!~zyga@> has joined #yocto09:29
kanavinRP: yes, that is the offending commit09:34
RPkanavin: I can confirm it does reproduce here too09:44
*** obcecado <obcecado!pcaetano@tilde.institute> has quit IRC (Quit: leaving)09:46
kanavinRP: and gone with the revert09:47
RPkanavin: right :/09:50
RPkanavin: although it does always print about deadlock first so I think the bug may be that the deadlock code adds to both covered and not covered09:51
RPkanavin: so two issues: a) why does it deadlock and should it? b) does the deadlock code do something incorrectly09:52
kanavinRP: even before it prints about deferring (and does not with the revert), so I'm not sure if that is an issue too09:52
RPkanavin: The deferring would be expected for builds with multiple similar tasks09:53
wCPOIs there any convention for where to put recipe? recipes-foo/foo ?09:55
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)09:56
kanavinwCPO, recipes-domain/foo09:56
rburtonwCPO: your layer, so you get to define the recipes-* namespaces09:56
wCPOkanavin, rburton: naming is always hard :) I will try to stick with recipes-domain/foo09:59
rburtonyour layer will basically enforce that unless you change layer.conf09:59
RPkanavin: I think if setscene is present, tasks in the deferred list aren't being made available. The logs are odd10:00
*** iokill <iokill!~dave@static.> has quit IRC (Ping timeout: 252 seconds)10:04
*** derRichard <derRichard!~derRichar@static.> has quit IRC (Ping timeout: 245 seconds)10:04
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto10:18
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)10:22
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:27
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 265 seconds)10:33
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto10:34
*** iokill <iokill!~dave@static.> has joined #yocto10:34
*** derRichard <derRichard!~derRichar@static.> has joined #yocto10:35
RPkanavin: I think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1cd2b6defa1e77d84cb268571edc1cacf9b57cd1 is a decent workaround10:39
RPkanavin: I'm still not quite show whether there is a better fix for this10:39
wCPOIs there any reason for some recipe using not following the "Packages should install their configuration files in /usr/lib/tmpfiles.d." convention for tmpfiles.d? (connman, cups, bind)10:40
RPwCPO: where is that a quote from?10:41
wCPORP: the manpage: https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html . It is the same for systemd service file10:41
RPwCPO: I suspect the guidance from systemd has changed over time and the recipes aren't keeping up10:42
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 260 seconds)10:42
wCPORP: I see. I'm coming from Arch Linux where packages must never install anything into /etc/tmpfiles.d or /etc/systemd/system, so just wanted to know if the recipe was out-of-date or I missed something :)10:43
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto10:45
rburtonwCPO: if the bug is in the recipe itself, send a patch, otherwise send a bug report/patch upstream10:50
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds)10:51
kanavinRP: sleep on it?10:54
RPkanavin: I'm staring at the code a bit. There is something just slightly out of reach with regard to fixing this10:54
frosteyes1Hi folks. I just have an interresting issue while trying to upgrade poky / dunfell on a platform I am working with. The issue is a permission issue.10:56
frosteyes1The issue is this - Exception: bb.process.ExecutionError: Execution of '/builds/x/x/x/x/build/tmp/work/x/x/1.0-r0/temp/run.reproducible_final_image_task.34850' failed with exit code 123:10:57
frosteyes1With a bunch of Exception: bb.process.ExecutionError: Execution of '/builds/x/x/x/x/build/tmp/work/x/x/1.0-r0/temp/run.reproducible_final_image_task.34850' failed with exit code 123:10:57
frosteyes1For the different license files.10:57
frosteyes1Notice it is not an issue when building local - but it is an issue when building on our build server.10:58
frosteyes1As it was working with the older dunfell release, I have looked into what have changed and found this one liner..10:59
mihaifrosteyes1: check the equivalent log file log.reproducible_final...11:00
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto11:01
mihaiexit code 123 smells like pseudo abort11:01
frosteyes1mihai: thanks.11:02
frosteyes1The commit I linked to was a change from using a single process with find to touch the files, to now using a pipe with xargs and touch.11:02
frosteyes1So was wandering if this change also changed how interitance of permission for the touch process with regards to fakeroot / pseudo..11:04
*** frosteyes1 is now known as frosteyes11:04
mihaior arguments list too long11:09
frosteyesGood point..11:09
RPkanavin: two patches sent to the bitbake list which I think should resolve this11:16
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto11:29
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto11:30
*** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has joined #yocto11:45
*** beneth <beneth!~beneth@2001:41d0:c:a71:1000:25::> has joined #yocto12:02
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Remote host closed the connection)12:11
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto12:11
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto12:17
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto12:19
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9c94:7807:4c0c:960> has joined #yocto12:19
*** andy99 <andy99!~andy@> has joined #yocto12:23
*** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has left #yocto12:23
*** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has joined #yocto12:24
andy99Hello everyone. can I ask you a question about the kernel-fitimage?12:25
mihaiandy99: don't ask to ask, just ask :)12:28
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto12:28
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection)12:28
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto12:29
andy99:) ok, so ... what's the current status of usage kernel-fitimage including initrams? Why is not part of rootfs? Or even better, how to get the image into rootfs?12:30
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Quit: Leaving)12:32
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto12:33
Guest39andy99: Is kernel-fitimage one of the available initramfs image types?12:35
andy99I think so, because it's being produced into deploydir but not into rootfs12:36
Guest39andy99: The initramfs is an image which will be bundled to the kernel image12:37
andy99yes, and the kernel is deployed into deploydir instead of rootfs12:37
Guest39andy99: The kernel is a file in the boot partition. When the kernel starts as a process it loads the initramfs from its appendix on the kernel image. After the initramfs is loaded a script in the initramfs will load the rootfs. Usually the rootfs is located in another partition.12:40
andy99I think, that I know, how the initramfs works :). The main problem is, that this type of image is created after packing, so it's not inside any package. So it can't be installed.12:41
Guest39andy99: So I suppose your problem is the initramfs is not bundled to the kernel image, right?12:42
Guest39andy99: I don't know if that helps for you since I use core-image-tiny-imageramfs but maybe you can adapt my .conf file:12:46
Guest39INITRAMFS_IMAGE = "core-image-tiny-initramfs"12:47
andy99no, initramfs is created, but not inside the pckage12:47
Guest39VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"12:47
andy99because it's created afterwards the packaging process12:48
Guest39andy99: it's created in the second step but will be bundled to the kernel afterwards12:50
Guest39andy99: ... if you configure the bundling properly as shown above12:50
andy99Yes, I have the similar setup12:51
smurrayandy99: one way would be to add it to IMAGE_BOOT_FILES if using the bootimg-partition partition type12:52
andy99no, I don't have a boot partition12:52
andy99everything is inside rootfs/boot folder12:52
smurrayafaik you'll need to do up a custom image recipe that depends upon the initramfs and copies it in12:53
smurrayif you're using wic and /boot has the usual stuff in it, living with a second partition and using bootimg-partition might be simpler12:55
*** Guest60 <Guest60!~Guest60@95-105-142-182.dynamic.orange.sk> has joined #yocto12:55
andy99but is it a problem to have it inside rootfs?12:59
*** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto13:02
qschulzandy99: so you want your kernel with an initramfs inside the actual initramfs?13:02
qschulzThere is an egg/chicken issue there13:03
andy99no, maybe I didn't write it correctly. Currently I was using the generic kernel. Now I would like to switch into signing one. The bootloader (u-boot) should unpack the initramfs from kernel and verify the signature. Afterwards the device will be booted.13:04
andy99so I need to have bundled initramfs inside the kernel. But the artifacts is not being created inside any package, just in the deploy folder.13:05
andy99I would like to "take" the artifacts from deploy folder and install it into rootfs13:05
Guest39andy99: It makes more sense to put the key files which you need for verifying into the boot partition but not in a folder of the root partition13:10
andy99currently I have only one partition13:10
andy99Does it mean, to have a separated /boot partition is better idea?13:11
Guest39andy99: Separating is a better idea in my opinion, and it works :)13:11
Guest39andy99: The bootloader must not mount the whole disk just for running the kernel13:13
andy99What I heard, the reason why is "disabled" on the master is, that there was some kind of circular dependency, but I don't have a more info.13:13
qschulzyour rootfs is not your initramfs is it?13:19
qschulzyour initramfs is here just to do a dm_verity of the actual rootfs and then switch_root to it?13:20
Guest60qschulz: yes, this is the design13:20
qschulzGuest60: that was not clear, because the initramfs can be the rootfs (and actually is, just a temporary one in your case)13:21
qschulzyeah there was (and maybe still is) a circular dependency13:21
qschulzyou need a handcrafted kernel-fitimage class13:22
qschulzor check what Bartosz from Baylibre tried to upstream a few months ago13:22
qschulzI don't remember if it was ever merged but I think not13:22
Guest39andy99: I understood your folder with the key files for verifying is in the rootfs. But do you mean that folder is in the initramfs?13:24
andy99do you have the link somewhere?13:24
qschulzhttps://bootlin.com/pub/conferences/2018/elc/josserand-schulz-secure-boot/josserand-schulz-secure-boot.pdf slide 4213:25
qschulzis the issue we ran into13:25
Guest60Guest39:  the key files are in the initramfs, the signatures are passed in the kernel cmdline from u-boot environment13:26
qschulzand that you'll run into13:27
qschulzseems like it was merged in meta-security13:28
qschulzyou probably need other stuff too13:28
qschulzthis is not using the u-boot script/fitimage mechanism though\13:29
Guest60Just to be clear - we don't use dm-verity - problem is that our embedded device can't crash on integrity error during the runtime, so we check on boot.13:31
Guest60But maybe we can get some bits and pieces for our implementation.13:31
qschulzhttps://lists.openembedded.org/g/openembedded-core/topic/74158924 last version13:34
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9c94:7807:4c0c:960> has quit IRC (Ping timeout: 260 seconds)13:35
Guest60qschulz: Thank you. I'll take a look and contact you in the case of other questions.13:36
andy99qschulz: that's the right link ;). But it's from 2020, so no further movement?13:37
qschulzandy99: not that I know13:38
qschulzGuest60: not personally please :) continue the discussion here, on the mailing list or contact the people who worked on this, they *might* be ok with you contacting thm direclty13:38
Guest60qschulz: Ok, i completely understand. I'll proccess the links you provided, and then try the mailing list. Thanks for the info provided so far.13:42
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto13:42
qschulzGuest60: my pleasure. Wondering what you have decided to go for instead of dm-verity though :)13:43
Guest60Just to check the whole partition signature using dd & openssl. The issue is, that the device does some things very rarely, and when we check the blocks on access, the kernel panic or other indication can occur in a very critical time.13:47
*** angolini <angolini!uid62003@id-62003.helmsley.irccloud.com> has joined #yocto13:49
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)13:53
Guest39that's why it's better to load the kernel before that partition becomes actively mounted13:55
*** sakoman <sakoman!~steve@> has joined #yocto14:00
Guest60Guest39: Crash during the startup is not critical at all, but the crash during runtime can be an issue.14:01
Guest39ok, I see14:07
*** Guest60 <Guest60!~Guest60@95-105-142-182.dynamic.orange.sk> has quit IRC (Quit: Client closed)14:20
smurrayqschulz: the circular dependency issue with dm-verity comes from e.g. needing kernel modules in the rootfs, but the rootfs hash is needed for the initramfs that gets built in the kernel recipe14:24
qschulzsmurray: we had the circular depenedency because of u-boot script storing the root hash needed by dm_verity stored in the kernel fitimage14:25
qschulzexcept the kernel fitimage is created after the rootfs14:25
qschulz(in yocto)14:25
smurrayqschulz: yes, it's easy to get there with the fitimage14:25
qschulzor is it before, eh don't remember, long time ago14:26
qschulzit was in the slides I linked :p14:26
smurrayqschulz: aiui there are some standalone initramfs recipes floating around, but nothing upstreamed14:26
* qschulz hides14:26
smurrayheh, I've thought about working one up, but have not, so I can't point any fingers14:27
qschulzI left the company so can't upstream this anymore as I don't recall any of it14:27
qschulzand it would have been probably  a bit too hacky14:27
qschulzmaybe we should ping bartosz/rp again on that topic14:27
smurrayit's going to become a more common issue as dm-verity shows up on more reqts lists, so sooner or later something will be needed upstream14:28
* qschulz nods14:29
*** marex <marex!~marex@> has joined #yocto14:33
andy99yes, the artifacts are created afterwards14:35
kanavinRP: thanks, I am not setting up the previous reported build which presumably regressed due to these fixes, to confirm (or not)14:49
*** andy99 <andy99!~andy@> has quit IRC (Quit: Leaving)15:00
kanavinRP: and sadly... yes. Wrote a comment in https://bugzilla.yoctoproject.org/show_bug.cgi?id=1434215:07
thekappehello guys.. I need a hint15:07
thekappeI have a kernel recipe append file that install some .bin in ${D}/lib/firmware15:08
*** Guest39 <Guest39!~Guest39@> has quit IRC (Quit: Guest39)15:09
thekappeby the way, when the image is built, in build/tmp/work/machine/image/image/ver/rootfs/lib/firmware I have just one .bin file instead of the two of them15:09
thekappethe strange thing is that in in build/tmp/work/machine/kernel/ver/image/lib/firmware I have both of them15:10
qschulzthekappe: I guess they are split in different packages and you only install one of them?15:10
qschulzoe-pkgdata-util find-path '*yourbin.bin'15:11
thekappeyou are always right qschulz15:12
*** camus <camus!~Instantbi@2409:8a1e:911c:bc40:e4e3:c8f8:b37f:894f> has joined #yocto15:13
yanndin yocto 1.6 we had a basepath= parameter for file: SRC_URI's, and this old manual version keeps coming up in searches, while the parameter does not exist any more and was never mentionned in "Upgrading to ..." sections.15:16
yannddid anything replaced it ?15:18
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto15:25
kanavinRP: *not ---> now15:32
kanavin(I am *now* setting up...)15:33
qschulzyannd: what was the purpose of such a parameter?15:36
*** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection)15:37
*** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has joined #yocto15:39
yanndqschulz: I'd have used it to shorten paths under ${S}.  Currently using an absolute file:// URI just copies the full absolute path (under ${WORKDIR} by default)15:48
yanndyes, I know absolute file:// is not a good idea, but in some corporate environments that can be the only available way to get to some files15:49
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)15:50
yanndhere is how it has to be handled AFAIK: https://stackoverflow.com/a/69091155/628502315:51
*** mckoan is now known as mckoan|away15:52
qschulzyeah I would have said subdir too15:53
yanndmy first try after googling for unpack parameters (yes I'm kinda lazy with the docs) was to use both subdir and basepath... until I realized basepath is just doing nothing and I was looking at an outdated doc.  Then I googled to know what replaced that parameter and only found that unanswered question ...15:56
yanndin fact I'm pretty sure now I already got hit by that old doc item in the past, so my SA answer is as much a reminder to a future self as to anyone else...15:58
qschulzyannd: removed in 201615:59
qschulz    (Bitbake rev: e659a3b0c2771679057ee3e13cd42e6c62383ff2)15:59
qschulzremoved from the docs only recently16:00
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)16:03
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto16:03
*** sakoman <sakoman!~steve@> has joined #yocto16:08
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:08
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 260 seconds)16:13
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:14
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)16:19
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)16:24
RPkanavin: Shame it regresses the other test case :(16:25
RPkanavin: that is quite frustrating16:26
smurrayoh boy, OpenSSL 3.0 has officially released16:45
*** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed)16:46
RPkanavin: hmm, I do understand what breaks in that other test case16:48
fraysmurray thanks for the heads up..16:48
RPsmurray: should we try and get that into 3.4? :)16:51
*** goliath <goliath!~goliath@user/goliath> has joined #yocto16:52
smurrayRP: heh, definitely not16:52
RPsmurray: I don't think I could take it (and more seriously, the user projects need to adapt first)16:52
smurrayRP: yeah, I'll be curious to see how quick Fedora jumps on it16:54
smurrayRP: I suspect the bigger pain comes whenever they do a release that drops the piles of APIs they've marked as deprecated in 3.016:56
*** frieder <frieder!~frieder@mue-88-130-75-072.dsl.tropolys.de> has quit IRC (Remote host closed the connection)16:59
wCPORP: Is it the fix or the broken commit you linked here? https://lore.kernel.org/qemu-devel/709a88a0f24ed8fd5399a2be88fb9d57ceb0a25a.camel@linuxfoundation.org/16:59
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto17:00
RPwCPO: Not sure I understand your question?17:00
wCPORP: it is your mail right? You linked the same commit twice17:01
RPwCPO: ah,yes, I did mess that up17:01
RPwCPO: that commit broke things iirc and the fix was https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=rcu/next&id=dc87740c8a6806bd2162bfb441770e4e53be560117:05
wCPORP: thanks, we started seeing some "rcu_preempt detected stalls" recently in Arch Linux CI. Not sure it is related tho17:09
RPwCPO: can have many causes, if it locks the system up entirely this one could be a cause though17:10
*** robbawebba <robbawebba!~rob@> has joined #yocto17:10
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto17:14
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds)17:15
RPkanavin: ok, I think my fix was the right idea, wrong function: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=e6ec662c597cdad358f08a9ec9a5effea28978d117:20
RPkanavin: master-next updated17:24
robbawebbaHello, I have a question about premirrors, specifically using the "own-mirrors" bbclass. I noticed that the DL_DIR contains the source code archives as well as a .done file for each archive. Should the .done files be served from a mirror along with the actual source code archives, or will the .done file be created by the client after downloading from the mirror?17:32
kergothrobbawebba: the latter17:32
fray.done files won't cause failures from the mirror server, but they also don't do anything.  I usually remove them from the server17:46
whuang0389I need to provide my own hostapd.conf file17:49
whuang0389whats the preferred way of doing it?17:50
kanavinRP: thanks, I'll try that once I get out of cycling kit and shower ;)17:57
RPkanavin: I think the test case in c13 will throw "errors" but I'm not sure these new ones are the fault of runqueue18:03
kanavinRP: I'll try. And gah, that Damian guy on bitbake-devel :-/18:04
kanavinRP: meanwhile, I have some results from lttng-tools 10x ptests18:05
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)18:07
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto18:09
RPkanavin: I think I understand what is going on with the new errors. Trying to decide if I want to fix the sstate hashes or runqueue further18:10
robbawebbaThanks kergoth and fray :)18:11
robbawebbawhuang0389: The preferred way of doing it should be creating your own bbappend file for the hostapd package. In this bbappend file, you'll want to append the path to your custom file to the FILES variable, and you'll probably need a custom do_install_append function to overwrite the default config.18:16
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed)18:18
robbawebbawhoops, I said FILES, but I meant SRC_URI18:18
kanavinRP: let me know when you have something you'd like me to test18:19
*** angolini <angolini!uid62003@id-62003.helmsley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)18:19
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 260 seconds)18:20
*** zyga <zyga!~zyga@> has quit IRC (Ping timeout: 252 seconds)18:24
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto18:27
RPkanavin: master-next has a tweaked patch which is ready for wider testing again. I'll continue to run local tests too18:35
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Read error: Connection reset by peer)18:36
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto18:37
abelloniRP: I just sent the previous one to the AB, should I restart ?18:38
abelloniwell, 42 minutes ago18:38
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto18:50
*** BobPungartnik <BobPungartnik!~Pung@> has joined #yocto18:51
*** BobPungartnik <BobPungartnik!~Pung@> has quit IRC (Client Quit)18:52
whuang0389robbawebba thanks, it worked! I guess Yocto wasn't happy when I overwrote the hostapd.conf file with the one in application recipe18:52
*** camus <camus!~Instantbi@2409:8a1e:911c:bc40:e4e3:c8f8:b37f:894f> has quit IRC (Quit: camus)18:52
RPabelloni: please19:05
RPabelloni: it would be worth testing these two properly as my local testing shows they're better19:06
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)19:17
vdIs it OK to use the deploy class to copy a final image to a specific (CI/CD) directory (not DEPLOYDIR/DEPLOY_DIR_IMAGE)?19:32
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)19:39
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)19:42
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto19:42
JPEWvd: You might have touble with task reruns if you try to do that19:50
JPEWI wouldn't recommend it at least19:50
vdJPEW so I shouldn't inherit the deploy class?19:55
*** RobertBerger <RobertBerger!~rber|res@185-232-103-115.xdsl.philuweb.net> has quit IRC (Ping timeout: 252 seconds)20:06
JPEWvd: You cause use it, but it might cause some issues if you don't deploy to DEPLOYDIR20:19
*** Guest98 <Guest98!~Guest98@2001:16b8:57b3:5e00:4013:76ec:9bb4:ec66> has joined #yocto20:20
JPEWvd: What is it you want to accomplish?20:20
*** Guest98 <Guest98!~Guest98@2001:16b8:57b3:5e00:4013:76ec:9bb4:ec66> has quit IRC (Client Quit)20:21
vdJPEW a bit like you alias deploy whisk class, I need the CI/CD to copy the interesting output files (not all of them) to a different local directory20:23
*** goliath <goliath!~goliath@user/goliath> has joined #yocto20:38
JPEWvd: Copy files out of deploydir?20:42
JPEWor DEPLOY_DIR_IMAGE more specifically?20:42
JPEWMy first thought would be "Do you really need to run that as a bitbake task for some reason?" It seems like your CI/CD could have a post-build script that copies the output from deploy dir to where ever you want it20:43
JPEW(But I might be misunderstanding what you are trying to do)20:44
vdout of DEPLOY_DIR_IMAGE. I could simply upload DEPLOY_DIR_IMAGE but there is so much image files we don't need in there, it's confusing. I only need to copy a few final image files to a locally mounted server directory.20:44
vdgood question. The thing is that only bitbake knows about specific path for a multiconfig (e.g. DEPLOY_DIR_IMAGE, BB_CURRENT_MC, etc.)20:45
JPEWvd: Ah, ya, that's a common problem; the best solution (that I've found) is to fix it by having a convention for how your files and directories are named; the is effectively what whisk does, although it has the convenience of setting some variables for you to make it a little easier.20:47
JPEWvd: But, there is another way; you can actually ask bitbake the value of those variables. Sort of like you do manually with `bitbake -e`20:48
JPEWvd: I think there is a command or library that can be used to query that programatically?20:48
RPJPEW: bitbake-getvar ?20:59
RPor tinfoil21:00
*** florian <florian!~florian@dynamic-093-135-141-137.93.135.pool.telefonica.de> has joined #yocto21:03
vdhum, I donno. I have a dummy recipe to group all interesting images, and I build this dummy recipe for all my multiconfig (these are build profiles). I think the simplest is still to have a simple additional task in this dummy recipe to copy its images to a custom directory.21:11
*** creich_ <creich_!~creich@p200300f6af262d106bbd1ab975fe5d89.dip0.t-ipconnect.de> has joined #yocto21:12
*** creich <creich!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds)21:14
*** amitk_ <amitk_!~amit@> has joined #yocto21:20
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 252 seconds)21:23
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto21:35
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed)21:39
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto21:40
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto21:43
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Client Quit)21:44
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)22:11
*** amitk_ <amitk_!~amit@> has quit IRC (Quit: leaving)22:13
*** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Quit: Leaving)22:19
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection)22:25
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto22:27
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)22:37
*** florian <florian!~florian@dynamic-093-135-141-137.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds)22:58
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 240 seconds)22:59
*** yannd <yannd!~yann@> has joined #yocto23:41
*** yannd <yannd!~yann@> has quit IRC (Ping timeout: 260 seconds)23:46
*** yannd <yannd!~yann@> has joined #yocto23:58

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!