dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
BCMM has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #yocto
halstead has quit [Ping timeout: 272 seconds]
rcw has quit [Quit: Leaving]
hpsy has joined #yocto
hpsy1 has quit [Ping timeout: 268 seconds]
sakoman has quit [Quit: Leaving.]
Vonter has joined #yocto
camus has joined #yocto
paulg has quit [Ping timeout: 252 seconds]
halstead has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
<ant_> RP: when you're finished bisecting, there is another unexplicable issue here, much simpler I hope
<ant_> for collie, just for this machine, the cpio is not created.
<ant_> the initramfs image, instead, is jffs2 and tar.gz
<ant_> since eons we include the same .inc for all machines, setting
<ant_> INITRAMFS_FSTYPES ?= "cpio.gz cpio.xz"
<ant_> something is really broken if it fails just for armv4
<ant_> both bitbake -e and the jsonn data have the right value inside
<ant_> "IMAGE_FSTYPES": "tar.gz jffs2 jffs2.sum",
<ant_> "IMAGE_FSTYPES_DEBUGFS": "tar.gz",
<ant_> "IMAGE_FSTYPES_collie": "tar.gz jffs2 jffs2.sum",
<ant_> "INITRAMFS_FSTYPES": "cpio.gz cpio.xz",
<ant_> boh !
<RP> ant_: this is with master?
<ant_> yes
<ant_> -next actually
<RP> ant_: to reproduce that I'd need meta-handheld, a collie build and it would fail at which point?
<ant_> kernel cannot find cpio
<ant_> is not built, just the jffs2 and tar.gx in deploydir
<ant_> seems I fix it adding INITRAMFS_FSTYPES_collie ?= "cpio.gz cpio.xz"
<ant_> wait a min
<RP> ant_: ERROR: Layer meta-handheld is not compatible with the core layer which only supports these series: hardknott honister (layer is compatible with sumo thud)
<ant_> ah, paul has pull requests since some time...
<ant_> ok, seems the issue is the weak assignment
<ant_> inherit image
<ant_> +IMAGE_FSTYPES_collie ?= "cpio.gz cpio.xz"
<RP> ant_: the maintainers file doesn't even have a correct email address for paul :/
<ant_> even adding this to the image it fails
<ant_> I must use _collie =
<ant_> now see setting it back in zaurus.inc
<RP> ant_: have you a branch somewhere which makes this work with master? also, perhaps you should just have push access to this layer? :)
<ant_> for the rest no changes, just add layer name (and do not exceed max length ;)
<ant_> no, the setting in the .inc are intercepted :
<ant_> some class does reset the IMAGE_FSTYPES
<ant_> that's wrong
<RP> ant_: ok, I think I now understand. These are the images in meta-initramfs ?
<RP> ant_: it is entirely expected that if something does: IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" then IMAGE_FSTYPES_collie": "tar.gz jffs2 jffs2.sum" from configuration would override the INITRAMFS_FSTYPES setting :(
<RP> ant_: python () { d.setVar("IMAGE_FSTYPES", d.getVar("INITRAMFS_FSTYPES")) } in those image recipes would likely fix that
* RP notes that setting an incompatible layer causes bitbake to hang
<ant_> but why was it ok before?
<ant_> I did build linux-kexecboot for collie back 2017-2018
<ant_> note bitbake -e says "INITRAMFS_FSTYPES": "cpio.gz cpio.xz"
<RP> ant_: that doesn't matter, what matters is "MACHINE=collie bitbake initramfs-kexecboot-image -e | grep IMAGE_FSTYPES"
<RP> it is the value that IMAGE_FSTYPES gets set to which is the issue
<ant_> hen must be weakened in the image
<RP> ant_: the problem is the machine override is winning and that won't help. You need the anonymous python I mentioned to "win" compared to the machine override
<ant_> INITRAMFS_FSTYPES RP: I start to remember...collie had not enough blocks for ubi so I special-cased it
<ant_> ah ha
<ant_> my bad :)
<ant_> after that I did not compile the image anymore posibly
<ant_> (for collie)
<ant_> ok, I better remove that in zaurus.inc
<RP> ant_: well, I think that assignment in the image recipe is dangerous and would be better as anon python too
<ant_> sigh
<ant_> RP: afais core-image-minimal-initramfs does the same
<ant_> RP: fix thisone pls, so we then fix meta-initramfs
<ant_> RP: btw ubi on collie rules :)
<ant_> I'm testing it, thanks
<ant_> RP: I must manage better the build of ubifs exceeding the aval eraseblocks
<ant_> iirc now build continues if one fstype fails, unsure
<ant_> now = 5 yrs later
<ant_> :)
<ant_> RP: doesn't seem to solve :/
<RP> ant_: you applied that to the two other initramfs recipes?
<ant_> yes
<RP> ant_: gives IMAGE_FSTYPES="cpio.gz cpio.xz" as the value now
<RP> ant_: what problem are you seeing?
<ant_> I don't have any cpio in deploydir, the image is built as IMAGE_FSTYPES jffs2/tar.gz
<ant_> │ initramfs-kexecboot-klibc-ima~e-20210612104354.rootfs.jffs2│ 14336K│giu 12 12:44││ │ │ │
<ant_> │ initramfs-kexecboot-klibc-ima~210612104354.rootfs.jffs2.sum│ 262144│giu 12 12:44││ │ │ │
<ant_> │ initramfs-kexecboot-klibc-ima~0210612104354.rootfs.manifest│ 121│giu 12 12:44││ │ │ │
<ant_> │ initramfs-kexecboot-klibc-ima~-20210612104354.rootfs.tar.gz│ 117835│giu 12 12:44││ │ │ │
<ant_> │ initramfs-kexecboot-klibc-ima~-20210612104354.testdata.json
<ant_> the origina sin is my commit in meta-handheld :)
<ant_> but this discovers some other issues I thin
<RP> ant_: try putting the anon python before the inherit image part
<ant_> yea, I was doing that :)
<ant_> that's th eproblem
<ant_> now it is ok
<ant_> btw while here I will inherit core-image
<ant_> (didn't exist back then prolly)
<ant_> RP: it's always a surprise to exactly catch when a var is set/evaluated with overrides :)
<ant_> RP: ha ha, with latest tc we have inflated
<ant_> | DEBUG: Executing shell function do_sizecheck
<ant_> | WARNING: This kernel zImage (size=1024(K) > 1024(K)) is too big for your device.
<ant_> did still fit some years ago
<ant_> RP: this is the meta-initramfs part then https://pastebin.com/zzzQyjwQ
<RP> ant_: if image works, just use image
<RP> ant_: but yes, that looks good.
<RP> ant_: btw, the kexec image fails with package_rpm
<RP> ant_: updated the patch in master-next
<ant_> thanks
<ant_> KERNEL_IMAGE_MAXSIZE_collie = "1024"
<ant_> *zImage │1047288│
<ant_> I think these few bytes are the added empty dirs (h
<ant_> boh -rwxr-xr-x 1 andrea andrea 1023K giu 12 12:59 zImage
<ant_> why does test now fail?
<ant_> RP: it seems in the years xz has improved and needs much less ram for kernel-decompression
<ant_> I did set this at the time
<ant_> because poodle (32MB ram) could not decompress the kernel otherwise
<ant_> wellm with XZ_COMPRESSION_LEVEL_collie = "-7e" is even bigger *zImage │1047376
<ant_> neverthless is always < 1048576, test is bogus
<ant_> hell
<ant_> RP: it is rounded up to kb so it fails
<ant_> INTEGER1 -ge INTEGER2
<ant_> INTEGER1 is greater than or equal to INTEGER2
<ant_> if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
<ant_> once it was on bytes iirc, now the equal part is disturbing
<ant_> (I know this is probably the smallest, unique, OE kernel with 1MiB limit :)
Shaun_ is now known as Shaun
<ant_> RP: final note, do_sizecheck() was born for collie :)
<ant_> bbl
paulg has joined #yocto
<vmeson> RP: I finally have another BUG: in the bisect, on: 7c4c016a3d linux-yocto/5.10: update to v5.10.37 -- I'll continue with bisect.
BCMM has joined #yocto
<RP> vmeson: cool. I will admit I've focused on other things today, I have a backlog of other issues
dlan has quit [Ping timeout: 252 seconds]
droman has quit [Ping timeout: 252 seconds]
LocutusOfBorg has quit [Ping timeout: 252 seconds]
LocutusOfBorg has joined #yocto
stkw0 has joined #yocto
dlan has joined #yocto
goliath has joined #yocto
ant_ has quit [Ping timeout: 265 seconds]
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
BCMM has quit [Ping timeout: 264 seconds]
<vmeson> RP only 1 failure out of 15 runs! I'm going to do another 15 at this commit id.
ant_ has joined #yocto
<RP> vmeson: well, once you have a fail, you know it is bad
<ant_> RP: should I increment the KERNEL_MAXSIZE of poor collie or adjust the greater/equal check =
* paulg is looking at dentry code that contains gems like "name->name.name = name->inline_name;"
<ant_> RP: it is really (lower) border-case
<paulg> FWIW, I got another "long" run w/o ever getting a failure - so it seems you can get VM boots that are immune ; testing with "-c testimage" seems to be required.
<RP> ant_: the test probably needs tweaking if it isn't working correctly but I'm not 100% sure what the issue is
<ant_> rounding
<RP> ant_: so can we rework it to avoid the rounding?
<paulg> vmeson, testimage takes some timeouts, vs manually watching for a hang ; I've added these to local.conf but not (yet) started another run with them...
<RP> paulg: fun. I just couldn't face any more of it this weekend
<paulg> TEST_OVERALL_TIMEOUT = "360"
<ant_> accepting the equal case?
<ant_> This kernel zImage (size=1024(K) > 1024(K)) is too big
<RP> paulg: I did also notice there is an ltp option to inject the test name into the kernel log, been meaning to try that
<paulg> vmeson, the 360 is 'cause on ala3 the test always has completed in under 5m
<RP> ant_: I'd accept that
<paulg> RP, afaik it is enabled, I've been seeing that since the get-go
<RP> paulg: hmm, I'm not
<paulg> well, i've been seeing it on my manual runs, on the console...
<paulg> you are right ; they aren't in my testimage qemu logs tho..
<paulg> [54843.160382] LTP: starting memcg_usage_in_bytes (memcg_usage_in_bytes_test.sh)
<paulg> [54845.518415] LTP: starting memcg_control (memcg_control_test.sh)
<paulg> [54851.574800] LTP: starting cpuset_regression_test (cpuset_regression_test.sh)
<paulg> [54851.621707] LTP: starting cgroup_xattr
<paulg> [54851.626250] new mount options do not match the existing superblock, will be ignored
<paulg> etc etc
<ant_> -if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
<ant_> +if [ $size -gt ${KERNEL_IMAGE_MAXSIZE} ]; then
<RP> paulg: right, different ltp commands I guess
<RP> ant_: the autobuilder blew up with my initramfs patch :(
<ant_> how so?
<RP> ant_: Adding IMAGE_FSTYPES += ' hddimg' to local.conf, then "MACHINE=genericx86 bitbake -p" blows up in parsing
<ant_> I admit never building that one
<RP> ant_: qemux86 does it too
<RP> ant_: its another ordering issue
<ant_> RP: then do :/oe/oe-core/meta$ grep -R INITRAMFS_FSTYPE
<ant_> there are more IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
<vmeson> another 10 runs at this commit and no errror. I expect/wonder if it's more common under heavy load...
* vmeson starts a seperate world build in a loop to find out.
<RP> vmeson: I would have been running multiple builds on my machine
<ant_> overrides and includes are indeed a fragile thing
<RP> ant_: it is a mess, there isn't actually any way to do this as even := won't clear the overrides
<RP> kergoth: what is you view on XXX_machine = "X"\n XXX := "Y" with machine in OVERRIDES?
<RP> We don't appear to have a test case for that
<ant_> in C it's easier...#ifndef
<ant_> RP: after surviving to the sizecheckI still have the obstacle in kernel.bbclass, do_deploy does check packaging even if packaging is disabled
<vmeson> paulg: hope you don't mind the background builds on ala3... load is b/w 50-90% busy. poor monster machine.
<ant_> once youguys solve the kernel issue I'll come back with these minor things
<paulg> vmeson, for the moment I've been just USTL and not testing today
<paulg> coding up some debug stuff to better get the kernel to tell us what corrupted (hopefully)
<vmeson> In other news, after years of our build cluster running, I've decided that since we often build w/o sstate and then rm -rf, we should try to avoid sstate generation completely.
<vmeson> paulg: k, let me know if you want the machine to be less busy.
* vmeson goes away for an hour or so
<RP> kergoth: I think our current behaviour is wrong, or would be better as the other anyway...
* RP wonders how much that would break
<paulg> vmeson, ha ha ha.
<paulg> [06/01 11:44] <paulg> sstate could vanish overnight and I'd probably not notice, or perhaps even be happier for it.
<paulg> [06/01 11:49] <paulg> at least they aren't like autoconf - a solution to a 1985 problem. B-)
<paulg> [06/01 11:45] <paulg> kinda like distcc and ccache type stuff. Seem like dated solutions to a 2005-ish problem.
<paulg> Just don't let RP hear you throwing shade on sstate.... ;-)
<RP> paulg: Lets just say I disagree about sstate. I'm not so keen on distcc/ccache though
<paulg> :-) Couldn't resist poking some fun, seeing as I'm sitting here suffering anyway.
camus has quit [Quit: camus]
<vmeson> RP, is there a flag to avoid generating sstate aleady? I looked but didn't see one. I expect it'd cut build times in our cluster by a few %. I can create a bugzilla enhancement if needed.
ant_ has quit [Ping timeout: 264 seconds]
<paulg> I think this one is new... https://paste.debian.net/1200977/ at least to me.
<paulg> core rcu code is running and the code page vanishes?!? wtf.
<paulg> qemu "hardware" sure seems baked.
<paulg> vmeson, I think you killed our test box.
BCMM has joined #yocto
<vmeson> paulg: yikes. shells are hung, can't ssh but the box is pingable. I've txted Konrad asking if he has time to reset it.
<paulg> doesn't answer pings ; maybe he reset it
<vmeson> yep, it's back , continuing with one world buid this time...
<paulg> except the reboot broke networking
<vmeson> it had completed 32 tests total before the reset - still only 1 BUG: -- that's not good news for being able to identify where this bug was introduced.
* vmeson ploughs ahead with the bisect
<vmeson> I guess I should call this one 'bad' but given the probablility of an accurate signal , this is likely pointless.
* vmeson calls it bad and ploughs on.
<vmeson> paulg: networking, you mean tun/tap?
Guest22 has joined #yocto
<vmeson> paulg: fixed
<paulg> thanks
Guest22 has quit [Ping timeout: 250 seconds]
camus has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
ant_ has joined #yocto
<kanavin> one of the wayland libraries is incorrectly relocated at do_image time
<kanavin> which begs the question: how useful is prelink? How about disabling it?
<vmeson> summary of what I've seen on this ltp -> kernel BUG: : https://paste.debian.net/1200991/
* vmeson takes a few hours off
<kanavin> I see prelink was disabled/enabled a couple times in the past, so maybe it's time to do that again...
Vonter has quit [Ping timeout: 252 seconds]
camus has quit [Remote host closed the connection]
<RP> kanavin: for better or worse it is useful in that it reduces memory usage...
<RP> vmeson: I really dislike the idea of allowing sstate generation to be turned off
<RP> vmeson: I'd bet you can hack it to remove the file generation just be zeroing out some functions
<RP> vmeson: in fact the more I think about it, the more I think you know not what you ask for. I can/will explain but not now
<kanavin> I tend to agree with RP, this 'we don't need sstate' heresy has to stop
<moto-timo> Pretty sure #freenocommonsense doesn’t want to exist anymore. I already dropped from any relevant community channels but now I’m kicked (and burned the bridge)
<ant_> heh, just one day of bisecting makes you ramble
<moto-timo> We need sstate.
<RP> I can understand why vmeson wants to disable generation of it if it isn't used but its just going to complicate the test matrix and generate new bugs where odd things happen if we don't generate it
<moto-timo> CFP for ELC closes tomorrow. What would you like me to talk about?
vmeson has quit [Ping timeout: 244 seconds]
vmeson has joined #yocto
Vonter has joined #yocto
sakoman has joined #yocto
BCMM has quit [Quit: Konversation terminated!]
hpsy1 has joined #yocto
hpsy has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]