**** BEGIN LOGGING AT Thu May 03 03:00:05 2018 May 03 04:41:07 how can i modify recipe and upgrade "PR" for 'm4' May 03 05:57:32 New news from stackoverflow: do_rootfs: Can't install packagegroup-core-x11-utils-1.0-r40@all: no package provides xserver-nodm-init May 03 07:22:48 anyone know how to upgrade PR service of m4 recipe May 03 07:36:11 Hi, folks! May 03 07:36:37 Hi i am facing some issue about installing linuxrc script on my rootfs, the error is : miscellaneous-0.1-r0 do_package: QA Issue: miscellaneous: Files/directories were installed but not shipped in any package: /linuxrc. Here is my recipe file https://pastebin.com/0SZzYWPF. Anyone know how to work around this issue? May 03 07:37:29 I can get list of recipes with "bitbake -s", but how can I get it with license information? '-s' gives me only name of recipe, version and revision May 03 07:49:02 vladzouth: what is "MY_FILES"? you cannot add something that is not in SRC_URI May 03 07:50:43 acrap: oe-pkgdata-util package-info -e LICENSE May 03 07:51:47 acrap: or bitbake -e | grep ^LICENSE May 03 07:54:01 nayfe: "My_FILE" is the directory where the linuxrc script is. May 03 07:55:21 vladzouth: you can look at https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#building-software-from-an-external-source to replace MY_FILES, and after that, you'll need in do_install() to replace install ... ${MY_FILES} by "install -m 0755 ${S}/linuxrc ${D}/linuxrc" May 03 07:56:26 in fact you don't need MY_FILES variable as it is in layer May 03 07:56:44 just replace it by ${S} May 03 07:57:00 it will search the correct path automatically May 03 07:57:09 nayfe: OK, thanks! May 03 07:59:50 finally in FILES_${PN}, you have to remove ${D} May 03 08:02:13 vladzouth: but, if you already have a linuxrc file provided by busybox for instance, you cannot create a "patch" recipe to replace it, you have to bbappend that recipe or patch linuxrc at the very end with https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-ROOTFS_POSTPROCESS_COMMAND May 03 08:05:51 nayfe: In fact, i don't have a linuxrc provided by busybox in my images. Indeed, is there a way to tell busybox to include the linuxrc script file? May 03 08:08:16 nayfe: thanks May 03 08:13:17 vladzouth: ok so your recipe will be ok after corrections May 03 08:23:46 nayfe: i still have the same issue after adding INHERIT="externalsrc" on my local.conf, defining EXTERNALSRC on my recipe file and changing the do_install function with what you told me May 03 08:28:37 nayfe: it works, thank you! May 03 08:38:50 vladzouth: np May 03 08:38:56 acrap: np May 03 09:21:36 Hi all, I am using the default network manager provided by yocto I want create a hotspot (AP) for my wifi interface, are ther any recipes to do that or any pointer for getting it working ? May 03 09:22:23 prabhakarlad: http://layers.openembedded.org/layerindex/recipe/28409/ May 03 09:36:40 LetoThe2nd: thank you for the pointer :) May 03 11:58:40 New news from stackoverflow: Yocto - Bitbake - Example recipe to add a line in /etc/inittab file May 03 12:07:06 while running build-appliance-image it resulted in - ERROR: libx11-native-1_1.6.5-r0 do_configure: autoreconf execution failed. May 03 12:41:03 Hi, apologies for the ignorant question, I'm trying to choose a platform for an IoT Hub: I'm looking at Ubuntu Core and Yocto (and ResinOS also looks great). What would you say are the advantages/differences of Yocto over Ubuntu Core? May 03 12:42:24 its basically source-based, development host build (yocto) versus binary-based, in-target (ubuntu) May 03 12:42:47 not absolutely, there are of course intersections. but basically its that. May 03 12:44:25 Configurability and a good license compliance workflow are the advantages of Yocto for me May 03 12:44:48 ah, ok, so Yocto is more low level, allowing you to build exactly what you want and ubuntu-core is more of a higher level package, trying to tie you into their cloud services and container type? May 03 12:45:33 https://git.linaro.org/openembedded/meta-linaro.git/tree/meta-optee/recipes-security/optee/optee-os_git.bb?h=master#n46 its "{D}/usr/include/optee/export-user_ta/" not getting created on my rootfs May 03 12:45:35 ResinOS would be good if you want to use Docker containers, but again, those docker containers won't be as configurable and you won't have the same tools you get with Yocto May 03 12:45:44 when I run this recipe May 03 12:45:54 hackeron: yep, I'd say that's fair May 03 12:46:48 paulbarker: I see, thank you :) - from what I understand ResinOS is basically Yocto with a few customisation, so it should be possible to keep/remove anything that's useful for the specific requirement? May 03 12:47:11 Not sure, you'd need to talk to them about it May 03 12:48:43 hackeron, Yocto is probably a better platform for this stuff May 03 12:48:58 between the two choices, Yocto is easier to customize, and it isn't that difficult to get started May 03 12:49:25 it's supported by a number of companies, offering Yocto-based distributions that help you get off the ground quickly May 03 12:49:40 whereas Ubuntu Core significantly lacks in diversity May 03 12:49:50 Son_Goku: despite being a yocto supporter, i actually have to disagree May 03 12:50:17 really? May 03 12:50:29 the only requirement we saw so far is "iot gateway", i firmly believe that theres absolutely no way for anybody to make a proper recommendation on that buzzword alone. May 03 12:50:43 ah no, "iot hub" May 03 12:50:45 i'm sorry. May 03 12:50:46 :P May 03 12:51:25 LetoThe2nd, judging by what they're comparing, they're looking for a way to build a minimal platform that's relatively easy to maintain going forward May 03 12:51:41 Son_Goku: assumptions, assumptions, assumptions. May 03 12:52:18 hackeron, there's also Wind River Linux: https://github.com/WindRiver-Labs/wrlinux-x May 03 12:52:52 fully audited, supportable, and integrated platform May 03 12:53:18 and most of the heavy lifting is done for you May 03 12:53:41 the only really good advice one can give is to really (and i mean, really!) evaluate the specific use case and extract the requirements, then see what fits best. it might be any of the choices that have been named, or something different still May 03 12:54:14 (and no, "we want to start out with a minimal thing" does *not* count as a proper requirement) May 03 12:56:49 Tartarus: I think Stephano has it. May 03 12:57:01 Son_Goku: that's exactly what we're looking for - there are thousands of Gigabyte Brix and Raspberry Pi units at various locations, some on farms using solar panel. Currently we use Ubuntu Sever but a few times per month, the root filesystem inevitably gets corrupt and we need to send a replacement hard drive or SD card. So yes, looking for something that will address this but still won't require manual May 03 12:57:07 firmware updates when we update the app (currently we just rsync the rails source, run bundle install and do a zero downtime restart) May 03 12:58:06 Son_Goku: hmm, is Wind River one of those Yocto based projects? May 03 12:58:11 yes May 03 12:58:26 hackeron: then you actually want a proper update mechanism first, totally independent from the underlying distribution May 03 12:58:44 hackeron: look at swupdate, rauc.io, mender.io May 03 12:58:48 hackeron, RPM-OSTree is a supported update option as well May 03 12:59:21 WRLinux offers it as an option, so you can use traditional infra to build software packages and compose it into immutable, atomic updates May 03 12:59:38 its true that anything openembedded based leans itself more easy to those mechanisms, but the real problem certainly is device management and updates., May 03 13:00:14 otavio[m]: hey, you'r there? May 03 13:00:20 which again also suggests to look at resin.io, indeed. May 03 13:00:50 can anyone point me out why "install -d ${D}/usr/include/optee/export-user_ta/" do not create optee/export-user_ta/ in rootfs ? May 03 13:01:44 nayfe: yes May 03 13:01:56 LetoThe2nd: we also offer updatehub.io May 03 13:02:06 Ramose: assuming that this is inside the do_install stage, you've probably not added it to FILES May 03 13:02:21 yes its in do_install May 03 13:02:21 Did you see my message on mfgtools recipe? May 03 13:02:34 otavio[m]: there are certainly a variety of more options, absolutely agreed. May 03 13:02:35 nayfe: I did not May 03 13:02:37 nayfe: what is it? May 03 13:02:44 LetoThe2nd: that's one thing where ubuntu-core looks quite nice, they have unattended automated fill OS update May 03 13:03:13 i just made a recipe for Freescale Mfgtools Linux (master) branch, it runs well on ARM https://github.com/nefethael/meta-random/tree/master/recipes-devtools/mfgtools . Recipe's quite dirty but do you think it makes sense to make a PR on meta-freescale? May 03 13:03:50 hackeron: don't get me wrong, i'm not trying to get you away from anything. its just that my impression is that your *actual* requirements are something that is not really an ubuntu vs. OE vs. anything question May 03 13:04:06 LetoThe2nd: in terms of device management, all the units are on an OpenVPN and provisioned by Ansible, there's an in house web interface that shows all the health stats and other metrics May 03 13:04:40 LetoThe2nd: What exactly you mean by , you've probably not added it to FILES ? May 03 13:04:50 nayfe: Sure. Please prepare a PR so we review it May 03 13:05:26 Ramose: just what the sentence says. you have probably not added it to the FILES variable of the package, hence it is not packaged and installed to the rootfs, but only to the staging area. May 03 13:05:39 Ramose: look up FILES in the yocto ref-manual :) May 03 13:06:48 hackeron: Usually I prefer to have ready to use images built from Yocto so no changes are need after installation; May 03 13:06:57 LetoThe2nd: sure, I'm just trying to understand what are the different components. So with resin-os you get the device management, which I don't necessarily need, with Yocto I guess I can plug my own in. So if I need to upgade the operating system, say to a new version of the kernel, I guess it's up to me to build that with Yocto? May 03 13:07:11 otavio[m] ok i'll do it when i have time :p May 03 13:07:15 LetoThe2nd: this task https://git.linaro.org/openembedded/meta-linaro.git/tree/meta-optee/recipes-security/optee/optee-os_git.bb?h=master#n44 runs well and packed images in rootfs of same recipe May 03 13:07:25 hackeron: that allows for reproducibility in long term May 03 13:07:26 and I see this as a critical thing May 03 13:07:44 aratiu: so once built, you never really update the kernel or anything like that? May 03 13:07:57 hackeron: well, the real power of OE is to create complete images, so no software deployment through pacakges or stuff is required on top May 03 13:08:01 LetoThe2nd: install -m 644 ${B}/out/arm-plat-${OPTEEOUTPUTMACHINE}/core/*.bin ${D}${nonarch_base_libdir}/firmware/, It runs well May 03 13:08:29 nayfe: thanks I look forward to it. mfgtools is a nightmare :-) May 03 13:09:00 I guess you are talking about FILES_${PN} ? May 03 13:09:59 LetoThe2nd: in my case I want to push software updates multiple times per week, possible per day - but I guess there can be containers on top of the OS. In terms of US that generally is only updated once every 1-2 years, I guess this is the bit that would be difficult? May 03 13:10:35 in terms of the OS* May 03 13:11:40 otavio: indeed :) i just saw yesterday that a new "uuu" is coming, hope it will be better ... I prefer imx_usb_loader, but when legacy stuff comes into game, it is hard to break it ... and it's quite funny to flash a board from another one :) May 03 13:11:51 hackeron: i'd say it depends a bit on the architecture. given a writeable rootfs, there's certainly nothign keeping you from deploying smaller updates as a package stream May 03 13:12:24 which on the other hand breaks more easily May 03 13:12:24 nayfe: for sure. May 03 13:12:56 you prefer PR or mailing-list? May 03 13:13:49 LetoThe2nd: from what I understand there are 2 read-only root filesystems, so you can always revert if an update fails? May 03 13:14:06 nayfe: I think we can start on a PR; so we can go over the review process. May 03 13:14:26 LetoThe2nd: so in terms of the software packages, that will just be say a docker container, which also handles revert, etc -- I'm more curious how the kernel updates happen and how to prevent bricking the units, hmmm May 03 13:14:26 nayfe: depending on how big it is, we can send it for ML May 03 13:14:41 hackeron: thats a common method, yes. but its actually part of the update strategy, not of yocto/OE. those do just buld those rootfs May 03 13:14:41 nayfe: otherwise I can pull it and send. May 03 13:14:55 k PR will do May 03 13:15:04 LetoThe2nd: Cool, it gets created when I replace FILES_${PN}-dev = "/usr/include/optee" with FILES_${PN} = "/usr/include/optee" May 03 13:15:20 nayfe: remember, github is a mirror for meta-freescale May 03 13:15:44 hackeron: try to not think of the kernel as a singular thing to update. think of it (and anything else) as part of a monolithic OS image that is either updated in full, or not at all. May 03 13:15:53 hackeron: the A/B system is indeed the most secure way of update. May 03 13:16:15 hackeron: it allows you to revert manually or automatically May 03 13:16:35 hackeron: as LetoThe2nd said, usually we deal with the system as a single unit. So the kernel is part of it May 03 13:17:22 hackeron: the only exception is the bootloader. In updatehub case we detect the running version and update it only when it changes as it is the tricker part of it May 03 13:17:38 otavio[m]: LetoThe2nd: sure, that makes a lot of sense - but with Yocto, I'm guessing there isn't a kind of standard version that I can just go from Yocto 1.0 to Yocto 1.1 which will upgrade this one single unit, including kernel/code libs, etc? May 03 13:17:53 otavio[m]: sorry, which means? PR should be done on other git repo than github? May 03 13:19:03 hackeron: you're still thinking of yocto as a distribution, with updates. this is jsut not the reight thing. it creates a distribution image, with whatever content you like. May 03 13:19:22 hackeron: you can upgrate from 1.0 to 10.0 if need. But you are responsible to handle migrations from the apps yourself. May 03 13:19:43 hackeron: you have to get your head around the point that yocto is *NOT* running on the target. it is a tool that *CREATES* the image that runs on your target. May 03 13:20:03 hackeron: as LetoThe2nd said, you deal it as an atomic version. May 03 13:20:12 and of course you can feed new versions into that tool, then roll out a newer image. May 03 13:20:17 hackeron: not upgrade in package level May 03 13:20:18 hackeron: but a full move from A to B May 03 13:21:32 * otavio[m] sent a long message: otavio[m]_2018-05-03_13:21:30.txt May 03 13:24:36 LetoThe2nd: otavio[m]: No, no, I get that, but say I rolled my own image, it has kernel 4.16, it has docker to run my containers, etc -- I then want to update my kernel and docker version and roll a new image. How do I do that? - do I need to go in and manually download the linux kernel sources and any other libraries that I might need to modify and then build a new image? - or is there a kind of base I May 03 13:24:42 can start with that will give me the latest kernel, with sensible defaults and modules, etc? May 03 13:25:48 hackeron: the upstream state of poky respectively meta-openembedded is basically that base with sensible defaults. May 03 13:26:29 Yocto Project usually comes with fairly recent versions. So you'll need to upgrade your base version and use it as base. May 03 13:26:47 your base Yocto Project version May 03 13:27:08 HOWEVER you are free to do changes, if need. May 03 13:27:09 LetoThe2nd: ah, ok, so I just get the latest poky/meta-opembedded and hopefully my modifications on top of that will still build a working image (or not, lol) May 03 13:27:25 hackeron: thats the plan, in a nutshell. correct. May 03 13:27:50 your modifications/addons are located in a so-called layer, that gets added on top May 03 13:28:00 That is exactly why Yocto Project serves better embedded devices than Ubuntu, Debian and others. It is very easy to customize whatever is need. May 03 13:28:36 hackeron: take a look on the first book I gave the link; it explains this very well May 03 13:29:01 ok, thank you, I'l do more research and experiment, it's making a lot more sense now :) May 03 13:29:05 hackeron: grab a sandwich and some coolaid, then watch and properly digest https://www.youtube.com/watch?v=bJVYxlkHees&list=PLGYJ6-t7fDZ6VgbKPTeAXOBcnAk9Fonr_&index=6 May 03 13:29:53 hackeron: thats the basically bare bones version of the yocto dev day beginner track. and depending on what your timeframe and location are, you might want to join one of the sessions in real life. May 03 13:30:49 aratiu: sorry I missed the book link, is it this? < https://matrix.org/_matrix/media/v1/download/matrix.org/zdZOvGCXJwWAbcTEVIAdfKwG May 03 13:31:25 LetoThe2nd: that's fantastic, thank you, grabbing a coffee and some pork scratchings :P May 03 13:32:16 hackeron: shameless plug: if you're based in germany near cologne, i'm doing a training early in june https://www.buildingiot.de/veranstaltung-6616-erste-schritte-mit-dem-yocto-project.html?id=6616 May 03 13:32:49 LetoThe2nd: Based in London, UK :( - but I'll watch out fo anything yocto related in and around London :) May 03 13:33:19 hackeron: ELC-E is coming to edinburgh in late october, there probably will be dev day again May 03 13:35:18 LetoThe2nd, we are trying May 03 13:35:57 LetoThe2nd: what's ELC-E? May 03 13:36:41 ELCE: your annual chance to personally blame all OE devs! May 03 13:36:53 lol May 03 13:37:08 lol, sorry, what's OE devs? May 03 13:37:12 https://events.linuxfoundation.org/events/elc-openiot-europe-2018/ May 03 13:37:12 oh, OpenEmbedded? May 03 13:37:27 The guys that do all the work on the YP :) May 03 13:37:36 got it :) - thank you May 03 13:38:02 OpenEmbedded, that weird thing which is the foundation of Yocto Project :-D May 03 13:38:27 I need to bitch about Active COmmunity members getting labled as hobbyists May 03 13:39:11 So wrlinux-x is built on top of Yocto which is built in top of OpenEmbedded? May 03 13:39:32 i usually go like this: i blame everybody for breaking everything, making everything overly complicated, and generally being stupid and ugly. then we all get shitfaced. May 03 13:39:41 (ELCE in a nutshell) May 03 13:41:05 lol May 03 13:41:19 And LetoThe2nd brings me beer. At least if he doesn't have to fly May 03 13:41:36 hackeron: yes, thatis the book link May 03 13:41:38 hackeron, basically :) May 03 13:42:17 and we get shitfaced, we argue about the meaning of words May 03 13:42:18 ok, that actually was a bit exaggerated, we're all pretty nice guys. May 03 13:42:29 except for me May 03 13:42:33 but it sounds way more cool May 03 13:43:12 and i can say with absolute certainty that i have never been sober to the yocto BoF! May 03 13:43:35 also there will very likely be an OpenEmbedded developer meeting Sunday before May 03 13:43:41 hackeron, yes, WRLinux -> Yocto -> OE May 03 13:44:16 * armpit OE -> MSDos ? May 03 13:44:26 WRLinux is Yocto for rich people May 03 13:44:43 hello, has anyone successfully generated an SDK with rocko and meta-qt5 (Qt 5.10)? May 03 13:44:58 mckoan, the 1% May 03 13:45:04 eduardas_m: yes, of course May 03 13:45:04 something broke when moving from Qt 5.9.4 to Qt 5.10 May 03 13:45:27 mckoan: I can no longer export the environment correctly May 03 13:45:41 eduardas_m: how do you generate the SDK? May 03 13:46:00 armpit: \o/ May 03 13:46:08 mckoan: -c populate_sdk May 03 13:46:16 eduardas_m: nah May 03 13:46:32 i think we need badges here. who's working for which company. :) May 03 13:46:33 eduardas_m: meta-toolchain-qt5 May 03 13:47:15 armpit: I merged rocko, thanks! May 03 13:47:48 RP: i merged rock into my hifi, does that count too? May 03 13:47:50 RP, I saw. thank you May 03 13:47:50 mckoan: I was told once by wise Yocto people that Yocto project does not care about that since it's a meta-qt5-specific method May 03 13:48:26 * mckoan bows to wide people May 03 13:48:33 rly? oO May 03 13:48:35 s/wide/wise May 03 13:48:48 ah. May 03 13:48:58 mckoan: it also has the downside of not pulling in everything in the target sysroot May 03 13:49:20 like v4l2 libraries, etc. May 03 13:49:29 RP, pyro is segfaulting in musl ruby, but rocko is not so I suspect fix in later version of ruby May 03 13:49:42 eduardas_m: you could customize the meta-toolchain-qt5 though May 03 13:49:47 armpit: quite likely, ruby seems to be good at faulting :( May 03 13:49:50 mckoan: i hereby declare that "typo of the day." May 03 13:50:18 LetoThe2nd: people on diet may become upset May 03 13:50:34 if something is worth doing, it is worth doing well. Even segfaulting May 03 13:50:39 eduardas_m: you can inherit populate_sdk_qt5 in your custom image and use it instead May 03 13:50:43 mckoan: thats the point, right May 03 13:50:54 otavio[m]: that is exactly what I am doing May 03 13:51:10 and what is failing? May 03 13:51:18 * RP decides he probably doesn't want to think about what meta-qt5 is doing :/ May 03 13:51:25 otavio[m]: the problem is when executing qt5.sh May 03 13:52:01 nayfe: I reviewed it. Some comments. May 03 13:52:02 otavio[m]: something like qmake -query QT_INSTALL_LIBS gets me an "Empty filename passed to function" May 03 13:52:21 eduardas_m: check if it is included inside the environment.d May 03 13:52:48 otavio[m]: the qt5.sh script itself is definitely there May 03 13:52:52 eduardas_m: that is inside master / sumo? May 03 13:53:18 eduardas_m: or rocko? May 03 13:53:18 RP: why? May 03 13:53:59 mckoan: hehe Qt does some black magic to make it all work ;-) May 03 13:54:12 RP: so do I; but I can't heh May 03 13:54:15 otavio[m]: I am using the meta-qt5 branch for Qt 5.10 currently mainatined by Qt comapny, but same thing used to happen with community meta-qt5 on master (when it was on Qt5.10) May 03 13:54:30 RP: have you looked at behans intro to bitbake/yp from ELC? May 03 13:54:57 eduardas_m: well if you are using Qt company's layer so ask them to support it. May 03 13:55:12 eduardas_m: I don't use it myself (but for customers) May 03 13:55:42 LetoThe2nd: no... May 03 13:55:45 otavio[m]: same thing happens with "mainline" meta-qt5 on master last time I used it May 03 13:55:48 eduardas_m: if it fails in meta-qt5's layer, in our branches, I can take a look May 03 13:56:00 eduardas_m: today? May 03 13:56:13 RP: citation: ".. its so complex that I doubt anybody knows all about it. Well, maybe except RP." May 03 13:56:15 eduardas_m: please check, if it fails I can look at it. May 03 13:57:07 LetoThe2nd: I'm not sure any of us know all of the system ;-) May 03 13:57:25 otavio[m]: ok, will try with master...will take long to build though... what is the best way to get in touch after checking? May 03 13:57:26 RP: hehe, it just kinda stuck :) May 03 13:58:15 eduardas_m: ping me here or pvt message May 03 13:59:15 otavio[m]: thank you, will try tomorrow morning with master since my work hours are pretty much over today May 03 13:59:31 otavio[m]: thanks i'll correct PR tomorrow May 03 14:00:10 eduardas_m: that's fine. May 03 14:00:12 nayfe: sure. May 03 14:00:33 nayfe: I think it is simple to fix the build system to properly build the cli and use a single recipe for it May 03 14:01:04 nayfe: did you prepare an image for its use? May 03 14:01:10 indeed, but I didn't want to go deeper in that CMakeList.txt :D May 03 14:01:59 nayfe: it'll buy some time later, for sure. Also I can push NXP to apply it for next release May 03 14:02:04 build is quite awfull, with plain Makefile that calls cmake, do some copy, relaunch cmake etc :) May 03 14:03:16 So think if putting it into the cmake only does not make it simpler. If it does, fork the repository and prepare the changes May 03 14:03:31 we can use your fork in meanwhile or fork it inside our orga if you prefer May 03 14:08:43 not sure i'll have time for this rework this month is plenty of holidays :) May 03 14:11:28 nayfe: I hope you do :-D May 03 14:29:23 there is also the "native" part that could be added too to run it on host ... May 03 15:25:19 Hmmm, can INITRAMFS_FSTYPES even theoretically be a list? I don't see anyone doing more than one off hand May 03 15:25:49 and documentation uses singular words May 03 15:26:01 INITRAMFS_FSTYPES ?= "cpio.gz cpio.xz" works beautifully May 03 15:27:30 clear May 03 15:27:48 hi khem May 03 15:27:52 hey ant_work May 03 15:27:54 howdy May 03 15:28:00 sorry for bothering you by mail May 03 15:28:27 but one of the two klibc devs is 'krank', the other disappeared/offline...so you get the idea May 03 15:29:00 ant_work: Define works please May 03 15:29:05 bitbake certainly won't blow up May 03 15:29:19 But does anything that comes back and plays with INITRAMFS_FSTYPES work as expected? May 03 15:29:25 Tatarus: in use since 5-6 years May 03 15:29:36 ant_work: where? May 03 15:29:44 I do believe they will be produced, yes May 03 15:29:46 since kernel could decompress xz intramfs's May 03 15:30:01 But will wic work or just use the first one found? May 03 15:30:04 or blow up May 03 15:30:33 you get the two, the kernel recipe defines which one to use May 03 15:30:56 ant_work: Ah, via which variable? May 03 15:31:06 Or just a loop and guess? May 03 15:31:36 CONFIG_INITRAMFS_SOURCE="initramfs.cpio.xz" May 03 15:31:51 see meta-handheld layer May 03 15:32:33 ant_work: OK, any particular machine too? May 03 15:32:54 sure May 03 15:34:43 well, note you have to define INITRAMFS_IMAG May 03 15:34:45 E May 03 15:34:55 Yeah May 03 15:35:12 in our case we do force INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_image_complete" May 03 15:35:54 RIght May 03 15:36:03 So, I'm kicking https://github.com/jiazhang0/meta-secure-core/blob/master/meta/recipes-core/images/kernel-initramfs.bb#L39 to be more robust May 03 15:36:14 And use update-alternatives too in the non-bundled case May 03 15:36:37 And with your hints, I think the answer is that no, I can't assume INITRAMFS_FSTYPES is singular May 03 15:36:57 And i need to drop that break out, and continue not using the update-alternatives class directly May 03 15:37:05 I lost track of the last changes butnowadays it should be possible to build two kernel flavours whithout issues May 03 15:37:10 Or study busybox a bit more May 03 15:37:26 For dynamic playing with the alternatives list May 03 15:37:35 thanks May 03 15:37:46 yw May 03 19:19:19 Hey May 03 19:20:56 I added new kernel modules and this caused me to have a new kernel package. I used smart PM to update the packages and I can see the modules present under the folder for the new kernel. May 03 19:21:34 My question is how can tell the machine to boot using the new kernel. when i put uname -r it seems to be using the old one still May 03 19:49:18 that depends on what bootloader you're using May 03 19:49:30 you haven't told us anything about what you're doing, distro, machine, anything May 03 23:00:40 trying to decide for the correct place for network configuration files for systemd. It seems like my BSP layer is the wrong place. Any way to make these kind of things specific to an image? **** ENDING LOGGING AT Fri May 04 03:00:04 2018