<tomzy_0[m]>
When creating image using wks file with multiple partitions (2 rootfs A/B and couple for different kind of data) the permissions on those data partitions are messed up - do_image_wic logs the following pseudo folder does not exist. Usernames and permissions will be invalid
<tomzy_0[m]>
Lately we updated project from dunfell to kirkstone
<tomzy_0[m]>
the data partition were created with lines in wks file like part --source rootfs --fstype=ext4 --label ABC-data --align 1024 --use-uuid --fixed-size 2048 --rootfs-dir=${IMAGE_ROOTFS}${ABC-data_VAR}
<sudip>
is there any way to create an ubi image with multiple volumes?
<sudip>
currently I am using wic to build a complete image with multiple partitions, but will like to move to ubi image if possible
<fabatera[m]>
I already had to do something related (for the working NUC10). Created an append for the initramfs recipe: INITRAMFS_SCRIPTS:append = " initramfs-module-nfsrootfs"
<fabatera[m]>
But still can't find how to add such driver
<fabatera[m]>
my reply was to mcfrisk
<tomzy_0[m]>
Hello
<tomzy_0[m]>
When creating image using wks file with multiple partitions (2 rootfs A/B and couple for different kind of data) the permissions on those data partitions are messed up - do_image_wic logs the following pseudo folder does not exist. Usernames and permissions will be invalid
<tomzy_0[m]>
Lately we updated project from dunfell to kirkstone
<tomzy_0[m]>
the data partition were created with lines in wks file like `part --source rootfs --fstype=ext4 --label ABC-data --align 1024 --use-uuid --fixed-size 2048 --rootfs-dir=${IMAGE_ROOTFS}${ABC-data_VAR}`
<tomzy_0[m]>
should we just dump rootfs plugin and rootfs-dir flag for those kind of partitions?
d-s-e has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
fvincenzo has quit [Quit: Client closed]
<qschulz>
sudip: multiubi IMAGE_FSTYPE?
adsdasd has joined #yocto
kscherer has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
florian_kc has joined #yocto
adsdasd has quit [Quit: Client closed]
jkolasa has joined #yocto
xxx666 has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
olani- has quit [Ping timeout: 256 seconds]
olani- has joined #yocto
<sudip>
qschulz: but I thought multiubi is only used to create ubi images with different mkubifs_args and ubinize_args. In multiubi_mkfs() its always using "${IMAGE_ROOTFS}" in the mkfs.ubifs, so how will it take other partitions apart from the rootfs partition?
* sudip
wonders what is he missing
<qschulz>
sudip: yeah that was probably a bad suggestion, should have read a bit more about it
<sudip>
np, thanks for helping, which made me look at the code :)
sakoman has joined #yocto
zpfvo has joined #yocto
seninha has quit [Ping timeout: 265 seconds]
Haxxa has quit [Ping timeout: 248 seconds]
GNUmoon2 has quit [Ping timeout: 240 seconds]
Haxxa has joined #yocto
GNUmoon2 has joined #yocto
jkolasa has quit [Quit: Client closed]
seninha has joined #yocto
rob_w has quit [Remote host closed the connection]
leonanavi has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<Xagen>
is there a way to get the sdk to preserve file ctime/mtime from packaging to later extraction?
<hpfr->
is IMAGE_INSTALL:append:machine-name expected to not really work from local.conf? I’m trying it and it seems to get clobbered by my image recipe
<rburton>
appends will always work
<rburton>
did you remember leading whitespace?
<hpfr->
yes
<hpfr->
and if I remove :machine-name, the append works fine. I’ve confirmed machine-name is correct, here is bitbake -e with :machine-name:
<rburton>
if you want the image name, you want to prefix it with pn-
<rburton>
eg :pn-core-image-base
amitk has joined #yocto
<hpfr->
oof, I forgot about that
<hpfr->
thank you!
silbe has quit [Ping timeout: 260 seconds]
<hpfr->
one more: the docs mention you can’t use :append with IMAGE_FSTYPES. I have that defined in my machine config and now I want to append to it from local.conf, but it doesn’t seem to be possible
frieder has quit [Remote host closed the connection]
<JaMa>
hpfr-: and what's wrong with that? it seems to do what you asked it to do
<hpfr->
I want wic appended to the existing tar.bz2 and cpio.gz from the machine config
<hpfr->
but it clobbers the machine config value
<hpfr->
despite me using +=
<JaMa>
hpfr-: I understand that it's not what you've expected it to do as you've used += with an override, but that's PEBKAC, not specific to IMAGE_FSTYPES
<hpfr->
can you point me to some docs then?
<hpfr->
I’m not sure what I’m missing
<Saur[m]>
RP: Not sure what's going on, but the last 12 commits in openembedded-core have `(From OE-Core rev: ...)` in their commit messages, referring to commits that do not exist (probably themselves in some earlier version). I noticed it in poky where the commits now have two such lines, one correct and one not so correct...
<JaMa>
you might need to add :pn-your_image to limit this only to your images (to prevent adding wic to e.g. initramfs images), but then it should just work
<RP>
Saur[m]: I picked patches from a poky branch instead of an oecore one and didn't notice/fix it, sorry
<Saur[m]>
RP: Ok. Just wanted to check that it wasn't some tooling gone wrong.
amitk has quit [Ping timeout: 256 seconds]
vladest has joined #yocto
<hpfr->
JaMa: thanks, this seems to work fine. it seems like the warning about += in the docs predates the sphinx migration, so maybe it can be removed
<hpfr->
so I wouldn’t be surprised if it just doesn’t apply anymore
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
amitk__ has quit [Ping timeout: 256 seconds]
eddy_ has joined #yocto
<eddy_>
hello here I am again with a yocto question: if i add this to a yocto kernel module recipe yocto somehow will not set the MODULE macro any more. am i dooing somehting wrong? => EXTRA_OEMAKE += "KBUILD_CFLAGS_MODULE+="-I${STAGING_DIR_HOST}${includedir}/kernel/""
<eddy_>
my intention is to have a shared folder between the kernel modules where the headers are installed and this line is to tell kbuild where to look for the other modules headers
<paowz>
rburton: Thanks for the suggestion. Unhappily, it didn't help a lot.. the error remains.. :-/
hpfr- has quit [Remote host closed the connection]
hpfr has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
hpfr is now known as Guest4538
seninha has joined #yocto
alessioigor has quit [Remote host closed the connection]
florian_kc has joined #yocto
<eddy_>
ok found my mistake.i am not suppost to set KBUILD_CFLAGS_MODULE but KCFLAGS wich will then be appended to KBUILD_CFLAGS from kbuild
goliath has joined #yocto
Guest8668 has joined #yocto
Guest8668 has quit [Client Quit]
Guest86668 has joined #yocto
eddy_ has quit [Quit: eddy_]
<Guest86668>
Hello to all,
<Guest86668>
In the project Im working, we have some shared libraries installed in non standard paths.
<Guest86668>
I would like to append to the CFLAGS and LDFLAGS this new path so the compiler will find the header files and the linker the shared libs.
<Guest86668>
Do you have some suggestions on how to do this?
Guest86668 has quit [Quit: Client closed]
gsalazar has quit [Ping timeout: 260 seconds]
Guest86668 has joined #yocto
Guest86668 has quit [Client Quit]
Guest86668 has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Leonardo19 has joined #yocto
<Leonardo19>
I have a problem when try to enable pgsql flag in PHP build, anyone can help me?
starblue has quit [Ping timeout: 265 seconds]
Leonardo19 has quit [Client Quit]
Guest86668 has quit [Quit: Client closed]
starblue has joined #yocto
prabhakarlad has quit [Quit: Client closed]
PobodysNerfect_ has quit [Quit: Gone to sleep. ZZZzzz…]
<yolo>
why must TMPDIR be absolute path? I ran out of disk and moved yocto to another partition and I have to rebuild because TMPDIR no longer is valid, even though I made sure using symlinks to make sure the location is still the "same" before "mv" to new partition
alex88 has quit [Ping timeout: 265 seconds]
akiCA has joined #yocto
<RP>
yolo: people can break that all too easily so it has checks to make sure people don't do it. You could disable the checks and see what happens but no guarantees. In general it is easier just to delete and let things recover from sstate
Guest4538 has quit [Remote host closed the connection]
hpfr has joined #yocto
hpfr is now known as Guest6007
alex88 has joined #yocto
<yolo>
RP: I did the saved_tmpdir trick and it still kind of rebuilding, maybe a little faster than from scratcccch
<RP>
yolo: building from sstate and just copying that would have been easier/faster ;-)
<yolo>
not aware of that, will keep this in mind, now it's 81%, will just wait it out, it's a pitty each new build takes hours even on SSD with 8 cores and 32GB memory.
<yolo>
building openbmc that is
kscherer has quit [Quit: Konversation terminated!]
<yolo>
is systemd+musl "production ready" in yocto? systemd is really glibc only but I assume yocto has done some heavy patching to make it musl-ready too?
<rburton>
i wouldn't want to go as far as production ready. if you want that, speak to systemd maintainers and convince them to consider supporting musl properly
<yolo>
it seems Lennart rejected that idea outright a while ago and his attitude was non-negotiatble
<rburton>
there _might_ be a softening of that stance recently
<rburton>
definitely worth asking again, especially if you can come from a "and I want to deploy across a fleet of servers" perspective and not just "because its cool"
goliath has quit [Quit: SIGSEGV]
<yolo>
will try, definitely. yes openbmc is related to servers and downsize the image matters to me, and yes we deploy a fleet of servers
<rburton>
things like alpine looking to fund an alternative partly because systemd doesn't support musl might be helping too
<yolo>
isn't alpine busybox+musl only, i guess containers need more than busybox's init
<yolo>
there are a few inits, just that systemd is now dominant
<rburton>
yeah you want a proper init ideally, even in containers
<yolo>
make it embedded friendly is beneficial for all
Minvera has quit [Ping timeout: 240 seconds]
<yolo>
in fact, systemd+musl is also a selling point for containers, where size matters due to the large scale of containers used in depolyments
<rburton>
yeah
<yolo>
i will ask chatggpt to write up something and convince Lennart tonight :)
<rburton>
going back to what you said earlier: always keep sstate-cache, never delete it, always share it between builds. huge savings, basically only build from scratch once.
<rburton>
but now, bed. :)
<yolo>
thanks! good nite
olani- has quit [Ping timeout: 256 seconds]
prabhakarlad has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
alex88 has quit [Ping timeout: 268 seconds]
alex88 has joined #yocto
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 240 seconds]
<khem>
yolo: systemd on musl is not as bad as it used to me. We still carry few patches which are still questionable but Lennart has provided detailed feedback on them and how we can proceed to get some of them resolved upstream. Its just time. someone has to work through them