**** BEGIN LOGGING AT Fri Jul 21 03:00:02 2017 Jul 21 06:44:08 RP: do runqemu and oe-selftest support multiconfig? What I mean is, can they be told to boot images or run tests in some other config than the default one? Jul 21 06:44:33 Same for "bitbake -e". Jul 21 07:11:22 RP: is changing DISTRO_FEATURES allowed in a multiconfig? Apparently not (at least not out-of-the-box), because recipes of different multiconfigs end up sharing the same WORKDIR. Jul 21 07:12:17 Switching between machines avoids that because only machine-specific recipes vary between builds, and they already have different paths. Jul 21 07:23:28 RP: does it really make sense that -native tools are built in "x86_64-linux" where "linux" is from "TARGET_OS"? Are these tools really specific to the target OS? Jul 21 07:24:15 pohly: Isn't that from BUILD_OS? Jul 21 07:24:59 RP: hmm, not according to "bitbake -e intltools-native", unless I misread something. Let me double-check. Jul 21 07:26:13 pohly: runqemu and oe-selftest have no knowledge of multiconfig. I'd have thought runqemu would be fine if you point it at the right deploy artefacts. oe-selftest would be hard for multiconfig Jul 21 07:26:27 I'm asking because in my multiconfig variants I could set TARGET_VENDOR or TARGET_OS differently than in the main config to avoid the path clash. TARGET_OS would be a bit more natural, but only if it isn't used for the native tools. Jul 21 07:27:08 pohly: You could just set a different TMPDIR? Jul 21 07:27:25 Yes, but then native tools aren't shared either. Jul 21 07:27:59 # pre-expansion value: Jul 21 07:27:59 # "${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}" Jul 21 07:27:59 MULTIMACH_TARGET_SYS="x86_64-linux" Jul 21 07:28:19 pohly: hmm. If they are prepopulated in sstate you'd likely be fine but yes, in a from scratch scenario they would get duplicated Jul 21 07:28:29 That's for intltools-native. Jul 21 07:28:46 So no, it's not using BUILD_OS. Jul 21 07:29:07 pohly: It is since native.bbclass sets TARGET_OS = BUILD_OS Jul 21 07:30:05 pohly: I think TARGET_VENDOR may be the correct thing here btw Jul 21 07:30:23 pohly: since vendor is a custom field where as os is keyed off by various things Jul 21 07:30:57 and yes, TARGET_VENDOR and BUILD_VENDOR are different things Jul 21 07:50:05 RP: changing "TARGET_OS" away from "linux" doesn't work, I end up with "Unable to determine bit size for architecture 'x86_64' - Please add your architecture to siteinfo.bbclass" errors. Jul 21 07:53:48 It's a bit confusing that the message only mentions HOST_ARCH and not HOST_OS. I suspect it is HOST_OS which changes to something that isn't known. Jul 21 07:57:09 Yes, HOST_OS = linux-x11 = TARGET_OS in my conf/multiconfig/x11.conf. Jul 21 07:57:31 pohly: right, siteinfo reads HOST_OS which is set from TARGET_OS in many cases Jul 21 07:57:40 pohly: as I said, changing TARGET_OS is a bad idea Jul 21 07:57:49 pohly: you want TARGET_VENDOR Jul 21 07:58:17 Did you say that? ;-} Sorry, I did not quite get the message. But I see now why it is a bad idea. Jul 21 07:58:52 pohly: I perhaps didn't put it quite strongly enough :) Jul 21 07:59:36 Nothing beats first hand experience - seeing the errors is much better than someone saying "don't do that" ;-} Jul 21 07:59:51 pohly: indeed :) Jul 21 08:01:23 Changing TARGET_VENDOR helped a bit, but I'm still getting file conflicts elsewere, for example for tmp-glibc/deploy/ipk/corei7-64/wpa-supplicant-cli_2.6-r0_corei7-64.ipk. Jul 21 08:01:27 I'll keep trying... Jul 21 08:02:12 pohly: right, you might need a DEPLOY_DIR tweak too Jul 21 08:02:25 pohly: you're trying something I don't think anyone has tried before Jul 21 08:02:48 RP: you know me - boldly going where no (sane) man has gone before ;-} Jul 21 08:03:00 pohly: you're also assuming DISTRO_FEATURES don't leak into native recipes Jul 21 08:03:08 I do. Jul 21 08:03:45 pohly: whilst most distro features shouldn't and the contains() mechanism should prevent leakage of non relevant values, I do wonder if we can assume that Jul 21 08:05:08 pohly: as a headsup for refkit, we just merged the bitbake server rework changes. These are significant changes. Jul 21 08:09:54 They don't leak for x11 and wayland, which is what I am trying to build in parallel here. Or perhaps more precisely, x11 is always enabled (due to DISTRO_FEATURES_NATIVE) and wayland gets filtered out. Jul 21 08:11:02 Thinking about this some more, I wonder whether I can actually achieve my goal. My hope was that by using multiconfig, I can get a more efficient build compared to invoking bitbake three times in the same build directory with different distro features. Jul 21 08:11:40 But the "more efficient" part is a bit questionable. Jul 21 08:13:21 pohly: Its an interesting experiment, I'm cheering you on Jul 21 08:13:47 For example, if there is a target recipe "foo.bb" which doesn't depend on either x11 or wayland, and it needs to be rebuilt for some reason. When invoking bitbake three times, it will get built the first time and then be left unchanged. Jul 21 08:15:06 When all three variants are active in a build (foo, multiconfig:x11:foo, multiconfig:wayland:foo), then I fear that they will all get built in parallel, producing the exact same sstate. That's less efficient. Jul 21 08:15:30 RP: is my expectation right? I haven't actually tried it. Jul 21 08:15:35 pohly: until fairly recently changing DISTRO_FEATURES on an existing tmpdir was dangerous and not supported ;-) Jul 21 08:16:03 pohly: your suspicion is correct unfortunately Jul 21 08:16:19 pohly: there is an open bug to optimise that but we're no where near ready for that yet Jul 21 08:16:30 Bug number? Jul 21 08:17:01 pohly: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10682 Jul 21 08:17:02 Bug 10682: enhancement, Medium, Future, richard.purdie, NEW , multiconfig sstate optimisations Jul 21 08:18:21 pohly: there is overlap between solving that and distributed builds Jul 21 08:19:56 RP: FYI I enabled sstate for oe-selftest on the prod (yp.o) cluster last night, a master build has several failures in oe-selftest Jul 21 08:20:27 I can probably avoid this particular inefficiency by building each target separately. But then the question becomes whether it is still more efficient than the traditional approach. Jul 21 08:22:00 joshuagl: one failure in wic? Jul 21 08:22:05 looks like it's just one test that fails, wic.Wic.test_fs_types - Testcase 1849: FAILED Jul 21 08:22:17 joshuagl: that doesn't look sstate related to me Jul 21 08:22:22 ed2: ^^^ Jul 21 08:22:26 https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/945/steps/Running%20oe-selftest/logs/stdio Jul 21 08:22:44 RP: neat, was slowly reaching the same conclusion. Thanks for looking Jul 21 08:23:01 transaction.h:42: btrfs_start_transaction: BUG_ON `fs_info->running_transaction` triggered, value 15520960 Jul 21 08:23:31 joshuagl: RP: I'll have a look. Jul 21 08:23:52 ed2: looks like it may be a btrfs tools bug Jul 21 08:25:50 RP: sstate also enabled for new (y.io) cluster now Jul 21 08:25:54 thanks ed2 Jul 21 08:27:53 joshuagl: thanks Jul 21 08:29:40 RP: about this "changing DISTRO_FEATURES in existing tmp not supported" - was that documented or just part of the "if you run into problems, remove tmp and try again" fallback? I wasn't aware of this limitation. Jul 21 08:29:46 What removed it? Jul 21 08:30:23 pohly: We added code which makes it work in the majority of cases now Jul 21 08:31:00 pohly: too many users got confused and saw breakage with it not working Jul 21 08:31:12 pohly: rss should have been the final piece of that puzzle Jul 21 08:33:05 RP: rburton: going to make some quick changes to the AB's this morning, please give me a few Jul 21 08:36:32 RP: when I do "bitbake multiconfig:x11:refkit-image-common", I end up with three messages about "Build completion summary", with identical content. Jul 21 08:36:57 Is that a report about the entire build config? Jul 21 08:37:11 I inherit buildstats-summary.bbclass. Jul 21 08:37:33 I suspect it's related to your recent event trigger changes. Jul 21 08:37:53 RP: regarding patchelf & gold issue(#11785). Does this patch looks ok to you? https://gist.github.com/bartosh/aacbdc5140149e408e3639f1edc60fca Jul 21 08:37:54 pohly: We intentionally fire BuildCompleted events for each multiconfig Jul 21 08:38:03 pohly: if we don't there are much worse things happen Jul 21 08:38:18 pohly: I'm fine with adding a "MulticonfigBuildCompleted" event too Jul 21 08:38:55 RP: here is a diff of readelf output after and before the patch: https://gist.github.com/bartosh/aacbdc5140149e408e3639f1edc60fca Jul 21 08:39:25 ed2: at a quick glance, yes Jul 21 08:40:15 ed2: does that actually change behaviour at all though? Jul 21 08:40:16 RP: I think such a MulticonfigBuildCompleted event is needed for buildstats-summary.bbclass. Jul 21 08:40:33 ed2: same link? Jul 21 08:40:36 Do you want a bugzilla entry for it? Jul 21 08:40:44 RP: yes, it does. Jul 21 08:41:06 RP: oops, sorry. this is the right one: https://gist.github.com/bartosh/6e0e2c2c0c0a7f28a2c4d0c2814f223e Jul 21 08:41:09 pohly: hmm. I can probably write the patch just as fast Jul 21 08:41:17 Okay ;-} Jul 21 08:42:36 RP: without this patchelf produces broken executable. ldd reports (not a dynamic executable) and ld-linux segfaults when loading it. Jul 21 08:44:46 RP: you can see much more info in the bug #11785 Jul 21 08:44:47 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=11785 major, Medium+, 2.4 M3, eduard.bartosh, IN PROGRESS IMPLEMENTATION , On Debian 9 m4 segfaults making impossible to build autoconf-native due to the uninative feature Jul 21 08:48:18 ed2: are you sure the patch above is the one you're testing? Jul 21 08:48:44 ed2: It doesn't seem to match the one in the bug but its hard to tell with diffs of diffs Jul 21 08:50:33 RP: it's mostly the same. The idea is to put startPage = startOffset; inside the 'startOffset > startPage' condition. It was outside, causing startPage to be changed for all executables. Jul 21 08:51:26 RP: rburton: done on the AB's, feel free to schedule builds Jul 21 08:51:57 ed2: of course, I see now Jul 21 08:52:18 ed2: I think that does make sense Jul 21 08:52:25 joshuagl: thanks! Jul 21 08:52:44 RP: great. I'll send it for review then. Jul 21 08:52:48 RP: thank you Jul 21 08:52:50 ed2: might be worth adding this patch to the github site, they did take my last patch too! Jul 21 08:53:05 ed2: well spotted finding that :) Jul 21 08:53:07 RP: yep, will send it upstream too. Jul 21 08:54:11 RP: thanks. this kind of things are easily overlooked. Took me some time to find it out :) Jul 21 08:55:52 joshuagl: is wic test failure still relevant. My build is still going, so I didn't check it out yet. Jul 21 08:55:59 joshuagl: ? Jul 21 08:56:09 ed2: still relevant, yes Jul 21 09:01:57 ed2: reproducing it may be hard :( Jul 21 09:04:18 RP: true. we're lucky it's 100% reproducible on our m4 executable linked with gold Jul 21 09:12:28 RP: btw, did we try to test build performance for ld vs gold? according to what people say gold is much faster. Jul 21 09:13:37 RP: looks like changing TARGET_VENDOR is also a dead-end. It is passed to configure as --target=x86_64-refkit-x11-linux and thus changes sstate signatures even in recipes which do not depend on the distro feature. Jul 21 09:17:24 I'm coming to the conclusion that different TMPDIR is the only viable approach. It also gets rid of conflicts in the deploy package feeds. Jul 21 09:20:06 RP: but then what about BUILDSTATS_BASE, as used by buildstats-summary.bbclass? Does that need to use a TMPDIR that is the same for all multiconfigs? Currently it doesn't. Jul 21 09:23:42 joshuagl: RP: I can't reproduce wic.Wic.test_fs_types on my machine. Used the same poky commit & machine. Jul 21 09:33:38 ed2: hmm, I had a feeling that one might be tricky/rare :/ Jul 21 09:33:46 pohly: good question :/ Jul 21 09:34:03 pohly: this is why I ended up with separate events Jul 21 09:35:20 RP: I think buildstats are per-build, and thus need to be independent of the TMPDIR used by each individual multiconfig. Jul 21 09:37:50 buildstats.bbclass hard-codes BUILDSTATS_BASE, so it cannot even be configured easily in a local.conf where BBMULTICONF is set. I'm now using BUILDSTATS_BASE_forcevariable = "${TOPDIR}/tmp/buildstats". Jul 21 09:45:51 pohly: that does sound like the correct implementation Jul 21 09:58:19 RP: however, there's a namespacing issue: the directories in ${BUILDSTATS_BASE} do not include the BB_CURRENT_MC prefix, so different variants overwrite each other's files. Jul 21 10:00:19 But I still think a single BUILDSTATS_BASE is the right solution. For example, the system monitor .log files only get written in the main build configuration. Jul 21 10:06:07 pohly: hmm, I'm torn on this to be honest... Jul 21 10:08:35 If it is per multiconfig, then pybootchartgui becomes less useful because it only shows a subset of what really went on. Jul 21 10:09:18 I'm not familiar enough with buildstats-diff to determine which approach would be better. Jul 21 10:10:31 pohly: you can run pybootchartgui on a set of directories iirc Jul 21 10:12:31 RP: then we have the name clash in the UI. Jul 21 10:13:30 pohly: hmm, true Jul 21 10:13:52 pohly: I did write http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip5&id=917beaeecc83798e4853fceaafc09aeb87c17158 Jul 21 10:14:11 Speaking of pybootchartgui, it's complaining here with "empty state: ... does not contain a valid bootchart" even for the single directory case. Jul 21 10:14:30 Perhaps it doesn't like short builds with only setscene tasks? Not sure. Jul 21 10:14:52 pohly: could be. sstate works better now than when it was originally written :) Jul 21 10:17:29 RP: about that patch: the terminology is getting confusing. The comment "Event fired once per multiconfig build completion" for MultiConfigBuildCompleted to me sounds more like "fired once for each of the multiconfigs", i.e. more than once per "bitbake" invocation. Jul 21 10:17:56 But it's the other way around, BuildCompleted fires more than once and MultiConfigBuildCompleted exactly once. Jul 21 10:18:54 We probably need a term for the building of a particular variant. Jul 21 10:19:52 Then we can define "multiconfig build" = "a build where BBMULTICONFIG is set, ends when all variants are built -> MultiConfigBuildCompleted". Jul 21 10:20:37 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip5&id=84954acf84fef77a613c83c8d309addf83875a3e better ? Jul 21 10:21:08 Yes, that's better. Jul 21 10:22:43 Hi, how can run bitbake to show echo's from do_install functions in bb files Jul 21 10:22:52 Hi. I'm new to yocto and learning while I try to build a image for my CHIP Pro board. I have followed the guide from the Link, and I now have a login prompt from my CHIP pro. If I type root in the login prompt it gives "Login incorrect". I have looked at the rootfs tar file and can see a passwd file in the etc folder, but there is no shadow file? My question: is there some way of telling yocto NOT to include Jul 21 10:22:58 a shadow file? Jul 21 10:23:01 Link: https://github.com/texierp/meta-chip Jul 21 10:23:02 However, """Event when builds have completed (one event per multiconfig)""" for BuildCompleted is not quite correct in the current implementation. An event handler that registers for BuildCompleted will be invoked twice in a normal build, once for bb.event.BuildCompleted and once for MultiConfigBuildCompleted. Jul 21 10:23:02 MarcWe: use bbwarn instead of echo Jul 21 10:23:08 a oke Jul 21 10:23:10 tnx Jul 21 10:23:10 MarcWe: you should be able to see them in the WORKDIR/temp/log.do_install file Jul 21 10:23:33 tnx Jul 21 10:24:21 pohly: hmm, I guess I need to split that base class :( Jul 21 10:24:25 RP: to avoid that, we probably need a "class BuildCompletedBase" with the current BuildCompleted code and two leaf classes. Jul 21 10:24:39 pohly: yes, how ugly :( Jul 21 10:26:11 pohly: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip5&id=6c5f525e34e9a424f749ed29acccb3478b64372f Jul 21 10:27:55 pohly: well spotted though thanks Jul 21 11:03:08 rburton: this patch seems to be forgotten: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139389.html Jul 21 11:03:33 rburton: I don't see it in any of pre-branches (checked master-next, ross/mut, ross/mut2) Jul 21 11:07:21 rburton: and unlucky /boot patchset too: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138802.html (this fixes M2 Medium+ bug) Jul 21 11:07:33 thanks ed2, sorry about that Jul 21 11:08:07 rburton: no prob, just wanted to point out Jul 21 11:08:39 RP: did you see ed2 sent a patchelf patch? Jul 21 11:09:55 rburton: we talked about it earlier, looks good to me Jul 21 11:10:12 cool Jul 21 11:10:35 ed2: Isn't the status there submitted? Jul 21 11:39:07 rburton: I tracked that mesa failure to the vulkan distro change. I've therefore added mut to -next minus that and will see how that build goes Jul 21 12:11:20 RP: sent v2. thanks for pointing it out. Jul 21 12:15:06 RP: +1 Jul 21 12:20:22 ed2: "runqemu: rework of exception handling" is already in master. merged the rootfs changes to mut now. Jul 21 12:20:38 rburton: gstreamer is moving to meson too, so I'm not at all interested in sending them our pending patches, which are all fixing stuff in autotools. Fair enough? :) Jul 21 12:20:46 yeah :) Jul 21 12:20:55 kanavin: now you're back... Jul 21 12:21:02 want to play "how to make meson build gtk-doc" Jul 21 12:21:03 :) Jul 21 12:21:50 meson has built in support for "i need this command to run a target binary", so in theory if we set that and then tell meson to use that when it invokes stuff it builds, it should just work and all be upstreamable Jul 21 12:22:11 (or g-i but i suspect gtkdoc is the easier case to start with) Jul 21 12:22:37 rburton: I have never used meson before (but I bloody should) Jul 21 12:22:59 just seeing if all my patches to the class/recipe in meta-oe have landed now Jul 21 12:23:15 theres a ross/meson in poky-contrib which has some relevant work in too Jul 21 12:23:37 rburton: just reading the meson's developer post called "why autotools is not my favorite build system". He has a finnish name btw, Jussi Pakkanen. Jul 21 12:24:23 yeah, i'm pretty sure i've worked near him in the past. then again about 80% of finnish engineers worked at nokia... Jul 21 12:24:48 rburton: the remaining 20% worked for nokia subcontractors Jul 21 12:25:29 his linkedin doesn't have any nokia contractors in :O Jul 21 12:43:21 kergoth: I got the Python script I wanted to use to execute. Then I found out it was not updated for Pi3 so I am working with the author to get the GitHub code tested and updated with a pull request someone else made that seems to have Pi3 support. Then he can push it to pypi and I can make a further recipie update to get the new version. Jul 21 12:44:53 kergoth: Then I can get the image build, on my Pi and I'll finally be able to turn and LED on and off via the GPIO. Simples. Thank you for your help yesterday. I'll commit an updated recipie file that fixed the missing python dependencies soon. Jul 21 12:55:01 ed2: props for the patchelf debugging Jul 21 12:55:37 rburton: I'll spend some time playing with meson next week. Right now my daily rhythm is seriously crooked :-/ Jul 21 12:55:53 (which is something of a lifetime struggle :( Jul 21 12:56:19 kanavin: sure, no problem. the irc channel is friendly and i've a few more patches building up for meta-oe Jul 21 13:06:18 rburton: I better stop trying to do mentally intense work, and tidy up the apartment instead :D Jul 21 13:07:36 rburton: thanks. it was interesting challenge Jul 21 13:08:19 ed2: made it seem easy :) Jul 21 13:08:41 * Tartarus hopes over here Jul 21 13:09:08 pohly: ping when you're around again Jul 21 13:09:56 Tartarus: hi. I'm around briefly - was about to run an errand. Jul 21 13:10:20 pohly: k. So, as I was saying on the ML, I'm not convinced we need to push vmdk stuff in a different direction Jul 21 13:10:30 I was telling RP over in #oe that we do use vmdk/etc as distinct types Jul 21 13:10:46 ie in AGL we build the various target images as vmdk and pass them to qemu/vmware/virtualbox Jul 21 13:11:44 Tartarus: pohly: +1 for making vmdk a conversion type. Jul 21 13:12:40 Tartarus: so did we with Ostro. But we didn't want to be limited to images created with the image-vm.bbclass, and therefore introduced the conversion command. Jul 21 13:12:58 * RP moves his conversation here Jul 21 13:13:11 It's simply more flexible that way. The conversion is always the same, just the base raw image isn't. Jul 21 13:13:26 I can see this from both sides. The current approach is rather hardcoded and less flexible and I can see why it could be difficult to use Jul 21 13:13:29 Yeah, I can see how being able to use vmdk as a conversion too is useful Jul 21 13:13:53 Tartarus: also note that you don't need to keep the intermediate raw image if you don't want - the current code already throws it away if its not listed separately in IMAGE_FSTYPES. Jul 21 13:14:17 pohly: The current code does not throw away hdddirects Jul 21 13:14:29 Hi all. I am relatively new to Yocto (moving from buildroot). I have a layer (meta-xilinx) that generates a devicetree file with a horrendous name. Is it possible to create another layer that I apply that renames it something more manageable? Jul 21 13:14:35 (ok, unless something changed somewhat recently, I did this initially vs morty, I'm bad, just testing it a bit now vs master) Jul 21 13:14:54 Tartarus: what I meant is that if you ask for foo.vmdk, the "foo" image will be deleted once foo.vmdk is produced. Jul 21 13:15:29 pohly: Er, again, unless things changed for pyro/master, we have the foo.ext4 and foo.hdddirects around Jul 21 13:15:35 but some of the intermediate bits do get nuked Jul 21 13:17:02 Tartarus: I think we are talking about different things. What I have in mind is the solution where image-vm.bbclass is responsible for creating a .hddirect image, and nothing else. Jul 21 13:17:24 Then a conversion commands produces .hddirect.vmdk. Jul 21 13:17:49 When a user selects IMAGE_FSTYPES = hddirect.vmdk, that's all that will be in the image deploy directory. Jul 21 13:18:05 pohly: Right. I don't think that's quite the right direction Jul 21 13:18:21 It's not obvious that users want "hdddirect.foo" to get something for $VM to use Jul 21 13:18:31 vmdk is a distinct known type Jul 21 13:18:54 How we implement that under the hood, yes, we need to allow for converting anything, easily, to vmdk/etc Jul 21 13:19:08 wic.vmdk/wic.qcow2/etc should happen, I agree Jul 21 13:19:39 Tartarus: so you are arguing that IMAGE_FSTYPES = vmdk is a thing (= hddirect converted to vmdk format), and that has to be kept. Right? Jul 21 13:19:46 pohly: Yes Jul 21 13:19:57 vmdk/qcow2 are well known types Jul 21 13:20:53 RP: does this look like something related to those bitbake changes? it's build I haven't run for a while and today it fails with: Jul 21 13:20:56 ERROR: Failed to spawn fakeroot worker to run /OE/build/owpb/webos-ports/meta-qt5/recipes-qt/qt5/qtxmlpatterns_git.bb:do_install_ptest: [Errno 2] No such file or directory: '/OE/build/owpb/webos-ports/tmp-glibc/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo' Jul 21 13:21:09 I get your point. I'm just not sure how important it is to preserve that. To me it seems more like an accident how these types were implemented initially. Jul 21 13:21:30 pohly: I disagree it being an accident Jul 21 13:21:41 vmdk is an image type Jul 21 13:21:46 Just like ext4 is an image type Jul 21 13:21:54 These are known quantities outside of the OE world Jul 21 13:22:02 When was vmdk introduced? Jul 21 13:22:10 googling Jul 21 13:22:20 RP: also shouldn't bitbake-cookerdaemon.log be in tmp-glibc/log? or it cannot be inside tmp-glibc? Jul 21 13:22:43 hmm, wikipedia doesn't say Jul 21 13:22:48 I mean, in OE-core. Jul 21 13:22:59 pohly: I think very long time ago Jul 21 13:23:02 90% sure it predates oe-core Jul 21 13:23:03 JaMa: good question. I just inherited the memres logging so its actually always been there for memres. Our logging needs a huge overhaul Jul 21 13:23:09 I know image-vm talks about 2004 Jul 21 13:23:17 But that might have been iso stuff Jul 21 13:23:24 with the later VM conversions added on top late Jul 21 13:23:25 r Jul 21 13:23:39 RP: I'm just asking because I was reading the cooker logs in tmp-glibc/log/cooker/ Jul 21 13:23:44 My problem with a user from outside OE coming and asking for "a vmdk image" is that it's completely underspecified. Jul 21 13:23:50 What should be inside the image? Jul 21 13:24:02 pohly: I again disagree Jul 21 13:24:16 A user coming from outside of OE and asking for a vmdk image of core-image-sato knows exactly what they're asking for Jul 21 13:24:30 Tartarus: .hdddirect.vmdk looks more informative than .vmdk to me. Jul 21 13:24:32 they're expecting a vmdk file they can throw at vmware/etc that will boot up and have core-image-sato running Jul 21 13:24:52 Do they want an image that can install itself? Jul 21 13:25:01 Because that's what they are getting. Jul 21 13:25:09 What do you mean install itself? Jul 21 13:25:15 Including all the extra baggage that comes with that. Jul 21 13:25:32 They're getting a disk image that can be used with a virtual machine Jul 21 13:25:36 Tartarus: hddimg includes an enhanced initramfs that can partition disks and copy the rootfs to the new disk. Jul 21 13:25:43 ed2: It's informative in that it's exposing OE internals, yes Jul 21 13:25:51 Tartarus: they get more than that. Jul 21 13:25:58 If they don't care, fine. Jul 21 13:25:59 pohly: hddimg != hdddirect Jul 21 13:26:24 That's another one of the internal things that we should sort out, we have too many ways to say "make a raw disk image" Jul 21 13:26:36 Tartarus: it's exposing type of the image. This is what pohly is also pointing out to, I believe. Jul 21 13:26:59 Tartarus: hdddirect.vmdk can be quite different to wic.vmdk Jul 21 13:27:21 Tartarus: which some users may prefer, btw. Jul 21 13:27:46 ed2: I agree that wic.vmdk should be a thing that's allowed to happen Jul 21 13:28:44 But I still think that we need to allow for users to just say "I want an image I can throw at my virtual machine" and that internals like "hdddirect" or "hddimg" are not going to lead to a better experience in that regard Jul 21 13:28:53 Tartarus: it's quite possible that I have confused the live image with hdddirect. I've hardly ever used either of them. Jul 21 13:28:57 Tartarus: My point is that .vmdk is more flexible and more informative than .vmdk as it gives user a choice of image. Jul 21 13:29:21 Tartarus: current .vmdk hides underlying type and forces it. Jul 21 13:30:15 Tartarus: anyway, I don't mind keeping "vmdk/vdi/qcow2" around as distinct types. I'm just worried that it'll make the code more complicated - but that remains to be seen. Jul 21 13:30:34 pohly: I'm attempting to see if we can add a conversion trivially atm Jul 21 13:30:47 ed2: Yes, I agree it does force a certain base type of "disk" onto the user Jul 21 13:31:10 I also don't think that hdddirect is necessarily the best starting point for such a type. It's mostly legacy code that has been superseeded by wic. Jul 21 13:31:36 But I need to go now... Jul 21 13:33:28 ok Jul 21 13:33:45 * Tartarus fixes thinko, gets to the point of seeing if we can easily have vmdk and wic.vmdk Jul 21 13:34:06 Good news is it's not failing early and obvious Jul 21 13:34:15 bad news I need a few min to build all of the new deps that wic.vmdk is adding in Jul 21 13:34:38 Does wic default to something that supports BIOS rather than EFI? Jul 21 13:34:48 or at least both? Jul 21 13:35:07 Tartarus: it depends on which .wks config is used. Jul 21 13:35:20 Tartarus: it supports both Jul 21 13:35:59 Tartarus: even both at the same time sometimes Jul 21 13:36:28 ed2: My first hope for an outright "vmdk now is just doing wic.vmdk, really" would be function-for-functionl replacement Jul 21 13:36:33 Tartarus: it doesn't support initfs directly though, so if you need to load some disk modules it'd not be trivial to do. Jul 21 13:36:57 ie if qemux86-64 is going to spit out a wic.vmdk that still just works on qemu/vmware/virtual box, just as well as it would have before and the user doesn't care, then I don't care :) Jul 21 13:37:28 Otherwise I'd like to go with vmdk does what it does today, and wic.vmdk is now a real thing that exists too Jul 21 13:37:33 but is not a direct replacement of Jul 21 13:38:08 Tartarus: I thought hddimg.vmdk is a direct replacement, no? Jul 21 13:38:20 Tartarus: wic is a different beast. Jul 21 13:38:23 ed2: s/hddimg/hdddirect/ would be Jul 21 13:38:34 But gets back to exposing pointless details to the end user Jul 21 13:38:45 Nobody knows what hdddirect is Jul 21 13:38:47 Tartarus: no it's not :) Jul 21 13:38:56 Fine, I'm arguing it's a pointless detail :) Jul 21 13:39:04 Tartarus: it's a valuable detail from my point of view. Jul 21 13:39:28 Tartarus: especially when other underlying types support vmdk conversion Jul 21 13:39:56 Tartarus: the fact that they don't exist yet doesn't make the solution worse Jul 21 13:41:08 Tartarus: and as a programmer I'd love to see one .bbclass removed and replaced by couple of lines introducing vmdk conversion Jul 21 13:42:00 Tartarus: however, I udnerstand that it would not be easy to achieve. probably … Jul 21 13:42:10 ed2: Well, lets start with this. What do I need to do, to get core-image-minimal.wic for qemux86-64 to be functionally equivalent to core-image-minimal.vmdk, today? Jul 21 13:42:19 On just oe-core Jul 21 13:42:39 (which is why I started this over in #oe ;)) Jul 21 13:44:09 Tartarus: I don't know which functionality is provided by vmdk. What kind of image is it? Jul 21 13:45:24 ed2: It's an at least PCBIOS bootable disk image, with syslinux Jul 21 13:45:53 Tartarus: how is it different from hddimg? Jul 21 13:46:29 Lets see Jul 21 13:47:24 ed2: It looks like hddimg forces us to shove something into FAT? Jul 21 13:47:31 Tartarus: I'd start from hddirect.vmdk. It should be easier to make it workin. Jul 21 13:47:41 ed2: hdddirect will have an arbitrary ext4 (default) second partition and fat first partition Jul 21 13:50:06 Tartarus: so, if you add conversion types vmdk, gcow and vdi would you be able to build working hddirect.[vmdk, gcow, vdi] image without using image-vm.bbclass ? Jul 21 13:50:45 ed2: No, because image-vm.bbclass is where we have the logic for hdddirect Jul 21 13:52:03 Tartarus: ah, ok. If you move that logic to image_types_hdddirect.bbclass and add 3 conversion types would it be cleaner solution than current one? Jul 21 13:52:18 ed2: Take a look at the patches I posted please Jul 21 13:52:38 And then yes, a follow up could be a rename of image-vm to image_types_vm Jul 21 13:54:55 Tartarus: I did. This is not what I'm talking about. Jul 21 13:55:46 Tartarus: I'm talking about getting rid of main image types vmdk, gcow, vdi and replacing them with conversion types. Jul 21 13:56:01 Tartarus: and this is not what your patchset does. Jul 21 13:57:10 If that is in place the next step would be to look at wic Jul 21 13:57:24 ed2: What my patch does is 90% of that however Jul 21 13:57:41 Since the hard part isn't making vmdk being a conversion type Jul 21 13:57:52 it's about making it still easy on end users to get what the expect Jul 21 13:58:07 And if we're lucky we can get dir of hddirect image type. However, I'm not expecting it to be easy. At least for now. Jul 21 13:58:20 ed2: So, lets cycle back to my question Jul 21 13:58:27 If I build core-image-minimal.wic Jul 21 13:58:33 For qemux86-64 Jul 21 13:58:48 Am I going to get something that'll just run, easily, on qemu/vmware/virtualbox? Jul 21 13:59:08 yes for qemu Jul 21 13:59:20 didn't try to run it on vmware/virtualbox Jul 21 13:59:35 runqemu script supports wic out of the box. Jul 21 13:59:54 Not runqemu so much as users with qemu ;) Jul 21 13:59:58 But, yes, OK, documentation Jul 21 14:01:00 runqemu is just a wrapper around qemu I believe Jul 21 14:01:48 Yeah, it buries various bits of logic Jul 21 14:02:08 But if wic is spitting out a functional disk image, it should just be seen as a raw disk Jul 21 14:03:11 yes, qemu runs it as a raw disk Jul 21 14:04:13 OK, seeing what vmware/vbox do with core-image-minimal.wic Jul 21 14:04:21 And then I'll move forward from that :) Jul 21 14:22:01 Tartarus: one more thing that I found confusing is that hdddirect seems to be not related to vm. please, correct me if I'm wrong here. Jul 21 14:22:30 ed2: No, it would make more sense as .raw rather than .hdddirect Jul 21 14:22:42 As it was initially for raw disk images / ISOs Jul 21 14:22:48 And VM got bolted on ages and ages ago Jul 21 14:23:01 ed2: FWIW, maybe we can just go with .wic.vmdk Jul 21 14:23:28 Tartarus: exactly. That's why it's underlying image type unlike vmdk, qcov and vdi Jul 21 14:23:29 I still want to see if we can hide the "wic" part to normal users in some ways Jul 21 14:24:10 My tester is reminding me that he wouldn't have any clue what wic means, were it not for some other JIRA issues he's been reading over of late Jul 21 14:25:14 Tartarus: we shouldn't hide it :) It gives user opportunity to tweak it using different .wks entries: have more partitions, support EFI, use different filesystems etc. Jul 21 14:25:51 ed2: IMAGE_FSTYPES += "wic.vmdk.xz" is not user friendly Jul 21 14:26:19 What is wic? Jul 21 14:26:31 Tartarus: why not? Pretty clear explains what's inside. Jul 21 14:26:56 To OE people, sure Jul 21 14:27:50 Tartarus: for oe users as well. for external users you can rename it if you want. Jul 21 14:28:34 Tartarus: directdisk or hdddisk are not very self-explanatory too, btw. Jul 21 14:28:57 Agreed Jul 21 14:28:59 raw would be Jul 21 14:29:35 Tartarus: vmdk is just an image format. it doesn't tell anything about the structure or content of the image. Jul 21 14:30:08 ed2: I fear we're just going to go round and round on that part Jul 21 14:30:34 "core-image-minimal.vmdk" tells the user what they expect to know, "core-image-minimal.wic.vmdk" tells the user more or less the same thing Jul 21 14:30:42 except some people will know what wic means and some will not Jul 21 14:30:45 Tartarus: yes, agree. I think we've got each other points, jus don't agree. That's ok. Jul 21 14:30:55 For the moment I'm going to see why I have wic.vmdk spitting out Jul 21 14:30:58 but nto wic.vmdk.xz Jul 21 14:32:27 Tartarus: raw doesn't tell much about image structure(partitions, filesystems), btw. Jul 21 14:32:44 ed2: No, but it says it's a raw image :) Jul 21 14:33:14 raw disk image, people know that it's a raw disk image to poke at using usual tools Jul 21 14:33:40 grrr Jul 21 14:33:50 We are allowed normally to stack conversion/compression types, yes? Jul 21 14:33:56 Tartarus: yep, and pretty much can be called raw image. It doesn't matter if it's partitioned or not, has efi or syslinux, ext4 or btrfs partitions. Jul 21 14:34:27 Tartarus: yes, it's allowed to chain conversion types. Jul 21 14:34:56 ok Jul 21 14:34:57 hmm Jul 21 14:35:04 Tartarus: raw doesn't tell user if the image contains installer either. Jul 21 14:35:22 ed2: No, image name should be telling the user if it's something that installs Jul 21 14:35:35 Since that's extremely image context dependent Jul 21 14:36:40 Tartarus: it should, but it doesn't. core-mage-minimal only tells you about rootfs content. Jul 21 14:36:51 Right Jul 21 14:37:01 Or maybe let me try a different path Jul 21 14:37:26 Why would images be able to "install" unless someone was very explicit about that being a use case they had? Jul 21 14:37:44 I'd be quite unhappy if suddenly my images could "install" Jul 21 14:37:59 when that's not anything I want them to be anywhere near as that's nonsense Jul 21 14:41:39 ed2: No, I'm not seeing arbitrary stacking Jul 21 14:42:21 * Tartarus pokes stuff harder to see whats up Jul 21 14:43:19 Tartarus: sorry, I don't follow. arbitrary stacking of what? Jul 21 14:43:31 ed2: Compression / conversion Jul 21 14:43:38 ie I can't do ext3.gz.bz2 Jul 21 14:43:41 Nor wic.vmdk.xz Jul 21 14:44:00 Tartarus: looks like a bug to me. Jul 21 14:46:25 Tartarus: I remember pohly implemented it some time ago. Jul 21 14:46:52 pohly: back yet? Jul 21 14:47:28 Tartarus: just tried to build wic.gz.xz and it built only wic. Looks like it either didn't build compressed types or removed them. Jul 21 14:47:59 Yeah, I don't think it's building them even :( Jul 21 14:48:07 When did this work last roughly? Jul 21 14:51:18 hard to say. I only saw it implemented. Didn't test it. Jul 21 14:55:14 OK, fun times :) Jul 21 14:55:20 * Tartarus prepares to kick things around Jul 21 14:55:37 ed2, was it in 2017 or 2016? :) Jul 21 15:01:14 Tartarus: commit ba57ba1942546045907a7e1831515ad2da420ab2 Jul 21 15:01:14 Author: Patrick Ohly Jul 21 15:01:14 Date: Mon Mar 7 15:51:14 2016 +0100 Jul 21 15:01:14 image.bbclass: support chaining compression (aka conversion) commands Jul 21 15:02:42 ed2, Tartarus: it definitely used to work. But I've not been involved in further changes to the code, so I can't say anything about the current state of affairs. Jul 21 15:03:01 Ug, ok Jul 21 15:03:10 what bitbake version do I even need for that Jul 21 15:03:38 Double ugh, lemme grab a yocto.. Jul 21 15:03:38 pohly: some tests would ensure it works, I believe :) Jul 21 15:04:16 Tartarus: you don't need to grab a Yocto just for that. Jul 21 15:04:26 ed2: Yeah, found oe core rev Jul 21 15:04:27 ed2: I've learned about oe-selftest only later... but yeah, some tests would be needed. Jul 21 15:04:43 Tartarus: git log |grep "support chaining compression" Jul 21 15:04:46 I've heard rumors of a QA team adding tests after developers have implemented features... Jul 21 15:05:01 ... but I guess it's better to not rely on that. Jul 21 15:05:55 OK, found an old bitbake version Jul 21 15:06:59 Tartarus: just file a bug. You don't need this right now. wic.vmdk would work if you define vmdk conversion. Jul 21 15:07:01 confirming it did work then, then let the bisect begin Jul 21 15:07:12 ed2: I need compressed vmdk upstream Jul 21 15:08:19 ed2: Do you have any hints on where to poke things to have wic change from passing root=/dev/sda2 to passing root=PARTUUID=${@generated_disk_signature()} or there-abouts ? Jul 21 15:08:33 That's that other thing to make these images easily passable between VMs Jul 21 15:11:24 Tartarus: http://lists.openembedded.org/pipermail/openembedded-core/2015-June/105759.html Jul 21 15:11:57 ed2: ... OK, and then to make that be the default used for a board? Jul 21 15:12:28 Tartarus: it depens on the board/machine. Jul 21 15:12:47 ed2: Well, the default seems to be sda2 Jul 21 15:12:58 Based on what's coming up as waiting for ..., when testing these wic images in VMs Jul 21 15:13:16 Ugh Jul 21 15:13:17 I see Jul 21 15:13:28 Tartarus: it's specified in wks. here is an example: http://lists.openembedded.org/pipermail/openembedded-core/2016-October/127948.html Jul 21 15:13:31 ed2: Is there a reason we're not defaulting to PARTUUID for these canned things? Jul 21 15:13:52 scripts/lib/wic/canned-wks/directdisk-bootloader-config.cfg and scripts/lib/wic/canned-wks/qemux86-directdisk.wks Jul 21 15:13:57 shouldn't default to sda Jul 21 15:15:16 well 1st thing is legacy. 2nd - I prefer to have wic configs in layers as there you can be more specific with its content. Jul 21 15:15:46 3rd - directdisk is not efi image. it uses mbr and partuuids for mbr are a bit unusual. Jul 21 15:16:04 ed2: Legacy what? Jul 21 15:16:16 Everything as PARTUUID Jul 21 15:16:20 s/as/has/ Jul 21 15:16:35 MBR ones are just not awesome ones Jul 21 15:16:38 But they're valid Jul 21 15:17:16 meta/classes/image-vm.bbclass even makes better-than-normal ones for MBR Jul 21 15:18:39 Tartarus: wic also supports them. I was just afraid of adding them to canned wks as they're widely used. Jul 21 15:18:58 ed2: PARTUUID is part of the kernel, has been for forever Jul 21 15:19:03 someone asked me about this here couple of months ago. Jul 21 15:19:05 uuid does sound a like a hell of a lot better default Jul 21 15:19:12 That's why we use them by default in U-Boot whenever we can Jul 21 15:19:16 Can't rely on kernel ordering Jul 21 15:19:24 and promised to send a patch :) Jul 21 15:19:26 can't rely on sdX vs hdX Jul 21 15:19:45 refkit-image-common-intel-corei7-64-20170721150939.wic.xz was just created fine for me. Jul 21 15:19:46 ed2: So where would I need to start kicking things to move those to use --use-uuid by default? Jul 21 15:19:56 pohly: Yes, but that's not stacking Jul 21 15:20:03 pohly: wic.gz.xz will fail Jul 21 15:20:06 pohly: wic.xz is using one conversion type Jul 21 15:20:13 Okay, just one level. Right, you wanted more. Jul 21 15:20:14 pohly: We got there since it's "trivial" to get wic.vmdk going Jul 21 15:20:21 with vmdk as conversion typ Jul 21 15:20:21 e Jul 21 15:20:47 i kind of hate IMAGE_CMD and all of that, the use of bitbake variables is a bit silly, we should have just used shell functions that accept arguments Jul 21 15:20:54 Jul 21 15:21:40 Tartarus: if you think this change is harmless - just send a patch. if you want to be careful you can start from discussing it on architecture mailing list and then send a patch. Jul 21 15:22:07 ed2: Patch to what? root=/dev/sda2 is in a bunch of places Jul 21 15:22:11 Do I just need to drop those? Jul 21 15:22:39 It's jsut automatic insertion? Jul 21 15:23:16 it's automatic as far as I remember. just use —use-uuid for root Jul 21 15:23:27 for root partition Jul 21 15:23:28 Right-o Jul 21 15:23:56 Indeed, wic.xz.sha1sum no longer works. Jul 21 15:24:05 ed2: are you going to file a bug? Jul 21 15:25:41 pohly: I proposed Tartarus to do that :) Jul 21 15:25:51 Tartarus: can you? Jul 21 15:25:54 I'm attempting a bisect atm Jul 21 15:27:51 Tartarus: —ondisk=sda should be removed as well. it's not mandatory, but less confusing. Jul 21 15:28:06 ok Jul 21 15:29:00 Tartarus: did you try if wic.vmdk is functional under vmware? Jul 21 15:29:17 ed2: Yes, wic.vmdk functioned, aside from root= 'issues' Jul 21 15:29:26 as in, need to make sure to pass the right bits so it shows up as scsi Jul 21 15:30:05 Tartarus: that's what I expected. you'd need initfs for ide drivers or include them into kernel. Jul 21 15:30:40 Tartarus: how does it work with current .vmdk images? does they work for all disk drive types? Jul 21 15:30:42 ed2: Kernel should be as functional as ever Jul 21 15:30:58 ed2: They 'just work', once the PARTUUID bit is passed in Jul 21 15:31:05 my coworker with the setup is helping his MIL atm Jul 21 15:32:13 Tartarus: hm, intersting. Someone told me that only scsi disk drive is supported. I didn't try it myself though. Jul 21 15:32:29 ed2: Yes, I think that's part of the fun Jul 21 15:59:59 Starting maintenance on main AB. Jul 21 16:21:39 Main AB ready for use. Jul 21 16:24:30 Can't see why in meta-qt5 layer qtchooser is not native ant thus doesn't populate sysroot with /usr/bin/*. Anyone, what I'm missing? Jul 21 16:30:27 Wow, been broken for a long time it looks like :( Jul 21 16:30:29 * Tartarus continues the bisect Jul 21 16:31:35 clown_: per recipe sysroot unfun and you're missing DEPENDS ? Jul 21 16:32:28 * Tartarus gets on with zucchini bread making, idly wonders where the (ex)Mentor folks are that would appreciate bread talk Jul 21 16:38:36 Tartarus: I have DEPENDS on qtchooser. But qchooser:do_populate_sysroot don't care about /usr/bin at all. Do you think it's a bug, or I'm wearing a shoe on my head? Jul 21 16:40:41 clown_: DEPENDS += qtchoser-native ? Jul 21 16:43:41 Tartarus: ...and a complimentary qtchooser-native.bbappend, I recon? Jul 21 16:43:56 errr Jul 21 16:44:20 qtchooser_...bb should BBCLASSEXTENDS native or whatever the right syntax is Jul 21 16:44:41 And if some qt5 class doesn't already say you DEPENDS on qtchooser-native Jul 21 16:44:43 Your recipe should Jul 21 16:44:50 I don't do qt enough to know if that's a common tool or not, sorry Jul 21 16:46:14 Tartarus: yes, that was the original issue. qtchooser does not BBCLASSEXTEND native. Ignore any garbage I said after that Jul 21 16:46:49 ah, kk :) Jul 21 19:06:32 hello! i'm having issues with 'testimage'. i've added 'INHERIT += testimage' to conf/local.conf, among other test-related options, and run `bitbake core-image-sato-sdk -c testimage -v` which yields an error that asks `Have you built the image with INHERIT+="testimage" in the conf/local.conf?` Jul 21 19:06:53 since 'INHERIT += testimage' is indeed in conf/local.conf, i don't know how to interpret or act on the error message Jul 21 19:16:09 garbados: make sure core-image-sato-sdk has been built already, so no -c testimage Jul 21 19:16:23 garbados: with 'INHERIT += testimage' still in local.conf Jul 21 19:17:13 clsulliv, thanks, i'll try that :) Jul 21 19:29:41 Down to 7 steps to go Jul 21 20:19:43 clsulliv, hey, that got me to a different error! thanks for your help getting out of one jam :) Jul 21 20:20:13 getting these errors now: `core-image-sato-sdk-1.0-r0 do_testimage: Couldn't get ip from qemu command line and runqemu output!` Jul 21 20:21:05 .io AB ready for use. Jul 21 20:21:17 3 steps to go Jul 21 20:21:35 and it's now basically a cleansstate, check, repeat loop, woo Jul 21 20:22:38 garbados, Your VM doesn't have nested KVM enabled. Let me know if you need that for accelerated sanity testing. Jul 21 20:23:16 halstead, KVM? all i'm trying to do is `bitbake core-image-sato-sdk -c testimage -v` Jul 21 20:24:25 garbados, I don't think it should be an issue unless you are working on sanity tests but I wanted to mention it since I saw you here talking about qemu. Jul 21 20:27:05 i'm not quite sure if i'm working on sanity tests. just trying to follow through on steps in yocto guides regarding testing images Jul 21 20:27:42 commit 46bc438374de74af76d288520c6252c9b7840767 Jul 21 20:27:43 Author: Zhenhua Luo Jul 21 20:27:43 Date: Mon Jun 13 19:47:34 2016 +0800 Jul 21 20:27:43 image.bbclass: do exact match for rootfs type Jul 21 20:27:53 Now to think about those changes a bit :) Jul 21 20:33:11 garbados: this is a shot in the dark since I've only done testing on real hardware, but you might need to set the TEST_TARGET_IP variable to your host's IP address Jul 21 20:33:22 could be completely wrong here Jul 21 20:33:56 err, TEST_SERVER_IP Jul 21 20:34:06 target is used for the hardware target IIRC Jul 21 20:35:46 clsulliv, thanks, i'll try that Jul 21 20:38:35 Also, ugh, need to stop making the uboot image stuff second class citizen **** ENDING LOGGING AT Sat Jul 22 03:00:03 2017