=== retrack is now known as Guest2661 [06:26] good morning [07:05] good morning [07:17] hey [07:18] mvo, howdy, question for you ... do you know why the docker group is added to the ubuntu-core image? is docker needed for some snappy features to work? or it's just to enable the docker snap to be installed since groups can't be added later? [07:18] context is snappy personal/desktop and knowing if that group is needed there [07:40] seb128: yes, its needed for docker and we can not yet add groups later [07:40] seb128: it won't be needed on desktop [07:40] mvo, k, why is docker special cased? Just because it's a popular demo? [07:41] or is it needed for snappy features to work? [07:41] seb128: because it was the only way to get docker working :) and its a important package for us [07:42] mvo, but it's not on the personnal desktop image? [07:42] just making sure :-) [07:42] well, let's start without it [07:42] we can do similar hack later if needed [07:43] seb128: yeah, just go without it for now [07:43] but I guess we are going to need a solution to this groups problem [07:43] seb128: we sort of have, we have libnss-extrasusers on the image, we just have no mechanism that can write to it [07:43] ah, I see [07:43] mvo, thanks :-) [07:44] and yeah, its a known issue, we need to solve that and add adduser support for extrasusers plus a snappy extension that can add additional user === davmor2_hols is now known as davmor2 [08:27] ppisati, do you have an image anywhere with the working 1G RAM on the RPi2 ? i have tried all combos of uboot and kernel that i can find and cant ever get more than 256M [08:27] ogra_: yes i do [08:28] ogra_: https://github.com/piso77/ubuntu-embedded [08:28] ogra_: sudo ./make_img.sh -b raspy2 -d 14.04 [08:28] all i found was the early version on p.u.c [08:28] ogra_: or i can build one for yo [08:28] ogra_: and put it somewhere [08:28] oh, i meant a binary, no i can build it myself ... is that buildin an actual snappy image ? [08:28] ogra_: nope, vanilla ubuntu [08:29] ogra_: but i'm using uboot, ppa kernel, etc [08:29] ok [08:30] seems to me like the kernel does not actually get to change any memory settings with the current setup i have ... it always only shows whatever the start.elf initialized [08:31] ogra_: do you have a dmesg of your kernel? [08:31] ogra_: or a log of the entire boot? [08:31] several, yes, my screen is set to auto-logging :) [08:31] ogra_: but try that img, has 1G of ram [08:32] i will === dholbach_ is now known as dholbach === dholbach_ is now known as dholbach [08:57] ppisati, (sorry, was dragged into a meeting) here is the screen log of various boots http://people.canonical.com/~ogra/scree-rpi.log [08:58] ogra_: do we know what this is https://www.raspberrypi.org/downloads/snappy/ [08:59] ogra_: my colleague installed it and it's some version of vivid [08:59] (the third last is your old 3.18 image from people.u.c, which was the only one i had 1G with yet, all other boots have either 128 or 256M depending on which start.elf i use) [08:59] zyga, it should be some old snappy version of vivid [08:59] i'm just trying to get an updated image together (but struggle with it a little) [09:00] ogra_: for rpi2? [09:00] yes [09:00] ogra_: thanks, I have kissiel here who will gladly use one when available [09:01] zyga, I missed some of your conversation, are you talking about the image? [09:01] i'll send a mail announcement once it is done ... [09:01] kissiel: yes [09:01] zyga, cool [09:01] kissiel: it seems that there is no updated image yet, just wait for ogra_'s announcement [09:01] ogra_: thanks, I owe you way too many beers, perhaps at fosdem :) [09:01] zyga, I'll build it from scratch then [09:02] heh :) [09:10] ogra_: what you see if you do a cat /proc/meminfo? [09:11] (RaspberryPi2)ubuntu@localhost:~$ cat /proc/meminfo |grep Total [09:11] MemTotal: 119468 kB [09:11] SwapTotal: 0 kB [09:11] VmallocTotal: 1941504 kB [09:11] CmaTotal: 8192 kB [09:11] with the most recent boot ... [09:11] ubuntu@raspy2:~$ uname -a [09:11] Linux raspy2 3.19.1-11-generic-bcm2709 #11-Ubuntu SMP PREEMPT Tue May 26 10:34:36 UTC 2015 armv7l armv7l armv7l GNU/Linux [09:11] (do you need all of it ?) [09:11] ubuntu@raspy2:~$ cat /proc/meminfo [09:11] MemTotal: 947020 kB [09:11] ... [09:11] ogra_: i can put the img somewhere if you want [09:11] (RaspberryPi2)ubuntu@localhost:~$ uname -a [09:11] Linux localhost.localdomain 3.19.1-11-generic-bcm2709 #11-Ubuntu SMP PREEMPT Tue May 26 10:34:36 UTC 2015 armv7l armv7l armv7l GNU/Linux [09:11] same kernel [09:12] it's definitely the binary blob or uboot [09:12] do you have anything special on the cmdline ? [09:12] wait [09:12] ubuntu@raspy2:~$ cat /proc/cmdline [09:12] earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd [09:12] ogra_: do you? [09:12] console=tty0 console=ttyAMA0 root=/dev/disk/by-label/system-a init=/lib/systemd/systemd ro panic=-1 fixrtc [09:13] nothing :) [09:14] * ogra_ grumbles about /var/log/dmesg being empty [09:14] ogra_: i'm uploadinf that img [09:14] ppisati, thanks, i'll try mine with your bootloader [09:14] i wonder if it is the uboot.env that loic created [09:15] ogra_: all the bootloader binaries i'm using [09:15] ogra_: are here, btw [09:15] ogra_: https://github.com/piso77/ubuntu-embedded/tree/master/boards/raspy2/bootloaders [09:15] well, i tried them [09:16] didnt make any difference [09:16] you dont load an initrd ... [09:16] perhaps our load address is wrong and we trash something when loading it [09:16] ogra_: but the initrd is discarded by the kernel [09:17] ogra_: one thing that i noticed in your bootlog [09:17] ogra_: is that the kernel can actually see the entire mem [09:18] ogra_: bullshit [09:18] where do you see that ? [09:18] ogra_: i read it wrong [09:18] [ 0.000000] Memory: 95036K/131072K available (6873K kernel code, 437K rwdata, 1972K rodata, 448K init, 782K bss, 27844K reserved, 8192K cma-reserved) [09:18] yeah [09:18] [ 0.000000] Memory: 938380K/966656K available (6873K kernel code, 437K rwdata, 1972K rodata, 448K init, 782K bss, 20084K reserved, 8192) [09:18] that's my img [09:18] yup+ [09:19] ogra_: you should try to load the initrd with my img [09:19] will do [09:19] ogra_: http://people.canonical.com/~ppisati/disk-2015-06-04-14.04-raspy2.img.gz [09:21] jdstrand: hi, for later when you are online - now that we have a private /tmp via the ubuntu-core-launcher I proposed to simplify our /tmp handling (bug https://bugs.launchpad.net/snappy/+bug/1462916). apparmor would need to be updated and /tmp would have to be allowed. do you have any concerns about this approach? i.e. shifting the security from apparmor to the launcher (I put some info into the description) [09:21] Ubuntu bug 1462916 in Snappy 15.04 "Simplify TMPDIR handling" [Undecided,New] [09:23] jdstrand: would love to hear your opinion on this :) [09:26] Hi folks, is there a way to solve "Failed to start Load/Save Random Seed." error on boot? [09:27] * ogra_ has been wondering that for ages :) [09:28] * longsleep will investigate [09:29] Good morning all; happy Monday, and happy Upsy Daisy Day! 😃 [09:33] hi - can anyone tell me which devices are officially supported by Snappy Ubuntu and which of those have stable images? [09:40] So the problem on the systemd-random-seed service is that it tries to write to /var/lib/systemd/random-seed which is read only. That is very bad as essentially all snappy devices boot up with little to no entropy, at least if the Kernel does not have http://lkml.iu.edu/hypermail/linux/kernel/1312.1/04772.html [09:41] longsleep, can you file a bug ? [09:41] we should definitely shipo that dir writable [09:42] well random-seed is a file - i am not sure if the whole /var/lib/systemd should be writeable [09:42] mvo, ^^^ i guess you agree [09:42] not sure we can make the whole dir writable ... but surely that file [09:42] ok - i file a bug [09:42] * mvo nods [09:43] (for the dir we'd need to ask the security team about possible impact) [09:44] * longsleep thinks the security team should think about entropy and randomness [09:44] Snappy bugs go here: https://bugs.launchpad.net/snappy ? [09:44] yep [09:51] What Kernel version is the default for Snappy images if no device tree is provided? [09:59] (RaspberryPi2)ubuntu@localhost:~$ free [09:59] total used free shared buffers cached [09:59] Mem: 947012 120888 826124 12768 6684 81884 [09:59] ppisati, ^^^ [09:59] \o/ [10:00] yo! [10:00] what was that? [10:00] but i blindly copied your whole dir into my image [10:00] ogra_: so it was the bootloader [10:00] i'll now start removing file by file and see when it drops back to 128M [10:00] ogra_: cool, nice find [10:01] well, we dont ship any of the fixup files ... or any extra config.txt or cmdline.txt [10:01] i suspect it is related to that [10:02] Random seed service bug report here: https://bugs.launchpad.net/snappy/+bug/1462954 [10:02] Ubuntu bug 1462954 in Snappy " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [Undecided,New] [10:03] longsleep, thanks [10:03] jdstrand, can we get some security team opinion on bug 1462954 if we can make the whole dir writable or not [10:04] ogra_: I think a real solution would be to make the random-seed file available to both system-a and -b (it should be shared). [10:05] yeah, that should happen automatically ... [10:05] the writable partition is shared between them ... [10:06] ogra_: ah i see - thats cool then [10:06] (RaspberryPi2)ubuntu@localhost:~$ sudo snappy install webdm [10:06] Installing webdm [10:06] .... [10:06] operation not supported [10:06] webdm failed to install: unpack /tmp/webdm683385157 to /apps/webdm/0.8 failed with exit status 1 [10:06] (RaspberryPi2)ubuntu@localhost:~$ [10:07] grmpf ... [10:07] Jun 8 10:06:31 localhost snappy[857]: main.go:62: DEBUG: [snappy internal-unpack /tmp/webdm683385157 /apps/webdm/0.8 /] failed: operation not supported [10:07] Jun 8 10:06:31 localhost snappy[824]: main.go:62: DEBUG: [snappy install webdm] failed: webdm failed to install: unpack /tmp/webdm683385157 to /apps/webdm/0.8 failed with exit status 1 [10:07] hmm, not so informative ... [10:10] dang ... and i get that for every snap it seems [10:10] ppisati, are we sure the kernel has all necessary options set ? [10:11] (apparmor and systemd etc ...) [10:11] So, now that i have a base image. How can i modify the image after build? Are there some post hooks or something? [10:11] ogra_: it's the same kernel + config options since... [10:11] ogra_: months? [10:11] ogra_: wait [10:11] i used your latest deb for this image [10:12] ah, i forgot to push it [10:22] ogra_: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_raspi2 [10:46] mvo: really, TMPDIR is cleared in setuid? [10:46] daaarn [10:47] * Chipaca has one of those "how did this ever work then" moments [10:56] * kissiel is away: lunch [11:02] Chipaca: yep - but all under control we just need to decide what approach to take [11:02] Chipaca: its only cleared for users, i.e. when running as root its fine [11:26] wow, so removing all new files but fixup.dat gets me a completely messed up boot [11:55] mvo, sergiusens, Chipaca, so i have a working edge RPi2 image now ... but i cant install any snaps ... all info i get in syslog is the line above (operation not supported) ... any hint how i can debug that a bit more detailed than from syslog [11:57] ogra_: is that edge? or 15.04 ? [11:58] sudo ubuntu-device-flash core --channel=edge --oem pi2_0.12_all.snap --developer-mode --device-part=device-pi2-0.12.tar.xz -o pi2.img rolling [11:58] ogra_: is this a wily snappy? [11:58] thats what i used to build it [11:58] ogra_: if so it's build with go 1.4 [11:58] yeah, wily [11:58] ogra_: and something is busted there [11:58] oh, so it is also broken on BBB ? [11:58] ogra_: in wily, yes [11:58] * mvo looks [11:58] * ogra_ has no recent BB image around, else i would have cross checked [11:58] ogra_: and amd [11:58] ah, phew [11:59] * ogra_ goes and builds a 15.04 image then [12:00] ogra_: that is the 'rolling' parameter to your ubuntu-device-flash command from above? [12:01] it picks the rollin channel from http://system-image.ubuntu.com/ubuntu-core/ [12:01] +g [12:01] sudo ubuntu-device-flash core --channel=stable --oem pi2_0.12_all.snap --developer-mode --device-part=device-pi2-0.12.tar.xz -o pi2.img 15.04 [12:01] thats builds from the release channel ... [12:01] -s [12:02] i see thanks - still a lot i dont know about :) [12:02] well, system-image will be going away [12:02] images will be fully built from snaps [12:03] * longsleep is trying to build rolling edge image for ODROID C1 now [12:03] ogra_: that sounds awesome [12:07] Channel: edge, Version: 63 - does that sound good? [12:08] yes, but it will be broken as you can see above :) [12:08] wont allow you to install snaps [12:08] ogra_: thats what i wanted to confirm [12:08] ah [12:08] to verify that the image i build behaves the same as yours [12:08] the release image works fine :) [12:09] yes here too [12:12] * ogra_ installs chatroom to test [12:13] GRRR [12:13] ERROR: chatroom.ogra failed to install: unpack /tmp/snaps/webdm/0.8/tmp/chatroom275084212 to /apps/chatroom.ogra/0.1-8 failed with exit status 1 [12:14] so this is with 15.04 now [12:14] tryin to install chatroom from webdm [12:14] mhm it was not yesterday [12:16] * ogra_ tries from cmdline [12:16] ogra_: ok ok edge rolling it fails for me too [12:18] ha, cmdline works fine [12:18] seems to be a bu in webdm [12:18] *bug [12:19] mhm i just tried from cmdline [12:19] http://paste.ubuntu.com/11647904/ [12:19] worked fine for me [12:19] and i can reach the chatroom at port 6565 in chromium [12:20] * ogra_ tires another package from webdm [12:20] http://paste.ubuntu.com/11647909 [12:20] (thats on edge though) [12:20] yeah, there it seems to be expected [12:21] so cmdline works in 15.04 but not in webdm? [12:21] * longsleep tries that [12:22] only for the chatroom package it seems ... go-example-webserver installed just fine [12:22] * ogra_ tries pastebinit [12:22] hmm, weird, works too [12:23] i will be trying to build a snappy release https://github.com/strukturag/spreed-webrtc next weekend so i get familiar with these things too. [12:23] * ogra_ uninstalls chatroom and tries again [12:23] ah, nice [12:23] chatroom in a more complex way :) [12:24] yeah - i didnt know about chatroom since yesterday [12:24] well, its just a hacked together example to test node-snapper :) [12:25] webrtc stuff makes a good show if your snappy install is in the local LAN when you hold talks ... you can involve the audience easily ;) [12:26] hey folks, is this a good place to be asking stupid questions about making snaps? [12:26] mattyw, only if you promise they are really stupid :) [12:26] mattyw: if you start ask stupid questions too i do not feel so alone :) [12:27] awesome, I'll do some typing and we'll see where we end up [12:27] ha [12:27] woah ! [12:27] Jun 8 12:24:32 localhost ubuntu-core-launcher[962]: open /apps/chatroom.ogra/0.1-8/amd64/node_modules/express/lib/middleware/init.js: permission denied [12:27] Jun 8 12:24:32 localhost ubuntu-core-launcher[962]: 2015-06-08 12:24:32 ERROR snappy logger.go:199 chatroom.ogra failed to install: unpack /tmp/snaps/webdm/0.8/tmp/chatroom031296173 to /apps/chatroom.ogra/0.1-8 failed with exit status 1 [12:28] WTF ! [12:28] so - I'm trying to make a tmux snap - because why not. After it's installed I run tmux.tmux and I get told ERROR: profile "tmux_tmux_1.9.6" does not exist. [12:28] my next question is - tmux requires libevent - so I need to install that somewhere, what should I be doing with SOs? [12:28] mattyw, did you check for apparmor denials in syslog ? [12:28] mattyw: not sure if that qualifies for a stupid question - but if you want a stupid answer - i guess its related to apparmor profiles :) [12:29] libs should go into your snap with LD_LIBRABRY_PATH pointing to their dir [12:31] ogra_: Chipaca is debugging that on wily - or do you get the above error on 15.04? [12:31] mvo, yes ... note the "amd64" in that error [12:31] (i'm obviously on armhf) [12:31] longsleep, ogra_ awesome, just as an experiment can we talk about apparmor profiles and LD_LIBRARY_PATH as if I don't know anything about those things? ;) [12:32] mvo, it looks like an ownership error with the file to me ... though installing from commandline with snappy install doesnt show that error [12:32] ogra_: chatroom installs just fine here: http://paste.ubuntu.com/11648126/ [12:33] longsleep, yeah, for me too if i use the commandline [12:33] just not from webdm [12:33] ok let me try [12:33] webdm generates the permission denied error above in syslog [12:34] bah, now it also fails from cmdline :( [12:34] open /apps/chatroom.ogra/0.1-8/amd64/node_modules/express/node_modules/cookie-signature/.npmignore: permission denied [12:34] another permission error ... different file though [12:35] and i also get: [12:35] 2015/06/08 12:33:52 Warning: failed to remove /apps/chatroom.ogra/0.1-8: %!s() [12:35] chatroom.ogra failed to install: unpack /tmp/chatroom360659173 to /apps/chatroom.ogra/0.1-8 failed with exit status 1 [12:35] hmm [12:35] (RaspberryPi2)ubuntu@localhost:~$ ls /apps/ [12:35] bin chatroom.ogra go-example-webserver.canonical pastebinit.mvo webd [12:35] and in fact i have an empty chatroom.ogra dir under apps [12:36] snappy remove chatroom.ogra doesnt remove the dir [12:36] ogra_: if that is still wily, then I think Chipaca found the issue, setgid does no longer work with go 1.4 [12:36] mvo, no, thats still 15.04 [12:37] ogra_: failed for me too with webdm [12:37] plenty of errors in syslog [12:37] mvo: hey, any reason we update-grub on updates? [12:37] mvo, i gave up on rolling for now, need to get that Pi image to work [12:37] ogra_: *ick* do you get that on bbb/kvm? [12:37] surely not on kvm [12:38] i developed the new chatroom package in kvm, there it always worked fine [12:38] sergiusens: well, thats what updates grub.cfg? or am I misunderstanding the question? [12:38] and one out of three install attempts on the 15.04 RPi image worked too [12:38] mvo: yes and it causes a nice bug [12:38] (resulting in a working chatroom) [12:39] sergiusens: *autsch* which one? the one you reported friday? [12:39] ogra_: My syslog when installing chatroom though webdm on 15.04 http://paste.ubuntu.com/11648298/ [12:39] mvo: yes [12:39] Jun 08 12:36:28 odroid systemd[1]: [/lib/systemd/system/snappy-workaround-apparmor.service:5] Unknown lvalue 'WantedBy' in section 'Unit' [12:39] wow [12:39] ogra_: meh [12:40] longsleep, are you sure you have all ubuntu apparmor patches in your kernel ? [12:40] ogra_, ah, I just have to do LD_LIBRARY_PATH=my_snap_lib_dir ./myapp, that's what you mean right? there's no magic other than that? [12:40] longsleep: (I like you nick!) - he "'WantedBy'" is my bug, sorry for that [12:41] ogra_: no i have not all the patches - currently running unmodifed hardkernel tree [12:41] longsleep, ah, then your issue is different [12:41] mvo, http://paste.ubuntu.com/11648369/ [12:42] mvo: https://bugs.launchpad.net/snappy/+bug/1462501 [12:42] Ubuntu bug 1462501 in Snappy trunk "Updates on grub systems lose track of panic=-1" [Critical,New] [12:42] mvo: no worries - i am new to snappy and trying to figure out the ecosystem [12:42] mvo: removing update-grub solves the azure problem [12:42] longsleep, the systemd kernel config options and apparmor are both essential [12:42] ogra_: ok i have "look at kernel patches" on my list :) [12:43] longsleep, ppisati can most likely help you [12:44] ogra_: problem is that i am on Kernel 3.10 + messy patches. I hope the patches required are small :) [12:44] in fact it is the whole of apparmor you need to replace [12:44] mvo: Do you want me to file a bug for the "'WantedBy'" problem? [12:45] and there is a bunch of cgroups options that snappy uses [12:45] for systemd [12:45] some work for tonight then :) [12:47] longsleep: feel free, but I think I know the reason and work on a fix [12:48] longsleep: https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels for easy apparmor instructions [12:48] sergiusens: thanks! [12:50] ogra_: are you using 15.04/edge? [12:51] guess that only stable will get you 15.04/stable [12:51] rsalveti, edge is obviously completely broken [12:51] rolling you mean? [12:51] which made me switch to 15.04 stable 1h ago [12:51] well, edge/rolling [12:51] 15.04/edge should be good [12:51] rolling/edge is known to be broken [12:52] 15.04 stable is broken for me too [12:52] let me try 15.04 edge then [12:52] right, 15.04/edge is what we're trying to release :-) [12:52] but currently blocked by the grub issue [12:53] ogra_: did you find out the reason why you can now access the entire 1gb ram on rpi2? [12:53] rsalveti, bootloader [12:53] took me 4 days but i finally found the working combo of files :) [12:54] oh, great then [12:54] using kernel7.img without config.txt makes the bootloader ninary fall back to some weird bits [12:55] *binary [12:55] my oem snap now uses uboot.bin again with a confi.txt pointing to it [12:55] and you need the fixup.dat file apparently [12:56] once i found a working combo that actually doesnt break when installing snaps i'll push that to people.u.c [12:58] great [12:58] well, not so great that on all images i tried yet the snap installation has issues [12:59] * ogra_ boots 15.04 edge and crosses fingers [13:00] wonders if the 'WantedBy' is also in 15.04/edge [13:00] no, we were both tryin stable [13:00] +g [13:00] ogra_: it's g+ [13:01] :P [13:01] ogra_: no i was trying 15.04/edge [13:01] oh [13:01] i was not aware about the distinction [13:01] sergiusens: meh [13:01] i am now :) [13:01] sergiusens: I look at the bug now, it looks a bit like its not going to be fun [13:02] * mvo makes a extra big cup of tea [13:02] ok, webdm installed [13:02] * ogra_ tries installing chatroom via UI again [13:03] ogra_: that even works for me without the kernel patches [13:03] right, but your apps wont be confined [13:03] saying that i just wonder what the difference is regarding installing from webdm and commandline one fails because of missing kernel patches while the other works fine [13:04] yay [13:04] chatroom installed fine [13:04] nice [13:04] mvo: guess we'd also need to upload ubuntu-core-config to wily [13:04] just saw your change [13:04] mvo: rsalveti well I have the workaround fix [13:05] rsalveti: yes, also lp:~chipaca/snappy/muppets needs to land to unblock will [13:05] mvo: but we are indeed crippled [13:05] rsalveti, ok, looks like this image works, i'll push it to my people.u.c account and mail a call for testing [13:05] sergiusens: oh, the workaround to use the core config? [13:06] mvo: yeah, as mentioned in the bug https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/panic/+merge/261378 [13:06] neat [13:06] mvo: but I also extended u-d-f to be able to add a grub.cfg in the oem snappy package, it would work fine if update-grub was not part of a snappy update [13:07] mvo: it also breaks the semantics for when we truly decouple kernel and os [13:07] snake works too ! [13:07] ogra_: great [13:07] sergiusens: yeah, I think we need a static grub.cfg just like uboot [13:07] :q [13:07] I'll be triggering a new rootfs in a few (once ubuntu-core-config) gets published [13:07] mvo: I have this azure one alreay :-) [13:07] rsalveti, oh, then i'll wait for that [13:07] then wait for the grub fix [13:07] sergiusens: post it! [13:07] mvo: I'm just looking for blessings to remove update-grub [13:07] * ogra_ needs to mow the lawn before it rains anyway [13:08] rsalveti: https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/panic/+merge/261378 [13:08] * rsalveti wondering what would be the side effect of removing update-grub [13:08] sergiusens: +1 from me for this, we "just" need to expand handleAssets() for grub [13:08] * ogra_ afk [13:08] mvo: expand or reduce? :-) [13:09] sergiusens: well, expand as its empty right now ;) and then remove 20_snappy from grub config [13:09] sergiusens: let me know if you want help with that, I look forward to simplify this area of the code [13:09] sergiusens: I cherry pick you azure fix in the meantime for vivid, ok? [13:10] mvo: sure, but this doesn't fix azure [13:10] sergiusens: it does not? [13:10] mvo: only the fact that we lose panic=-1 on snappy updates [13:11] mvo: if I remove update-grub from snappy update's code path there is no work in handleAssets (immediate at least) as grub.cfg sits in the common area [13:11] which makes the fact that we are running update-grub slightly worse ;-) [13:11] as rollbacks are endangered [13:11] indeed [13:12] sergiusens: I'm confused, but let me try to work it out after I cherry-picked your workaround fix [13:13] mvo: update-grub creates a grub.cfg in /boot/grub/grub.cfg based out of what is in system-a or system-b [13:14] sergiusens: fix for vivid uploaded [13:17] sergiusens: I guess we mean the same. so if we would stop calling update-grub today, what would write /boot/grub/grub.cfg? [13:17] mvo: u-d-f on device provisioning [13:17] mvo: or ... (one sec) [13:17] * sergiusens commits and pushes [13:17] sergiusens: and if the kernel is updated to a new ABI version? [13:18] sergiusens: oh, are you suggesting to use /vmlinuz, /initrd.img for this? [13:19] mvo: so this may need more thought [13:19] links should help yeah [13:19] mvo: but I would standarize the names [13:19] as long we're covering the update and rollback with them [13:19] meh, yeah, the rollback is a problem with that, I think we need handleAssets for this [13:20] sergiusens: +100 for the idea though, I think that will make things much easier [13:21] mvo: ok, I'll start with this [13:21] and here https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381 [13:21] * sergiusens needs to run some errands [13:23] sergiusens: looks like a good start :) will you continue once you are back from errands or shall I look at what is needed for handleAssets() ? [14:25] tyhicks: would you mind commenting on the TMPDIR conversation ^ (this is also bug https://bugs.launchpad.net/bugs/1462916) [14:25] Ubuntu bug 1462916 in Snappy trunk "Simplify TMPDIR handling" [Undecided,New] [14:29] jdstrand: sure - give me a bit to finish reading email and then read backscroll in here [14:29] tyhicks: I think they are proposing what we understood to be the plan [14:32] mvo: I can continue [14:34] sergiusens: cool, please merge the bits I couldn't resist removing [14:37] mvo: what do you think about unforking si client 3.0? [14:38] barry: I meant to file a bug (but haven't yet), there is one tiny regression compared to the forked version. if there is a error during the apply step it seems 3.0 does not pass that error to the machine readable progress [14:39] mvo: ah, yes please do file a bug. i will fix that asap and get it into wily. i'd really like to unfork snappy. [14:39] barry: does that sound possible? I have not looked further and pushed it on my todo instead but I remember something like "update failed, see syslog for details". for snappy and the progress fd I would love to get the actual backtrace for log and display [14:39]