[02:47] sabdfl: so you're on this side of the pond now? === ikey is now known as ikey|zzz === JoshStrobl is now known as JoshStrobl|zzz [06:14] good morning [06:15] * zyga-ubuntu does PR pass [06:21] mvo: o/ [06:29] mvo: hey [06:29] mvo: I'm willing to do a deep dive on https://github.com/snapcore/snapd/pull/4030 [06:29] PR #4030: many: add internal squashfuse copy as "snapfuse" [06:29] mvo: unless you are already doing that [06:31] zyga-ubuntu [06:31] that seems like a super-bad idea [06:35] Son_Goku: hey [06:35] Son_Goku: I know [06:35] Son_Goku: but if it's sufficient let's do it the best we can: [06:35] Son_Goku: I'd discard the generated files, discard uneeded code, integrate it into our build system, ete [06:35] Son_Goku: I haven't looked yet, maybe it is huge, maybe it will end up being a handful of files that we can just maintian [06:36] *maintain [06:36] Son_Goku: and good morning :) [06:36] Son_Goku: you're up early, it's barely sunrise here [06:36] I'm about to pass out [06:36] my son is in a new school today [06:36] so I'm working from a coffee shop nearby [06:36] zyga-ubuntu: I think it's a really bad idea to do this at all [06:36] Son_Goku: sure but what is the alternative? [06:37] Son_Goku: if we have to do it, we have to do it [06:37] Son_Goku: we canont just change apt defaults overnight (even though I agree they are bad) [06:37] Son_Goku: those should have been changed years ago [06:37] Son_Goku: but I think that now it is too late for that [06:37] well, if people are updating graphically or using `apt upgrade`, they'd get it [06:38] just fix apt-get upgrade's behavior [06:38] Son_Goku: yes but there is always a set that doesn't [06:38] Son_Goku: I think we've seen that already with snapd before (and we reverted a change that triggered that) [06:38] Son_Goku: it will also be a (I suspect) endless discussion in debian [06:38] Son_Goku: I think it's risky business to go and change that for snapd's sake [06:39] Son_Goku: (I'd still change it but on separate schedules) [06:39] Son_Goku: and once snapd can reliably depend on things, let's yank this [06:39] then don't integrate it into the source tree [06:39] just carry it as a separate tarball bundle [06:39] mmm [06:39] that way it's harder to be lazy about it [06:39] that's interesting, perhaps that's a better idea indeed [06:40] Son_Goku: i'd require some tweaks to CI but yes, it's nicer this way [06:44] zyga-ubuntu: I wish you'd do this with a vendor overlay tarball too [06:44] basically, a tarball that only contains snapd-/vendor/ [06:45] Son_Goku: yes, I think that's a natural place to do this for releases [06:45] Son_Goku: I'll talk to mvo [06:46] this would allow me to ship the snapd-.tar.gz (or in debian parlance, snapd-.orig.tar.gz) and snapd-.vendor.tar.gz in distgit as sources while not using the vendor tarball on Fedora [06:47] which would open the door to adding an EPEL build [06:47] (aka CentOS) [06:47] zyga-ubuntu: a vendor tarball? we can do this easily [06:48] I asked for this a year ago too, btw [06:48] :( [06:48] sorry [06:48] must have forgoten [06:48] the experimental CentOS builds are super-brittle :( [06:49] zyga-ubuntu: incidentally, for your amusement, with literally no expectation of anything working: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/ [06:49] Son_Goku: so snapd_2.28.5.{pristine,vendor}.tar.xz? a [06:49] mvo: yep [06:49] sounds fine with me :D [06:50] ok [06:50] * mvo will update his release script [06:50] mvo: basically, I need the base tarball to be closest to what git repo looks like, otherwise patches don't apply [06:51] mvo: though you don't have to do weird underscores and whatnot :) [06:51] unlike debian, I don't have such restrictions :) [06:51] Son_Goku: heh, ok [06:52] o/ [06:52] it can just be snapd-2.28.5.tar.xz and snapd-2.28.5.vendor.tar.xz [06:53] Son_Goku: ok, I may need to keep the current convention for people using our GH release page, so it might be snapd.vendor-only.tar.xz or I will just annouce the new format and assume that not a lot of people need to adjust their scripts [06:54] sure [06:54] that's fine [06:54] I don't particularly care if you only just upload a vendor-only tarball [06:54] as I can just get the regular one from the GitHub link as I do now [06:54] mvo: I think it's just a handful of people, we'll be fine [06:54] I just need the vendor code in a separate tarball that I can extract [06:56] PR snapd#4047 opened: snap-confine: init all arrays with `= {0,}` [07:08] mvo: .5 looks good so far [07:09] * zyga-ubuntu tweaks details on https://github.com/snapcore/snapd/pull/4008 [07:09] PR #4008: cmd/snap-update-ns: create missing mount points automatically [07:12] zyga-ubuntu: test and give karma for Fedora snapd updates [07:12] they're on 2.28.5 now [07:12] zyga-ubuntu: could you or pawel try to reproduce the error on the pi3 that sergio got? I'm still nervous about it. otoh I have no report other than from sergio about it and would love to get that confirmed [07:19] mvo: I cannot do that today, sorry, I won't be home until after 18 [07:19] mvo: it seems the error cachio got was repeated on >1 SD card he had [07:20] maybe it's just bad luck but it does seem to indicate more than random issue [07:20] Son_Goku: only after I'm home, sorry :/ [07:21] mvo: though my pi3 is still up [07:21] mvo: I could try to test something remotely [07:23] pstolowski: hey [07:23] pstolowski: is your pi3 operational? [07:24] mvo: my pi3-1 is operational, though I cannot reflash it remotely [07:31] zyga-ubuntu, morning! yes, it is [07:31] pstolowski: I think mvo needs a little bit of help and I'm not at my office today [07:31] 09:12 < mvo> zyga-ubuntu: could you or pawel try to reproduce the error on the pi3 that sergio got? I'm still nervous about it. otoh I have no report other [07:31] than from sergio about it and would love to get that confirmed [07:31] pstolowski: I can only run spread tests on pre-installed remotely [07:32] pstolowski: last week cachio ran into a bug where smoehing got corrupted in the boot process [07:32] pstolowski: it might be related to the SD card he was using (he tried two) [07:32] pstolowski: we need hands on testing to see if we can reproduce it [07:35] zyga-ubuntu, sure, happy to help. i need to reflash with latest edge image correct? [07:35] pstolowski: I think so, ideally build the image as cachio did [07:35] * zyga-ubuntu looks [07:36] pstolowski: look at this thread please: https://forum.snapcraft.io/t/snap-mode-try-on-raspberry-pi/2454 [07:38] zyga-ubuntu, k === kira is now known as Guest92109 [07:41] hello got stuck in network configuration can any one please help [07:42] Guest92109: hey, can you please ask a more precise question? [07:42] zyga-ubuntu: Sure [07:42] pstolowski: I commented on the thread with details of what I know [07:42] zyga-ubuntu, thanks [07:42] I got a machine with ubuntu core15.10 [07:43] I need to configure eth0 [07:43] I teied to edit /etc/network/interfaces file but it gives system is read-only message please help [07:46] Guest92109: 15.10 you say [07:46] hmmm [07:46] Guest92109: may I ask if you really want to use 15.10 or can you consider updating to ubuntu core 16? [07:47] zyga-ubuntu, what are the steps to build an image? [07:47] Guest92109: I don't think we support 15.10 anymore (apart from commercial contracts) as it was an early version and ubuntu core 16 has received immense fixes, features and improvements since [07:48] pstolowski: I think you need ubuntu-image and the pi3 model, one sec [07:48] pstolowski: $ sudo ubuntu-image -c beta -O pi3-beta.img pi3.model [07:48]

- I am using dell edge gateway 5000 series which comes with preinstalled snappy core 15.10 and need to configure same [07:49] Guest92109: it used to ship with 15.10 with the desire to update to 16-series, new releases are only using 16; in any case let me try to find someone who can help you [07:50] pstolowski: you need the pi3.model assertion [07:50] pstolowski: cachio sent a link somewhere to a repo with test scripts but I cannot find it [07:50] mvo: do you happen to remember how to fetch the pi3 model file [07:51] Guest92109: I've asked around but I don't know how soon I'll get an answer [07:51] Guest92109: may I suggest that you go to forum.snapcraft.io and ask your question there [07:51] zyga-ubuntu: thanks in advance would be a great help i am not getting any help onlien [07:52] Guest92109: please double check that you cannot upgrade your device to 16 series, then we can all help you easily [07:52] Guest92109: I think 15.10 is not supported anymore (apart from contractual obligations) and everyone is strongly encouraged to go to 16 [07:53] zyga-ubuntu: Sure thanks but can u just answer is the read-only file system also persist in 16 series [07:53] While configuring /etc/network/interfaces file [07:53] Guest92109: yes although network configuration in 16 series is different and much much easier [07:54] Guest92109: apart from a menu-driven wizard we also use declarative YAML based nplan (netplan) configuration [07:54] Guest92109: while the system as a whole is read only the set of writable files is different [07:54] Guest92109: (between 16-series and 15.10) [07:55] kissiel: ^ [07:55] kissiel: I think you are experienced with the dell gateways more than I am [07:56] zyga-ubuntu: Thanks can i get the steps of 16 series, i will get the idea regarding the configuration [07:57] Guest92109: it's a simple process you follow using the on-screen menu (also availale via serial port) [07:57] Guest92109: you can run "console-conf" after initial setup if you wish to change the configuration [07:57] Guest92109: I'd poke around network-manager snap [07:57] kissiel: note, Guest92109 is using 15.10, I'm not sure we still ship that snap for 15.10 [07:57] zyga-ubuntu, pstolowski sorry, was distracted, do you still need the pi3 model assertion ? i [07:58] pstolowski: "snap known --remote model series=16 brand-id=canonical model=pi3" [07:58] zyga-ubuntu: ah, right. maybe joc will know more, I'll ping him when he gets online [07:59] mvo: thank you, I had a copy but I forgot how I got it [07:59] Guest92109: joc is in the UK timezone, he should be around soon [08:01] zyga-ubuntu: Thanks a lot for ur support one last thing how would i know if he comes online [08:02] mvo, zyga-ubuntu thanks! so, I'm going to rebuild the pi3 image, flash it, configure pi3, then add the assertion on it, then run ubuntu-core-upgrade spread test on it in a loop; did i miss anything? [08:03] pstolowski: the assertion is needed to build the image [08:03] ah! [08:03] pstolowski: you need to set up the pi for external backend [08:03] ok [08:03] pstolowski: this is described in tests/external-backend.md [08:04] pstolowski: have a look, you just flash & first-boot as usual [08:04] pstolowski: then run a few scripts [08:04] pstolowski: (from the tree) [08:04] pstolowski: and then you are ready for testing [08:04] pstolowski: ask if you need help, I did this on Friday [08:05] zyga-ubuntu, oh yeah, i know that, just unclear on building the image + assertion part [08:06] pstolowski: yes, what zyga-ubuntu said and good luck [08:06] <__chip__> morning peeps [08:07] __chip__: hello, good morning [08:07] <__chip__> i'm on the road today -- doing admin stuff wrt the boys' schooling [08:07] <__chip__> got my tablet with me (thus the nick) [08:07] __chip__: I'm on the road too, and my son changed school (well, maybe, trial week) [08:07] __chip__: fingers crossed for both of us : [08:07] :) [08:08] <__chip__> zyga-ubuntu: hah. this is about changing schools also (looking into a different school) [08:08] <__chip__> so, yeah, good luck to us [08:08] mvo, zyga-ubuntu ok, all clear, i see where the assertion is needed now, thanks [08:09] mvo: if you want I can keep running that test on my pi3 but I think it depends on SD card model [08:09] mvo: and some models corrput something [08:09] mvo: otherwise why would it never fail vs always fail? [08:10] ok, got the image built, falshing [08:12] zyga-ubuntu: did you build the image yourself when you did the test? or download a pre-made one? maybe its a specific combination of the ubuntu-image cmdline/kernel/gadget or something [08:13] mvo: no, I ran the pre-made one [08:14] mvo: ah, indeed [08:14] mvo: could be! [08:17] <__chip__> pedronis: are you working today? [08:22] morphis: Guest92109 here has a dell gateway with ubuntu 15.10 and need help, can you please try to render assistance? [08:23] * zyga-ubuntu is on the move again, I'll be online in ~~ hour [08:23] ttyl [08:25] Bug #1723881 opened: [Feature Request] Support pre-invoke and post-invoke commands as DPkg::Pre-Invoke and DPkg::Post-Invoke in APT [08:48] Guest92109: hi, i see you had some questions about the 5000 series gateways [08:53] mvo, it failed for me, but with slightly different output http://pastebin.ubuntu.com/25751741/ [08:54] Error: "snap_mode" not defined ? [09:05] mvo, it seems that re-running the test again after the above failure gives another unexpected failure, i assume the box is now in a bad shape and needs re-flashing before attempting tests again? [09:06] pstolowski: looking [09:07] pstolowski: could you please paste the other failure too? [09:07] pstolowski: this is very different from what cachio got, it went much further [09:08] mvo, the other failure after I re-run the tests: http://pastebin.ubuntu.com/25751799/ [09:08] pstolowski: and a different error, I would love to compare the revisions of core/gadget/kernel you have and the revision of ubuntu-image to see where things are different [09:08] mvo, external:ubuntu-core-16-arm-32 .../tests/main/ubuntu-core-upgrade# snap list [09:08] Name Version Rev Developer Notes [09:08] core 16-2.28.5 3214 canonical core [09:08] pi2-kernel 4.4.0.1075.75 43 canonical kernel [09:08] pi3 16.04-0.5 6 canonical gadget [09:09] pstolowski: maybe we can put it into sergios forum post? this way we can compare notes more easily [09:09] sure [09:10] pstolowski: the followup looks indeed just like a test issue with a strange state, might be enough to just "rm curChg" in the debug shell and run again [09:11] pstolowski: thank you, this looks promising, it does not fail in the omg-cant-explain-what-is-going on way at least (which is the case for sergios error, I can't make any sense of it) [09:12] mvo, I hope I didn't miss anything in the setup. will re-try from scratch in a while [09:13] pstolowski: if you could rm curChg and run again, that would be nice [09:14] pstolowski: miss something> well, if its really hard to reproduce it means its not wide-spread at least. i.e. we can't reproduce it with the pre-build images, we can't reproduce the same error with ubuntu-image, so it must be sometihng special [09:14] pstolowski: well, hopefully [09:18] Guest92109: joc is online, you could consult him [09:25] anyone else hitting https://bugs.launchpad.net/snapcraft/+bug/1723898 ? [09:25] Bug #1723898: Unable to build snaps using python plugin - pypi.debian.net no longer accessible [09:25] for the life of me I can't actually figure out where snapcraft is configured to use that [09:26] hrm, hrm, interfaces-cups-control test is busted [09:26] (in debian-unstable) [09:26] re [09:26] (and right on time) [09:28] zyga-ubuntu: heh :) debian-unstable cups control test is busted, that rings a bell, iirc we had artful broken as well recently. anyways, I'm debugging [09:28] kissiel: Thanks [09:29] joc: Hello I have a dell edge geteway with ubuntu 15.10 snappy core [09:30] I am having difficulty in configuring the network using the traditional ubuntu method in the interfaces file [09:30] as the system is read-only [09:33] Guest92109: if i could first make a recommendation: if you are just beginning a project then zyga & kissiel were correct in urging you to update to Series 16 Ubuntu Core, we have been working with Dell to transition customers for serveral months to Series 16 [09:34] Guest92109: in addition I believe Dell announced that your version of Ubuntu Core would go End Of Life on September 30th so you will not receive further security updates [09:35] mvo: ack [09:35] mvo: let me know if I can help in some way [09:35] mvo: I'm updating my branches [09:36] Guest92109: in the meantime the supported method for configuring the network is to use network-manager which should come preinstalled on your system [09:36] zyga-ubuntu: yeah, I keep you updated, waiting for a debug shell right now. a cheap way would be to simply disable the test [09:36] zyga-ubuntu: on debian [09:36] mvo: is there a thread? [09:36] zyga-ubuntu: otoh, it will probably come back to use for artful+1 [09:36] zyga-ubuntu: not yet, I just noticed with my most recent PR that it fails [09:36] * zyga-ubuntu was reading something while stuck in transit and is a bit freaked out about this: [09:36] ok [09:37] http://papers.mathyvanhoef.com/ccs2017.pdf [09:37] mvo: note, our spread image differs for linode and qemu [09:37] mvo: qemu uses, I believe, real sid, while linode is using stretch [09:37] mvo: I wanted to fix this a while ago but I wans't sure how [09:37] zyga-ubuntu: yeah, I'm running against linode just to be sure [09:38] zyga-ubuntu: however there was a new upstream release of cups to unstable yesterday so most likely fallout from that [09:38] joc: thanks for your valuable information [09:38] Will contact them and do the same [09:39] Can i get a doc where complete step is mentioned how to open network manager and configure [09:39] mvo: aha [09:40] mvo: that paper I linked to looks like a massive security issue that affects everything using wifi, expect surge of updates everywhere :/ [09:40] I am new to core and tried various commands using snappy but could not get the setting . Thanks in advance [09:40] morphis: I think you need to update hostapd [09:43] Guest92109: configuration should be via the "nmcli" command [09:44] pstolowski: can you try the test a few more times? [09:44] joc: sure will check and let u know :) [09:44] Guest92109: there should be plenty of documentation for that in mangpages and on the internet, I would have to check with our Dell liasons whether there is some official docs for customers [09:46] joc: Thanks a lot would be a great help [10:11] PR snapd#4048 opened: tests: fix interfaces-cups-control test for cups-2.2.5 [10:12] mvo: +1 :) [10:12] zyga-ubuntu: ta [10:12] zyga-ubuntu: silly idea - could we simply govendor the squashfuse binary :) ? [10:13] zyga-ubuntu: it looks like govendor does not care if the git repo is go [10:13] mvo: mmm, dunno, how do you envision that? a go binary linking to something that is squashfuse itself or just a "govendor sync" repo that keeps all of squashfuse code but is unrelated to go [10:14] zyga-ubuntu: the later, just to have the git checkout and we do the building ourselfs [10:14] I like that much more than the PR [10:14] * kalikiana coffee [10:15] zyga-ubuntu: its slightly crazy but maybe a nicer option than the massive embedding [10:16] mvo: yes, certainly nicer [10:16] *certainly [10:33] mvo, urgh ... i think i found your reason for the upgrade test issues ... [10:33] mvo, https://dashboard.snapcraft.io/dev/snaps/5596/configurations/ [10:34] candidate and beta use the stable gadget (ancient firmware and uboot) [10:34] if you dont start from edge this wil most likely always fail with newer kernels [10:35] pstolowski's last comment on the thread helped a great deal ... [10:36] mvo, if you dont mind, i'll switch beta and candidate to the latest edge gadget [10:37] ogra_, oh, the versions? [10:37] pstolowski, yeah, your pi3 is the stable one [10:37] (pi3 snap) [10:38] ogra_: lets not change it just yet, lets see if cachio can refresh to edge gadget to make the issue go away [10:38] ogra_: but it sounds great [10:38] ogra_: I mean, great in the sense that it sounds like a plausible theory [10:38] ogra_: and also would explain all the oddness around the issue [10:39] mvo, well, he'Äd have to build an edge image and then downgrade kerne/coe to the espective target channels he wants to test [10:39] mvo, what doesnt go well with that theory is that it only started recently [10:39] ogra_: yeah, he says it started recently, hm, hm [10:40] there must be another aspect to it since the gadget channel setup has never changed after the first stable one [10:40] but it is defintely one of the issues [10:41] ogra_, hmm, ok all the rpi3 stuff is new to me, so please bear with me... I didn't miss any setup test, did I? [10:42] pstolowski, well, if i wanted to test beta i'*d also just builld a beta image, the issue is on ou side, not on yours [10:42] *our [10:42] ok [10:43] ogra_, interestingly, i re-flashed and testing again, it a 3rd run of the test and so far so good [10:43] *it's a 3rd [10:43] pstolowski: ha! [10:43] and pi3 is still at rev 6 ? [10:43] pstolowski: so you and cachio need to compare notes what is different [10:44] ogra_, yes, rev 6 still [10:44] ++ fw_printenv snap_mode [10:44] ## Error: "snap_mode" not defined [10:44] ogra_: lets try to find what this other factor is, then we need to fix the gadget to match the beta kernel. but lets try to get to the bottom of this first [10:44] thats the thing that made me curious ... [10:44] the stable gadget has still all the old variablle names [10:45] the test should fail exactly there ... [10:45] (from http://pastebin.ubuntu.com/25751741/) [10:45] github feature idea: mark a PR as "unbreaks master" and stop testing and landing all other PRs [10:45] could help us with cases like the one today [10:46] do we have any friends there? [10:47] ogra_: hm, things should be ok if snap_mode is not definied at all (unless I miss something). when it needs to get set, snapd will set it. in what line in http://pastebin.ubuntu.com/25751741/ should it fail you mean? [10:47] mvo, sure, the point is that snap__mode doesnt even exist ... which is true for the ancient gadget but not true for all newer ones [10:48] mvo, in the old gadget only "snappy_mode" is set [10:48] the price of renaming [10:49] mvo, indeed just the missing variable isnt an issue but an indicator that yoou run old and incompatible binary bllobs and uboot [10:49] is eternal backwards compatibilty support code [10:49] ogra_: aha, yes [10:49] (said with the voice of malcom mcdowell) [10:49] *malcolm* [10:51] mvo, ogra_ ah, no, it eventually failed again http://pastebin.ubuntu.com/25752176 [10:51] PR snapd#4030 closed: many: add internal squashfuse copy as "snapfuse" [10:51] Read error on /boot/uboot/uboot.env: Success [10:51] something is not setting errno [10:52] pstolowski: if you hexdump -C /boot/uboot/uboot.env - what happens? [10:53] mvo, note that this can actuallly be a eal corruption issue due to the ancient uboot vfat version in stable (vs very new kernel in beta and candidate) [10:53] mvo, I exited the spread test shell, is it still useful if I do that after spread restored the stuff? [10:54] pstolowski, just call fw_printenv alone [10:54] pstolowski: I think so [10:54] just ssh into it [10:54] pstolowski: I think so too [10:54] the test proobably swallows output [10:54] ogra_: yeah, corruption of the vfat would make a lot of sense. what version of uboot do we have there and in edge? might be worthwhile to do a quick scan of the uboot git log to see if anything related to vfat is there [10:55] ogra_, mvo, zyga-ubuntu fw_printenv output: http://pastebin.ubuntu.com/25752195/ [10:55] mvo, some 2015 version iirc, we neve properlly documented it and it isnt built fom source [10:55] that onlly changed in edge when we switched to actual uboot source builds [10:56] pstolowski, well, that doesnt look corrupt at all [10:56] pstolowski: the first call looks very short [10:56] mvo, seeing that i take back my vfat theory :P [10:56] mvo, yeah, ignore it, probably I made a mistake copying [10:56] there must be some issue how the test uses fw_printenv instead [10:57] ogra_: well: "+ fw_printenv [10:57] Read error on /boot/uboot/uboot.env: Success" is the error from the test [10:57] pstolowski: anything in dmesg? [10:57] pstolowski: related to read error or so? [10:58] mvo, snappy_mode in there? [10:58] mvo, yes ... but nmanualy it woks [10:58] pstolowski, yeah, eftover [10:58] *left [10:58] ogra_: yeah, still odd, how could the test use it incorrectly? also no errno set :/ [10:58] pstolowski, there should also be a snap_mode *if* you ae in any of try/trying ... it gets unset afterwards [10:59] PR snapd#4048 closed: tests: fix interfaces-cups-control test for cups-2.2.5 [10:59] mvo, well, i dont know, but manually running it obviously works ... perhaps missing env ? or does the test unmont snappy-boot at some point ? [11:00] ogra_: I don't think it does [11:00] mvo, nothing stands out in dmesg.. except for [ 6.989717] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities [11:00] [ 7.004959] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities [11:00] pstolowski: what ogra said, snappy_mode= can be ignored [11:01] pstolowski, thats /writable ;) and normal noise from the ext4 driver looping over fs capabilities [11:01] mvo: could it be (in any way) related to the fact that more recent ubuntu versions use incompatible feature set for ext4 [11:01] (i whish we could just quieten that) [11:01] csum_metadata [11:01] chsum_metadata* [11:01] zyga-ubuntu, wrong path :P we talk about a vfat ;) [11:02] ogra_: p2 is vfat? [11:02] ogra_: I thought p1 is [11:02] zyga-ubuntu, system-boot is [11:02] everywhere [11:05] mvo, the original test ooutput has "mesg: ttyname failed: Inappropriate ioctl for device" https://paste.ubuntu.com/25728858/ [11:05] mvo, i wonder if that could inflluence fw_printenv functionality somehow [11:06] ogra_: I think thats something from spread actually, but it might be, I am looking at fw_printenv from the uboot git now [11:06] mvo, better look at the one fgrom the deb source [11:06] thats what we use [11:06] (and it might be far behind git) [11:06] ogra_: the xenial one? [11:06] yep [11:08] 2016.01+dfsg1-2ubuntu3 ... nearly 2y old [11:08] how can 2016 be nearly two years old? [11:08] well, [11:08] nearly ok [11:08] january 2016 ... [11:09] (i could have said 22 months if you'd prefer that :P ) [11:10] my tests also had a couple of 'mesg: ttyname failed: Inappropriate ioctl for device' errors [11:10] yeah [11:10] must not be the issue but it might indicate that you tty is somewhat different to the one you have when running fw_printenv manually [11:11] something is surelly with the env [11:16] pstolowski, ogra_ http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/fw_env.c;h=ab06415898c2f718e8a926879379b1f8d74ca55d;hb=HEAD#l760 is the only place where this error is produced (looks the same in the 2016 version) [11:16] too bad it doesn't display rc [11:17] pstolowski: I would argue the code in there is incorrect [11:17] it may be just a partial read [11:17] zyga-ubuntu: yeah, exactly [11:17] (truncated environment?) [11:17] zyga-ubuntu: you mean something else truncated the uboot.env? [11:17] mvo: last week we learned how error messages suck [11:17] mvo: well, not sure if really truncated [11:17] mvo: I didn't read the rest of the code [11:17] mvo: I meant that if you have a fixed buffer [11:17] mvo: and then read until EOF [11:17] well, uboot.env isnt truncated if you manually run fw_printenv [11:18] mvo: then eventually you will get a partially complete buffer [11:18] zyga-ubuntu: there might be a signal [11:18] mvo: unless there's some assumption about the alignment of the file [11:18] mvo: "alignment" in blocks [11:18]