| === 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 | ||
| elopio | pitti: 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 |
|---|---|---|
| pitti | elopio: no, not right now; mind filing a bug for this? | 06:58 |
| elopio | pitti: sure. | 06:58 |
| elopio | pitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1488358 | 07:02 |
| ubottu | Launchpad bug 1488358 in autopkgtest (Ubuntu) "Can't increase the reboot timeout" [Undecided,New] | 07:03 |
| elopio | mvo: could you look into https://bugs.launchpad.net/snappy/+bug/1488186 ? | 07:04 |
| ubottu | Launchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [Undecided,New] | 07:04 |
| elopio | it'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 | |
| mvo | hey elopio, sure, I have a look | 07:16 |
| mvo | elopio: sleep well | 07:16 |
| mvo | ppisati: 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 else | 07:17 |
| ubottu | Launchpad bug 1480248 in Snappy "automatic reboot fails with zero size initrd in bbb" [Critical,Triaged] | 07:17 |
| ppisati | mvo: so the actual bug is that it hangs there instead of panicing | 07:21 |
| ppisati | mvo: weird, let me see | 07:21 |
| pitti | elopio: asked some questions in the bug | 07:34 |
| ppisati | mvo: why the watchdog doesn't kick in and reboot the board? | 07:40 |
| mvo | ppisati: AFAIK we don't use the watchdog, how can we enable it, that would be a nice fix indeed | 07:42 |
| ppisati | mvo: that should be enabled in uboot | 07:43 |
| mvo | ppisati: I have the board in this state sitting on my desk if you want me to test anything | 07:43 |
| ppisati | mvo: so if we don't reach the userspace in 60secs, it reboots the board | 07:43 |
| ppisati | mvo: so, i did a couple of tests | 07:43 |
| mvo | ppisati: nice, is that a uboot config option or code? | 07:43 |
| ppisati | mvo: yep | 07:43 |
| ppisati | mvo: let me do a couple more checks and i'll comment in the lp bug | 07:43 |
| mvo | great, thanks | 07:44 |
| * ppisati needs more coffee first | 07:44 | |
| mvo | elopio: 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 |
| beowulf | mvo: I commented on #1480404, i think both front and backend need work | 08:59 |
| mvo | ta | 09:02 |
| ogra_ | ppisati, hmm, why in u-boot ? i thought thats a kernel feature | 09:03 |
| Chipaca | ogra_: i guess it needs enabling from kernel commandline to be useful? | 09:07 |
| * Chipaca guesses | 09:07 | |
| ogra_ | well, we have panic=-1 by default there | 09:07 |
| ogra_ | panic=[KNL] Kernel behaviour on panic: delay <timeout> | 09:08 |
| ogra_ | ... | 09:08 |
| ogra_ | timeout < 0: reboot immediately | 09:08 |
| ogra_ | ... is what the kernel docs say | 09:08 |
| ppisati | ogra_: i didn't look at the option for the watchdog on the cmdline | 09:14 |
| ogra_ | well, we dont set nmi_watchdog=1 | 09:14 |
| ppisati | ogra_: but AFAIK a userspace sw open /dev/watchdog | 09:14 |
| ogra_ | but we do set panic=-1 | 09:15 |
| ppisati | ogra_: and have to reopen it before TIMEOUT expires | 09:15 |
| ogra_ | which shoud make the kernel reboot i think | 09:15 |
| ppisati | etc | 09:15 |
| ppisati | ogra_: moreover, what happens if thekernel hangs before the wdt is enabled? | 09:15 |
| ppisati | the correct init should be: | 09:15 |
| ppisati | uboot sets the wdt to X and start booting the board | 09:16 |
| ogra_ | i thought the nmi_watchdog is kernel only | 09:16 |
| ppisati | kernel takes over and, either reach usrspace (and wdt is reset) | 09:16 |
| ppisati | or uboot settings reset the board | 09:16 |
| ogra_ | BOOTPARAM_SOFTLOCKUP_PANIC and BOOTPARAM_HARDLOCKUP_PANIC shoudl provide that if i can belive the docs | 09:17 |
| ppisati | anyhow, i spent the morning looking at uboot | 09:17 |
| ppisati | and it seems the wdt is not supported there | 09:17 |
| ogra_ | ppisati, but why does the normal panic option not kick in here ? | 09:19 |
| ppisati | ogra_: nmi_watchdog? | 09:19 |
| ogra_ | no, we dont have that on currently | 09:19 |
| ogra_ | just the normal panic= stuff | 09:19 |
| ppisati | and it's x86 only | 09:20 |
| ppisati | nmi_watchdog= [KNL,BUGS=X86] | 09:20 |
| ppisati | he sayd he doesn't get any panic | 09:20 |
| ogra_ | oh, right | 09:20 |
| ogra_ | damn | 09:20 |
| ppisati | just hangs there | 09:20 |
| ogra_ | oh, i see why :P | 09: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 links | 09:21 |
| mvo | yeah, thats the symptom, but why does it not complain if initrd.img is invalid? | 09:21 |
| ppisati | do we pass rootwait? | 09:22 |
| ogra_ | depends on the board | 09:22 |
| ppisati | mvo: it doesn't get the initrd at all | 09:22 |
| ogra_ | if it is in the default env we dont wipe it | 09:22 |
| ogra_ | we dont add it explicitly iirc | 09:22 |
| ppisati | mvo: if you pass a malformed initrd, like 1 byte, it says "bad format" or something | 09:22 |
| ppisati | mvo: but it doesn't panic there either | 09:22 |
| ogra_ | i guess we could add a check to uboot (and switch system_ab based on it) | 09:23 |
| ppisati | what really bugs me is that uboot says "watchdog enabled" but i can't fucking get that thing to work | 09:23 |
| ppisati | and IMO it doesn't | 09:23 |
| ogra_ | i.e. look up the size and make sure it isnt zero after loading the initrd | 09:24 |
| ogra_ | but technically having the kernel fall over would be cleaner | 09:24 |
| ogra_ | is there any kernel option for "dont boot without initrd" ? | 09:25 |
| ppisati | not that i am aware | 09:26 |
| ppisati | mvo: do you have the rootwait option? | 09:26 |
| ppisati | mvo: on the cmdline i mean | 09:26 |
| mvo | ppisati: 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 |
| ppisati | ok | 09:27 |
| ppisati | quick test | 09:27 |
| ogra_ | bah, why do we set rootfstype | 09: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 |
| ppisati | if loops there waiting for tghe rootdevice if root_wait = true | 09:27 |
| ogra_ | yeah | 09:27 |
| ppisati | can you try to take that option out? | 09:28 |
| ogra_ | neither rootfstype nor rootwait should be set | 09:28 |
| ogra_ | thats comeing from the default env for the BBB | 09:28 |
| ogra_ | mvo, hmm, can it be that our bbb changes never actually landed in snappy-hub/snappy-systems ? | 10:15 |
| mvo | ogra_: I certainly send a MP | 10:16 |
| mvo | ogra_: 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/264975 | 10:16 |
| * ogra_ approves | 10: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 above | 10:17 |
| ogra_ | *bug | 10:18 |
| Chipaca | elopio: question: is there a reason _integration-tests/bin/ and _integration-tests/data/output aren't in bzrignore? | 10:21 |
| mvo | ogra_: thanks, branch updated | 10:21 |
| mvo | ogra_: cool, so if I remove the rootwait it will work? | 10:22 |
| mvo | ogra_: as a quick test? | 10:22 |
| ogra_ | mvo, you should test it, but it is very likely, yes | 10:22 |
| mvo | ogra_: does that also fixes the "1" byte file initrd.img ? or is that a separate bug ? | 10:22 |
| * mvo tests once that bbb finishes booting | 10:23 | |
| ogra_ | just intercept the boot in uboot and set mmcrootfstype to nothing or just to ext4 or so | 10:23 |
| ogra_ | the 1byte initrd will also try to fall back to mount root= directly ... (and fail) the outcome should be the same | 10:23 |
| mvo | ogra_: cool, I set this now via fw_setenv and see what happens | 10:24 |
| ogra_ | +1 | 10:24 |
| mvo | nice panic | 10:24 |
| ogra_ | and reboot too ? | 10:24 |
| mvo | yes | 10:25 |
| ogra_ | yay ! | 10:25 |
| ogra_ | awesome | 10:25 |
| mvo | I try the one byte file now just for good measure | 10:25 |
| ogra_ | yeah | 10:26 |
| mvo | ogra_: I assume you are on the updated snappy-systems branch? | 10:26 |
| ogra_ | i would be surpised if it wouldnt do the same | 10: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 |
| mvo | ogra_: ok, I can work on the branch if you want, just don't want to dupliicate work :) | 10:27 |
| ogra_ | ah, k | 10:27 |
| mvo | same for 1 byte | 10:27 |
| ogra_ | yay | 10:27 |
| ogra_ | ppisati, ^^^ all fine then | 10:27 |
| ppisati | ogra_: cool, but i still want to understand why the f*ck watchdog didn't reboot from uboot | 10:31 |
| Chipaca | 15.04 is go 1.3, right? | 10:32 |
| mvo | yes | 10:32 |
| mvo | ogra_: https://code.launchpad.net/~mvo/snappy-hub/lp1480248-norootwait/+merge/269032 | 10:33 |
| ogra_ | mvo, approved | 10:34 |
| mvo | ogra_: I'm doing a final test with a good initrd.img (takes forever because of the sync mount option) | 10:34 |
| mvo | ogra_: thanks | 10:34 |
| ogra_ | the sync mount option ? | 10:35 |
| mvo | ogra_: I copied the good initrd back and that cp takes a long time | 10:35 |
| mvo | ogra_: because we mount /boot sync | 10:35 |
| ogra_ | ah, right | 10:35 |
| mvo | ogra_: but all good, booted fine from b | 10:35 |
| ogra_ | i thought the boot takes forever :) | 10:35 |
| Chipaca | rsalveti: 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 snap | 10:49 | |
| mvo | someone will need to approve my updated bbb snap | 11:04 |
| * mvo gets lunch first | 11:04 | |
| rickspencer3 | hi all, snappy-remote keeps timing out on me | 11:58 |
| rickspencer3 | any ideas? I can easily ssh right into the BBB | 11:59 |
| Mikaela | I 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 |
| rickspencer3 | Mikaela, thanks for your answer, that is interesting | 12:01 |
| rickspencer3 | but, snappy-remote is just a wrapper around ssh, I think, to push and install your snap package | 12:01 |
| rickspencer3 | it looks like it is trying to do some kind of key exchange that is failing | 12:02 |
| ogra_ | rickspencer3, using an IP or webdm.local ? | 12:02 |
| rickspencer3 | ogra_, webdm.local | 12:02 |
| ogra_ | and ssh to webdm.local works from the same machine ? | 12:02 |
| * rickspencer3 tries with straight ip | 12:05 | |
| rickspencer3 | ogra_, ssh works fine, yeah (using webdm.local) | 12:05 |
| rickspencer3 | and using the ip address with snappy remote worked fined as well | 12:06 |
| ogra_ | aha | 12:06 |
| rickspencer3 | I 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-assign | 12:07 |
| rickspencer3 | ogra_, 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 access | 12:08 |
| rickspencer3 | ogra_, does this tell me how to use hw-assign? | 12:29 |
| rickspencer3 | nm, I figured it out | 12:32 |
| ogra_ | :) | 12:32 |
| mvo | ogra_: 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 |
| ubottu | Launchpad 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/1429749 | 12:53 |
| rickspencer3 | is there a Go library for gpio that is known to work with BBB and snappy? | 12:53 |
| sergiusens | hello hello | 13:06 |
| * sergiusens is in back to normal mode | 13:07 | |
| mvo | hey sergiusens, good monring! | 13:09 |
| mvo | sergiusens: do you happen to know if we have a branch for snappy remote 0.4 somewhere? | 13:09 |
| mvo | sergiusens: I was looking into a issue that rickspencer3 reported earlier about slow webdm.local resolving | 13:10 |
| sergiusens | mvo: how is it related to snappy remote? | 13:10 |
| sergiusens | mvo: snappy-remote just uses avahi indirectly when using ssh | 13:11 |
| sergiusens | mvo: you probably want to up the broadcast of IPs in webdm itself, I think | 13:11 |
| mvo | sergiusens: I wanted to check what snappy-remote is doing and if we could cache the ip there for example | 13:11 |
| sergiusens | mvo: oh, it's just using 'ssh' | 13:11 |
| mvo | sergiusens: aha, that sounds like a better suggestions, thanks | 13:11 |
| mvo | sergiusens: 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 |
| sergiusens | mvo: yeah, I might have forgotten to push and I'll need to power up my older laptop to get it :-/ | 13:12 |
| sergiusens | will do in a bit; the 0.4 thing only does some key magic | 13:13 |
| mvo | no worries, I can manually import from the deb if its trouble to find the old laptop | 13:13 |
| mvo | ogra_, 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 |
| nothal | Bug #1458866: hangs in uboot boot prompt if dtbs dir is missing <Snappy:New> <http://launchpad.net/bugs/1458866> | 13:48 |
| ubottu | bug 1458866 in Snappy "hangs in uboot boot prompt if dtbs dir is missing" [Undecided,New] https://launchpad.net/bugs/1458866 | 13:48 |
| mvo | lool: re bug #1459755 - could we simply unconditionally enable serail grub in our generic-amd64 snap? or is there a downside to this? | 13:58 |
| nothal | Bug #1459755: Need a way to drive GRUB over serial port <Snappy:New> <http://launchpad.net/bugs/1459755> | 13:58 |
| ubottu | bug 1459755 in Snappy "Need a way to drive GRUB over serial port" [Undecided,New] https://launchpad.net/bugs/1459755 | 13:58 |
| mvo | elopio: 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 branch | 14:39 |
| mvo | ppisati, 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_ | *handles | 14:52 |
| ogra_ | do the azure images have a special initrd or some such ? | 14:53 |
| sergiusens | ogra_: iirc, rsalveti added it | 14: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 |
| rsalveti | ogra_: azure needs it | 14:54 |
| rsalveti | because of azure :-) | 14:54 |
| rsalveti | or better, because of reasons | 14:54 |
| sergiusens | ogra_: ah, it's in there docs | 14:54 |
| ogra_ | lol | 14:54 |
| sergiusens | as a requirement | 14:54 |
| ogra_ | i dont get that | 14:55 |
| ogra_ | it should be a total no-op if you use an initrd | 14:55 |
| ogra_ | (apart from breaking our auto-panic ) | 14:55 |
| ogra_ | do we have any azure devs we could ask ? | 14:56 |
| ogra_ | for $reasons | 14:56 |
| rsalveti | ogra_: check our priv channel | 14:56 |
| ogra_ | ah, i need to re-loacate | 14:56 |
| * ogra_ goes to the office | 14:56 | |
| elopio | mvo: 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 |
| elopio | https://code.launchpad.net/~mvo/snappy/snappy-review-tools-reenable/+merge/264301/comments/676317 | 14:58 |
| mvo | elopio: aha, ok, sorry, I didn't - brain was in quick triage mode apparently :/ | 14:59 |
| elopio | mvo: wow, you triaged the world. Thanks! | 15:01 |
| davmor2 | elopio: 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 |
| elopio | davmor2: snappying the world it's such a chore. | 15:45 |
| elopio | barry: we started getting this error: https://bugs.launchpad.net/snappy/+bug/1488186 | 15:45 |
| ubottu | Launchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [High,Triaged] | 15:45 |
| elopio | barry: any idea what could cause it? | 15:45 |
| barry | elopio: 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 |
| elopio | barry: who manages the server? I'm not sure whom to ask about that. | 15:48 |
| barry | elopio: probably is, but slangasek has access | 15:50 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| slangasek | elopio, barry: I don't have any access to the web frontends; that's IS-managed | 16:02 |
| mvo | elopio: I guess a rt ticket is the best way forward at this point | 16:09 |
| elopio | mvo: ok, on it. | 16:11 |
| elopio | Chipaca: 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 |
| elopio | a .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 it | 16:25 |
| ricmm_ | ogra_: gparted offers to fix the partition table header for you | 16:25 |
| ricmm_ | then it shows fine as unallocated space | 16:25 |
| ogra_ | hmm, doesnt here | 16:26 |
| ricmm_ | then sfdisk actually does the job correctly when doing 2.26 | 16:26 |
| ricmm_ | didnt offer you to fix? | 16:26 |
| ricmm_ | I appended zeros to the image file first | 16:26 |
| ogra_ | ah, i was trying to shrink writable | 16:26 |
| ricmm_ | so I'm trying right now with flashing the image as-is (4G) onto flash and see if that works | 16:27 |
| ricmm_ | or if theres the same error as on kvm | 16:27 |
| ogra_ | i'd expect the same error with the old sfdisk | 16:28 |
| ogra_ | ricmm_, hmm, no errors on rolling ... but no resize either | 16:32 |
| ogra_ | http://paste.ubuntu.com/12193628/ | 16:33 |
| * ogra_ appends moar zeros | 16:34 | |
| ogra_ | hmm, it sees that the disk grew bigger | 16:36 |
| ricmm_ | ogra_: it gret 1.3 MB for you | 16:37 |
| ricmm_ | yet you had added 500M of zeros | 16:37 |
| ricmm_ | mmm | 16:37 |
| ogra_ | i added another GB | 16:37 |
| ogra_ | and it properly sees the device is 5GB now | 16:38 |
| ogra_ | but it doesnt resize | 16:38 |
| ogra_ | (doesnt error either) | 16:38 |
| elopio | Chipaca: https://code.launchpad.net/~elopio/snappy/bzr_ignore_integration_output/+merge/269095 | 16:44 |
| ricmm_ | ogra_: hmmm it worked for me | 16:53 |
| ricmm_ | did you open it with gparted at some point? | 16:53 |
| ogra_ | no | 16:53 |
| ricmm_ | open it with gparted, lets try to understand what kind of fix that is doing | 16:53 |
| ogra_ | i added 1.5G | 16:53 |
| ricmm_ | it will offer to "fix" the partitioning | 16:53 |
| ricmm_ | yea but added it how | 16:53 |
| ricmm_ | just appending zeros? | 16:53 |
| ogra_ | dd | 16:54 |
| ogra_ | yeah | 16:54 |
| ogra_ | dd oflag=append conv=notrunc if=/dev/zero of=kvm-rolling.img bs=1MB count=1000 | 16:54 |
| ogra_ | and before the same with 500 | 16:54 |
| ogra_ | now i'm in an initrd shell ... | 16:54 |
| ricmm_ | lol | 16: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 hw | 16:55 |
| ricmm_ | right, thats the error that gparted fixes | 16: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 seems | 16:55 |
| ogra_ | hmm | 16:55 |
| ogra_ | perhaps i need a reboot or re-read the partition table at the kernel level | 16:55 |
| ogra_ | hmm, nope | 16:56 |
| ogra_ | blockdev --rereadpt doesnt change a thing | 16:56 |
| ogra_ | sigh | 16:59 |
| ogra_ | i dont think there is a way around using parted | 17: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 partition | 17:01 |
| ricmm_ | ogra_: sfdisk knows GPT | 17:05 |
| ricmm_ | thats not the problem | 17:05 |
| ogra_ | yes | 17: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 misaligned | 17:05 |
| ricmm_ | its not at the physical end of disk | 17:05 |
| elopio | kyrofa: nice video. Did you publish the source for your snap somewhere? | 17:05 |
| ogra_ | right | 17:05 |
| ricmm_ | ogra_: parted can fix this I think but there should be an easier way to do so for GPT | 17:05 |
| ricmm_ | maybe we can teach sfdisk to do so | 17:05 |
| ricmm_ | :) | 17:05 |
| kyrofa | elopio, thanks! Yeah, it's here: https://github.com/kyrofa/piglowtop | 17:06 |
| kyrofa | elopio, 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 doesnt | 17:06 |
| elopio | kyrofa: thanks! | 17:06 |
| ricmm_ | ogra_: but did it do an actual write? how about read the partition as-is then write it again | 17:06 |
| ricmm_ | it might realign it to end of disk | 17:06 |
| ogra_ | oh damn ! | 17:08 |
| ogra_ | i'm blind | 17: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 :P | 17:08 |
| ogra_ | sigh | 17:09 |
| ogra_ | so that silly GPT stuff will make me re-write the whole thing then :((( to use parted and bloat the initrd | 17:10 |
| ricmm_ | well not necesarily | 17:10 |
| ricmm_ | we can try to understand what gparted is doing to fix the stuff | 17:10 |
| ricmm_ | and just teach sfdisk about it | 17:10 |
| ricmm_ | if we want to avoid the bloat... | 17:10 |
| ricmm_ | how big is this bloat anyways? why does it concern you so much | 17:10 |
| ogra_ | i guess thats a lot more effort | 17:10 |
| ogra_ | dunno, likely a few MB | 17: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 small | 17:12 |
| sergiusens | ogra_: ricmm_ parted should be compilable without curses | 17:12 |
| ogra_ | sergiusens, it is linked against it | 17:12 |
| sergiusens | ogra_: you need to do multibuild in the deb package | 17:12 |
| ogra_ | so copy_exec from initramfs-tools pulls in the libs | 17: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 ;D | 17:18 |
| ogra_ | hmm | 17:19 |
| ogra_ | i think upstream sfdisk is even at 2.28 ... perhaps someone cared already :) | 17:19 |
| ricmm_ | perhaps | 17:20 |
| ogra_ | ah, no, 2.27 ... | 17:20 |
| ogra_ | 2.28 is in development | 17:20 |
| ricmm_ | yea 227 | 17:20 |
| ogra_ | hah ... they added json dumps :P | 17:22 |
| ricmm_ | of course they did | 17:23 |
| ricmm_ | going to rest my disk now | 17:23 |
| ricmm_ | ogra_: https://github.com/karelzak/util-linux/commit/9d9a1b876094fe38c5539f19a57323437b8b8a0d | 17:29 |
| ricmm_ | looks relevant | 17:29 |
| ogra_ | well, thats only checks | 17: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 parted | 17:45 |
| sergiusens | ricmm 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 |
| sergiusens | ogra_: cloud-init does growfs outside of init | 17:55 |
| sergiusens | initrd that is | 17: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 active | 17: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 speed | 17: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 is | 17:58 |
| ricmm_ | :) | 17:58 |
| === ricmm_ is now known as ricmm | ||
| ogra_ | :) | 17:58 |
| sergiusens | Chipaca or mvo and elopio I am ready for slaughter https://code.launchpad.net/~sergiusens/snapcraft/meta-all-yaml/+merge/269100 :-) | 18:01 |
| elopio | sergiusens: I'll start looking at it after lunch. | 18:26 |
| elopio | sergiusens: could you look at https://code.launchpad.net/~elopio/snappy/remove_ssh_copy/+merge/268947 ? | 18:26 |
| sergiusens | elopio: sure | 18:27 |
| * mvo also needs review for some branches | 18: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 |
| ricmm | ogra_: sfdisk: libfdisk/src/table.c:420: new_freespace: Assertion `end > start' failed. | 18:47 |
| ricmm | looks like an error to me ! | 18:47 |
| ogra_ | well, it doesnt complain about the GPT anymore | 18:48 |
| ricmm | right but it fails at "creating" the freespace definition | 18:48 |
| ricmm | in other words I'll bet the GPT footer is still wrongly positioned | 18:48 |
| ricmm | because it didnt get the padding from the unallocated space | 18:48 |
| lool | mvo: 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 whatever | 18:49 |
| nothal | Bug #1459755: Need a way to drive GRUB over serial port <Snappy:Triaged> <http://launchpad.net/bugs/1459755> | 18:49 |
| ubottu | bug 1459755 in Snappy "Need a way to drive GRUB over serial port" [Medium,Triaged] https://launchpad.net/bugs/1459755 | 18:49 |
| lool | mvo: I guess in theory it ties into our hardware assignment story | 18:50 |
| lool | but this is probably too remote for now | 18:50 |
| sergiusens | mvo: seems like we are in bargaining mode :-P | 18:50 |
| lool | mvo: in any case, we need to set the right linux console | 18:50 |
| lool | mvo: a config flag would be fine though; something like /writable/etc/grub.d/zzzSetserial.conf could be generated perhaps | 18:51 |
| ogra_ | ricmm, yeah, i'll switch to parted ... that just means a lot more math i was hoping to avoid | 18:52 |
| sergiusens | lool: we don't parse and generate grub.cfg anymore ;-) It goes straight into the snap | 18:52 |
| sergiusens | so it can be whatever you want | 18:52 |
| lool | sergiusens: right; it doesn't really relate to what we used to do, but just to a config-time place to set bootloader options | 18:53 |
| lool | that's why I thought of the single-instance writable partition which has some etc stuff rather than dealing with system-a/system-b stuff | 18:54 |
| sergiusens | lool: if it is a fixed function device problem it can certainly have its own gadget/oem snap defining the console | 18:55 |
| lool | sergiusens: yes, that's exactly what I have in mind | 18:55 |
| sergiusens | if not, I prefer a snappy config for ubuntu-core (or the gadget) | 18:55 |
| sergiusens | although the gadget snap is not configured, it handles passing down config :-) | 18:55 |
| sergiusens | lool: great | 18:55 |
| lool | sergiusens: I mean, we need to provide the config hooks to turn on serial console in a couple of places, and they need to set it | 18:55 |
| lool | sergiusens: so typically one would set the config from gadget snap, and it would set config options provided by the kernel snap I guess | 18:56 |
| lool | of course, there's a risk that walking down the path of adding config options makes us reinvent every single of GRUB's options | 18:57 |
| lool | and here we can already see the difference between the GRUB notion of a serial console and the linux one | 18:57 |
| lool | are we going to abstract it away for folks to consume | 18:57 |
| lool | e.g. ubuntu-core/serial-console=ttyS0 and then map that to the right GRUB and Linux serial devices | 18:57 |
| lool | or will we provide kernel/console=(or extra-cmdline=)/dev/ttyS0 and bootloader/serial-console=ttyS0 | 18:58 |
| lool | etc. | 18:58 |
| ricmm | ogra_: | 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 |
| ricmm | lazy 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 disagree | 18:59 |
| ogra_ | (i,e, /proc/partitions) | 18:59 |
| ricmm | well you'd still need to resize2fs right ? | 19:00 |
| ricmm | not sure if your script is doing that | 19:00 |
| ogra_ | indeed it does | 19:00 |
| ogra_ | http://paste.ubuntu.com/12194394/ | 19:00 |
| sergiusens | lool: I don't plan to look at that today | 19:00 |
| ricmm | hmm it looked fine for me after gparted sorted the error | 19:00 |
| ogra_ | df tells me 1.6G | 19:01 |
| ogra_ | for the /oem mount | 19:01 |
| ogra_ | (which is the writable partition) | 19:01 |
| ogra_ | and /proc/partitions agrees ... | 19:01 |
| ogra_ | the resize log says it resized though | 19:01 |
| ogra_ | and sfdisk run on the running system with --force says 1.6G too | 19:02 |
| ogra_ | it didnt actually resize | 19:02 |
| ricmm | ah you are right | 19:03 |
| ricmm | GPT PMBR size mismatch (11713186 != 11713187) will be corrected by w(rite). | 19:04 |
| ricmm | im getting this now | 19:04 |
| ogra_ | yeah, thats what i got all the time | 19:04 |
| ogra_ | lets give up on sfdisk ... | 19:04 |
| ricmm | geez | 19:04 |
| ricmm | heh | 19:04 |
| ogra_ | unless we want to drop GPT ... | 19:04 |
| ricmm | try the parted approach | 19:04 |
| ricmm | lets see how larger it is | 19:04 |
| ogra_ | yeah, but thats a bit more than just adding parted and removing sfdisk | 19:05 |
| ogra_ | parted expects exact values for everything ... that will require a lot more scripting | 19:05 |
| ogra_ | not a 5 min job | 19:05 |
| ricmm | if only we had a shell expert | 19:06 |
| ogra_ | :P | 19:06 |
| ricmm | ogra_: dont need it today, tomorrow 7am is fine | 19:06 |
| ricmm | ;D | 19:06 |
| ricmm | j/k, we can continue tomorrow | 19:06 |
| ogra_ | if only we had someone who could still focus :P | 19:06 |
| ricmm | its late anyways | 19:06 |
| ogra_ | yeah | 19:06 |
| sergiusens | ricmm: it's barely snack time for you! | 19:08 |
| ricmm | true | 19:08 |
| * lool returns to leave | 19:19 | |
| ricmm | ogra_: I think im going to try to do the sfdisk patch | 19:23 |
| ogra_ | ricmm, hah, brave | 19:24 |
| ogra_ | after seeing it tell me lies about the resizing i dont feel like i can trust it wrt GPT | 19:24 |
| ricmm | well the error happened because of the line I showed you | 19:30 |
| ricmm | it exits quietly before writing back to disk | 19:30 |
| ricmm | thats where there should be a yes/no option to "fix" and a headless force I guess | 19:30 |
| ricmm | will look into it later tonight if I got energy | 19:30 |
| ricmm | after all, I'm still in PST | 19:30 |
| ogra_ | heh | 19:31 |
| ogra_ | brainf*cked ... | 19:31 |
| === ahayzen_ is now known as ahayzen | ||
| === carlo is now known as Guest19154 | ||
| === Guest19154 is now known as clobrano_ | ||
| sergiusens | elopio: Chipaca another one https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/269120 | 20:46 |
| sergiusens | elopio: 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!