w2vyjust learning here... anyone using Ubuntu Core/snappy on freescale i.mx6 or i.mx7?00:39
biezpaljdstrand, thanks!03:11
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
imuguruzaLanderU: Hey!06:43
LanderUimuguruza: Hi!!!06:45
ravirdvI've got ubuntu core running on imx6 based board, how do I install snappy package manager?06:48
ravirdvI'm using this ppa sudo add-apt-repository ppa:snappy-dev/tools06:49
ravirdvbut when I install snappy-tools, it throws unmet dependencies error for package "ubuntu-device-flash"06:49
biezpalHi all, need help again :)08:04
biezpalWanted to configure apparmor profile for openvswitch and faced the following problem:08:04
biezpalapparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="openvswitch_ovs-init-switch_0.0.1" name="apps/openvswitch/0.0.1/var/run/openvswitch/db.sock" pid=6190 comm="ovs-vswitchd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=008:04
biezpalBut in apparmor profile we have "/apps/openvswitch/** rwklmpix,"08:04
biezpalIf we start switchd service from the console without ubuntu-core-launcher everything is ok.08:04
ogra_biezpal, iirc there is a bug open about this, create your socket in $SNAP_APP_DATA_DIR, then it should work08:07
ogra_(i.e. /var/lib/apps/<packagename>/<version>)08:08
biezpalogra_, let me check, thanks08:09
biezpalogra_, the same for new paths(08:18
biezpalapparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="openvswitch_ovs-init-switch_0.0.1" name="var/lib/apps/openvswitch/0.0.1/db.sock" pid=2766 comm="ovs-vswitchd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=008:18
biezpalis it ok that we don't have / in the beginning of "name"08:19
* ogra_ wonders if it is normal that the first / is missing 08:19
ogra_i think it is not normal ... i definitely see it in other denial messages08:21
* Chipaca thinks β€œdude, where's my /”08:24
biezpalService starts with the following string08:24
biezpal"/apps/openvswitch/current/bin/ovs-switchd --db=unix:/var/lib/apps/openvswitch/0.0.1/db.sock --pidfile"08:24
biezpaland if we run this command from the console - everything is working08:25
ogra_you need a triple slash for the unix socket ;)08:26
biezpal*adding second "/" didn't helped08:26
biezpaland third08:26
ogra_add a third one08:26
Chipacaogra_: where's the triple slash requirement coming from?08:26
Chipacacan't see that in http://manpages.ubuntu.com/manpages/natty/man8/ovs-vswitchd.8.html08:27
Chipacais it pretending it's a url?08:27
ogra_its a unix socket ... they always have a :// ... plus the path08:27
ogra_no idea where that comes from to be honest08:27
ogra_well, not true08:28
* ogra_ tries to find out :P08:28
Chipacabiezpal: are you using ovs-switchd from ubuntu? because there's no --db mentioned in the manpage either08:29
Chipacabiezpal: i know nothing about ovs-switchd though :)08:29
biezpal/usr/bin/ubuntu-core-launcher openvswitch openvswitch_ovs-init-switch_0.0.1 /apps/openvswitch/current/bin/ovs-vswitchd --pidfile unix:///var/lib/apps/openvswitch/0.0.1/db.sock08:30
biezpalChipaca, sorry, --db argument was from ovs-vsctl08:30
biezpalChipaca, yes, we are using ovs from ubuntu08:31
Chipacabiezpal: and that triple-slashed one doesn't work either?08:31
biezpalChipaca, yep08:31
Chipacaogra_: β€œThe  default is unix:/var/run/openvswitch/db.sockβ€œ08:33
biezpalwithout /usr/bin/ubuntu-core-launcher everything is perfect08:33
Chipacaogra_: no triple slash shenanigans08:33
Chipacabiezpal: well, yeah :) except you're not contained08:33
Chipacabiezpal: what arch are you running this on, and what version of snappy core?08:34
ogra_did longsleep not recently have a similar prob ?08:34
Chipacalongsleep had *all* the problems, but I don't remember this one08:34
ogra_(creating a socket in /var/run ... which then worked when using $SNAPP_APP_DATA_PATH in the call)08:34
Chipacaah, that yes08:35
biezpalChipaca, release: ubuntu-core/15.04/stable, architecture: amd6408:35
ogra_biezpal, try using the variable instead of the path name in your call08:35
biezpalogra_, $SNAPP_APP_DATA_PATH - this variable?08:36
biezpalogra_, checking08:36
Chipacabiezpal: can you scp strace from your machine, and run it (contained) with strace -f -o /tmp/ovs.trace -s 999 your_binary_here ?08:36
Chipacabiezpal: alternatively, you could share your snap :)08:40
biezpalogra_, the same with env var in path08:50
biezpalChipaca, how can I send strace output to you?08:50
Chipacabiezpal: pastebin? scp it somewhere? john.lenton@canonical.com?08:51
biezpalChipaca, http://pastebin.com/fPXGw7Jv08:52
Chipacathere's a lot of WAT in that08:54
Chipacalike, why is it trying to modify things in /etc/ ?08:54
Chipacabiezpal: but also, it's trying to write to /apps/openvswitch/current/var/run/openswitch/08:55
biezpalChipaca, yes, this strace was made for old paths08:56
biezpalChipaca, for /var/lib/apps it's the same08:56
Chipacabiezpal: ok, so, to help me help you debug08:56
biezpalChipaca, sorry, uno moment :)08:57
Chipacabiezpal: first, different question, is this a binary or a service?08:58
Chipacathe order of things to do varies a little depending on that :)08:58
Chipacabiezpal: no worries, before doing it again let's start with as clean a slate as possible08:58
biezpalChipaca, it's a service08:58
Chipacabiezpal: and how are you running the service under strace?08:59
biezpalChipaca, I'm running the command from ExecStart line in service unit09:00
Chipacabiezpal: good :)09:00
Chipacabiezpal: now, do dmesg -T | tail, note the timestamp, start the service, and pastebin everything after that timestamp in a followup dmesg -T; also, pastebin the strace with the "right" paths please09:02
Chipacabiezpal: importantly, don't do anything else between the two dmesg's :)09:03
beowulfChipaca: hey, what's the lastest version of snappy-tools on vivid?09:09
* Chipaca checks09:09
biezpalChipaca, strace - http://pastebin.com/CQRhrh0J09:09
biezpalChipaca, dmesg - http://pastebin.com/kN6KZPFf09:09
Chipacabeowulf: 9, i guess?09:10
Chipacabeowulf: there's a 10 in wily though09:10
ogra_shouldnt you use the tools PPA anyway ?09:12
beowulfChipaca: ogra_: i am, i'm just trying to figure out if i've fubar'd something with my install before i do any more compaining about package review failing in the store :)09:16
beowulfChipaca: thanks, i'm on 10 in vivid09:17
Chipacabeowulf: where's that coming from? (apt-cache policy snappy-tools)09:18
beowulfChipaca: apt-cache policy and dpkg -s snappy-tools both say 10 for me09:19
ogra_then you are likely using the PPA09:20
beowulfhttp://ppa.launchpad.net/snappy-dev/tools/ubuntu/ vivid/main amd64 Packages09:20
ogra_you shoudl be good09:20
* guest42315 π–Ž π–“π–Šπ–Šπ–‰ 𝖇𝖑𝖔𝖔𝖉!09:20
=== guest42315 is now known as drk|aw
beowulfi'm trying to build a mimimun viable snap to use for examining user flows in the store, to try and make that a more pleasant experience, but my snap keeps failing review with apparmor errors, can anyone help me? http://pastebin.ubuntu.com/12134346/09:25
beowulfthe snap is here http://bazaar.launchpad.net/~stephen-stewart/+junk/test-snap/view/head:/meta/package.yaml09:26
Chipacadrk|aw: π•½π–Šπ–›π–Šπ–—π–™π–Šπ–—π–Š π–Žπ–“π–™π–Šπ–—π–•π–šπ–“π–ˆπ–™π–Žπ–”π–“π–Š π–ˆπ–šπ–’ π–•π–”π–˜π–˜π–Žπ–˜09:27
Chipacabeowulf: bzr branch lp:snappy-examples ?09:28
Chipacawait, no, wrong lp:09:28
Chipacabeowulf: lp:~snappy-dev/snappy-hub/snappy-examples09:28
beowulfChipaca: no, the problem is staging :(09:28
beowulfChipaca: it's review tools must be out of date, gah09:28
beowulfi just tried on prod and it's fine09:29
Chipacabeowulf: good thing you've got root on staging, amirite09:29
beowulfno comment09:30
Chipacabiezpal: i am still looking at your thing09:30
Chipacajust in case you're wondering09:30
biezpalChipaca, waiting :)09:31
Chipacabiezpal: it's a framework, yes?09:31
biezpalChipaca, right09:31
Chipacalongsleep: you around?09:41
Chipacabiezpal: so. I don't know quite what's going on with your snap09:46
Chipacabiezpal: i've confirmed in 15.04 you can write to $SNAP_APP_DATA_PATH, and AFAIK longsleep i susing that to create a socket09:46
Chipacabiezpal: your service is doing a bunch of things which are failing09:46
ogra_i know we even have a bug open for that but i cant find it09:46
Chipacabiezpal: for example, it's looking for a control socket in the wrong place09:47
Chipacabiezpal: and you're getting an apparmor denied from a service, which i thought couldn't happen09:47
Chipacabiezpal: so09:48
ogra_Chipaca, well, the interesting bit is still that the DENIED messages miss a leading / in the name= bit ... i have never seen that09:48
Chipacabiezpal: your service09:48
Chipacabiezpal: is calling binaries you ship09:48
Chipacabiezpal: through their wrapper09:48
Chipacabiezpal: this won't work09:48
Chipacabiezpal: just call the binaries directly09:48
Chipacaogra_: maybe that's a side effect of double-wrapping?09:50
ogra_hmm, snappy list -v didnt show me a new docker ... snappy update now downloads a docker update ... there seems to be no way for me to see tho what i'm actually upgrading09:50
Chipacabiezpal: did what i just said make sense to you?09:50
ogra_oh, i'm blind :P09:50
Chipacaogra_: snappy list --updates09:50
ogra_yeah, that was more about tehupdate command09:51
ogra_i totally missed that it printed the version in the first output line09:51
ogra_sadly the running docker service doesnt want to stop, so now it hangs09:51
ogra_(i started a container manually, seems the systemd unit doesnt get along with that ?09:52
ogra_Waiting for docker_docker-daemon_1.6.2.002.service to stop.09:52
Chipacadocker is slow to stop09:53
Chipacawas the first service to necessitate the "waiting" work09:53
ogra_ok, i'll give it more time then09:53
ogra_it moved to ...09:54
ogra_Waiting for owncloud_owncloud_8.0.2.004.service to stop.09:54
Chipacait does eventually get tired of waiting and goes to play with its marbles09:55
ogra_(which isnt running ... lets see how it deals with that)09:55
Chipacabut shouldn't happen09:55
Chipacathat should be quick then :)09:55
ogra_yeah, just moved on09:55
ogra_downloading a new owncloud too09:55
* Chipaca is on the edge of his seat09:55
ogra_i wonder how we ever want to make this work in webdm09:56
ogra_your browser will surely time out :)09:56
Chipacaogra_: heheh09:56
Chipacaogra_: i dunno if you've looked, but there are these "interacter" things everywhere09:57
ogra_at the webdm code ? no, not yet :)09:57
Chipacaogra_: those abstract away the idea that interaction is asynchronous sometimes09:57
Chipacaogra_: no, in snappy itself09:57
Chipacaogra_: webdm provides its own "progress bar" kinda thing, interacter, whatever you call it09:57
Chipacaogra_: whereas we just provide a terminal one (and a null one)09:58
ogra_yeah, that didnt work so well even for installing docker and owncloud :)09:58
Chipacaogra_: you can't do it with webdm?09:58
Chipacathat's good to know, see :)09:58
ogra_i usually end up with an error message in webdm09:58
ogra_it works and all ...09:58
ogra_but prints an error at the end of the install (which takes a felt century)09:59
kickinz1ogra_ one way for owncloud would have be to include the image itself to the snap, so the progress bar could be seen.09:59
ogra_(RPi2 here btw, everything is slow ;) )09:59
kickinz1ogra_, but at upgrade time we have useless data download unless we have binary diffs.09:59
ogra_kickinz1, yeah, i was wondering why you dont include it ... does it get so big ?09:59
biezpalChipaca, yes, it make sense for me, but we don't calling binaries through the wrapper10:00
ogra_saving bits :)10:00
Chipacabiezpal: yes you do10:00
biezpalChipaca, actually, we don't have binaries defined in package.yaml10:00
biezpalChipaca, http://pastebin.com/hapxpjjc10:00
ogra_it finished10:00
Chipacabiezpal: not through the wrapper10:00
kickinz1then also, on a rpi2 loading the image is quite long, so you see the progress bar, but you are still waiting 5 mns for the image to be loaded :(10:00
Chipacabiezpal: i lied to you10:00
Chipacabiezpal: and that's probably the launcher itself :-/10:01
Chipacaman i suck at debugging :)10:01
biezpalChipaca, we are using our own wrappers only when we need to export LD_LIBRARY_PATH for our binaries10:04
Chipacabiezpal: what do you get from10:05
Chipacabiezpal: sudo journalctl -u openvswitch_ovs-init-switch_0.1.service10:06
biezpalChipaca, http://pastebin.com/w5aw605v10:12
=== greyback_ is now known as greyback|shops
Chipacabiezpal: fwiw, i am able to create a socket and listen on it just fine, with no additional privileges nor anything, in 15.04 amd6410:20
Chipacabiezpal: are you using a custom policy or something?10:20
biezpalChipaca, we are able to create and listen on socket too, but we cannot connect to it10:21
biezpalChipaca, our ugly debug policy prfile: http://pastebin.com/JyjSNW3810:21
ogra_kickinz1, seems to be working really well now ...10:22
biezpalChipaca, in unconfined mode everything is ok10:23
biezpalyes, it's ugly :)10:23
Chipacabiezpal: silly question, what permissions does the socket file have?10:24
Chipacabiezpal: also, what creates the socket, and what tries to connect to the socket?10:25
biezpal(amd64)ubuntu@rh1440073371:~$ ls -l /var/lib/apps/openvswitch/0.1/db.sock    srwx------ 1 root root 0 Aug 20 16:09 /var/lib/apps/openvswitch/0.1/db.sock10:25
biezpal"/apps/openvswitch/current/bin/ovsdb-server --remote=punix:$SNAP_APP_DATA_PATH/db.sock  --remote=db:Open_vSwitch,Open_vSwitch,manager_options  --pidfile"10:26
biezpalthis command creates socket10:26
biezpaland it works under the same profile10:26
Chipacabiezpal: and both these things are services10:26
biezpal"/apps/openvswitch/current/bin/ovs-vswitchd --pidfile unix:$SNAP_APP_DATA_PATH/db.sock"10:26
biezpallast command - connects to the socket10:26
ogra_with the --pidfile option ?10:27
biezpalyes, both services10:27
biezpalogra_, yes, it creates pidfile for daemon10:27
* ogra_ woould expect a pidfile as argument for this 10:27
Chipacabiezpal: and both run with the debug profile you pasted? or is that profile the one you use when you say unconfined it works?10:27
biezpalogra_, daemon uses default path for pidfile10:28
biezpalChipaca, ovsdb-server able to create socket under this profile, but ovs-vswitchd can connect only in unconfined mode10:29
Chipacabiezpal: ogra_: it creates a pidfile at /apps/openvswitch/0.1/var/run/openvswitch/ovs-vswitchd.pid.tmp which will be a problem when you try to tigthen the profile, but works for now10:31
ogra_you can define it via --pidfile= ...10:32
biezpalChipaca, yes, we are keep it in mind10:32
ogra_according to the manpage10:32
biezpalwe'll change it when solve the main problem :)10:32
=== greyback|shops is now known as greyback
Chipacabiezpal: i'm out of ideas10:33
kickinz1ogra_, but it still need systemd's socket support, and an upgrade to 8.1.1, both are in the pipe, but I'm lacking time.10:33
Chipacabiezpal: let's wait on jdstrand or tyhicks, they're smart :)10:33
ogra_kickinz1, well, i dont get nagged about upgrades anymore10:34
ogra_so thats a win10:34
kickinz1ogra_, I've already did some snappy code, so it supports sockets, so we may get rid of sleeps. I started an owncloud 8.1.1, but upgrade from 8.0.2 is stuck10:34
ogra_cool !10:34
kickinz1ogra_, owncloud gets broke, good for fresh install, but definitively need to understand where it hangs.10:34
biezpalChipaca, thanks for the help anyway, we are also working on it10:35
biezpalwaiting for these guys10:35
Chipacaok. i've got to run to the shops. will be back for the standup. o/10:35
ogra_kickinz1, i wonder if we shouldnt have some mechanism that an app can use its own upgrade mechanism if wanted ...10:36
ogra_so it would do the upgrade inside the container ...10:36
kickinz1ogra_ yes I think we need that, but for owncloud, owncloud already has db migration, and an upgrade path. Data and files are kept outside the container via volumes. But the migration get stucks in the middle.10:38
kickinz1ogra_ the new owncloud starts, but say it is in maintenance mode, and I had to left it like that.10:38
kickinz1ogra_ (it say it will work out the migration, then is seems to do something then maintenance mode is on)10:39
kickinz1s/is on/is blocked on/10:41
w2vynew here... looking at running snappy on freescale i.mx6 or i.mx7 and have some general questions...10:49
w2vythey have their own kernel and build with yocto, just wonder how much of their support i would lose by switching..10:50
w2vyi was thinking yocto could deal with snappy, assuming there were recipies for it...10:52
ravirdv@w2vy I'm also looking for some help with imx611:04
nothalravirdv: No such command!11:04
w2vyok. just curious, why not use the freescale release?11:05
ravirdvSnappy looks good, mainly for OTA11:06
ravirdvI was able to  run Ubuntu Core with own kernel11:06
ravirdvtrying to build snappy with with a/b partition scheme11:06
w2vyi am looking for options because they can't tell me who is responsible for security patches, etc11:08
w2vyfrom talking to them it sound like the Buck Stops Here... I don't WANT that buck!11:08
ravirdvtrue, that control has be with us11:09
ravirdvas in product manufacturers11:09
w2vyyou want to have to deal with every patch that is released and apply each one yourself?11:09
ravirdvjust the control of which packages goes onto customer's device11:10
w2vyof course... but not each patch to each package!11:10
ravirdvofcouse not :)11:10
w2vyof course i will have to pay for the ability to sleep at night...11:10
ogra_w2vy, you can use whatever kernel you want as long as you can make all options work and have the latest apparmor patches11:11
ogra_the u-boot bits there need updating, we changed that setup, but the stuff there is definitely enough to make it work11:13
w2vywell here I go again... is there a ubuntu core channel?11:14
w2vyi am trying to drill down to pick a kernel first...11:14
ogra_not surew what you mean by ubuntu core channel11:15
w2vyme either...11:15
ogra_ubuntu-core (the non snappy variant) has no channel (though it has nothing to do with snappy)11:15
ogra_snappy ubuntu-core has this channel11:15
w2vylet me back up and you can tell me where to go...11:16
w2vyi am planning a product that will run linux inside - for various reasons. looking for a kernel that I can use (free or not - but not go broke) that has patches tested so I not not need to be the open source patch guru11:17
w2vytalking to freescale i felt like i was getting dumb looks, like I had no idea what I was talking about (could be)11:18
ogra_well, with snappy you can use any kernel you want as long as you can enable the right options and can apply the apparmor patches that are required to run apps under confinement ...11:19
ogra_so you will likely not get around touching some kernel bits, even if your board is supported by the latest upstream kernel you will want to apply the right build configuration as the very least11:19
ogra_the porting websie above has that documented in the last paragraph i thinnk11:20
ogra_well, not last but one of the last :)11:20
w2vyyes well "upstream kernel" does not imply any reliability... not like a canonical kernel does...11:21
w2vyi guess i just need to wait for someone from canonical to contact me...11:21
ogra_well, the canonical kernel uses the upstream one :)11:21
w2vyyes, but it may have been tested and the patches selected by someone who knows a hellva lot more than me!11:22
w2vys/someone/a whole team/11:22
ogra_did you contact anyone already ?11:22
w2vyyesterday, so i figured i'd try to learn a bit more before they call11:23
ogra_so ... the ubuntu kernel is plain mainline with a specific config and a few extra patches. if your board can already be suported by that then it should be trivial ...11:24
ogra_if it cant or if you need to use a BSP kernel then you either need to make the necessary changes yourself or you need to pay someone for this :)11:25
w2vyyeah, the "few extra patches" is where I would  mess up and ship a holey product11:25
ogra_totally depends :)11:25
w2vyyeah, i an trying to find where i will be sending my support money...11:26
w2vy(inbox fills up)11:26
ogra_the most important bits are apparmor and some config options for systemd ...11:26
ogra_applying the apparmor patches essentially means "delete the whole apparmor dir in the kernel source and replace by canonicals"11:26
ogra_and the rest is just confi stuff11:26
ogra_bah !11:27
ogra_thanks :)11:27
w2vyok, let me raise the SNR here and go read you link...11:27
ogra_the same thing goes for uboot ... there are some minimal config patches and a specific setup, nothing fancy11:28
ogra_once you have both you can build an oem snap package for the bootloader and a device tarball for the kernel ...11:28
ogra_then you hand both of them to the ubuntu-device-flash tool which assembles an image for you using the snappy rootfs and the two bits you created11:29
ogra_if you look for a commercial contact at canonical try maarten.ectors@canonical.com ... he does that stuff for snappy specifically11:30
=== chihchun is now known as chihchun_afk
ogra_why is my test initrd only 2.6M big12:05
Chipacaogra_: because you're testing klibc-snappy?12:45
ogra_Chipaca, well, not sure why, i havent looked yet ... it boots fine even with the small one that i built in a chroot12:46
* ogra_ will check for differences once he landed the resize code 12:46
=== chihchun_afk is now known as chihchun
* ogra_ sighs ... resizing takes aeons12:54
ogra_i should have re-partitioned instead of relying on gparted to shrink the partition for testing12:58
ogra_took 20min already just to resize from 16G to 512:58
ogra_crap ... and indeed the resizing didnt work13:01
ogra_it did work but didnt re-read the new partition table13:03
longsleepogra_: why does it take so long to resize?13:32
ogra_longsleep, ask gparted :P13:32
ogra_i resorted to not cut the partition in half but only make it 2G smaller ... that works a tad faster13:33
ogra_but still, i cant convince the initrd to reread the new partition table without reboot13:33
longsleepogra_: did you try to run my script, that works just fine without reboot required if i remember correctly13:33
longsleepmaybe the cloud init script does some extra magic13:34
ogra_also, your code uses a lot non-std tools, i had to copy quite a few bits into the initrd (realpath etc)13:34
longsleepyeah well, realpath is kind of standard but not part of a shell builtin13:34
ogra_right, nor is dirname13:34
longsleepbusybox does not have it?13:34
longsleepnarf :)13:34
* ogra_ reboots and prays 13:35
ogra_(not that i'm religious :P )13:35
longsleepbusybox has dirname and realpath13:35
longsleepso i suggest to just add busybox :P13:35
ogra_ah, not linked or not the initrd build we use then13:35
longsleepmhm i checked the busybox on my 14.04 workstation, i did assume the one in initrd might be the same13:36
longsleepmaybe the links are missing13:36
ogra_GRRR !"!!!13:37
ogra_funny that the manpage explicitly lists -R13:37
ogra_even more interesting that the resizefs complains about missing fsck while i see that running above in the log13:38
ogra_(RaspberryPi2)ubuntu@localhost:~$ sudo sfdisk -s /dev/sda113:40
ogra_and pobviously the kernel actually knows the new partition size ... so somewhere along the way it actually *did* re-read it13:40
ogra_myths all over the place :P13:40
longsleepoh boy13:41
longsleepogra_: i remember something about that and reading something that the error is no error and can be ignored in this case13:42
ogra_if resize2fs would actually use the new size i wouldnt care about the error :)13:42
ogra_i might have to re-read *before* running fsck13:43
* ogra_ tries that 13:43
longsleepogra_: my script does the job just fine http://paste.ubuntu.com/12135559/13:45
longsleepogra_: so it must be some magic of cloud init13:45
ogra_longsleep, yeah, i cant pull cloud-init into the initrd13:46
ogra_(and i really dont want to use it13:46
longsleepogra_: yeah, but maybe take a look what it is doing13:46
ogra_also it operates in a saner environment than initrd ... you have a fully running system up13:46
longsleepwell, if it just works you could avoid run it from initrd and do it later as a regular service13:47
ogra_ok, next try ...13:47
* ogra_ crosses fingers13:47
longsleepbtw, growpart is just a bash script too, so you should be able to add this into initrd without too much issue13:49
ogra_longsleep, i really dont want to tinker with a filesystem underneath a ton of bindmounts13:49
ogra_resizing from a systemd unit really calls for trouble, even if it might work right now13:49
longsleepogra_: yeah - i prefer to have it in initrd as well, take a look at the growpart script, it is quite long but works just fine13:50
longsleepit uses partx to update the partition13:50
longsleepand sfdisk13:51
longsleepso you should be good13:51
ogra_yeah, i really dont want partx in the initrd13:51
ogra_that will pull in a ton of deps13:51
ogra_GEEZ !13:52
ogra_e2fsck 1.42.12 (29-Aug-2014)13:52
ogra_writable: 135627/840480 files (0.0% non-contiguous), 577059/3368192 blocks13:52
ogra_resize2fs 1.42.12 (29-Aug-2014)13:52
ogra_Please run 'e2fsck -f /dev/sda1' first.13:52
longsleepwell, i just found this update the the kernel partition table info after growing this requires kernel support and 'partx --update'13:52
* ogra_ cant belive that 13:52
longsleepogra_: same disk?13:52
ogra_the fsck obviously runs directly before the resizefs13:52
longsleepno idea13:53
ogra_so it checks, gives me the summary and then resize complains13:53
ogra_i wonder if e2fsck behaves differently if you use -fy vs oinly using -f13:56
ogra_thats the onl idea i have13:56
ogra_resize2fs has a -f option too ... lets try that one :)13:57
ogra_(RaspberryPi2)ubuntu@localhost:~$ sudo cp chroot/boot/initrd.img-foo /boot/uboot/a/initrd.img13:59
ogra_^^^ this takes nearly 5min13:59
ogra_goota love the RPi IO13:59
=== chihchun is now known as chihchun_afk
ogra_hmm, it definitely does something this time14:03
ogra_(RaspberryPi2)ubuntu@localhost:~$ df -h |grep oem14:04
ogra_/dev/sda1                     15G  1.9G   12G  14% /oem14:04
ogra_yippie !!14:04
ogra_and now the same with running from SD ...14:06
ogra_lets see what it does if the first partition is already mounted :P14:06
jdstrandbeowulf: make sue the review tools are up to date and you are using an up to date snappy binary to build the snap14:10
beowulfjdstrand: it was a problem with myapps.developer.staging.u.c, the core framework had different policy versions on staging and prod14:12
Chipacaogra_: have not read all the backlog, but "sfdisk -R" used to work, but at least in wily it says you should do "blockdev --rereadpt" instead14:14
ogra_Chipaca, yeah, thats what i use now14:14
Chipacaah, k14:14
jdstrandbeowulf: ok, cool, glad it is resolved14:14
Chipacaogra_: and it didn't?14:14
ogra_(and what i tried to use forst ... but i was running it to late ... inbetween i tried sfdisk -R ... )14:15
ogra_it works now with writable on USB disk ... i'm just re-flashing from scratch to see what it does with /root is already mounted from the same disk now14:15
asackyrofa: what do i need to do to get your piglowtop app working? readme doesnt say anything :)14:15
ogra_i have a slight suspicion it will not work14:15
ogra_asac, hw-assign14:16
ogra_for the i2c device i think+14:16
asacogra_: dev/i2c...?14:16
asaclet me try14:16
kyrofaogra_, check the meta/readme14:16
kyrofaerr, asac ^^14:16
ogra_me ?14:16
kyrofaogra_, sorry :)14:16
asackyrofa: it wasnt in the README.md... :)14:16
asaclet me see14:16
kyrofaogra_, I'm so used to typing out your nick really fast14:16
asacwonder if this persists across reboots :)14:17
ogra_kyrofa, yeah, asac and me are easy to mix up ... i'm the fat toothless longhaired guy ... and he is not :P14:17
kyrofaasac, yeah, I kept that pretty high level since it wasn't specifically for snappy. The snappy-specific stuff is in the "snappy" readme (i.e. meta/readme)14:17
kyrofaasac, the hw-assign? Works for me14:18
asackyrofa: so after reboot the process is still running14:18
asacbut nothing is blinking14:18
kyrofaasac, although it's a little wonky. When you uninstall piglowtop it also removes the hw-assignment, except when it doesn't14:18
kyrofaasac, hmm. systemctl status -l piglowtop_piglowtop_0.1.0.service ?14:19
asacstill complains about not being able to access it14:19
kyrofaasac, also verifying i2c is setup: you have /dev/i2c-1?14:19
ogra_asac, try  reboot ?14:19
asacyeah did that14:20
asaci have ls -la /dev/i2c-114:20
asaccrw------- 1 root root 89, 1 Aug  7 17:01 /dev/i2c-114:20
asachave that too14:20
asacmaybe i didnt connect it proper?14:20
asaci connected it to the last pins... not the side of the gpiop14:20
ogra_damn ... that didnt look like it resized14:20
* ogra_ guesses it doesnt like having a partition mounted14:21
kyrofaasac, mine is on the side closest to the power LEDs14:21
asacoh ... so thats different then14:21
* asac tries14:21
asacguess i cant connect the gpio pins anyway when having the orange box closed, so ... :)14:22
ogra_This disk is currently in use - repartitioning is probably a bad idea.14:22
ogra_Umount all file systems, and swapoff all swap partitions on this disk.14:22
ogra_Use the --no-reread flag to suppress this check.14:22
* asac shuts down, opens case and reconnects glow14:22
ogra_now the question is how dangerous is it to ignore that check14:23
longsleepogra_: well - i am pretty sure there are ways that this breaks the system14:24
asac ok greawt... let me not do the mistake again and clsoe the case :)14:24
ogra_longsleep, well, i dont touch any of the partitions that are mounted ... i only change the table14:25
ogra_and only for a partition that isnt mounted currently14:25
longsleepogra_: the partition you change is also always at the end - so you should be good in all normal cases14:26
asacand yes, it just started glowing.... i miracle ::14:26
asacthx kyrofa14:26
ogra_longsleep, right14:26
asacguess device tree could be used to map those pins somwhere else?14:26
ogra_i think it is fine as an interim solution14:26
kyrofaasac, no problem! Thanks for trying it :)14:26
ogra_that code wont stay anyway i think14:26
asackyrofa: you could add a config for it14:27
asacso i could change the values you refer to in README.md14:27
asacright now ping does not glow :)14:27
asacsnappy config14:27
asaceat yaml, remember values for service etc.14:27
asacbut great!!14:27
kyrofaasac, you mean so snappy config can change the brightness, etc?14:28
asacyeah the parameters you mention in README.md14:28
vmayoralogra_: hi! thanks for the kernel pointers. I'm struggling with udf to recreate the image14:28
vmayoralogra_: mind looking at https://gist.github.com/vmayoral/c7f9ab2b6160cdcfabca?14:28
asacwould be cool to have snappy config so i can change those values from the defaults14:28
kyrofaasac, good idea! I've not messed with snappy config yet14:28
asacfor the service14:28
asacits easy kinda14:28
asackyrofa: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example/14:29
asacjust check the meta/hooks dir14:29
asackyrofa: or http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example-bash/14:29
asacif you want hacky yaml/bash :)14:29
asacok guess time to close the case :P14:29
kyrofaasac, thanks for the reference!14:30
ogra_GRRRRRR !!!!14:30
ogra_didnt work even with the option forced14:31
vmayoralogra_: i see it's been addressed at https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516, let me try to update my tools and retry14:31
ubottuLaunchpad bug 1472516 in goget-ubuntu-touch (Ubuntu) "udf cannot double map partitions error" [Undecided,Fix released]14:31
ogra_Syncing disks.14:32
ogra_blockdev: ioctl error on BLKRRPART: Device or resource busy14:32
* ogra_ cries 14:32
* asac wonders what my wife will say once this thing replaces our old, super powerwasteful mini 10 laptop that does mail/ftp/irc server in the living room :)... hope she will be impressed by the ultimate beauty odf this thing14:32
ogra_sigh ... i guess i have to start from scratch and use a premount script :/14:33
* ogra_ wanted to have that code ready by wed. :(((14:33
asacresizing premount sounds reasonable14:33
asacyou can still finish it today14:33
ogra_asac, yeah, i should have done that from the start, but its so convenient to do it later since i dont need to duplicate half the code to fill the right vars14:33
ogra_vmayoral, well, your output looks slightly different, but yeah, try it14:34
ogra_why the heck does the ubuntu-core initrd script forcefully mount /run/initramfs14:53
ogra_init does that already and this makes us use all former logs14:54
ogra_and we even mount /run afresh14:54
ogra_so mucxh code duplication !!!14:55
ogra_(and so harmful)14:55
Chipacaogra_: if only we knew those ubuntu-core people we could make them fix it!14:55
ogra_well, i have a mild guess the person that wrote most of this script isnt here anymore14:56
Chipacaogra_: :)14:56
Chipacaelopio: so my mp from yesterday should be getting two more auto-comments at some point?15:08
elopioChipaca: yes, if I manage to get the polling right today.15:13
vmayoralogra_: nah, didn't work https://gist.github.com/vmayoral/33e80be0b06b7a48a74c. Went ahead and created a new chroot with vivid downloading the latest packages https://gist.github.com/vmayoral/33e80be0b06b7a48a74c15:13
elopioChipaca: your MP looks good to me, but you are touching many funcs that I haven't seen before. I think it would be better to wait for mvo's or sergio's review.15:13
Chipacaelopio: yes, i wasn't expecting a proper code review on this one any time soon15:15
vmayoralogra_: don't think it's that but let me map dev, proc and sys in the chroot and retry15:15
vmayoralogra_: nop, got read of the resolving issue but still getting the "exit status 2"15:17
Chipacavmayoral: have you verified your snap?15:20
vmayoralChipaca: i also tried the same with the one provided by you guys http://people.canonical.com/~platform/snappy/raspberrypi2/15:20
ogra_Chipaca, well, i bet the erle snap usually works :)15:21
Chipacavmayoral: what version of ubuntu-device-flash is that?15:21
Chipacavmayoral: (do you always sudo when you're already root? :-p)15:21
Chipacaah, it's in the gist15:22
* Chipaca reads15:22
Chipacavmayoral: it seems to work here on wily15:30
Chipacavmayoral: which isn't particularly helpful i know15:30
Chipacavmayoral: let me see if the other computer is still legacy :)15:30
vmayoralChipaca: mmmm i just created a new vivid chroot to make sure that it could be reproducible15:31
vmayoralChipaca: do you think you could try that?15:31
Chipacavmayoral: i've got a vivid host, let me try there first15:31
vmayoralChipaca: great, thanks15:31
ogra_i did build the rpi image on trusty FWIW15:32
ogra_but using ubuntu-device-flash from the tools PPA so we should be using the same thing15:33
Chipacajohn@fridge:/tmp/pi2$ sudo ubuntu-device-flash core 15.04 --oem=pi2_0.15_all.snap --device-part=device-pi2-0.15.tar.xz -o pi2.img --developer-mode15:34
ChipacaDetermining oem configuration15:34
ChipacaUsing a custom OS or Kernel part will prevent updates for these components15:34
ChipacaFetching information from server...15:34
ChipacaDownloading and setting up...15:34
Chipacavmayoral: New image complete15:35
ogra_looks fine to me15:35
ogra_vmayoral, are you using ubuntu-device-flash from https://launchpad.net/~snappy-dev/+archive/ubuntu/tools ?15:36
ogra_0.27-0ubuntu1  ....15:36
Chipacaogra_: that's what his apt-cache policy says15:36
vmayoralogra_: yeap15:37
Chipacavmayoral: is the filesystem you are doing this on in any way special?15:37
ogra_Chipaca, how good is your shell foo ? i dont want to upload without a second pair of eyes  http://paste.ubuntu.com/12136199/15:37
Chipacaogra_: i aspire to upgrade it to your level someday somehow, but i can read what you write15:38
ogra_i guess thats enough for a yay or nay :)15:38
vmayoralChipaca: mmm i'm running a trusty virtual machine and i chrooted the a new vivid image since it was giving me trouble on trusty15:38
ogra_hmm, i should expand the first changelog line a bit i guess15:38
vmayoralnot sure if that's special :(15:38
ogra_vmayoral, well, it works for me onb trusty too15:40
ogra_that is how i created the image in the first place15:40
Chipacaogra_: i see no problems in the shell in the patch15:45
Chipacaogra_: if i were feeling nitpicky i'd ask whether it was intentional to lose precision on the size check15:46
Chipacaogra_: but i'm not :-P15:47
ogra_well, i dont really want it to resize just because there are 10k free or some such15:47
ogra_which is why i picked these artificial 10%15:47
ogra_[    9.596964]  sda: sda115:47
ogra_e2fsck 1.42.12 (29-Aug-2014)15:47
ogra_[    9.951713] random: nonblocking pool is initialized15:47
ogra_resize2fs 1.42.12 (29-Aug-2014)15:47
ogra_so even with USB disk writable partition it works fine15:48
Chipacaogra_: i meant, you're checking (device_size-used_size) against the floor of device_size/1015:48
Chipacaso it sometimes won't resize even when you have 10% waste15:49
ogra_what would you propose ?15:49
Chipacaogra_: to commit it :)15:49
Chipacayou can tell people to use tune2fs to get back their precious bytes if the need 'em :-p15:50
ogra_well, we can always improve15:50
ogra_and i'm not sure at all we'll even keep that code15:50
ogra_so yeah, let me upload so we have it in tomorrows rolling/edge image15:51
ogra_so if bug 1485306 could be fixed now ... we could actually make u-d-f create a 1byte partition ...15:52
ubottubug 1485306 in Snappy "ubuntu-device-flash should not create data in writable partition" [Undecided,New] https://launchpad.net/bugs/148530615:52
ogra_that would make the images massively smaller :)15:52
ogra_utlemming, ^^^ automatic resizing of the writable partition should show up in the next rolling/edge image build tonight15:59
* ogra_ adds a checkmark on the trello card next to "ping back ben howard" about resizing :)16:00
ogra_elopio, so this trello card has a "add automated tests under self tests" ... do we have any tests at all for initrd scripts anywhere ?16:01
ogra_i mean ... its a great approach ... but i cant even imagine remotely how such a test would work16:02
elopioogra_: the self tests are functional from the point of view of the user, so there you would have to check that the partition was resized.16:05
elopioI'm not sure how to generate an image and a kvm that causes a resize, but that sounds doable.16:05
ogra_elopio, so we would actually need an image where writable doesnt occupy the full space16:06
ogra_i guess thats a task for sergiusens then to change u-d-f16:06
ogra_which we should do in general now16:06
ogra_to generate smaller images16:06
elopiotesting the script itself as it runs in memory, I have no idea how to do that.16:06
sergiusensogra_: you already have that working?16:07
ogra_that was what made me curious :)16:07
ogra_sergiusens, well, i just uploaded http://paste.ubuntu.com/12136293/16:07
ogra_should work in the next image16:07
sergiusensogra_: I'll work on an MP then16:07
ogra_(still room for improvement, but i understood it is urgent to have it )16:07
sergiusensogra_: really?16:07
ogra_sergiusens, yeah, see the other channel :)16:09
elopioogra_: I guess you can also run the resize script. Change all the initramfs specifics for parameters so it's easily testable.16:11
elopioso the problem would be the hooks. Maybe sergiusens has ideas, or somebody from the kernel team.16:11
elopioa fake initramfs?16:11
ogra_well, you need to check it at runtime somehow16:12
ogra_so i guess a boot test of an image is needed16:12
ogra_and i assume we dont have anything for that at all yet anyway ... sounds like a bier task16:12
elopioogra_: yes, please make new cards for these things. If you have any clues about where to start, please add them as comments to so we can start the research.16:13
ogra_will do16:16
ogra_hah, what i really love is that i re-flashed my SD about ten times today ... just removing the label from the last partition and plugging in my USB key with the formerly used writable partition and i'm back with all my installed apps (docker, owncloud etc) just working like before16:21
=== drk|aw is now known as o
=== o is now known as Guest83769
sergiusensogra_: should we growfs by default and make writable 1MiB?17:20
sergiusensogra_: also, should we take a shot at making system-a and system-b smaller?17:20

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