<bhstalel>
Hello, anyone knows a clear method on how to generate a totally empty ext4 image ?
<bhstalel>
The rootfs folder under workdir is totally empty, all image postprocess commands are removed, but still the generated .ext4 file contains (bin, lib, run, sbin, var, .., and etc/{timestamp, version})
bhstalel has quit [Client Quit]
bhstalel has joined #yocto
<walter>
you can use dd and mkfs.ext4 for that.
<bhstalel>
I mean getting emty image with the default core-image class
<rburton>
bhstalel: if you want an empty image, why use core-image?
berton has joined #yocto
<bhstalel>
rburton client base image is based on core-image, some packages were there, now its empty, so do I need to remove that core-image and manage do_image_ext4 myself ?
ablu has quit [Ping timeout: 265 seconds]
<rburton>
bhstalel: might be easier. meta-selftest has an empty-image recipe thoigh
ablu has joined #yocto
<bhstalel>
rburton: I see it now, besides that, I am trying to understand what causes the creation of the default rootfs structure (is it created by mkfs.ext4 ?)
<rburton>
base-files, mostly
<bhstalel>
is it invoked even if it is not in PACKAGE_INSTALL ?
<rburton>
there's also some logic involving meta/files/fs-perms.txt, but sure if that creates or just changes if exist
<rburton>
mkfs will make a lost+found but nothing else
<bhstalel>
yeah, still the test-empty-image.bb even with empty PACKAGE_INSTALL, still has the default structure in rootfs
<bhstalel>
I need to find out how base-files or fs-perms.txt are involved here (one of them or both)
bhstalel has quit [Quit: Client closed]
bhstalel has joined #yocto
bhstalel has quit [Quit: Client closed]
bhstalel has joined #yocto
<walter>
I'm now trying yocto for the first time. The bitbake KnottyUI is jumping all over the place because of warnings and errors, but the ncurses UI is more stable, it doesn't make my eyes hurt.
zeddii has quit [Read error: Connection reset by peer]
zeddii has joined #yocto
<RP>
walter: I guess we're all just use to knotty by now and don't see it like that. I'd just caution that ncurses isn't used much and may have issues
<walter>
Question, I got to this point with the ncurses UI, and it doesn't seem to do anything else and the status is Idle, do I CTRL+C out of there? Q doesn't seem to do anything, here's the last line in the log:
<walter>
INFO: Tasks Summary: Attempted 2135 tasks of which 1917 didn't need to be rerun and 1 failed.
<walter>
I CTRL+C-ed out of it, trying it again, maybe that failed "pkgconfig-native" task will be fixed.
<RP>
walter: see above, I think it has bugs :(
<walter>
Tried a 2nd time, it failed to fetch pkgconfig-native. Trying the default UI now. Thanks for the hint.
<RP>
walter: one tip is to pipe it through cat and you'll get a scrolling log instead
<RP>
i.e. it knows if the console is interactive or not
<walter>
I see. I went with looking at the cooker logs with `tail -f`, it feels better. or at least I'm used to that kind of output. :)
<rburton>
walter: if its failing to fetch pkgconfig-native then either you've a really old release, or i'd be concerned that your networking is a bit broken
<walter>
I
<walter>
I'm doing it over theadered 4G from a coffee shop.
<rburton>
walter: fyi a toolchain fetch is several gigs
<walter>
No worries there. Was expecting that.
<walter>
I'm on Fedora 42, which is a recent release, I even got a warning about while running one of the commands.
<walter>
I'm on origin/walnascar with a commit from about 2 weeks ago.
<walter>
Interesting commit: local.conf.sample: Switch to new CDN -- The project is switching the way handle our CDN provision of sstate objects, update the URL accordingly.
<rburton>
yeah i saw a slew of errors from cdn fetches failing but thought i was just breaking things as usual...
steelswords94361 has quit [Read error: Connection reset by peer]
steelswords94361 has joined #yocto
<kanavin>
rburton, I'm seeing this too
<walter>
Should I cancel the command?
<walter>
maybe switch to origin/master? or origin/master-next?
<walter>
It finished: There were 7000 WARNING messages. There were 4514 ERROR messages, returning a non-zero exit code.
<rburton>
i expect they were all sstate failures :(
<rburton>
walnascar is good
<tlwoerner>
AdrianF: your example of PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny" (and others) only works when building an image if you setup MACHINE_EXTRA_RDEPENDS (or MACHINE_ESSENTIAL_EXTRA_RDEPENDS) properly
<kanavin>
yep, 403 forbidden
<kanavin>
will report to halstead now
<rburton>
i wonder if we're being blocked for rate limits :)
<tlwoerner>
so in the documentation where you say MACHINE_EXTRA_RDEPENDS += "${PREFERRED_PROVIDER_virtual/kernel}-fitimage" is only true if PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
<kanavin>
rburton, no it's the ai scumbot blocker
<kanavin>
will write an email to yocto-infra list now
<tlwoerner>
AdrianF: any layer wanting to use an assortment of linux-yocto{-dev|-tiny|-rt} kernels will need some fancy logic around the MACHINE_EXTRA_RDEPENDS variable to get it right
<walter>
Out of 4516 "ERROR:" lines, 4512 were "Fetcher failure".
<walter>
So, that's why the UI was jumping all over the place. It just had an abnormal ammount of errors.
<kanavin>
walter, sadly sstate mirror is currently broken. I'm not sure what you're using exactly, but it needs to be disabled, and you won't see sstate reuse :(
<kanavin>
(the sstate mirror setting needs to be disabled that is)
<walter>
You mean "--no-setscene"?
<tlwoerner>
AdrianF: or will have to create linux-yocto{-dev|-tiny|-rt}-fitimage recipes for simplicity... recipes that probably should be in oe-core instead of having various bsp layers create them for themselves
<RP>
kanavin: can you report to helpdesk@ please
<kanavin>
RP: I just did
<RP>
kanavin: great thanks
<kanavin>
walter, no, you have sstate.yoctoproject.org configured as sstate mirror somewhere, you need to comment that out
<walter>
oh, ok, thanks a lot!
<kanavin>
walter, SSTATE_MIRRORS is the variable, use bitbake -e to see where it's set
rob_w has quit [Remote host closed the connection]
<RP>
mischief: sorry, I've messed up the push. Shoud be there now
<mischief>
RP: ty!
<tlwoerner>
qschulz: i might be getting close to having something for meta-rockchip's updates for fitimage. i still have to try some on-board tests
<tlwoerner>
qschulz: have you been taking a look at it?
<qschulz>
tlwoerner: no sorry, been busy burning my CPU on mesa panthor :D
<qschulz>
(OOM a few times already, been compiling for days, darn clang!)
MarcWeDLM has joined #yocto
<tlwoerner>
qschulz: it looks like the 2 patches meta-rockchip was carrying for tf-a aren't needed anymore as well
<qschulz>
tlwoerner: I believe everything should have been merged in tf-a 2.13 indeed
<qschulz>
well... can't still compile rk3399 TF-A with clang only
<qschulz>
but that is far from straightforward last I checked (the whole build system in TF-A is customer for rk3399...)
<qschulz>
custom*
<walter>
Thanks for the tips. Also, the KnottyUI is much better without all those warnings and errors. I'm thinking that maybe the sstate mirror should be disabled after encountering many errors, or the script should stop..
<mischief>
more adventures on the milk-v megrez.. i restarted the build with BB_NUMBER_THREADS=1 on a whim and i no longer see the strange bit flips/gcc segfault i saw :-/
zeddiii has joined #yocto
zeddii has quit [Ping timeout: 260 seconds]
alperak has quit [Excess Flood]
alperak has joined #yocto
LainIwakura has joined #yocto
sudip has quit [Remote host closed the connection]
bjdooks has quit [Quit: No Ping reply in 180 seconds.]
bjdooks has joined #yocto
sudip_ has joined #yocto
LainIwakura has quit [Quit: Client closed]
<walter>
I'm reading stuff while waiting for a build... and I've noticed something that maybe needs to be changed in the `40 Using Wayland and Weston` page. It mentions that "Due to lack of EGL support, Weston 1.0.3 will not...", but Weston 1.0.3 is 2012 ancient, and from what I can tell, that's no longer the case. Should this be removed or updated to say maybe something like "Prior to version ..."?
<AdrianF>
tlwoerner: But is it as simple as just setting e.g. MACHINE_EXTRA_RDEPENDS to linux-yocto? I guess this should work for e.g. PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny" as well. At least if you build an image.
<AdrianF>
tlwoerner: If you need only a kernel it should be possible to just do bitbake linux-yocto-fitimage instead of bitbake linux-yocto, also for e.g. PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
<tlwoerner>
AdrianF: please stop saying "just bitbake linux-yocto-fitimage" i am not building individual pieces, i am building images
<tlwoerner>
giving instructions on how to build each piece independently is irrelevant
LainIwakura has joined #yocto
<tlwoerner>
AdrianF: if PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" then MACHINE_EXTRA_RDEPENDS = "linux-yocto-fitimage"
<tlwoerner>
AdrianF: but if PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt" then MACHINE_EXTRA_RDEPENDS = "linux-yocto"
<tlwoerner>
??
<tlwoerner>
if true, then:
<AdrianF>
I think this should work. Or does it not?
<tlwoerner>
1) the documentation needs to be updated. because right now the documentation says: MACHINE_EXTRA_RDEPENDS += "${PREFERRED_PROVIDER_virtual/kernel}-fitimage"
<tlwoerner>
which is no longer true
<AdrianF>
tlwoerner: Ah, no. I think it should be: if PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt" then MACHINE_EXTRA_RDEPENDS = "linux-yocto-fitimage"
<tlwoerner>
2) BSP layers that use a combination of these yocto kernels will need extra logic around the MACHINE_EXTRA_RDEPENDS variable (if they're trying to do it in a generic way)
<AdrianF>
tlwoerner: Basically MACHINE_EXTRA_RDEPENDS = "linux-yocto-fitimage" means: I want to have the kernel build as a FIT image. PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt" means my kernel is the rt one. As a result the FIT image will contain the rt kernel because the linux-yocto-fitimage recipe depends on PREFERRED_PROVIDER_virtual/kernel and
<AdrianF>
packs the kernel which is there. Whatever kernel it is.
<AdrianF>
tlwoerner: 1) agree. The docs patch needs a v2.
<AdrianF>
tlwoerner: 2) not 100% sure if I see all the corner cases. But I think it should just work with PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-xyz" and MACHINE_EXTRA_RDEPENDS = "linux-yocto-fitimage" for all types of linux-yocto.
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
Tyaku has quit [Quit: Lost terminal]
Kubu_work has quit [Quit: Leaving.]
MarcWeDLM has quit [Quit: Client closed]
gvmeson is now known as vmeson
jmd has joined #yocto
rfuentess has quit [Remote host closed the connection]
grma has quit []
grma has joined #yocto
<walter>
Yay, I was able to build and run core-image-sato. I've did this on Fedora and bitbake showed a warning about it. and of course there were problems. Where can I report them and the fix I've applied? The warning was:
<walter>
`WARNING: Host distribution "fedora-42" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.`
<walter>
I actually downgraded gcc to get around the issue, but the end result is the same.
<rburton>
yeah
<rburton>
that will appear in walnascar at some point, sakoman should pick it up
sizzop has joined #yocto
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
sizzop has quit [Remote host closed the connection]
<walter>
thanks, have a nice day! -- more fun tomorrow!
walter has quit [Quit: Konversation terminated!]
florian has quit [Quit: Ex-Chat]
mckoan is now known as mckoan|away
sudip_ is now known as sudip
zeemate has quit [Ping timeout: 248 seconds]
LainIwakura has quit [Ping timeout: 272 seconds]
walter has joined #yocto
walter has quit [Changing host]
walter has joined #yocto
walter has quit [Client Quit]
walter has joined #yocto
walter has quit [Changing host]
walter has joined #yocto
florian has joined #yocto
<walter>
Is there a reason why `core-image-weston` would be lagging a lot? Do I need something else besides VT-x? The cursor is slow to move and if I type any letter in the terminal, I get like 20 characters. And I can't figure out how to check the logs.
<walter>
Nevermind, found it in the wiki: If the underlying hardware does not provide support for KVM or if it has been disabled, qemu can be used to run the VMs using software emulation, but with a performance loss.
<walter>
yeap, kvm solved the performance issues.
sizzop has joined #yocto
ptsneves has joined #yocto
sizzop has quit [Remote host closed the connection]
druppy has joined #yocto
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
<walter>
I manually deleted a directory for my recipe from `build/tmp` thinnking that it will be recreated after I run bitbake again (I even tried with `-c clean`). How do I purge everything related to a layer/recipe and start from scratch?
<tgamblin>
walter: bitbake -c cleanall <recipe>
<tgamblin>
IIRC that only works for recipes, not layers
<rburton>
don't use cleanall
<rburton>
its very very very slow
<rburton>
1) don't delete stuff from build/tmp unless you know what you're doing. if you want to save disk space, INHERIT += "rm_work" in local.conf to wipe recipe build trees when they're done with
prabhakalad has quit [Ping timeout: 272 seconds]
<rburton>
2) just bitbake recipe will rebuild (pull from sstate) as needed. if you're actually asking "how can i have a build tree for a recipe so i can poke around it", bitbake -C compile [recipe]
<walter>
cleanall didn't fix my issue. and `-v` doesn't provide any more details. The strange thing is that the log file mentioned at the end doesn't exist.
jmd has quit [Remote host closed the connection]
<rburton>
tmp is entirely transient, if you've been poking at files and thus deleting stuff that other bits of the system thinks still exists then just delete tmp/
<rburton>
a rebuild from sstate will take about a minute
prabhakalad has joined #yocto
<walter>
interesting, the build directory contains a broken simlink.
<rburton>
the problem is likely you deleted bits of the build tree but didn't delete the stamps (that tell bitbake that certain jobs have completed)
<walter>
well, tough luck. I guess I'll let it rebuilt everything. Thanks for the info.
<walter>
Oh, `bitbake core-image-weston` wasn't that slow after all. I thought I would have to wait a couple of hours again.
ptsneves has quit [Ping timeout: 252 seconds]
walter has quit [Remote host closed the connection]
chep has quit [Ping timeout: 252 seconds]
zeemate has joined #yocto
druppy has quit [Ping timeout: 272 seconds]
florian has quit [Ping timeout: 260 seconds]
zeemate has quit [Ping timeout: 248 seconds]
berton has quit [Quit: Connection closed for inactivity]