| === chihchun_afk is now known as chihchun | ||
| mvo | ogra_: I blame fw_setenv for the breakage and I think I can prove it: http://paste.ubuntu.com/11923858/ | 06:33 |
|---|---|---|
| mvo | ogra_: thats operating on the pristine uboot.env I got from you and that was generated with mkenvimage, no snappy involved at all and notice the corruption at the end of the file | 06:34 |
| mvo | ogra_: I think I have a plan, lets see if it works | 06:39 |
| fgimenez | good morning | 07:10 |
| dholbach | good morning | 07:10 |
| mvo | ogra_: I uploaded a fix to the ppa that should fix the corruption, its a bit ugly, I work on a nice version with proper tests etc now. its also very panic()y to ensure that any remaining issues are caught | 07:15 |
| mvo | ogra_: once the updated uboot-go is in, we need to rebuild snappy and make a new image and then fingers crossed :) | 07:15 |
| mvo | hey fgimenez and dholbach, good morning! | 07:17 |
| fgimenez | hi mvo dholbach and all :) | 07:19 |
| dholbach | hey hey :) | 07:22 |
| ogra_ | mvo, thanks ! | 08:02 |
| ogra_ | mvo, i still dont get how it broke between 125 and 126 though ... only the config was different there | 08:03 |
| ogra_ | (and 125 was to 100% reliable) | 08:04 |
| longsleep | reading through backlog you guys had some fun last night - anything i should test with 126? | 08:16 |
| ogra_ | longsleep, no, but the next build | 08:16 |
| longsleep | ogra_: ok - did you make any changes to the saveenv logic? | 08:17 |
| ogra_ | not yet, i'm cleaning that up now, but since it worked for both of us before it should technically be fine, this is more cosmetic to rip out the inconsistent quoting | 08:18 |
| longsleep | ogra_: i think i have alreayd put double quotes around everthing - are you doing that too? | 08:18 |
| ogra_ | yep | 08:18 |
| ogra_ | our current snappy_boot only has half of the vars and values quoted | 08:19 |
| ogra_ | (on the BBB that is) | 08:19 |
| longsleep | well, i only put double quotes around stuff used for comparison, for the rest i never use double quotes | 08:20 |
| longsleep | ok - i see what you mean i am inconsitent there too | 08:21 |
| * longsleep is fixing | 08:21 | |
| ogra_ | heh | 08:21 |
| ogra_ | as i said ... simply cosmetic | 08:21 |
| longsleep | by the way - what is the reason to have snappy_cmdline as seperate var ? | 08:22 |
| longsleep | i think its unclean to just add that value at the end of mmcroot and will probably remove the var | 08:22 |
| ogra_ | i'm also putting a saveenv behind every setenv here | 08:22 |
| longsleep | really | 08:23 |
| ogra_ | well, for the snappy_boot line ... not for everything :) | 08:24 |
| longsleep | i need to make it multi line to make sense of it | 08:24 |
| longsleep | yeah i figured that much :) | 08:24 |
| longsleep | ogra_: mine currently looks like this https://pad.struktur.de/p/snappy_boot | 08:26 |
| longsleep | ogra_: where do you put extra setenv? | 08:26 |
| longsleep | saveenv | 08:26 |
| ogra_ | http://paste.ubuntu.com/11924149/ | 08:27 |
| ogra_ | i cant open your url ... insufficient privs | 08:27 |
| longsleep | err | 08:27 |
| longsleep | maybe its blocked from outside | 08:27 |
| longsleep | let me check your diff | 08:27 |
| ogra_ | The requested URL /insufficient_privileges was not found on this server. | 08:27 |
| ogra_ | :D | 08:27 |
| ogra_ | thats like "the url "broken link" was not found" | 08:28 |
| longsleep | hehe | 08:28 |
| longsleep | i think the pad is not in outside DNS and you end up at some fallback server | 08:29 |
| * ogra_ notes he ends up at a fedora server .... thats all it says | 08:29 | |
| longsleep | so you saveenv whenever the snappy_ab is changed - not sure why this is required - i was under the impression that this is only for the current boot | 08:29 |
| ogra_ | well, it means you keep the condition if you powered off the board before the boot finished | 08:30 |
| longsleep | mhm, what is the difference between boot failure and powered off - shouldnt it roll back in that case? | 08:31 |
| ogra_ | yes | 08:31 |
| longsleep | ok i see your point - i was under the impression only snappy_mode was set to try on upgrade. But that would make no sense. | 08:33 |
| longsleep | well ok hold on | 08:33 |
| longsleep | it would make sense if the system upgrade would set snappy_ab to the upgraded partition value as well | 08:34 |
| ogra_ | it will roll back in both cases ... weather or not the var is set ... | 08:34 |
| longsleep | then you would not have to save that change from u-boot ? | 08:34 |
| ogra_ | either all the vars are stored and the next boot will switch back to the former partition .... or none of the vars is stored so they are reset and it boots normal ... | 08:35 |
| mvo | ogra_: I can build you a custom snappy if you want to test/explore with the fixed code until the full image is ready | 08:36 |
| ogra_ | but in the latter case the bootloader will never know that an upgrade boot was attempted ... in the former it will ... the result is the same | 08:36 |
| longsleep | the next boot will only switch to former partition if it failed to boot when the successfull boot does not reset snappy_mode and snapp_trial_boot | 08:36 |
| ogra_ | mvo, i can wait for the full image ... btw, did you make the snappy_trial_boot a boolean ? | 08:36 |
| ogra_ | longsleep, exactly | 08:36 |
| longsleep | so why do you saveenv the snappy_ab change in u-boot then? | 08:37 |
| mvo | ogra_: its still a unset, I can change that now (would like to change it in both grub and uboot then in wily) do you think its important? i.e. will uboot be unhappy if its not set at all? | 08:37 |
| * longsleep does not get it - lets get some coffee | 08:38 | |
| ogra_ | mvo, well, i'd like to exclude the possibility that it could get unhappy ... i have no proof, only gut feeling | 08:38 |
| ogra_ | longsleep, hmm, yeah, prehaps i have a brainfart here | 08:39 |
| longsleep | ogra_: lets use this https://etherpad.mozilla.org/sglergmwrt - i hope you can open that :) | 08:40 |
| longsleep | arg | 08:40 |
| longsleep | it did format it | 08:40 |
| ogra_ | lol | 08:40 |
| ogra_ | in a weird way | 08:40 |
| longsleep | that is just plain stupid | 08:40 |
| longsleep | paste it in, gets formatted | 08:40 |
| ogra_ | what is "run setup" ? | 08:41 |
| longsleep | thats setting up fdt based on variables | 08:42 |
| ogra_ | and how do you hand over the initrd, i dont see that in bootm | 08:42 |
| longsleep | https://public.pad.fsfe.org/p/snappy_boot | 08:42 |
| longsleep | copy paste fail - forgot the last line | 08:43 |
| ogra_ | ah ! | 08:43 |
| ogra_ | :) | 08:43 |
| longsleep | so | 08:43 |
| longsleep | i fail to see why the setenv snappy_ab parts need to be saved | 08:43 |
| ogra_ | looks good ... and i thihnk based on the above i'll leave out the saveenv | 08:44 |
| longsleep | and i would like to get rid of snappy_cmdline | 08:44 |
| longsleep | feels strage to just add it to mmvroot | 08:44 |
| ogra_ | well, it is good to have it separate for better readability ... | 08:45 |
| longsleep | just added the setup - so you get the whole picture | 08:45 |
| ogra_ | so that you can see the actual cmdline options in one go without having to pick them out of an already way to long snappy_boot line | 08:46 |
| longsleep | ogra_: so the only question is what does happen when the system gets updated. Someone sets snappy_mode to try - i get that much, the question is if snappy_ab is also changed or not | 08:46 |
| ogra_ | it is | 08:46 |
| ogra_ | snappy cvhanges it from userspace | 08:46 |
| ogra_ | it sets "ab" to the "other" partition and sets trial_boot to 1 | 08:47 |
| longsleep | ogra_: good, then it would be bad to saveenv snappy_ab from u-boot | 08:47 |
| longsleep | ogra_: i just changed snappy_cmdline to be added by mccargs to bootargs | 08:48 |
| longsleep | i think that is cleaner | 08:48 |
| * ogra_ needs to check how mmcargs looks on the BBB and RPi | 08:50 | |
| ogra_ | uh | 08:50 |
| longsleep | i think it just sets the bootargs. It is called by snappy to pull in mmcroot as this contains the snappy_ab variable | 08:51 |
| ogra_ | never noticed that before ... BBB sets rootfstype there | 08:51 |
| longsleep | yeah i saw that. I think that is redundant | 08:51 |
| ogra_ | no, thats dangerous | 08:51 |
| longsleep | mhm ok :) | 08:51 |
| ogra_ | mmcrootfstype=ext4 rootwait | 08:52 |
| ogra_ | not so clever if we switch to some other fs :) | 08:52 |
| longsleep | yeah | 08:54 |
| longsleep | ogra_: so in the pad i now have my complete mmcargs with snappy_cmdline put there, instead of in the setenv in snappy_boot | 08:55 |
| longsleep | feels cleaner | 08:55 |
| ogra_ | yes, i did the same here (anmd dropped mmcrootfstype) | 08:55 |
| longsleep | ok great - so what is the problem with build 126 / why did you add the saveenv's in the first place? | 08:58 |
| longsleep | ogra_: above you wrote the system sets ab to the other partition and trial_boot to 1. Is that really so? I think it should not touch trial_boot, but set snapp_mode to try instead? | 09:01 |
| JamesTait | Good morning all; happy Gorgeous Grandma Day! 😃 | 09:02 |
| ogra_ | longsleep, 126 corrupts the uboot.env file by adding a value without a var name to it | 09:03 |
| mvo | ogra_: I triggered a new armhf build for 15.04, fingers crossed | 09:03 |
| ogra_ | fw_setenv actually allows things like: "fw_setenv ' ' 1" | 09:03 |
| ogra_ | mvo, \o/ | 09:03 |
| longsleep | oh | 09:04 |
| longsleep | any news about using uboot-go instead? | 09:04 |
| ogra_ | longsleep, it is go ... | 09:08 |
| ogra_ | (meaning it is a static binary of 2MB size) | 09:09 |
| longsleep | ogra_: thats great then | 09:25 |
| longsleep | ogra_: btw - i wanted to ask you how to handle upgrades from snappy-system.txt to uboot.env. When an new image is released and gets updated to uboot.env | 09:41 |
| ogra_ | i'm not sure we do that | 09:41 |
| ogra_ | (we do use the old files if they exist, so it only affects new installs) | 09:41 |
| longsleep | mhm | 09:42 |
| longsleep | ok | 09:42 |
| longsleep | so version 4 will contain the new and old behavior then? | 09:42 |
| === howefield_afk is now known as howefield | ||
| mvo | ogra_: looks like the new armhf 15.04 is available | 09:48 |
| * mvo downloads | 09:48 | |
| longsleep | mvo: version 128 sounds good? | 09:51 |
| * ogra_ downloads too | 09:51 | |
| longsleep | mvo, ogra_ : all right i am booted into 128 - let me know if you want me to do any specific tests | 10:01 |
| longsleep | Mhm - fw_printenv Read error on /boot/uboot/uboot.env: Success | 10:02 |
| dholbach | davidcalle, I added an item to the trello card about generalising the markdown importer so we can import docs from lp:snapcraft too - I'll look into that now | 10:09 |
| longsleep | mvo: well, fw_printenv cannot read or set anything in the .env file, while uboot-go works just fine | 10:09 |
| mvo | longsleep: hm, hm, let me investigate | 10:10 |
| longsleep | mvo: i see the scary config in /etc/fw_env.config | 10:11 |
| longsleep | mvo: i also just updated uboot-go to latest git and it still works | 10:11 |
| longsleep | (ODROIDC)root@odroid:~# fw_setenv foo bar | 10:12 |
| longsleep | Read error on /boot/uboot/uboot.env: Success | 10:12 |
| longsleep | Error: environment not initialized | 10:12 |
| longsleep | (ODROIDC)root@odroid:~# fw_printenv | 10:12 |
| longsleep | Read error on /boot/uboot/uboot.env: Success | 10:12 |
| mvo | longsleep: so 113/rolling works with fw_setenv/fw_printenv, I create a 15.04 one now | 10:17 |
| longsleep | mvo: did you fix the issue with the OEM snap in rolling? (bug #1477224) | 10:20 |
| nothal | Bug #1477224: OEM snap does not install when building image for rolling <Snappy:New> <http://launchpad.net/bugs/1477224> | 10:20 |
| ubottu | bug 1477224 in Snappy "OEM snap does not install when building image for rolling" [Undecided,New] https://launchpad.net/bugs/1477224 | 10:20 |
| mvo | longsleep: no, I think its a race actually, after ~5 tries it worked for me | 10:20 |
| longsleep | ok let me try that | 10:20 |
| ogra_ | mvo, hmm ... settin snappy_ab to b and snappy_mode to try doesnt get me booted from b | 10:22 |
| mvo | ogra_: does it show the correct values in the uboot prompt with printenv? | 10:23 |
| ogra_ | havent checked that yet | 10:24 |
| * ogra_ isnt sure if our logic is actually correct | 10:24 | |
| longsleep | did you see what i wrote above: ogra_: above you wrote the system sets ab to the other partition and trial_boot to 1. Is that really so? I think it should not touch trial_boot, but set snapp_mode to try instead? | 10:26 |
| ogra_ | mvo, http://paste.ubuntu.com/11924535/ | 10:26 |
| ogra_ | yeah, the trial_boot looks wrong | 10:26 |
| ogra_ | setting trial_boot to 1 and mode to try works | 10:28 |
| longsleep | yes - but you should not set trial_boot, you should set mode to try and ab to the one which you want to try | 10:29 |
| longsleep | whats how i see it at least | 10:29 |
| ogra_ | right, but thats not what the logic we have does | 10:29 |
| * ogra_ takes a look at the old code | 10:30 | |
| longsleep | no? i think it does just that | 10:30 |
| ogra_ | http://paste.ubuntu.com/11924535/ is the currentl logic | 10:30 |
| longsleep | yes | 10:30 |
| longsleep | but that is in uboot | 10:30 |
| ogra_ | it onl switches if mode is try and at the same time trial_boot is 1 | 10:30 |
| ogra_ | sigh | 10:31 |
| longsleep | yes but it only has to switch if the boot failed | 10:31 |
| ogra_ | why cant cloud-init not write to /dev/null | 10:31 |
| ogra_ | so annoying | 10:31 |
| longsleep | +1 | 10:31 |
| ogra_ | well, at least i dont see corruption now | 10:31 |
| longsleep | from my point of view, uboot is only switching in case of roll back | 10:31 |
| longsleep | the try is done from the system side after update | 10:32 |
| ogra_ | it shoudl also switch in case of upgrade :) | 10:32 |
| longsleep | set try and ab to other | 10:32 |
| ogra_ | and it doesnt with the current logic | 10:32 |
| longsleep | so the system does only set try but not ab to other | 10:32 |
| longsleep | thats the error then | 10:32 |
| ogra_ | no, the system sets try and ab to the other | 10:32 |
| longsleep | then all is good | 10:32 |
| ogra_ | well, no | 10:33 |
| ogra_ | it doesnt boot from b if i set it to b | 10:33 |
| longsleep | well it should, because mode is try, it boots from whatever ab is set to because trial boot is 0 | 10:33 |
| ogra_ | http://paste.ubuntu.com/11924564/ | 10:34 |
| longsleep | so either ab is a or if its b then trail boot is 1 | 10:34 |
| longsleep | if ab is b and you want to boot it from b, then trial boot needs to be 0 | 10:37 |
| mvo | ogra_: hm, hm U-Boot# printenv snappy_ab | 10:37 |
| mvo | snappy_ab=b | 10:37 |
| longsleep | ok, then trial boot is 1 | 10:38 |
| ogra_ | U-Boot# printenv snappy_ab | 10:38 |
| ogra_ | snappy_ab=b | 10:38 |
| mvo | and snappy_mode is try as well I assume? | 10:38 |
| mvo | i.e. the env is read correctly? | 10:38 |
| ogra_ | http://paste.ubuntu.com/11924581/ | 10:38 |
| ogra_ | ah, wait, didnt check mode | 10:38 |
| ogra_ | ab is definitely b after reboot | 10:39 |
| ogra_ | as you can see in the paste it boots a though | 10:39 |
| longsleep | well, for me it boots just fine from b when i set it to b, saveenv and reset | 10:40 |
| mvo | just snappy_ab b ?without the try? | 10:40 |
| mvo | without hte snappy_mode try? | 10:40 |
| longsleep | if ab is set to b and mode is try, then trial is 1 if it boots from a | 10:40 |
| longsleep | yes without the try | 10:41 |
| longsleep | let me try with try | 10:41 |
| longsleep | ok that boots from a | 10:41 |
| longsleep | so .. | 10:42 |
| longsleep | script does not work | 10:42 |
| longsleep | let me check | 10:42 |
| ogra_ | http://paste.ubuntu.com/11924593/ | 10:43 |
| ogra_ | mvo, ^^^ | 10:43 |
| ogra_ | so ab is set to b and mode to try | 10:43 |
| * ogra_ doesnt get that | 10:43 | |
| longsleep | ah i guess the problem is that snappy_trial_boot is not set and then always returns true | 10:43 |
| longsleep | i remember test to behave that way | 10:43 |
| ogra_ | yeah, thats why i wanted a boolean | 10:44 |
| * ogra_ sets it ... once cloud-init lets me | 10:44 | |
| mvo | if test ${snappy_trial_boot} = 1; then echo yes; fi | 10:44 |
| mvo | yes | 10:44 |
| mvo | echo ${snappy_trial_boot} | 10:44 |
| ogra_ | mvo, what sets it ? | 10:44 |
| mvo | thats…unexcpected | 10:44 |
| longsleep | if snappy_trial_boot is not set then it always sets to a | 10:44 |
| mvo | u-boot, seriously? | 10:45 |
| longsleep | if i set it to 0 | 10:45 |
| longsleep | it works just fine | 10:45 |
| ogra_ | mvo, well, thats the hush shell implementation ... cant blame uboot itself :) | 10:45 |
| mvo | hm, quoting maybe? | 10:45 |
| mvo | if test "${snappy_trial_boot}" = "1"; then echo yes; fi | 10:45 |
| mvo | give no output | 10:45 |
| longsleep | no, my script is quoted | 10:46 |
| longsleep | i remember having this issue before | 10:46 |
| ogra_ | yeah, i have a local fix for the quoting, but its not that | 10:46 |
| mvo | http://paste.ubuntu.com/11924602/ | 10:46 |
| mvo | looks like quoting to me unless I miss something | 10:46 |
| ogra_ | hmm | 10:46 |
| longsleep | mvo: no it does not work with the quoting either | 10:47 |
| mvo | http://paste.ubuntu.com/11924610/ | 10:47 |
| mvo | longsleep: how does yours look like? | 10:47 |
| mvo | longsleep: could you pastebin it please? | 10:47 |
| ogra_ | so what are the actual reasons for using cloud-init ? this is really annoying the hell out of me (additionally to the extra 30sec boot time it spams the console all the time) | 10:47 |
| ogra_ | i know we have distro ways of generating ssh keys | 10:47 |
| longsleep | mvo: http://paste.ubuntu.com/11924615/ | 10:47 |
| ogra_ | and i guess it wouldnt be to hard to have user creation code adopted from d-i or some such | 10:48 |
| ogra_ | what else does cloud-init do for us ? | 10:48 |
| longsleep | i have checked that a couple of weeks ago. It creates the default user too i think | 10:49 |
| longsleep | and something with the hostname | 10:49 |
| ogra_ | right | 10:49 |
| ogra_ | see what i write | 10:49 |
| ogra_ | *wrote | 10:49 |
| ogra_ | we have tools for that in the distro that we use on the livecd for example | 10:50 |
| ogra_ | its a 10 line script or so | 10:50 |
| ogra_ | same goes for ssh ... its a few extra lines to have it create keys if they dont exist | 10:50 |
| mvo | longsleep: hm, thats confusing. does your uboot shell also behave like what I see in http://paste.ubuntu.com/11924610/ ? | 10:50 |
| ogra_ | and setting the hostname from /proc/cpuinfo isnt to hard either | 10:50 |
| longsleep | mvo: i just checked that | 10:50 |
| longsleep | mvo: mine behaves differently | 10:51 |
| longsleep | mvo: if test "${snappy_trial_boot}" = "1"; then echo yes; fi | 10:51 |
| longsleep | yes | 10:51 |
| ogra_ | i just dont get why we have to go through all the pain with cloud-init for these tzhree bits ... and make it really hard and uncomfortable for developers | 10:51 |
| longsleep | (with unset trial boot) | 10:51 |
| ogra_ | longsleep, mvo most likely a version thing | 10:51 |
| longsleep | ogra_: yeah - i think you should ask the one who added it - i would really love to see it go away | 10:52 |
| longsleep | ogra_: let me check Git | 10:52 |
| ogra_ | seems everyone would | 10:52 |
| ogra_ | so yeah setting trial_boot to 0 gets me properly booted from b as expected | 10:52 |
| mvo | longsleep: woah, thats amazing, uboot is always good for a suprise | 10:53 |
| longsleep | mvo: http://paste.ubuntu.com/11924645/ | 10:53 |
| longsleep | mvo: indeed | 10:53 |
| ogra_ | mvo, well, vendors are good for surprises in that case ;) ... since they fork off from ancient uboot versions and never merge back usually | 10:53 |
| longsleep | ah yes | 10:54 |
| longsleep | http://git.denx.de/?p=u-boot.git;a=commit;h=2453de99df576fb907fe06cac58c628e3590833f | 10:54 |
| mvo | ogra_: yeah, looks like we need to make it bool and also change grub to be on the safe side, it looks on the bbb quoting will help, but if thats not universal its no good | 10:54 |
| ogra_ | yep | 10:55 |
| mvo | amazing | 10:55 |
| mvo | thanks longsleep | 10:55 |
| longsleep | i did remember seeing that because i have another u-boot where i needed the -e for test and thus merged around in test command before | 10:56 |
| * longsleep is going to have some lunch | 10:56 | |
| mvo | longsleep: do you also a yes for ' if "" = "1"; then echo yes; fi' | 10:56 |
| longsleep | mvo: err sorry | 10:56 |
| longsleep | mvo: what do you want me to run? | 10:56 |
| longsleep | got it hold on | 10:57 |
| longsleep | mvo: you missed a test in there right? else if gives unknown command | 10:58 |
| longsleep | mvo: empty string works just fine | 10:58 |
| mvo | longsleep: yes, sorry. I wonder if "if printenv snappy_trial_boot; then echo yes; fi works | 10:59 |
| mvo | longsleep: interessting and crazy | 10:59 |
| ogra_ | WOAH ! | 10:59 |
| ogra_ | mvo, why is /var/lib/dpkg/info not wiped ? | 10:59 |
| mvo | ogra_: we only do that on wily | 11:00 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ du -hcs /var/lib/dpkg/info/ | 11:00 |
| ogra_ | 9.2M /var/lib/dpkg/info/ | 11:00 |
| ogra_ | ah, k | 11:00 |
| ogra_ | then i'm fine | 11:00 |
| longsleep | mvo: that seems to work http://paste.ubuntu.com/11924669/ | 11:00 |
| ogra_ | mvo, that meanbs we have 9.2M extra space there in which we could ass uboot-go ;) | 11:01 |
| mvo | lol | 11:01 |
| ogra_ | *add | 11:01 |
| mvo | yeah, I thnk we should add it | 11:01 |
| mvo | http://people.canonical.com/~mvo/tmp/beagleblack_1.10_all.snap <- that has a snap with the quotes, building a new image+mp will be at least 2h that we can't test the rest :/ | 11:01 |
| Chipaca | pitti had suggested how we restart the network from inside the 'first boot' unit; does anybody remember how it was? | 11:02 |
| mvo | longsleep: I wonder if that could/should be used so that we can continue iterating, the image building is so slow :/ | 11:02 |
| ogra_ | mvo, does that have my MP merged ? | 11:02 |
| mvo | ogra_: I used your 1.9 snap | 11:02 |
| ogra_ | cool | 11:02 |
| mvo | as the base and just added the quotes | 11:02 |
| mvo | its writing now | 11:02 |
| ogra_ | mvo, hmm, no | 11:02 |
| longsleep | mvo: so for your u-boot it works with quotes? | 11:02 |
| longsleep | mvo: i could merge the fix into my u-boot | 11:03 |
| mvo | longsleep: it appears to be, I'm double checking | 11:03 |
| ogra_ | you probably also want snappy_trial_boot=0 in uboot.env.in | 11:03 |
| longsleep | but i guess it will be trouble | 11:03 |
| mvo | ogra_: thats in there already afaict | 11:03 |
| longsleep | as that change is from early 2014 | 11:03 |
| * mvo double-checks | 11:03 | |
| ogra_ | oh | 11:03 |
| mvo | longsleep: yeah, I think the final version needs to set it to "0" | 11:03 |
| ogra_ | ah, yeah | 11:03 |
| ogra_ | heh ... i dont know my own code after two days anymore ... | 11:04 |
| mvo | longsleep: I'm just sick of waiting for another image and want to give it a good beating (for testing) | 11:04 |
| mvo | ogra_: I don't after 2h | 11:04 |
| * ogra_ guesses he should check for some vacation :) | 11:04 | |
| longsleep | mvo: but for testing now i am fine with whatever workaround | 11:04 |
| ogra_ | mvo, but you have kids distracting you ... thats fine :P | 11:04 |
| mvo | then I can prepare a branch after lunch, its trivial | 11:04 |
| mvo | ogra_: you have cats, about the same, no ;) ? | 11:04 |
| ogra_ | nah, they lseep during the day :) | 11:04 |
| ogra_ | *sleep | 11:04 |
| * longsleep now really goes for lunch | 11:05 | |
| * mvo is also hungry | 11:05 | |
| * ogra_ considers breakfast :) | 11:06 | |
| Chipaca | Cogito ergo ipomoea batatal. | 11:10 |
| * Chipaca takes a break | 11:10 | |
| === kickinz1|afk is now known as kickinz1 | ||
| mvo | ogra_: http://people.canonical.com/~mvo/tmp/beagleblack_1.11_all.snap <- latest that works for me, i.e. it now boots b when I set snappy_ab b and snappy_mode try | 11:49 |
| mvo | next I will make it not unset the env | 11:50 |
| mvo | Chipaca: if you have a moment, it would be great if you could check https://code.launchpad.net/~mvo/snappy/snappy-no-unset-trial-boot and https://code.launchpad.net/~mvo/snappy/15.04-snappy-uboot-no-unset-trial-boot | 12:02 |
| mvo | ogra_: ^--- those branches set to "0" instead of unsetting | 12:02 |
| Chipaca | mvo: are those the result of what you and ogra debugged this morning? | 12:02 |
| mvo | Chipaca: yes, its the result of trying to be as compatible with u-boots quirks as possible | 12:02 |
| Chipaca | mvo: +1'ed; code looks sane, and i've watched you debug it :) | 12:06 |
| mvo | Chipaca: heh, thanks | 12:07 |
| mvo | Chipaca: crazy I say this u-boot | 12:07 |
| mvo | but it seems its under control | 12:07 |
| longsleep | mvo: i did some more testing and found that all combinations seem to work as long as no variable is not defined. | 12:12 |
| longsleep | mvo: See https://github.com/longsleep/snappy-odroidc/blob/uboot-env-support/oem/boot-assets/uboot.env.in for my latest env | 12:12 |
| mvo | longsleep: great, the above MP fixes the undefined vars | 12:16 |
| * mvo is still a bit disappointed by uboot, really | 12:16 | |
| longsleep | well u-boot is getting better and has improved a lot since 2014 | 12:18 |
| longsleep | unfortunately most vendors have based their u-boot on 2013 something .. | 12:18 |
| mvo | yeah, sorry, I'm ranting a bit | 12:18 |
| longsleep | at least it is open source - imagine you had to deal with closed source issues | 12:19 |
| mvo | longsleep: heh :) good point | 12:19 |
| longsleep | i am pretty sure uefi implementations are even worse than u-boot is | 12:19 |
| ogra_ | mvo, could be a lot worse ... we could have to deal with redboot or aboot :) | 12:23 |
| ogra_ | merge looks good indeed | 12:24 |
| ogra_ | hmm | 12:29 |
| * ogra_ wonders why his phone screen doesnt turn on on notofocations | 12:29 | |
| ogra_ | *notifications | 12:29 |
| === fgimenez_ is now known as fgimenez | ||
| ogra_ | WOW ... | 12:35 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages | 12:35 |
| ogra_ | why does it say "no signer" for the last snappy build | 12:35 |
| mvo | auto upload from the daily builds | 12:36 |
| mvo | thats ok | 12:36 |
| mvo | I triggered builds now and once they are in we can get the golden image | 12:36 |
| mvo | hopefully :P | 12:36 |
| ogra_ | does it correct that later ? | 12:36 |
| mvo | ogra_: the later? you mean the unset vs set = 0? | 12:37 |
| ogra_ | i mean the "no signer" i have never seen that before | 12:37 |
| mvo | I thnk its there all the time, for every daily build | 12:37 |
| * mvo could be wrong though | 12:37 | |
| ogra_ | i wonder why i never noticed it before | 12:37 |
| ogra_ | i not only need new teeth and vacation apparently but also glasses :P | 12:38 |
| * ogra_ is happy he still has some hair at least :P | 12:38 | |
| longsleep | mvo: so you think the fw_* commands will work with the next build? | 12:41 |
| longsleep | mvo: i did not manage to get the rolling release to accept my oem snap :/ | 12:41 |
| ogra_ | fw_* should work, yes | 12:41 |
| ogra_ | they already work here right now though | 12:42 |
| longsleep | oh - so am an 128 and they do not work for me | 12:43 |
| ogra_ | oh ? | 12:43 |
| mvo | longsleep: crc error? or something else? | 12:43 |
| ogra_ | 4 vs 5 byte again? | 12:43 |
| longsleep | no i got 5 byte env | 12:44 |
| longsleep | parses fine with uboot-go | 12:44 |
| mvo | size also corret on disk and maches fw_env.config? | 12:44 |
| mvo | fw_env.config needs the hex size | 12:44 |
| mvo | if its nothing like this I run out of ideas :/ | 12:44 |
| longsleep | the config has the two lines with the comment for 5 bytes | 12:44 |
| mvo | uboot-go is smarter and figures the size out by itself | 12:45 |
| longsleep | mhm | 12:45 |
| longsleep | http://paste.ubuntu.com/11925071/ | 12:46 |
| longsleep | 5 bytes until the b | 12:47 |
| mvo | longsleep: what fize has the file? | 12:47 |
| longsleep | mvo: 32768 bytes | 12:48 |
| elopio | fgimenez: I was wondering if we could leave your job code only for provisioning. | 12:48 |
| longsleep | (thats the value in u-boot compile time) | 12:48 |
| elopio | fgimenez: like leave the --command flag out, and make the main return an ip. | 12:48 |
| ogra_ | longsleep, to small then | 12:48 |
| longsleep | err | 12:48 |
| ogra_ | +uboot.env is created from uEnv.txt via: | 12:49 |
| ogra_ | +$ mkenvimage -r -s 131072 -o uboot.env uboot.env.in | 12:49 |
| fgimenez | elopio, sure, the cloud package takes care of that | 12:49 |
| ogra_ | from our beaglebone README in the snap branch | 12:49 |
| mvo | longsleep: hm, so we need to set 0x8000 in fw_env.config for you or you increase the env | 12:49 |
| longsleep | ogra_: why too small? | 12:50 |
| mvo | probably best if you increase it as we have no way right now to change fw_env.config | 12:50 |
| longsleep | how large should it be | 12:50 |
| ogra_ | longsleep, 128k | 12:50 |
| longsleep | oh ok | 12:50 |
| ogra_ | just use the same mkenvimage call | 12:50 |
| * mvo will explore to put uboot-go into the image, thats all a bit insane IMNSO | 12:51 | |
| longsleep | i doo | 12:51 |
| longsleep | see https://github.com/longsleep/snappy-odroidc/blob/uboot-env-support/oem.mk#L29 | 12:51 |
| ogra_ | mvo, +1000 | 12:51 |
| mvo | I mean, it seems bad to force everyone to use our env size just because of a silly config | 12:51 |
| ogra_ | longsleep, no, you use -s 32768 | 12:51 |
| longsleep | yes | 12:51 |
| longsleep | i was not aware that i have to use another size | 12:51 |
| elopio | fgimenez: so I'm thinking, on snappy/_integration-tests/main.go we can do a kvm-ok. If it succeeds, run adt-run ... -- snappy. If it doesn't, call your project and get an ip from canonistack, and then adt-run ... -- ssh ip. | 12:51 |
| ogra_ | <ogra_> +$ mkenvimage -r -s 131072 -o uboot.env uboot.env.in | 12:51 |
| longsleep | but no problem | 12:51 |
| mvo | longsleep: yeah, you wouldn't have to, actually you don't have to except for testing | 12:52 |
| ogra_ | longsleep, well, preferably fw_* would autodetect it | 12:52 |
| mvo | longsleep: snappy itself is not touch fw_setenv/printenv at all | 12:52 |
| ogra_ | but the command is originally for MTD devices | 12:52 |
| longsleep | yeah | 12:52 |
| mvo | it uses its own uboot env handling (thanks god for that) | 12:52 |
| elopio | fgimenez: also, I'm getting this error: http://paste.ubuntu.com/11925094/ | 12:54 |
| ogra_ | mvo, looks lilke the packages have built | 12:55 |
| ogra_ | (ppc failing on vivid) | 12:55 |
| * longsleep rebuilds u-boot with 128k env size | 12:55 | |
| fgimenez | elopio, the error is because the credentials you are using, the key specified with -k is not present, | 12:56 |
| mvo | ogra_: yeah, I triggered a rootfs build some minutes ago | 12:57 |
| mvo | so once that new image is available I guess QA needs to test the hell out of it | 12:57 |
| ogra_ | wheee !! | 12:57 |
| fgimenez | elopio, when we meet later we can talk about the shared user credentials | 12:57 |
| longsleep | mvo, ogra_ ok confirmed fw_* works with 128k size - thanks! | 13:02 |
| mvo | yay! | 13:02 |
| ogra_ | :) | 13:02 |
| ogra_ | silly hardcoding in the confi file | 13:02 |
| ogra_ | +g | 13:02 |
| mvo | oh yes | 13:02 |
| ogra_ | but i guess we get what we ask for ... abusing an MTD tool for a random file :) | 13:02 |
| elopio | fgimenez: ok, got it working now, thanks. I think the ssh security group is not needed, as the default is to allow the port 22. | 13:03 |
| mvo | ohh, image build, now its just a matter of waiting for it to be imported | 13:03 |
| ogra_ | yeah .... already uploading | 13:03 |
| elopio | utlemming: could you add the image # into the cloud image name? | 13:05 |
| fgimenez | elopio, ok thx, i'll correct that and some errors because of the import paths, at least when running from an instance without gopath defined | 13:10 |
| * ogra_ builds a new image | 13:13 | |
| ogra_ | oh, i cant | 13:13 |
| ogra_ | ! | 13:13 |
| ogra_ | mvo, where is your snap ? :) | 13:13 |
| ogra_ | (could you upload it somewhere) | 13:16 |
| ogra_ | oh man ! | 13:17 |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ snappy revert | 13:17 |
| ogra_ | Unknown command `revert'. Please specify one command of: booted, build, config, firstboot, hw-assign, hw-info, hw-unassign, info, install, internal-run-hooks, internal-unpack, list, login, purge, remove, rollback, search, set, update or versions | 13:17 |
| * ogra_ makes snappy a hardlink to bzr on his machine :P | 13:17 | |
| mvo | ogra_: http://people.canonical.com/~mvo/tmp/beagleblack_1.11_all.snap | 13:18 |
| ogra_ | thx | 13:18 |
| mvo | yw | 13:18 |
| * rsalveti reads backlog | 13:18 | |
| mvo | yay, looks like the image is there | 13:18 |
| ogra_ | yep | 13:18 |
| Chipaca | mvo: when you have a moment, and it's not urgent at all, i could use a review on https://code.launchpad.net/~chipaca/snappy/service/+merge/265658 | 13:18 |
| Chipaca | also on its pre-req | 13:18 |
| mvo | Chipaca: sure | 13:18 |
| * Chipaca ~> lunch | 13:19 | |
| mvo | rsalveti: executive summary: more fighting with uboot and its quirks, we *think* we have a final image | 13:19 |
| ogra_ | yeah | 13:19 |
| mvo | rsalveti: that just finished building ~2min ago | 13:19 |
| ogra_ | we are pretty pretty sure we do :) | 13:19 |
| mvo | rsalveti: if ${var_that_is_not_set} = "1"; then echo yes; fi returns yes in uboot, that took us a while to figure out (well, me at least) | 13:20 |
| mvo | even with quotes its still not working on an older uboot | 13:20 |
| ogra_ | boolean ftw :) | 13:20 |
| Chipaca | mvo: ogra_: in uboot, does if "11" = "1"; then echo yes; fi produce yes? | 13:24 |
| Chipaca | ie, is = a prefix search? | 13:24 |
| ogra_ | no | 13:24 |
| ogra_ | but if "" = "1" can produce yes in older versions | 13:25 |
| ogra_ | Chipaca, http://git.denx.de/?p=u-boot.git;a=commit;h=2453de99df576fb907fe06cac58c628e3590833f | 13:25 |
| * ogra_ twiddles thumbs waitin for dd | 13:26 | |
| mvo | ogra_: use godd, it tells me that I need to wait 8 more min utes | 13:26 |
| mvo | this makes the thumb twiddle much more planable | 13:26 |
| ogra_ | mvo, but it doesnt speed up anything | 13:27 |
| Chipaca | or killall -USR1 dd | 13:27 |
| * mvo thinks about complex patterns | 13:27 | |
| ogra_ | i know how to get a progressbar ... i wrote usb-imagewrite 5 years ago using the USR hack | 13:27 |
| mvo | ogra_: did you send a USR signal every N seconds? just curious? | 13:27 |
| mvo | Chipaca: shhh, don't tell people that the 7 lines of go code for godd are not needed ;) | 13:28 |
| * ogra_ would be more interested in a patch to dd so that it automatically determines the fastest blocksize for me and speeds up the write ;) | 13:28 | |
| Chipaca | ogra_: mvo: clearly, your computers need more ram! http://downloadmoreram.com/ | 13:28 |
| ogra_ | mvo, yeah ... two processes | 13:28 |
| ogra_ | a shell wrapper to call the dd with a watch ... and a pygtk UI that reads from it to show a UI progressbar | 13:29 |
| ogra_ | (i never found the time to port it away from hal though ... and left it die) | 13:29 |
| mvo | ogra_: neat! | 13:29 |
| ogra_ | heh, it is still promoted on https://help.ubuntu.com/community/Installation/FromImgFiles | 13:31 |
| ogra_ | "for systems up to 12.10" ... :P | 13:31 |
| * ogra_ boots the new image | 13:32 | |
| * ogra_ reboots and crosses fingers | 13:36 | |
| ogra_ | yay ... boots from b | 13:37 |
| mvo | same here | 13:38 |
| ogra_ | rebooting back to a | 13:38 |
| ogra_ | works too :) | 13:38 |
| mvo | yay | 13:40 |
| ogra_ | ok, lets torture it a bit with reset button and reboot -f | 13:40 |
| mvo | go go go | 13:40 |
| mvo | and someone needs to test upgrades from older image sto the new and check that the old uEnv.txt is still fully supported and understood | 13:40 |
| mvo | etc | 13:40 |
| ogra_ | we need the images for that ... on the server i mean | 13:41 |
| ogra_ | and the snap approved in the store | 13:41 |
| ogra_ | (not sure how else you could upgrade manually ... does sideloadign the oem snap work ? | 13:41 |
| ogra_ | mvo, btw, why do we need to give a and b ... wouldnt it be better to have something like "other" and snappy or the bootloader automatically pick the currently not used path ? | 13:43 |
| mvo | ogra_: hm, upgrading the oem snap is actually a problem, we can't allow that before we can not also write a new uboot | 13:44 |
| ogra_ | so i think it tried all possible ways to kill it now ... removing power, reset button "reboot -fp" ... no corruption | 13:45 |
| ogra_ | (and it reacts as expected still) | 13:45 |
| ogra_ | that shoudl also finally fix vmayorals issues with the erle bots | 13:46 |
| mvo | yeah, someone needs to send him a mail that its finally under control | 13:46 |
| mvo | (if he is not on irc) | 13:46 |
| ogra_ | well, once we released it i'll write an announcement mail and also some documentation for porters | 13:46 |
| ogra_ | i just dont want to do that before we have a 100% final implementation | 13:47 |
| mvo | ogra_: uh, looks like someone approved beagleblack 1.9 in the store | 13:47 |
| ogra_ | (seems we hit a roadblock every time we think we are done ... i got careful :) ) | 13:47 |
| ogra_ | mvo, eeek ! | 13:47 |
| ogra_ | so better push .11 over it | 13:48 |
| mvo | ogra_: well, the remaining roadblock is what to do with existing users | 13:48 |
| ogra_ | right | 13:48 |
| rsalveti | mvo: wow, that is annoying (the if check issue) | 13:54 |
| rsalveti | and wow, you guys had a lot of fun :-) | 13:54 |
| ogra_ | LOL | 13:55 |
| ogra_ | FSVO fun :) | 13:55 |
| rsalveti | so you guys had to path u-boot in the end? | 13:55 |
| mvo | ogra_: puhh, all good, I *think* we are save, boot-assets are only handled by u-d-f so we are good for the upgrade | 13:55 |
| ogra_ | no, in the beginning :) | 13:55 |
| rsalveti | *patch | 13:56 |
| ogra_ | rsalveti, we only ptach the enabling of uboot.env into the config, nothing more | 13:56 |
| rsalveti | right, cool | 13:56 |
| ogra_ | *patch | 13:57 |
| ogra_ | :P | 13:57 |
| rsalveti | mvo: ogra_: so did we approve the oem we didn't yet want to land? | 13:57 |
| ogra_ | (such a hard word to type :P ) | 13:57 |
| rsalveti | beagleblack 1.9 | 13:57 |
| ogra_ | yes | 13:57 |
| rsalveti | why? | 13:57 |
| ogra_ | but there is a 1.11 that we need anyway | 13:57 |
| ogra_ | no idea, i dont know who approved and why | 13:57 |
| rsalveti | so would 1.9 break the current stable image? | 13:57 |
| ogra_ | yes | 13:57 |
| rsalveti | crap | 13:57 |
| longsleep | so is the new image ready - so i can give it another try? | 13:57 |
| ogra_ | half breeded | 13:57 |
| ogra_ | which is why we havent approved it | 13:58 |
| ogra_ | longsleep, yeah | 13:58 |
| rsalveti | well, if 1.9 is already causing us pain, just push 1.11 | 13:58 |
| ogra_ | mvo, ^^^ | 13:58 |
| rsalveti | and let's hope we can release today | 13:58 |
| === zyga is now known as zyga-afk | ||
| * longsleep is downloading | 13:59 | |
| rsalveti | at least we can test it easily | 13:59 |
| ogra_ | rsalveti, +1 ... that took way to long again :/ | 13:59 |
| rsalveti | ogra_: might be a good time to promote latest edge to alpha | 13:59 |
| ogra_ | does that make sense without the snap ? | 13:59 |
| ogra_ | i think we need 1.11 first ... then promote | 13:59 |
| rsalveti | sure, I was assuming we can do both in parallel | 14:00 |
| ogra_ | or that, yeah | 14:00 |
| longsleep | all right, booted into 129 - lets have some fun | 14:13 |
| longsleep | ogra_, mvo : 129 works just fine (faking update by fw_setenv snappy_ab b; fw_setenv snappy_mode try; reboot) | 14:15 |
| ogra_ | yay | 14:16 |
| longsleep | let me try rollback | 14:16 |
| longsleep | ogra_, mvo : Rollback works as well - so all green from me :) | 14:19 |
| rsalveti | ogra_: do we need to wait for mvo to upload a new oem? | 14:23 |
| longsleep | from what i understand is that old oem should work with new image but new oem will not work with old image | 14:24 |
| longsleep | that the state for my odroidc oem at least | 14:24 |
| ogra_ | longsleep, \o/ | 14:26 |
| ogra_ | rsalveti, it is uploaded but someone needs to approve it | 14:26 |
| mvo | rsalveti: already uploaded, just needs approval | 14:27 |
| rsalveti | I guess I can approve it, but would need to find it first | 14:27 |
| rsalveti | let me check | 14:27 |
| ogra_ | https://myapps.developer.ubuntu.com/dev/click-apps/2277/ | 14:27 |
| rsalveti | ogra_: mvo: done | 14:28 |
| mvo | longsleep: thanks a bunch for all your help and testing and feedback | 14:29 |
| mvo | rsalveti: \o/ | 14:29 |
| ogra_ | so let me push edge to alpha then | 14:30 |
| mvo | elopio, fgimenez do you guys have time to test the new 15.04 image in edge? we need to be sure that upgrades do not break, especially with beagleblack 1.8 from the last stable to the current alpha | 14:31 |
| mvo | ogra_: cool | 14:31 |
| fgimenez | mvo, sure, on it | 14:31 |
| mvo | thanks! | 14:32 |
| elopio | mvo: yes. | 14:34 |
| ogra_ | mvo, hmm, that doesnt look right http://system-image.ubuntu.com/ubuntu-core/15.04/edge/generic_amd64/ | 14:34 |
| elopio | fgimenez: mvo: current stable is the same as alpha#3, so we can start flashing that one. | 14:34 |
| ogra_ | mvo, last build is from yesterday | 14:35 |
| elopio | fgimenez: want to meet, or do you prefer to spend the time testing? | 14:35 |
| mvo | ogra_: oh, I did not triggered amd64, one sec | 14:36 |
| ogra_ | mvo, did you buiuld with ARCHES= set when you re-triggered a build ? | 14:36 |
| mvo | ogra_: I did | 14:36 |
| ogra_ | ah | 14:36 |
| mvo | ogra_: to speed it up | 14:36 |
| ogra_ | yeah | 14:36 |
| ogra_ | armhf is copied to alpha now | 14:36 |
| mvo | I triggered a full build now too | 14:37 |
| ogra_ | waiting for amd64 now :) | 14:37 |
| fgimenez | elopio, as you like, i have the ho open :) | 14:38 |
| mvo | elopio: great, the important part is that beagleback is still 1.8 on the base image so that we are confident that existing users will not break with the new oem part. I'm 96% certain they won't but the remaining 4% worry me a bit | 14:38 |
| * longsleep thinks i should implement that into the new oem as well | 14:38 | |
| longsleep | mvo: how did you handle this case, how do you know if you have to load snappy-system.txt ? | 14:42 |
| mvo | longsleep: I check for /boot/uboot/uboot.env, if thats there I assume its the new system. this will only be put in place by u-d-f | 14:58 |
| longsleep | mvo: ah - you are saying that updating the oem snap from the store does not change stuff below /boot/uboot ? | 15:00 |
| longsleep | mvo: or where is this check? | 15:00 |
| mvo | longsleep: yes, new boot-assets are not put into place | 15:01 |
| longsleep | mvo: ok, that essentially means that there is no way to upgrade from old oem uboot to new one? | 15:02 |
| ogra_ | longsleep, works in rollinng afaik | 15:03 |
| vmayoral | hi everyone, just realized https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ changed | 15:04 |
| vmayoral | i noticed that system-a is now "2 GB" | 15:04 |
| vmayoral | do the new BeagleBone Black images includes this change? | 15:05 |
| longsleep | ogra_: you mean in rolling, the boot-assets are put in place on update? | 15:05 |
| vmayoral | also, what happened to "system-boot"? | 15:05 |
| vmayoral | mmm, the filesystem information conflicts with what's provided at https://developer.ubuntu.com/en/snappy/guides/transactional-updates/ | 15:06 |
| rsalveti | hm, it shouldn't be 2gb, wonder what happened in there | 15:11 |
| ogra_ | vmayoral, FYI we reworked the uboot bits the last days, i'll write an announcement and documentation soon, that should one and for all fix all your corruption issues | 15:12 |
| vmayoral | ogra_: that's great, thanks a lot | 15:13 |
| ogra_ | you likely want to adjust your oem snaps for that then | 15:13 |
| vmayoral | ogra_: the oem snap? | 15:14 |
| ogra_ | well, the ones you use for your bootloader | 15:14 |
| ogra_ | (i think i saw a few in the store) | 15:15 |
| vmayoral | ogra_: i'd expect to modify something within the boot partition (e.g. the initrd.img). Currently our oem snap does not contain any dtb | 15:15 |
| ogra_ | oh, i didnt know, i thought you include uboot and a uboot confi for the dtb overrides | 15:16 |
| vmayoral | ogra_: that'll happen soon i hope :) | 15:17 |
| Chipaca | rsalveti: wrt bug 1466672, given that webdm isn't useful if there's no network, i think what we want to happen is it's only started when an external interface is brought up | 15:23 |
| ubottu | bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672 | 15:23 |
| ogra_ | +1 | 15:23 |
| ogra_ | its doesnt do that currently though | 15:24 |
| ogra_ | there is no auto-starting | 15:24 |
| Chipaca | rsalveti: given that, i propose we modify the generated service startup scripts so that, if a service specifies an external port, we make it depend on having an external network | 15:24 |
| ogra_ | ok, seems the image is done | 15:25 |
| elopio | mvo: so, I can't flash alpha like this: http://paste.ubuntu.com/11925656/ ? | 15:25 |
| * ogra_ copies again to alpha | 15:25 | |
| Chipaca | rsalveti: keying off of having an external port means we can implement it with no changes to published meta description | 15:25 |
| ogra_ | elopio, oh, why ? | 15:25 |
| elopio | ogra_: not sure, it's booting into debian. | 15:26 |
| elopio | might be my sdcard, so I'll try with the new one. | 15:26 |
| ogra_ | did you hold down the S2 button ? | 15:26 |
| elopio | ogra_: no. | 15:27 |
| elopio | didn't we change it so the s2 button does nothing anymore? | 15:28 |
| ogra_ | well, try that :) | 15:28 |
| ogra_ | no, we cant change the RM | 15:28 |
| ogra_ | *ROM | 15:28 |
| fgimenez | elopio, mvo ogra_ mmm it seems to fail to rollback from 6 to 3 here http://paste.ubuntu.com/11925667/ | 15:29 |
| * ogra_ would like to see the bootloader messages on serial console for that | 15:29 | |
| fgimenez | how can i get the output from the serial console? | 15:29 |
| ogra_ | with your serial cable :) | 15:30 |
| elopio | fgimenez: ctrl+a + H saves it to a log file | 15:30 |
| fgimenez | ogra_, yep :) but the screen... ok thx elopio | 15:30 |
| elopio | that's ctrl+a and then H | 15:30 |
| mvo | elopio: might be that you get a beaglebone thats too new I wonder if the store can give you 1.8, let me see | 15:30 |
| ogra_ | or if you use screen use the -L option | 15:30 |
| ogra_ | it will create a screenlog.0 file and log everything in $(pwd) | 15:30 |
| fgimenez | ogra_, ok thx, trying now | 15:30 |
| longsleep | mvo: just trying update from 129 to 130 - getting "can not find file /writable/cache/assets/vmlinuz" http://paste.ubuntu.com/11925676/ - any idea? | 15:31 |
| longsleep | update seems to work | 15:32 |
| ogra_ | despite the errors ? | 15:32 |
| ogra_ | *error | 15:32 |
| longsleep | well, it wrote the other patition, trying boot now | 15:32 |
| mvo | elopio: could you please try if http://people.canonical.com/~mvo/tmp/beagleblack_1.8_all.snap with u-d-f works? so download and then --oem ./beagleblack_1.8_all.snap ? | 15:32 |
| elopio | mvo: sure. | 15:33 |
| longsleep | ogra_: no - it seems it did not write the changes to the environment | 15:33 |
| ogra_ | hrm | 15:33 |
| longsleep | (ODROIDC)root@odroid:~# snappy list -v | 15:33 |
| longsleep | Name Date Version Developer | 15:33 |
| longsleep | ubuntu-core 2015-07-23 129 ubuntu* | 15:33 |
| longsleep | ubuntu-core 2015-07-23 130 ubuntu! | 15:33 |
| longsleep | odroidc 2015-07-23 0.3 * | 15:33 |
| longsleep | Reboot to use the new ubuntu-core. | 15:33 |
| longsleep | when i reboot it boots into 129 | 15:33 |
| mvo | fgimenez: so you upgraded from 3->6 and then the rollback showed the behvior in the pastebin? could you pastebin ls -al /boot/uboot/ please | 15:34 |
| mvo | longsleep: so you just get this warning? let me look at the source, no ideas right from the top of my head | 15:34 |
| elopio | mvo: is there an option to allow-unauthenticated from udf? beagleblack_1.8_all.snap failed to install: Signature verification failed | 15:35 |
| longsleep | mvo: yes that warning and nothing more | 15:35 |
| mvo | longsleep: oh, so your changes got applied to the other partiton but it did not boot the other one? | 15:35 |
| longsleep | mvo: correct | 15:35 |
| ogra_ | elopio, weird, that works locally | 15:35 |
| fgimenez | mvo, of course, this is the serial console log http://paste.ubuntu.com/11925689/ | 15:35 |
| mvo | elopio: I thought it did that automatically with --developer-mode :/ | 15:35 |
| fgimenez | ogra_, ^ | 15:35 |
| longsleep | mvo: probably stopped because of the vmlinuz error before modify of the uboot.env | 15:36 |
| ogra_ | elopio, sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.8_all.snap --developer-mode -o bbb.img 15.04 | 15:36 |
| elopio | mvo: That's it. I wasn't using dev mode. | 15:36 |
| mvo | longsleep: what does fw_printenv|grep ^snappy show? and ls -al /boot/uboot? | 15:36 |
| mvo | longsleep: aha, that makes sense, yes | 15:36 |
| mvo | elopio: cool | 15:36 |
| longsleep | mvo: http://paste.ubuntu.com/11925696/ | 15:36 |
| fgimenez | mvo, http://paste.ubuntu.com/11925697/ | 15:37 |
| mvo | ogra_, fgimenez I wonder if the rollback failed because of spl_load_image_fat_os: error reading image args, err - -1 in the pastebin | 15:37 |
| longsleep | mvo: but why does it want an vmlinuz file - my oem snap provides uImage | 15:37 |
| vmayoral | guys, recently i've noticed that when creating some snaps, I get ".sideload" at the end. Can anyone explain why's that? | 15:37 |
| ogra_ | mvo, no | 15:37 |
| mvo | fgimenez: it looks like it tried booting a, then failed and reverted to b? | 15:37 |
| mvo | ogra_: no? | 15:37 |
| ogra_ | mvo, SPL doesnt need more than finding uboot.img | 15:37 |
| longsleep | mvo: sorry meant device tarball - that provides uImage and not vmlinuz | 15:38 |
| ogra_ | you can ignore the messages | 15:38 |
| mvo | longsleep: ohhh, I think we may have hardcoded vmlinuz :/ | 15:38 |
| longsleep | mvo: ah - well | 15:38 |
| mvo | longsleep: we call it "normalized" instead of hardcoded but its the same :( | 15:38 |
| longsleep | mvo: i guess i can write it to vmlinuz even if it is not a vmlinuz | 15:39 |
| mvo | fgimenez: thanks, the uboot dir looks fine, you were not migrated to the new uboot.env which is what we expected | 15:39 |
| ogra_ | riht | 15:39 |
| ogra_ | the serial log looks ok too | 15:39 |
| longsleep | mvo: you should probablu use the name provided in device/hardware.yaml - there i say kernel: assets/uImage | 15:39 |
| ogra_ | loads the old files, they seem to contain data too and it even writes snappy-stamp.txt | 15:39 |
| mvo | ogra_: in the pastebin http://paste.ubuntu.com/11925689/ I see in line ~205 that it tries to load a/vmlinz, boots it, then 227 has the uboot prompt again and it boots b/ again, so I wonder if the kernel on a/ failed somehow | 15:40 |
| mvo | longsleep: *cough* indeed | 15:40 |
| ogra_ | mvo, yeah, but why would it ? its the same kernel | 15:40 |
| mvo | longsleep: thats a diferent bug, I need to look at this (or sergio when he is back) | 15:40 |
| mvo | ogra_: I have no clue, there is also no message | 15:40 |
| ogra_ | right | 15:40 |
| mvo | unless its the same corruption we are trying to fix with the new uboot.env | 15:41 |
| mvo | but that feels a bit too much like magic-rabitt-to-explain-this-problem | 15:41 |
| ogra_ | yeah | 15:41 |
| ogra_ | and that usually also errors | 15:41 |
| ogra_ | there are no errors | 15:41 |
| * mvo nods | 15:42 | |
| ogra_ | fgimenez, can you paste uEnv.txt and snappy-system.txt | 15:42 |
| mvo | fgimenez: could you md5sum the kernels in /boot/uboot/?/vmlinuz | 15:42 |
| rsalveti | Chipaca: I think that's ok | 15:42 |
| longsleep | mvo: i will add a ticket, and change my device tarball to use vmlinuz | 15:42 |
| mvo | longsleep: thanks | 15:43 |
| rsalveti | but yeah, we can start the service once we get the network I guess | 15:43 |
| fgimenez | ogra_, http://paste.ubuntu.com/11925725/ | 15:43 |
| ogra_ | fgimenez, thanks, looks all as expected | 15:44 |
| fgimenez | mvo, http://paste.ubuntu.com/11925728/ | 15:44 |
| ogra_ | interesting ! | 15:44 |
| ogra_ | they should be the same binary | 15:45 |
| ogra_ | i wonder if mvo is actually right and we hit fs corruption on the old version | 15:45 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ md5sum /boot/uboot/?/vmlinuz | 15:46 |
| ogra_ | 73d20f826ae7ec09671950057dee0db8 /boot/uboot/a/vmlinuz | 15:46 |
| ogra_ | 73d20f826ae7ec09671950057dee0db8 /boot/uboot/b/vmlinuz | 15:46 |
| ogra_ | that is how it shoudl look like | 15:46 |
| ogra_ | so i guess the a kernel got corrupted somehow | 15:46 |
| mvo | elopio: you are writing a alpha rev3 image too right? what md5sum do you have for the kernel(s). does it match http://paste.ubuntu.com/11925728/? | 15:47 |
| mvo | longsleep: thanks! this part the code in snappy needs some love iirc | 15:47 |
| longsleep | mvo: yeah - added bug #1477657 - now chaning stuff to be named vmlinuz (btw, that worked when updating from 2 to 3 in stable). Do you check for initrd name as well (because that is named uInitrd for me) | 15:49 |
| nothal | Bug #1477657: Snappy update fails because of hardcoded assets/vmlinuz <Snappy:New> <http://launchpad.net/bugs/1477657> | 15:49 |
| ubottu | bug 1477657 in Snappy "Snappy update fails because of hardcoded assets/vmlinuz" [Undecided,New] https://launchpad.net/bugs/1477657 | 15:49 |
| mvo | ogra_: there were some more issues with non-store device part updates, right ? longsleep is hitting some issue - or is the odroid oem in the store? | 15:50 |
| ogra_ | the latter | 15:51 |
| ogra_ | and no, updates in 15.04 should theoretically work, we never blocked them there | 15:51 |
| ogra_ | (practically it is a matter of the uboot setup ) | 15:52 |
| ogra_ | if they used to work they shoudl still do | 15:52 |
| longsleep | right - but my uboot setup is fine and stable updates with my released stuff from https://www.stdin.xyz/downloads/snappy/odroidc/ work | 15:53 |
| longsleep | (that is the same snap as in the store) | 15:53 |
| === chihchun is now known as chihchun_afk | ||
| elopio | mvo: nop: http://paste.ubuntu.com/11925776/ | 15:57 |
| ogra_ | lol | 15:57 |
| ogra_ | so now we have 3 different md5 sums for the same kernel | 15:57 |
| ogra_ | (... proposedly same kernel) | 15:58 |
| fgimenez | elopio, that's before the update + rollback, right? | 16:00 |
| elopio | fgimenez: yes, I've just flashed | 16:01 |
| elopio | with http://paste.ubuntu.com/11925790/ | 16:01 |
| * mvo gets dinner | 16:02 | |
| fgimenez | elopio, mine was after, i flashed the image with the normal --oem beagleblack | 16:03 |
| elopio | updating now... | 16:03 |
| Chipaca | why, oh why, has go decided that setsockopt is private? | 16:07 |
| Chipaca | :-( | 16:07 |
| ogra_ | fgimenez, yeah, i dont think that works, you cant use the current snap in the store with an image 3 rootfs | 16:07 |
| ogra_ | you would have to use the 1.8 version of it | 16:08 |
| ogra_ | http://people.canonical.com/~mvo/tmp/beagleblack_1.8_all.snap | 16:08 |
| fgimenez | ogra_, ok thx, i'll try that | 16:09 |
| fgimenez | ogra_, elopio btw i flashed the alpha #3 -image for the previous | 16:13 |
| fgimenez | release, a week or so ago | 16:14 |
| ogra_ | fgimenez, yes, but using the new oem snap from the store | 16:16 |
| longsleep | mvo: mhm even when i ship vmlinuz in my device tree it still fails with same error | 16:17 |
| elopio | so, I do snappy rollback ubuntu-core 3 | 16:17 |
| elopio | and I also have to rollback the beaglebone package, right? | 16:17 |
| elopio | or it will magically rollback? | 16:17 |
| ogra_ | no, you dont | 16:17 |
| ogra_ | it *should* be backwards compatible on upgrades | 16:17 |
| ogra_ | "should" | 16:17 |
| ogra_ | "should".... | 16:17 |
| elopio | let's see... | 16:17 |
| longsleep | (the folder also does contain a initrd.img and initrd.img-3.19.0.0-23-generic) | 16:18 |
| fgimenez | ogra_, ok, the oem snap was already the new one by then, thanks | 16:18 |
| ogra_ | longsleep, yeah, thats something still to fix on sergiusens plate ... we need the versioned binary to make system-image recognize there is a new binary | 16:18 |
| longsleep | ogra_: mhm i dont understand - the only thing which needs to happen is the change to the environment to try the update - isnt it? | 16:21 |
| ogra_ | longsleep, yeah, the versioned vmlinuz is unrelated to that | 16:22 |
| fgimenez | leaving, nice evening o/ | 16:22 |
| longsleep | ogra_: ok - so now i am stuck, seems like the update does require a vmlinuz file in /writable/cache/assets which i have no way to provide | 16:23 |
| elopio | nop, can't rollback. | 16:23 |
| elopio | now I get the same md5sums that fginther | 16:23 |
| ogra_ | elopio, los ? | 16:23 |
| ogra_ | *logs | 16:23 |
| elopio | sorry fginther. fgimenez left. | 16:24 |
| elopio | ogra_: on their way. | 16:24 |
| ogra_ | (serial specifically) | 16:24 |
| fginther | elopio, nw | 16:24 |
| mvo | elopio: same output as well, i.e. it tries to boot a/ (or b/) and then you return to the uboot prompt? | 16:29 |
| elopio | ogra_: mvo: http://people.ubuntu.com/~elopio/logs/bbb-rollback-alpha7-3.log.0 | 16:32 |
| elopio | mvo: yes. | 16:32 |
| ogra_ | sigh, why cant any browser open that inline | 16:34 |
| longsleep | mvo: so seems i am unable to do an automatic update, because of it not finding vmlinuz - i updated #1477657 accordingly | 16:35 |
| ogra_ | elopio, if you cp the b kernel to the a partition, does it work then (make a backup of the file in a first) | 16:37 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | mvo, elopio, hmmm, is that the cirrect uboot that is being used there ? | 16:41 |
| ogra_ | *correct | 16:41 |
| ogra_ | looks like the onboard one | 16:41 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| ogra_ | (iirc ours had a git hash in the version instead of -dirty, i could be wrong though) | 16:43 |
| elopio | ogra_: $ sudo cp /boot/uboot/b/VMLINUZ /boot/uboot/a/ ? | 16:44 |
| elopio | it starts booting on a | 16:44 |
| elopio | but it says LZMA data is corrupt | 16:44 |
| ogra_ | elopio, right, it starts and then resets itself and boots b | 16:44 |
| ogra_ | oh, you mena after the copy ? | 16:44 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | *mean | 16:45 |
| elopio | ogra_: yes, after copy. It doesn't reset. | 16:45 |
| ogra_ | ok, copy the initrd too | 16:45 |
| elopio | it's stuck waiting for root device ... system-a | 16:45 |
| ogra_ | the lzma error likely talks about the initrd | 16:45 |
| elopio | ogra_: emergency mode. | 16:50 |
| ogra_ | did it load the initrd before going there ? | 16:50 |
| elopio | ogra_: yes: http://people.ubuntu.com/~elopio/logs/bbb-rollback-alpha7-3-copying_b_kernel.log.0 | 16:53 |
| ogra_ | oh, why can my browser open this one inline but couldnt the former ... weird | 16:53 |
| ogra_ | elopio, ah, thats expected since you use a kernel that has no modules in that rootfs | 16:54 |
| ogra_ | so yeah, your a kernel *and* your a initrd were corrupt ... wow, thats really gross | 16:54 |
| ogra_ | rsalveti, ^^ | 16:55 |
| ogra_ | rsalveti, after upgrading from alpha 3 the original alpha3 kernel in /boot/uboot/a/ and the initrd get broken | 16:55 |
| * ogra_ scratches head | 17:00 | |
| longsleep | ogra_: after update, should i still have the old version on the "other" partition? | 17:00 |
| ogra_ | oh, meanwhile my 129 install upgraded in bg and asks me to reboot | 17:01 |
| * ogra_ does so | 17:01 | |
| longsleep | ogra_: nice - that is was failed for me because of bug #1477657 :( | 17:01 |
| nothal | Bug #1477657: Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz <Snappy:New> <http://launchpad.net/bugs/1477657> | 17:01 |
| ubottu | bug 1477657 in Snappy "Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz" [Undecided,New] https://launchpad.net/bugs/1477657 | 17:01 |
| ogra_ | longsleep, yeah, a should still have the install kernel and b the one for the new image | 17:02 |
| longsleep | ogra_: ok - so then i can confirm that update works fine when i set the uboot.env stuff manually | 17:03 |
| longsleep | i now have booted 130 and 129 on the other | 17:03 |
| longsleep | ogra_: so for you there is a vmlinuz in /writable/cache/assets/ ? | 17:04 |
| * longsleep wonders where this comes from | 17:04 | |
| ogra_ | Name Date Version Developer | 17:04 |
| ogra_ | ubuntu-core 2015-07-23 129 ubuntu* | 17:04 |
| ogra_ | ubuntu-core 2015-07-23 130 ubuntu! | 17:04 |
| * ogra_ curses | 17:04 | |
| longsleep | mhm - maybe your update also didnt set the env variables then | 17:05 |
| ogra_ | so it clearly boots from the b partition ... i see it mounting system-b during boot as readonly partition ... | 17:05 |
| ogra_ | but snappy thinks i'm still on 129 | 17:05 |
| longsleep | mhm thats strange | 17:05 |
| ogra_ | yes | 17:05 |
| ogra_ | snappy bug most likely | 17:05 |
| longsleep | mine says i am on 130 | 17:05 |
| longsleep | what does the exclamation mark mean? | 17:06 |
| longsleep | i am pretty sure it means something as mine does not have it | 17:06 |
| ogra_ | /dev/mmcblk0p3 on / type ext4 (ro,relatime,data=ordered) | 17:06 |
| ogra_ | definitely the b partition | 17:06 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ls /writable/cache/assets/ | 17:07 |
| ogra_ | initrd.img initrd.img-3.19.0-23-generic | 17:07 |
| ogra_ | no vmlinuz here | 17:07 |
| ogra_ | but i guess simply because we didnt update it (system-image strips it then) | 17:07 |
| longsleep | mhm - then maybe you have the same error but just didnt see it because you auto updated and i did it manually by calling snappy update ? | 17:08 |
| ogra_ | no | 17:08 |
| ogra_ | i called snappy update the second time | 17:08 |
| ogra_ | didnt change a thing | 17:08 |
| longsleep | mhm | 17:08 |
| ogra_ | it boots by default from b now | 17:08 |
| longsleep | ok | 17:08 |
| ogra_ | but snappy still thinks it is 129 | 17:08 |
| longsleep | what if you boot from a ? | 17:09 |
| ogra_ | hmpf | 17:11 |
| ogra_ | snappy rollback also only boots from b | 17:11 |
| * longsleep tries that | 17:12 | |
| longsleep | ogra_: yes confirmed - snappy rollback does not work for me either - still booted 130 / 129 now marked with ! | 17:14 |
| mvo | ogra_: what values do you have in /etc/system-image/channel.ini ? | 17:14 |
| mvo | ogra_: and /writable/cache/system//etc/system-image/channel.ini ? | 17:15 |
| ogra_ | http://paste.ubuntu.com/11926102/ | 17:15 |
| ogra_ | http://paste.ubuntu.com/11926112/ | 17:16 |
| ogra_ | writable has 130 | 17:16 |
| longsleep | added another bug #1477692 about the rollback issue | 17:19 |
| nothal | Bug #1477692: snappy rollback ubuntu-core does not change uboot.env <Snappy:New> <http://launchpad.net/bugs/1477692> | 17:19 |
| ubottu | bug 1477692 in Snappy "snappy rollback ubuntu-core does not change uboot.env" [Undecided,New] https://launchpad.net/bugs/1477692 | 17:19 |
| longsleep | is there a way to undo the rollback, unmark it somehow? | 17:20 |
| * ogra_ doesnt know | 17:20 | |
| ogra_ | this starts getting depressing :( | 17:21 |
| longsleep | do it like me, grab some cuba libre from the bar next door | 17:21 |
| ogra_ | no bars around me ... | 17:22 |
| ogra_ | (i live in an awkward place in an awful city :/ ) | 17:22 |
| longsleep | you should grab your laptop and go to a bar :P | 17:23 |
| ogra_ | well, the only bars kassel has are on the other side of the city | 17:23 |
| ogra_ | and are not exciting either ... | 17:23 |
| Chipaca | ogra_: longsleep: a manual update should undo the manual rollback | 17:25 |
| ogra_ | Chipaca, well, whatever i do it boots from b | 17:26 |
| ogra_ | neither update nor rollback change that | 17:26 |
| ogra_ | (i guess i could enforce it by setting the uboot vars directly though, but not via any snappy command it seems) | 17:26 |
| === JamesTai1 is now known as JamesTait | ||
| mvo | ogra_: that means the snappy output is correct its really in 129, what does fw_printenv |grep ^snappy show? | 17:26 |
| ogra_ | oh, wow, that works without sudo ! | 17:27 |
| ogra_ | mvo, everything as expected http://paste.ubuntu.com/11926167/ | 17:28 |
| mvo | ogra_: hm, except that it should be snappy_ab=a, no? | 17:28 |
| ogra_ | for 129, yes | 17:28 |
| ogra_ | for the state i'm in b is correct ... since it booted that | 17:28 |
| ogra_ | (but indeed 129 isnt then) | 17:29 |
| mvo | you are b with 129 but you actually want to be in a which is 130, do I understand that correctly? | 17:29 |
| ogra_ | no | 17:29 |
| ogra_ | b should be 130 | 17:29 |
| ogra_ | i got an auto upgrade and got asked to reboot | 17:29 |
| ogra_ | that properly booted to b ... but still shows 129 | 17:29 |
| mvo | what was b before? and a? | 17:30 |
| ogra_ | a was my original install of 129 | 17:30 |
| mvo | and now a is 130? | 17:30 |
| ogra_ | no idea, i cant boot to a | 17:30 |
| ogra_ | unless i hack the vars directly | 17:30 |
| ogra_ | (i guess, didnt try yet) | 17:30 |
| mvo | oh, hm, what does snappy set ubuntu-core active=130 give you? | 17:31 |
| mvo | with sudo | 17:31 |
| ogra_ | i installed 129 and booted to a ... then i got an auto update and was asked to reboot ... on reboot i see it booting to b proper ... but snappy list still shows i'm running 129 | 17:31 |
| ogra_ | nothing | 17:32 |
| ogra_ | =129 doesnt return anything either though ... | 17:32 |
| mvo | ok, let me look deeper, thanks! | 17:32 |
| ogra_ | just dumps me back to the shell prompt | 17:32 |
| longsleep | Chipaca: mhm snappy-update ubuntu-core does nothing | 17:33 |
| mvo | I think there is another missing piece | 17:34 |
| mvo | I'm on it | 17:34 |
| ogra_ | yeah | 17:34 |
| ogra_ | looks like | 17:34 |
| ogra_ | meanwhile i'll try to manually switch back to a to check potential corruption | 17:34 |
| ogra_ | yup, manually works fine | 17:36 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v | 17:37 |
| ogra_ | Name Date Version Developer | 17:37 |
| ogra_ | ubuntu-core 2015-07-23 130 ubuntu* | 17:37 |
| ogra_ | ubuntu-core 2015-07-23 129 ubuntu | 17:37 |
| ogra_ | after manual switch to a | 17:37 |
| longsleep | yes i did that too | 17:38 |
| ogra_ | so apparently a actually has 130 ... and b had 129 ... | 17:38 |
| longsleep | worked for me | 17:38 |
| ogra_ | for whatever weird reason | 17:38 |
| ogra_ | ok, snapy rollback doesnt roll me back | 17:39 |
| ogra_ | still boots a | 17:39 |
| longsleep | yes - me neither | 17:39 |
| ogra_ | but at least i dont have any coorruption here | 17:39 |
| longsleep | i am now stuck in this | 17:39 |
| longsleep | (ODROIDC)root@odroid:~# snappy list -v | 17:39 |
| longsleep | Name Date Version Developer | 17:39 |
| longsleep | ubuntu-core 2015-07-23 130 ubuntu* | 17:39 |
| longsleep | ubuntu-core 2015-07-23 129 ubuntu! | 17:39 |
| longsleep | odroidc 2015-07-23 0.3 * | 17:39 |
| longsleep | Reboot to use ubuntu-core version 129. | 17:39 |
| longsleep | cant seem to set it back to 130 | 17:39 |
| ogra_ | now ... why do we get corruption when switching from image 3 to the latest | 17:40 |
| longsleep | mhm - maybe the fat in 3 is already corrupted? | 17:40 |
| ogra_ | longsleep, yeah ... mvo is on it | 17:40 |
| ogra_ | longsleep, well, it isnt corrupted until you upgrade apparently | 17:41 |
| mvo | longsleep: I will have something ready RSN | 17:41 |
| mvo | Chipaca: will you be around for a review? | 17:41 |
| ogra_ | and the fat as a whole seems to be ok ... only the a directory contents are corrupted after upgrade | 17:41 |
| davmor2 | ogra_: not using a big enough hammer | 17:41 |
| ogra_ | davmor2, dude ... hammers all the way down here ... and from the sides too | 17:42 |
| ogra_ | no dice though | 17:42 |
| ogra_ | :) | 17:42 |
| mvo | ogra_: hm, if we still have corruption :( | 17:43 |
| ogra_ | mvo, i dont | 17:43 |
| ogra_ | mvo, federico and elopio do when coming from image 3 | 17:44 |
| longsleep | So, if you guys are interested in why i am working on the ODROID stuff with snappy - check out https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc | 17:44 |
| longsleep | just launched | 17:44 |
| ogra_ | mvo, the old kernel and initrd are trashed if you upgrade from old to now | 17:44 |
| ogra_ | i.e. from the snappy-system-txt way ... | 17:44 |
| mvo | ogra_: aha, only with the old uboot? thats ok | 17:45 |
| ogra_ | mvo, not really ok ... but yeah | 17:45 |
| ogra_ | there is no reason why the a subdir content should get corrupted | 17:45 |
| ogra_ | (b is fine) | 17:45 |
| ogra_ | it only breaks rollback though | 17:46 |
| === zyga-afk is now known as zyga | ||
| mvo | ogra_: could you please put http://people.canonical.com/~mvo/tmp/snappy_armhf onto your image as /usr/bin/snappy and see if that helps? | 17:46 |
| ogra_ | oh how i hate that we dont have wget on the image :P | 17:47 |
| mvo | Chipaca: https://code.launchpad.net/~mvo/snappy/15.04-snappy-more-uboot-fiddling if you have a moment should unblock ogra and I will a version in trunk thats nicer | 17:48 |
| ogra_ | mvo, rollback seems to work, update doesnt ... | 17:53 |
| ogra_ | though i might have confused the system with my manual switching before upgrading in the beginning | 17:54 |
| ogra_ | (by using fw_setenv for corruption tests) | 17:55 |
| ogra_ | why does snappy update always re-download 130 | 17:59 |
| * ogra_ considers a fresh flash of 129, i think i cinfused the system to much | 18:00 | |
| rsalveti | elopio: ogra_: usually when the kernel name is VMLINUZ instead of vmlinuz that means the fs got corrupted somehow | 18:05 |
| ogra_ | rsalveti, well, only the a directory | 18:06 |
| ogra_ | rsalveti, he can fix it by copying the b content to the a dir | 18:06 |
| ogra_ | well, "fix" ... it then fails to find the modules indeed | 18:06 |
| rsalveti | if you are coming from 3, that is expected, isn't it? | 18:08 |
| rsalveti | because it will still run fatwrite | 18:08 |
| ogra_ | rsalveti, fatwrite writes to the toplevel dir | 18:08 |
| rsalveti | still, that is the original behavior I had | 18:08 |
| ogra_ | rsalveti, the a dir shouldnt be touched at all | 18:08 |
| rsalveti | fsck was later touching everything | 18:08 |
| ogra_ | there was no fsck ... at least i didnt see it in the logs | 18:09 |
| rsalveti | the long file names were all renamed to match 8 chars | 18:09 |
| rsalveti | should be | 18:09 |
| rsalveti | during boot | 18:09 |
| ogra_ | well, erhaps i didnt see all logs | 18:09 |
| ogra_ | rsalveti, so not being able to roll back to 3 is acceptable ? | 18:09 |
| rsalveti | let me start fresh with image 3 | 18:09 |
| ogra_ | i wonder what happens for the next rollback then :/ | 18:10 |
| rsalveti | ogra_: right, we can't avoid that | 18:10 |
| rsalveti | because we can't update the bootloader | 18:10 |
| rsalveti | and the updater is not yet separated | 18:10 |
| ogra_ | well, people using fatwrite will go on doing so | 18:10 |
| ogra_ | while people installing freshly will get the new behavior | 18:10 |
| rsalveti | right, what we said is that we'd ask people to manually update the bootloader | 18:10 |
| rsalveti | at least for this release | 18:10 |
| rsalveti | while we can fix the remaining issues, like splitting the updater and making it able to upgrade the bootloader | 18:11 |
| ogra_ | k | 18:11 |
| mvo | Chipaca: and https://code.launchpad.net/~mvo/snappy/snappy-more-uboot-fiddling | 18:11 |
| mvo | ogra_: keep me updated, need to bring the kids to bed | 18:11 |
| ogra_ | all i'm worried about now is what happens if you upgrade from 4 to 5 or some such | 18:11 |
| mvo | ogra_: if the new snappy binary helps or not | 18:12 |
| ogra_ | mvo, will do ... i just created a new 129 image and wont touch the bootloader vars this time | 18:12 |
| ogra_ | mvo, rollback worked ... update didnt ... but i'm not sure thats not caused by my tinkering | 18:12 |
| mvo | ogra_: cool, you can also just copy uboot.env from e.g. the beagleblack 1.11 snap, saves some time :) | 18:12 |
| rsalveti | ogra_: did we publish 2 images for alpha? | 18:13 |
| mvo | ogra_: keep me updated if it updates the env vars etc, I will check back in some minutes | 18:13 |
| ogra_ | rsalveti, yes, i didnt notice that there were no amd64 builds | 18:13 |
| ogra_ | my fault, sorry | 18:13 |
| ogra_ | (amd64 only had one promotion) | 18:13 |
| rsalveti | oh, but only for amd64 | 18:13 |
| rsalveti | sorry, armhf | 18:13 |
| ogra_ | yes | 18:13 |
| rsalveti | would like to align the numbers if possible | 18:14 |
| ogra_ | to make sure we have the same content | 18:14 |
| ogra_ | hmm | 18:14 |
| rsalveti | otherwise this will create even more confusion | 18:14 |
| rsalveti | but I also wanted us to release another image to alpha | 18:14 |
| rsalveti | so we could test the upgrade from -1 to latest | 18:14 |
| ogra_ | yeah, but i'm not sure thats easily doable if we dont do an amd64 only build | 18:14 |
| rsalveti | to make sure the new logic will handle the next update without corruption | 18:14 |
| rsalveti | let's do one amd64 only build | 18:15 |
| ogra_ | (though i guess we can do that to get them in line again) | 18:15 |
| rsalveti | and do a build for both | 18:15 |
| ogra_ | will do once we're ready | 18:15 |
| ogra_ | there are still issues | 18:15 |
| rsalveti | ogra_: what are the current issues? | 18:15 |
| ogra_ | rsalveti, rollback not working | 18:15 |
| rsalveti | rollback from what? | 18:15 |
| ogra_ | (snappy rollback is a no-op) | 18:15 |
| rsalveti | 3->7->3? | 18:16 |
| rsalveti | that might indeed be a problem | 18:16 |
| ogra_ | yes :) | 18:16 |
| rsalveti | because since we're not creating the stamp anymore | 18:16 |
| ogra_ | mvo has a fix ... i'll test in a minute with a fresh 129 image | 18:16 |
| rsalveti | great | 18:16 |
| mvo | well still create the stamp if you start from 3, no? we do not change existing snappy-system.txt or uEnv.txt the new boot-assets are only applied on fresh u-d-f runs | 18:24 |
| mvo | of course, once a user manually flahes he/she can not go back | 18:24 |
| ogra_ | yeah, afaik | 18:24 |
| mvo | cool, so we are all aligned | 18:25 |
| ogra_ | ok, so i'm booted into 129 on partition a ... i did put snappy_armhf in place and am now updating | 18:26 |
| * ogra_ twiddles thumbs | 18:27 | |
| * ogra_ wonders why he gets to awful download rates | 18:28 | |
| ogra_ | mvo, hmm http://paste.ubuntu.com/11926470/ | 18:31 |
| ogra_ | (see the pre-last line) | 18:31 |
| rsalveti | isn't this the issue longsleep had? | 18:31 |
| ogra_ | bug #1477657 | 18:31 |
| nothal | Bug #1477657: Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz <Snappy:New> <http://launchpad.net/bugs/1477657> | 18:31 |
| ubottu | bug 1477657 in Snappy "Snappy update fails because of its looking for non existing /writable/cache/assets/vmlinuz" [Undecided,New] https://launchpad.net/bugs/1477657 | 18:31 |
| ogra_ | yes | 18:31 |
| ogra_ | anything i should capture before reboot ? | 18:32 |
| * ogra_ wnats to see if it at least boots to b now | 18:32 | |
| longsleep | ogra_: ah - thats a relief you see that issue too | 18:33 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ls /writable/cache/assets/ | 18:33 |
| ogra_ | initrd.img initrd.img-3.19.0-23-generic | 18:33 |
| ogra_ | and it is correct :) | 18:33 |
| * ogra_ reboots anyway | 18:34 | |
| longsleep | will not boot to the one it just updated as the env file was not updated | 18:34 |
| ogra_ | yay | 18:34 |
| ogra_ | boots from b | 18:34 |
| longsleep | oh | 18:34 |
| longsleep | then something was fixed? | 18:34 |
| ogra_ | well, i'm testing mvo's new snappy binary from above | 18:34 |
| longsleep | ah i see | 18:35 |
| longsleep | that makes sense | 18:35 |
| longsleep | so the error is no error and only a warning | 18:35 |
| ogra_ | well, it might be an error ... the bootloader config is updated before though ... see my paste | 18:35 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v | 18:36 |
| ogra_ | Name Date Version Developer | 18:36 |
| ogra_ | ubuntu-core 2015-07-23 130 ubuntu* | 18:36 |
| ogra_ | ubuntu-core 2015-07-23 129 ubuntu | 18:36 |
| ogra_ | yay | 18:36 |
| ogra_ | now lets see rollback | 18:36 |
| * longsleep cheers | 18:36 | |
| rsalveti | great | 18:36 |
| ogra_ | nope ... | 18:36 |
| ogra_ | still boots from b | 18:37 |
| ogra_ | oh ! | 18:37 |
| ogra_ | wait :P | 18:37 |
| rsalveti | did it work? | 18:37 |
| ogra_ | i replaces snappy with the new binary on a but not on b | 18:37 |
| ogra_ | rsalveti, no | 18:37 |
| rsalveti | sigh | 18:37 |
| ogra_ | but the b partition has the wrong snappy binary | 18:37 |
| ogra_ | once cloud-init is done and i can log in i'll try again | 18:38 |
| ogra_ | *twiddle* | 18:38 |
| ogra_ | YAY | 18:39 |
| ogra_ | works | 18:39 |
| ogra_ | rollback gets me back to a now | 18:39 |
| * ogra_ will try that a few times to be sure | 18:39 | |
| ogra_ | sigh ... cloud-init ... | 18:40 |
| ogra_ | another minute of wasted worktime | 18:40 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v | 18:41 |
| ogra_ | Name Date Version Developer | 18:41 |
| ogra_ | ubuntu-core 2015-07-23 129 ubuntu* | 18:41 |
| ogra_ | ubuntu-core 2015-07-23 130 ubuntu | 18:41 |
| * ogra_ snappy updates again | 18:41 | |
| ogra_ | properly boots b | 18:42 |
| hio_ | hey, i don't understand snappy. does it replace the old ubuntu completely? | 18:43 |
| hio_ | will in the future all software on ubuntu be packaged as snappy? | 18:44 |
| ogra_ | no, it will be developed in parallel | 18:44 |
| hio_ | ok but in the future? | 18:44 |
| ogra_ | somce new variants will only be available as snappy though | 18:44 |
| hio_ | and i can have snappy installed on an old ubuntu? | 18:44 |
| ogra_ | snappy is a special installation variant ... a special package manager and essentially a lot more ... you cant just install it on a deb based ubuntu. no | 18:45 |
| hio_ | does snappy have a graphical desktop? can i use it as a desktop machine? | 18:46 |
| ogra_ | (snappy systems also dont have dpkg or apt ) | 18:46 |
| hio_ | but i thought it was developed in parallel? | 18:46 |
| ogra_ | there will be snappy variants with graphical desktop, yes | 18:46 |
| ogra_ | mvo, all fine, get your MP in ! | 18:47 |
| hio_ | so for example, if i use snappy on my server right now and i need a specific package for my code to compile, maybe there won't be a snappy version yet and it won't work? | 18:47 |
| * ogra_ has done 5 update/rollback cycles now ... no more issues | 18:47 | |
| ogra_ | hio_, for that there is a special tool in development that will bundle your deb packages for a project into a snap that you can install (or upload to the ubuntu store to provide it to others) | 18:48 |
| ogra_ | rsalveti, ^^ with mvo's MP all is fine here ... update/rollback between edge 129/1330 works fine for me | 18:49 |
| ogra_ | *130 | 18:49 |
| hio_ | what relation does it have to docker? none? | 18:49 |
| ogra_ | you can use docker pretty easily with it | 18:49 |
| ogra_ | there is already a docker framework in the store you can use | 18:49 |
| mvo | ogra_: \o/ thank you so much for the testing | 18:49 |
| hio_ | docker would be a mother layer on top of it ok, good | 18:50 |
| hio_ | another* | 18:50 |
| ogra_ | mvo, i still feel a bit uncomfortable that people going on to use the fatwrite stuff will get corruption | 18:50 |
| mvo | now someone just needs to review :) | 18:50 |
| ogra_ | but i guess there is not much we can do | 18:50 |
| rsalveti | ogra_: that's great | 18:50 |
| hio_ | ok how far long is the development? should i use it right now as my server ? | 18:50 |
| rsalveti | yeah | 18:50 |
| mvo | ogra_: we could auto-migrate them, but then there is really no rollback (automigrate via custom boot script) | 18:51 |
| mvo | but thats very scary | 18:51 |
| rsalveti | hio_: depends on what you want to run as your workload | 18:51 |
| rsalveti | you can run docker containers or you can create services that could be provided by a snap | 18:51 |
| hio_ | a java webserver | 18:51 |
| rsalveti | and push that in our store | 18:51 |
| ogra_ | mvo, well, and indeed super dangerous to dd to the disk ... if power fails that moment you are completely bricked | 18:51 |
| hio_ | i don't want to push things into the store, i might want my own store though | 18:52 |
| hio_ | can i create my own snappy repo? | 18:52 |
| ogra_ | no | 18:52 |
| rsalveti | at least not yet | 18:52 |
| ogra_ | you can set up a push service that sideloads the snaps | 18:52 |
| rsalveti | there is an idea of having private store | 18:52 |
| ogra_ | yeah | 18:53 |
| ogra_ | which is essentially just a sub-store of the official store then | 18:53 |
| hio_ | i don't want it to be online, its in my own LAN | 18:53 |
| ogra_ | right, then you can script something that pushes snaps via ssh | 18:53 |
| rsalveti | then for now you could create the snap and just sideload it | 18:53 |
| hio_ | what exactly do you mean by "sideload"? i assume theres still just a simple cmdline so i can install my own snappy packages | 18:54 |
| rsalveti | yeah, once you create it, you can install it locally or even remotely | 18:54 |
| rsalveti | with snappy-remote | 18:54 |
| hio_ | ok good | 18:54 |
| ogra_ | there is either a commandline or a remote tool | 18:54 |
| rsalveti | sideloaded means it's not coming from the store | 18:55 |
| ogra_ | right | 18:55 |
| rsalveti | ogra_: will you take care of the reviews? | 18:55 |
| ogra_ | rsalveti, of go code ? ... | 18:56 |
| rsalveti | ogra_: at least check if the logic is fine in there | 18:56 |
| ogra_ | i can do that but cant give any guarantees if what i say makes even sense | 18:56 |
| rsalveti | let me take a look as well | 18:56 |
| rsalveti | https://code.launchpad.net/~mvo/snappy/snappy-more-uboot-fiddling/+merge/265715 | 18:56 |
| rsalveti | right? | 18:56 |
| ogra_ | looks like | 18:57 |
| ogra_ | by the timestamp | 18:57 |
| ogra_ | bah, thats big | 18:57 |
| ogra_ | i'm not sure my judgement is helpful, it looks ok to me (and well, i just ran the binary and it worked :P ) | 18:58 |
| ogra_ | approved | 19:01 |
| * longsleep is leaving for the night - check out our kickstarter bringing a Spreed hardware device powered by Snappy: https://www.kickstarter.com/projects/spreed/spreedbox-the-most-private-video-chat-and-file-exc | 19:04 | |
| longsleep | (sorry for the spam) :) | 19:04 |
| ogra_ | longsleep, dude ... i have quite a bunch of G+ followers, you need to ppaste such a thing earlier ! | 19:04 |
| longsleep | well it just started - there are 29 days to go | 19:05 |
| longsleep | any sharing would be very nice :) | 19:05 |
| ogra_ | yeah, no prob | 19:06 |
| longsleep | cool thanks - see you tomorrow | 19:06 |
| ogra_ | director of bits and bytes ... heh | 19:06 |
| ogra_ | do you have that on your business card too ? :) | 19:06 |
| longsleep | only the first part | 19:07 |
| longsleep | no idea where that came from :P | 19:07 |
| ogra_ | heh | 19:07 |
| * rsalveti waits mr to land before triggering a new image | 19:41 | |
| rsalveti | webdm failed to install: Get https://myapps.developer.ubuntu.com/site_media/appmedia/2015/04/ubuntu.png: EOF | 19:41 |
| rsalveti | wat | 19:41 |
| mvo | yay | 19:52 |
| * mvo looks forward for the new image | 19:52 | |
| Chipaca | mvo: still needing that review? | 20:35 |
| mvo | Chipaca: looks like rsalveti already did it, so all good :) tomorrow is enough | 20:38 |
| mvo | and we almost have a new image | 20:38 |
| rsalveti | yeah, image 131 is currently being imported | 20:38 |
| rsalveti | then will migrate to alpha and test it a bit more | 20:38 |
| mvo | yay | 20:38 |
| rsalveti | and maybe, hopefully, we can release it tomorrow | 20:39 |
| mvo | *fingerscrossed* | 20:39 |
| rsalveti | image 131 seems to be out | 20:52 |
| * ogra_ waits for 130 to tell him about the auto update :) | 20:53 | |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v|tail -1 | 21:07 |
| ogra_ | Reboot to use the new ubuntu-core. | 21:07 |
| ogra_ | :D | 21:07 |
| ogra_ | auto updated ... | 21:07 |
| * ogra_ reboots | 21:07 | |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v | 21:09 |
| ogra_ | Name Date Version Developer | 21:09 |
| ogra_ | ubuntu-core 2015-07-23 131 ubuntu* | 21:09 |
| ogra_ | ubuntu-core 2015-07-23 130 ubuntu | 21:09 |
| ogra_ | :D | 21:09 |
| * ogra_ tries a rollback | 21:09 | |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ snappy list -v | 21:12 |
| ogra_ | Name Date Version Developer | 21:12 |
| ogra_ | ubuntu-core 2015-07-23 130 ubuntu* | 21:12 |
| ogra_ | ubuntu-core 2015-07-23 131 ubuntu | 21:12 |
| ogra_ | looks good | 21:12 |
| ogra_ | rsalveti, looks all good over here | 21:15 |
| ogra_ | rollback and update work, no corruption | 21:15 |
| rsalveti | great, let me promote to alpha then | 21:16 |
| ogra_ | +1 | 21:17 |
| ogra_ | rsalveti, oh, wait | 21:17 |
| rsalveti | what now? :-) | 21:17 |
| ogra_ | didnt we want an amd64 only buuld first ? | 21:17 |
| ogra_ | *build | 21:17 |
| rsalveti | already did that | 21:17 |
| ogra_ | oh, heh | 21:18 |
| ogra_ | well, then go for it ... the copy-image should still be in cdimages history | 21:18 |
| rsalveti | alright, copied for armhf | 21:19 |
| rsalveti | copying for amd64 | 21:19 |
| ogra_ | yay | 21:19 |
| rsalveti | done, image 8 is the latest edge | 21:19 |
| rsalveti | now let me flash image 3 first :-) | 21:20 |
| ogra_ | dont try to roll back :P | 21:20 |
| rsalveti | :-) | 21:21 |
| ricmm | stop breaking everything guys | 21:24 |
| ricmm | geez | 21:24 |
| ogra_ | ricmm, it was broken already | 21:26 |
| * ogra_ blames microsoft ... for inventing vfat | 21:28 | |
| rsalveti | ogra_: crap, need to use 3 with the sideloaded oem snap | 21:31 |
| ogra_ | yeah | 21:31 |
| rsalveti | do you have the link for that in hands? | 21:31 |
| rsalveti | oh cloud-init | 21:31 |
| ogra_ | rsalveti, http://people.canonical.com/~mvo/tmp/beagleblack_1.8_all.snap | 21:31 |
| * rsalveti kicks it | 21:31 | |
| rsalveti | thanks | 21:31 |
| rsalveti | Signature verification failed | 21:33 |
| rsalveti | ogra_: how to skip that? | 21:33 |
| ogra_ | --developer-mode | 21:33 |
| rsalveti | haha, alright | 21:34 |
| ogra_ | :) | 21:34 |
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
