| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| biezpal | good morning all | 04:49 |
|---|---|---|
| biezpal | Seems like we have faced another "random-version-string" problem, similar to https://bugs.launchpad.net/bugs/1498396 | 05:00 |
| ubottu | Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,Fix committed] | 05:00 |
| biezpal | We have service in snap package with apparmor profile defined like: | 05:00 |
| biezpal | profile "app_ovs-init-db_0.0.1" { | 05:00 |
| biezpal | capability, | 05:00 |
| biezpal | ... | 05:00 |
| biezpal | In systemd this service exist with name "app_ovs-init-db_IDDSYPEfafNM.service" and seems like apparmor cannot change profile properly because of different names. When we trying to start service through ubuntu-core-launcher we see error: | 05:00 |
| biezpal | aa_change_onexec failed with -1 | 05:00 |
| biezpal | . errmsg: No such file or directory | 05:00 |
| biezpal | If we change service name in apparmor profile and start service again - everything works fine. | 05:00 |
| biezpal | How can we configure apparmor profile to work with random named services? | 05:00 |
| jjohansen | biezpal: ? | 05:01 |
| jjohansen | biezpal: within a profile you can specify the name to transition to | 05:02 |
| jjohansen | /foo px -> bar, | 05:02 |
| jjohansen | or you could use the the change_profile api | 05:02 |
| jjohansen | from a shell you can do | 05:03 |
| jjohansen | aa-exec -p profile_name -- your shell command | 05:03 |
| jjohansen | and that will run your shell command with the specified profile_name | 05:04 |
| jjohansen | aa-exec is just a wrapper around the change_profile api | 05:04 |
| biezpal | jjohansen, but we need valid apparmor profile before snap package installed | 05:04 |
| biezpal | we have a list of service that should run automatically after package installed and we cannot change all profiles manually from shell | 05:06 |
| jjohansen | biezpal: so what kind of changes do you need to the profile? Just changing the name, or do you need to change the profile contents? | 05:07 |
| jjohansen | sorry, I am reading the bug now | 05:08 |
| biezpal | apparmor profile that we have in snap package becomes invalid after install because of randow version in service name | 05:08 |
| jjohansen | biezpal: do you need the random version in the profile name? | 05:09 |
| biezpal | for example, profile defined for service_0.0.1 but system looking for service_IDDSYPEfafNM | 05:10 |
| biezpal | jjohansen, we don't need random version in profile :) | 05:11 |
| biezpal | cause we cannot define them in advance, before installation | 05:11 |
| jjohansen | right | 05:11 |
| biezpal | and because of it our services cannot start | 05:12 |
| jjohansen | so, I am not sure what the best way to proceed from here, jdstrand will know the snap integration part much better | 05:13 |
| jjohansen | biezpal: unfortunately jdstrand won't come online for about 8 hours | 05:14 |
| biezpal | jjohansen, yes, we know :) | 05:14 |
| biezpal | thanks anyway | 05:14 |
| jjohansen | biezpal: my initial reaction is don't do that :) | 05:15 |
| jjohansen | it is possible to make the change_profile rule match multiple versions | 05:15 |
| jjohansen | and I am guessing that will be the route to go, but I'd run it past jdstrand first | 05:16 |
| biezpal | ok, waiting for jdstrand | 05:17 |
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:36 |
| mvo | hey dholbach, good morning | 06:40 |
| dholbach | hi mvo | 06:41 |
| mvo | ogra_: hi, fwiw, I triggered a new build for vivid from proposed that contains some rest api fixes (just in case you wonder why a new build is happening right now) | 06:59 |
| fgimenez | good morning | 07:02 |
| Chipaca | mo'in | 07:53 |
| Chipaca | something weird is up with wily | 07:53 |
| Chipaca | getting stuck in emerg mode | 07:53 |
| Chipaca | mvo: o/ | 07:58 |
| mvo | hey Chipaca | 08:00 |
| Chipaca | mvo: how's things? | 08:00 |
| Chipaca | mvo: did you know wily edge 199 -> 201 lands you in emergency mode right now? | 08:02 |
| Chipaca | mvo: (just in case you thought things were ok :-p) | 08:02 |
| mvo | Chipaca: uff | 08:04 |
| mvo | Chipaca: ok, thats alarming as it most likely affects stable in some way too | 08:04 |
| longsleep | good morning snappy | 08:04 |
| Chipaca | indeed, I am moderately alarmed by this | 08:04 |
| Chipaca | Chipaca code Mauve | 08:05 |
| * Chipaca steals python *and* perl from under longsleep's feet | 08:05 | |
| Chipaca | longsleep: morning :) | 08:05 |
| longsleep | hehe i switched from Perl to Python in 2001 | 08:08 |
| longsleep | so have fun with the Perl but let me keep Python :P | 08:08 |
| longsleep | but aside from scripting languages, what is the best practice to create an snappy image with many snaps pre installed where some of the snaps are not in the store? I have to start with some build system for this soon - any suggestions? | 08:11 |
| fgimenez | hi mvo | 08:25 |
| mvo | hey fgimenez | 08:26 |
| fgimenez | i'm trying 15.04/edge r212 on kvm and it doesn't have eth0 up when started | 08:27 |
| fgimenez | mvo, is that a known issue? ^ | 08:27 |
| mvo | fgimenez: not a know issue :( | 08:28 |
| fgimenez | mvo, i'll try to check again and ping you back, even more after sudo ifconfig eth0 up it only has a ipv6 address | 08:30 |
| Chipaca | fgimenez: not any eth0, or not ipv4? | 08:30 |
| Chipaca | ah | 08:30 |
| fgimenez | Chipaca, only lo | 08:30 |
| Chipaca | fgimenez: "ifconfig eth0 up", or ifup eth0? | 08:30 |
| Chipaca | fgimenez: what do you have in /etc/network/interfaces.d? | 08:31 |
| fgimenez | Chipaca, eth0 with: "allow-hotpug eth0\niface eth0 inet dhcp" | 08:32 |
| Chipaca | fgimenez: and "sudo journalctl -x"? | 08:33 |
| Chipaca | fgimenez: anything red in that? :) | 08:33 |
| mvo | fgimenez: so it might be the new kernel http://people.canonical.com/~ogra/core-image-stats/vivid/20151013.1.changes | 08:36 |
| fgimenez | Chipaca, :) a few about ACPI, EXT4-fs and pkcsslotd, I also get http://paste.ubuntu.com/12771951/ | 08:38 |
| mvo | Chipaca: hm, I just upgraded rolling and no panic, let me try to reproduce again with the exact versions | 08:42 |
| ogra_ | fgimenez, there is actually a \n in the eth0 file ? | 09:02 |
| fgimenez | ogra_, no, just for displaying it here :) | 09:06 |
| ogra_ | ah, k | 09:06 |
| Chipaca | ogra_: excellent question :) | 09:07 |
| ogra_ | hah, look ... my test server just started spilling autopilot reboot messages to the console ... it is on 211 ... lets see if it comes up | 09:08 |
| fgimenez | ogra_, latest stable was 185 on edge, right? | 09:15 |
| ogra_ | fgimenez, yup | 09:16 |
| Chipaca | gah! map is not a function, it's a keyword :-( | 09:18 |
| fgimenez | ogra_, ok thx, i'll try upgrade and rollback from there | 09:18 |
| * ogra_ waits for ogra2 to return ... | 09:18 | |
| ogra_ | there he is | 09:18 |
| ogra_ | so looks like my installed/auto-upgraded server comes up fine with 212 | 09:19 |
| ogra_ | yep, all up | 09:19 |
| JamesTait | Good morning all; happy Tuesday, and happy Ada Lovelace Day! 😃 | 09:19 |
| mvo | Chipaca: so r199->201 is a 40mb delta update and I strongly suspect it contains a new kernel *but* for me it did not panic :( | 10:04 |
| mvo | Chipaca: no new kernel, sorry | 10:04 |
| mvo | Chipaca: do you have some more details about the recovery mode you ended up in? | 10:05 |
| Chipaca | mvo: it looks recoverish? | 10:05 |
| Chipaca | mvo: dunno what details there are to be had :) | 10:05 |
| Chipaca | it's a kvm in snapshot mode, so i can drop back to the old thing and redo the update any time | 10:06 |
| Chipaca | (and have, multiple times, and it ends up in emerg mode every time) | 10:06 |
| Chipaca | ah, this might be relevant | 10:06 |
| Chipaca | failed to exec /bin/plymouth | 10:07 |
| mvo | Chipaca: I thnk the pylmouth is a red-herring | 10:07 |
| Chipaca | ok :) | 10:07 |
| mvo | Chipaca: does it tell you why its in recovery mode? or is it because of plymouth and its not a red-herring at all :) ? | 10:07 |
| Chipaca | ah, charset not found | 10:07 |
| mvo | Chipaca: ha! | 10:07 |
| Chipaca | failed to mount /boot/efi | 10:07 |
| mvo | Chipaca: so that indicates that the kernel has changed but no modules | 10:07 |
| Chipaca | because charset not found | 10:07 |
| mvo | Chipaca: so a new kernel but no modules, or rather, the filesystem has a new kernel abi and the old kernel is booted which then can not load the nls8859-1 module | 10:08 |
| ogra_ | someone dropped vfat stuff ? | 10:08 |
| ogra_ | it shouldnt be a module anymore | 10:08 |
| * ogra_ asked for that ages ago | 10:08 | |
| mvo | Chipaca: can you inspect the filesystem? | 10:08 |
| Chipaca | mvo: sure, what do i look for? | 10:09 |
| mvo | Chipaca: i.e. md5sums of /boot/grub/{a,b}/* | 10:09 |
| Chipaca | let me see if i can bring up ssh | 10:09 |
| mvo | Chipaca: and "ls /lib/modules/ /writable/cache/system/" | 10:09 |
| mvo | Chipaca: I actually suspect just 199->201 is not enough, something like ?->199->201, i.e. old-kernel->new->new maybe? | 10:10 |
| ogra_ | (amd64)ogra@aleph2:~$ lsmod |grep vfat | 10:10 |
| ogra_ | (amd64)ogra@aleph2:~$ cat /proc/filesystems |grep fat | 10:10 |
| ogra_ | vfat | 10:10 |
| Chipaca | trying to bring up ssh froze stuff (?) | 10:10 |
| Chipaca | ogra_: what about nls | 10:10 |
| Chipaca | ogra_: problem isn't vfat | 10:10 |
| ogra_ | nls8859-1 really needs to be compiled in, givcen that vaft is too | 10:10 |
| mvo | yeah, its nls8859 | 10:10 |
| ogra_ | i'm not doubting that :) | 10:11 |
| mvo | :) | 10:11 |
| ogra_ | but vfat is useless without nls8859, so it needs to be compiled in too | 10:11 |
| mvo | all good, well, there is a bug in our code somewhere I think | 10:11 |
| * mvo nods | 10:12 | |
| Chipaca | where was the kernel config stored? | 10:12 |
| ogra_ | (though it helps finding module issues :P ) | 10:12 |
| ogra_ | Chipaca, in boot (if you are lucky and the kernel is the same as in the device tarball( | 10:12 |
| Chipaca | mvo: before the reboot: http://pastebin.ubuntu.com/12772258/ | 10:12 |
| Chipaca | ogra_: where in boot? | 10:13 |
| mvo | Chipaca: what does the module dirs look like? | 10:14 |
| ogra_ | Chipaca, in /boot | 10:14 |
| Chipaca | $ ls /lib/modules/ | 10:14 |
| Chipaca | 4.2.0-16-generic | 10:14 |
| Chipaca | $ ls /boot/ | 10:14 |
| ogra_ | oh ! | 10:14 |
| Chipaca | efi grub | 10:14 |
| ogra_ | (amd64)ogra@aleph2:~$ ls /boot/ | 10:14 |
| ogra_ | System.map-3.19.0-31-generic efi initrd.img-3.19.0-31-generic vmlinuz-3.19.0-31-generic.efi.signed | 10:14 |
| ogra_ | abi-3.19.0-31-generic grub vmlinuz-3.19.0-31-generic | 10:14 |
| mvo | Chipaca: and the other one? /writable/cache ? | 10:14 |
| ogra_ | no config anymore ? | 10:14 |
| mvo | Chipaca: and the other one? /writable/cache/system/lib/modules ? | 10:14 |
| Chipaca | $ ls /writable/cache/system/lib/modules/ | 10:14 |
| Chipaca | 4.2.0-14-generic | 10:14 |
| mvo | Chipaca: so that is before the reboot? | 10:15 |
| Chipaca | yes | 10:15 |
| mvo | Chipaca: what is the content /writable/cache/system/etc/system-image/channel.ini? | 10:16 |
| mvo | Chipaca: and /etc/system-image/channel.ini ? | 10:16 |
| mvo | Chipaca: so I'm super confused, /lib/modules is different on a/b but the kernel is the same but also the "other" parition has a lower version for the kernel modules than your current partition | 10:17 |
| Chipaca | mvo: http://pastebin.ubuntu.com/12772276/ | 10:17 |
| mvo | Chipaca: thats puzzling | 10:17 |
| mvo | Chipaca: thanks, so other looks correct and yet it has the modules for 4.2.0-14-generic ? | 10:18 |
| mvo | Chipaca: it explains the failure, but how the systemd ended up in that state is the interessting part now :) | 10:19 |
| mvo | Chipaca: does it make sense so far? what I'm saying? | 10:19 |
| Chipaca | mvo: new system has .16 kernel and .14 modules --> how can it i don't even | 10:20 |
| Chipaca | mvo: makes sense to me | 10:20 |
| mvo | Chipaca: yeah, it does not make any sense, do you still have content in /writable/cache ? i.e. the delta update? | 10:21 |
| mvo | Chipaca: the delta update files? | 10:21 |
| mvo | Chipaca: so one theory might be that the delta update used the wrong base, e.g. "other" was "185" but the delta update used soemthing later that did no include the kernel change in the filesystem which is still a weak theory because the kernel itself was part of the delta | 10:22 |
| Chipaca | mvo: where in /writable/cache should i have content? | 10:24 |
| Chipaca | i mean, there's /writable/cache/system :) | 10:24 |
| Chipaca | let me start over, and see what system-image-cli has to say for itself | 10:25 |
| Chipaca | $ sudo system-image-cli -n | 10:26 |
| Chipaca | Upgrade path is 200:201 | 10:26 |
| mvo | Chipaca: yeah, thanks. if you still have the state of before the upgrade, thats awsome, what revno was "other" before? | 10:26 |
| Chipaca | yes, i do still have the before-upgrade; always do kvm -snapshot here | 10:26 |
| mvo | Chipaca: we dtive system-image by pointing it to the "other" parition so that we get the delta download relative to this "other" | 10:26 |
| Chipaca | because i can commit a snapshot, but can't uncommit a non-snapshot :) | 10:27 |
| mvo | :) | 10:27 |
| Chipaca | version_detail: ubuntu=20151008,raw-device=20151008,version=197 | 10:27 |
| Chipaca | that's /writable/cache/system/etc/system-image/channel.ini before the upgrade | 10:27 |
| Chipaca | (i mean, it has all the other stuff, but that's got the info you want) | 10:28 |
| mvo | Chipaca: could you run system-image-cli -C /writable/cache/system/etc/system-image -n | 10:30 |
| mvo | Chipaca: thats what snappy will do? | 10:30 |
| mvo | Chipaca: well, it will not use "-n" | 10:30 |
| Chipaca | I can, but you might not like it | 10:31 |
| mvo | Chipaca: this smells like a but in s-i or a bug in the way we drive it | 10:31 |
| Chipaca | $ sudo system-image-cli -C /writable/cache/system/etc/system-image -n | 10:31 |
| Chipaca | Already up-to-date | 10:31 |
| mvo | Chipaca: oh? well, that would explain the issue, but … but? | 10:31 |
| mvo | why does it think its up-to-date? | 10:31 |
| Chipaca | mvo: wait, we get to blame barry for this? | 10:31 |
| Chipaca | that's always a win! | 10:32 |
| mvo | Chipaca: do you have --debug or something in s-i? | 10:32 |
| mvo | Chipaca: well, we better have hard data to backup this claim ;) | 10:32 |
| Chipaca | http://pastebin.ubuntu.com/12772321/ | 10:32 |
| mvo | Chipaca: hm, I hope this getprop failure is not the issue :( | 10:36 |
| mvo | Chipaca: what does "sudo system-image-cli -n -v" yield? | 10:36 |
| Chipaca | i'm assuming that's part of the "check you're on an ubuntu phone" code :) | 10:36 |
| mvo | Chipaca: ups, coud you set the -C dir to "/writable/cache/system/etc/system-image/config.d" instead? | 10:37 |
| mvo | Chipaca: sorry, I think I pasted you the wrong dir | 10:37 |
| Chipaca | http://pastebin.ubuntu.com/12772343/ | 10:37 |
| mvo | ta | 10:37 |
| Chipaca | http://pastebin.ubuntu.com/12772348/ | 10:38 |
| Chipaca | “Upgrade path is 201” | 10:38 |
| mvo | Chipaca: I wonder what that means, if it means a full download, we are good, if it means just the 200:201 delta not so much | 10:39 |
| Chipaca | i think a delta is written m:n | 10:40 |
| mvo | Chipaca: if you run it with "--no-apply" instead of "-n", what does it download? | 10:40 |
| Chipaca | as in the 200:201 you get without -C | 10:40 |
| mvo | the download will end up in /writable/cache | 10:40 |
| Chipaca | http://system-image.ubuntu.com/ubuntu-core/rolling/edge/generic_amd64/version-201.tar.xz.asc -> /writable/cache/version-201.tar.xz.asc | 10:40 |
| mvo | i.e. sudo system-image-cli -C /writable/cache/system/etc/system-image/config.d/ -g -v | 10:40 |
| === lifeeth_ is now known as lifeeth | ||
| Chipaca | tadaa | 10:42 |
| Chipaca | http://pastebin.ubuntu.com/12772377/ | 10:43 |
| Chipaca | includes: device-2bc2ee8db5cd33e143438171da503c2ce56eeb49adc0617872b9a099d18c2288.tar.xz | 10:43 |
| Chipaca | and that file has lib/modules/4.2.0-16-generic | 10:43 |
| Chipaca | and vmlinuz 4.2.0.16 | 10:44 |
| Chipaca | wait, that shouldn't be a problem :) | 10:44 |
| mvo | Chipaca: ok, so the next suspect is the upgrader then that applies the upgrade | 10:44 |
| Chipaca | mvo: is that also system-image? | 10:45 |
| mvo | Chipaca: "sudo ubuntu-core-upgrade --dry-run --leave-files" maybe? | 10:45 |
| mvo | Chipaca: "sudo ubuntu-core-upgrade --dry-run --leave-files --debug" maybe? | 10:45 |
| Chipaca | Failed to read command file: None | 10:46 |
| mvo | Chipaca: is there a ubuntu_command file in /writable/cache ? | 10:46 |
| Chipaca | mvo: i could send you the kvm image, fwiw :) | 10:46 |
| mvo | Chipaca: that might be easier indeed | 10:46 |
| Chipaca | http://pastebin.ubuntu.com/12772390/ | 10:46 |
| mvo | Chipaca: less learning expereince for you :P | 10:47 |
| Chipaca | indeed | 10:47 |
| Chipaca | which is why i'm not stopping you :) | 10:47 |
| mvo | Chipaca: I'm kidding, I will be so happy when this part gets replaced | 10:47 |
| longsleep | Does it make sense to test for future breakage anything other than 15.04/edge (which works fine). Should i test rolling/edge from time to time? | 10:47 |
| mvo | Chipaca: but maybe you will appreciate it more this way when we replace it | 10:47 |
| mvo | Chipaca: "sudo ubuntu-core-upgrade --dry-run --leave-files --debug /writable/cache/ubuntu_command" | 10:49 |
| mvo | Chipaca: sorry for my mistaken cmdline earlier | 10:50 |
| mvo | Chipaca: and feel free to upload your image to people.c.c or something and I can poke it harder | 10:50 |
| mvo | Chipaca: this command should give us some hints | 10:50 |
| Chipaca | ubuntu-core-upgrade: error: argument --debug: invalid int value: '/writable/cache/ubuntu_command' | 10:50 |
| Chipaca | :) | 10:51 |
| * Chipaca goes with 9 | 10:52 | |
| Chipaca | whoa, that was verbose. doing over. | 10:52 |
| mvo | Chipaca: I get some lunch but will read scrollback | 10:54 |
| Chipaca | mvo: stderr: http://pastebin.ubuntu.com/12772425/ | 10:56 |
| Chipaca | mvo: stdout looks like a tar listing, can upload if needed | 10:56 |
| mvo | Chipaca: hm, if you run that without --dry-run, does it unpack the right lib/modules? I suspect it will and this means something is missing here :( | 10:58 |
| mvo | Chipaca: i.e. somewhere what we did is not what snappy did | 10:59 |
| * mvo really lunches first | 10:59 | |
| === chihchun is now known as chihchun_afk | ||
| olli | gm | 11:01 |
| Chipaca | mvo: indeed, that worked perfectly | 11:01 |
| Chipaca | doing over with strace | 11:02 |
| mvo | Chipaca: yeah, lets figure out what it execve()s :/ | 11:03 |
| sergiusens | morning | 11:03 |
| Chipaca | olli: sergiusens: mo'in | 11:03 |
| * sergiusens has a nasty cold since yesterday | 11:04 | |
| Chipaca | so does the uk | 11:04 |
| Chipaca | they're calling it "autumn" | 11:04 |
| sergiusens | Chipaca, it snowed in the Altas Cumbres yesterday! | 11:04 |
| sergiusens | we are enjoying spring ;-) | 11:04 |
| Chipaca | wow, slightly late this year | 11:05 |
| Chipaca | usually it's september it snows :) | 11:05 |
| Chipaca | whaaaa | 11:06 |
| Chipaca | ok, lots of trace files :) | 11:06 |
| Chipaca | hah, well, that's something that went wrong | 11:07 |
| Chipaca | /tmp/trace.1080:execve("/usr/bin/system-image-cli", ["system-image-cli", "--progress", "json", "-C", "/etc/system-image/config.d"], [/* 23 vars */]) = 0 | 11:08 |
| Chipaca | and that happens if it can't read the one in /writable/cache | 11:09 |
| Chipaca | $ ls -l /writable/cache/system/etc/system-image/config.d/00_default.ini | 11:09 |
| Chipaca | lrwxrwxrwx 1 root root 13 Oct 13 11:04 /writable/cache/system/etc/system-image/config.d/00_default.ini -> ../client.ini | 11:09 |
| Chipaca | puzzled, now | 11:10 |
| ogra_ | why ? | 11:12 |
| ogra_ | the old s-i-cli used /etc/system-image/client.ini by default, the new one uses the files under /etc/system-image/config.d/ | 11:13 |
| Chipaca | i think this is related to a bug barry already fixed | 11:17 |
| Chipaca | with system-image not really requiring config to work | 11:17 |
| Chipaca | but we still treat it like it does | 11:17 |
| Chipaca | and system-image used to crash with a symlink, but he fixed taht | 11:17 |
| Chipaca | ogra_: in any case, it's doing the wrong update and getting into trouble | 11:18 |
| * olli waves at Chipaca | 11:18 | |
| Chipaca | i'm not sure when using the wrong config for system image is the right thing, but this isn't one of those times :) | 11:18 |
| ogra_ | well, whats inside that client.ini ? | 11:18 |
| ogra_ | it should point to the new image | 11:18 |
| Chipaca | it's not there ^ | 11:19 |
| Chipaca | broken symlink | 11:19 |
| ogra_ | ah ! | 11:19 |
| ogra_ | it should be there | 11:19 |
| Chipaca | it refuses to bow to your imperialist views on existentialism | 11:20 |
| ogra_ | http://paste.ubuntu.com/12772505/ | 11:20 |
| Chipaca | i don't believe it's necessary any more | 11:20 |
| ogra_ | (note that archive_master lives elsewhere in rolling, the above is stable) | 11:21 |
| Chipaca | k | 11:21 |
| ogra_ | i thik it is still necessary | 11:21 |
| * Chipaca buys ogra_ a box of chocolates of the wrong ABI | 11:21 | |
| ogra_ | haha | 11:22 |
| mvo | Chipaca: ha! so 00_default.ini is a dangling symlink on wily. nice catch. its not on 15.04 fortunately there is a client.ini there but I think its there because I put it back | 11:55 |
| mvo | Chipaca: so the fix is to test for 01_channel.ini I guess (?) or 20_snappy.ini which is safer | 11:55 |
| mvo | Chipaca: nice work tracking this one down \o/ | 11:56 |
| Chipaca | what are we actually testing for? | 11:56 |
| mvo | Chipaca: that the other partition is "valid" (no-empty) | 11:56 |
| mvo | Chipaca: see systemimage.go:222 | 11:57 |
| * mvo needs to vanish again for some seconds | 11:57 | |
| Chipaca | mvo: if the question is "can system-image build an upgrade path from this", then maybe we should check with barry and update the check | 11:57 |
| Chipaca | mvo: there's an XXX just below where you ponted me at in systemimage.go that points at potential trouble; it doesn't say *why* it does two different checks :-/ | 12:09 |
| mvo | Chipaca: it otherIsEmpty() contains some info, no? | 12:09 |
| mvo | Chipaca: i.e. we need(ed) in the old days both client and channnel config, nowdays we don't need a client config but we still need a snappy specific config | 12:10 |
| Chipaca | ah, so it does, so it does | 12:10 |
| mvo | so checking for 20_snappy.ini seems prudent (unless I miss something) | 12:10 |
| longsleep | When testing snappy on bare metal, how many sdcards have you folks worn out already? These things drive me crazy eventually :/ | 12:36 |
| Chipaca | longsleep: hard drives are a consumable; sd cards more so | 12:44 |
| mvo | fgimenez: how big is /boot now with the alpha images and the signed kernels? | 12:44 |
| fgimenez | mvo, let me check | 12:44 |
| longsleep | Chipaca: yeah, i am just wondering if this happens to other people as well | 12:45 |
| longsleep | i mean, flash 100x, the odds that the card is borked seem to be big | 12:45 |
| Chipaca | longsleep: yes. Fortunately update is usually good enough you only rarely need a full reflash, and that helps | 12:46 |
| mvo | longsleep: how many cards did you loose already? and how often does it happen? | 12:46 |
| longsleep | mvo: this is now the third card out of 5 which stopped working since i started working with snappy in march | 12:46 |
| Chipaca | longsleep: how often do you reflash? | 12:47 |
| mvo | longsleep: all the same batch of cards? just curious if there are differences between manufactors etc | 12:47 |
| mvo | longsleep: seems like a lot indeed | 12:47 |
| longsleep | Chipaca: sure they will last longer for normal use case - though the general quality of the sdcards seem like shit, i mean these are all sandisk cards - the normal ones though. The exreme ones seem to be more durable. | 12:47 |
| longsleep | mvo: yes those who give i/o errors are from the same batch | 12:48 |
| Chipaca | longsleep: like these? http://martybugs.net/articles/images/sandisk_box_large.jpg | 12:48 |
| Chipaca | ah, those are cf | 12:49 |
| longsleep | Chipaca: around 100 times | 12:49 |
| Chipaca | http://ecx.images-amazon.com/images/I/61ezDfz50AL.jpg | 12:49 |
| longsleep | Chipaca: yes those | 12:49 |
| Chipaca | longsleep: check they aren't fake sandisks | 12:49 |
| longsleep | and i got a broken one from transcend as well | 12:49 |
| beuno | longsleep, FWIW, I trashed an SD card in a single night when I wrote a small app that took pictures when it detected movement, and it rained that night :) (it was pointing out the window) | 12:49 |
| longsleep | beuno: yeah - thats why i ask here, if this is a common thing others must have dead sdcards as well | 12:50 |
| longsleep | or do you all get the expensive ones? | 12:50 |
| fgimenez | mvo, 76M in bbb, 131M in amd64 | 12:50 |
| longsleep | Chipaca: hard to tell if its a fake | 12:50 |
| Chipaca | longsleep: yep, seems to vary a lot | 12:51 |
| longsleep | Chipaca: could be, but they worked fine half a year full capacity and all. So i find it unlikely | 12:51 |
| Chipaca | longsleep: ah, ok :) | 12:51 |
| Chipaca | longsleep: these days i mostly just get the expensive ones | 12:51 |
| Chipaca | longsleep: but if i were working with them in bulk i'd probably be ok wiht the cheaper ones | 12:52 |
| longsleep | Chipaca: right, thats why i am testing the cheap ones | 12:52 |
| longsleep | but the Transcend one which broke today is an expensive one, only 8GB though | 12:52 |
| longsleep | they give 30 years limited guarantee on that one | 12:53 |
| longsleep | haha they do not give that guarantee for write intensive applications | 12:55 |
| Chipaca | i'd be tempted to get it rma'd :) | 12:56 |
| longsleep | they explicitly list "servers" as write intensive or continuous use case in their warranty agreement | 12:56 |
| longsleep | so basically they know that the card can just fail when used in a server | 12:56 |
| longsleep | and that is for a card which is called "Premium" | 12:57 |
| === fginther` is now known as fginther | ||
| mvo | Chipaca: do we have a bug for the upgrade issue or should we have one? I want to ensure its tracked because I will likely forget about it because of release and all this other stuff that is going on | 13:02 |
| Chipaca | mvo: filing i tnow | 13:03 |
| Chipaca | mvo: do you know why it failed for me and not for you? | 13:03 |
| beuno | spite? | 13:03 |
| mvo | Chipaca: \o/ please add the relevant bits from irc so that we know how to fix it too :) | 13:03 |
| mvo | Chipaca: no idea yet, in a meeting right now so I can't check, will check tonight | 13:04 |
| Chipaca | beuno: +1 | 13:04 |
| Chipaca | mvo: bug 1505682 | 13:07 |
| ubottu | bug 1505682 in Snappy "upgrade wily/edge 199->201 failed" [Undecided,New] https://launchpad.net/bugs/1505682 | 13:07 |
| Chipaca | mvo: let me know if i should expand it any | 13:07 |
| mvo | Chipaca: looks good | 13:18 |
| Chipaca | and wily.img.xz made it up | 13:18 |
| sergiusens | elopio, can you look at https://code.launchpad.net/~sergiusens/snapcraft/1500902/+merge/273444 again? or are we good already? | 13:36 |
| elopio | sergiusens: we are good. | 13:41 |
| sergiusens | elopio, \o/ | 13:41 |
| elopio | I saw Chipaca's +1 but forgot to push mine. | 13:41 |
| barry | mvo: hi. what's up? | 13:45 |
| mvo | hey barry, we tracked down a issue in snappy to a broken /etc/system-image/config.d/00_default.ini symlink. this may be snappy specific I need to look further into it | 13:47 |
| === balloons is now known as Guest77290 | ||
| barry | mvo: cool. si 3.0.2 in wily at least no longer crashes on dangling symlinks, but i don't think we ever tracked down why the symlink is dangling | 13:49 |
| barry | (don't think it is on touch) | 13:49 |
| mvo | barry: ok, thanks! thats good to know | 13:49 |
| * mvo adds it to the bug | 13:50 | |
| barry | mvo: i'm around all day so ping me if needed | 13:50 |
| mvo | barry: thanks, busy with $stuff today :( but much appreciated that offer | 13:52 |
| barry | mvo: i hear ya :) | 13:52 |
| plars | ogra_: is pi2_0.15_all.snap still available somewhere? | 13:52 |
| ogra_ | sure | 13:52 |
| ogra_ | there is an achive folder in the download dir | 13:53 |
| plars | ogra_: got it, thanks! | 13:54 |
| elopio | Chipaca: are you getting a vet error on trunk? | 14:10 |
| Chipaca | elopio: negatory | 14:10 |
| Chipaca | well, i could get *actual* trunk | 14:10 |
| Chipaca | and see | 14:10 |
| Chipaca | give me a mo' | 14:10 |
| sergiusens | Chipaca, a month? | 14:11 |
| ogra_ | no, he typoed mvo | 14:11 |
| Chipaca | yes, tests are slow | 14:11 |
| elopio | Chipaca: http://pastebin.ubuntu.com/12773266/ | 14:11 |
| Chipaca | definitely not getting that | 14:12 |
| Chipaca | and would be disappointed with everything if i did | 14:12 |
| mvo | ogra_: heh | 14:12 |
| elopio | tarmac is not getting that either, so might be a wily thing. | 14:14 |
| Chipaca | i'm on wily | 14:15 |
| Chipaca | but haven't updated | 14:15 |
| Chipaca | on it now | 14:16 |
| Chipaca | elopio: i guess i can rewrite that test to use reflect instead of the lazier printf | 14:18 |
| elopio | Chipaca: that might be clearer, because I'm not sure what you are testing there. | 14:22 |
| Chipaca | elopio: pointer equality | 14:22 |
| Chipaca | elopio: i want to know they're the same *actual object* | 14:22 |
| Chipaca | elopio: but go won't let you compare functions, it protects you from thinking two functions that compare different give different values for the same inputs | 14:23 |
| Chipaca | or somehting, i don't know why it doesn't let you | 14:23 |
| elopio | Chipaca: got it. It might be nicer to actually excercise that d.router.NotFoundHandler instead of just checking the references. | 14:26 |
| elopio | but I'm not sure how hard it would be to write that test. | 14:26 |
| elopio | and I don't understand the vet error anyway. I'm upgrading here too. | 14:26 |
| Chipaca | elopio: updated, still not getting that | 14:27 |
| Chipaca | elopio: your vet probably comes from source | 14:27 |
| Guest42341 | omg what am i doing here??? | 14:31 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | ogra_: https://pastebin.canonical.com/141658/ <- know issue of rpi2 on rolling? | 14:46 |
| * ogra_ grumbles about 2fa | 14:46 | |
| Chipaca | ogra_: sorry, comes from somebody working on server side, always 2fa'd in :) | 14:47 |
| ogra_ | definitely not known, no | 14:47 |
| Chipaca | ogra_: anything verterok could try? | 14:47 |
| mvo | Chipaca: "failed to find user uid/gid" hu? no clickpkg or snappypkg user on this system? | 14:48 |
| ogra_ | works flawless here | 14:49 |
| Chipaca | um | 14:49 |
| verterok | Chipaca: o/ | 14:49 |
| Chipaca | verterok: you did install the tools ppa, didn't you? | 14:49 |
| ogra_ | (copy pasted the command) | 14:49 |
| Chipaca | mvo: i'd guess an old u-d-f | 14:49 |
| Chipaca | pre the switch | 14:49 |
| ogra_ | 0.31-0ubuntu1 | 14:49 |
| ogra_ | is what i use atm | 14:49 |
| Chipaca | verterok: ppa:snappy-dev/tools is what i mean | 14:50 |
| verterok | Chipaca: I have the ppa, checking the installed version | 14:50 |
| Chipaca | ah, ok | 14:50 |
| ogra_ | newer should work too | 14:50 |
| verterok | Chipaca: I have http://ppa.launchpad.net/snappy-dev/beta/ubuntu | 14:50 |
| * Chipaca also builds just in case | 14:50 | |
| Chipaca | verterok: ah! no, not that one | 14:50 |
| Chipaca | i thought we'd deleted that one already | 14:50 |
| verterok | Chipaca: ok, removing and adding the new one | 14:50 |
| Chipaca | that has 0.23 | 14:51 |
| verterok | yup | 14:51 |
| ogra_ | http://paste.ubuntu.com/12773485/ | 14:51 |
| Chipaca | tools has 0.31 | 14:51 |
| ogra_ | just for reference | 14:51 |
| ogra_ | sergiusens, can we tunr off that azure warning for RPi builds ? | 14:52 |
| Chipaca | ogra_: http://pastebin.ubuntu.com/12773489/ | 14:52 |
| ogra_ | wut ?!? | 14:52 |
| Chipaca | ogra_: $ sudo tail -n1 /etc/sudoers | 14:53 |
| Chipaca | Defaultsinsults | 14:53 |
| Chipaca | ogra_: just in case you thought sudo was all serious and only about security | 14:53 |
| ogra_ | hah | 14:53 |
| qengho | I'm accustomed to, and like, having only a debian/ directory in source control and giving that to some kind of System that creates deb packages in architectures I don't own. Am I right in thinking that, in snappy, there are about five things missing from that kind of workflow? | 14:57 |
| Chipaca | qengho: not sure what you mean, but I'd start with "no, you are not right" | 14:57 |
| Chipaca | qengho: for example, lp:~snappy-dev/snappy-hub/snappy-examples has a bunch of sources of snaps in source control | 15:00 |
| qengho | Thanks, Chipaca. I'll look. | 15:00 |
| qengho | Okay, so cross-compiling is normal and expected, in this new world. And fabricating the programs for a package involves knowing something of the package, in this world too; there is no debian/rules kind of standard interface. I wish those facts were in the docs on the web site. | 15:05 |
| sergiusens | qengho, you want a snapcraft.yaml which defines everything, launchpad will build snaps from that | 15:06 |
| sergiusens | qengho, it is not open to public building just yet though | 15:06 |
| qengho | Huh. | 15:06 |
| sergiusens | qengho, more context maybe? | 15:07 |
| sergiusens | or huh to your huh ;-) | 15:07 |
| ogra_ | huh huh | 15:07 |
| qengho | Okay, I've read most of the web site, and haven't heard of snapcraft yet. | 15:09 |
| sergiusens | qengho, https://developer.ubuntu.com/en/snappy/snapcraft/ | 15:11 |
| qengho | sergiusens: I think that deserves to be merged into guides, pretty early. | 15:14 |
| Facu | Hi all! Question... we're installing the standard image in a raspberry pi 2... all works ok, and we can see the raspi in 'webdm.local' | 15:14 |
| Facu | it's nice, it works | 15:14 |
| sergiusens | qengho, right, Thibaut is working on that with dholbach | 15:14 |
| Facu | however, we want to start a *second* one, how we can change that name so we don't get BOTH trying to use webdm.local? | 15:14 |
| Facu | thanks!! | 15:15 |
| sergiusens | Facu, with snappy config and changing the hostname I think/hope | 15:15 |
| verterok | Chipaca: FYI, now its working (building rolling) | 15:15 |
| qengho | Facu: this isn't a snappy answer, but: mdns should append numbers to avoid name collisions. webdm.local, webdm1.local, webdm2.local | 15:16 |
| Facu | sergiusens, that is using u-d-f, or after it? | 15:16 |
| Facu | qengho, and there you don't know which one is which one :) (it will depend on boot order, right?) | 15:17 |
| sergiusens | Facu, after, on a running image | 15:17 |
| sergiusens | qengho, right there is a plan | 15:17 |
| sergiusens | to be fair, webdm needs lots of catching up to do | 15:18 |
| Facu | sergiusens, but to do that, I'd need to ssh into the raspi, and for that I'd need the IP ;) | 15:18 |
| qengho | Facu: Something like that. Also, there's probably a hyphen before the number, now that I think about it. | 15:18 |
| sergiusens | Facu, it might just be easier to connect your rpi2 to your network socket in your laptop and setup nm to share the connection | 15:18 |
| ogra_ | sergiusens, i dont think webdm picks up the hostname | 15:19 |
| ogra_ | it still uses webdm.local in any case | 15:20 |
| ogra_ | (unless something changed recently) | 15:20 |
| Chipaca | ogra_: it only uses webdm if hostname is localhost | 15:22 |
| Chipaca | you need to restart the service though | 15:22 |
| Chipaca | so | 15:22 |
| ogra_ | oh, i didnt know that ! | 15:22 |
| Chipaca | echo "config: {ubuntu-core: {hostname: potato}}" | sudo snappy config ubuntu-core - | grep hostname | 15:22 |
| Chipaca | sudo snappy service restart | 15:22 |
| Chipaca | Facu: ^ those two should get you sorted | 15:22 |
| ogra_ | creeezie ... it works ! | 15:23 |
| sergiusens | ogra_, imagine that ;-) | 15:23 |
| sergiusens | ogra_, it was done for MWC fwiw | 15:23 |
| ogra_ | ah | 15:23 |
| Facu | Chipaca, do you know if I can choose a different hostname at the u-d-f step? | 15:23 |
| ogra_ | not at the u-d-f step | 15:24 |
| Chipaca | Facu: not unless you want to write your own oem snap | 15:24 |
| ogra_ | you can pre-define settings inside the oem snap (but that would mean you need to use your own and are bound to always use --developer-mode ) | 15:24 |
| Chipaca | ogra_: jinx, i guess | 15:24 |
| Facu | we're using developer mode already | 15:25 |
| Facu | ok | 15:25 |
| ogra_ | :) | 15:25 |
| Facu | Chipaca, ogra_, sergiusens, qengho, thanks!! | 15:25 |
| elopio | fgimenez: so, what are we testing? 15.04 alpha? | 15:29 |
| fgimenez | elopio, yep, 14 for amd64 and 13 for armhf are the candidates | 15:30 |
| elopio | fgimenez: ok. And we are only missing some exploratory to see if we catch the ip issue again? | 15:30 |
| fgimenez | elopio, yes, the suite is passing on both (with eventual failures of the rollback test, but that's a test problem), i've tried -rollback and -update on amd64 too | 15:31 |
| fgimenez | elopio, also 13->14->13->14... oon amd64, i'm currently doing the same for bbb | 15:32 |
| elopio | fgimenez: awesome. | 15:32 |
| fgimenez | elopio, there's also this branch https://code.launchpad.net/~fgimenez/snappy/fix-activate-test, activate is not present in the rc images | 15:33 |
| fgimenez | elopio, and setupsuite does funny things on reboot :) | 15:33 |
| elopio | fgimenez: yeah, the setup has become scary | 15:34 |
| verterok | Chipaca, ogra_: hey, it's working now, old tools was the reason of my error. | 15:49 |
| verterok | Chipaca, ogra_: We are now seeing that the dhcp client is not starting on boot (no IP assigned to the device)...in case it's relevant let me know if you need more info about it | 15:50 |
| ogra_ | verterok, weird, works here | 15:51 |
| Chipaca | verterok: more info plz :) | 15:51 |
| ogra_ | do you use snapy config to modify the eth0 settings somehow ? | 15:51 |
| verterok | ogra_: no, we are sideloading a test snap. no other changes besides that | 15:51 |
| verterok | Chipaca, ogra_: looking at syslog | 15:52 |
| ogra_ | oh, wait, you are using rolling | 15:52 |
| ogra_ | that can indeed have unexpected breakage | 15:52 |
| elopio | fgimenez: oh, sorry, we were in the middle of something in the meeting. | 15:52 |
| verterok | ogra_: yes, we are on rolling | 15:52 |
| ogra_ | (at any time) | 15:52 |
| elopio | fgimenez: ah, ovmf, this is the card: https://trello.com/c/I1BSZ6iV/130-run-tests-for-snappy-personal-and-uefi-boot | 15:53 |
| fgimenez | elopio, my connection was ugly, we can join again | 15:53 |
| verterok | yup, we know :) | 15:53 |
| elopio | fgimenez: no, don't worry. That was the last thing I wanted to mention. | 15:53 |
| elopio | we need to give it a try. | 15:54 |
| elopio | sergiusens: did you uplad the example snap? | 15:54 |
| elopio | *upload | 15:54 |
| fgimenez | elopio, ok thanks, there's the link you mentioned | 15:54 |
| sergiusens | elopio, oh sorry, no; which one was it? | 15:55 |
| elopio | sergiusens: bash config. | 15:55 |
| sergiusens | elopio, hah, you didn't update the version ;- | 15:57 |
| sergiusens | ;-) | 15:57 |
| elopio | sergiusens: I haven't made any changes to it. | 15:57 |
| sergiusens | elopio, ah, so it is a new package? | 15:57 |
| elopio | sergiusens: yes, it's not in the store. | 15:57 |
| sergiusens | elopio, uploaded | 15:58 |
| === chihchun is now known as chihchun_afk | ||
| fgimenez | nice evening everyone o/ | 16:09 |
| elopio | sergiusens: thanks! | 16:17 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === lborda is now known as lborda-sprint | ||
| tasdomas | hi | 19:27 |
| tasdomas | a quick question regarding hw-assign | 19:27 |
| tasdomas | let's say my snap specifies a service that requires access to a device (a pi-glow in this instance) | 19:28 |
| tasdomas | when I install it, the service does not have access | 19:28 |
| tasdomas | but even after performing hw-assign, it seems I need to restart the service for the settings to take effect | 19:28 |
| tasdomas | is there a nicer way of doing this? | 19:29 |
| ogra_ | tasdomas, sadly not, there is a bug open that services should be auto-restarted though | 20:05 |
| jdstrand | beuno: hey, this isn't urgent-- at the next store rollout can you pull in the latest review tools? | 21:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
