**** BEGIN LOGGING AT Sat Feb 10 03:00:01 2018 Feb 10 17:28:49 As soon as I add a defconfig to SRC_URI in my linux-yocto_%.bbappend, booting the image in qemu barfs on no rootfs available on /dev/vda Feb 10 17:29:48 I've tried setting KCONFIG_MODE to "--alldefconfig", but still no success Feb 10 17:30:12 The defconfig is generated via -c savedefconfig Feb 10 17:31:38 Shouldn't this just work ? Feb 10 19:20:53 Is is OK to override IMG_CMD_="MY_IMG=.....;dd if= of=; dd ; dd; dd;" ? Feb 10 19:21:04 to create simple binary image ? Feb 10 19:21:16 I men is it the "recommended" way ? Feb 10 19:21:34 yes, you can create your own image type if you want to. i don't really know why you'd want to, when you can just use wic and adjust the offsets, but whatever works Feb 10 19:22:00 wic has a few shortcommings: Feb 10 19:22:00 1. Always create partition table Feb 10 19:22:31 2. You cannot specify the binary size (dd if=/dev/zero of=IMG bs=1M count=16) Feb 10 19:22:55 3. The offset has only 1KiB granularity (though it is not a problem) Feb 10 19:23:17 kergoth: Previously I had my own image-classes.class Feb 10 19:23:43 kergoth: Or maybe I _just_ misuse wic..... Feb 10 19:26:02 wic seems to be tunned for the scenario when one wants to create sd/eMMC image (with partition table, some binaries, but also the partitions) - like SD card to boot BBB Feb 10 19:26:05 * kergoth shrugs, can definitely still create your own image type, that hasn't changed Feb 10 19:26:24 What I do need is a binary image for NAND memory Feb 10 19:27:21 kergoth: I just want to ask if yocto|OE team is going to support IMG_CMD stuff (if it doesn't disappear in some near future ) :-) Feb 10 19:29:41 I don't think it's likely that it'll go away in the near future, anyway. I could see eventually moving in the direction of using actual shell functions for everything rather than commands in IMAGE_CMD variables, but I dont' think there's a plan to do so in the short term. Of course, it's possible someone is doing something in that direction that I'm not aware of, but haven't seen any discussions on the list in that area. I'd suggest searching bugzilla Feb 10 19:29:41 for any pending tasks in that area Feb 10 19:30:26 personally i'd like to see proper shell functions that accept the input and output image names as arguments, to facilitate easier reuse, rather than referencing the IMAGE_NAME/etc vars in image commands directly, but that's just a personal would-be-nice thing :) Feb 10 19:30:30 * kergoth shrugs Feb 10 19:32:27 kergoth: I was even considering adding my own "plugin" to wic Feb 10 19:32:35 to have the same options as with dd Feb 10 19:33:06 but then I realized that wic is a "larger" project, from which OE|yocto only reuses some parts .... Feb 10 19:33:48 That wouldn't be a bad idea if the plugin is semi-generic. Probably overkill if it's bsp-specific Feb 10 19:36:33 kergoth: It also seems so for me Feb 10 19:37:48 the image creation seems like: Feb 10 19:37:48 IMAGE_FSTYPES_append_bbb = " spinor" Feb 10 19:38:07 IMAGE_CMD_spinor_bbb = "\ Feb 10 19:38:08 SPINOR_IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.spinor;\ Feb 10 19:38:08 SPINOR_IMAGE_LINK=${IMAGE_BASENAME}-${MACHINE}.spinor;\ Feb 10 19:38:08 dd if=/dev/zero bs=1M count=32 | tr '\000' '\377' > ${SPINOR_IMAGE};\ Feb 10 19:38:21 I can even reuse the original OE env variables Feb 10 19:38:45 It is a bit a hack, but neat (and short) one ..... Feb 10 19:53:48 yeah, that seems reasonable to me Feb 10 20:05:14 kergoth: Thanks a lot - I just want to avoid having maintenance problems in the future :) Feb 10 20:12:45 kergoth: If I may ask Feb 10 20:13:50 I suppose that list of commands for IMAGE_CMD_spinor_bbb is executed with something like: Feb 10 20:13:50 sh -c "${IMAGE_CMD_spinor_bbb}" , so I don't need to care about PWD ? **** BEGIN LOGGING AT Sat Feb 10 20:47:47 2018 Feb 10 22:01:34 Hi all, I am trying to put together an image using Poky (Rocko), and I fail to compile my services which use libdbus-c++ and c++17 standard due to: void DBus::_init_threading() Feb 10 22:01:46 have anyone stumpled upon this error in Rocko? **** ENDING LOGGING AT Sun Feb 11 03:00:00 2018