| carif | almost there with my first simple snap, an "echo" shell script. The script isn't executable in the snap, but is in the "source" directory. is that what 'caps: []' does? | 02:03 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| === erkules_ is now known as erkules | ||
| dholbach | good morning | 06:35 |
| fgimenez | good morning | 07:14 |
| biezpal | Hi guys, can anyone help us with libs in .snapp package? Where we should place our libs in snapp package to make it visible for app? | 07:37 |
| ogra_ | anywhere you want ... just make sure to point LD_LIBRARY_PATH to it and export it | 07:38 |
| biezpal | and how we can set the variable for all users? | 07:38 |
| biezpal | now we are doing it manually | 07:39 |
| ogra_ | you usually set it in your wrapper script for the binary or service | 07:41 |
| biezpal | alaik, automatically generated wrapper script is stored in /apps/bin/<appname>, but we cannot customize it during snapp installation. Am I right? | 07:44 |
| biezpal | Or we should create our own wrapper script which will be executed by automatically generated wrapper script? | 07:45 |
| ogra_ | yes | 07:46 |
| ogra_ | (the latter) | 07:46 |
| ogra_ | seb128, hmm, did you ever try snappy update on personal ? | 07:47 |
| * ogra_ gets out of space errors for /system-boot | 07:47 | |
| biezpal | thanks | 07:47 |
| seb128 | ogra_, yes, remember me reporting those kernel mismatch error some days ago :p | 07:48 |
| seb128 | ogra_, let me try with today's image | 07:48 |
| ogra_ | i guess u-d-f needs to learn to assign a bigger /boot | 07:48 |
| ogra_ | well, my update actually failed, i didnt get to a point where i could even boot into the update | 07:48 |
| seb128 | it was working for me yesterday | 07:49 |
| seb128 | well "working" | 07:49 |
| seb128 | the updated system failed to load modules and booted in debug mode | 07:49 |
| ogra_ | right, i remember | 07:50 |
| seb128 | but it's weird, /boot shouldn't be bigger on personal than core, should it? | 07:51 |
| seb128 | we use the same kernel | 07:52 |
| ogra_ | the initrd might be | 07:52 |
| ogra_ | hah ... booting with "kvm -m 384 -vga qxl personal_x86.img" works ! | 08:03 |
| ogra_ | -m 256 sadly doesnt anymore :( | 08:03 |
| seb128 | so I've a "snappy update --automatic-reboot" process | 08:04 |
| seb128 | is there any way to query it for status? | 08:04 |
| ogra_ | not sure, sergiusens would know i guess ... or mvo | 08:05 |
| seb128 | mvo is hidding again! | 08:05 |
| ogra_ | hmm, i take back the above ... 384MB boots ... but i cant log in | 08:07 |
| seb128 | stop asking for more | 08:07 |
| ogra_ | (512M works fine though) | 08:07 |
| seb128 | ogra_, I'm getting that "no space left on device" as well now | 08:12 |
| ogra_ | i think we duplicate kernl and initrd now ... | 08:12 |
| ogra_ | with and withoout version in the name ... | 08:12 |
| ogra_ | hmm, no, a and b only have a single copy each | 08:16 |
| biezpal | ogra_, is there are plans to add something like "LD_LIBRARY_PATH" parameter into meta/package.yml ? | 08:20 |
| ogra_ | no, i dont think so ... but we might add a standard path that the launcher defaults to ... (we use <appinstalldir>/lib/<arch> in click packages for example ... ) so you have a place that always works with extra variable hackery | 08:21 |
| ogra_ | s/with/without/ | 08:21 |
| biezpal | ogra_, cool, thx | 08:22 |
| pitti | sorry, I forgot: what do I have to downgrade in wily again to make ubuntu-device-flash work? | 08:42 |
| seb128 | ogra_, ubuntu-core is having the same upgrade /boot size issue | 08:42 |
| ogra_ | yeah, i would have expected so | 08:43 |
| pitti | ("panic: cannot double map partitions') | 08:43 |
| pitti | (we've had this for weeks, is it so hard to fix?) | 08:43 |
| ogra_ | pitti, i think you should just retry ... iirc Chipaca had the same issue yesterday and it just worked at some point | 08:43 |
| ogra_ | IIRC | 08:43 |
| pitti | I remember fgimenez downgraded something and then it worked | 08:44 |
| seb128 | pitti, nothing to "downgrade" afaik, I'm using wily standard and not having issues | 08:44 |
| pitti | some *mutter* *mutter* go incompatibility | 08:44 |
| pitti | http://paste.ubuntu.com/11854764/ | 08:44 |
| Chipaca | pitti: yes, that's the error we're talking about | 08:46 |
| pitti | and --channel=alpha with rolling doesn't work at all ("Failed to locate latest image information") | 08:46 |
| seb128 | pitti, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516 has a mr ready for review, you might want to give the fix a try? | 08:46 |
| ubottu | Ubuntu bug 1472516 in goget-ubuntu-touch (Ubuntu) "udf cannot double map partitions error" [Undecided,New] | 08:46 |
| pitti | seb128: ah, thanks for the bug pointer! | 08:47 |
| seb128 | yw! | 08:47 |
| Chipaca | pitti: AIUI even though the error isn't handled (hence the panic), it is "real" and coming from a race in partx or sth like that | 08:47 |
| Chipaca | and AIUI the fix to the error is to print it prettier | 08:47 |
| fgimenez | pitti, yep, it's already reported, as ogra_ mentioned retrying helps | 08:47 |
| pitti | ah, it seems the 7th retry worked | 08:47 |
| seb128 | ogra_, so, who need to be nagged about "snappy upgrade" being busted because /boot is too small now? | 08:48 |
| ogra_ | seb128, well, i see we only assign 63M in total for that partition ... u-d-f defines the partition sizes i think | 08:48 |
| ogra_ | a) we need to get back to normal size again ... b) we should assign more space by default anyway | 08:49 |
| pitti | do I need anything else to enable ssh? sshd is running inside, but trying to ssh in just hangs | 08:49 |
| pitti | (I ran with --developer-mode, which should include --enable-ssh) | 08:50 |
| ogra_ | it should even copy your key inside | 08:50 |
| pitti | I see the open port in netstat too | 08:50 |
| pitti | ah - eth0 is not up | 08:50 |
| ogra_ | how long did you wait ... creating the host keys takes a while (cloud-init is pretty slow) | 08:50 |
| pitti | that would do it :) | 08:50 |
| ogra_ | ah | 08:50 |
| ogra_ | well, there is no eth0 anymore because someone changed the device names :P | 08:51 |
| pitti | there is an eth0 in qemu, it's just not up :) | 08:51 |
| * pitti runs sudo ifup eth0 for now | 08:51 | |
| ogra_ | oh ... there should be an entry for it in /e/n/interfaces.d/ then | 08:51 |
| ogra_ | wonder why it isnt brought up now ... | 08:52 |
| pitti | ogra_, Chipaca: thanks for your help! enough to test the updated autopkgtest snappy script | 08:52 |
| ogra_ | Chipaca, ^^ i guess we need to re-visit the NIC changes | 08:52 |
| * Chipaca reads | 08:52 | |
| ogra_ | (the configuration is created fine on boot apparently ... but the interface isnt brought up) | 08:53 |
| Chipaca | very odd | 08:53 |
| pitti | perhaps it's created too late? | 08:54 |
| pitti | i. e. after /etc/init.d/networking already run, respectively after eth0 was already detected and thus ifup@eth0.service triggeerd? | 08:55 |
| pitti | then these need to be restarted | 08:55 |
| Chipaca | pitti: perhaps | 09:05 |
| Chipaca | in which case we need to move firstboot way up :) | 09:06 |
| pitti | Chipaca: note that allow-hotplug gets triggered via udev rules, so it'll run fairly early after udev trigger | 09:07 |
| pitti | Chipaca: probably better to just restart ifup@ after you wrote the file | 09:07 |
| Chipaca | pitti: but we can't restart a service from inside a service | 09:08 |
| Chipaca | it deadlocks | 09:08 |
| pitti | Chipaca: you can, with --no-block | 09:08 |
| pitti | Chipaca: you can also do it more indirectly, with udevadm trigger --sysname-match=eth0 | 09:09 |
| pitti | (or whatever the interface name is) | 09:09 |
| pitti | that pretends eth* was "re-hotplugged", and you don't need to know the precise mechanics how it's brought up | 09:09 |
| JamesTait | Good morning all; happy Friday, and happy Don’t Step On A Bee Day! 😃 | 09:14 |
| ogra_ | save the bees !! | 09:14 |
| ogra_ | (and the bumblebees too) | 09:15 |
| === vrruiz_ is now known as rvr | ||
| seb128 | ogra_, so, who is to nag about snappy update being busted? | 09:32 |
| seb128 | Chipaca? sergiusens? mvo? | 09:32 |
| ogra_ | seb128, sergiusens i think | 09:33 |
| Chipaca | who shouldn't be here today | 09:34 |
| Chipaca | as it's a national holiday for him | 09:34 |
| ogra_ | Chipaca, wasnt that yesterday ? | 09:36 |
| Chipaca | ogra_: yes, but the president got bored or something | 09:37 |
| ogra_ | or did he take a bridge holiday | 09:37 |
| ogra_ | ah | 09:37 |
| Chipaca | declared it a bridge | 09:37 |
| * ogra_ gets ready for dentist ... back later ... | 09:37 | |
| Chipaca | glad she chose that, as the other button was "declare war" | 09:37 |
| sergiusens | ogra_: seb128 Chipaca I am here today, but I've been playing fix the image for a week now, time to pass it on to someone else in the team | 10:47 |
| sergiusens | Chipaca: it's not a bridge | 10:47 |
| Chipaca | sergiusens: my sources have lied to me! | 10:48 |
| * Chipaca has them all go on reddit and bash kittens | 10:48 | |
| sergiusens | Chipaca: http://www.mininterior.gov.ar/tramitesyservicios/feriados.php | 10:52 |
| sergiusens | Chipaca: or en.ar#holiday@group.v.calendar.google.com) | 10:52 |
| * Chipaca tries to decide whether continuing to be wrong would be more o rless fun than being correct | 10:53 | |
| ogra_ | sergiusens, well, i have no clue how the partitioning is done ... but 63M is definitely not enough for three kernels and three initrds on x86/amd64 | 11:29 |
| * ogra_ is happy to take over parts of the image indeed | 11:30 | |
| ogra_ | >(but thats u-d-f which is a black hole for me) | 11:30 |
| sergiusens | ogra_: 63M | 11:34 |
| sergiusens | ogra_: supposed to be 512M | 11:35 |
| sergiusens | ogra_: and I'm not sure what you are talking about | 11:35 |
| ogra_ | hmm, df shows 63 | 11:35 |
| sergiusens | ogra_: oh, right, blame lool | 11:35 |
| sergiusens | ogra_: why are there 3 kernels? | 11:35 |
| sergiusens | should only be 2 | 11:35 |
| ogra_ | sergiusens, amd64 core and personal fail snppy update with an out of space error when copying the kernel to /boot | 11:36 |
| ogra_ | there is one in /boot from the rootfs still | 11:36 |
| ogra_ | (which we should get rid of, but didnt yet apparently) | 11:36 |
| ogra_ | so you have three kernels and initrds | 11:36 |
| sergiusens | ogra_: /boot is part of system-a/b | 11:37 |
| sergiusens | ogra_: /boot/u-boot, /boot/grub and /boot-efi are mounted for system-boot | 11:37 |
| sergiusens | ogra_: and I thought my MP did get rid of the extra kernels fwiw | 11:38 |
| ogra_ | right, /boot/efi is 63M for me here | 11:38 |
| sergiusens | ogra_: right, it is 64M (give or take for alignment), blame lool ;-) | 11:38 |
| ogra_ | i'm currentl ylooking at personbal ... might be that this doesnt have the MP yet | 11:38 |
| * ogra_ blames lool in absence | 11:39 | |
| sergiusens | ogra_: well it's the one you merged ;-) | 11:39 |
| ogra_ | sergiusens, seb128 only merged it yesterday for personal | 11:39 |
| sergiusens | ogra_: the first red in https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158 | 11:39 |
| ogra_ | since it had a bunch of issues i fixed in core first (quoting) | 11:39 |
| sergiusens | ogra_: but that does not come into play for system-boot at all | 11:39 |
| ogra_ | right, only for /boot | 11:40 |
| * davmor2 blames that ogra_ bloke bound to be his fault somewhere along the lines | 11:40 | |
| sergiusens | ogra_: yeah, your code review was terrible ;-) just proving how shell scripting can go ;-) | 11:40 |
| seb128 | ogra_, sergiusens, ubuntu-core has the same issue, I download core 98 and did a "snappy update" before lunch and it failed the same way | 11:40 |
| ogra_ | sergiusens, well, i fixed it at least :P | 11:41 |
| sergiusens | seb128: it was 512M before and I was told to lower it to 64, I don't mind making it 512 again | 11:41 |
| ogra_ | yeah, lets do that again | 11:41 |
| seb128 | smaller is better | 11:41 |
| ogra_ | who knows what people come up with and add to their initrd on custom images :) | 11:41 |
| seb128 | ideally personal would fit on a 8G stick | 11:41 |
| seb128 | but otherwise I've no strong opinion | 11:42 |
| ogra_ | 8G ? | 11:42 |
| ogra_ | i would say 4 ;) | 11:42 |
| seb128 | the personal image doesn't fit on a 8Gb stick | 11:42 |
| seb128 | ogra_, even better | 11:42 |
| sergiusens | seb128: btw, I did your s/ubuntu-core/ubuntu-personal/ thing, but this will play in negatively with the oem snaps, you might need to roll your own due to snappy config ubuntu-core | 11:42 |
| seb128 | but today it's 10Gb | 11:42 |
| ogra_ | (without libreoffice and thunderbird though :) ) | 11:42 |
| seb128 | sergiusens, oh, ok | 11:42 |
| seb128 | ogra_, 4 is a bit short with system-a/b for a full desktop | 11:43 |
| ogra_ | seb128, currently the booted personal image uses 2.3G writable space ... | 11:43 |
| seb128 | why is our image take 10Gb then? | 11:43 |
| ogra_ | system-a|b dupplicates that | 11:43 |
| ogra_ | and you want some wiggle room | 11:43 |
| seb128 | right, but 2.3*2=4.6 | 11:44 |
| seb128 | + boot = 64M atm | 11:44 |
| seb128 | + writable | 11:44 |
| ogra_ | right, 6 should be fine ... and i think we can slim it down a bit still | 11:44 |
| seb128 | we should be able to do e.g a 6G | 11:44 |
| seb128 | well, before sergiusens merged his changed with the 10G size, I tried to build with the size specified to 8 and it failed for some reason | 11:44 |
| seb128 | I never debugged by it wanted more that 8 though | 11:45 |
| ogra_ | anyway, i would at least go with 128M for /boot | 11:45 |
| sergiusens | seb128: ogra_ I chose 10 just to get started, we can lower that as soon as you have the right package set stabilized a bit | 11:45 |
| seb128 | sergiusens, well, when you picked 10 I tried 8 locally because that's what I had as usb stick, but it failed for some reason | 11:46 |
| seb128 | so it seemed it wanted > 8G | 11:46 |
| seb128 | ogra_, right | 11:46 |
| ogra_ | seb128, we were recently discussing making the writable part realyl tiny in the img and then just expand it to full disk on first boot | 11:46 |
| sergiusens | seb128: yeah, the min required size is enforced so people don't have the disk full issue when creating images | 11:46 |
| ogra_ | that should make everyhting way more flexible | 11:47 |
| ogra_ | (and give you a way snaller image) | 11:47 |
| sergiusens | seb128: https://code.launchpad.net/~sergiusens/snappy/rollYourOwnCorePersonal/+merge/264405 | 11:48 |
| seb128 | sergiusens, should that maybe be discussed on the list? I think it is useful, would it only to let people know about the change | 11:52 |
| * ogra_ grumbles about the anesthesia not wearing off today ... annoying | 12:20 | |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | Chipaca: did you get a chance to review the u-d-f MP? | 12:35 |
| Chipaca | sergiusens: url? | 12:38 |
| sergiusens | Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/unmapErr/+merge/264250 | 12:39 |
| Chipaca | yes, i had | 12:40 |
| Chipaca | and now i told launchpad about it and all | 12:40 |
| sergiusens | Chipaca: that makes things better :) | 12:40 |
| rsalveti | sergiusens: is that just to help exposing the error or actually fixing it? | 13:17 |
| rsalveti | ogra_: sergiusens: do we want to remove the duplicated kernel from stable still? | 13:18 |
| rsalveti | sergiusens: moved the meeting to tuesday since we had conflicts on monday | 13:21 |
| rsalveti | mterry: what do we need to change regarding tarmac to land the snapcraft branches? | 13:24 |
| mterry | rsalveti, sergiusens: add ppa:hardware-certification/public to our tarmac machine | 13:25 |
| ogra_ | rsalveti, not sure, i wonder what the risk is | 13:36 |
| ogra_ | (the change would just be two rm's indeed) | 13:36 |
| rsalveti | ogra_: if it's fine to not fix it now, it's also ok | 13:37 |
| rsalveti | but would the kernel always be there after we fix and update? | 13:37 |
| ogra_ | it should be handled like a normal file by s-i | 13:37 |
| ogra_ | so if it goes away in the image it should go away on disk | 13:37 |
| rsalveti | yeah | 13:38 |
| rsalveti | fgimenez: any other issue with the image? | 13:40 |
| rsalveti | fgimenez: https://bugs.launchpad.net/snappy/+bug/1473014 should be fixed with latest | 13:42 |
| ubottu | Ubuntu bug 1473014 in Snappy "waagent related systemd-fstab-generator error" [High,Fix committed] | 13:42 |
| rsalveti | hm, created latest kvm image, did control+c on qemu after it booted completely, trying to boot again but I can't login now | 13:49 |
| rsalveti | and ssh is not giving me the login prompt either | 13:49 |
| ogra_ | lovely :/ | 13:50 |
| rsalveti | and boot took longer as well | 13:50 |
| rsalveti | this is with 15.04/edge | 13:50 |
| sergiusens | mterry: rsalveti k | 13:51 |
| sergiusens | rsalveti: ogra_ it doesn't really matter to ship those kernels | 13:51 |
| ogra_ | sergiusens, rsalveti, hmm, though i wonder if elopio's second fake upgrade issue could be related to a full vfat on the BBB | 13:52 |
| rsalveti | Jul 10 13:50:09 localhost login[656]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', User not known to the underlying authentication module | 13:53 |
| rsalveti | user ubuntu unknown | 13:53 |
| ogra_ | ugh | 13:53 |
| sergiusens | ogra_: rsalveti fwiw https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/biggerPartition/+merge/264421 | 13:54 |
| rsalveti | Jul 10 13:49:36 localhost systemd[1]: Failed to start Login Service. | 13:54 |
| rsalveti | that is why | 13:54 |
| ogra_ | sergiusens, will that automatically adjust the other sizes ? | 13:54 |
| ogra_ | rsalveti, yeah, but why :P | 13:55 |
| sergiusens | but that makes our 4GiB images look like 512MB(system-boot), 1Gib (system-a/b), 512MB (writable) | 13:55 |
| rsalveti | ogra_: my boot log http://paste.ubuntu.com/11856027/ | 13:55 |
| sergiusens | ogra_: yes, it adapts everything else | 13:55 |
| ogra_ | sergiusens, 128M would suffice i guess | 13:55 |
| sergiusens | ogra_: that's what people said about 64 ;-) | 13:55 |
| rsalveti | 512 is a bit too much, isn't it? | 13:56 |
| rsalveti | and why are we changing? | 13:56 |
| rsalveti | sorry, no context | 13:56 |
| sergiusens | ogra_: give me numbers! | 13:56 |
| sergiusens | rsalveti: because ogra_ said so :-P | 13:56 |
| ogra_ | well, people were at least cleverer than bill gates then ... he said 640k is enough ;) | 13:56 |
| sergiusens | rsalveti: ogra_ fwiw, 512 is the recommended size to hold grub stuff from cjwatson | 13:56 |
| ogra_ | rsalveti, rolling has an issue with upgrading on core and personal | 13:56 |
| ogra_ | rsalveti, fails with ENOSPC on /boot | 13:57 |
| ogra_ | Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,808 - cc_growpart.py[DEBUG]: '/' FAILED: failed to resize: disk=/dev/sda, ptnum=3: Unexpected error while running command. | 13:58 |
| ogra_ | Jul 10 13:48:24 localhost cloud-init[605]: Command: ['growpart', '--dry-run', '/dev/sda', '3'] | 13:58 |
| ogra_ | whats that ? | 13:58 |
| ogra_ | rsalveti, smells to me like we run cloud-init in some werd mode | 13:58 |
| ogra_ | *weird | 13:58 |
| rsalveti | yeah, no idea | 13:59 |
| rsalveti | Jul 10 13:48:21 localhost systemd[1]: ubuntu-snappy.boot-ok.service: main process exited, code=exited, status=1/FAILURE | 13:59 |
| rsalveti | Jul 10 13:48:21 localhost systemd[1]: Failed to start Notify bootloader that boot was successful. | 13:59 |
| rsalveti | Jul 10 13:48:21 localhost systemd[1]: Unit ubuntu-snappy.boot-ok.service entered failed state. | 13:59 |
| rsalveti | Jul 10 13:48:21 localhost systemd[1]: ubuntu-snappy.boot-ok.service failed. | 13:59 |
| rsalveti | wow, why? | 13:59 |
| ogra_ | you dont have any network device | 13:59 |
| rsalveti | Jul 10 13:48:21 localhost snappy[554]: invalid package on system | 13:59 |
| sergiusens | rsalveti: what system is this? | 13:59 |
| rsalveti | sergiusens: 15.04/edge, created latest with kvm, booted, hit control+c, started again | 14:00 |
| rsalveti | and now can't even login anymore | 14:00 |
| sergiusens | rsalveti: invalid package on system means you have a package with a . in it when it's no supposed to | 14:00 |
| rsalveti | this is just the base system + webdm | 14:00 |
| rsalveti | didn't change anything, was my second boot | 14:00 |
| sergiusens | rsalveti: created just now? | 14:00 |
| rsalveti | sergiusens: yes | 14:00 |
| sergiusens | rsalveti: no update happened? | 14:00 |
| rsalveti | sergiusens: nops, was latest already | 14:00 |
| sergiusens | rsalveti: command run so I can run | 14:01 |
| ogra_ | rsalveti, hmm, works fine here | 14:01 |
| ogra_ | sudo ubuntu-device-flash core --channel edge -o snappy_core_x86.img --developer-mode 15.04 | 14:01 |
| rsalveti | sudo ubuntu-device-flash core 15.04 --channel edge --oem generic-amd64 --install=webdm --enable-ssh --output ubuntu-15.04-snappy-amd64-generic.img | 14:01 |
| ogra_ | boots even in seconds | 14:01 |
| rsalveti | got image 121 | 14:01 |
| sergiusens | rsalveti: fwiw, you don't need to specify --oem generic-amd64 ;-) | 14:01 |
| ogra_ | yep, same here | 14:01 |
| ogra_ | (imagenumber) | 14:01 |
| ogra_ | let me try with installing webdm | 14:02 |
| rsalveti | sergiusens: I know, this is because I was creating the released images, and wanted to be explicit in my script | 14:02 |
| sergiusens | rsalveti: that's fine | 14:02 |
| ogra_ | rsalveti, with webdm boots fine too | 14:04 |
| rsalveti | ogra_: right, it seems to be a fs corruption issue or something along that line | 14:06 |
| rsalveti | can't reproduce every time | 14:06 |
| fgimenez | rsalveti, no new issues on my side, the upgrade from 106 (kernel 3.19.0-21) to 122 (kernel 3.19.0-22) went fine on bbb http://paste.ubuntu.com/11855291/ | 14:06 |
| ogra_ | i use the udf with personal enabled ... 0.26-0ubuntu1 | 14:06 |
| ogra_ | do you use an older one ? | 14:07 |
| fgimenez | rsalveti, i've been hitting the space problem on rolling http://paste.ubuntu.com/11855475/ | 14:07 |
| rsalveti | fgimenez: great | 14:07 |
| rsalveti | right | 14:07 |
| ogra_ | aha, so it affects arm too | 14:07 |
| sergiusens | rsalveti: works fine here too | 14:08 |
| elopio | good morning | 14:08 |
| fgimenez | hi elopio | 14:09 |
| rsalveti | sergiusens: yup, as I said, I can't always reproduce it either | 14:09 |
| rsalveti | https://bugs.launchpad.net/snappy/+bug/1473465 | 14:09 |
| ubottu | Ubuntu bug 1473465 in Snappy "kvm/generic-amd64: system got in a broken state in the second boot" [Undecided,New] | 14:09 |
| ogra_ | rsalveti, bah, seems it hit it as well now | 14:10 |
| rsalveti | ogra_: \o/ | 14:11 |
| ogra_ | rsalveti, bah, seems it hit it as well now | 14:13 |
| ogra_ | bah | 14:13 |
| ogra_ | EFOCUS | 14:13 |
| rsalveti | hahah | 14:13 |
| sergiusens | ogra_: rsalveti second boot? So if I reboot reboot reboot I eventually hit it? | 14:13 |
| rsalveti | sergiusens: complete first boot then control + c on your kvm console | 14:13 |
| rsalveti | then start it again | 14:14 |
| ogra_ | sergiusens, my first boot was fine ... not sure it was the second ... but now i cant get in at all anymore | 14:14 |
| sergiusens | ogra_: rsalveti get in meaning log in? | 14:14 |
| ogra_ | yes | 14:14 |
| sergiusens | ogra_: ssh or console? | 14:14 |
| ogra_ | login incorrect on all consoles | 14:14 |
| ogra_ | tty and serial in kvm | 14:15 |
| sergiusens | meh, I've rebooted 10 times already | 14:15 |
| ogra_ | cloud-init suddenly seems to write a lot of files | 14:15 |
| ogra_ | i dont think i have seen that before | 14:15 |
| sergiusens | ogra_: rsalveti mount the writable partition and run 'find [mountpath] -ls' and pastebin for me | 14:16 |
| sergiusens | ogra_: rsalveti the growpart will surely break things I guess | 14:16 |
| ogra_ | yeah, i think we hit a stramge cloud-init mode | 14:16 |
| ogra_ | rsalveti, what was the dir you made writable ? | 14:17 |
| rsalveti | ogra_: waagent | 14:17 |
| rsalveti | but that is just for azure | 14:17 |
| sergiusens | rsalveti: there is no waagent anymore | 14:17 |
| rsalveti | /var/lib/waagent | 14:17 |
| sergiusens | rsalveti: it's all in cloud-init now | 14:17 |
| rsalveti | sergiusens: right, but it still uses that dir | 14:17 |
| ogra_ | ah, not /var/lib/cloud | 14:17 |
| sergiusens | the logic | 14:17 |
| ogra_ | k | 14:17 |
| rsalveti | that was for cloud-init | 14:17 |
| rsalveti | sergiusens: http://paste.ubuntu.com/11856151/ | 14:20 |
| ogra_ | sergiusens, http://paste.ubuntu.com/11856150/ | 14:20 |
| ogra_ | hah ! i beat you by 1 | 14:21 |
| rsalveti | not here :P | 14:21 |
| sergiusens | yeah, rsalveti's showed first here, but ogra ran it faster :-P | 14:21 |
| rsalveti | I'm uploading the image as well | 14:22 |
| rsalveti | that will take a few minutes | 14:22 |
| sergiusens | ogra_: rsalveti now "find [mountpath] -name 'package.yaml' -exec cat {} \; " | 14:23 |
| rsalveti | nothing | 14:23 |
| rsalveti | guess the syntax is wrong | 14:23 |
| ogra_ | same | 14:23 |
| sergiusens | rsalveti: maybe :-P | 14:23 |
| sergiusens | mnt/system-data/apps/webdm/0.9/meta/package.yaml | 14:23 |
| ogra_ | ogra@anubis:~/datengrab/images$ sudo find mnt/ -name 'package.yaml' | 14:24 |
| ogra_ | mnt/system-data/apps/webdm/0.9/meta/package.yaml | 14:24 |
| ogra_ | mnt/system-data/oem/generic-amd64/1.4/meta/package.yaml | 14:24 |
| sergiusens | and mnt/system-data/oem/generic-amd64/1.4/meta/package.yaml | 14:24 |
| sergiusens | ogra_: rsalveti | 14:24 |
| sergiusens | oh | 14:24 |
| sergiusens | I see | 14:24 |
| sergiusens | size 0! | 14:24 |
| sergiusens | ogra_: rsalveti it's empty!!! | 14:24 |
| rsalveti | yup, size 0 | 14:24 |
| sergiusens | rsalveti: everything is empty (checks paste again) | 14:25 |
| sergiusens | rsalveti: ogra_ some process did something nasty | 14:25 |
| rsalveti | everything is empty | 14:25 |
| rsalveti | lol | 14:25 |
| rsalveti | fuck | 14:25 |
| rsalveti | lol | 14:25 |
| ogra_ | yeah | 14:25 |
| ogra_ | the prowpart thing from cloud-init i bet | 14:25 |
| sergiusens | we can blame cloud-init and that growpart | 14:25 |
| ogra_ | *grow | 14:25 |
| sergiusens | it's a cloud-init-utils | 14:25 |
| rsalveti | we have a suicidal process around | 14:25 |
| rsalveti | not everything in the partition is 0 size | 14:26 |
| rsalveti | actually no | 14:27 |
| rsalveti | everything is 0, the stuff that is not 0 is because of my other boot | 14:28 |
| sergiusens | rsalveti: directories have sizes different than 0? | 14:28 |
| rsalveti | mostly logs | 14:28 |
| sergiusens | rsalveti: and boots | 14:28 |
| rsalveti | etc/dbus-1/system.d all 0 as well, which explains why systemd is complaining | 14:28 |
| sergiusens | rsalveti: well given that system-data is made out of copies from system-a which is partition 3 which is what growpart wants to play with, I don't think this is surprising | 14:32 |
| rsalveti | right, do we know why it decided to play with that partition? | 14:33 |
| rsalveti | and why didn't this affect first boot | 14:33 |
| rsalveti | and why it works sometimes? | 14:33 |
| rsalveti | :-) | 14:33 |
| sergiusens | rsalveti: why would growpart run anyways? that's cloud-init world | 14:33 |
| rsalveti | sergiusens: I ask you the same question :P | 14:36 |
| sergiusens | rsalveti: darn, I'm always hand picked for debugging :P | 14:36 |
| ogra_ | i dont see all that cloud-init output when removing waagent from writable paths and emptying system-data | 14:36 |
| rsalveti | Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,777 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg. Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices': ['/']} | 14:37 |
| rsalveti | Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,809 - cc_resizefs.py[DEBUG]: resize_info: dev=/dev/sda3 mnt_point=/ path=/ | 14:38 |
| rsalveti | growpart actually failed | 14:38 |
| ogra_ | but it tried to run ... | 14:38 |
| rsalveti | resizing went fine | 14:38 |
| sergiusens | rsalveti: ogra_ we can probably be safe from this if we write a cfg in /etc/cloud/... where we remove growpart's '/' option | 14:38 |
| ogra_ | failed perhps because it was mounted | 14:38 |
| rsalveti | but also something we shouldn't be running | 14:38 |
| ogra_ | sergiusens, well | 14:39 |
| ogra_ | sergiusens, how did it get ther ein the first place | 14:39 |
| rsalveti | we need to understand why this is even required | 14:39 |
| ogra_ | yes | 14:39 |
| rsalveti | maybe utlemming can give us a hand here | 14:39 |
| ogra_ | it wasnt on yesterdays image | 14:39 |
| ogra_ | i booted that a bunch of times | 14:39 |
| sergiusens | ogra_: SRU ;-) | 14:39 |
| rsalveti | the waagent change I did was earlier in the week | 14:39 |
| rsalveti | right, unless cloud-init itself changed | 14:39 |
| rsalveti | but it works sometimes | 14:40 |
| sergiusens | rsalveti: I don't think is related to waagent | 14:40 |
| sergiusens | at all | 14:40 |
| rsalveti | yeah | 14:40 |
| sergiusens | completely orthogonal | 14:40 |
| rsalveti | that would only make a difference for azure | 14:40 |
| ogra_ | rsalveti, clud-init didnt change in the iage | 14:40 |
| ogra_ | *image | 14:40 |
| ogra_ | according to the manifest | 14:41 |
| sergiusens | rsalveti: not only that, it would only make a difference if we didn't provide a seed which we do | 14:41 |
| sergiusens | ogra_: this might have been there for a few weeks and you guys seeing, I haven't seen it yet | 14:41 |
| ogra_ | sergiusens, well, yesterday i definitely booted the same image several times | 14:42 |
| rsalveti | right, I believe it was always there | 14:42 |
| ogra_ | now even a fresh image only works once | 14:42 |
| sergiusens | ogra_: rsalveti we should just add a config with growpart/mode: false | 14:42 |
| sergiusens | ogra_: rsalveti or in ubuntu-core-config -> touch /etc/growroot-disabled | 14:43 |
| sergiusens | or growpart/devices: "" in the config | 14:44 |
| sergiusens | default is '/' | 14:44 |
| rsalveti | yeah, that looks better | 14:44 |
| rsalveti | # if the file /etc/growroot-disabled exists, then cloud-init will not grow | 14:44 |
| rsalveti | # the root partition. This is to allow a single file to disable both | 14:44 |
| rsalveti | # cloud-initramfs-growroot and cloud-init's growroot support. | 14:44 |
| * ogra_ still doesnt feel comfortable not knowing where that came from | 14:44 | |
| sergiusens | ogra_: it comes from cloud-init | 14:44 |
| * sergiusens is reading the sources | 14:45 | |
| ogra_ | sergiusens, i know where it comes from | 14:45 |
| ogra_ | how could that sneak into our image | 14:45 |
| sergiusens | ogra_: then I don't understand "ogra_ still doesnt feel comfortable not knowing where that came from | 14:45 |
| sergiusens | lolz | 14:45 |
| ogra_ | especially on a stable channel | 14:45 |
| ogra_ | yeah, badly phrased :) | 14:45 |
| jdstrand | dholbach: hey, I think there is a problem on the documentation site | 14:46 |
| sergiusens | ogra_: well, it's super hard to diff packages | 14:46 |
| * ogra_ sets up a changelo diff script | 14:46 | |
| * sergiusens wants an all source build system | 14:46 | |
| jdstrand | dholbach: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ doesn't seem to be talking about the correct thing | 14:46 |
| ogra_ | naaah | 14:46 |
| sergiusens | ogra_: well, that does not give me the diff of the orig tarballs which is what I want | 14:46 |
| ogra_ | sergiusens, i want to see if a new clud-init version silently landed in the rootfs | 14:46 |
| ogra_ | (for example) | 14:47 |
| jdstrand | dholbach: it doesn't describe the FHS at all, but instead how updates are applied | 14:47 |
| sergiusens | ogra_: it didn't silently land, it was SRUd | 14:47 |
| ogra_ | without any testing on snappy ? | 14:47 |
| jdstrand | dholbach: it used to be another document I think (I'm not sure) | 14:47 |
| rsalveti | Jul 10 14:45:00 localhost [CLOUDINIT] stages.py[DEBUG]: Running module growpart (<module 'cloudinit.config.cc_growpart' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py'>) with frequency always | 14:47 |
| rsalveti | Jul 10 14:45:00 localhost [CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x7fb5149843c8>) | 14:47 |
| rsalveti | Jul 10 14:45:00 localhost [CLOUDINIT] cc_growpart.py[DEBUG]: growpart disabled: mode=False | 14:47 |
| ogra_ | i guess we need to add that to the SRU reqs | 14:47 |
| sergiusens | ogra_: not sure, and growroot might have always been there | 14:47 |
| rsalveti | Jul 10 14:45:00 localhost [CLOUDINIT] cc_resizefs.py[DEBUG]: Skipping module named resizefs, resizing disabled | 14:47 |
| rsalveti | on first boot | 14:47 |
| rsalveti | it didn't run | 14:47 |
| dholbach | jdstrand: I think that's an issue in https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst then | 14:47 |
| ogra_ | sergiusens, but hasnt been enabled | 14:47 |
| rsalveti | also didn't run now during my second boot | 14:48 |
| rsalveti | ogra_: sergiusens: so it's not always running | 14:48 |
| sergiusens | dholbach: I thought we were not supposed to use trunk for the stable documentation | 14:49 |
| sergiusens | dholbach: but lp:snappy/15.04 /docs | 14:49 |
| dholbach | sergiusens, sorry, wrong branch | 14:49 |
| dholbach | sergiusens, I doubt the file has changed since then | 14:49 |
| ogra_ | http://launchpadlibrarian.net/208620766/cloud-init_0.7.7~bzr1091-0ubuntu2_0.7.7~bzr1091-0ubuntu3.diff.gz | 14:49 |
| dholbach | https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/system-updates.rst | 14:49 |
| dholbach | jdstrand: ^ sorry, wrong branch earlier | 14:50 |
| jdstrand | I just filed bug #1473478 for this | 14:50 |
| nothal | Bug #1473478: snappy/guides/filesystem-layout/ no longer describes the FHS in detail <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1473478> | 14:50 |
| ubottu | bug 1473478 in Ubuntu Developer Portal "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New] https://launchpad.net/bugs/1473478 | 14:50 |
| rsalveti | sergiusens: ogra_: the interesting piece: http://paste.ubuntu.com/11856263/ | 14:50 |
| dholbach | thanks jdstrand | 14:50 |
| rsalveti | there is already a config disabling it | 14:50 |
| rsalveti | now why did it run? nobody knows yet | 14:51 |
| sergiusens | rsalveti: ogra_ might be related to making /etc/cloud/cloud.cfg.d a writable path and a race there | 14:51 |
| rsalveti | hm, that's a writable space | 14:51 |
| rsalveti | right | 14:52 |
| rsalveti | the broken image http://people.canonical.com/~rsalveti/ubuntu-15.04-snappy-amd64-generic-broken.img.xz | 14:52 |
| rsalveti | sergiusens: if you want to take a look | 14:52 |
| sergiusens | although writable paths are computed before anything else | 14:52 |
| rsalveti | yup, initrd | 14:53 |
| sergiusens | rsalveti: the only way for writable to be setup is for it run from initrd | 14:53 |
| sergiusens | ogra_: which begs the question, was the SRUd kernel+new init tested with snappy ;-) | 14:53 |
| ogra_ | sergiusens, why initrd ? | 14:54 |
| ogra_ | nothing should have changed there | 14:54 |
| sergiusens | rsalveti: so the initial copy went bad, cloud-init ran with its "default" config as all those file were empty | 14:54 |
| sergiusens | that settles it | 14:54 |
| rsalveti | right, growroot running is just a consequence | 14:55 |
| sergiusens | so the component that copies with the 'transition' rule is doing something bad | 14:55 |
| rsalveti | but, having such an important config as part of a writable space is dangerous | 14:55 |
| rsalveti | not sure if the copy was broken | 14:56 |
| rsalveti | control + c, might be that the fs was just corrupted | 14:56 |
| sergiusens | control + c? | 14:57 |
| rsalveti | on kvm | 14:57 |
| rsalveti | if I call sudo reboot it always works | 14:57 |
| rsalveti | the bug I got was when aborting kvm with a running system | 14:57 |
| ogra_ | rsalveti, could your wait-for-root change trigger any races in the transition copying ? | 14:57 |
| rsalveti | ogra_: don't think so | 14:58 |
| ogra_ | the PPA diff is a joke https://launchpadlibrarian.net/209263590/initramfs-tools-ubuntu-core_0.7.7~ppa1_0.7.7~ppa2.diff.gz | 14:58 |
| rsalveti | how are we mounting the writable dir? | 14:58 |
| ogra_ | i assume you didnt only quieten the output there, right ? | 14:58 |
| ogra_ | rsalveti, systemd shoudl parse fstab | 14:58 |
| ogra_ | (which we feed from initramfs ) | 14:58 |
| rsalveti | ogra_: that was the second upload, since wait-for-root was printing the fs format | 14:59 |
| ogra_ | rsalveti, right, thats what i mean ... PPA diffs are the moste useless thing | 14:59 |
| ogra_ | *most | 14:59 |
| rsalveti | /dev/sda5 on /writable type ext4 (rw,relatime,discard,data=ordered) | 14:59 |
| ogra_ | sounds fine | 14:59 |
| rsalveti | yeah | 14:59 |
| jdstrand | rsalveti: fyi, bug #1473478 - dholbach says it is an issues in the snappy docs. I think it is a critical issue for devs | 15:00 |
| nothal | Bug #1473478: snappy/guides/filesystem-layout/ no longer describes the FHS in detail <Ubuntu Developer Portal:New> <Snappy:New> <http://launchpad.net/bugs/1473478> | 15:00 |
| ubottu | bug 1473478 in Snappy "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New] https://launchpad.net/bugs/1473478 | 15:00 |
| mattyw | hey folks, my snap is producing the following error when I run it - fork/exec /usr/bin/ssh: operation not permitted. Can't quite work out what I should be adding to the seccomp stuff, seems like I might not even be allowed? | 15:00 |
| mattyw | sergiusens, do you know the answer ^^ ? | 15:02 |
| sergiusens | mattyw: that's not seccomp, that's apparmor; dmesg|grep DEN | 15:03 |
| mattyw | sergiusens, any idea what should I be putting in apparmor? | 15:05 |
| sergiusens | jdstrand: I don't understand the 'no longer' part as we haven't been updating the docs in lp:snappy/15.04 for this to be consumed incorrectly | 15:05 |
| sergiusens | mattyw: you need to go deeper into the apparmor world, jdstrand can help, you can start out by looking at the one in webdm | 15:06 |
| jdstrand | sergiusens: there used to be a doc that had a table of /apps, /var/lib/apps, /home, etc that described all the FHS bits. that doc used to be at https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/. What is in https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ now seems a totally different doc | 15:06 |
| sergiusens | jdstrand: right, I don't see how a document explaining how updates work are the culprit for this... | 15:07 |
| jdstrand | sergiusens: actually, can we recommend looking at the one in hello-dbus-fwk going forward instead? webdm is a huge exception with its policy and lack of seccomp | 15:08 |
| jdstrand | mattyw: ^ | 15:08 |
| rsalveti | sergiusens: ogra_: so the image only breaks if you hit control + c after the first boot | 15:08 |
| sergiusens | jdstrand: sure, but mattyw wants to exec ssh and on second though, he may need to provide it in his snap instead | 15:08 |
| ogra_ | hmpf | 15:08 |
| rsalveti | because the fs gets corrupted | 15:08 |
| ogra_ | ext4 should still recover | 15:08 |
| sergiusens | rsalveti: oh, ctrl+c from the terminal running kvm you mean? | 15:09 |
| jdstrand | sergiusens: no, I get that. what I am saying is the hello-dbus-fwk has security-policy that is better for people to model their stuff on than webdm. that is all | 15:09 |
| rsalveti | sergiusens: yes | 15:09 |
| sergiusens | jdstrand: sure, I'll recommend that, but typing webdm is faster than hello-dbus-fwk :-P | 15:09 |
| jdstrand | http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/package-dir-fwk/ | 15:09 |
| jdstrand | sergiusens: yes, but I was just in an hour meeting talking to people about how their policy is far too lenient because they used webdm as a template :P | 15:10 |
| jdstrand | to be fair, the whole meeting wasn't on that | 15:10 |
| davidcalle | jdstrand, about https://bugs.launchpad.net/developer-ubuntu-com/+bug/1473478 | 15:11 |
| ubottu | Ubuntu bug 1473478 in Snappy "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New] | 15:11 |
| jdstrand | sergiusens: re the docs site, I don't claim to know where the problem lies, I only know there is a problem | 15:11 |
| davidcalle | jdstrand, are you looking at the page in "live" or "draft" mode? | 15:11 |
| jdstrand | davidcalle: I just went to https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/. I am not logged in | 15:12 |
| jdstrand | I think the mapping is wrong | 15:12 |
| jdstrand | ie, the url is https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ | 15:12 |
| davidcalle | jdstrand, ok, then the fix needs to happen here https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/system-updates.rst (afair, the doc has barely changed over time) | 15:13 |
| jdstrand | but the title is 'Snappy Transactional System Updates' | 15:13 |
| jdstrand | ie, it is just not the correct subject | 15:13 |
| elopio | fgimenez: (amd64)ubuntu@localhost:~$ which dpkg-query | 15:13 |
| elopio | /usr/bin/dpkg-query | 15:13 |
| elopio | that's 15.04 | 15:13 |
| elopio | (amd64)ubuntu@localhost:~$ which dpkg-query | 15:13 |
| elopio | (amd64)ubuntu@localhost:~$ | 15:13 |
| jdstrand | davidcalle: why does system-updates.rst refer to filesystem-layout? | 15:13 |
| elopio | that's rolling. | 15:13 |
| jdstrand | those are different topics | 15:13 |
| fgimenez | elopio, yes, makes sense | 15:14 |
| davidcalle | jdstrand, that's also the only doc talking about the layout | 15:14 |
| jdstrand | davidcalle: well, here is further proof of what I am saying | 15:14 |
| jdstrand | davidcalle: 'system-updates.rst' refers to https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ for more info | 15:14 |
| jdstrand | at the bottom | 15:14 |
| jdstrand | something went wrong | 15:14 |
| jdstrand | look in section 10 | 15:15 |
| davidcalle | jdstrand, oh... ok. I don't think that's a doc regression, though, as I don't remember anything else about the fs. But yes, we need a proper fs doc. | 15:16 |
| davidcalle | (otp, brb) | 15:16 |
| jdstrand | davidcalle: I promise you it is a regression. I refer to that doc all the time | 15:16 |
| jdstrand | I refer to it in the security.md | 15:17 |
| jdstrand | precisely because it used to go into the FHS in detail | 15:17 |
| * jdstrand attempts a google cache to prove | 15:17 | |
| sergiusens | jdstrand: the title and the .rst pointed to correlate to me; the paritioning thing came from a google doc afaik | 15:18 |
| jdstrand | but clearly, even system-updates.rst expects this to gbe a different document-- it is referencing it in rreferences | 15:18 |
| jdstrand | sergiusens: ok, then can someone put the partitioning bits back? | 15:19 |
| jdstrand | ie, update system-updates.rst | 15:19 |
| jdstrand | really, I don't care-- either https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ needs to get the info back or a new page needs to be written and everything needs to be updated to refer to it. the former is easier by far | 15:20 |
| jdstrand | google cache is already updated | 15:20 |
| sergiusens | jdstrand: https://docs.google.com/document/d/1NdBgQXfuJWBOYT-iceTgagavE2r44dUs822gfAM9Srw/edit | 15:21 |
| sergiusens | jdstrand: I think the doc huys just imported the wrong docs | 15:21 |
| jdstrand | davidcalle: ^ | 15:22 |
| rsalveti | sergiusens: ogra_: I think it's the same fs corruption issue we had with touch | 15:22 |
| jdstrand | yes! | 15:22 |
| rsalveti | which made us change from data=ordered to data=journal | 15:22 |
| jdstrand | that is the page I was referring to | 15:22 |
| sergiusens | jdstrand: I updated the bug report | 15:22 |
| jdstrand | thanks | 15:23 |
| sergiusens | np | 15:23 |
| sergiusens | rsalveti: change it then ;-) | 15:23 |
| rsalveti | ogra_: sergiusens: I think we should probably do the same with snappy | 15:23 |
| rsalveti | right | 15:23 |
| * jdstrand notes that dpm said "Content now published on http://developer.ubuntu.com/snappy/filesystem-layout/" in a comment in that google doc :) I knew I wasn't crazy | 15:23 | |
| ogra_ | rsalveti, yeah | 15:23 |
| jdstrand | davidcalle: this is what it used to be: http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ | 15:24 |
| jdstrand | davidcalle: web.archive.org had the new cache around June 10th | 15:25 |
| sergiusens | mterry: http://paste.ubuntu.com/11856443/ | 15:25 |
| * mterry hugs sergiusens | 15:26 | |
| ogra_ | hmm why does sudo halt not kill my kvm | 15:26 |
| ogra_ | rsalveti, hmm, so after halting the system properly on first boot it doesnt fall over anymore if i ctrl-c | 15:29 |
| jdstrand | beuno: what does "Move to waiting for updates queue" do in the store? is that the correct thing to do if they need to perform an update before acceptance? | 15:29 |
| ogra_ | i cant get into the broken state | 15:29 |
| rsalveti | ogra_: that's because the writable data is already there | 15:29 |
| beuno | jdstrand, it's to dismisss something from the queue until they reply or upload | 15:29 |
| rsalveti | ogra_: it's a first boot thing as it's when the writable data gets copied over | 15:30 |
| beuno | so I think, yes | 15:30 |
| beuno | if you ask for more info | 15:30 |
| beuno | it does that as well | 15:30 |
| ogra_ | rsalveti, yes, but i think we dont need to change the mount options but call sync a few times in the right place | 15:30 |
| beuno | so it's more to do that, without having to write something becuase you've already communiuated | 15:30 |
| jdstrand | beuno: great, thanks! | 15:30 |
| rsalveti | ogra_: journal is a safe option, and also good since we can avoid the same apparmor issues we had | 15:31 |
| rsalveti | with phone | 15:31 |
| ogra_ | rsalveti, the initrd script mouonts /writable and copies the stuff ... but never unmounts or syncs | 15:31 |
| rsalveti | ogra_: because it stays there | 15:31 |
| rsalveti | for the bind mounts | 15:31 |
| ogra_ | so the partition content stays in cache | 15:31 |
| ogra_ | and then you ctrl-c | 15:31 |
| ogra_ | so simply adding a sync call at the end of the copying to flush the cache on boot already should save us | 15:32 |
| rsalveti | right, a sync would already help, but I think journal is still a better option | 15:32 |
| rsalveti | to avoid general writable space corruption issues | 15:32 |
| ogra_ | yes, we should do that, but will it be enough (will it write synced then ?) | 15:33 |
| rsalveti | ogra_: I think so, it gets to the journal first | 15:34 |
| rsalveti | we can try | 15:34 |
| ogra_ | i suspect even with the mount option set you wont flush the cache in time | 15:34 |
| rsalveti | let me upload the change | 15:34 |
| ogra_ | +1 | 15:34 |
| sergiusens | rsalveti: ogra_ just do both | 15:41 |
| rsalveti | sergiusens: don't think we need sync with journal | 15:41 |
| rsalveti | but yeah, already uploaded just with journal | 15:41 |
| rsalveti | will test once the new image is out | 15:41 |
| ogra_ | right, lets test that first | 15:41 |
| ogra_ | a sync after copy makes sense in any case though ... but if journal helps for this image thats enough | 15:42 |
| davidcalle | jdstrand, can you confirm that doc is still valid with latest 15.04? | 15:42 |
| rsalveti | sergiusens: don't know if you replied, but for https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516 we still need a fix, right? | 15:45 |
| ubottu | Ubuntu bug 1472516 in goget-ubuntu-touch (Ubuntu) "udf cannot double map partitions error" [Undecided,Confirmed] | 15:45 |
| ogra_ | some poeople did hit it the last two-three days in here | 15:45 |
| rsalveti | yeah, I'm expecting a lot of people getting that bug once we promote it to tools | 15:46 |
| ogra_ | merged 3h ao :) | 15:46 |
| ogra_ | *ago | 15:46 |
| rsalveti | ogra_: but don't know if that is the fix | 15:46 |
| rsalveti | that was my question to sergiusens | 15:46 |
| ogra_ | ah | 15:46 |
| sergiusens | rsalveti: ogra_ there's an MP at the end there | 15:49 |
| jdstrand | davidcalle: system-updates.rst is invalid with 15.04. http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ is correct | 15:49 |
| rsalveti | sergiusens: my question is if the mp really fixes the issue | 15:49 |
| jdstrand | davidcalle: I think that http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ should be restored and system-updates.rst mapped to something else | 15:49 |
| sergiusens | I can release that, it is related to error encapsulation; this would expose the actual issue and fail gracefully | 15:49 |
| sergiusens | rsalveti: I don't know, I can't reproduce | 15:49 |
| rsalveti | sergiusens: right, let's release this and copy to tools-proposed then | 15:50 |
| sergiusens | rsalveti: I just followed the trace | 15:50 |
| rsalveti | then we can get people to test it a bit more | 15:50 |
| rsalveti | at least Chipaca was getting it all the time | 15:50 |
| jdstrand | davidcalle: but, please talk to the snappy guys-- sergiusens suggested system-updates.rst may be wrong to begin with | 15:50 |
| sergiusens | rsalveti: yeah, that's why I asked him to review, not sure if he tested though | 15:50 |
| elopio | fgimenez: can you run the integration suite? In the latest #103 it can't ssh, but it seems to work in #102. | 15:50 |
| jdstrand | looking at the bzr commits, james hunt added ./system-updates.rst on 2015-04-15 | 15:51 |
| davidcalle | jdstrand, ok, I'm finishing restoring the old one (as Filesystem layout). I'll rename the existing one to "Transactional updates", then we'll see what to do with it. | 15:51 |
| jdstrand | it references https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ | 15:51 |
| jdstrand | it is intended to be a difference doc | 15:51 |
| jdstrand | davidcalle: that sounds perfect | 15:51 |
| jdstrand | davidcalle: thank you so much! :) | 15:52 |
| sergiusens | +1 | 15:52 |
| Chipaca | rsalveti: sergiusens: i got it a lot, but not all the time; after N tries i got an image | 15:52 |
| Chipaca | sergiusens: i did not get the error with your branch, but i didn't try 20 times either | 15:52 |
| Chipaca | sergiusens: should i? | 15:52 |
| * Chipaca can do a for | 15:52 | |
| rsalveti | would be nice, yeah | 15:52 |
| sergiusens | Chipaca: maybe :-P at least we can see the underlying error | 15:52 |
| fgimenez | elopio, i'm having problems with udf, let me try | 15:53 |
| Chipaca | sure | 15:53 |
| sergiusens | and I can fix before releasing | 15:53 |
| sergiusens | fgimenez too if time permit | 15:53 |
| fgimenez | sergiusens, ok | 15:53 |
| sergiusens | Chipaca: btw, pb has a race wrt to start and finish calls | 15:54 |
| jdstrand | vmayoral|pc, lool: fyi, the https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ wrong content issue is https://bugs.launchpad.net/snappy/+bug/1473478. davidcalle is fixing it as we speak | 15:54 |
| ubottu | Ubuntu bug 1473478 in Snappy "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New] | 15:54 |
| sergiusens | Chipaca: we might need a package update | 15:54 |
| lool | jdstrand: ah great thanks | 15:54 |
| Chipaca | sergiusens: goget-ubuntu-touch is missing gettext in dependencies? | 15:55 |
| mattyw | sergiusens, sorry, me again, any idea what a aa_change_onexec failed with -1 error is telling me? | 15:55 |
| fgimenez | elopio, btw, finally in azure with --vm-size Medium works fine for me :) | 15:55 |
| elopio | fgimenez: good, once we get the tests running we can put the instructions in the readme | 15:56 |
| sergiusens | Chipaca: oh, I added that to my release branch... | 16:00 |
| rsalveti | ogra_: sergiusens: elopio: building new image for 1473465 | 16:00 |
| sergiusens | rsalveti: ok for 0987654321 (?) | 16:00 |
| * sergiusens takes a chance with a bad joke | 16:00 | |
| * ogra_ has a lottery bill with exactly that number ! | 16:01 | |
| sergiusens | mattyw: most likely that your appamor profile is bad | 16:01 |
| sergiusens | or points to a file that doesn't exist | 16:01 |
| davidcalle | jdstrand, sergiusens : so, https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ and https://developer.ubuntu.com/en/snappy/guides/transactional-updates/ | 16:01 |
| jdstrand | davidcalle: looks great! | 16:01 |
| jdstrand | davidcalle: thanks! :) | 16:02 |
| sergiusens | wfm | 16:02 |
| sergiusens | Chipaca: scratch that, I didn't upload the 0.26 branch :-/ | 16:05 |
| * Chipaca scratches | 16:05 | |
| davidcalle | np :) | 16:05 |
| sergiusens | Chipaca: grab trunk again and it will all bzr bd/sbuild just fine | 16:07 |
| Chipaca | i'll take your word for it :) | 16:07 |
| fgimenez | sergiusens, building from trunk works for me | 16:07 |
| fgimenez | but 0.25-0ubuntu1, don't know if that's right | 16:09 |
| fgimenez | elopio, it cannot ssh with latest rolling/edge, trying now with revision -1 | 16:09 |
| fgimenez | elopio, 102 works fine | 16:14 |
| fgimenez | sergiusens, in fact i'm not sure if it works http://paste.ubuntu.com/11856655/ | 16:16 |
| fgimenez | elopio, i'm getting the same error on 102 too eventually, will catch up next monday o/ | 16:24 |
| mattyw | sergiusens, sorry, me again, nothing I do gives me anything other than that error message. Could I send you the snap to see what's wrong? | 16:29 |
| mattyw | sergiusens, and I'm sure nothing has changed - and I used to get a different error | 16:30 |
| mterry | rsalveti, if you can also review https://code.launchpad.net/~mterry/snapcraft/local-plugins/+merge/264305 that would be swell | 16:30 |
| mattyw | sergiusens, or suggest someone else who might be able to help? | 16:31 |
| mattyw | sergiusens, ah, I might have it | 16:33 |
| sergiusens | mattyw: send me the snap if you want (or link to it) | 16:34 |
| mattyw | sergiusens, I finally found it :) sorry for pestering :) | 16:35 |
| sergiusens | no worries | 16:35 |
| sergiusens | Chipaca: given http://paste.ubuntu.com/11856655/ I now know that format is failing, just need a better message, going to craft an MP | 16:36 |
| mattyw | sergiusens, it would be nice to have some tooling to parse package.yaml and apparmor/ seccomp files to at least check they parse ok, the problem seems to be that snaps can get built with that stuff not being valid | 16:37 |
| ogra_ | mattyw, we have tools for that in snappy build ... | 16:37 |
| sergiusens | mattyw: yeh, we are discussing adding json-schema support to all yamls with ricmm | 16:37 |
| ogra_ | they are just temporary disabled | 16:37 |
| sergiusens | jdstrand: btw, we are considering adding json-schema support to all our yamls | 16:38 |
| mattyw | ogra_, sergiusens awesome news | 16:38 |
| sergiusens | mattyw: for now, run click-reviewer-tools against the built package | 16:39 |
| vmayoral|pc | jdstrand: that's great thanks! | 16:39 |
| mattyw | sergiusens, what ppa is that in? | 16:39 |
| mterry | sergiusens, it would be nice if we had proper jenkins instances for snappy branches. Could build the debian package, could install packages as needed, etc | 16:40 |
| sergiusens | mterry: ppa:snappy-dev/tools | 16:40 |
| mterry | mattyw, ^ | 16:40 |
| sergiusens | yeah | 16:40 |
| mterry | :) | 16:40 |
| mattyw | mterry, sergiusens thanks :) | 16:40 |
| sergiusens | mterry: maybe; as I said, this tarmac thing was meant for go and snap packages not having debian packaging | 16:41 |
| sergiusens | mterry: I don't like jenkins so I'll leave that to someone else | 16:41 |
| sergiusens | already had my fair share of grief with it when I was with the ci+qa team | 16:42 |
| mterry | sergiusens, ah hrm. Do you have a preferred tool in the same problem space? | 16:42 |
| sergiusens | mterry: I don't think we have one for launchpad, at least a one size fits all solution | 17:00 |
| jdstrand | sergiusens: json-schema support? you mean, supporting json in the yaml? | 17:00 |
| sergiusens | jdstrand: http://www.yaml.org/spec/1.2/spec.html#id2803231 | 17:01 |
| sergiusens | mterry: I would love to just use travis fwiw | 17:02 |
| sergiusens | rsalveti: Chipaca https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/ErrExec/+merge/264440 | 17:14 |
| sergiusens | rsalveti: Chipaca from fgimenez' pastebin I guess the error he gets either comes from dmsetup clear or kpartx -ds, both related to unmapping | 17:15 |
| * Chipaca thinks it's nigh on beer o'clock | 17:15 | |
| Chipaca | sergiusens: 100 runs didn't get me the error here :-( | 17:15 |
| sergiusens | Chipaca: did you reboot? /me thinks kernel got confused | 17:16 |
| Chipaca | sergiusens: yesterday to fix it? dmsetup clear'ing between tries got it working | 17:17 |
| Chipaca | losetup/dmsetup/partx thing | 17:17 |
| sergiusens | Chipaca: what order is the suggested order? | 17:19 |
| sergiusens | Chipaca: dmsetup clear, kpartx -ds and last losetup -d ? | 17:20 |
| Chipaca | sergiusens: i did no research on this. i did it backwards to that though. | 17:20 |
| Chipaca | i think | 17:20 |
| Chipaca | not sure :) | 17:20 |
| sergiusens | Chipaca: you should delete the mapping for a loop device before deleting the loop device though | 17:21 |
| sergiusens | Chipaca: shouldn't | 17:22 |
| sergiusens | rsalveti: new u-d-f building | 17:32 |
| * elopio goes home before getting trapped here by the rain. | 17:58 | |
| === josepht` is now known as josepht | ||
| rsalveti | sergiusens: cool | 18:02 |
| rsalveti | builders are busy it seems | 18:02 |
| rsalveti | just built for ppc | 18:03 |
| rsalveti | webdm failed to install: Get https://public.apps.ubuntu.com/anon/download/canonical/webdm.canonical/webdm.canonical_0.9_multi.snap: EOF | 18:21 |
| rsalveti | niiice | 18:21 |
| rsalveti | trying again | 18:21 |
| rsalveti | ogra_: interesting https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/32102 | 18:22 |
| rsalveti | started 2 hours ago, still running | 18:23 |
| rsalveti | let's try yet another build | 18:37 |
| carif_ | is this channel archived somewhere? | 19:01 |
| Letozaf_ | higgins, someone asked me if you can open a terminal in Snappy personal desktop, can it be done ? | 19:16 |
| Letozaf_ | hi not higgins :( sorry | 19:16 |
| sergiusens | Chipaca: btw, I don't see you on untappd! | 19:19 |
| sergiusens | rsalveti: https://launchpad.net/builders seems to be availability for amd64 for only | 19:20 |
| rsalveti | sergiusens: yeah, everything is currently stuck | 19:21 |
| rsalveti | image, package builds, etc | 19:21 |
| Letozaf_ | no matter, found out by myself how to do it, thanks | 19:22 |
| elopio | a man came and brought the internet \o/ | 19:43 |
| rsalveti | elopio: \o/ | 19:45 |
| rsalveti | sergiusens: yeah, builds are busted | 19:45 |
| rsalveti | database outage | 19:45 |
| rsalveti | so yeah, guess no release for today =\ | 19:45 |
| sergiusens | rsalveti: oh well | 19:55 |
| rsalveti | sergiusens: at least it's already beer o clock for you it seems :-) | 19:56 |
| sergiusens | rsalveti: yup :-) | 19:57 |
| ogra_ | carif_, on irclogs.ubuntu.com | 20:05 |
| ogra_ | rsalveti, hmm, looks like it built fine | 20:05 |
| rsalveti | ogra_: image is still building | 20:06 |
| ogra_ | well, the log disagrees | 20:06 |
| rsalveti | colin said the buildds should be mostly fine now | 20:06 |
| rsalveti | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/ | 20:06 |
| rsalveti | needs building here | 20:06 |
| rsalveti | that other one was canceled | 20:06 |
| rsalveti | since it got stuck | 20:06 |
| ogra_ | i dont see amd64 | 20:06 |
| ogra_ | did you run it with ARCHES= set ? | 20:07 |
| ogra_ | <cjwatson> boiko,robru: lots of buildd breakage at the moment due to a partial database outage today, need to analyse the whole lot and repair | 20:09 |
| ogra_ | from #ubuntu-ci-eng | 20:10 |
| ogra_ | seems to affect a lot of LP | 20:10 |
| rsalveti | yup, what I said a bit earlier | 20:10 |
| rsalveti | all broken | 20:10 |
| rsalveti | :-) | 20:10 |
| ogra_ | rsalveti, hmm, so that also means we dont know yet if the fix works ? | 20:23 |
| rsalveti | ogra_: nops | 20:23 |
| ogra_ | damn | 20:24 |
| rsalveti | let me see if system-image imported the amd64 build at least | 20:24 |
| ogra_ | cdimage seems to have it at least | 20:25 |
| ogra_ | yup, system-image seems to have updated amd64 | 20:26 |
| ogra_ | has a timestamp that matches the cdimage build | 20:26 |
| ogra_ | hmm, but no package changes | 20:27 |
| ogra_ | oh | 20:27 |
| ogra_ | heh | 20:27 |
| ogra_ | ogra@anubis:~/datengrab/images$ ./compare-snappy-manifests.sh 20150709 20150710 | 20:28 |
| ogra_ | Package changes between 20150709 and 20150710 | 20:28 |
| ogra_ | === Upgraded Packages === | 20:28 |
| ogra_ | initramfs-tools-ubuntu-core from 0.7.7~ppa2 to 0.7.7~ppa3 | 20:28 |
| ogra_ | there we go ... | 20:28 |
| ogra_ | my script only checked armhf | 20:28 |
| * ogra_ twiddles thumbs waiting for udf | 20:31 | |
| rsalveti | yeah, let me give it a try | 20:37 |
| rsalveti | worked fine the first time, let me try a few more | 20:38 |
| * ogra_ is at the second time | 20:39 | |
| ogra_ | yup | 20:40 |
| ogra_ | no matter if i close the window or ctrl-c ... seems fine | 20:40 |
| ogra_ | 5 times no corruption ... | 20:41 |
| * ogra_ builds a new image and does another 10 | 20:41 | |
| ogra_ | bah, i wish it could cahe webdm | 20:41 |
| ogra_ | *cache | 20:41 |
| rsalveti | ogra_: yeah, seems fine here | 20:45 |
| ogra_ | yup, 10 10x killed and stable | 20:46 |
| ogra_ | -10 | 20:46 |
| ogra_ | :P | 20:46 |
| rsalveti | :-) | 20:47 |
| rsalveti | now to wait the armhf image | 20:47 |
| ogra_ | well, the build seems done | 20:48 |
| rsalveti | waiting https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.27-0ubuntu1 to be promoted as well | 20:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!