**** BEGIN LOGGING AT Thu Nov 08 02:59:59 2018 **** BEGIN LOGGING AT Thu Nov 08 04:58:25 2018 **** BEGIN LOGGING AT Thu Nov 08 05:13:28 2018 Nov 08 12:04:40 I stumbled upon a SSTATE_SKIP_CREATION flag, but I do not see any documentation for it, are these some deprecated leftovers? **** BEGIN LOGGING AT Thu Nov 08 14:03:11 2018 Nov 08 14:38:36 nrossi, hi there Nov 08 14:39:18 nrossi, that INITRAMFS_IMAGE_BUNDLE seems indeed decoupled Nov 08 14:40:28 I'll check later why the cpio was missing Nov 08 14:41:34 ant_work (IRC): ok great, also see my email wrt the /dev/console thingy... Nov 08 14:42:04 yes, see that boot does survive :) Nov 08 14:44:51 ant_work (IRC): curiously would it be useful as a generic option of the kernel-initramfs.bbclass, which is default disabled? so that derivative kernels or users that want to get rid of the warning can easily do so? Nov 08 14:47:10 well, if the recipes inheriting the class must dedclare it it does make sense Nov 08 14:49:05 long ago setting INITRAMFS_IMAGE in the kernel was the only line needed Nov 08 14:49:23 (in the kernel recipe I mean) Nov 08 14:50:27 ant_work (IRC): makes sense, i never did understand why the "INITRAMFS_IMAGE_BUNDLE" was needed Nov 08 14:50:56 ant_work (IRC): after all doing so would mean that the behaviour matches that of fitimage Nov 08 14:53:20 the issue was/is to have the two kernels in one pass without circular dependencies Nov 08 14:53:38 we solved this by 'mutilating' the 2nd kernel recipe Nov 08 14:55:10 ant_work (IRC): so it only really made sense because of the image depending on bundle tasks in older releases then? Nov 08 14:56:00 I *think* to remember you can build several kernels in parallel by now Nov 08 14:56:09 so all this is unneeded Nov 08 14:56:35 all the *BUNDLE was the first try I'd say Nov 08 14:58:41 ant_work (IRC): ok, so you think i should remove the BUNDLE variable in a v2 patch? and make kernel-initramfs behave just like kernel-fitimage? Nov 08 14:59:17 I can test the non-yocto case Nov 08 14:59:46 I must scrub the old flagged ML messages... Nov 08 15:02:02 ideally we should all use the initramfs-framework Nov 08 15:02:31 this was written for kexecboot initially ;) Nov 08 15:03:39 because of the size-contraints we abandoned the idea of a shared libc and moved to klibc-static so the schema does not fit anymore Nov 08 15:04:44 ant_work (IRC): initramfs framework though is intended for pivot roots and such no? My use case is primarily small embedded systems that simply embed the rootfs as a cpio into the kernel (or loaded via a bootloader) Nov 08 15:05:11 right Nov 08 15:28:34 nrossi, ah, found Nov 08 15:28:53 I think this patch does allow to have different kernels+modules versions Nov 08 15:28:55 http://cgit.openembedded.org/openembedded-core/commit/meta/classes/kernel.bbclass?id=6c8c899849d101fd1b86aad0b8eed05c7c785924 Nov 08 15:35:23 ant_work (IRC): Ah I do remember seeing that come through. Tomorrow I will try see if i can get some different kernels building at once with differing initramfs setup. And sort out a v2 of the /dev/console for linux-yocto Nov 08 15:36:08 in the meanwhile I'll debug my usecase Nov 08 15:38:14 note that as it is now I can build with one single i.e. bitbake core-image-base: Nov 08 15:38:21 - virtual/kernel Nov 08 15:38:41 - 2nd initramfs-kernel Nov 08 15:38:55 - installer packaging the 2nd kernel Nov 08 15:39:49 I have decoupled that ofc Nov 08 15:43:09 nrossi, finally, I don't like to add global vars in local.conf, I think our scope is the 2nd kernel recipe Nov 08 15:53:42 bbl Nov 08 18:02:40 nrossi, this is the log Nov 08 18:02:43 https://pastebin.com/k885HgZb Nov 08 18:18:26 nrossi, seems I have to remove from my defconfig CONFIG_INITRAMFS_SOURCE="initramfs.cpio.xz" to fix that Nov 08 18:23:45 ..ut then I don't get it embedded Nov 08 18:23:52 *but Nov 08 18:25:34 so it is not triggering... **** ENDING LOGGING AT Fri Nov 09 02:59:58 2018