| w2vy | just learning here... anyone using Ubuntu Core/snappy on freescale i.mx6 or i.mx7? | 00:39 |
|---|---|---|
| biezpal | jdstrand, thanks! | 03:11 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| imuguruza | LanderU: Hey! | 06:43 |
| LanderU | imuguruza: Hi!!! | 06:45 |
| ravirdv | hi | 06:48 |
| ravirdv | I've got ubuntu core running on imx6 based board, how do I install snappy package manager? | 06:48 |
| ravirdv | I'm using this ppa sudo add-apt-repository ppa:snappy-dev/tools | 06:49 |
| ravirdv | but when I install snappy-tools, it throws unmet dependencies error for package "ubuntu-device-flash" | 06:49 |
| biezpal | Hi all, need help again :) | 08:04 |
| biezpal | Wanted to configure apparmor profile for openvswitch and faced the following problem: | 08:04 |
| biezpal | apparmor="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=0 | 08:04 |
| biezpal | But in apparmor profile we have "/apps/openvswitch/** rwklmpix," | 08:04 |
| biezpal | If 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 work | 08:07 |
| ogra_ | (i.e. /var/lib/apps/<packagename>/<version>) | 08:08 |
| biezpal | ogra_, let me check, thanks | 08:09 |
| biezpal | ogra_, the same for new paths( | 08:18 |
| biezpal | apparmor="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=0 | 08:18 |
| ogra_ | hmm | 08:19 |
| biezpal | is 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_ | heh | 08:20 |
| ogra_ | *snap* | 08:20 |
| ogra_ | i think it is not normal ... i definitely see it in other denial messages | 08:21 |
| * Chipaca thinks βdude, where's my /β | 08:24 | |
| biezpal | Service starts with the following string | 08:24 |
| biezpal | "/apps/openvswitch/current/bin/ovs-switchd --db=unix:/var/lib/apps/openvswitch/0.0.1/db.sock --pidfile" | 08:24 |
| biezpal | and if we run this command from the console - everything is working | 08:25 |
| ogra_ | you need a triple slash for the unix socket ;) | 08:26 |
| biezpal | *adding second "/" didn't helped | 08:26 |
| biezpal | and third | 08:26 |
| ogra_ | add a third one | 08:26 |
| Chipaca | ogra_: where's the triple slash requirement coming from? | 08:26 |
| Chipaca | can't see that in http://manpages.ubuntu.com/manpages/natty/man8/ovs-vswitchd.8.html | 08:27 |
| ogra_ | unix:///var/run/foo.sock | 08:27 |
| Chipaca | is it pretending it's a url? | 08:27 |
| ogra_ | its a unix socket ... they always have a :// ... plus the path | 08:27 |
| ogra_ | no idea where that comes from to be honest | 08:27 |
| ogra_ | well, not true | 08:28 |
| * ogra_ tries to find out :P | 08:28 | |
| Chipaca | biezpal: are you using ovs-switchd from ubuntu? because there's no --db mentioned in the manpage either | 08:29 |
| Chipaca | biezpal: 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.sock | 08:30 |
| biezpal | Chipaca, sorry, --db argument was from ovs-vsctl | 08:30 |
| biezpal | Chipaca, yes, we are using ovs from ubuntu | 08:31 |
| Chipaca | biezpal: and that triple-slashed one doesn't work either? | 08:31 |
| biezpal | Chipaca, yep | 08:31 |
| Chipaca | ogra_: βThe default is unix:/var/run/openvswitch/db.sockβ | 08:33 |
| ogra_ | ok | 08:33 |
| biezpal | without /usr/bin/ubuntu-core-launcher everything is perfect | 08:33 |
| Chipaca | ogra_: no triple slash shenanigans | 08:33 |
| ogra_ | yeah | 08:33 |
| Chipaca | biezpal: well, yeah :) except you're not contained | 08:33 |
| Chipaca | biezpal: 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 |
| Chipaca | longsleep had *all* the problems, but I don't remember this one | 08:34 |
| ogra_ | (creating a socket in /var/run ... which then worked when using $SNAPP_APP_DATA_PATH in the call) | 08:34 |
| Chipaca | ah, that yes | 08:35 |
| biezpal | Chipaca, release: ubuntu-core/15.04/stable, architecture: amd64 | 08:35 |
| ogra_ | biezpal, try using the variable instead of the path name in your call | 08:35 |
| biezpal | ogra_, $SNAPP_APP_DATA_PATH - this variable? | 08:36 |
| ogra_ | yes | 08:36 |
| biezpal | ogra_, checking | 08:36 |
| Chipaca | biezpal: 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 |
| Chipaca | biezpal: alternatively, you could share your snap :) | 08:40 |
| biezpal | ogra_, the same with env var in path | 08:50 |
| biezpal | Chipaca, how can I send strace output to you? | 08:50 |
| Chipaca | biezpal: pastebin? scp it somewhere? john.lenton@canonical.com? | 08:51 |
| biezpal | Chipaca, http://pastebin.com/fPXGw7Jv | 08:52 |
| Chipaca | hm | 08:54 |
| Chipaca | there's a lot of WAT in that | 08:54 |
| Chipaca | like, why is it trying to modify things in /etc/ ? | 08:54 |
| Chipaca | biezpal: but also, it's trying to write to /apps/openvswitch/current/var/run/openswitch/ | 08:55 |
| Chipaca | openvswitch* | 08:55 |
| biezpal | Chipaca, yes, this strace was made for old paths | 08:56 |
| biezpal | Chipaca, for /var/lib/apps it's the same | 08:56 |
| Chipaca | sigh | 08:56 |
| Chipaca | biezpal: ok, so, to help me help you debug | 08:56 |
| biezpal | Chipaca, sorry, uno moment :) | 08:57 |
| Chipaca | biezpal: first, different question, is this a binary or a service? | 08:58 |
| Chipaca | the order of things to do varies a little depending on that :) | 08:58 |
| Chipaca | biezpal: no worries, before doing it again let's start with as clean a slate as possible | 08:58 |
| biezpal | Chipaca, it's a service | 08:58 |
| Chipaca | biezpal: and how are you running the service under strace? | 08:59 |
| biezpal | Chipaca, I'm running the command from ExecStart line in service unit | 09:00 |
| Chipaca | biezpal: good :) | 09:00 |
| Chipaca | biezpal: 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 please | 09:02 |
| Chipaca | biezpal: importantly, don't do anything else between the two dmesg's :) | 09:03 |
| beowulf | Chipaca: hey, what's the lastest version of snappy-tools on vivid? | 09:09 |
| Chipaca | oaiduno | 09:09 |
| * Chipaca checks | 09:09 | |
| biezpal | Chipaca, strace - http://pastebin.com/CQRhrh0J | 09:09 |
| biezpal | Chipaca, dmesg - http://pastebin.com/kN6KZPFf | 09:09 |
| Chipaca | beowulf: 9, i guess? | 09:10 |
| Chipaca | beowulf: there's a 10 in wily though | 09:10 |
| ogra_ | shouldnt you use the tools PPA anyway ? | 09:12 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/tools | 09:13 |
| beowulf | Chipaca: 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 |
| beowulf | Chipaca: thanks, i'm on 10 in vivid | 09:17 |
| Chipaca | beowulf: where's that coming from? (apt-cache policy snappy-tools) | 09:18 |
| beowulf | Chipaca: apt-cache policy and dpkg -s snappy-tools both say 10 for me | 09:19 |
| ogra_ | then you are likely using the PPA | 09:20 |
| beowulf | http://ppa.launchpad.net/snappy-dev/tools/ubuntu/ vivid/main amd64 Packages | 09:20 |
| ogra_ | yeah | 09:20 |
| ogra_ | you shoudl be good | 09:20 |
| * guest42315 π ππππ πππππ! | 09:20 | |
| === guest42315 is now known as drk|aw | ||
| beowulf | i'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 |
| beowulf | the snap is here http://bazaar.launchpad.net/~stephen-stewart/+junk/test-snap/view/head:/meta/package.yaml | 09:26 |
| Chipaca | drk|aw: π½ππππππππ ππππππππππππππ πππ ππππππ | 09:27 |
| Chipaca | beowulf: bzr branch lp:snappy-examples ? | 09:28 |
| Chipaca | wait, no, wrong lp: | 09:28 |
| Chipaca | beowulf: lp:~snappy-dev/snappy-hub/snappy-examples | 09:28 |
| beowulf | Chipaca: no, the problem is staging :( | 09:28 |
| beowulf | Chipaca: it's review tools must be out of date, gah | 09:28 |
| beowulf | i just tried on prod and it's fine | 09:29 |
| Chipaca | beowulf: good thing you've got root on staging, amirite | 09:29 |
| beowulf | no comment | 09:30 |
| Chipaca | biezpal: i am still looking at your thing | 09:30 |
| Chipaca | just in case you're wondering | 09:30 |
| biezpal | Chipaca, waiting :) | 09:31 |
| biezpal | thx | 09:31 |
| Chipaca | biezpal: it's a framework, yes? | 09:31 |
| biezpal | Chipaca, right | 09:31 |
| Chipaca | longsleep: you around? | 09:41 |
| Chipaca | biezpal: so. I don't know quite what's going on with your snap | 09:46 |
| Chipaca | biezpal: i've confirmed in 15.04 you can write to $SNAP_APP_DATA_PATH, and AFAIK longsleep i susing that to create a socket | 09:46 |
| ogra_ | yeah | 09:46 |
| Chipaca | biezpal: your service is doing a bunch of things which are failing | 09:46 |
| ogra_ | i know we even have a bug open for that but i cant find it | 09:46 |
| Chipaca | biezpal: for example, it's looking for a control socket in the wrong place | 09:47 |
| Chipaca | biezpal: and you're getting an apparmor denied from a service, which i thought couldn't happen | 09:47 |
| Chipaca | biezpal: so | 09:48 |
| ogra_ | Chipaca, well, the interesting bit is still that the DENIED messages miss a leading / in the name= bit ... i have never seen that | 09:48 |
| Chipaca | ooooooh | 09:48 |
| Chipaca | biezpal: your service | 09:48 |
| Chipaca | biezpal: is calling binaries you ship | 09:48 |
| Chipaca | biezpal: through their wrapper | 09:48 |
| Chipaca | biezpal: this won't work | 09:48 |
| Chipaca | biezpal: just call the binaries directly | 09:48 |
| Chipaca | ogra_: 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 upgrading | 09:50 |
| Chipaca | biezpal: did what i just said make sense to you? | 09:50 |
| ogra_ | oh, i'm blind :P | 09:50 |
| Chipaca | ogra_: snappy list --updates | 09:50 |
| ogra_ | yeah, that was more about tehupdate command | 09:51 |
| ogra_ | i totally missed that it printed the version in the first output line | 09:51 |
| ogra_ | sadly the running docker service doesnt want to stop, so now it hangs | 09:51 |
| ogra_ | (i started a container manually, seems the systemd unit doesnt get along with that ? | 09:52 |
| ogra_ | ) | 09:52 |
| ogra_ | Waiting for docker_docker-daemon_1.6.2.002.service to stop. | 09:52 |
| ogra_ | ... | 09:52 |
| Chipaca | docker is slow to stop | 09:53 |
| Chipaca | was the first service to necessitate the "waiting" work | 09:53 |
| ogra_ | ok, i'll give it more time then | 09:53 |
| ogra_ | aha | 09:54 |
| ogra_ | it moved to ... | 09:54 |
| ogra_ | Waiting for owncloud_owncloud_8.0.2.004.service to stop. | 09:54 |
| Chipaca | it does eventually get tired of waiting and goes to play with its marbles | 09:55 |
| ogra_ | (which isnt running ... lets see how it deals with that) | 09:55 |
| Chipaca | but shouldn't happen | 09:55 |
| Chipaca | that should be quick then :) | 09:55 |
| ogra_ | yeah, just moved on | 09:55 |
| ogra_ | downloading a new owncloud too | 09:55 |
| * Chipaca is on the edge of his seat | 09:55 | |
| ogra_ | i wonder how we ever want to make this work in webdm | 09:56 |
| ogra_ | your browser will surely time out :) | 09:56 |
| Chipaca | ogra_: heheh | 09:56 |
| Chipaca | ogra_: i dunno if you've looked, but there are these "interacter" things everywhere | 09:57 |
| ogra_ | at the webdm code ? no, not yet :) | 09:57 |
| Chipaca | ogra_: those abstract away the idea that interaction is asynchronous sometimes | 09:57 |
| Chipaca | ogra_: no, in snappy itself | 09:57 |
| ogra_ | ah | 09:57 |
| Chipaca | ogra_: webdm provides its own "progress bar" kinda thing, interacter, whatever you call it | 09:57 |
| Chipaca | ogra_: 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 |
| Chipaca | ogra_: you can't do it with webdm? | 09:58 |
| Chipaca | that's good to know, see :) | 09:58 |
| ogra_ | i usually end up with an error message in webdm | 09: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 |
| kickinz1 | ogra_ 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 |
| kickinz1 | ogra_, 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 |
| ogra_ | ah | 10:00 |
| biezpal | Chipaca, yes, it make sense for me, but we don't calling binaries through the wrapper | 10:00 |
| ogra_ | saving bits :) | 10:00 |
| Chipaca | biezpal: yes you do | 10:00 |
| biezpal | Chipaca, actually, we don't have binaries defined in package.yaml | 10:00 |
| biezpal | Chipaca, http://pastebin.com/hapxpjjc | 10:00 |
| ogra_ | yay | 10:00 |
| ogra_ | it finished | 10:00 |
| Chipaca | oh | 10:00 |
| Chipaca | execve("/apps/openvswitch/current/bin/ovs-vswitchd" | 10:00 |
| Chipaca | biezpal: not through the wrapper | 10:00 |
| kickinz1 | then 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 |
| Chipaca | biezpal: i lied to you | 10:00 |
| Chipaca | biezpal: and that's probably the launcher itself :-/ | 10:01 |
| Chipaca | man i suck at debugging :) | 10:01 |
| biezpal | Chipaca, we are using our own wrappers only when we need to export LD_LIBRARY_PATH for our binaries | 10:04 |
| Chipaca | biezpal: what do you get from | 10:05 |
| Chipaca | biezpal: sudo journalctl -u openvswitch_ovs-init-switch_0.1.service | 10:06 |
| biezpal | Chipaca, http://pastebin.com/w5aw605v | 10:12 |
| === greyback_ is now known as greyback|shops | ||
| Chipaca | biezpal: fwiw, i am able to create a socket and listen on it just fine, with no additional privileges nor anything, in 15.04 amd64 | 10:20 |
| Chipaca | biezpal: are you using a custom policy or something? | 10:20 |
| biezpal | Chipaca, we are able to create and listen on socket too, but we cannot connect to it | 10:21 |
| biezpal | Chipaca, our ugly debug policy prfile: http://pastebin.com/JyjSNW38 | 10:21 |
| ogra_ | kickinz1, seems to be working really well now ... | 10:22 |
| Chipaca | wow | 10:23 |
| biezpal | Chipaca, in unconfined mode everything is ok | 10:23 |
| biezpal | yes, it's ugly :) | 10:23 |
| Chipaca | biezpal: silly question, what permissions does the socket file have? | 10:24 |
| Chipaca | biezpal: 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.sock | 10: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 |
| biezpal | this command creates socket | 10:26 |
| biezpal | and it works under the same profile | 10:26 |
| Chipaca | biezpal: and both these things are services | 10:26 |
| biezpal | "/apps/openvswitch/current/bin/ovs-vswitchd --pidfile unix:$SNAP_APP_DATA_PATH/db.sock" | 10:26 |
| biezpal | last command - connects to the socket | 10:26 |
| ogra_ | with the --pidfile option ? | 10:27 |
| biezpal | yes, both services | 10:27 |
| biezpal | ogra_, yes, it creates pidfile for daemon | 10:27 |
| * ogra_ woould expect a pidfile as argument for this | 10:27 | |
| Chipaca | biezpal: 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 |
| biezpal | ogra_, daemon uses default path for pidfile | 10:28 |
| ogra_ | ok | 10:28 |
| biezpal | Chipaca, ovsdb-server able to create socket under this profile, but ovs-vswitchd can connect only in unconfined mode | 10:29 |
| Chipaca | biezpal: 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 now | 10:31 |
| ogra_ | yeah | 10:31 |
| ogra_ | you can define it via --pidfile= ... | 10:32 |
| biezpal | Chipaca, yes, we are keep it in mind | 10:32 |
| ogra_ | according to the manpage | 10:32 |
| biezpal | we'll change it when solve the main problem :) | 10:32 |
| === greyback|shops is now known as greyback | ||
| Chipaca | biezpal: i'm out of ideas | 10:33 |
| kickinz1 | ogra_, 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 |
| Chipaca | biezpal: let's wait on jdstrand or tyhicks, they're smart :) | 10:33 |
| ogra_ | kickinz1, well, i dont get nagged about upgrades anymore | 10:34 |
| ogra_ | so thats a win | 10:34 |
| kickinz1 | ogra_, 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 stuck | 10:34 |
| ogra_ | cool ! | 10:34 |
| kickinz1 | ogra_, owncloud gets broke, good for fresh install, but definitively need to understand where it hangs. | 10:34 |
| biezpal | Chipaca, thanks for the help anyway, we are also working on it | 10:35 |
| biezpal | waiting for these guys | 10:35 |
| Chipaca | ok. 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 |
| kickinz1 | ogra_ 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 |
| ogra_ | hmm | 10:38 |
| kickinz1 | ogra_ the new owncloud starts, but say it is in maintenance mode, and I had to left it like that. | 10:38 |
| kickinz1 | ogra_ (it say it will work out the migration, then is seems to do something then maintenance mode is on) | 10:39 |
| ogra_ | :( | 10:40 |
| kickinz1 | s/is on/is blocked on/ | 10:41 |
| w2vy | new here... looking at running snappy on freescale i.mx6 or i.mx7 and have some general questions... | 10:49 |
| w2vy | they have their own kernel and build with yocto, just wonder how much of their support i would lose by switching.. | 10:50 |
| w2vy | i 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 imx6 | 11:04 |
| nothal | ravirdv: No such command! | 11:04 |
| w2vy | ok. just curious, why not use the freescale release? | 11:05 |
| ravirdv | Snappy looks good, mainly for OTA | 11:06 |
| ravirdv | I was able to run Ubuntu Core with own kernel | 11:06 |
| ravirdv | trying to build snappy with with a/b partition scheme | 11:06 |
| ravirdv | image* | 11:06 |
| w2vy | i am looking for options because they can't tell me who is responsible for security patches, etc | 11:08 |
| w2vy | from talking to them it sound like the Buck Stops Here... I don't WANT that buck! | 11:08 |
| ravirdv | true, that control has be with us | 11:09 |
| w2vy | us? | 11:09 |
| ravirdv | as in product manufacturers | 11:09 |
| w2vy | you want to have to deal with every patch that is released and apply each one yourself? | 11:09 |
| ravirdv | just the control of which packages goes onto customer's device | 11:10 |
| w2vy | of course... but not each patch to each package! | 11:10 |
| ravirdv | ofcouse not :) | 11:10 |
| w2vy | of 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 patches | 11:11 |
| ogra_ | https://developer.ubuntu.com/en/snappy/guides/porting/ | 11:12 |
| ogra_ | the u-boot bits there need updating, we changed that setup, but the stuff there is definitely enough to make it work | 11:13 |
| w2vy | well here I go again... is there a ubuntu core channel? | 11:14 |
| w2vy | i am trying to drill down to pick a kernel first... | 11:14 |
| ogra_ | not surew what you mean by ubuntu core channel | 11:15 |
| w2vy | me either... | 11:15 |
| ogra_ | ubuntu-core (the non snappy variant) has no channel (though it has nothing to do with snappy) | 11:15 |
| w2vy | lol | 11:15 |
| w2vy | sigh | 11:15 |
| ogra_ | snappy ubuntu-core has this channel | 11:15 |
| w2vy | let me back up and you can tell me where to go... | 11:16 |
| w2vy | i 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 guru | 11:17 |
| w2vy | talking 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 least | 11:19 |
| ogra_ | the porting websie above has that documented in the last paragraph i thinnk | 11:20 |
| ogra_ | *website | 11:20 |
| ogra_ | well, not last but one of the last :) | 11:20 |
| w2vy | yes well "upstream kernel" does not imply any reliability... not like a canonical kernel does... | 11:21 |
| w2vy | i 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 |
| w2vy | yes, but it may have been tested and the patches selected by someone who knows a hellva lot more than me! | 11:22 |
| w2vy | s/someone/a whole team/ | 11:22 |
| ogra_ | did you contact anyone already ? | 11:22 |
| w2vy | yesterday, so i figured i'd try to learn a bit more before they call | 11: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 |
| w2vy | yeah, the "few extra patches" is where I would mess up and ship a holey product | 11:25 |
| ogra_ | totally depends :) | 11:25 |
| w2vy | yeah, 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 stuff | 11:26 |
| w2vy | lol | 11:26 |
| ogra_ | *gonfig | 11:27 |
| ogra_ | bah ! | 11:27 |
| w2vy | config | 11:27 |
| ogra_ | thanks :) | 11:27 |
| w2vy | ok, 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 fancy | 11: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 created | 11:29 |
| ogra_ | if you look for a commercial contact at canonical try maarten.ectors@canonical.com ... he does that stuff for snappy specifically | 11:30 |
| w2vy | thanks | 11:30 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | hmm | 12:05 |
| ogra_ | why is my test initrd only 2.6M big | 12:05 |
| Chipaca | ogra_: 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 chroot | 12: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 aeons | 12:54 | |
| ogra_ | i should have re-partitioned instead of relying on gparted to shrink the partition for testing | 12:58 |
| ogra_ | took 20min already just to resize from 16G to 5 | 12:58 |
| ogra_ | crap ... and indeed the resizing didnt work | 13:01 |
| ogra_ | grrr | 13:03 |
| ogra_ | http://paste.ubuntu.com/12135391/ | 13:03 |
| ogra_ | it did work but didnt re-read the new partition table | 13:03 |
| ogra_ | f*ckk | 13:21 |
| longsleep | ogra_: why does it take so long to resize? | 13:32 |
| ogra_ | longsleep, ask gparted :P | 13:32 |
| ogra_ | i resorted to not cut the partition in half but only make it 2G smaller ... that works a tad faster | 13:33 |
| ogra_ | but still, i cant convince the initrd to reread the new partition table without reboot | 13:33 |
| longsleep | ogra_: did you try to run my script, that works just fine without reboot required if i remember correctly | 13:33 |
| longsleep | maybe the cloud init script does some extra magic | 13: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 |
| longsleep | yeah well, realpath is kind of standard but not part of a shell builtin | 13:34 |
| ogra_ | right, nor is dirname | 13:34 |
| longsleep | busybox does not have it? | 13:34 |
| longsleep | narf :) | 13:34 |
| * ogra_ reboots and prays | 13:35 | |
| ogra_ | (not that i'm religious :P ) | 13:35 |
| longsleep | busybox has dirname and realpath | 13:35 |
| longsleep | so i suggest to just add busybox :P | 13:35 |
| ogra_ | ah, not linked or not the initrd build we use then | 13:35 |
| longsleep | mhm i checked the busybox on my 14.04 workstation, i did assume the one in initrd might be the same | 13:36 |
| longsleep | maybe the links are missing | 13:36 |
| ogra_ | GRRR !"!!! | 13:37 |
| ogra_ | http://paste.ubuntu.com/12135511/ | 13:37 |
| ogra_ | funny that the manpage explicitly lists -R | 13:37 |
| ogra_ | even more interesting that the resizefs complains about missing fsck while i see that running above in the log | 13:38 |
| ogra_ | hmm | 13:40 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ sudo sfdisk -s /dev/sda1 | 13:40 |
| ogra_ | 15666176 | 13:40 |
| ogra_ | and pobviously the kernel actually knows the new partition size ... so somewhere along the way it actually *did* re-read it | 13:40 |
| ogra_ | myths all over the place :P | 13:40 |
| longsleep | oh boy | 13:41 |
| longsleep | ogra_: i remember something about that and reading something that the error is no error and can be ignored in this case | 13:42 |
| ogra_ | well | 13:42 |
| ogra_ | if resize2fs would actually use the new size i wouldnt care about the error :) | 13:42 |
| longsleep | right | 13:42 |
| ogra_ | oh | 13:42 |
| ogra_ | i might have to re-read *before* running fsck | 13:43 |
| * ogra_ tries that | 13:43 | |
| longsleep | ogra_: my script does the job just fine http://paste.ubuntu.com/12135559/ | 13:45 |
| longsleep | ogra_: so it must be some magic of cloud init | 13:45 |
| ogra_ | longsleep, yeah, i cant pull cloud-init into the initrd | 13:46 |
| ogra_ | (and i really dont want to use it | 13:46 |
| ogra_ | ) | 13:46 |
| longsleep | ogra_: yeah, but maybe take a look what it is doing | 13:46 |
| ogra_ | also it operates in a saner environment than initrd ... you have a fully running system up | 13:46 |
| longsleep | well, if it just works you could avoid run it from initrd and do it later as a regular service | 13:47 |
| ogra_ | ok, next try ... | 13:47 |
| * ogra_ crosses fingers | 13:47 | |
| longsleep | btw, growpart is just a bash script too, so you should be able to add this into initrd without too much issue | 13:49 |
| ogra_ | longsleep, i really dont want to tinker with a filesystem underneath a ton of bindmounts | 13:49 |
| ogra_ | resizing from a systemd unit really calls for trouble, even if it might work right now | 13:49 |
| longsleep | ogra_: yeah - i prefer to have it in initrd as well, take a look at the growpart script, it is quite long but works just fine | 13:50 |
| longsleep | it uses partx to update the partition | 13:50 |
| longsleep | and sfdisk | 13:51 |
| longsleep | so you should be good | 13:51 |
| ogra_ | yeah, i really dont want partx in the initrd | 13:51 |
| ogra_ | that will pull in a ton of deps | 13:51 |
| ogra_ | GEEZ ! | 13:52 |
| ogra_ | e2fsck 1.42.12 (29-Aug-2014) | 13:52 |
| ogra_ | ... | 13:52 |
| ogra_ | writable: 135627/840480 files (0.0% non-contiguous), 577059/3368192 blocks | 13:52 |
| ogra_ | resize2fs 1.42.12 (29-Aug-2014) | 13:52 |
| ogra_ | Please run 'e2fsck -f /dev/sda1' first. | 13:52 |
| longsleep | well, 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 | |
| longsleep | ogra_: same disk? | 13:52 |
| ogra_ | the fsck obviously runs directly before the resizefs | 13:52 |
| ogra_ | yes | 13:52 |
| longsleep | hum | 13:52 |
| longsleep | no idea | 13:53 |
| ogra_ | so it checks, gives me the summary and then resize complains | 13:53 |
| ogra_ | i wonder if e2fsck behaves differently if you use -fy vs oinly using -f | 13:56 |
| ogra_ | thats the onl idea i have | 13:56 |
| ogra_ | oh | 13:56 |
| ogra_ | resize2fs has a -f option too ... lets try that one :) | 13:57 |
| ogra_ | heh | 13:59 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ sudo cp chroot/boot/initrd.img-foo /boot/uboot/a/initrd.img | 13:59 |
| ogra_ | ^^^ this takes nearly 5min | 13:59 |
| ogra_ | goota love the RPi IO | 13:59 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | hmm, it definitely does something this time | 14:03 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ df -h |grep oem | 14:04 |
| ogra_ | /dev/sda1 15G 1.9G 12G 14% /oem | 14:04 |
| ogra_ | yippie !! | 14:04 |
| ogra_ | http://paste.ubuntu.com/12135660/ | 14:05 |
| ogra_ | and now the same with running from SD ... | 14:06 |
| ogra_ | lets see what it does if the first partition is already mounted :P | 14:06 |
| jdstrand | beowulf: make sue the review tools are up to date and you are using an up to date snappy binary to build the snap | 14:10 |
| beowulf | jdstrand: it was a problem with myapps.developer.staging.u.c, the core framework had different policy versions on staging and prod | 14:12 |
| Chipaca | ogra_: have not read all the backlog, but "sfdisk -R" used to work, but at least in wily it says you should do "blockdev --rereadpt" instead | 14:14 |
| ogra_ | Chipaca, yeah, thats what i use now | 14:14 |
| Chipaca | ah, k | 14:14 |
| jdstrand | beowulf: ok, cool, glad it is resolved | 14:14 |
| Chipaca | ogra_: 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_ | *first | 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 now | 14:15 |
| asac | kyrofa: 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 work | 14:15 |
| ogra_ | asac, hw-assign | 14:16 |
| ogra_ | for the i2c device i think+ | 14:16 |
| asac | ogra_: dev/i2c...? | 14:16 |
| asac | kk | 14:16 |
| asac | let me try | 14:16 |
| kyrofa | ogra_, check the meta/readme | 14:16 |
| kyrofa | err, asac ^^ | 14:16 |
| ogra_ | me ? | 14:16 |
| ogra_ | heh | 14:16 |
| kyrofa | ogra_, sorry :) | 14:16 |
| asac | kyrofa: it wasnt in the README.md... :) | 14:16 |
| asac | let me see | 14:16 |
| kyrofa | ogra_, I'm so used to typing out your nick really fast | 14:16 |
| asac | gotcha | 14:16 |
| asac | wonder 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 :P | 14:17 |
| kyrofa | asac, 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 |
| kyrofa | asac, the hw-assign? Works for me | 14:18 |
| asac | kyrofa: so after reboot the process is still running | 14:18 |
| asac | but nothing is blinking | 14:18 |
| kyrofa | asac, although it's a little wonky. When you uninstall piglowtop it also removes the hw-assignment, except when it doesn't | 14:18 |
| kyrofa | asac, hmm. systemctl status -l piglowtop_piglowtop_0.1.0.service ? | 14:19 |
| asac | still complains about not being able to access it | 14:19 |
| kyrofa | asac, also verifying i2c is setup: you have /dev/i2c-1? | 14:19 |
| ogra_ | asac, try reboot ? | 14:19 |
| asac | yeah did that | 14:20 |
| asac | i have ls -la /dev/i2c-1 | 14:20 |
| asac | crw------- 1 root root 89, 1 Aug 7 17:01 /dev/i2c-1 | 14:20 |
| asac | have that too | 14:20 |
| asac | maybe i didnt connect it proper? | 14:20 |
| asac | i connected it to the last pins... not the side of the gpiop | 14:20 |
| ogra_ | damn ... that didnt look like it resized | 14:20 |
| * ogra_ guesses it doesnt like having a partition mounted | 14:21 | |
| kyrofa | asac, mine is on the side closest to the power LEDs | 14:21 |
| asac | oh ... so thats different then | 14:21 |
| * asac tries | 14:21 | |
| asac | guess i cant connect the gpio pins anyway when having the orange box closed, so ... :) | 14:22 |
| kyrofa | :P | 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 glow | 14:22 | |
| ogra_ | grmbl | 14:22 |
| ogra_ | now the question is how dangerous is it to ignore that check | 14:23 |
| longsleep | ogra_: well - i am pretty sure there are ways that this breaks the system | 14: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 table | 14:25 |
| ogra_ | and only for a partition that isnt mounted currently | 14:25 |
| longsleep | ogra_: the partition you change is also always at the end - so you should be good in all normal cases | 14:26 |
| asac | and yes, it just started glowing.... i miracle :: | 14:26 |
| asac | thx kyrofa | 14:26 |
| ogra_ | longsleep, right | 14:26 |
| asac | guess device tree could be used to map those pins somwhere else? | 14:26 |
| ogra_ | i think it is fine as an interim solution | 14:26 |
| kyrofa | asac, no problem! Thanks for trying it :) | 14:26 |
| ogra_ | that code wont stay anyway i think | 14:26 |
| asac | kyrofa: you could add a config for it | 14:27 |
| asac | so i could change the values you refer to in README.md | 14:27 |
| asac | right now ping does not glow :) | 14:27 |
| asac | snappy config | 14:27 |
| asac | hook | 14:27 |
| asac | eat yaml, remember values for service etc. | 14:27 |
| asac | but great!! | 14:27 |
| kyrofa | asac, you mean so snappy config can change the brightness, etc? | 14:28 |
| asac | yeah the parameters you mention in README.md | 14:28 |
| vmayoral | ogra_: hi! thanks for the kernel pointers. I'm struggling with udf to recreate the image | 14:28 |
| vmayoral | ogra_: mind looking at https://gist.github.com/vmayoral/c7f9ab2b6160cdcfabca? | 14:28 |
| asac | would be cool to have snappy config so i can change those values from the defaults | 14:28 |
| kyrofa | asac, good idea! I've not messed with snappy config yet | 14:28 |
| asac | for the service | 14:28 |
| asac | its easy kinda | 14:28 |
| kyrofa | :P | 14:28 |
| asac | kyrofa: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example/ | 14:29 |
| asac | just check the meta/hooks dir | 14:29 |
| asac | kyrofa: or http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example-bash/ | 14:29 |
| asac | if you want hacky yaml/bash :) | 14:29 |
| asac | ok guess time to close the case :P | 14:29 |
| kyrofa | asac, thanks for the reference! | 14:30 |
| ogra_ | GRRRRRR !!!! | 14:30 |
| ogra_ | didnt work even with the option forced | 14:31 |
| vmayoral | ogra_: 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 retry | 14:31 |
| ubottu | Launchpad 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 busy | 14: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 thing | 14: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 | |
| asac | resizing premount sounds reasonable | 14:33 |
| asac | you can still finish it today | 14: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 vars | 14:33 |
| ogra_ | vmayoral, well, your output looks slightly different, but yeah, try it | 14:34 |
| ogra_ | damned | 14:53 |
| ogra_ | why the heck does the ubuntu-core initrd script forcefully mount /run/initramfs | 14:53 |
| ogra_ | init does that already and this makes us use all former logs | 14:54 |
| ogra_ | eeek | 14:54 |
| ogra_ | and we even mount /run afresh | 14:54 |
| ogra_ | so mucxh code duplication !!! | 14:55 |
| ogra_ | (and so harmful) | 14:55 |
| Chipaca | ogra_: if only we knew those ubuntu-core people we could make them fix it! | 14:55 |
| ogra_ | haha | 14:56 |
| ogra_ | well, i have a mild guess the person that wrote most of this script isnt here anymore | 14:56 |
| Chipaca | ogra_: :) | 14:56 |
| Chipaca | elopio: so my mp from yesterday should be getting two more auto-comments at some point? | 15:08 |
| elopio | Chipaca: yes, if I manage to get the polling right today. | 15:13 |
| vmayoral | ogra_: 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/33e80be0b06b7a48a74c | 15:13 |
| elopio | Chipaca: 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 |
| Chipaca | elopio: yes, i wasn't expecting a proper code review on this one any time soon | 15:15 |
| vmayoral | ogra_: don't think it's that but let me map dev, proc and sys in the chroot and retry | 15:15 |
| vmayoral | ogra_: nop, got read of the resolving issue but still getting the "exit status 2" | 15:17 |
| vmayoral | s/read/rid | 15:17 |
| Chipaca | vmayoral: have you verified your snap? | 15:20 |
| ogra_ | yay | 15:20 |
| ogra_ | http://paste.ubuntu.com/12136132/ | 15:20 |
| vmayoral | Chipaca: 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 |
| Chipaca | vmayoral: what version of ubuntu-device-flash is that? | 15:21 |
| Chipaca | vmayoral: (do you always sudo when you're already root? :-p) | 15:21 |
| Chipaca | ah, it's in the gist | 15:22 |
| * Chipaca reads | 15:22 | |
| Chipaca | vmayoral: it seems to work here on wily | 15:30 |
| Chipaca | vmayoral: which isn't particularly helpful i know | 15:30 |
| Chipaca | vmayoral: let me see if the other computer is still legacy :) | 15:30 |
| vmayoral | Chipaca: mmmm i just created a new vivid chroot to make sure that it could be reproducible | 15:31 |
| vmayoral | Chipaca: do you think you could try that? | 15:31 |
| Chipaca | vmayoral: i've got a vivid host, let me try there first | 15:31 |
| vmayoral | Chipaca: great, thanks | 15:31 |
| ogra_ | i did build the rpi image on trusty FWIW | 15:32 |
| ogra_ | but using ubuntu-device-flash from the tools PPA so we should be using the same thing | 15:33 |
| Chipaca | john@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-mode | 15:34 |
| Chipaca | Determining oem configuration | 15:34 |
| Chipaca | Using a custom OS or Kernel part will prevent updates for these components | 15:34 |
| Chipaca | Fetching information from server... | 15:34 |
| Chipaca | Downloading and setting up... | 15:34 |
| Chipaca | vmayoral: New image complete | 15:35 |
| ogra_ | looks fine to me | 15: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 |
| Chipaca | ogra_: that's what his apt-cache policy says | 15:36 |
| ogra_ | weird | 15:36 |
| vmayoral | ogra_: yeap | 15:37 |
| Chipaca | vmayoral: 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 |
| Chipaca | ogra_: i aspire to upgrade it to your level someday somehow, but i can read what you write | 15:38 |
| ogra_ | i guess thats enough for a yay or nay :) | 15:38 |
| vmayoral | Chipaca: mmm i'm running a trusty virtual machine and i chrooted the a new vivid image since it was giving me trouble on trusty | 15:38 |
| ogra_ | hmm, i should expand the first changelog line a bit i guess | 15:38 |
| vmayoral | not sure if that's special :( | 15:38 |
| ogra_ | vmayoral, well, it works for me onb trusty too | 15:40 |
| ogra_ | that is how i created the image in the first place | 15:40 |
| Chipaca | ogra_: i see no problems in the shell in the patch | 15:45 |
| ogra_ | cool | 15:45 |
| Chipaca | ogra_: if i were feeling nitpicky i'd ask whether it was intentional to lose precision on the size check | 15:46 |
| Chipaca | ogra_: but i'm not :-P | 15:47 |
| ogra_ | well, i dont really want it to resize just because there are 10k free or some such | 15:47 |
| ogra_ | which is why i picked these artificial 10% | 15:47 |
| ogra_ | [ 9.596964] sda: sda1 | 15:47 |
| ogra_ | e2fsck 1.42.12 (29-Aug-2014) | 15:47 |
| ogra_ | [ 9.951713] random: nonblocking pool is initialized | 15:47 |
| ogra_ | resize2fs 1.42.12 (29-Aug-2014) | 15:47 |
| ogra_ | done. | 15:47 |
| ogra_ | yay | 15:47 |
| ogra_ | so even with USB disk writable partition it works fine | 15:48 |
| Chipaca | ogra_: i meant, you're checking (device_size-used_size) against the floor of device_size/10 | 15:48 |
| Chipaca | so it sometimes won't resize even when you have 10% waste | 15:49 |
| ogra_ | what would you propose ? | 15:49 |
| Chipaca | ogra_: to commit it :) | 15:49 |
| ogra_ | hahaha | 15:49 |
| ogra_ | ok | 15:50 |
| Chipaca | you can tell people to use tune2fs to get back their precious bytes if the need 'em :-p | 15:50 |
| ogra_ | well, we can always improve | 15:50 |
| ogra_ | and i'm not sure at all we'll even keep that code | 15:50 |
| ogra_ | so yeah, let me upload so we have it in tomorrows rolling/edge image | 15:51 |
| ogra_ | so if bug 1485306 could be fixed now ... we could actually make u-d-f create a 1byte partition ... | 15:52 |
| ubottu | bug 1485306 in Snappy "ubuntu-device-flash should not create data in writable partition" [Undecided,New] https://launchpad.net/bugs/1485306 | 15: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 tonight | 15: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 work | 16:02 |
| elopio | ogra_: 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 |
| elopio | I'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 space | 16:06 |
| ogra_ | i guess thats a task for sergiusens then to change u-d-f | 16:06 |
| ogra_ | which we should do in general now | 16:06 |
| ogra_ | to generate smaller images | 16:06 |
| elopio | testing the script itself as it runs in memory, I have no idea how to do that. | 16:06 |
| ogra_ | right | 16:07 |
| sergiusens | ogra_: 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 image | 16:07 |
| sergiusens | ogra_: I'll work on an MP then | 16:07 |
| ogra_ | (still room for improvement, but i understood it is urgent to have it ) | 16:07 |
| sergiusens | ogra_: really? | 16:07 |
| ogra_ | sergiusens, yeah, see the other channel :) | 16:09 |
| elopio | ogra_: I guess you can also run the resize script. Change all the initramfs specifics for parameters so it's easily testable. | 16:11 |
| elopio | so the problem would be the hooks. Maybe sergiusens has ideas, or somebody from the kernel team. | 16:11 |
| elopio | a fake initramfs? | 16:11 |
| ogra_ | well, you need to check it at runtime somehow | 16:12 |
| ogra_ | so i guess a boot test of an image is needed | 16:12 |
| ogra_ | and i assume we dont have anything for that at all yet anyway ... sounds like a bier task | 16:12 |
| ogra_ | *bigger | 16:12 |
| elopio | ogra_: 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 |
| elopio | s/to/too | 16:14 |
| ogra_ | will do | 16: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 before | 16:21 |
| ogra_ | :) | 16:21 |
| === drk|aw is now known as o | ||
| === o is now known as Guest83769 | ||
| sergiusens | ogra_: should we growfs by default and make writable 1MiB? | 17:20 |
| sergiusens | ogra_: 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!