<lead4good>
I'm experiencing a very weird error with a yocto image that I'm building. It's a minimal image, only booting a initramfs from disk and using the tiny distro as base (busybox, sysvinit). The issue I'm experiencing is that a go application that's running within the image after a few hours doesn't wake from 'hrtimer_nanosleep'. I can strace attach to
<lead4good>
the respective thread, then it wakes from the syscall and continues, if not, it's stuck for about 6 hours until it returns. I'm pretty sure it's not the applications fault, but I'm out of ideas what the reason could be. Kernel Config? Running from initramfs? Busybox?
Guest98 has joined #yocto
bps has joined #yocto
<yocton>
lead4good: Hi! I would use ftrace to check what is happenning on the kernel side but maybe that just me... (and it may not be trivial to setup :( )
bps has quit [Ping timeout: 258 seconds]
skokkond has joined #yocto
skokkond has quit [Client Quit]
ks82 has joined #yocto
manuel_ has joined #yocto
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
davidinux2 has quit [Ping timeout: 240 seconds]
manuel1985 has quit [Ping timeout: 260 seconds]
lead4good has quit [Ping timeout: 246 seconds]
davidinux2 has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
<PhoenixMage>
Guest98: Not sure if you could just inherit the old one and overload the methods?
<PhoenixMage>
Something similar to kernel-fitimage but that creates a grub-efi fitimage
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
florian has joined #yocto
bps has quit [Ping timeout: 240 seconds]
Bardon has joined #yocto
bps has joined #yocto
bps has joined #yocto
xmn has quit [Quit: ZZZzzz…]
Yash20 has joined #yocto
ptsneves has joined #yocto
<Saur[m]>
RP: Just had something weird happen. Started a build. Bitbake parsed the recipes for a while. At 94% it stopped. Then after 30 seconds I got "NOTE: No reply from server in 30s". During those 30s, when I looked at the output from `ps`, I could see that there were 16 workers running, but no master controlling them. And there is nothing in bitbake-cookerdaemon.log, console-latest.log nor the systemd journal indicating what happened to the master. Is
<Saur[m]>
this something you have seen?
Guest98 has quit [Ping timeout: 246 seconds]
<Saur[m]>
Guest98: If you make sure your layer is earlier in `BBLAYERS` than the layer that has the bbclass you want to override, you can just create a bbclass with the same name (and relative path if you are using Mickledore or later). bitbake will use the first class it finds when searching through the layers in `BBLAYERS`. If you just want to make a small modification, you can use `require` to load the original bbclass.
d-s-e has joined #yocto
leon-anavi has joined #yocto
bps has quit [Ping timeout: 240 seconds]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
Guest98 has joined #yocto
Yash20 has quit [Quit: Client closed]
kpo has quit [Ping timeout: 240 seconds]
PhoenixMage has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
bps has joined #yocto
bps has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
zpfvo has joined #yocto
bps has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
kpo has joined #yocto
<RP>
Saur[m]: not a known issue I'm aware of :(
<RP>
Saur[m]: I'd have thought/hoped there would be something in the cookerdaemon log
Guest60 has joined #yocto
seccar has joined #yocto
d-s-e has joined #yocto
Yash62 has joined #yocto
Guest60 has quit [Client Quit]
Guest98 has quit [Quit: Client closed]
Perflosopher has joined #yocto
Guest98 has joined #yocto
<seccar>
Hi guys, I have to patch a local file (namely poky/meta/recipes-core/initrdscripts/files/init-install-efi.sh) to adapt to my dev board, do do so cleanly I tried to modify the recipe (initramfs-module-install-efi) with devtool but the issue is that devtool put the file into folder `oe-local-files` which is not git tracked and so devtool finish does nothing... I checked
<seccar>
Sure I can patch manually but I was wondering if I missed something in the workflow ?
<qschulz>
seccar: you typically cannot patch a file that is included via SRC_URI mechanism
<qschulz>
seccar: usually how one does this is by completely replacing the file in a bbappend
<qschulz>
you just need to provide a bbappend with FILESEXTRAPATHS:prepend :=
<qschulz>
and the file in some place tha tyour bbappend can find it
Guest98 has quit [Quit: Client closed]
<seccar>
qschulz: thanks for the reply, "you typically cannot patch a file that is included via SRC_URI mechanism" -> what is point of do_patch then ? I thought it was to patch source code (from SRC_URI)
<qschulz>
seccar: the whole thing is that it is NOT source code
<qschulz>
and you saw that because it's put into oe-local-files
<seccar>
you mean SRC_URI with "file://" protocol ?
<seccar>
(i.e.: local files)
<qschulz>
in your WORKDIR for this recipe you'd see that it's directly in WORKDIR and not in S (where source code is located)
<qschulz>
seccar: yup
<seccar>
Ok I get it, but I don't get why it is a bad idea to be able to apply path on such instead of complete repalement (from my meta with FILESEXTRAPATHS) ? For me patch is better as it may also track upstream (poky) changes ?
<qschulz>
seccar: you technically can patch it, via a patch parameter in file:// fetcher, but IIRC it was error-prone (or only one of normal bitbake or devtool would work because you use relative paths that aren't the same in bitbake and devtool for local files)
<qschulz>
seccar: some people use sed to modify the local files too
<seccar>
indded it works when the recipe is build with bitbake but lead to patch error with devtool modify ...
<qschulz>
I don't remember if there was a consensus on patching local files being bad and for what reason, and I don't have an opinion on this other than overriding the file in a bbappend is usually what's dfone
<jbo>
Hey guys, I'm building a custom image for a Toradex platform. regarding device tree overlays, their documentation talks about having a /boot/overlays/ and a boot/overlay.txt However, my custom built image doesn't seem to have those. any wild guesses on what I'm missing?
lead4good has quit [Quit: Client closed]
kscherer has joined #yocto
sakoman has joined #yocto
<LetoThe2nd>
DrewMoseley[m]: ping on that
rob_w has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<rburton>
RP: oh ffs kbd
<rburton>
sudip: sadly because the ptest doesn't log failures, the linked log.do_testimage is the best you're getting. are you using core-image-ptest-libssh2 to test?
<rburton>
an improvement would be to make the run-ptest print the output if it fails
<rburton>
but i'd be looking at what test-sshd actually does and if an image has an sshd already running, does it fail
<sudip>
rburton: bitbake core-image-ptest-libssh2
<sudip>
also, I have taken the image, booted qemu locally manually ran the tests, no failure
<RP>
rburton: I thought you'd like that patch
<rburton>
sudip: it runs a opensshd, i bet it fails in images which ship dropbear
<sudip>
ok, but abelloni also was testing with core-image-ptest-libssh2, so why is that failing for him and not for me? unless he has changed something to install dropbear
<rburton>
well the log suggests that openssh is present
<sudip>
also RDEPENDS:${PN}-ptest has openssh
<sudip>
snap
florian_kc has joined #yocto
<rburton>
making the run-ptest print the log if there's a failure would be a good thing to do
<sudip>
hmm.. ok... I can try that
<rburton>
essential anyway, hard to debug a failure if you can't see what the failure is
<rburton>
abelloni: did 'libxcrypt: fix hard-coded ".so" extension' slip through the cracks or did it fail in testing for you?
starblue1 has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
ptsneves has quit [Ping timeout: 265 seconds]
vladest has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
d-s-e has quit [Quit: Konversation terminated!]
GNUmoon has quit [Ping timeout: 240 seconds]
zpfvo has quit [Quit: Leaving.]
GNUmoon has joined #yocto
seccar has quit [Ping timeout: 240 seconds]
starblue1 has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
leon-anavi has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
prabhakarlad has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
awafaa has quit [Server closed connection]
yannd has quit [Remote host closed the connection]
awafaa has joined #yocto
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
starblue1 has joined #yocto
kpo has joined #yocto
PhoenixMage has quit [Ping timeout: 240 seconds]
PhoenixMage has joined #yocto
<khem>
git-lfs using recipes are acting up
<khem>
anyone seen it since yesterday ?
<JaMa>
I don't see any changes with lfs
<khem>
I could be repo relared too this is acting up in a recipe from meta-riscv