mvo_ogra_: hi, do you have any expectation on the order of the uboot environment vars? I use alphabetic order right now but was wondering if I should keep the order of the input file inside the uboot.env. I guess it does not matter but I wanted to double check06:55
fgimenezgood morning07:03
dholbachgood morning07:19
ogra_mvo_, no, no expectations, uboot loads all at once before processing, so any order should be fine07:26
mvo_Chipaca: hi, I think https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 is good now, I fixed the missing dependency and update tha ppa. I also createda backport for 15.04 but have not proposed it yet, wanted to do the full willy image test first08:17
mvo_Chipaca: if you could check if its really good now, that would be great08:17
longsleepmvo_: When this is merged and i build a new willy image, will that include the new behavior?08:18
ogra_longsleep, yes08:18
ogra_you will need the updated device snap08:19
longsleepogra_: Even if i have my own device snap?08:19
mvo_yeah, we are just wating for the final code review, I guess I could top-approve, john said "good except the missing package dependency wich i added)08:19
* mvo_ wonders how impatient he is today :)08:20
ogra_longsleep, you will need uboot.env support in the bootloader08:20
longsleepyes i got that08:20
longsleepbtw - did you see my script for resizing from yesterday: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh08:21
longsleepi would suggest adding something like this to the boot process by default08:21
longsleepwill just grow the writable partition no matter what08:22
longsleep(if it can be grown)08:22
ogra_longsleep, we have a set of initramfs script already that are widely used (i.e. on the phones) ... we just havent decided to include them yet because there are potentially more and bigger changes to the partitioning setup ahead08:23
longsleepok - understoot. So for now see it as easy way for people to resize their snappy installation.08:24
longsleepso just to be sure - once mvo_ merged the changes, 'ubuntu-device-flash core --channel edge .. 15.10 should' fuse them into an image right?08:26
mvo_the snapy on the image will deal with both new uboot.env and old uEnv.txt, if uboot.env is there its used, otherwise it just keeps using the old system08:29
ogra_ah, sweet08:29
longsleepok - so i could now even remove the empty uEnv.txt ?08:31
longsleepand the snappy tool will still detect u-boot environment?08:32
ogra_if there is no uboot.env file u-boot will fall back to the defaults08:33
ogra_(and load uEnv.txt or boot.ini or whatever you have definaed by default)08:33
zygaogra_: hey, I found two bugs in snappy amd64 boot config08:35
ogra_file them then08:35
zygaogra_: I'll report them later today after meetings but I wanted to share this08:35
* ogra_ has never touched the grub stuff ... luckily :)08:35
zygaogra_: first, we use the wrong identifier for the hard drive and snappy really boots by accident08:35
zygaogra_: it should be hd0 instead of hd1 everywhere08:35
zygaogra_: I suspect this is because after the image was generated the grub config generator never ran again08:36
zygaogra_: this makes it boot by accident really, it boots because --08:36
zygaogra_: the filesytem identifiers are used as a fallback and those actually work08:36
zygaogra_: which is the second bug: everyone that downloads the pre-made image will have the same unique identifier08:36
zygaogra_: and then mess happens, boot snappy, plug snappy on a usb drive, reboot -- you will boot into the random one depending on bios08:37
zygaogra_: we should re-generate them on first boot08:37
zygaogra_: like other things (ssh keys)08:37
zygaogra_: I'll file them today, thanks08:37
longsleepogra_: yeah if there is no uboot.env file, my uboot will now fail to boot as i have dropped the boot.ini. But i am also not loading uEnv.txt and in the past this file was used to detect u-boot environment - thus is shipped an empty one and still do.08:42
ogra_well, why did you drop the boot.ini code ?08:42
ogra_i assume thats just a fatload somewhere in the u-boot default config ?08:43
longsleepbecause it is not needed anymore as everthing is in boot.env08:43
ogra_yes, and that means you can keep the old env around08:43
ogra_uboot.env will completely replace it if it is there ... if it is not there you fall back to the old methid automatically08:43
longsleepMhm - i thought to clean it up to avoid confusion08:43
ogra_well, its a safety net :)08:44
* ogra_ doesnt want to admit that he is just to lazy to clean that up in his own images :P08:44
longsleepmhm - i was thinking to bring back uboot.ini eventually so people can customize "some" variables without modifying the .env file08:45
longsleepthe .ini file is handy as it supports comments and empty lines08:45
longsleepi think these two points are the reason they added it08:45
ogra_well, with uboot-go around changing the env vars isnt actually a biggie08:45
ogra_but yeah, we dont remove the loading code for uEnv.txt either08:46
ogra_so you could use it to override thins08:46
longsleepwell you have to do it from command line - i was thinking about people who insert the sdcard into some pc and use notepad to edit it08:46
longsleepthere are some things people might want to change, like hdmi resolution, mode, sdcard compatibility08:47
zygaogra_: btw, who's working / looking after the amd64 images?08:47
JamesTaitGood morning all; happy Hammock Day! 😃08:48
longsleepogra_: and in my old boot.ini i was hacking and calling snappy_boot, so i really want to get rid of this08:48
ogra_longsleep, just ship an empty one then08:53
longsleepyeah i will do that with some examples for customization08:54
longsleepthis is not possible with uEnv.txt08:54
longsleepno comments and no empty lines right?08:54
longsleepi mean for the bbb uEnv.txt is just loaded with import -t -r08:55
ogra_uEnv.txt is exactly the same08:55
longsleepsame was what?08:55
ogra_comments and all08:55
ogra_they are identical ... just differently named08:56
ogra_(i never understood why odroid felt they need their own filename)08:56
longsleepidentical to what ? sorry i am not getting it :)08:56
longsleepyou mean the boot.ini ?08:56
longsleepthey are not the same08:56
longsleepthey are similar08:56
longsleepbut the boot.ini is parsed differently08:57
ogra_boot.ini and uEnv.txt are absolutely identical, just that whoever implemented the odroid uboot bits decided he wants it called boot.ini08:57
longsleepno thats not true08:57
longsleepboot.ini supports empty lines and comments08:57
ogra_i dont think there is any difference in parsing08:57
ogra_uEnv.txt too08:57
ogra_our beagle and RPi images hsip a uEnv.txt with empty lines and comments ;)08:57
longsleepwell they have 100 lines parsing code added to u-boot08:57
longsleepso let me check that code08:58
longsleepi would be happy to use uEnv.txt08:58
ogra_heh, seeing the wily-devel ML it looks like slangasek had "a-f day" :)09:00
ogra_err ... wily-changes i mean indeed09:01
longsleepogra_: so the code is here: https://github.com/hardkernel/u-boot/blob/odroidc-v2011.03/board/hardkernel/odroidc/cfgload.c - they have logic to load it from muliple locations which we do not need, the rest is about ignoring comments and parsing all with hush. Is uEnv.txt also parsed with hush?09:03
* longsleep needs to learn about uEnv.txt09:03
ogra_if hush is enabled, yeah09:03
longsleepok then - i do not know why they added this cfgload stuff either :)09:03
ogra_it might be implemented a few mobnths before the uEnv.txt support landed or some such09:04
longsleepmhm well that wile was added end of 2014 - so i guess uEnv.txt support is older09:04
ogra_uEnv.txt comes from 2010 or 2011 IIRC ---09:04
ogra_might have been 201209:05
longsleepthey have some text comparison verifying that the file is for the correct target - maybe that is the reason (it has to start with ODROIDC-UBOOT-CONFIG to be used).09:05
longsleepmhm - i still fail to see how "env import" can process stuff like "setenv foo bar" assuming uEnv.txt is the same as boot.ini09:08
Chipacamvo_: approved; sorry for the delay (first day of school holidays!)09:13
mvo_Chipaca: no problem at all09:13
mvo_Chipaca: I *so* look forward to the school holidays too09:14
* mvo_ will sleep until noon that day09:14
Chipacai instead got a supermarket delivery at 6:30am, just to celebrate09:14
Chipacabut then went back to sleep \o/09:15
ogra_your kids dont show up at your bed at 7 ?09:15
Chipacabut he's just started a longish book, so he was lost in it before 709:16
Chipacai must admit the fact that he's reading "young adult" fiction does bother me a little bit :)09:17
ogra_why is that ?09:19
Chipacabecause he's 10?09:19
ogra_nothing to bother about then :)09:19
Chipacathat's why the smile :)09:20
Chipacaespecially considering i was reading LOTR at his age09:20
ogra_i had a hang for scifi short stories at that age ...09:21
Chipaca(it's my grandpa's fault, as he gave me the best encouragement he could: he told me i was to young to read it)09:21
ogra_(i think i was way older before i read LOTR)09:21
Chipacanice, the kvm hung overnight09:22
longsleepogra_: so - from my testing uEnv.txt gets loaded as key=value file - it supports comments, but one cannot use if, or setenv in it. Do you have an example for an uEnv.txt which does that?09:26
Chipacamvo_: anything you'd do different wrt http://pastebin.ubuntu.com/11919018/ ?09:26
ogra_lohmm, no09:27
ogra_longsleep, hmm, no09:27
ogra_longsleep, why do you feel the need for setenv ?09:28
longsleepwell it all comes down how the uEnv.txt is loaded, in your bbb its just "env imported", the boot.ini is parse_string_outer line by line.09:28
ogra_var=value is enough09:28
longsleepsetenv is not required true09:28
longsleepbut i need if/else09:28
ogra_if/else work inside a var09:28
ogra_look at the old snappy-system.txt09:29
ogra_i.e. the snappy_boot cmd09:29
longsleepwell, ok - i need to do this: if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi09:29
longsleepi need to run commands inside if/else09:29
longsleepand the settings should be controllable by user09:30
ogra_mytest=if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi09:30
ogra_then you exec mytest from somewhere09:30
longsleepok i guess i could do that09:30
longsleeplet me try :)09:30
ogra_run mytest09:30
ogra_snappy_boot=if test "${snappy_mode}" = "try"; then if test ${snappy_trial_boot} = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr}09:30
ogra_uenvcmd=run snappy_boot09:30
ogra_like that :)09:31
longsleepyes, and those vars i could predefine in the .env file even09:31
longsleepok sounds like a plan - thanks09:31
longsleepi want to get rid of all hardkernel special stuff if possible, so make it easier to switch to upstream u-boot eventually.09:35
ogra_mvo_, do you need an extra approval on https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 ? i assume we wont get one from sergio this week10:18
=== bigcat is now known as bigcat[off]
mvo_ogra_: I self approved now, this branch is obsolete with the env2 one anyway10:27
ogra_so now i need to find out how to get the snap into the store10:28
ogra_seems it was uploaded by a canonical account10:28
ogra_(and i guess both people that could tell me about it are gone this week)10:29
=== bigcat[off] is now known as bigcat
mvo_ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image11:01
mvo_ogra_: re store,11:01
ogra_mvwe need the snap in the store ...11:01
ogra_mvo_, we need the snap in the store ...11:01
mvo_ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image11:02
ogra_and i have not the slightest clue how to get it there11:02
mvo_ogra_: re store,  one sec11:02
mvo_ogra_: you have a private message with details :)11:04
ogra_ah, i need to go to the other machine then :)11:04
* ogra_ is having brunch :) 11:04
conyoois it possible to rollback more than 1 step? i kinda find it interesting to be able to rollback 12 versions back if i'm crazy. the a/b is nice but the whole alphabet is nicer :D11:08
ogra_ii think currently only one step11:09
conyoooh currently :d11:09
conyooso there is hope!11:09
ogra_i'm not sure we plan to actually keep all versions of a snap on your disk forever ...11:10
ogra_which would be needed for endless rollback11:10
conyoomaybe for selected snaps? :D11:10
conyooi don't need all of them, but would be nice to work for selected snaps11:10
conyooi also don't care about disk space11:10
mvo_we plan to move to a more flexible way than a/b in the future, but its not done yet11:11
ogra_mvo_, thats about app snaps11:11
mvo_ogra_: let me know if the msg made it, if not I can also handle the upload11:11
conyoothanks mvo_ and ogra_ :D sounds amazing to me! :D11:11
ogra_i guess starting a discussion on the ML might be helpful11:11
ogra_mvo_, well ~30min, then i'll be back in the office11:12
mvo_oh, app snaps, yeah, we already keep 3 by default iirc, easy enough to keep more11:12
mvo_ogra_: thats fine, I get lunch then I think11:12
Chipacayeah, we'll allow a/b and *also* 𝛼/𝛽 \o/11:35
ogra_greek rollback ?11:37
ogra_mvo_, ok, new bealeblack snap sits in review in the store, someone needs to manually approve it11:45
longsleepogra_: so now that the change is merged - you think i can build a new image which should handle uboot.env ?11:59
ogra_longsleep, not yet ... we dont have a new rootfs yet12:00
longsleepogra_: ah yes - that reminds me that i need to learn how to build a rootfs myself12:00
ogra_yeah, thats next on my list ... making rootstock-ng work for home builds again12:00
longsleepwell does it actually matter how the preinstalled tarball is created? I mean building that should be easy. I am only worried about what comes after that - as i have no clue yet :)12:03
ogra_after that it gets processed by system-image12:04
ogra_which unpacks it and the last tarball, diffs the files and creates a delta tarball12:05
longsleepyeah thats the scary part :)12:05
* longsleep still needs to build a system-image and deltas for odroidc12:06
longsleepyes i have been reading that a couple of times - until now i found something which was more fun to work on12:08
ogra_i'm also not sure it is worth the effort ... eventually your device tarball will become a snap too ... then a system-image server would be rather pointless (as you would just serve the same rootfs we serve)12:10
mvo_ogra_: only for rolling right now, correct?12:11
mvo_ogra_: the 15.04 backport is not approved yet, but we should focus on that now I guess12:11
ogra_mvo_, well i didnt change anything in the package setup on the page ... it had both ticked ... can you just release for one ?12:11
longsleepogra_: i am not so sure yet, i might require changes to the rootfs or some software inside it. Or for the paranoid, i might want to have self compiled versions of everything12:11
mvo_ogra_: I think no, will it still install the old files? i.e. will a old snappy still work?12:12
ogra_longsleep, that breaks snappy design though ... you should put your extra bits into snaps people can install at build time of the image12:12
mvo_ogra_: eh, nevermind, of course not12:12
ogra_mvo_, uEnv.txt is empty12:12
mvo_ogra_: meh, ok12:13
mvo_ogra_: I will ask Chipaca for another review then :)12:13
ogra_yeah, then we can blame him if it breaks, good idea :)12:13
mvo_ogra_: thats the idea, right? its always the reviewers fault12:14
mvo_ogra_: unless I did the review in which case its the original authors fault12:14
ogra_*indeed* !12:14
mvo_Chipaca: if you have a moment, could you plese check https://code.launchpad.net/~mvo/snappy/15.04-snappy-bootsuccess-env2/+merge/26551012:14
ChipacaI shall consider it.12:15
longsleepogra_: yes, but what about images for certain hardware which come with pre installed stuff?12:15
mvo_Chipaca: meh, I just noticed it may miss a upstream revision, let me quickly double check12:16
ogra_longsleep, same thin12:16
ogra_longsleep, your extras should be in snaps12:16
longsleepogra_: ok i see - can the snap modify base behavior? Like add or change systemd services ?12:17
ogra_theoretically yes, not sure how that will practically work ... but confinement is something we enforcxe artificially so you can indeed work around it (as long as a store reviewer approves it)12:18
mvo_Chipaca: ok, should be ready now12:18
longsleepogra_: what about third party devices with custom behavior, do these have their own store then?12:19
ogra_i guess so12:19
* ogra_ doesnt know the exactly planned setup for that 12:19
longsleepogra_: ok, that is probalbly soemthing i need to investigate more then.12:20
ogra_beuno should be abck next week, he can elaborate12:20
beunowell, don't kick me out just yet!12:21
ogra_hey, didnt you mail that you are vacating ?12:21
beunotomorrow and thu!12:21
beunoer, tomorrow and fri!12:21
beunolongsleep, we're still working out the details on how to support third-party devices that need to break out of confinement. We can point you to the commercial team to help you flesh that out if you'd like12:22
longsleepbeuno: Yeah - i just had a call with Marteen and he sent an email to connect me with lool12:23
beunoah, perfectd12:24
longsleepbut i also would prefer to have as less customizations as possible. So i am checking all the possibilies here. Not sure if it really needs to break out of confinement.12:26
loollongsleep: hi!12:27
longsleepI have control on uboot, kernel, snaps and device part. Device part will become a snap eventually. What i need in addition is a customization like some post image build scripts.12:27
loollongsleep: just read through Maarten's email; reading the fwded one now12:27
longsleeplool: hey - no hurries12:27
loollongsleep: ok, done reading, and BTW well done on the ODROID-C OEM snap  :-)12:28
loollongsleep: I didn't find details of the questions around SSL and ports; is this written up somewhere in email or bug?12:28
longsleeplool: thanks - that was the easy part. Getting the thing doing the same as with normal ubuntu is the hard part.12:28
longsleeplool: i sent some points to the mailling list in the past, and i have added some stuff to the tracker as well.12:29
dholbachrsalveti, do we have much of an agenda for the snappy community call?12:29
ogra_oh, i totally forgot about that one12:30
ogra_no asac today too12:30
longsleeplool: bot i think its best explained all together rather to get the idea12:30
dholbachrsalveti, I had a few days off so not too much to report on my side12:30
longsleeplool: right now it comes down to entropy, having a NGINX framework so many snaps can share port 443 and SSL setup12:31
* ogra_ was busy with technical stuff the last days ... 12:31
ogra_not much from my side either12:31
loollongsleep: I see12:32
loollongsleep: I think it's a great thing to provide12:33
loollongsleep: so in general, we have not been mandating how this or that should be designed but rather gave a set of primitives (like frameworks and apps) as to let various experiences bloom12:33
loollongsleep: and then we see what picks up and makes the most sense12:34
loollongsleep: I think it's a wonderful example12:34
loollongsleep: in general, framework provide services typically in the sense of a shared resource; port 443 is one; entropy pool is another; great things to expose in a framework12:34
loollongsleep: how would the API be? apps depend on your nginx-based framework and register a name over HTTP/REST to localhost to get traffic forwarded to them for /name/ or for name.xyz?12:35
longsleeplool: yes something like that - not sure if it needs to be an api though. In non snappy we just have a conf.d folder where packages can put their configs.12:36
ogra_well, you could have snappy config do it from your oem snap12:36
ogra_snappy config can use script hooks to apply the config12:37
longsleeplool: and the entropy one is tricky, on first boot keys need to be generated - it needs to be ensured that there is entropy available. Right now it creates key with essentially no entropy on first boot.12:37
longsleepogra_: ok, snappy config - thats something i need to investigate then. Is that only for oem snaps or also for software snaps?12:38
loollongsleep: so apps (and frameworks) are sandboxed as to prevent apps to see files from other apps; there needs to be a provisioning mechanism; we dont want maintainer scripts, but you could have data bits12:38
ogra_longsleep, thats for all snaps12:38
ogra_but in context of oem it can indeed be more powerful12:38
loolI dont think config hook will help to cross app barriers12:38
ogra_no, but to alter system defaults without having to hack the rootfs snap12:38
loolthe idea of config hooks if to have a standard interface for one snap to load/dump its config in YAML12:39
ogra_(or tarball)12:39
ogra_what longsleep wants, as i understand is some firstboot config to be applied12:39
ogra_for that the config hooks in the oem snap should be fine12:39
longsleeponly if applying that would block boot12:40
longsleepor start of systemd services12:40
longsleepi mean, the problem exists today. The SSH keys are generated on first boot with essentially no entropy.12:40
longsleepThats why i think the problem needs solving on snappy level.12:40
loolwe're discussing two different things12:40
ogra_well, on a cloud-init level12:41
loolone is the entropy, the other is providing nginx to other apps12:41
longsleepyes true12:41
longsleeplets talk nginx first12:41
longsleepi was thinking to have something similar to the docker framework12:41
longsleepit essentially the same12:41
longsleepprovide outside resouces to snaps12:41
loolyup, kind of12:42
longsleepright now i would have to ship nginx inside my snap12:42
longsleepinstead i could create a nginx snap12:42
longsleepand somehow depend on it12:42
longsleepare frameworks snaps too?12:42
loolso generally, we are not trying to use frameworks as a mean to distribtue dependencies12:42
loolliek packages were12:43
loolsnaps are apps12:43
ogra_yes, frajmeworks are snaps12:43
loolfully contained12:43
loolframeworks are to deliver a service or access to a shared resource12:43
loolfor instance, a bluetooth service12:43
loolbut if the goal is to make it easy for an app to embed a HTTP server like nginx, then I think this is more of a snapcraft topic12:43
loolwhich is the optional developer tool to create snaps12:44
longsleepmhm not sure - that would mean there would be multiple nginx running12:44
loolwith snapcraft, you can say "embed a java runtime in my snap"12:44
loolsimilarly, you might want to embed a HTTP server12:44
loolyes, multiple HTTP servers running is fine12:44
loolobviously not on the same port12:44
longsleepnot on the same port - and they all would need access to the same private key12:44
loolnot necessarily12:45
loolthat's if they serve the same site12:45
loolso perhaps it would make sense to discuss the larger problem you're trying to solve12:45
longsleepright now we have a bunch of micro services all providing HTTP web server. To the outside they get exposed with specific configuration by Nginx TLS on 443/tcp12:46
loolis it to make it easy to server a bunch of websites from a snappy install?12:46
longsleepwell, if web sites mean differnt domains then no.12:46
longsleepits about exposing web services on port 443/tcp with a secure TLS configuration.12:47
longsleeplets take the example from spreed-webrtc12:47
longsleepits a go service, wich listens on port 8080/tcp12:47
longsleepit needs to be exposed to the world on port 443/tcp with tls12:48
longsleepit could do that itself or the snap could include a web service which does it12:48
loollongsleep: is there an architecture diagram of spreed somewhere?12:48
longsleephold on12:48
longsleepbut spreed-webrtc is simple12:49
longsleepin the default setup it has only one end point12:49
loollongsleep: yes, but rather than discussing bottom up, I'd like us to have a top down discussion12:49
longsleeplet me upload it12:49
loollongsleep: for instance, from my naive understanding, I understand that this is about delivering spreed easily; I instinctively think this shoud be implemented by delivering a single spreed snap that offers the whole thing with hardcoded configs for most things, then exposing more and more features12:50
longsleeplool: yes - but that only works if no other snap uses port 443.12:50
loollongsleep: basically, the closest thing that matches this for me is how I'd run Kodi on an Android device12:50
loolI'd install the Kodi app12:51
looland then run it12:51
ogra_and perhaps have snappy config options to en/disable single spreed bits12:51
loolin the first version, this would not expose all the crazy advanced features like the web services for the remote control or the storage abstraction or etc.12:51
* ogra_ tried a kodi snap on the weekend but failed to build a static binary *sniff*12:52
longsleeplool: can you go to https://spreed.me/struktur/longsleep and i share the diagram with you there12:52
loollongsleep: so port conflicts are a real issue; we need to provide a definitive solution for this, but for now I'd say take port 443 by default, make the port configurable in the config hook and let anyone install the app; if the port is free, it's used, otherwise it's configurable12:52
loollongsleep: I have a personal opinion on how we should solve the port issue, but I dont think it was discussed12:52
loollongsleep: the current plan was around having an API to negociate/reserve ports12:52
longsleeplool: ok - what about muliple ips - do you have ideas around that as well?12:53
loolmy personal opinion is that we should start apps in some kind of network namespace where they can do what they want and some core snappy config allows routing host ports to snappy apps12:53
mvo_Chipaca: \o/12:53
ogra_lool, sounds like ubuntu-fan for ports :)12:53
loollongsleep: I'm there12:54
longsleeplool: ok - i shared the file with you.12:55
rsalvetilongsleep: https://wiki.ubuntu.com/Snappy/CoreImageBuild as well12:55
rsalvetidholbach: we can do a short call, just wanted to talk about snapcraft quickly12:56
loollongsleep: got it12:56
longsleepso you see Nginx STUN and TURN12:57
longsleepIn the simple case we have only Nginx12:57
longsleepthat is on port 44312:57
longsleepbut what if we want to have a TURN server as well12:57
longsleepthat would be a different snap12:57
longsleepalso needs to listen on port 44312:58
longsleepdifferent IP12:58
longsleepor if we would add other backend services12:58
loollongsleep: ok, so what's the minimal first version we could target? coudl we do everything on top of User 2 in a single snap to start with?12:58
longsleepyes that is no problem12:58
loollongsleep: BTW, checkout snapcraft; it's alpha but it allows bundling binaries from .debs easily12:58
loolI've used it to embed a java runtime and tomcat with a webapp12:58
longsleeplool: Maarten told me about this today12:59
longsleepwill check it out for sure12:59
loollongsleep: (NB: I have a call tunnel starting now and going 4 hours)12:59
lool4.5 actually12:59
longsleepno problem12:59
loolbut I'm reading IRC12:59
longsleepthink about the entropy problem though12:59
longsleepthat is more critical :)12:59
longsleepthanks for your time13:00
loollongsleep: so are STUN and TURN typically provided / deployed with spreed?13:07
loolare you saying the second IP is mandatory?13:07
longsleepno they are optional13:07
longsleepbut you should have a STUN server somewhere13:07
longsleepand a TURN server too for firewalled users13:07
loollongsleep: ok; entropy... again super naive thought, but we do that in all our cloud images: they boot and get some entropy from linux to generate a SSH key (I guess /dev/random provides a limited amount thanks to entropy of network traffic?)13:08
longsleepeg on our deployments they are all installed and that requires 3 IP's even. But the spreed server works fine with one.13:08
loollongsleep: are the TURN/STUN bits typically provided with the spreed codebase?13:08
longsleeplool: no it is a separate software13:08
loollongsleep: are the TURN/STUN generally useful with non-spreed use cases?13:09
longsleeplool: cloud images are a little different, they have most likely network connection on first boot and load entropy from your entropy service. While i find that scary too at least the keys are fine assuming the entropy service is providing good random.13:09
lool(I know what kind of services these provide, just not sure if these are typically used outside of spreed in general)13:10
longsleeplool: yes sure, many services require / can use a STUN/TURN service13:10
kyrofaogra_, since i2c isn't enabled on the rpi2, does that mean the GPIO works out of the box?13:10
loollongsleep: I can't really judge on this question product-wise, but I see two ways this could be done: either bundle all the software in a spreed snap, with 3 sets of services; second and third set of services would be disabled by default but could be enabled from a tunable13:11
ogra_kyrofa, no13:11
loollongsleep: would also expose config to set IP address to use13:11
longsleeplool: yes - that is possible. No problems here - though i wanted to avoid problems when people have other snaps also binding port 443 (current example is the ownlcoud snap).13:12
kyrofaogra_, can I get it to work, or is it in a similar situation to i2c?13:12
ogra_you need to have the bootloaders load the overlay dtb files that are needed for this ... and it will onyl work with ppisati's new kernel which will only be in the next image13:13
kyrofaogra_, alright, thanks for the info :)13:15
=== kickinz1 is now known as kickinz1|afk
ogra_mvo_, E: Build-Depends dependency for ubuntu-snappy cannot be satisfied because the package golang-uboot-go-dev cannot be found ...13:20
ogra_anything to worry about ?13:20
mvo_ogra_: yeah, I coped the depenency but looks like it was only copied but not published13:20
mvo_ogra_: I'm sitting here very  impatiently13:20
mvo_ogra_: fwiw, I started a wily image build now, that should have the real deal13:21
ogra_ah, sweet13:21
mvo_ogra_: and once the golang-uboot-go package is available on vivid we can test that too13:21
mvo_ogra_: yay, build! now once that is published we should have a 15.04 test image13:24
ogra_cool .... i'll test after the call13:25
ogra_(assuming it ever ends so dholbach can go back to comb his moustache )13:25
kyrofaHas anyone tried doing something with apache or nginx on snappy?13:25
* longsleep has tried nginx13:26
* ogra_ has done a few nodejs snaps 13:26
kyrofalongsleep, any luck? Did you make it a framework and make a website snap or something?13:26
ogra_you should put it inside your snap13:26
longsleepkyrofa: did not make a framework - had it in a snap13:26
kyrofaogra_, interesting. How would I install multiple website snaps that way? (i.e. a fight over ports 80 and 443)13:27
* dholbach slaps ogra_ :)13:27
longsleepkyrofa: yeah we just had that discussion. Nginx framework might be handy13:27
* ogra_ hands dholbach https://vimeo.com/11112370713:27
kyrofalongsleep, interesting, I wonder how tough that would be. I'll look into it if you think that such a framework is possible13:30
* ogra_ doesnt think a webserver is actually suitable for frameworks ... but looks like lool disagrees above13:30
kyrofaogra_, how else to you get around the port fighting?13:31
longsleepkyrofa: well we will see how it goes13:31
ogra_kyrofa, see backlog that was discussed above ...13:31
ogra_most likely by providing a port controlling service inside snappy13:31
kyrofaogra_, oh, you were _literally_ just discussing it! Okay :)13:31
ogra_well lool told us his vision ... the discussion is still outstanding13:32
ogra_mvo_, hmm, udf for 15.04 edge still gets me image 124 (the same i had yesterday)13:34
mvo_ogra_: you are too quick, wily is still building and 15.04 is not even publised yet13:34
ogra_oh, ok13:35
mvo_ogra_: so once snappy is published I will trigger a build and let you know, ~30min at last13:35
* ogra_ gets fresh coffee and a cigrarette 13:35
mvo_yay, tea13:35
* mvo_ jumps with joy13:35
* ogra_ jumps along13:35
* Chipaca starts getting "unusable private key" from gpg, and is sad13:36
mterryelopio, even in your branch names, you like underscores  ;)  ~elopio/snapcraft/integration_coverage13:36
Chipacaooh! it's key day!13:36
=== nyx_ is now known as moonwalk
Chipacamvo_: you got a bit?13:59
mvo_Chipaca: sure14:02
elopiogood morning.14:09
elopiomterry: we should pep8 also our branch urls :)14:09
elopiozyga: is there a way to make less verbose the output of plainbox, in case all the tests pass?14:14
zygaelopio: hey14:16
zygaelopio: yes14:16
zygalool: https://bugs.launchpad.net/snappy/+bug/1477178 (the stuff I mentioned today)14:16
ubottuLaunchpad bug 1477178 in Snappy "Snappy prebuilt images have very non-unique filesystem identifiers" [Undecided,New]14:16
loolzyga: yup14:17
zygaelopio: you can provide a different UI, I can show you how to do that tomorrow after my chain of meetings14:17
zygaelopio: I suspect we could also use a more silent UI as an option, this is all related to using plainbox as a simple unit-test runner14:17
zygaelopio: can we work on that sometime tomorrow afternoon CET?14:17
mvo_ogra_: both wily and 15.04 are build, we just wait for arm64, iirc the import will only start if all arches are build, but maybe (hopefully) I misremember that14:18
* ogra_ taps foot 14:18
ogra_i shoudl grow a moustache too so i could comb it while waiting14:18
geniiAlso good for straining your soup14:19
ogra_yeah, and keep something for bad days14:19
longsleepfor some reason a bunch of parameters to the kernel get lost from uboot to dmesg - someone seen that before?14:22
=== howefield is now known as howefield_afk
elopiozyga: tomorrow around this time would be ok. Thanks.14:22
elopiomterry: can I move the snapcraft.dirs.setup_dirs() inside snapcraft.main.main() ?14:24
elopioI think main should do everything.14:24
mterryelopio, probably?  No one calls main() without doing that, I assume?14:24
kyrofaseb128, just a heads up: I believe a newly built version of the snappy scope hit the NEW queue yesterday. The newest version of lintian caught some duplicate licenses in debian/changelog, so that's been fixed now14:24
seb128kyrofa, k, great, I reviewed it yesterday and it looked good, let me NEW it14:25
longsleepah - it was uEnv.txt seems it cannot handle lines like var=value # comment14:25
ogra_longsleep, what kind of parameters ?14:26
ogra_yeah, i think they cant be on the same line14:26
kyrofalongsleep, how dare you comment your variables :P14:26
longsleepyes comments at end of lines get included in the variable value and then magically scripts handle the # and stop afterwards :D14:27
ogra_sounds like a bug though14:27
* longsleep will never comment variables again - not!14:27
kyrofalongsleep, I bet that was tough to find14:27
longsleepnot really - i am used to u-boot problems by now :)14:28
elopiofgimenez: I'll work on your comments for the rollback, so lets skip our meeting today.14:28
elopiolet me know here if you want me to do something this evening.14:28
longsleepthat explains why the kernel crashed before - i had variable values with hashes at the end14:30
ogra_well, if you need the hash sign you should be able to use single quotes14:31
longsleepright, but it was just the comment14:31
longsleepmoving the comments into extra lines works just fine14:31
longsleepstil the 4k monitor i got here does not even now then i changed to dvi mode :(14:32
tedgUhg, three QML apps installed and ran out of space in my VM.14:34
zygaelopio: nice14:34
fgimenezelopio, fine, i'll continue with the integration tests job, hopefully i'll push something for you to try today14:36
elopiofgimenez: now we can talk about putting all the tests in the tests package. That would be merging the current cmd and failover dirs.14:37
elopiodo you prefer to have them separated?14:38
fgimenezelopio, now it doesn't make too much sense, having them unified would simplify the filtering and would consolidate the output dir14:39
elopiofgimenez: ok, I'll get to that too.14:42
fgimenezelopio, ok thx14:45
Chipacazyga: wrt uuids, have you tried rolling? we no longer use uuids in grub15:09
Chipacazyga: in fact i thought that was already in 15.0415:11
Chipacabut i'm not the bestest at tracking what we backported and what not15:11
=== chihchun is now known as chihchun_afk
Chipaca(that would be mvo)15:11
mvo_we never use uuids, did we?15:11
mvo_not in 15.0415:12
Chipacamvo_: before i cleaned up update-grub, we got uuid cruft in there15:12
Chipacamvo_: s/i/we/15:12
Chipacamvo_: this is wrt https://bugs.launchpad.net/snappy/+bug/147717815:14
ubottuLaunchpad bug 1477178 in Snappy "Snappy prebuilt images have very non-unique filesystem identifiers" [Undecided,New]15:14
ogra_Chipaca, does that even matter at all, since we fall back to the right thing anyway ?15:15
Chipacaogra_: zyga seems to think it does :)15:18
ogra_as long as we end up booting the right thing ...15:18
zygaChipaca: I didn't but this should be fixed in stable as well15:25
zygaChipaca: I'd love if you could look at my inception snap if you have a moment15:25
zygaChipaca: and if you could tell me more about how /boot/grub/grub.cfg (as in 15.04 image) came to be15:25
zygaChipaca: as IMHO it's broken in other ways15:25
zygaChipaca: it looks like it was generated when /dev/sdb was snappy15:26
zygaChipaca: all the identifiers there refer to hd115:26
zygaChipaca: but if you inerrupt grub and go to grub console15:26
Chipacazyga: http://pastebin.ubuntu.com/11920503/15:26
zygaChipaca: ls hd<tab><tab> will show you that snappy is actually on another disk15:26
Chipacazyga: i have no idea what grub.cfg you're looking at; i don't think we've ever explicitly refered to hdX15:26
zygaChipaca: is that rolling?15:26
zygaChipaca: look at the one on ubuntu.com snappy website :)15:27
zygaChipaca: I can pastebin that in a moment15:27
ogra_smells a bit like something ran update-grub or some such15:27
zygaogra_: yes15:27
zygaogra_: likely15:27
ogra_(which i think we ripped out completely by now)15:27
zygaogra_: we should kill non-snappy /etc/grub.d/ bits15:27
Chipacazyga: we no longer use update-grub at all15:28
zygaogra_: that sounds good, so without that, and with uuids fixed, it should be better15:28
zygaChipaca: btw, when you said you don't use uuids15:28
Chipacabut, again, dunno about 15.04 stable; checking 15.04 edge right now15:28
zygaChipaca: does that mean they are changed on first boot15:28
zygaChipaca: because if not you will still get mess while booting15:28
Chipacazyga: not as far as i know15:28
Chipacazyga: why will we get a mess?15:28
zygaChipaca: e.g. you boot with labels and labels are terribly nonunqie15:28
zygaChipaca: boot snappy preinstalled with snappy usb15:28
zygaChipaca: you boot to ... usb15:28
ogra_but non-unique is exactly what we want15:29
zygaogra_: why?15:29
zygaChipaca: btw, what is /prefix there15:30
ogra_zyga, today i can boot from SD, plug in a USB key, make a partition and label it "wrtitable" ... move the content from the SD writable partition and delete it there .... and snap my writable space on the RPi is 1TB15:30
zygaogra_: yes, that's all fine15:30
ogra_same goes for a and b15:30
zygaogra_: but it break if you have two snappy-like partitions around15:30
ogra_yes, you shouldnt15:30
zygaogra_: that's unreliable, it should not break just beacuse I happen to have snappy dual boot15:30
zygaogra_: no, the system should keep working15:30
Chipaca15.04 edge is an update-grub--generated file, but no mention of hdX15:30
zygaogra_: and the right way to do that is to use unique partition IDs15:31
ogra_zyga, well, the whole setup is still totally in flux15:31
ogra_zyga, we might end up with only two partitions for everything15:31
zygaogra_: and the use case you want is a developer feature, I'm sure you can hack your boot conf to mount those by label15:31
zygaogra_: oh, nice15:31
ogra_ /boot and writable15:31
zygaogra_: what's the intended layout?15:31
Chipacazyga: “GRUB’s normal start-up procedure involves setting the ‘prefix’ environment variable to a value set in the core image by grub-install, setting the ‘root’ variable to match, loading the ‘normal’ module from the prefix, and running the ‘normal’ command (see normal). This command is responsible for reading /boot/grub/grub.cfg, running the menu, and doing all the useful things GRUB is supposed to do.”15:32
Chipacazyga: IOW, $prefix is set by grub on startup; it points to the grub directory (whatever holds grub.cfg)15:33
Chipacazyga: https://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-shell.html15:33
zygaChipaca: thanks15:33
zygaChipaca: I spent ~10 hours in grub this week :D15:34
zygaChipaca: found lots of goodies15:34
zygaChipaca: and learned a lot15:34
ogra_zyga, moving the a and b readonly partitons to be squashfs images ion /boot instead of partitions15:34
zygaogra_: oh, great15:34
zygaogra_: that's even more interesting15:34
zygaogra_: so they are mounted from squashfs15:35
Chipacazyga: i spent a little bit of time on it to pare grub.cfg down to what i pastebin'ed; i'm sure it's missing stuff (e.g., does it work on xen?), but it's at least a sane starting point15:35
ogra_zyga, right15:35
zygaogra_: will that follow to .snaps?15:35
zygahow can I get rolling?15:35
zygaI'd like to try that15:35
ogra_zyga, sergiusens and mvo are currently researching that setup15:35
Chipacao ubuntu-device-flash core rolling --oem=generic-amd64 --channel edge -o wily.img --developer-mode15:35
Chipacazyga: ^15:35
zygaChipaca: do I need to be on willy?15:35
Chipacazyga: s/^o/sudo/ :)15:36
zyga(I always want to say willy)15:36
Chipacazyga: there's a ppa for legacy releases like utopic15:36
Chipacazyga: the "tools" ppa15:36
zygaChipaca: i'm on vivid15:36
zygaand I have ...15:37
zygadeb http://ppa.launchpad.net/snappy-dev/tools/ubuntu vivid main15:37
Chipacazyga: should work, then15:37
zyganice, I'll try that15:37
zygaI have a dedicated snappy test box15:38
zygato try various cert magic on15:38
elopiomterry: I don't fully understand the current behaviour of log. Your idea was to use print from plugins and snapcraft.common.log from snapcraft itself?15:38
Chipacazyga: on first boot you might not get ethernet; a reboot should fix it15:38
Chipacazyga: also note "rolling" is code for "we break it all the time"15:39
zygaChipaca: I though that was "rawhide" ;-)15:40
ogra_dude !15:40
Chipacazyga: "rawhide" is code for "*they* break it all the time"15:40
ogra_wrong distro15:40
zygaogra_: I know that15:40
mvo_mterry: given that we have no python3-fixtures on tarmac right now I wonder if we should just merge manually right now. sucks but sucks to be blocked by tarmac too15:40
zygaChipaca: I'm woring on a solution for automatic testing machines that don't do netbooting15:40
zygaChipaca: e.g. xps13 over wifi15:40
zygaChipaca: I _may_ have some suggestions for boot parts as I go15:41
zygaChipaca: where can I target that as patches?15:41
zygaChipaca: (though x86 only atm)15:41
Chipacazyga: um, depends on the patch i guess? asking here is a good place to start15:43
zygaChipaca: where does grub part live?15:43
Chipacaogra_: we should rename 'stable' to 'rawhide', to see if they're paying attention15:43
zygaChipaca: I'm only interested in that for now15:43
Chipacazyga: split between u-d-f and the generic-amd64 part, afaik15:44
ogra_"rawhide tumbleweed" then15:44
zygaogra_: no, no15:44
zygaogra_: rawhide tumbleweed 10 X15:44
zygathen it'll work15:44
zygaChipaca: where do they live?15:44
Chipacazyga: lp:~snappy-dev/snappy-hub/snappy-systems15:45
Chipacazyga: or lp:goget-ubuntu-touch for u-d-f15:45
zygaI got the first one, getting the second15:46
zyga(and my boot beagle patch is merged now ^_^)15:46
ChipacaI'm not sure we don't have logic in livecd still; sergio would know but he's away doing critical feature work15:46
zygaChipaca: aka putting the big fire out ;) ?15:46
Chipacazyga: aka having a kid15:46
zygaChipaca: how does livecd fit into place?15:46
zygayeah, that takes a while15:46
zygalike 30 years ...15:47
* Chipaca is 10 into that15:47
zygaChipaca: I'm 815:47
ogra_and i always thought you looked older15:48
Chipacazyga: i'm not *sure*, but i think we use livecd-rootfs to create the rootfs15:48
ogra_we do15:48
Chipacaogra_: it's the beard15:48
ogra_yeah :)15:48
Chipacabut that's descending into handwavy "sergio and ogra get a room, and magic happens, and we get an image" territory15:49
ogra_mvo_, damn ... i just found out the image doesnt boot .... if you dont plug the SD into the slot ...15:50
Chipacaogra_: the image that is on the SD?15:50
ogra_Chipaca, yeah15:50
Chipacaogra_: stop the line! that's a critical bug15:50
zygaogra_: ;-)15:50
zygaogra_: use the force15:50
zygaogra_: make it boot15:50
ogra_looks fine if i pluig it in though :)15:50
mvo_ogra_: I'm still waiting for the dd to finish, godd tells me 2m:50s15:51
mvo_but I think its lying15:51
zygaogra_: do you remember that weird remote SD card from linaro?15:52
zygaogra_: I hear you can get some15:53
zygaogra_: if you ask the right person15:53
zygaogra_: if you are tired with waving that SD card around all the time15:53
kyrofaChipaca, sergio is having a kid?15:54
ogra_mvo_, so whats the command to change the uboot vars now, how did you call the final binary ?15:54
kyrofaChipaca, that's awesome!15:54
ogra_kyrofa, he already had ... now he is having insomnia15:54
zygatab up mess15:54
kyrofaogra_, yeah, I know how that goes. I have a 1-year-old myself15:54
mvo_ogra_: there is no command (but fw_printenv, fw_setenv will work). its all part of the library that is used from inside snappy15:55
ogra_mvo_, hmm, i dont see the config in /etc15:59
ogra_(note i'm on 15.04 edge)15:59
mvo_meh, right, its only in edge. do you "just" need it for debugging?16:00
ogra_(BeagleBoneBlack)ubuntu@localhost:~$ ls /etc/fw*16:01
ogra_ls: cannot access /etc/fw*: No such file or directory16:01
ogra_(BeagleBoneBlack)ubuntu@localhost:~$ sudo fw_printenv16:01
ogra_Cannot parse config file: No such file or directory16:01
mvo_I need to add it for 15.04 to livecd rootfs too if we need it16:01
ogra_well, i need to set the boot to "try" no ?16:01
ogra_i'll do it from the uboot prompt16:01
ogra_yawn ... cloud-init ...16:03
ogra_mvo_, hmm, so booting with "try" still boots from a/16:05
ogra_shouldnt it have switched to b ?16:06
mvo_ogra_: did you also set snappy_ab=b ?16:06
ogra_no, just try16:06
mvo_ogra_: both need to be set16:06
* ogra_ retries16:06
mvo_ogra_: no worries, try is actually more logical16:07
ogra_at least i havent managed to trash it yet16:07
mvo_I mean, its more logical that you set it to try and it automatically toggles16:07
ogra_in 5 boots16:07
mvo_a good sign!16:07
ogra_and i always find snappy_mode=regular when i reset the board16:08
ogra_so snappy updates the var properly16:08
ogra_still boots from a/16:09
ogra_even with both set16:09
ogra_but still no corruption at least16:09
ogra_bah !16:10
mvo_ogra_: same here on wily, boots from "a"16:10
mvo_ogra_: cloud-init is soooooo slow16:10
mvo_but snappy_ab is set to b hmmmm16:11
ogra_yeah, cloud-init is a pain16:11
ogra_really wastes my time16:11
mvo_hm, snappy_trial_boot may also needs to be set to 116:11
ogra_my snappy_ab is properly re-set to a16:11
* mvo_ tests16:11
longsleepmvo_: do i can try a new image too now? 15.04 edge?16:11
mvo_longsleep: yes16:12
ogra_oh !16:12
longsleepmvo_: ok great16:12
ogra_shouldnt it set snappy_trial_boot ?16:12
mvo_longsleep: or rolling for now, the fw_setenv/printenv is not working yet on 15.0416:12
ogra_i dont see that here16:12
mvo_ogra_: ups, silly me16:12
mvo_of course16:12
ogra_is that snappys fault or uboots16:12
ogra_oh, i see ... snappys16:13
ogra_well, snappy needs to set it to 116:14
mvo_set what to 1?16:14
ogra_if test ${snappy_trial_boot} = 1; then16:14
longsleepogra_: what channel should i use for rolling?16:14
ogra_that wraps around the ab logic16:14
mvo_ogra_: the bootloader sets this, snappy just resets it16:14
mvo_ogra_: thats how its done in grub at least16:14
ogra_oh, ok16:14
mvo_ogra_: and its doing this, no? in the else setenv part?16:15
ogra_setenv snappy_trial_boot 116:15
ogra_U-Boot# setenv snappy_trial_boot 116:16
ogra_U-Boot# setenv snappy_mode try16:16
ogra_U-Boot# setenv snappy_ab b16:16
ogra_U-Boot# saveenv16:16
ogra_lets see16:16
ogra_sigh  ... still a/16:16
longsleepthis logic is in uboot only / independent from the booted system isnt it?16:17
mvo_hm, thats confing indeed "printenv snappy_ab16:17
mvo_but on boot it runs from a/16:17
ogra_longsleep, no, snappy adjusts the values after boot16:17
longsleepmhm i got an error when building the image - it failed to extract my oem snap.16:19
mvo_ogra_: could it (uboot) read stuff from snappy-system.txt still? that has snappy_ab=a in there16:19
ogra_mvo_, must be snappy that resets it ... snappy_trial_boot is actually completely gone from uboot.env after i booted ...16:19
longsleepsnap failed to install unpack failed with exit status 116:20
mvo_ogra_: yes, thats part of the firstboot job to unset it16:20
ogra_while a saveenv on the uboot prompt (even witrhj a reset afterwards) has the var16:20
ogra_mvo_, unset or set it to 0 ?16:20
ogra_not good i think16:20
mvo_I could change it so that it sets it to zero16:20
ogra_i think we need a boolean here16:21
mvo_oh, ok16:21
ogra_so we at least know the corruption is gone16:21
ogra_i did like 20 boots now ... and each time uboot.env was modified16:21
mvo_ogra_: easy to fix, but it does not explain why it boots a/ instead of b/ if you set it in the uboot prompt manually - or does it?16:21
mvo_ogra_: yay! corruption free booting16:22
ogra_i wonder if its a quoting issue16:22
ogra_U-Boot# setenv snappy_boot if test "${snappy_mode}" = "try"; then if test "${snappy_trial_boot}" = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr}16:23
ogra_syntax error16:23
longsleepput single quotes around the value16:24
kyrofaseb128, I'm making an MP to get unity-scope-snappy into the Personal seed (thanks for pushing that through!)16:24
seb128kyrofa, yw!16:24
kyrofaseb128, but as I mentioned previously, it does depend upon WebDM16:24
seb128did it work out of the box? I didn't try yet16:24
kyrofaseb128, which is only a snap16:24
longsleepmvo_: so - when i try to build the image with rolling it gives me an error that my oem snap fails to install. Any idea?16:25
seb128so if you snappy install webdm it should work?16:25
ogra_not a quoting issue then ... still boots from a ... :/16:25
longsleepmvo_: 15.04 creates image fine with the same oem snap16:25
kyrofaseb128, normally yes, but webdm isn't in the Personal channel, so you have to sideload it. But then, yes :P16:25
mvo_longsleep: are you on trusty ? latest tools from the ppa:snappy-dev/tools ?16:25
seb128kyrofa, can you get it in the personal channel?16:25
longsleepmvo_: i am on vivid - let me check if there are updates16:25
seb128unsure how to do that16:25
mvo_longsleep: oh, ok. maybe its a issue with rolling then, I'm not aware of one though16:25
* mvo_ needs to get some dinner, bbiab16:26
kyrofaseb128, I pinged sergiusens about it last week, but apparently he just had a baby16:26
kyrofaMaybe rsalveti can help us here16:26
seb128oh, ok16:26
seb128sergiusens, congrats ;-)16:26
mvo_longsleep: aha, I think its a race or something, I had this too16:26
mvo_longsleep: no, meh, I think its something else16:27
kyrofaseb128, so let's pretend it's in the Personal channel. Can I modify something else in this branch to make sure it's included, or is it something special we're going to have to add to the u-d-f incantation every time we make an image?16:28
seb128kyrofa, no idea, that's an udf/sergiusens question16:28
kyrofaseb128, alright, so you're not preloading any snaps at the moment then?16:29
longsleepmvo_: http://paste.ubuntu.com/11920858/ that shows both outputs16:29
mvo_longsleep: yeah, I think its "failed to find user uid/gid" thats the culprit16:30
kyrofaseb128, alright, I should probably hold off on adding this to the seed until it works out of the box, yes?16:30
longsleepmvo_: ok - is that something i could change in my snap?16:30
mvo_unfortunately not, let me build you a new 15.04 image for now until this issue is fixed16:31
longsleepmvo_: that would be awesome16:31
* longsleep wonders how ogra_ did it 16:31
kyrofaseb128, perhaps I'll make an MP, but make a note of the prerequisite?16:31
longsleepmvo_: do you want me to add the issue to the tracker?16:32
mvo_longsleep: yes, set it to critical please, I think its because we renamed the snap user from clickpkg to snappypkg in rolling16:32
longsleepmvo_: ok16:32
ogra_longsleep, i'm testing 15.04 rolling here16:33
mvo_longsleep: but I need to double check, I have a vague memory of fixing it but maybe the fix was not promoted from ppa:snappy-dev/tools-proposed to tools, you might check if tools-proposed has a update for ubuntu-device-flash16:33
mvo_but in any case, image build with /etc/fw_env.config triggered16:33
mvo_and dinner!16:33
* ogra_ doesnt care much about wily atm ... 16:33
ogra_i just want that stable image done16:33
longsleepsure - so why did i test wily then? Set channel to rolling and release to 15.04 should give me all the new stuff?16:34
seb128kyrofa, that image is experimental, we can document that webdm should be installed and how...16:34
kyrofaseb128, perfect, making the MP16:34
seb128kyrofa, no, we are not proloading any snap atm, I don't know how to do that/didn't look at it16:34
seb128kyrofa, thanks16:35
ogra_longsleep, yes ... we need to test wily too though +16:35
ogra_but for now i want that stable image out first16:35
longsleeprolling not found on server.16:35
ogra_and i didnt really plan to do a late shift today, damned16:35
ogra_sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.0416:36
ogra_longsleep, ^^^ edge ... sorry16:36
longsleepah edge16:36
ogra_U-Boot# setenv snappy_ab b16:37
ogra_U-Boot# run loadfiles16:37
ogra_reading b/vmlinuz16:37
ogra_why does that work16:37
ogra_(and why doesnt it if snappy_boot calls the same)16:37
longsleepmvo_: i just added bug 1477224 - but i do not seem to be able to set to critical16:39
ubottubug 1477224 in Snappy "OEM snap does not install when building image for rolling" [Undecided,New] https://launchpad.net/bugs/147722416:39
longsleepogra_: ok i got an image edge version 125. That looks good?16:39
ogra_thats what i use here16:40
mterrymvo_, sorry, was out for lunch.  About fixtures and tarmac...  That would involve not just a manual merge, but turning off tarmac altogether, as other merges would be blocked too, if trunk required fixtures16:40
ogra_hmm, so manually setzting snappy_ab to b and snappy_trial_boot to 1 and then running run snappy_boot works fine16:42
ogra_it properly boots from b16:42
ogra_i dont get that16:42
longsleepmaybe its an order thing16:42
ogra_why would it work on the uboot prompt then ?16:42
longsleepno idea :)16:42
ogra_(and why did it work before when we tested it)16:42
ogra_U-Boot# setenv snappy_trial_boot 116:44
ogra_U-Boot# if test "${snappy_trial_boot}" = 1; then echo foo; fi16:44
ogra_works just fine too16:44
longsleepwhat about env print snappy_trial_boot16:45
longsleepdoes that show 1 ?16:45
ogra_not by default16:45
ogra_but yes, if i set it16:45
longsleepso what is the problem?16:46
ogra_U-Boot# printenv snappy_ab16:46
longsleepi just finished fusing - so lets see if i can reproduce16:46
ogra_U-Boot# if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; fi16:46
ogra_U-Boot# printenv snappy_ab16:46
ogra_so that bit is ok as well16:46
ogra_longsleep, the prob is that no matter what i set, it always boots from a16:47
longsleepok so mine booted just fine - what should i try?16:47
ogra_unless i do it manually16:47
ogra_by calling run snappy_boot after setting the vars16:47
longsleephow do you set something not manually?16:48
longsleepmine now is booted from a16:48
ogra_i set it, call saveenv and call reset16:48
longsleepah ok16:48
longsleeplet me try that16:48
ogra_or i set it and run snappy_boot16:48
ogra_the latter works16:48
ogra_the former doesnt16:48
longsleepwhat should i set? snappy_mode to try?16:49
ogra_snappy_mode try ... snappy_ab b .... and snappy_trial_boot 116:49
longsleepright - booted from a for me too16:50
ogra_oh, wait16:50
ogra_do we actually need to set snappy_ab at all ?16:50
longsleepwell depends what you want16:51
* ogra_ tries without it ... 16:51
longsleepit changes to the other at some point16:51
ogra_i dont think we touch that var normally16:51
longsleepdependend on the other vars16:51
ogra_only snappy_trial_boot and snappy_mode16:51
* ogra_ taps foot waiting for cloud init16:51
longsleepit fast on the odroid16:52
longsleeprather fast16:52
longsleepi can confirm that the system did set snappy_mode to regular and it sems to have removed snappy_trial_boot16:53
ogra_me has it booting from b with only the two vars touched16:53
longsleepyes works here too16:53
longsleepif i only change those two it boots from b16:53
ogra_which is indeed logical :)16:53
ogra_and if you change them again it shoudl switch back16:54
ogra_and so it does !°16:54
ogra_and still no corruption16:55
slangasekogra_: g-* was meant to happen overnight, but apparently I didn't hit the right key before going to bed :P16:55
ogra_i guess we can call that a success16:55
longsleepyes - changing back works here too16:55
* ogra_ needs to wait for mvo to return to confirm snappy itself doesnt tinker with snappy_ab16:56
ogra_but yay ... we have grub and uboot unified !!!16:56
longsleepvery nice indeed!16:56
ogra_now we just need to convince both upstreams to also merge theior code :)16:57
ogra_slangasek, lol16:57
ogra_i actually had to look up what i had said to trigger your answer :)16:58
ogra_rsalveti, so confirmed that there is no fat corruption anymore ... i just need one final confirmation from mvo and we are good16:59
longsleepogra_: https://github.com/longsleep/snappy-odroidc/tree/uboot-env-support branch has all the gear to build oem and device for ODRODIC using the new .env file - if you want to give it a try see how my uEnv.txt and .env.in look now.17:00
rsalvetiogra_: that's great, can you promote latest edge to alpha so we can test the update/rollback a bit more in there?17:00
ogra_rsalveti, one thing missing in the current rootfs, mvo has triggered a build with a fix17:00
rsalvetiwant to give it a shot in a few17:00
ogra_waiting for that17:00
rsalvetiogra_: oh, great17:00
ogra_(fw_setenv/printenv config was missing in 15.04 --- so you cant tinker with the config from the runnng system)17:01
longsleepit is there in the image i just built17:01
ogra_oh, so the rootfs is already there ?17:01
longsleepah the config17:01
* ogra_ tries17:01
longsleepno - i thought you mean the commands17:02
ogra_yeah /etc/fw_something17:02
longsleepyes that still is missing17:02
ogra_the commands dont work at all without that17:02
longsleepyeah - thats one reason why the go tool would be nicer17:02
=== retrack is now known as Guest25941
ogra_(though i would have preferred to just includethe uboot-go tool instead ... the fw_ stuff is so fragile)17:02
rsalvetikyrofa: to include webdm by default I'd assume we need to change the oem itself17:15
rsalvetisince it's a snap package17:16
kyrofarsalveti, ah, good to know. But I think we need it in the Personal channel first, right?17:16
kyrofarsalveti, last I checked, it was only in Core17:16
rsalvetido we have another channel dedicated just for personal?17:23
rsalvetinever used personal17:23
ogra_a whole image17:24
* ogra_ forgot what he did to build personal17:24
ogra_but you need the u-d-f that suports the "personal" keyword17:24
ogra_grrr !!!!17:25
* ogra_ wants FFB (focus follow brain)17:25
mterryrsalveti, is sergiusens away?17:29
ogra_GODDAMNED !17:30
mterryogra_, :)17:30
ogra_mterry, he had a kid (and now he has insomnia)17:30
mterryogra_, oh right!  the child!17:30
ogra_back next week (perhaps ...)17:30
rsalvetimterry: yeah, back on monday17:30
* mterry has amnesia himself17:30
mterrymvo_, maybe we better manually merge snapcraft indeed for a couple days17:31
mterrymvo_, just involves me running tests instead of tarmac, not that different17:31
jobotHi, I have owncloud installed on snappy (beaglebone black). I would like to point the storage to a usb drive. I have manually mounted the drive. and did a chown ubuntu:ubuntu. But, when I mount usb to the folder (as root because I have too?), the ownership changes, and becomes unwritable. Ownloud gives this: Can't create or write into the data directory /home/ubuntu/owncloud. Any advice appreciated. Thanks17:32
ogra_jobot, format the dirve ... create a label on it "writable" ... then copy the content from the writable partition on the SD to that ... and delete the writable partition of the SD (or just remove the label)17:33
rsalvetiif blocked by tarmac might just be easier to merge by hand17:33
rsalvetiuntil we have our own tarmac that elopio and federico are working on17:33
jobot@ogra_ , thanks. Does that mean I need to recreate any symlinks to the usb or does that get detected automatically?17:35
nothaljobot: No such command!17:35
elopiorsalveti: I can put a tarmac in canonistack now, but I would have to create a new tarmac-snappy user as I don't have the credentials for the existing one.17:35
elopioI'd prefer to wait and use the same one.17:35
rsalvetiyeah, no need to rush17:35
ogra_jobot, the USB disk simply takes over the writable bits of the SD then yu dont need any symlinks or anything with that method17:35
ogra_rsalveti, a and b contents are identical on the BBB image, right ?17:36
ogra_if i didnt upgrade anything i mean17:36
jobotogra_, thank you. I will give it a go.17:36
rsalvetiogra_: after flashing, yes17:37
ogra_well, indeed17:37
ogra_funny then17:37
ogra_i reliably get "[   20.580754] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517" 8 times in the log when booting from b17:38
ogra_it never shows when booting from a17:38
jobotSecond question: is it possible to have the usb encrypted and mountable easily?17:39
ogra_not yet ...17:39
ogra_(it is definitely planned to support all kinds of disk encryption, but not implemented yet)17:39
jobotok cool thanks17:40
ogra_mvo_, livecd-rootfs seems to have promoted, i trigered a new 15.04 image build now17:43
mterrytedg, poke about the questions you had in focused-assemble, got a sec?17:59
rsalvetijobot: just remember that after you migrate the writable content you'd need to keep the usb stick around18:04
rsalvetiwe definitely need a better way to handle usb storage devices18:05
jobotrsalveti: good point. thanks !18:05
ogra_rsalveti, well, i think moving writable to USB stick is a valid workaround for the moment :)18:08
ogra_(or even tio the 3TB external rotary USB disk)18:09
ogra_thats the beauty of using labels :)18:09
ogra_the new image weems to be up ... (at least udf downloads something)18:12
ogra_*seems ...18:13
* ogra_ will need a break shortly 18:13
mvo_ogra_: snappy itself does not tinker with snappy_ab - well, the code does but it has no affect, on bootsuccess snappy_ab=a it sets it to … "a" :P which is silly as its already set to a (and values that are already set to the same value are not written)18:48
mvo_ogra_, longsleep: I'm happy to add the uboot-go binary, its just so huge (~2mb or so) :/18:49
mvo_mterry: yeah, maybe we do it manually, I have access to tarmac but can not install stuff on the tarmac instance. and sergio is using unattended-upgrades so I can't help myself with the root access either :/18:50
mterrymvo_, I merged one thing automatically already, but hit a snag with one of yours -- commented on it18:50
mvo_elopio: I have access to the tarmac instance, I can get the creds I think18:50
mvo_ogra_: \o/18:51
mvo_mterry: oh, I have a look, thanks18:51
* mvo_ has finished reading backlog18:51
mvo_longsleep: does it mean the uboot.env stuff is working now ? what was the issue that ogra was seeing, do you know?18:51
ogra_mvo_, all working :D18:53
* ogra_ is just playing with image 126 here 18:53
ogra_http://paste.ubuntu.com/11921381/  properly switches back and forth between a and b18:53
ogra_no, it doesnt anymore18:55
ogra_reading uboot.env18:56
ogra_ERROR: Cannot import environment: errno = 2218:56
ogra_mvo_, :(((18:56
ogra_at ../common/env_common.c:221/env_import()18:57
ogra_*** Warning - import failed, using default environment18:57
ogra_mvo_, i had it working by manually adding the config to image 125 ... now it completely broke in 126 ... and i have not the slightest idea why18:58
rsalvetican you check the vfat partition?18:58
ogra_fatls lists everything fine ...18:59
ogra_it also looks different from the corruption errors18:59
ogra_(and i really cant focus anymore ... i need to stop soon)18:59
ogra_i suspect it has somethign to do with the way the config is created ... thats the only difference we have19:00
ogra_(the fw_setenv config)19:01
elopiomvo_: great, please send them to me. Also if you can copy the tarmac config, that would be handy.19:03
mvo_ogra_: hm, errno 22 is invalid argument in linux at least, wonder if uboot is the same. not more infos?19:13
mvo_ogra_: aha, nevermind, take a break :)19:13
mvo_elopio: sure thing, or if you have a instance just add my ssh key and I scp everything over19:14
mvo_elopio: and turn the other tarmac off19:14
elopiomvo_: your keys are imported,
tedgmterry, Just got back (long story) are you around now?19:26
mterrytedg, heyo19:57
mterrytedg, sorry, had a contractor come by to look at some winter damage19:57
mterrytedg, so I replied to you in merge comments, but wanted to drop to IRC to fully understand the issues in #2 (how snappy handles paths)19:58
tedgmterry, Hmm, I don't see the reply. Let me check LP.20:00
tedgmterry, So I guess that the snappy build does do that, but I'm not sure how I'd reference something in the path then.20:02
mterrytedg, I don't think you do, not at the snappy-command level20:03
tedgmterry, The QML plugin is setting up the PATH to include qmlscene20:03
tedgmterry, I don't want the project to care where qmlscene is installed20:03
mterrytedg, your plugin can install a thin wrapper that is basically "#!/bin/sh; qmlscene $*" or hardcode the qml there too if you know it20:04
mterrytedg, i.e. drop to shell in order to use PATH20:04
mterryAnd then have the user put your wrapper at the exec line20:04
tedgSure, trying to avoid having everyone build a shell script20:04
mterrytedg, i.e. bin/qmlplugin myqmlfile.qml20:04
mterrytedg, well the user wouldn't do it20:05
mterrytedg, or you could basically just have the plugin install a symlink20:05
mterrytedg, I'm trying to think of ways for you to have users not care about where your plugin puts qmlscene20:05
mterrytedg, so I'm saying your plugin can put a symlink (or thin wrapper) somewhere in a place that you "own" and would tell users to run20:05
tedgmterry, They have to define the exec statement20:06
mterrytedg, so maybe that's a toplevel "runqml" symlink20:06
mterrytedg, or "bin/runqml" that users of your plugin put in the exec statement20:06
mterrytedg, (or you could just tell users to put usr/bin/qmlscene there)20:06
tedgI guess I don't understand why it has to be different than running it on my development system.20:06
tedgqmlscene foo.qml20:06
mterrytedg, snappy is a whole different thing man20:06
mterrytedg, that's just not how exec lines work20:06
mterrytedg, (unless you put a qmlscene symlink at the toplevel)20:07
mterrybut at that point, you're just faking it so it looks like it's a PATH references20:07
tedgSnapcraft could fix that :-)20:07
mterrytedg, I mean, we basically do for everything *AFTER* that entry point20:07
tedgIf you're pulling things in with teh Ubuntu plugin, you probably want them to be in the PATH (they are) so I think it makes sense to use them as such.20:07
mterrytedg, but that entry point itself is a snappy thing, and is a relative path20:08
tedgSo I'm saying that the snapcraft wrapper should allow using the PATH that is already in that same wrapper.20:08
tedg(which if you're using Ubuntu, it is)20:08
mterrytedg, ... so you want in your case of 'qmlscene', you want snapcraft to make a 'qmlscene.wrapper' file at, I dunno, the toplevel, which which assumes that the exec line was not in fact a standard snappy exec line but actually a PATH reference. I'm leery of doing that as a matter of course.  And it feels silly to have an option for that20:10
mterrytedg, maybe if we detect that the file doesn't exist20:10
mterrytedg, and we could check all the PATH locations....20:11
mterrytedg, find it, and stuff that into the exec line instead20:11
mterrytedg, that's awfully magic20:11
mterrytedg, just to avoid people learning a tiny bit about how snappy works  :)20:11
mterrytedg, but it seems like a harmless feature to add20:11
mterrytedg, but I'm comfortable making that a separate branch  :)20:12
tedgmterry, Heh, okay.20:12
tedgmterry, I'm not sure if we need to search the PATH, I think we can just assume the path if it doesn't exist.20:12
mterrytedg, it is a decent way to avoid what may be a common problem for people unused to snappy, indeed.  I'll file a bug20:13
mterrytedg, well, someone may have legitimately made a typo or not understood something.  We know what the PATH will be at that point, so it's harmless to check20:13
mterrytedg, though maybe it will be hard to know what is in Core vs the snap, if the first command is a Core exec20:13
tedgmterry, We'd have to run it through a shell, we're not actually evaluating the PATH.20:13
tedgI think the point of Snappy is "assume nothing is core" right? ;-)20:14
mterrytedg, we can parse all the env vars that are PATH= that the plugins give us into the snap20:14
mterrytedg, yeah but what if the first exec fragment is "env"20:14
mterrytedg, maybe that's just not allowed (it wouldn't be by base snappy I don't think)20:14
tedgmterry, Heh, then right now you'll rewrite it as "$SNAP_APP_PATH/env" ;-)20:15
mterrytedg, which is what snappy itself would do.  I don't think that's a bug in the current instance20:15
mterrytedg, I was just seeing if we could be more magic there for the user.  But I don't think we want to in that case20:15
mterrytedg, how about https://bugs.launchpad.net/snapcraft/+bug/1477286 ?20:20
ubottuLaunchpad bug 1477286 in Snapcraft "Support PATH-resolved commands in exec lines" [Undecided,New]20:20
mterrytedg, and credited you in a comment  :)20:21
tedgmterry, Heh, that works.20:21
mterrytedg, I also have a bunch of source-option branches if you're feeling review-y20:24
tedgmterry, Sure, source-options, more-source-options?20:26
mterrytedg, and source-tarball20:26
elopiomterry: did you need any other package installed in tarmac, in addition to python3-fixtures?20:26
mterryelopio, I will also probably need git, bzr, and xz-utils (if they aren't already there)20:27
mterrytedg, source-* options may change in further spec discussions too.  I just wanted something in place to not block people and other work.  All yaml is changeable  :)20:42
mterrytedg, and I admit that git isn't my first language.  I just did something I found would work.  I miss bzr's easy to understand revnos20:43
tedgmterry, Yeah, at least Linus admitting not having them was a mistake :-)20:47
tedgCool, let me get qml updated for trunk. (and see if it still works :-) )20:51
mterrytedg, you're right...  I'll make a little unit test for isurl20:53
mvo_ogra_: for tomorrow, one data point with r126 and the corruption is that I see is that there is a "=b" entry in printenv. I can get that by typing "setenv "" b; saveenv" in the u-boot prompt and I wonder if somehow something in our bootscript sets a empty var to b. something like "setenv $some_var_that_is_not_defined b; saveenv" or something. once there is a empty key in the uboot env it seems it can no longer load the file. but looking at uboot20:53
mvo_.env.in I don't see anything like this20:53
mvo_ogra_: so manybe/probably a wrong theory20:53
ogra_mvo_, i noticed that i have an 8 byte header on the unreadable file20:54
mvo_ogra_: could you pastebin the hexdump -C uboot.env |head output please?20:55
ogra_mvo_, i'll check the quoting tomorrow, it isnt consistent in snappy_boot ...20:55
ogra_mvo_, http://paste.ubuntu.com/11922519/20:55
mvo_ogra_: the "=1" is a key=value, the key is just empty, should not happen of course and I wonder what is triggering it20:56
ogra_mvo_, then i'm sure it is the quoting in snappy_boot ... i changed some bits in 125 when i tested it20:57
mvo_ogra_: it could be, yeah, I managed to corrupt my file in a similar way with setenv "" x ; saveenv in the uboot prompt20:58
ogra_(because i couldnt use fw_setenv initially)20:58
mvo_ogra_: there is something funny with the fw_setenv in 15.0420:58
mvo_ogra_: I have strange issues here too20:58
ogra_well, it worked for at least 50 boots for me with 12520:58
ogra_i didnt have any comments in my config ... thats the only difference on that layer20:59
mterrytedg, thanks for the reviews!20:59
mvo_ogra_: hm, hm, if it worked in 125 and no longer in 126 its probably something else20:59
ogra_(i actually wonder if fw_*'s config handling is comment safe :=)20:59
mvo_ogra_: haha20:59
ogra_well, I#ll re-work tezh snappy_boot command tomorrow morning i know it can work for 50 boots without any issue21:00
mvo_ta, lets check it out tomorrow and I let you kow if I notice anything21:00
ogra_now it breaks reliably the third boot21:01
mvo_ogra_: and I remove the comments21:01
ogra_heh, i wasnt actually serious :)21:01
mvo_I know21:01
mvo_but I am ;)21:01
mvo_every 3 boots you say?21:01
ogra_i'm pretty sure its snappy_boot that breaks us21:01
ogra_well, when switching back from b to a21:01
mvo_snappy_boot in snappy-go ? or in the bootloader itself?21:02
ogra_in uboot.env21:02
ogra_its a var21:02
ogra_the thing that carries the a/b logic21:02
ogra_i already noticed the quoting is pretty inconsistent, that needs fixing anyway21:02
mvo_ogra_: ok, lets hope that its that and I will get some rest :)21:03
ogra_oh man21:04
ogra_i see whats wrong ... after the setenv snappy_ab "a" and snappy_ab "b" there needs to be a saveenv indeed21:04
mvo_ogra_: nice, hope its that. here is what I see when its broken:21:06
mvo_fw_printenv|cut -f1 -d=|sort|head21:06
mvo_meh, http://paste.ubuntu.com/11922579/ is better. a empty key in the first line21:07
ogra_perhaps we should really take uboot-go instead21:07
ogra_even if it costs 2M21:08
mvo_might be me corrupting it, I just don't know right now :/21:08
mvo_ogra_: this is what I did: http://paste.ubuntu.com/11922587/21:09
ogra_well, thats wrong21:09
ogra_though it shouldnt break anything21:09
ogra_you want to set snappy_trial_boot 1 ... not snappy_ab b21:10
ogra_setting snappy_ab happens inside the bootloader later21:10
mvo_ogra_: snappy_trial_boot is what the bootloader sets itself, snappy just cleans that21:10
mvo_ogra_: at least thats how grub is doing it21:11
ogra_well, see the snappy_boot command i pasted above21:11
ogra_it checks for that being set21:11
mvo_yeah, it uses that to detect that the boot failed, i.e. if its in "try" mode and it has not booted successfully (trial boot is set) it will revert back to the previous partition21:12
ogra_hmpf, then i tested wrong21:13
mvo_so when the bootloader sees try it will set trial_boot=1 and then booted OS is expected to clean that21:13
mvo_its confusing :/21:13
ogra_i did set snappy_trial_boot to 1 and snappy_mode to try21:13
mvo_that should be ok, that simulates the fallback to the other patition21:14
mvo_with that it should simpliy toggle21:14
mvo_or flip-flop :)21:14
mvo_meh, I whish it would boot faster21:16
ogra_cloud-init is a pain21:17
ogra_and something still hangs with th NIC startup21:17
mvo_ogra_: ok, the bug is on my turf, I just ran "snappy booted" manually and managed to trigger it without rebooting21:18
mvo_ogra_: so its not uboot21:18
ogra_P H E W  !21:19
mvo_oh, wait21:19
ogra_mvo_, i still dont get how it worked in 125 and stopped working in 12621:22
ogra_did you do a snappy upload alongside the livecd-rootfs one ?21:23
* ogra_ thoguht adding the config was the only change 21:24
Chipacamvo_: ogra_: you guys are up way past your bedtime21:28
ogra_Chipaca, you not ?21:28
ChipacaI'm 1h behind you21:28
Chipacaand my eod is always late :)21:29
ogra_(definitely hours before my bedtime though ... but far past my EOD time :) )21:29
Chipacaalso feeling a little bit guilty that the biggest problem i'm wrangling is around naming, and you guys are fighting uboot21:30
Chipacabut the feeling will pass i'm sure21:30
ogra_hah, i like bootloader wrangling :)21:30
mvo_ogra_: I can not find a way to trigger it reliable21:39
mvo_ogra_: I guess my best option for now is rest21:40
ogra_yeah, same here ... we'll nail it tomorrow ...21:40
* mvo_ waves21:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!