/srv/irclogs.ubuntu.com/2015/08/25/#snappy.txt

=== erkules_ is now known as erkules
=== bigcat is now known as bigcat[otp]
=== bigcat[otp] is now known as bigcat
=== chihchun_afk is now known as chihchun
elopiopitti: ping. I think I have a test that is taking long to reboot. But there's no way to increase the reboot timeout in adt-run, right?06:55
pittielopio: no, not right now; mind filing a bug for this?06:58
elopiopitti: sure.06:58
elopiopitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/148835807:02
ubottuLaunchpad bug 1488358 in autopkgtest (Ubuntu) "Can't increase the reboot timeout" [Undecided,New]07:03
elopiomvo: could you look into https://bugs.launchpad.net/snappy/+bug/1488186 ?07:04
ubottuLaunchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [Undecided,New]07:04
elopioit's causing like 50% of the failures in jenkins.07:04
=== chihchun is now known as chihchun_afk
* elopio goes to bed. See you tomorrow.07:07
mvohey elopio, sure, I have a look07:16
mvoelopio: sleep well07:16
mvoppisati: hey, for later (no rush) I would love to hear your opinion on https://bugs.launchpad.net/snappy/+bug/1480248 and if it needs to be re-assigned to the kernel or something else07:17
ubottuLaunchpad bug 1480248 in Snappy "automatic reboot fails with zero size initrd in bbb" [Critical,Triaged]07:17
ppisatimvo: so the actual bug is that it hangs there instead of panicing07:21
ppisatimvo: weird, let me see07:21
pittielopio: asked some questions in the bug07:34
ppisatimvo: why the watchdog doesn't kick in and reboot the board?07:40
mvoppisati: AFAIK we don't use the watchdog, how can we enable it, that would be a nice fix indeed07:42
ppisatimvo: that should be enabled in uboot07:43
mvoppisati: I have the board in this state sitting on my desk if you want me to test anything07:43
ppisatimvo: so if we don't reach the userspace in 60secs, it reboots the board07:43
ppisatimvo: so, i did a couple of tests07:43
mvoppisati: nice, is that a uboot config option or code?07:43
ppisatimvo: yep07:43
ppisatimvo: let me do a couple more checks and i'll comment in the lp bug07:43
mvogreat, thanks07:44
* ppisati needs more coffee first07:44
mvoelopio: I debug the issue a bit but so far nothing conclusive, maybe worth trying to run a curl test on the jenkins server (see bugreport)07:55
beowulfmvo: I commented on #1480404, i think both front and backend need work08:59
mvota09:02
ogra_ppisati, hmm, why in u-boot ? i thought thats a kernel feature09:03
Chipacaogra_: i guess it needs enabling from kernel commandline to be useful?09:07
* Chipaca guesses09:07
ogra_well, we have panic=-1 by default there09:07
ogra_panic=[KNL] Kernel behaviour on panic: delay <timeout>09:08
ogra_...09:08
ogra_timeout < 0: reboot immediately09:08
ogra_... is what the kernel docs say09:08
ppisatiogra_: i didn't look at the option for the watchdog on the cmdline09:14
ogra_well, we dont set nmi_watchdog=109:14
ppisatiogra_: but AFAIK a userspace sw open /dev/watchdog09:14
ogra_but we do set panic=-109:15
ppisatiogra_: and have to reopen it before TIMEOUT expires09:15
ogra_which shoud make the kernel reboot i think09:15
ppisatietc09:15
ppisatiogra_: moreover, what happens if thekernel hangs before the wdt is enabled?09:15
ppisatithe correct init should be:09:15
ppisatiuboot sets the wdt to X and start booting the board09:16
ogra_i thought the nmi_watchdog is kernel only09:16
ppisatikernel takes over and, either reach usrspace (and wdt is reset)09:16
ppisatior uboot settings reset the board09:16
ogra_BOOTPARAM_SOFTLOCKUP_PANIC and BOOTPARAM_HARDLOCKUP_PANIC shoudl provide that if i can belive the docs09:17
ppisatianyhow, i spent the morning looking at uboot09:17
ppisatiand it seems the wdt is not supported there09:17
ogra_ppisati, but why does the normal panic option not kick in here ?09:19
ppisatiogra_: nmi_watchdog?09:19
ogra_no, we dont have that on currently09:19
ogra_just the normal panic= stuff09:19
ppisatiand it's x86 only09:20
ppisatinmi_watchdog=   [KNL,BUGS=X86]09:20
ppisatihe sayd he doesn't get any panic09:20
ogra_oh, right09:20
ogra_damn09:20
ppisatijust hangs there09:20
ogra_oh, i see why :P09:20
ogra_ Waiting for root device /dev/disk/by-label/system-b...09:20
ogra_no udev ... no /dev/disk/by-label/system-b ...09:21
ogra_the kernel itself doesnt set these links09:21
mvoyeah, thats the symptom, but why does it not complain if initrd.img is invalid?09:21
ppisatido we pass rootwait?09:22
ogra_depends on the board09:22
ppisatimvo: it doesn't get the initrd at all09:22
ogra_if it is in the default env we dont wipe it09:22
ogra_we dont add it explicitly iirc09:22
ppisatimvo: if you pass a malformed initrd, like 1 byte, it says "bad format" or something09:22
ppisatimvo: but it doesn't panic there either09:22
ogra_i guess we could add a check to uboot (and switch system_ab based on it)09:23
ppisatiwhat really bugs me is that uboot says "watchdog enabled" but i can't fucking get that thing to work09:23
ppisatiand IMO it doesn't09:23
ogra_i.e. look up the size and make sure it isnt zero after loading the initrd09:24
ogra_but technically having the kernel fall over would be cleaner09:24
ogra_is there any kernel option for "dont boot without initrd" ?09:25
ppisatinot that i am aware09:26
ppisatimvo: do you have the rootwait option?09:26
ppisatimvo: on the cmdline i mean09:26
mvoppisati: yes, "Kernel command line: console=ttyO0,115200n8 root=/dev/disk/by-label/system-b init=/lib/systemd/systemd ro panic=-1 fixrtc rootfstype=ext4 rootwait"09:27
ppisatiok09:27
ppisatiquick test09:27
ogra_bah, why do we set rootfstype09:27
ppisati   /* wait for any asynchronous scanning to complete */09:27
ppisati    if ((ROOT_DEV == 0) && root_wait) {09:27
ppisati        printk(KERN_INFO "Waiting for root device %s...\n",09:27
ppisati            saved_root_name);09:27
ppisati...09:27
ppisatiif loops there waiting for tghe rootdevice if root_wait = true09:27
ogra_yeah09:27
ppisatican you try to take that option out?09:28
ogra_neither rootfstype nor rootwait should be set09:28
ogra_thats comeing from the default env for the BBB09:28
ogra_mvo, hmm, can it be that our bbb changes never actually landed in snappy-hub/snappy-systems ?10:15
mvoogra_: I certainly send a MP10:16
mvoogra_: but I haven't tracked (due to sprints/confs) if it actually landed :/10:16
ogra_https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/26497510:16
* ogra_ approves10:16
ogra_(hopin thats the actual code we used for the last image :P )10:16
ogra_line 90 is the issue for the bog above10:17
ogra_*bug10:18
Chipacaelopio: question: is there a reason _integration-tests/bin/ and _integration-tests/data/output aren't in bzrignore?10:21
mvoogra_: thanks, branch updated10:21
mvoogra_: cool, so if I remove the rootwait it will work?10:22
mvoogra_: as a quick test?10:22
ogra_mvo, you should test it, but it is very likely, yes10:22
mvoogra_: does that also fixes the "1" byte file initrd.img ? or is that a separate bug ?10:22
* mvo tests once that bbb finishes booting10:23
ogra_just intercept the boot in uboot and set mmcrootfstype to nothing or just to ext4 or so10:23
ogra_the 1byte initrd will also try to fall back to mount root= directly ... (and fail) the outcome should be the same10:23
mvoogra_: cool, I set this now via fw_setenv and see what happens10:24
ogra_+110:24
mvonice panic10:24
ogra_and reboot too ?10:24
mvoyes10:25
ogra_yay !10:25
ogra_awesome10:25
mvoI try the one byte file now just for good measure10:25
ogra_yeah10:26
mvoogra_: I assume you are on the updated snappy-systems branch?10:26
ogra_i would be surpised if it wouldnt do the same10:26
ogra_i dont have my BBB powered/wired up atm ...10:26
ogra_the Rpi is (on a local copy, since we dont have the Pi upstream)10:26
mvoogra_: ok, I can work on the branch if you want, just don't want to dupliicate work :)10:27
ogra_ah, k10:27
mvosame for 1 byte10:27
ogra_yay10:27
ogra_ppisati, ^^^ all fine then10:27
ppisatiogra_: cool, but i still want to understand why the f*ck watchdog didn't reboot from uboot10:31
Chipaca15.04 is go 1.3, right?10:32
mvoyes10:32
mvoogra_: https://code.launchpad.net/~mvo/snappy-hub/lp1480248-norootwait/+merge/26903210:33
ogra_mvo, approved10:34
mvoogra_: I'm doing a final test with a good initrd.img (takes forever because of the sync mount option)10:34
mvoogra_: thanks10:34
ogra_the sync mount option ?10:35
mvoogra_: I copied the good initrd back and that cp takes a long time10:35
mvoogra_: because we mount /boot sync10:35
ogra_ah, right10:35
mvoogra_: but all good, booted fine from b10:35
ogra_i thought the boot takes forever :)10:35
Chipacarsalveti: you around?10:38
* ogra_ is afk for a bit (need to get a new laptop for susie ... her lenovo blew up the DC board last night ... out of the blue ... a month after the warranty is gone ... crap HW...)10:44
* mvo tests bbb update snap10:49
mvosomeone will need to approve my updated bbb snap11:04
* mvo gets lunch first11:04
rickspencer3hi all, snappy-remote keeps timing out on me11:58
rickspencer3any ideas? I can easily ssh right into the BBB11:59
MikaelaI am unfamiliar with snappy-remote but if it has something to do with GitHub they are mitigating DDoS attack and restoring service which causes git pulls etc. to fail for me unrelated to snappy.12:00
rickspencer3Mikaela, thanks for your answer, that is interesting12:01
rickspencer3but, snappy-remote is just a wrapper around ssh, I think, to push and install your snap package12:01
rickspencer3it looks like it is trying to do some kind of key exchange that is failing12:02
ogra_rickspencer3, using an IP or webdm.local ?12:02
rickspencer3ogra_,  webdm.local12:02
ogra_and ssh to webdm.local works from the same machine ?12:02
* rickspencer3 tries with straight ip12:05
rickspencer3ogra_, ssh works fine, yeah (using webdm.local)12:05
rickspencer3and using the ip address with snappy remote worked fined as well12:06
ogra_aha12:06
rickspencer3I assume that I need to grant permissions for the snap to use the gpio pins?12:06
ogra_you most likely need to grant access to teh respectiver /dev node with hw-assign12:07
rickspencer3ogra_, is there a place where I can look up how to do that?12:07
ogra_the webcam tutorial ...12:08
ogra_https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/12:08
ogra_you should actually see complaints in syslog about device access12:08
rickspencer3ogra_, does this tell me how to use hw-assign?12:29
rickspencer3nm, I figured it out12:32
ogra_:)12:32
mvoogra_: is lp #1429749 sill a issue? i.e. that the rpi2 is not updating ? aiui this was only a problem with early rpi2 images, right?12:53
ubottuLaunchpad bug 1429749 in Snappy trunk "Ubuntu Core updated but not switch to new version after reboot on Raspberry Pi 2" [Undecided,New] https://launchpad.net/bugs/142974912:53
rickspencer3is there a Go library for gpio that is known to work with BBB and snappy?12:53
sergiusenshello hello13:06
* sergiusens is in back to normal mode13:07
mvohey sergiusens, good monring!13:09
mvosergiusens: do you happen to know if we have a branch for snappy remote 0.4 somewhere?13:09
mvosergiusens: I was looking into a issue that rickspencer3 reported earlier about slow webdm.local resolving13:10
sergiusensmvo: how is it related to snappy remote?13:10
sergiusensmvo: snappy-remote just uses avahi indirectly when using ssh13:11
sergiusensmvo: you probably want to up the broadcast of IPs in webdm itself, I think13:11
mvosergiusens:  I wanted to check what snappy-remote is doing and if we could cache the ip there for example13:11
sergiusensmvo: oh, it's just using 'ssh'13:11
mvosergiusens: aha, that sounds like a better suggestions, thanks13:11
mvosergiusens: yeah, I found the source for 0.3 but was wondering if 0.4 has changed anything, looks like bzr might need a bzr push with the latest changes :)13:12
mvo(or I looked at the wrong branch :/)13:12
sergiusensmvo: yeah, I might have forgotten to push and I'll need to power up my older laptop to get it :-/13:12
sergiusenswill do in a bit; the 0.4 thing only does some key magic13:13
mvono worries, I can manually import from the deb if its trouble to find the old laptop13:13
mvoogra_, ppisati: bug #1458866 is another one of the failover robustness that would be nice to get input on. this time its about a correpted dtb. could we do something smart if snappy_mode is try and it fails to read the dtb?13:48
nothalBug #1458866: hangs in uboot boot prompt if dtbs dir is missing <Snappy:New> <http://launchpad.net/bugs/1458866>13:48
ubottubug 1458866 in Snappy "hangs in uboot boot prompt if dtbs dir is missing" [Undecided,New] https://launchpad.net/bugs/145886613:48
mvolool: re bug #1459755 - could we simply unconditionally enable serail grub in our generic-amd64 snap? or is there a downside to this?13:58
nothalBug #1459755: Need a way to drive GRUB over serial port <Snappy:New> <http://launchpad.net/bugs/1459755>13:58
ubottubug 1459755 in Snappy "Need a way to drive GRUB over serial port" [Undecided,New] https://launchpad.net/bugs/145975513:58
mvoelopio: hi, can we get click-reviewers-tools in the testbed? this triggered a issue in the intergration tests that caused the test failure for the snappy-review-tools-reneable branch14:39
mvoppisati, ogra_: I subscribed you to some more of the failover bugs, would be nice to get your input (not urgent though)14:52
ogra_sergiusens, any idea why azure needs rootwait ? that shouldnt be necessary (and is usually unused, since the initrd handled waiting itself)14:52
ogra_*handles14:52
ogra_do the azure images have a special initrd or some such ?14:53
sergiusensogra_: iirc, rsalveti added it14:53
ogra_right, but why ?14:54
ogra_rootwait is only helpful when booting without initrd ... and in our case it is actually harmful :)14:54
rsalvetiogra_: azure needs it14:54
rsalvetibecause of azure :-)14:54
rsalvetior better, because of reasons14:54
sergiusensogra_: ah, it's in there docs14:54
ogra_lol14:54
sergiusensas a requirement14:54
ogra_i dont get that14:55
ogra_it should be a total no-op if you use an initrd14:55
ogra_(apart from breaking our auto-panic )14:55
ogra_do we have any azure devs we could ask ?14:56
ogra_for $reasons14:56
rsalvetiogra_: check our priv channel14:56
ogra_ah, i need to re-loacate14:56
* ogra_ goes to the office14:56
elopiomvo: we could, but it's always hard to install things in snappy. We could copy the python script, or we could make a snap. But did you see my comment here?14:58
elopiohttps://code.launchpad.net/~mvo/snappy/snappy-review-tools-reenable/+merge/264301/comments/67631714:58
mvoelopio: aha, ok, sorry, I didn't - brain was in quick triage mode apparently :/14:59
elopiomvo: wow, you triaged the world. Thanks!15:01
davmor2elopio: don't make it sound like such a chore,  it's easy, "The World" is broken, global warming, war, deforestation, over heating, yellowstone get more active, the list goes on ;)15:06
elopiodavmor2: snappying the world it's such a chore.15:45
elopiobarry: we started getting this error: https://bugs.launchpad.net/snappy/+bug/148818615:45
ubottuLaunchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [High,Triaged]15:45
elopiobarry: any idea what could cause it?15:45
barryelopio: i don't.  i'll subscribe to the bug, but it seems like it's a lower level tls problem.  is the server perhaps load balanced and maybe there's a problem there?15:48
elopiobarry: who manages the server? I'm not sure whom to ask about that.15:48
barryelopio: probably is, but slangasek has access15:50
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
slangasekelopio, barry: I don't have any access to the web frontends; that's IS-managed16:02
mvoelopio: I guess a rt ticket is the best way forward at this point16:09
elopiomvo: ok, on it.16:11
elopioChipaca: we wanted to move _integration-tests/bin/ and _integration-tests/data/output out of the tree, but didn't get to it yet.16:12
elopioa .bzrignore in the mean time seems appropriate.16:12
ogra_ricmm_, how do you resize the partition on the kvm image ... seems gparted doesnt like it16:25
ricmm_ogra_: gparted offers to fix the partition table header for you16:25
ricmm_then it shows fine as unallocated space16:25
ogra_hmm, doesnt here16:26
ricmm_then sfdisk actually does the job correctly when doing 2.2616:26
ricmm_didnt offer you to fix?16:26
ricmm_I appended zeros to the image file first16:26
ogra_ah, i was trying to shrink writable16:26
ricmm_so I'm trying right now with flashing the image as-is (4G) onto flash and see if that works16:27
ricmm_or if theres the same error as on kvm16:27
ogra_i'd expect the same error with the old sfdisk16:28
ogra_ricmm_, hmm, no errors on rolling ... but no resize either16:32
ogra_http://paste.ubuntu.com/12193628/16:33
* ogra_ appends moar zeros16:34
ogra_hmm, it sees that the disk grew bigger16:36
ricmm_ogra_: it gret 1.3 MB for you16:37
ricmm_yet you had added 500M of zeros16:37
ricmm_mmm16:37
ogra_i added another GB16:37
ogra_and it properly sees the device is 5GB now16:38
ogra_but it doesnt resize16:38
ogra_(doesnt error either)16:38
elopioChipaca: https://code.launchpad.net/~elopio/snappy/bzr_ignore_integration_output/+merge/26909516:44
ricmm_ogra_: hmmm it worked for me16:53
ricmm_did you open it with gparted at some point?16:53
ogra_no16:53
ricmm_open it with gparted, lets try to understand what kind of fix that is doing16:53
ogra_i added 1.5G16:53
ricmm_it will offer to "fix" the partitioning16:53
ricmm_yea but added it how16:53
ricmm_just appending zeros?16:53
ogra_dd16:54
ogra_yeah16:54
ogra_dd oflag=append conv=notrunc if=/dev/zero of=kvm-rolling.img bs=1MB count=100016:54
ogra_and before the same with 50016:54
ogra_now i'm in an initrd shell ...16:54
ricmm_lol16:54
ogra_trying sfdisk there manually say the GPT is damaged and will be fixed on next write ...16:54
ricmm_yea wily didnt boot for me on real hw16:55
ricmm_right, thats the error that gparted fixes16:55
ogra_(on purpose, i added break=premount to the cmdlijne)16:55
ogra_well, but sfdisk tells me it will fix it on next write ... i tried to write it but that didnt help it seems16:55
ogra_hmm16:55
ogra_perhaps i need a reboot or re-read the partition table at the kernel level16:55
ogra_hmm, nope16:56
ogra_blockdev --rereadpt doesnt change a thing16:56
ogra_sigh16:59
ogra_i dont think there is a way around using parted17:00
ogra_slangasek, do you happen to have any idea about teaching sfdisk about GPT ? (it works fine for all MBR based images just not for the amd64 one now)17:00
ogra_well, not teaching it about it but making it repair the GPT to make it possible to resize the writable partition17:01
ricmm_ogra_: sfdisk knows GPT17:05
ricmm_thats not the problem17:05
ogra_yes17:05
ogra_thats why i wrote the second line :)17:05
ricmm_the problem is that when cloning disk images like this the secondary GPT header (footer) is misaligned17:05
ricmm_its not at the physical end of disk17:05
elopiokyrofa: nice video. Did you publish the source for your snap somewhere?17:05
ogra_right17:05
ricmm_ogra_: parted can fix this I think but there should be an easier way to do so for GPT17:05
ricmm_maybe we can teach sfdisk to do so17:05
ricmm_:)17:05
kyrofaelopio, thanks! Yeah, it's here: https://github.com/kyrofa/piglowtop17:06
kyrofaelopio, for snappy-specific stuff, see the snappy readme (meta/readme)17:06
ogra_well, sfdisk even *tells* me it will fix it "on next w(rite)"17:06
ogra_but it seemingly doesnt17:06
elopiokyrofa: thanks!17:06
ricmm_ogra_: but did it do an actual write? how about read the partition as-is then write it again17:06
ricmm_it might realign it to end of disk17:06
ogra_oh damn !17:08
ogra_i'm blind17:08
ogra_so after printing a lot of info when i do the write ... it then says "use gparted to correct the GPT errors"17:08
ogra_i missed that :P17:08
ogra_sigh17:09
ogra_so that silly GPT stuff will make me re-write the whole thing then :((( to use parted and bloat the initrd17:10
ricmm_well not necesarily17:10
ricmm_we can try to understand what gparted is doing to fix the stuff17:10
ricmm_and just teach sfdisk about it17:10
ricmm_if we want to avoid the bloat...17:10
ricmm_how big is this bloat anyways? why does it concern you so much17:10
ogra_i guess thats a lot more effort17:10
ogra_dunno, likely a few MB17:11
ogra_it pulls in all of ncurses at least ... probably even more stuff (i never checked, ncurses was already enough to make me run away)17:11
ogra_the code change alone is probably small17:12
sergiusensogra_: ricmm_ parted should be compilable without curses17:12
ogra_sergiusens, it is linked against it17:12
sergiusensogra_: you need to do multibuild in the deb package17:12
ogra_so copy_exec from initramfs-tools pulls in the libs17:12
ogra_(copy_exec reversely runs ldd against all binaries and copies all deps in)17:13
ogra_and i surely dont want to re-package parted :)17:14
ricmm_ogra_:      if (q == PED_EXCEPTION_FIX)17:18
ricmm_        {17:18
ricmm_          last_usable = last_usable_if_grown;17:18
ricmm_          /* clear the old backup gpt header */17:18
ricmm_          ptt_clear_sectors (disk->dev,17:18
ricmm_                             gpt_disk_data->AlternateLBA, 1);17:18
ricmm_          gpt_disk_data->AlternateLBA = disk->dev->length - 1;17:18
ricmm_          *update_needed = 1;17:18
ricmm_        }17:18
ricmm_doesnt look that bad to teach sfdisk about it perhaps ;D17:18
ogra_hmm17:19
ogra_i think upstream sfdisk is even at 2.28 ... perhaps someone cared already :)17:19
ricmm_perhaps17:20
ogra_ah, no, 2.27 ...17:20
ogra_2.28 is in development17:20
ricmm_yea 22717:20
ogra_hah ... they added json dumps :P17:22
ricmm_of course they did17:23
ricmm_going to rest my disk now17:23
ricmm_ogra_: https://github.com/karelzak/util-linux/commit/9d9a1b876094fe38c5539f19a57323437b8b8a0d17:29
ricmm_looks relevant17:29
ogra_well, thats only checks17:30
ogra_i was hoping for relocation code :)17:31
ogra_so seemingly we could use gdisk ... but that has a similar dependency chain as parted17:45
sergiusensricmm ogra_: then maybe the idea of using cloud-init is back up for discussion?17:54
ogra_sergiusens, cloud-init ????17:54
ogra_you want to pull cloud-init into the initrd ?17:54
* ogra_ wants cloud-init gone completely, its a PITA 17:55
ogra_and i surely dont want a python interpreter in the initrd :)17:55
sergiusensogra_: cloud-init does growfs outside of init17:55
sergiusensinitrd that is17:55
ogra_sergiusens, with the whole bind mount farm active on top of the writable part ??17:55
ogra_thats like gambling :)17:56
ogra_the only sane way to resize is from the initrd before we have the bind mounts active17:56
ogra_(even before anything gets mounted at all for extra safety)17:57
ogra_sergiusens, i'll pull parted in before this discussion even comes to speed17:58
ricmm_I'd like not have a bunch of python scripts meant for dispoable cloud instances running on unreachable hardware that is meant to stand the test of time (10 yrs)17:58
ricmm_doing partitioning that is17:58
ricmm_:)17:58
=== ricmm_ is now known as ricmm
ogra_:)17:58
sergiusensChipaca or mvo and elopio I am ready for slaughter https://code.launchpad.net/~sergiusens/snapcraft/meta-all-yaml/+merge/269100 :-)18:01
elopiosergiusens: I'll start looking at it after lunch.18:26
elopiosergiusens: could you look at https://code.launchpad.net/~elopio/snappy/remove_ssh_copy/+merge/268947 ?18:26
sergiusenselopio: sure18:27
* mvo also needs review for some branches18:30
ogra_ricmm, sfdisk -d /dev/sda|sfdisk /dev/sda  ... that makes the error go away but doesnt allow me to resize anymore ... http://paste.ubuntu.com/12194329/18:47
ricmmogra_: sfdisk: libfdisk/src/table.c:420: new_freespace: Assertion `end > start' failed.18:47
ricmmlooks like an error to me !18:47
ogra_well, it doesnt complain about the GPT anymore18:48
ricmmright but it fails at "creating" the freespace definition18:48
ricmmin other words I'll bet the GPT footer is still wrongly positioned18:48
ricmmbecause it didnt get the padding from the unallocated space18:48
loolmvo: bug #1459755: perhaps we can do this for now, but it's not a long-term solution as the serial port might be used for e.g. an UPS or whatever18:49
nothalBug #1459755: Need a way to drive GRUB over serial port <Snappy:Triaged> <http://launchpad.net/bugs/1459755>18:49
ubottubug 1459755 in Snappy "Need a way to drive GRUB over serial port" [Medium,Triaged] https://launchpad.net/bugs/145975518:49
loolmvo: I guess in theory it ties into our hardware assignment story18:50
loolbut this is probably too remote for now18:50
sergiusensmvo: seems like we are in bargaining mode :-P18:50
loolmvo: in any case, we need to set the right linux console18:50
loolmvo: a config flag would be fine though; something like /writable/etc/grub.d/zzzSetserial.conf could be generated perhaps18:51
ogra_ricmm, yeah, i'll switch to parted ... that just means a lot more math i was hoping to avoid18:52
sergiusenslool: we don't parse and generate grub.cfg anymore ;-) It goes straight into the snap18:52
sergiusensso it can be whatever you want18:52
loolsergiusens: right; it doesn't really relate to what we used to do, but just to a config-time place to set bootloader options18:53
loolthat's why I thought of the single-instance writable partition which has some etc stuff rather than dealing with system-a/system-b stuff18:54
sergiusenslool: if it is a fixed function device problem it can certainly have its own gadget/oem snap defining the console18:55
loolsergiusens: yes, that's exactly what I have in mind18:55
sergiusensif not, I prefer a snappy config for ubuntu-core (or the gadget)18:55
sergiusensalthough the gadget snap is not configured, it handles passing down config :-)18:55
sergiusenslool: great18:55
loolsergiusens: I mean, we need to provide the config hooks to turn on serial console in a couple of places, and they need to set it18:55
loolsergiusens: so typically one would set the config from gadget snap, and it would set config options provided by the kernel snap I guess18:56
loolof course, there's a risk that walking down the path of adding config options makes us reinvent every single of GRUB's options18:57
looland here we can already see the difference between the GRUB notion of a serial console and the linux one18:57
loolare we going to abstract it away for folks to consume18:57
loole.g. ubuntu-core/serial-console=ttyS0 and then map that to the right GRUB and Linux serial devices18:57
loolor will we provide kernel/console=(or extra-cmdline=)/dev/ttyS0 and bootloader/serial-console=ttyS018:58
looletc.18:58
ricmmogra_:18:59
ricmm    /* check that the backup header is properly placed */18:59
ricmm    if (le64_to_cpu(gpt->pheader->alternative_lba) < cxt->total_sectors - 1)18:59
ricmm        /* TODO: correct this (with user authorization) and write */18:59
ricmm        goto err0;18:59
ricmmlazy people ;)18:59
ogra_ricmm, hmm, so i just tried the goarted repair ... and while the resize log says the partition is 2.5G now, df and the rest of the world disagree18:59
ogra_(i,e, /proc/partitions)18:59
ricmmwell you'd still need to resize2fs right ?19:00
ricmmnot sure if your script is doing that19:00
ogra_indeed it does19:00
ogra_http://paste.ubuntu.com/12194394/19:00
sergiusenslool: I don't plan to look at that today19:00
ricmmhmm it looked fine for me after gparted sorted the error19:00
ogra_df tells me 1.6G19:01
ogra_for the /oem mount19:01
ogra_(which is the writable partition)19:01
ogra_and /proc/partitions agrees ...19:01
ogra_the resize log says it resized though19:01
ogra_and sfdisk run on the running system with --force says 1.6G too19:02
ogra_it didnt actually resize19:02
ricmmah you are right19:03
ricmmGPT PMBR size mismatch (11713186 != 11713187) will be corrected by w(rite).19:04
ricmmim getting this now19:04
ogra_yeah, thats what i got all the time19:04
ogra_lets give up on sfdisk ...19:04
ricmmgeez19:04
ricmmheh19:04
ogra_unless we want to drop GPT ...19:04
ricmmtry the parted approach19:04
ricmmlets see how larger it is19:04
ogra_yeah, but thats a bit more than just adding parted and removing sfdisk19:05
ogra_parted expects exact values for everything ... that will require a lot more scripting19:05
ogra_not a 5 min job19:05
ricmmif only we had a shell expert19:06
ogra_:P19:06
ricmmogra_: dont need it today, tomorrow 7am is fine19:06
ricmm;D19:06
ricmmj/k, we can continue tomorrow19:06
ogra_if only we had someone who could still focus :P19:06
ricmmits late anyways19:06
ogra_yeah19:06
sergiusensricmm: it's barely snack time for you!19:08
ricmmtrue19:08
* lool returns to leave19:19
ricmmogra_: I think im going to try to do the sfdisk patch19:23
ogra_ricmm, hah, brave19:24
ogra_after seeing it tell me lies about the resizing i dont feel like i can trust it wrt GPT19:24
ricmmwell the error happened because of the line I showed you19:30
ricmmit exits quietly before writing back to disk19:30
ricmmthats where there should be a yes/no option to "fix" and a headless force I guess19:30
ricmmwill look into it later tonight if I got energy19:30
ricmmafter all, I'm still in PST19:30
ogra_heh19:31
ogra_brainf*cked ...19:31
=== ahayzen_ is now known as ahayzen
=== carlo is now known as Guest19154
=== Guest19154 is now known as clobrano_
sergiusenselopio: Chipaca another one https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/26912020:46
sergiusenselopio: did you find a way to not see those 'Leftover .*' messages from plainbox?20:51

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