**** BEGIN LOGGING AT Fri Jan 20 03:00:03 2017 Jan 20 06:52:03 I am building minimal image for Odroid-C1 with custom meta layer. Board boot without error with standalone linux build. But when i use uImage build using yocto, kernel gets crash and there is not log after starting kernel. Jan 20 06:52:52 I check, standalone linux build and yocto kernel build both have same dtb and .config file. I check diff there is no difference. Jan 20 06:53:31 yocto uImage and standalone uImage have different file size. What can be difference between two image, except toolchain ? Jan 20 08:13:44 qemu-native no longer builds for me. SRC_URI joins to distinct entries together -> SRC_URI="http://wiki.qemu-project.org/download/qemu-2.7.0.tar.bz2file://powerpc_rom.bin Jan 20 08:14:34 There's a missing space at the end of _prepend: SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2" Jan 20 08:14:47 But the existing SRC_URI starts with a space, so why is it breaking? Jan 20 08:15:49 Full bitbake -e history here: http://pastebin.com/72dHPUig Jan 20 08:27:52 hello, where can I check at what memory location of sd card image u-boot was put when generating image via bitbake? Jan 20 08:28:55 I need this to define "Device offset" parameter to make fw_printenv of u-boot-fw_utils work Jan 20 08:29:35 eduardas_m: what are you using to generate the sd image? Jan 20 08:29:58 eduardas_m: as in layer/machine/imagefstype/etc? Jan 20 08:30:10 nrossi, I just do a "bitbake fsl-image-qt5" and get an .sdcard file Jan 20 08:33:38 eduardas_m: which fsl target? mx? Jan 20 08:33:42 nrossi, these are the layers used: http://pastebin.com/XcaU8Enu Jan 20 08:34:03 machine is Variscite DART6UL with imx6UL chip Jan 20 08:34:32 eduardas_m: Ok, all the magic is in this file: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/classes/image_types_fsl.bbclass Jan 20 08:34:32 sources/meta-fsl-arm/classes/image_types_fsl.bbclass Jan 20 08:34:34 not sure where to look for imagefstype Jan 20 08:34:40 eduardas_m: Or the u-boot magic address are http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/classes/image_types_fsl.bbclass#n169 Jan 20 08:34:48 s/Or/all/ Jan 20 08:36:25 eduardas_m: If its using SPL, u-boot should start 69K from start of file. Without SPL it should be 1K. If i am reading it right Jan 20 08:38:40 nrossi, thank you...however 69K is 0x11400 in hexadecimal... if I write that as Device offset in fw_env.config, it still does not work Jan 20 08:39:26 eduardas_m: are you using u-boot SPL? or just u-boot? Jan 20 08:39:44 nrossi, using SPL Jan 20 08:40:28 nrossi, perhaps I don't understand something and Device offset means something else Jan 20 08:41:05 eduardas_m: wait, doesn't fw_printenv work on the environment, not the bootloader image? Jan 20 08:42:58 nrossi, yes it does... I have googled around a bit... but still not sure where there is documentation of "Device offset" Jan 20 08:43:51 eduardas_m: Device offset refers to the offset for the device storing the environment. Im not sure what the default device is for you board is. Its likely to be in mtd though (aka spi flash) Jan 20 08:44:44 nrossi, my device is SD card (/dev/mmcblk0) Jan 20 08:45:38 My config line is: /dev/mmcblk0 0x11400 0x1FFC Jan 20 08:46:20 I am pretty sure of the environment size (second parameter) because that is easy to get via u-boot printenv Jan 20 08:52:00 eduardas_m: Sorry had to dive around to find the u-boot source for you machine. Looks like this is the magic define you are after :) https://github.com/varigit/uboot-imx/blob/imx_v2015.10_dart_6ul_var1/include/configs/mx6ul_var_dart.h#L274 Jan 20 08:53:03 nrossi, it might be CONFIG_ENV_OFFSET ... will try now Jan 20 08:57:12 nrossi, there is #define CONFIG_ENV_OFFSET (8 * SZ_64K) for MMC so I set Device offset to 0x80000, still does not work Jan 20 08:59:20 eduardas_m: When you start the machine, and U-Boot prints out its info before booting. What does it say about the environment? Jan 20 09:01:47 nrossi, actually, it does not seem to say anythin useful: http://pastebin.com/vq19NJPe Jan 20 09:02:28 eduardas_m: if you run "saveenv" in the u-boot prompt does it save anything? Jan 20 09:03:03 Saving Environment to MMC... Jan 20 09:03:15 Writing to MMC(0)=SD... done Jan 20 09:03:23 that is all Jan 20 09:03:55 eduardas_m: ok, so its at least saving to MMC. Have you tried fw_printenv after doing a manual saveenv? Jan 20 09:04:00 If I run printenv, the environment size info is Environment size: 1990/8188 bytes Jan 20 09:04:25 nrossi, will try now Jan 20 09:06:44 nrossi, does not help... neither for values 0x80000 or 0x11400 of device offset Jan 20 09:11:48 eduardas_m: Hmmm, im out of ideas. Maybe you should query the layer mailing list if not one else here has any ideas ? Jan 20 09:30:02 nrossi, so thanks to agust in u-boot IRC I got it working Jan 20 09:30:38 it seems Env. size has to be whatever the maximu size printenv gives + 4 bytes (CRC32) Jan 20 09:30:56 so 0x1FFC + 0x4 = 0x2000 Jan 20 09:31:34 also, Device offset has to be the same as CONFIG_ENV_OFFSET in mx6ul_var_dart.h Jan 20 09:31:47 and not the actual offset of u-boot in image Jan 20 09:33:33 honestly, these are gotchas that are not apparent to me from u-boot documentation or any kind of other documentation Jan 20 09:39:55 Hi everyone! I've just downloaded the basic Yocto and added the meta-openembedded layer, and beneath it, meta-oe, meta-python and lots of other layers. I want to create my own image and I added the layers to bblayer.conf, do I need to build all the recipes included in the layers? There's any way to bitbake all of them in one step? thanks Jan 20 09:44:49 RP: about the qemu-native SRC_URI issue (http://pastebin.com/72dHPUig) - I managed to track it down to adding something in my local.conf: SRC_URI_remove_pn-linux-yocto = "git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=kernel-meta" Jan 20 09:45:33 botman: it's basically like apt-get install, if you build the top level (ie. core-image-minimal) it will build all dependencies first Jan 20 09:45:41 How can it be that something entirely unrelated ends up removing spaces from SRC_UR? Jan 20 09:46:53 pohly: I don't think its unrelated. You're relying on the space before git:// and I suspect the removal code removes the space Jan 20 09:47:23 iirc removal code does a split, remove, join Jan 20 09:47:44 RP: but the recipe is qemu-native. Why does it even use SRC_URI_remove_pn-linux-yocto? Jan 20 09:48:20 pohly: that isn't right, is it Jan 20 09:49:06 pohly: I think I understand looking at the code. Fancy trying to change something? Jan 20 09:49:10 joshuagl: you added alsa-state recipe years ago, any recollection? I think the postinst has never worked, and I'm not sure I understand what it's for... Jan 20 09:49:26 rburton: I agree that SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2" in qemu_2.7.4.bb is broken. But I'm worried that something else isn't quite as it should be, hence the question. Jan 20 09:49:34 RP: sure, shoot. Jan 20 09:50:34 pohly: bitbake/lib/bb/data_smart.py, there is a line, filtered = filter(lambda v: v not in removes, around like 784 Jan 20 09:50:58 pohly: I think that piece of code needs to be conditional on removes not being empty Jan 20 09:52:03 pohly: if you look at the code you'll see that match=True doesn't happen in this case (since the overrides aren't active) but it does mess the value around anyway Jan 20 09:52:55 pohly: the re joining of that string would swallow the leading space Jan 20 09:53:56 jku: hmm, a copy/paste recipe from oe-classic to persist alsa mixer settings. Not sure if it's still used/useful. Used to be that bsps would rely on it to ensure the volume wasn't 0 on new devices. Jan 20 09:53:58 RP: yes, that's it. Jan 20 09:54:19 hi Jan 20 09:54:42 joshuagl: ah so some other layer would contain a "asound.state" that actually had something in it Jan 20 09:54:43 I'm getting: lshw-02.16-r1 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/mnt/storage/zeenix/GDP/genivi-dev-platform-qemu-x86_64/gdp-src-build/tmp/work/core2-64-poky-linux/lshw/02.16-r1/packages Jan 20 09:54:44 -split/lshw/usr/sbin/lshw' [ldflags] Jan 20 09:54:47 any clues? Jan 20 09:54:49 jku: right! Jan 20 09:54:55 RP: I'm a bit surprised that _remove seems to run before _append, though. Jan 20 09:55:07 zeenix: the build of lshw isn't respecting $LDFLAGS Jan 20 09:55:11 I thought _remove was always done last? Jan 20 09:55:46 pohly: _append is applied further up in that function Jan 20 09:56:03 Wait, it's a _prepend in qemu. Jan 20 09:56:22 damnit i broke the selftest again Jan 20 09:56:30 jku: could you glance at https://autobuilder.yocto.io/builders/nightly-world-lsb/builds/130/steps/BuildImages/logs/stdio, the epiphany failure, any idea what would break like that? Jan 20 09:56:41 "Fatal Python error: getentropy() failed" Jan 20 09:56:42 awesome Jan 20 09:56:48 The nss failure is also odd :( Jan 20 09:57:04 I'll take a look Jan 20 09:57:05 rburton: we need more randomness! Jan 20 09:57:23 RP: don't appreciate more randomness right now Jan 20 09:57:52 jku: https://autobuilder.yocto.io/builders/nightly-world/builds/130/steps/BuildImages/logs/stdio also failed the same way so I think its something on the rss branch Jan 20 09:58:17 rburton: I did see an irony there Jan 20 09:58:29 now hiring: person to wiggle the mouse at autobuilder.yocto.io Jan 20 09:58:48 jku: hhahaha Jan 20 09:59:03 jku: actually, that second one is clearer, missing intltool-native depends? Jan 20 09:59:16 jku: :D Jan 20 09:59:47 | configure: error: GNU gettext tools not found; required for intltool sounds like a missing gettext dependency/inherit Jan 20 09:59:55 jku: or gettext-native depends? Jan 20 09:59:57 jku: we need a lego mindstorms kit in OSUOSL Jan 20 10:00:08 i'll take point on that Jan 20 10:00:14 * rburton expenses a full mindstorm set Jan 20 10:00:32 joshuagl: have you seen the new mini-mindstorm? Jan 20 10:00:47 i spy next years christmas present to "the kids" Jan 20 10:00:55 The one that is puzzling me is https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/129/steps/BuildImages_2/logs/stdio Jan 20 10:01:00 we're seeing a load of those Jan 20 10:01:14 nice log Jan 20 10:01:21 really useful Jan 20 10:02:45 rburton: on the AB the log is much more helpful Jan 20 10:02:46 tar: ./usr/src/debug/nativesdk-pseudo/1.8.1-r0/recipe-sysroot/opt/poky/2.2+snapshot/sysroots/i686-pokysdk-linux/usr/include/sqlite3.h: file changed as we read it Jan 20 10:02:47 dpkg-deb: error: subprocess tar -cf returned error exit status 1 Jan 20 10:03:35 Hi. Anyone know how to make "smart" package manager be verbose and show the output from a package post install script? Using 'smart reinstall --log-level=debug ' doesn't do it. Jan 20 10:04:24 arkver: I know at rootfs time, setting ROOTFS_RPM_DEBUG = "1" does this Jan 20 10:04:32 arkver: you could see what options that passes to rpm/smart Jan 20 10:05:09 RP: huh Jan 20 10:05:12 RP: adding some debug output confirms that the line you called out gets executed before the SRC_URI_prepend. But removal works, so it seems to get executed multiple times? Does that right to you? Jan 20 10:05:14 Is smart used at rootfs build time? Jan 20 10:05:22 if you're using rpms, yes Jan 20 10:05:27 ok,t a Jan 20 10:05:28 ta Jan 20 10:06:43 Aye, that just adds "--log-level=debug" Jan 20 10:06:50 It's not wrong per se from a semantic point of view (_remove is meant to run last, so doing it multiple times doesn't change the semantic), it might just be slower. Jan 20 10:07:19 pohly: yes, we have an "on demand" data store now Jan 20 10:07:27 I'll just get the script to redirect to a log file. Jan 20 10:07:32 pohly: so values are commuted on the fly Jan 20 10:07:53 arkver: I think it adds something to rpm as well, that is the key Jan 20 10:07:58 Meaning _remove gets applied multiple time? Jan 20 10:08:27 pohly: meaning we never store the finalised value, it gets recomputed each time Jan 20 10:08:40 pohly: I suspect that is what you're seeing Jan 20 10:09:47 Perhaps. Still sounds a bit weird to compute some intermediate state (initial value + _remove) before applying the _prepend, but I take your word that it's meant to be that way ;-} Jan 20 10:10:40 pohly: I can't say for sure without poking at this in detail and I really don't have time right now but I'm not unduly worried Jan 20 10:11:12 pohly: the datastore is a bit weird/tricky Jan 20 10:12:34 pohly: actually, cna you check something. Is the parsing input parameter set? Jan 20 10:13:15 pohly: I do have to wonder if you're right and the remove block shouldn't be triggering when parsing is set Jan 20 10:14:02 pohly: you'll note that append and prepend are dependent on that variable Jan 20 10:14:14 * RP dreads you asking what it means Jan 20 10:18:48 RP: I think it changes the scriptlet invocation and content dump runes, but I don't see anything to make it dump the script output itself. I think this is shown if the script fails, but not if it succeeds. Jan 20 10:20:47 arkver: ok, I thought there was something in there but perhaps not, sorry Jan 20 10:23:43 np, thanks. I'll go for the redirect within the script option. Jan 20 10:23:52 RP: yes, parsing=True. Jan 20 10:24:45 pohly: I think you're right and that could be a bug Jan 20 10:25:35 pohly: There is an alarm bell going off that I've been here before though. Would be interesting to change it and see it bitbake-selftest still passes and OE still parses Jan 20 10:26:06 So add a "not parsing" to "if value and flag == "_content" and local_var is not None and "_remove" in local_var"? Jan 20 10:26:53 pohly: I think so Jan 20 10:27:18 pohly: As I said, I just can't help think there may have been a reason not to do this Jan 20 10:28:02 Let me file a bug and then we can investigate when the time is better. Jan 20 10:28:20 pohly: ok, fair enough Jan 20 10:43:51 ernstp: I'm getting an error because it doesn't find layer.conf in meta-openembedded, but there's no such directory or file on the tree http://cgit.openembedded.org/meta-openembedded/tree/ Jan 20 10:44:11 meta-openembedded isn't a layer Jan 20 10:44:17 its a collection of layers Jan 20 10:44:28 you need to add the layers you want, such as meta-oe or meta-python Jan 20 10:44:40 they are already in Jan 20 10:46:04 but that happend when I try to use bitbake on a recipe inside meta-python Jan 20 10:47:20 what's the actual error please Jan 20 10:48:10 ERROR: Unable to parse /home/bec_1/Yocto/poky/meta-openembedded/conf/layer.conf: [Errno 2] file /home/bec_1/Yocto/poky/meta-openembedded/conf/layer.conf not found Jan 20 10:48:19 meta-openembedded is a folder of layers, don't add that to BBLAYERS add some of its children Jan 20 10:48:33 yeah that Jan 20 10:49:24 joshuagl: ok, give me a sec Jan 20 10:49:35 thanks btw Jan 20 10:50:42 it's working now, aparently Jan 20 10:52:21 ERROR: Nothing PROVIDES 'python-pip_9.0.1.bb' :-( Jan 20 10:52:47 just use python-pip Jan 20 10:55:50 rburton: compiling Jan 20 11:07:27 I would like to ask what the preferred storage is for embedded systems these days? Is there any kind of advantage to gain by choosing NAND over eMMC for a SoM? Jan 20 11:08:28 eduardas_m: "depends" (TM) Jan 20 11:09:21 Personally I am going with eMMC at this time just because it looks to be like an integrated SD card and I am more familiar with those Jan 20 11:09:54 I may be oversimplifying things though Jan 20 11:09:58 eduardas_m: without context/usecase/requirements, the whole discussion is pretty much pointless, don't you think? Jan 20 11:10:41 i mean, you didn't even state if you are talking about volatile or nonvolatile storage :) Jan 20 11:10:52 LetoThe2nd, ok...then lets say it is a handheld measurement device... similar to a handheld oscilloscope Jan 20 11:11:22 eduardas_m: that is a usecase, but does not include requirements Jan 20 11:11:28 LetoThe2nd, nonvolatile of course :) Jan 20 11:11:53 eduardas_m: well why "of course"? my preferred memory is ddr, in a couple of contexts. Jan 20 11:14:21 LetoThe2nd, not sure what kind of embedded linux systems manage without some kind of nonvolatile storage... what are the usecases when one can manage with ddr only? when booting via network? Jan 20 11:15:23 eduardas_m: and even for your handheld scope i easily can see 3 totally different storage contexts: 1) some rom for the application 2) some ram for holding the measurement data 3) some other nv storage for logging. Jan 20 11:16:08 eduardas_m: and read again, i never stated that my use case is "ddr only". i only said it is my "preferred memory" Jan 20 11:18:54 LetoThe2nd, why not just have bootloader + kernel + sysroot + logging in single eMMC instead of two instances of nonvolatile storage (points 1 and 3)? Jan 20 11:20:04 eduardas_m: "depends". maybe one wants 1) to be totally RO, and higher quality than 3)? maybe one does wnat 3) to be removable? Jan 20 11:21:01 eduardas_m: i'm just trying to show you that your understanding of the question already contains way too many assumptions and inherent decisions for anybody else to give you valuable input. Jan 20 11:24:06 LetoThe2nd, yes, I suppose there is a valid point here, so I'll try to narrow it down... Jan 20 11:24:22 eduardas_m: :-) Jan 20 11:24:34 Lets say I decide to go with one particular SoM: http://www.variscite.com/products/system-on-module-som/cortex-a7/dart-6ul-freescale-imx-6ul Jan 20 11:24:59 and there is an SLC NAND and and eMMC option for nonvolatile storage Jan 20 11:25:22 pohly: were you going to send a patch for that first issue (unnecessary manipulation of the string)? Jan 20 11:25:38 eduardas_m: thats what the overview on the webpage says, yes. Jan 20 11:25:56 options are 128 - 512 MB for SLC NAND and 4 - 32 GB for eMMC Jan 20 11:26:12 RP: no, I intended to defer it so that it can be tested together with that other, more invasive change. Jan 20 11:26:20 I will send the fix for qemu, though. Jan 20 11:26:39 pohly: ok, I have a patch for that which I might queue. I'm happy enough that bit is safe/correct/a good idea Jan 20 11:26:57 RP: sure, your call. Jan 20 11:27:16 LetoThe2nd, device will probably have removable SD card for data storage, so NAND or eMMC is required for kernel, sysroot and application basically Jan 20 11:27:40 also I need to implement a two image update system with reliable fallback Jan 20 11:28:29 but either storage technology allows for enough memory for me to implement that Jan 20 11:29:27 the main thing that might make me switch from one to the other is if one of those allowed for faster reads/writes and thus faster bootup Jan 20 11:29:42 eduardas_m: thats right. so the question is more like: "should i use emmc or slc nand as my application rom when i need a realiable two-image update mechanism". right? Jan 20 11:29:56 LetoThe2nd, pretty much so Jan 20 11:30:24 pohly: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=729505e9235ab693d274b4075b30da19f8499776 is what I'm thinking Jan 20 11:30:40 pohly: it will have a performance impact which is why I'd like to fix it Jan 20 11:31:03 eduardas_m: and in that case, i would say: evaluate the requirements by the updating mechanism that you have chosen. some have direct support for ubifs, which makes slc a viable option. others rely on pure fs functionality, in which case i would probably opt for emmc. Jan 20 11:32:03 rburton: I assume you're ok with -next going in even if the build isn't done? Jan 20 11:32:40 RP: in my tests I still had the "if expand and var in self.expand_cache" block active. But I agree, skipping that too seems to make sense (value already in cache and not changed, I suppose). Jan 20 11:33:07 pohly: right, it only needs to do that if it changed someting Jan 20 11:35:57 rburton: how do you feel about reverting the flex version update, as it currently prevents merging the UEFI/OVMF patch series? Jan 20 11:36:32 Do we have any flex experts around here perhaps who could help? Jan 20 11:37:52 rburton: any ideas on what could lead "$(AM_V_GEN) $(GLIB_MKENUMS) \" to expand to " \" in a epiphany Makefile.am? Jan 20 11:38:55 glib-mkenums should be in glib-2.0-dev -- I'd expect that to be present... Jan 20 11:39:50 I mean glib-2.0-native obviously Jan 20 11:41:52 LetoThe2nd, thank you for your opinions. It seems that it is relatively easy to overwrite unused FAT boot partition and unused ext4 rootfs partition in case of eMMC using generic linux tools (what you call pure fs functionality), so it seems like the way to go. But then again can one not have multiple ubifs partitions on single chip and just dd the unused one? I am not familiar with this file system so thats when I'm asking. Jan 20 11:42:52 jku: hm no Jan 20 11:46:25 RP: yes Jan 20 11:48:13 jku: this is recipe specific sysroots so there is no gurantee that glib-2.0-native is present Jan 20 11:48:33 jku: does it DEPENDS on it? Jan 20 11:50:20 damn, it doesn't. I was sure it would have... Jan 20 11:51:05 jku: I suspect a gettext-native issue in there as well :/ Jan 20 11:51:16 jku: maybe we should have a class for that? Jan 20 11:51:16 RP: yup that's definitely missing Jan 20 11:53:19 RP, so how did glib-2.0-native end up in recipe-sysroot-native when I built epiphany? Jan 20 11:54:16 (still building lib32-epiphany, not sure what happens there) Jan 20 11:56:08 jku: I think it peeks though and sees host tools which aren't on some AB workers Jan 20 11:56:35 jku: I'd guess your host has a GLIB_MKENUMS Jan 20 11:57:20 eduardas_m: when using ubi, direct access to the memory is a no-go, as ubi takes care of wear levelling and bad blacks Jan 20 11:57:24 RP: no, I'm looking at recipe-sysroot-native/ for epiphany: glib-2.0-native is in sysroot-providers Jan 20 11:57:39 eduardas_m: you can have one ubi partition, containing several ubifs. Jan 20 11:57:47 jku: that is odd Jan 20 11:58:18 so is gettext-native Jan 20 11:58:50 eduardas_m: which works very well for us - we have an updating system that is ubi aware, and hence takes care of wear levelling, bad blocks and such when rewriting the iamge. Jan 20 11:59:21 LetoThe2nd, also when you said your prefered storage is ddr, did you mean you prefer to run your systems and applications in initrd? Jan 20 12:00:06 eduardas_m: no, i meant that for archieving certain pieces of functionality, i need relatively large amounts of ram. hence i prefer having much ddr. Jan 20 12:00:07 LetoThe2nd, this ubi - aware updating system does not happen to be open source? Jan 20 12:00:26 eduardas_m: it does happen. see meta-swupdate by sbabic :) Jan 20 12:00:40 pokybuild@debian-testing:~/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/i586-poky-linux/epiphany/3.22.3-r0/recipe-sysroot-native$ ls sysroot-providers/g* Jan 20 12:00:40 sysroot-providers/gcc-cross-i586 sysroot-providers/gettext-minimal-native sysroot-providers/gmp-native sysroot-providers/gnu-config-native sysroot-providers/gzip-native Jan 20 12:00:55 jku: ^^^ shows that machine does not have those things installed in the native sysroot Jan 20 12:00:59 huh Jan 20 12:01:08 LetoThe2nd, have already played around with meta-swupdate... just was not aware of ubi -related functionality Jan 20 12:02:21 jku: its possible something is racing here and that some later task depends on them Jan 20 12:02:42 jku: can you look at the timestamps, see when they were installed compared to when configure ran? Jan 20 12:03:02 LetoThe2nd, I actually could build the swupdate-image for my system, but ran into the problem described here: https://groups.google.com/forum/#!topic/swupdate/O2VdV7SBVr0 Jan 20 12:03:28 jku: for example, qemu-native may be needed during do_package and that links to glib-2.0-native, hence it could be installed then Jan 20 12:03:35 sw-description does not get fetched for me for some reason Jan 20 12:03:51 (i'm not saying that specific example is true but something like it) Jan 20 12:04:19 jku: the best test would be "bitbake epiphany -c configure" (clean epiphany first) Jan 20 12:06:19 LetoThe2nd, so basically the place where I got stuck was that I could not generate compound images for updates Jan 20 12:07:49 rburton: I think I'm seeing things. https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/153 - what does that say to you? Jan 20 12:08:11 RP: I'll try configure, the timestamps are confusing -- probably looking at wrong stamp Jan 20 12:08:43 jku: ok. It did this for lib32 and non-multilib so I think it affects both Jan 20 12:09:41 RP: fyi: smart -o rpm-log-level=debug shows all the rpm verbosity. Jan 20 12:10:18 arkver: cool, I thought there had to be a way! Jan 20 12:11:11 eduardas_m: well of course i don't know your specifics, but we genereate single swu images which we can hand to swupdate. Jan 20 12:13:03 LetoThe2nd, I pretty much like the idea of SWUpdate from the documentation I have read, but I find it lacking in some places... Jan 20 12:13:26 I can not make an swu although I try to follow the beaglebone black example Jan 20 12:13:35 which is the only one provided Jan 20 12:14:05 eduardas_m: if it fit your needs is something that you have to evaluate for yourself, of course. i can only tell you that it works fine for one of mine, using ubi on slc :) Jan 20 12:14:19 also, I do not like how meta-swupdate expects your BSP to have the newest bootloader Jan 20 12:14:44 if you don't it breaks u-boot-fw-utils recipe with patches for example Jan 20 12:15:22 eduardas_m: we certainly do not have the newest bootloader. but you're right, it needs a bit of massaging to work Jan 20 12:15:33 eduardas_m: another option might be mender.io Jan 20 12:15:43 eduardas_m: or resin os Jan 20 12:15:53 it really depends, there is no silver bullet. Jan 20 12:16:03 mender.io does not support local or at least is not oriented to IIRC Jan 20 12:16:20 and we basically only need local updates Jan 20 12:16:38 like from an archive on a USB key that one attaches to device Jan 20 12:16:48 the only thing i can really give as strong advice: do *not* try and roll your own. Jan 20 12:17:29 eduardas_m: fyi mender does support locally applied updates Jan 20 12:17:36 LetoThe2nd, that is exactly what I am trying to do right now... and that is because SWUpdate does not work for me Jan 20 12:18:09 eduardas_m: do not do. the long term pains will exceed any trouble that you might have initially with a preexising solution by orders of magnitude. Jan 20 12:19:10 RP: you're correct. glib-2.0-native and gettext-native are missing during configure... Jan 20 12:20:48 eduardas_m: and if you're using a specific SoM, you can always ask the vendor if they support some specific solution, for example. Jan 20 12:25:21 LetoThe2nd, I am aware of the danger... but sometimes for an embedded linux novice like me the problem lies here: there are no funds to hire expensive foreign experts to massage SWUpdate or some other solution into place for the BSP we are using Jan 20 12:26:08 eduardas_m: well you always have to pay in either time or money. and if you don't have money, you have to invest time. Jan 20 12:26:29 I would actually prefer to have some paid consulting or support for what I am doing, but the problem is again : money Jan 20 12:27:03 eduardas_m: i'm just saying: "do not invest your time in rolling your own quick-hack solution, as it will give you pains. invest your time in understanding and using a preexisting solution" Jan 20 12:27:51 eduardas_m: and sad to say, but rolling a product always requires some money, especially if hardware is involved. Jan 20 12:33:11 so can intltool-native ever work without gettext-native ? Jan 20 12:33:58 rburton maybe ^ Jan 20 12:34:26 eduardas_m: anyways, i'm off. if you feel like discussing more, find me here on monday :) Jan 20 12:34:58 LetoThe2nd, thank you very much for your time... Jan 20 12:35:07 eduardas_m: np, have fun. Jan 20 12:44:08 RP: let me know if you just want a patch for epiphany ASAP: I'm still trying to understand how this works and whether there are other dependency issues like this Jan 20 12:45:31 for example, why doe "bitbake -cconfigure vte" results in gettext-native being in recipe-sysroot-native/ even though the recipe does not depend on gettext-native Jan 20 12:48:48 jku: is there a depends from the gettext class? Jan 20 12:49:01 jku: I do agree we need to figure this out, a patch would be good in the meantime though please Jan 20 12:50:56 RP: there is, but e.g. vte does not inherit (not directly anyway) Jan 20 12:57:10 jku: have a look at the do_prepare_recipe_sysroot task logs, that might give clues about where it comes from Jan 20 12:58:06 rburton: https://github.com/westes/flex/issues has lots of issues about "flex 2.6.3 breaks compiling xyz". Jan 20 12:58:34 jku: looking at my logs, gettext-native is added as a dependency of glib-2.0-native Jan 20 12:58:47 I should be able to come up with a hotfix for compiling acpica, but I am really wondering whether we should really upgrade to 2.6.3 at this time. Jan 20 12:59:44 jku: i.e. it looks like a glib-2.0 depends is enough to pull in gettext Jan 20 12:59:53 (which does make sense) Jan 20 13:03:12 RP can you walk me through that: http://pastebin.com/ds25FMSx ? How do you see the dependency logic from there Jan 20 13:05:42 but yeah, confirming that : glib-2.0-native does pull gettext-native in Jan 20 13:06:36 \0/ it's taken a bit, but now also core-image-sato builds and boots (to GUI) with dnf :) Jan 20 13:06:50 nice Jan 20 13:07:31 I guess that's the end of the '90%' Jan 20 13:07:31 jku: trick it to work backwards. Start by finding "Adding dependency on gettext-native" Jan 20 13:07:37 now come the other 90% Jan 20 13:07:52 jku: line above is considering dependency: ['glib-2.0-native', 'do_populate_sysroot'] which means that was the dependency which triggered the addition Jan 20 13:08:11 jku: welcome to the world of sstate setscene reverse logic Jan 20 13:08:36 thanks! Jan 20 13:12:40 Hi, I have an .ipk, originating from meta-qt5 layer, with file name libqt5svg5_5.4.2+git0+ccae23961e-r0_cortexa9hf-vfp-neon.ipk Jan 20 13:13:05 I can install it manually with opkg, and a QML app which uses svgs works after that (not without) Jan 20 13:13:35 I have been unable to figure out how to get it installed in an image recipe though Jan 20 13:14:05 so, if I have an .ipk produced by bitbake, and I want to find out how I would add it to image recipe, how should I go about it? Jan 20 13:14:36 I have grepped for the packge name and various parts of it, but haven't yet figured out where the .ipk even comes from (other than it must be from meta-qt5 layer) Jan 20 13:15:01 any suggestions? Jan 20 13:16:53 pohly: ok that takes it from "acapi breaks" to "everyone breaks", i'll revert. thanks for digging. Jan 20 13:18:16 rburton: well, I'm not sure whether it breaks "everyone" in OE. Jan 20 13:19:28 okay, 'lots' Jan 20 13:19:32 For example, binutils, gdb master and grub are getting mentioned. Jan 20 13:20:23 Those must have been built successfully in OE, right? So it's perhaps not that bad in OE core itself (for whatever reason), but yes, it doesn't look good overall. Jan 20 13:20:38 well, binutils is sufficiently tricky to build that we may be using pregenerated files for that Jan 20 13:21:04 Hmm, could it be that gdb for the target wasn't even using flex-native? Jan 20 13:21:56 No, it's in pn-buildlist of "bitbake -g gdb". Jan 20 13:22:24 hyde: how do you know it's from meta-qt5? Jan 20 13:22:40 rburton: how do you want to proceed? I have a workaround for acpica ready. Jan 20 13:22:45 pohly: the binutils bug says 2.6.2 works Jan 20 13:23:03 But we updated to 2.6.3... Jan 20 13:23:23 my patch was to 2.6.2 Jan 20 13:23:25 Ooops, we didn't. Jan 20 13:23:51 I got confused because the latest upstream code that I checked out had 2.6.3 Jan 20 13:26:21 Okay, let's keep 2.6.2, work around this in acpica, and revisit once we know better whether it affects others and what upstream flex says about my bug report (https://github.com/westes/flex/issues/164). Jan 20 13:39:51 pohly: is the secureboot something that was scheduled for m2? Jan 20 13:40:02 i guess its got new bits so sooner rather than later is good Jan 20 13:40:45 Which Secure Boot thing? The UEFI/OVMF patches? That doesn't have an official Bugzilla entry, so no. Jan 20 13:42:00 But I agree, getting them in sooner than later would be better. Jan 20 13:42:31 I've ping Ricardo again to check out the revised patches, just in case that you were waiting for someone to double-check them. Jan 20 13:42:46 someone else checking them would be good Jan 20 13:42:57 Yes. Jan 20 13:43:00 just hecking if theres a greater need for them to be in *now* Jan 20 13:43:56 Other than me struggling with keeping all of my pending patches available while building locally, no ;-} Jan 20 13:44:28 yeah thats a pain i think we all understand Jan 20 13:44:43 * rburton has 47 local branches Jan 20 13:44:45 I need a "merge all pending git series into a working branch" helper script. Jan 20 13:45:10 no idea what percentage of them actually rebase to master Jan 20 13:46:10 I like that "git series" maintains clean patch series, but compared to accumulating all pending patches in a branch it's harder when your actual work depends on more than one series. Jan 20 14:13:37 jku: I think I have my other issues fixed for another rss test run, do you have a fix I could add in ? Jan 20 14:23:32 ed2: The wic series seems good thanks. Do you want me to mail that to the list (dependent on the rss patches)? Jan 20 14:32:39 RP, oh I sent an epiphany patch to list earlier , sorry I didn't ping you Jan 20 14:33:08 no idea about the nss package_write_deb failure Jan 20 14:33:29 jku: its ok, I have that one Jan 20 14:33:35 jku: thanks! Jan 20 14:34:06 lots of epiphany activity? is it the best option these days? Jan 20 14:35:31 ernstp: epiphany activity in here because its part of oe-core Jan 20 14:35:35 ernstp: depends what you need it for. It's pretty good at failing to build for example Jan 20 14:35:43 lol Jan 20 14:36:01 jku: that is not currently on the requirements list :-) Jan 20 14:37:00 * RP quietly sobs at new ways the rss code breaks after the last fix Jan 20 14:38:43 using chromium right now, the back/forward swipe gestures you get out of the box is pretty neat Jan 20 14:44:44 also, you can use compiling chromium/webkit for heating your office Jan 20 15:45:24 has anyone seen an error with wic where it says Partition internal size is not an integer. This a bug in source plugin rawrootfs and needs to be fixed. Jan 20 16:08:12 cc ed2: ^^ Jan 20 16:11:57 davis: never seen it. can you create bug? Jan 20 16:13:39 yes, it happens every time I do the wic step. btw, I've been using wic for sometime now, but not taken time to look into it. Jan 20 16:14:09 I wrote a recipe which inherits module. It builds correctly but when I try to install on the system has a dependancy on kernel-module-stream-bus-sbc. Can someone explain? https://gist.github.com/strike5150/3d1160481a6bcda27bf25992ced16c6d Jan 20 16:14:32 is it something to do with Windows Image configurator or is that just a coincidence? Jan 20 16:14:41 I don't know how to install the dependancy and I don't understand where it comes from Jan 20 16:14:59 davis: just a coincidence I believe. Jan 20 16:15:08 ok many thanks Jan 20 16:15:17 do you know of a ref online for wic? Jan 20 16:17:31 davis: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-partitioned-images Jan 20 16:17:53 ed2: many thanks. i appreciate it. Jan 20 16:18:48 davis: if you're ok with local ref you can also run wic help overview|kickstart|plugins Jan 20 16:19:17 ahh that is cool. many thanks Jan 20 16:19:42 davis: I wouldn't suggest to look at the code though. It's a messy java-like stream of bytes. Jan 20 16:20:12 davis: I'm trying to refactor it at the moment, so I speak from experience :) Jan 20 16:20:43 tip of the hat to you. Jan 20 16:20:57 i'll be happy if I can understand how to use it Jan 20 16:22:00 davis: the best way to use it is to create .wks file, set WKS_FILE variable, add 'wic' to IMAGE_FSTYPES and run bitbake Jan 20 16:23:27 my colleague set this up for me. I'm hoping to talk to him about this error, but in the meantime i'll read your reference. Its been awhile since I've made a sata img. Jan 20 16:23:32 davis: feel free to ask questions about wic. I'll be happy to answer. Jan 20 16:23:37 the usb img wic step still works. Jan 20 16:23:56 we do have a wks file Jan 20 16:24:17 and when i first got the error, i looked at it. I don't see any fractional numbers. Jan 20 16:24:30 so i am not sure why the error has occured. Jan 20 16:24:47 davis: ok, can you show it here? which machine do you use, btw? Jan 20 16:24:56 Error: Partition internal size is not an integer. This a bug in source plugin rawrootfs and needs to be fixed. Jan 20 16:25:12 davis: i mean wks file Jan 20 16:25:16 its for atom Jan 20 16:25:25 im using a custom wks file Jan 20 16:25:42 it has entries which look like attributes for each partition Jan 20 16:26:26 davis: I'm afraid this is not enough for me to reproduce and fix this. I need more details. Jan 20 16:26:38 we have three different wks files for sata. possibly for differnt rootfs types. the sizes look same but the bootloader cmd line varies between files. Jan 20 16:26:47 that makes sense Jan 20 16:27:49 davis: if you can tell me which MACHINE do you use, show your wks file and your bblayers.conf I might be able to reproduce the issue. Jan 20 16:28:09 davis: it's better to do in bugzilla, I believe. Jan 20 16:28:17 one sec Jan 20 16:31:42 im getting waits on github gist. heh entire company must be watching the innaugration Jan 20 16:37:10 or the internet started to fail already Jan 20 16:39:31 hi ,i have a siemens iot 2020 running yocto 4.4.13 , I am trying to access ttyUSB0 , but get permission denied , how can I fix this? Jan 20 16:43:41 zeddii: have you changed the linux-libc-headers 4.9 upgrade since you submitted it first? Jan 20 16:43:53 i can't reproduce my connman/musl/4.9 headers failure anymore! Jan 20 16:44:17 ed2 https://gist.github.com/netskink/08277765c898333ecd093141aa573e12 Jan 20 16:44:19 nope. it is still 4.9. I was going to bump it to a -stable variant eventually but was holding on that. Jan 20 16:44:42 there is a third wks file, but I don't think its being used during that invocation ive shown Jan 20 16:46:41 in terms of machine, i do an export MACHINE=buts its a product name and not somthing like x86 or beaglebone, etc. but I think it steers towards an atom based cpu/board Jan 20 16:48:54 zeddii: huh. thanks. Jan 20 16:49:09 davis: can you reproduce the issue on genericx86* or qemu machines? Jan 20 16:50:19 i dont use qemu. i've used in the past but not on this system. Jan 20 16:51:00 i can look into it though. that will take some time. Jan 20 17:08:30 davis: can you give names to your partitions in .wks. you'll see which partition wic complains about. Jan 20 17:10:03 ed2: how to do that? Jan 20 17:10:40 the bit in ""? Jan 20 17:10:52 yes Jan 20 17:10:58 ok one sec Jan 20 17:11:34 RP, Locking is broken on debian-testing now. But the build isn't stuck yet. Jan 20 17:13:40 hmm. makes a python stacktrace Jan 20 17:15:15 davis: what's rawrootfs plugin? Jan 20 17:15:30 davis: looks like custom Jan 20 17:16:00 davis: I don't see it among standard wic plugins. Jan 20 17:16:04 halstead: :(. Any idea what is breaking? I was hoping the completed build meant you'd fixed it? Jan 20 17:18:03 RP, It's the out of sequence error in the logs again. I don't think we've seen it on debian-testing before. It might be a new trigger for the old problem. Jan 20 17:48:08 halstead: not good :/ Jan 20 17:52:08 RP, I got it to recover without interrupting anything. So this build might be okay at least. Jan 20 17:57:11 halstead: how did you do that out of interest? Jan 20 18:05:33 * RP has posted the recipe specific sysroot patch for review Jan 20 18:19:10 halstead: thanks for keeping it running, I'm hoping for good things from that build! Jan 20 18:19:18 (its the final rss patchset) Jan 20 18:47:02 khem: you there? Jan 20 18:48:11 is there really no better way than this? https://lists.yoctoproject.org/pipermail/yocto/2014-July/020782.html I do need pam support for my openssh server. Jan 20 18:55:26 RP, I kind of brute forced it. umount -l /srv/autobuilder && systemctl restart nfs-utils && mount /srv/autobuilder Jan 20 18:57:02 RP, I ran lsof /srv/autobuilder/ to try to make sure nothing would be interrupted by it first. Jan 20 19:54:22 RP: congratulations, I guess :) Jan 20 19:54:47 uhoh Jan 20 19:56:20 webkit build was OOMed on the autobuilder Jan 20 19:56:52 I hope to come out with the dnf work before the end of the month, I'm getting tired of working in isolation on it Jan 20 19:57:25 I should ask WR team (that has offered to help) to run the current patchset through their systems, and report specific issues Jan 20 20:03:03 yes, definitely Jan 20 20:04:34 rburton: some of the things I'm doing there are controversial Jan 20 20:05:15 rburton: db 6.x is removed, rpm5 is removed, a bunch of complicated barely penetrable logic around rpm5 that may or may not serve real purpose is also removed Jan 20 20:06:31 probably worth mailing a link to the branch to the list as work in progress for feedback Jan 20 20:07:01 rburton: yeah, i just want to get the most obvious omissions fixed first - sdk generation is at the moment broken for instance Jan 20 20:07:09 rburton: but images build and boot :) Jan 20 20:20:58 Is this the right place to ask bitbake questions? Jan 20 20:24:57 here or #oe, yes. either one Jan 20 20:27:53 Excellent. I'm trying to maintain a local mirror of all of our source pacakges and I'd like to run with BB_FETCH_PREMIRRORONLY and I have that workign fine. The only thing I'd like to add is the ability to "whitelist" an internal Gitlab server so I can still fetch directly from that Jan 20 20:28:19 see BB_ALLOWED_NETWORKS Jan 20 20:28:24 (iirc) Jan 20 20:32:02 kergoth: Thanks! I was looking at an old version of the bb user manual. My mistake Jan 20 20:32:52 it's ideal for limiting to internal servers like that Jan 20 20:39:58 kergoth: Its exactly what I was looking for. Huge thanks. Jan 20 20:40:57 np Jan 20 22:26:18 halstead: we're seeing this a lot on the new cluster in recent builds: https://autobuilder.yocto.io/builders/nightly-x86/builds/164/steps/BuildImages/logs/stdio - seems the PR server can't cope :( Jan 20 22:26:32 halstead: probably not your problem to fix but I thought I'd flag it Jan 20 22:27:22 RP, So. In my continued research the advice I see over and over is to reduce load on the system and see if NFS errors continue. Could high load also cause issues with the PR server? Jan 20 22:30:03 halstead: absolutely Jan 20 22:30:25 halstead: just looking at https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/136 and the second failure at least is resource problems Jan 20 22:30:46 halstead: https://autobuilder.yocto.io/builders/nightly-multilib/builds/157 also could be resource issues, was the same machine Jan 20 22:31:46 RP, Is there a good way to reduce the number of threads we start? Or we could just switch to 2 workers per box for a bit. Jan 20 22:32:47 halstead: we'd set BB_NUMBER_THREADS lower Jan 20 22:43:53 RP, So we have BB_NUMBER_THREADS=16 on the stable cluster and BB_NUMBER_THREADS=48 on the unstable cluster. Can you recommend a good value in between? Jan 20 22:44:48 halstead: try 24? Jan 20 22:44:55 * halstead nods. Jan 20 22:45:51 RP, I'll reload the controller when/if these last builds wrap up. Jan 20 22:45:51 halstead: I run 144 locally :) Jan 20 22:46:05 RP, On how many cores? Jan 20 22:46:09 halstead: not often with many in parallel though Jan 20 22:46:21 halstead: 72 Jan 20 22:47:21 halstead: I mainly do this to stress things rather than it being fast Jan 20 22:47:33 Okay so we have 28 cores with hyperthreading that is 56. And we are running 48 threads * 3 workers so 144 as well. Jan 20 22:48:16 halstead: this is 36 cores with HT in addition to that Jan 20 22:48:37 halstead: the builds can't really leverage 144 much of the time anyway Jan 20 22:48:51 halstead: 24 seems like a reasonable number to try and see if it calms things down Jan 20 22:49:12 Sounds good. Jan 20 23:18:46 halstead: if you need a test once you've changed that, master-next should be good (it contains rss but will be a full rebuild due to a tweak) Jan 20 23:19:08 RP, Excellent. Jan 20 23:19:31 Is there someone on here that can help me and my team understand how to make a bootable X86 PC out of the Yocto artificats? We have been unsuccessful with everything we have tried to date. Jan 20 23:20:47 We want to create (at least to start) a boot partition and a root partition with grub2 as a bootloader. Eventually we'll have two boots and two roots (for current and next version) for upgrades. Jan 20 23:24:01 dmikulin: I'm sure there are people here who've done it and the project can certainly do that. There are a lot of specifics to your environment there to get right though of which we know nothing. I'd try and ask more specific questions and give more information (e.g. you did what exactly and how exactly did it fail?) Jan 20 23:25:34 RP: Specifics: target is a core i7 industrial PC. Using Ubuntu as a development host. Jan 20 23:26:33 If we "dd" the .hddimg to a SSD it boots. We have been able to boot using PXE putting the bzImage in a TFTP directory and the root file system in an NFS directory. Jan 20 23:27:13 RP: We've tried 'dd'ing the .wic file to a HDD and it doesn't boot. Should it? Jan 20 23:27:26 dmikulin: do you weren't entirely unsuccessful Jan 20 23:27:32 s/do/so/ Jan 20 23:28:02 dmikulin: I was about to suggest that wic should be able to combine things together in a way that would do what you need Jan 20 23:29:01 dmikulin: sadly I'm not a wic expert and the one I do know is in Europe and gone for the weekend but if you write up a decent summary on the mailing list its possible he can spot the problem Jan 20 23:29:02 RP: We have about a combined 100 MB kernel + RFS, but are installing image onto a 128 GB disk where the 127+ GB will be reserved for logging. We don't want to have to create and store 128 GB wic files. Jan 20 23:29:30 dmikulin: the wic files should be sparse if I remember correctly Jan 20 23:30:11 RP: Should the .wic file boot if copied to a disk? Does legacy / EFI come into the picture? Jan 20 23:30:30 RP: .wic dd'd to disk, not just copied. Jan 20 23:31:04 all you should ahve to do is dd the .wic to the disk Jan 20 23:31:14 dmikulin: I'd have expected dd, copied to what would be the question otherwise. You need someone who knows wic more Jan 20 23:31:25 i'd suggest comparing your working and non-working disk image. examine the partition tables. mount the partitions with loopback and compare their contents Jan 20 23:31:32 * kergoth has had to do that before Jan 20 23:32:35 RP: Does the default core-image-minimal expect legacy MBR or EFI? I wonder if it is not booting just because of a BIOS setting? Jan 20 23:33:11 RP: We get the error message "Please insert a bootable media" type message. Jan 20 23:34:10 dmikulin: entirely possible, I'd suggest what kergoth mentions, compare the disk working and not working and see what the partition tables look like Jan 20 23:34:20 RP: The working .hddimage has no partitions and the .wic has three partitions. So, they are very different. Jan 20 23:34:25 can also read the .wks to see what it's doing (use bitbake -e to examine WKS_FILE) Jan 20 23:34:43 that really doesn't make sense. how exactly would you boot a disk image without a partition table? Jan 20 23:35:05 kergoth: Sorry, .hddimg has a single partition. Jan 20 23:36:13 kergoth / RP: What is the most appropriate #yocto mailing list to ask this question on? Jan 20 23:37:34 dmikulin: yocto@ Jan 20 23:38:13 dmikulin: what wks file are you using to create your image? Jan 20 23:38:18 dmikulin: as kergoth said, look at the wks file for an idea of what its doing. hddimg is certianly legacy Jan 20 23:38:34 dmikulin: and sgw_ does this more than I do Jan 20 23:38:47 Kind of makes me sad I don't get to play with real hardware that much now Jan 20 23:40:07 SGW_ We haven't created our wks file. We are simply creating core-image-minimal at this point with a few extra packages added. Nothing special. So, it's whatever the default file is for machine type intel core i7 Jan 20 23:41:05 SGW_ Default .wks file that is. BTW, we followed the same process for Beaglebone and the resultant .wic file from the build did boot on the Beaglebone. Jan 20 23:41:27 halstead: if it helps, kill the current cluster build and start a new master-next one, I think it broke enough the result doesn't matter so much and its nowhere near even starting selftest Jan 20 23:41:45 halstead: I'll take the results of the new build Jan 20 23:41:54 dmikulin: So your using the meta-intel BSP (intel-corei7-64) or genericx86-64 or custom? Default WKS might depend on which EFI_PROVIDER you have set also Jan 20 23:41:54 RP, Ah. Thank you. I didn't really look forward to waiting to kill it. Jan 20 23:42:21 dmikulin: I assume it's EFI or PCBIOS? Jan 20 23:42:57 SGW_ We are using meta-intel BSP intel-corei7-64. Jan 20 23:43:19 halstead: I can't tell if some of those failures are rss bugs or not. I suspect the eSDK one on nightly arm is though :( Jan 20 23:43:32 dmikulin: Which release of Yocto Project/Poky? Jan 20 23:44:23 SGW_ Hot off the press - we just put the same SSD into another PC and it boots, so it must be a BIOS setting or EFI option. We are trying to boot on Advantec ARK 3500. Jan 20 23:44:38 Morty (Yocto 2.2) Jan 20 23:45:19 dmikulin: Ok, not familiar with ARK 3500, do you know if it's PCBIOS or EFI? Jan 20 23:46:58 RP, Do you want artifacts generated? Jan 20 23:47:08 sgw_ Not sure ourselves. But considering the .wic looks to be EFI and it works on PC where UEFI is enabled and not on the ARK 3500, I have to assume PCBIOS. Jan 20 23:47:16 halstead: no, I don't need them thanks Jan 20 23:47:41 sgw: Is intel-corei7-64 default to generate .wic that needs EFI? Jan 20 23:49:36 sgw_ Looking... the wks file specifies --source bootimg-efi. What is the corresponding option for PCBIOS? Jan 20 23:49:41 dmikulin: yes, currently wic images are assumed to be EFI Jan 20 23:51:28 you can try directdisk-bootloader-config (in scripts/lib/wic/canned-wks Jan 20 23:51:51 dmikulin: I have not worked with that recently Jan 20 23:52:32 sgw_ Okay, we will take a look at that. Jan 20 23:53:06 dmikulin: you can also look atdirectdisk-gpt any other directdisk in that directly Jan 20 23:53:38 dmikulin: we are working to create a new wks that actaully replaces the hddimg, but not there yet. Jan 20 23:54:18 dmikulin: hopefully that gets you going Jan 20 23:54:37 * sgw_ has to bolt to mentor a High School Roborics team have a good weekend all Jan 20 23:54:55 sgw_, kergoth, RP: Thanks guys - you have been very helpful! Jan 20 23:56:11 dmikulin: hopefully you're heading in a good direction now :) Jan 20 23:56:15 * RP should sleep **** ENDING LOGGING AT Sat Jan 21 03:00:00 2017