<RP>
user_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?
<user_123>
RP: no, i have not tried with plain poky
leon-anavi has joined #yocto
Guest39 has joined #yocto
<Guest39>
Hi, 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.
<qschulz>
Guest39: 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)
prabhakarlad has joined #yocto
<Guest39>
I measure with tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced ... and I think this switches HW timestamps on.
<Guest39>
Anyway this is how I understand the tcpdump options
bps has quit [Ping timeout: 256 seconds]
Xagen has quit [Ping timeout: 245 seconds]
Xagen has joined #yocto
florian has joined #yocto
<mckoan>
Guest39: 99% HW issue
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<Guest39>
Is it the PHY which sets HW timestamps on an imx8?
<qschulz>
Guest39: I doubt there's an Ethernet PHY embedded in the i.MX8 so it depends on the board you're using
<qschulz>
your PHY needs to support it, and the driver driving your PHY needs to support it too
<kanavin>
RP: can you suggest where I could start with figuring out what goes wrong there?
te_johan has quit [Ping timeout: 265 seconds]
<RP>
kanavin: 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 today
<kanavin>
RP: 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 you
<RP>
kanavin: there isn't a simple/easy way to even explain where to start on that one :/
<kanavin>
RP: but it does reproduce fairly easily, so hopefully that helps you
<RP>
kanavin: there is a logic glitch somewhere. A task should never be both covered and notcovered, it should be one or the other
<RP>
kanavin: the question is therefore which codepath ends up with an item on both
<RP>
kanavin: 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 patches
<kanavin>
RP: I can try if you point me to suspected good commit
<RP>
kanavin: 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 it
<RP>
kanavin: I'm still not quite show whether there is a better fix for this
<wCPO>
Is 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)
<RP>
wCPO: I suspect the guidance from systemd has changed over time and the recipes aren't keeping up
te_johan has quit [Ping timeout: 260 seconds]
<wCPO>
RP: 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 :)
florian_kc has joined #yocto
<rburton>
wCPO: if the bug is in the recipe itself, send a patch, otherwise send a bug report/patch upstream
florian_kc has quit [Ping timeout: 252 seconds]
<kanavin>
RP: sleep on it?
<RP>
kanavin: I'm staring at the code a bit. There is something just slightly out of reach with regard to fixing this
<frosteyes1>
Hi 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.
<frosteyes1>
The 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:
<frosteyes1>
With 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:
<frosteyes1>
For the different license files.
<frosteyes1>
Notice it is not an issue when building local - but it is an issue when building on our build server.
<frosteyes1>
As it was working with the older dunfell release, I have looked into what have changed and found this one liner..
<mihai>
frosteyes1: check the equivalent log file log.reproducible_final...
<frosteyes1>
The 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.
<frosteyes1>
So was wandering if this change also changed how interitance of permission for the touch process with regards to fakeroot / pseudo..
frosteyes1 is now known as frosteyes
<mihai>
or arguments list too long
<frosteyes>
Good point..
<RP>
kanavin: two patches sent to the bitbake list which I think should resolve this
jmiehe has joined #yocto
te_johan has joined #yocto
TrevorWoerner[m] has joined #yocto
beneth has joined #yocto
te_johan has quit [Remote host closed the connection]
te_johan has joined #yocto
florian_kc has joined #yocto
xmn has joined #yocto
manuel1985 has joined #yocto
andy99 has joined #yocto
TrevorWoerner[m] has left #yocto [#yocto]
xicopitz[m] has joined #yocto
<andy99>
Hello everyone. can I ask you a question about the kernel-fitimage?
<mihai>
andy99: don't ask to ask, just ask :)
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
<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?
tgamblin_ has quit [Quit: Leaving]
tgamblin has joined #yocto
<Guest39>
andy99: Is kernel-fitimage one of the available initramfs image types?
<andy99>
I think so, because it's being produced into deploydir but not into rootfs
<Guest39>
andy99: The initramfs is an image which will be bundled to the kernel image
<andy99>
yes, and the kernel is deployed into deploydir instead of rootfs
<Guest39>
andy99: 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.
<andy99>
I 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.
<Guest39>
andy99: So I suppose your problem is the initramfs is not bundled to the kernel image, right?
<Guest39>
andy99: I don't know if that helps for you since I use core-image-tiny-imageramfs but maybe you can adapt my .conf file:
<andy99>
because it's created afterwards the packaging process
<Guest39>
andy99: it's created in the second step but will be bundled to the kernel afterwards
<Guest39>
andy99: ... if you configure the bundling properly as shown above
<andy99>
Yes, I have the similar setup
<smurray>
andy99: one way would be to add it to IMAGE_BOOT_FILES if using the bootimg-partition partition type
<andy99>
no, I don't have a boot partition
<andy99>
everything is inside rootfs/boot folder
<smurray>
afaik you'll need to do up a custom image recipe that depends upon the initramfs and copies it in
<smurray>
if you're using wic and /boot has the usual stuff in it, living with a second partition and using bootimg-partition might be simpler
Guest60 has joined #yocto
<andy99>
but is it a problem to have it inside rootfs?
paulg has joined #yocto
<qschulz>
andy99: so you want your kernel with an initramfs inside the actual initramfs?
<qschulz>
There is an egg/chicken issue there
<andy99>
no, 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.
<andy99>
so I need to have bundled initramfs inside the kernel. But the artifacts is not being created inside any package, just in the deploy folder.
<andy99>
I would like to "take" the artifacts from deploy folder and install it into rootfs
<Guest39>
andy99: 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 partition
<andy99>
currently I have only one partition
<andy99>
Does it mean, to have a separated /boot partition is better idea?
<Guest39>
andy99: Separating is a better idea in my opinion, and it works :)
<Guest39>
andy99: The bootloader must not mount the whole disk just for running the kernel
<andy99>
What 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.
<qschulz>
your rootfs is not your initramfs is it?
<qschulz>
your initramfs is here just to do a dm_verity of the actual rootfs and then switch_root to it?
<Guest60>
qschulz: yes, this is the design
<qschulz>
Guest60: that was not clear, because the initramfs can be the rootfs (and actually is, just a temporary one in your case)
<qschulz>
yeah there was (and maybe still is) a circular dependency
<qschulz>
you need a handcrafted kernel-fitimage class
<qschulz>
or check what Bartosz from Baylibre tried to upstream a few months ago
<qschulz>
I don't remember if it was ever merged but I think not
<Guest39>
andy99: I understood your folder with the key files for verifying is in the rootfs. But do you mean that folder is in the initramfs?
<qschulz>
this is not using the u-boot script/fitimage mechanism though\
<Guest60>
Just 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.
<Guest60>
But maybe we can get some bits and pieces for our implementation.
<Guest60>
qschulz: Thank you. I'll take a look and contact you in the case of other questions.
<andy99>
qschulz: that's the right link ;). But it's from 2020, so no further movement?
<qschulz>
andy99: not that I know
<qschulz>
Guest60: 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 direclty
<Guest60>
qschulz: Ok, i completely understand. I'll proccess the links you provided, and then try the mailing list. Thanks for the info provided so far.
roussinm has joined #yocto
<qschulz>
Guest60: my pleasure. Wondering what you have decided to go for instead of dm-verity though :)
<Guest60>
Just 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.
angolini has joined #yocto
camus has quit [Quit: camus]
<Guest39>
that's why it's better to load the kernel before that partition becomes actively mounted
sakoman has joined #yocto
<Guest60>
Guest39: Crash during the startup is not critical at all, but the crash during runtime can be an issue.
<Guest39>
ok, I see
Guest60 has quit [Quit: Client closed]
<smurray>
qschulz: 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 recipe
<qschulz>
smurray: we had the circular depenedency because of u-boot script storing the root hash needed by dm_verity stored in the kernel fitimage
<qschulz>
except the kernel fitimage is created after the rootfs
<qschulz>
(in yocto)
<smurray>
qschulz: yes, it's easy to get there with the fitimage
<qschulz>
or is it before, eh don't remember, long time ago
<qschulz>
it was in the slides I linked :p
<smurray>
qschulz: aiui there are some standalone initramfs recipes floating around, but nothing upstreamed
* qschulz
hides
<smurray>
heh, I've thought about working one up, but have not, so I can't point any fingers
<qschulz>
I left the company so can't upstream this anymore as I don't recall any of it
<qschulz>
and it would have been probably a bit too hacky
<qschulz>
maybe we should ping bartosz/rp again on that topic
<smurray>
it'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 upstream
* qschulz
nods
marex has joined #yocto
<andy99>
yes, the artifacts are created afterwards
<kanavin>
RP: thanks, I am not setting up the previous reported build which presumably regressed due to these fixes, to confirm (or not)
<thekappe>
I have a kernel recipe append file that install some .bin in ${D}/lib/firmware
Guest39 has quit [Quit: Guest39]
<thekappe>
by 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 them
<thekappe>
the strange thing is that in in build/tmp/work/machine/kernel/ver/image/lib/firmware I have both of them
<qschulz>
thekappe: I guess they are split in different packages and you only install one of them?
<yannd>
in 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.
<yannd>
did anything replaced it ?
vd has joined #yocto
<kanavin>
RP: *not ---> now
<kanavin>
(I am *now* setting up...)
<qschulz>
yannd: what was the purpose of such a parameter?
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #yocto
<yannd>
qschulz: 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)
<yannd>
yes, 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 files
sakoman has quit [Read error: Connection reset by peer]
<yannd>
my 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 ...
<yannd>
in 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...
<robbawebba>
Hello, 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?
<kergoth>
robbawebba: the latter
<fray>
.done files won't cause failures from the mirror server, but they also don't do anything. I usually remove them from the server
<whuang0389>
I need to provide my own hostapd.conf file
<whuang0389>
whats the preferred way of doing it?
<kanavin>
RP: thanks, I'll try that once I get out of cycling kit and shower ;)
<RP>
kanavin: I think the test case in c13 will throw "errors" but I'm not sure these new ones are the fault of runqueue
<kanavin>
RP: I'll try. And gah, that Damian guy on bitbake-devel :-/
<kanavin>
RP: meanwhile, I have some results from lttng-tools 10x ptests
vd has quit [Quit: Client closed]
vd has joined #yocto
<RP>
kanavin: 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 further
<robbawebba>
Thanks kergoth and fray :)
<robbawebba>
whuang0389: 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.
whuang0389 has quit [Quit: Client closed]
<robbawebba>
whoops, I said FILES, but I meant SRC_URI
<kanavin>
RP: let me know when you have something you'd like me to test
angolini has quit [Quit: Connection closed for inactivity]
jmiehe has quit [Ping timeout: 260 seconds]
zyga has quit [Ping timeout: 252 seconds]
zyga-mbp has joined #yocto
<RP>
kanavin: master-next has a tweaked patch which is ready for wider testing again. I'll continue to run local tests too
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<abelloni>
RP: I just sent the previous one to the AB, should I restart ?
<abelloni>
well, 42 minutes ago
whuang0389 has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
<whuang0389>
robbawebba thanks, it worked! I guess Yocto wasn't happy when I overwrote the hostapd.conf file with the one in application recipe
camus has quit [Quit: camus]
<RP>
abelloni: please
<RP>
abelloni: it would be worth testing these two properly as my local testing shows they're better
leon-anavi has quit [Quit: Leaving]
<vd>
Is it OK to use the deploy class to copy a final image to a specific (CI/CD) directory (not DEPLOYDIR/DEPLOY_DIR_IMAGE)?
goliath has quit [Quit: SIGSEGV]
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Dracos-Carazza has joined #yocto
<JPEW>
vd: You might have touble with task reruns if you try to do that
<JPEW>
I wouldn't recommend it at least
<vd>
JPEW so I shouldn't inherit the deploy class?
RobertBerger has quit [Ping timeout: 252 seconds]
<JPEW>
vd: You cause use it, but it might cause some issues if you don't deploy to DEPLOYDIR
Guest98 has joined #yocto
<JPEW>
vd: What is it you want to accomplish?
Guest98 has quit [Client Quit]
<vd>
JPEW 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 directory
goliath has joined #yocto
<JPEW>
vd: Copy files out of deploydir?
<JPEW>
or DEPLOY_DIR_IMAGE more specifically?
<JPEW>
My 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 it
<JPEW>
(But I might be misunderstanding what you are trying to do)
<vd>
out 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.
<vd>
good question. The thing is that only bitbake knows about specific path for a multiconfig (e.g. DEPLOY_DIR_IMAGE, BB_CURRENT_MC, etc.)
<JPEW>
vd: 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.
<JPEW>
vd: But, there is another way; you can actually ask bitbake the value of those variables. Sort of like you do manually with `bitbake -e`
<JPEW>
vd: I think there is a command or library that can be used to query that programatically?
<RP>
JPEW: bitbake-getvar ?
<RP>
or tinfoil
florian has joined #yocto
<vd>
hum, 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.
creich_ has joined #yocto
creich has quit [Ping timeout: 252 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
jmiehe has joined #yocto
whuang0389 has quit [Quit: Client closed]
whuang0389 has joined #yocto
xmn has joined #yocto
whuang0389 has quit [Client Quit]
jmiehe has quit [Quit: jmiehe]
amitk_ has quit [Quit: leaving]
tlwoerner has quit [Quit: Leaving]
otavio has quit [Remote host closed the connection]