<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_>
<ant_>
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
<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
<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
<ant_>
IMAGE_FSTYPES ?= "${INITRAMFS_FSTYPES}"
<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
<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_>
<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_>
XZ_COMPRESSION_LEVEL = "-2e"
<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_QEMUBOOT_TIMEOUT = "200"
<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..
<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.
<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.
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]