=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === erkules_ is now known as erkules [07:08] good morning [07:11] good morning [07:24] Good morning o/ [08:07] Good morning all; happy Meteor Watch Day! 😃 [08:09] Hello brethren [08:16] JamesTait: you can't fool me, it's Ice cream soda day. [08:17] blr, really? Works for me! [08:51] mo'in ppls [08:51] blr: no, that's june 20 [08:52] blr: although according to the same source, today is "turkey lovers' month" [08:53] blr: so i'm not sure they understand the concept of "day" [08:53] to be fair, it's a tricky one for chefs to grasp [08:53] Chipaca: my secretary will hear about this... this is an outrage. [08:55] (my secretary is a black smoke persian, she's not very good at scheduling. Suppose I'll have to return the crate of ice cream soda) [08:57] * Chipaca hopes that's a cat, as opposed to being incredibly racist [08:57] yes, a cat... [08:57] blr: no returns on food though === vrruiz_ is now known as rvr [09:31] blr, if you need a hand disposing of that ice cream soda, I know someone.... 😉 [10:22] mvo: i didn't realize gettext2 was merging into gettext, not sure what gives now [10:22] Chipaca: i resubmit, no problem [10:23] mvo: okie doke [10:25] morning [10:26] sergiusens: wrt https://code.launchpad.net/~sergiusens/snappy-hub/grubcfg/+merge/262701 do you want that landed? [10:26] rsalveti: mo'in! [10:39] ogra_: this beaglecore is quite interesting, but a bit expensive it seems [10:40] at the same time there are the other guys doing the $9 board [10:41] rsalveti, the $9 board is a fake ... it will cost $49 after the kickstarter [10:42] right lol [10:43] ah, sorry, $39 is what thy said [10:47] Chipaca: hm, is it just me or is snappy trunk unhappy right now (and if so, how is this possible?): http://paste.ubuntu.com/11798388/ - gtg to get lunch so no hurry :) [10:52] mvo: it's just you [10:52] oh, wait [10:52] i don't have adt-run :) [10:52] mvo: maybe tarmac doesn't have adt-run either [11:06] mvo, Chipaca it is failing here too, this branch should fix it https://code.launchpad.net/~fgimenez/snappy/fix-installsnap-call/+merge/263336 [11:14] Chipaca: I think I want to apply the pastebin first === julienrbt is now known as jrbt [11:19] Chipaca: if someone approves it, it can land ;-) [11:22] Chipaca: mvo did the go tests land? And no, no adt-run on tarmac, not sure it would work well (merges would take a tad longer, tad == couple of hours with no prior measurement) [11:32] sergiusens: where does tarmac run? [11:33] Chipaca: we had this conversation already :-P [11:33] Chipaca: on a DO instance [11:33] sergiusens: this was a tarmac in a puny cloud thing? [11:34] right [11:34] sergiusens: you're expensing that, right? [11:34] Chipaca: nope [11:34] sergiusens: aww, but i want to throw hardware at the problem :) [11:35] * ogra_ hands Chipaca a spare RPi [11:35] ogra_: let's go grab the ubuntu build farm of rpi's that whatsisname croudfunded [11:36] heh [11:36] this one: https://www.indiegogo.com/projects/a-raspberry-pi-build-cluster-for-ubuntu [11:37] yeah, alan [11:37] ye, wossisname [11:38] anyway :) [11:38] sergiusens: if the integration tests are too slow, we split them and farm them out so they're only as slow as the slowest individual test (+overhead) [11:38] alan bell :) [11:39] as opposed to the other alan, wossisname-with-a-face [11:39] and then there's wossisname-welsh-guy-plays-with-n-scale-trains [11:40] Chipaca: building is not the problem, i's running [11:40] sergiusens: that's what i'm talking about [11:40] in other news, run-checks now asks me for my password [11:40] Chipaca: ok, so first solve the provisioning issue on rpi's and then we do that ;-) [11:40] what could possibly go wrong :-) [11:43] ugh, does adt-run really leave schroots lying around? :( [11:45] * Chipaca makes some guacamole to mask his pain [11:46] get two cucumber slices too ... [11:50] no cucumber, no tomato, no peppers. so it's my ex-mother-in-law's recipe: palta, lemon, salt, ground pepper [11:52] and some garlic bread ? [11:52] yep [11:56] fgimenez: with that patch the tests build but don't pass, right? [11:59] Chipaca, no, i have them passing too, are they failing? [12:00] fgimenez: ver es [12:00] fgimenez: ver yes [12:00] fgimenez: http://pastebin.ubuntu.com/11798701/ [12:01] Chipaca, this is the adt-run error because of the missing dpkg-query, with adt-run 3.15.1 should be ok [12:01] fgimenez: ahhhh [12:02] Chipaca, however i think 3.15.1 is only available in wily atm... [12:02] fgimenez: i'm on wily, but haven't updated this week [12:02] * Chipaca apologizes [12:02] * sergiusens is back [12:02] Chipaca, ah ok then :) [12:03] Chipaca, np :) [12:28] Chipaca: does this work for you https://code.launchpad.net/~sergiusens/snappy/splitDown/+merge/263294 ? [12:28] * Chipaca looks [12:29] sergiusens: sure [12:32] Chipaca: that solves the nit in https://code.launchpad.net/~sergiusens/snappy/downloadIcon/+merge/263296 , right? [12:33] sergiusens: you probably want to merge trunk [12:34] Chipaca: I have [12:34] sergiusens: it solves it for the common "download failed" error, but not sure whether the more pathologic errors (the copy failing for example) [12:34] sergiusens: why do you have conflicts then? [12:34] maybe i'm looking at the wrong diff :) [12:34] Chipaca: maybe my syc-pipeline failed, let me check [12:35] yeah, there are for real conflicts in there [12:36] Chipaca: ok, one more sec; sync-pipeline is doing its thing now [12:37] Chipaca: there [12:37] Chipaca: the obscure error from w.Sync() you mean? [12:37] Chipaca: we have a bug for clearer download errors fwiw [12:38] maybe we should tackle that there? [12:40] sergiusens: maybe? what's the bug? [12:41] Chipaca: not sure, I asked someone to log it [12:41] Chipaca: so maybe we don't... === chihchun is now known as chihchun_afk [14:27] seb128: so where do you get the udf/goget-ubuntun-touch that has personal channel support from ? [14:29] kgunn: for now you can just grab the u-d-f deb from https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.25-0ubuntu1 ... I'll take it to tools-proposed in a bit [14:29] hello. [14:29] sergiusens: thanks... [14:29] kgunn: clickable linke https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.25-0ubuntu1/+build/7569188/+files/ubuntu-device-flash_0.25-0ubuntu1_amd64.deb [14:30] if you are on an amd64 system [14:30] sergiusens: uh....do you have one for vivid ? [14:30] its go [14:30] kgunn: it really really doesn't matter [14:30] k [14:30] just install ti [14:30] *it [14:30] and yes amd64 [14:31] kgunn, what sergiusens said [14:31] kgunn: just make sure add-apt-repository ppa:snappy-dev/tools to make sure all aux deps are up to date [14:31] bah, I don't get why but cloud-init fails to start on snappy personal for a week [14:31] i dont get why you still havent unseeded it :P [14:32] (we talked about it last week iirc) [14:32] ogra_, because we don't want to diverge from core [14:32] fgimenez: sorry I'm late. I'm joining the hangout. [14:33] seb128, you definitely do want to diverge from core [14:33] elopio, ok np [14:33] ogra_, why? [14:33] seb128, you want to actually have a merged system between core and touch [14:33] because core isnt a desktop system [14:33] right, but we want the base snappy zest to work [14:33] and cloud-init isnt really designed for desktops [14:34] * ogra_ would use the user creation from touch for now ... as i suggested last week [14:34] and drop cloud-init [14:34] kgunn, ^ what do you think? [14:35] you will most likely get a lot of issues with session startup and permissions etc [14:35] (not sure how clous-init exactly works, but it likely is focused on cloud user creation :) ) [14:36] seb128: ogra_ I can fix this from the u-d-f side, just give me a sec [14:36] sergiusens, cloud-init ? [14:36] ogra_: yeah, just like we do for our 'devices' [14:36] I just didn't think personal would have cloud-init seeded ;-) [14:37] yeah [14:37] I think seb128 has a point, it will be easier to migrate into core if the base has additions only and not removals [14:37] sergiusens, oh, it's an u-d-f issue? [14:38] seb128: yes and no [14:38] seb128, teg phablet user creation for touch is in livecd-rootfs in a hook btw ... (if you port it you want to take a look at the groups though, you likely dont want the android groups in personal desktop) [14:38] *the phablet [14:38] seb128: what is in u-d-f today I consider a hack and we have a task to remove that hack [14:39] ogra_, yeah, I'm looking at http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/00-uid-gid-fix.chroot_early [14:39] seb128, no, not that one [14:39] ogra_, sergiusens, I'm unsure what to do there, I wanted to get the image working without diverging too much from core, then start to discuss things like not using cloud-init [14:40] ogra_, sorry [14:40] seb128, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/01-setup_user.chroot [14:40] ogra_, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/01-setup_user.chroot [14:40] I mean [14:40] yeah, clicked the wrong one :p [14:40] http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot and http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/45-add-sudo-group-nm.chroot are the ones you want to take a look at too [14:41] ogra_, thanks [14:41] though for the first one you probably only want the audio group (if at all) [14:42] sergiusens, hmm, that reminds me ... did you take a look at usermod too wrt extrausers ? [14:42] it might also need love [14:46] ppisati: ping [14:48] ogra_: I haven't, and yes it needs love, but one step at a time; deluser also needs some love fwiw [14:48] sergiusens, yeah, just struck me that we didnt have it on the list yet [14:49] but apparently you do already :) [14:49] sergiusens, ok, I think I'm going to follow ogra_'s suggestion for the user creation, it's likely going to make easier to have the user in the right groups as well [14:50] seb128, indeed thats not a long term solution (but neither is cloud-init i guess) [14:51] seb128, we also have a bunch of lightdm changes (in either lxc-android-config or ubuntu-tuch-session, i forgot where they landed ... that are needed to make u-s-c start etc ... ) mterry implemented that back then [14:53] seb128: so you are unseeding cloud-init? [14:53] sergiusens, going to have a look at doing that, I hope it doesn't carry us at doing too many changes [14:54] seb128: when it's safe to seed it again once the proper snappy firstboot logic is in place you can add it back [14:54] ogra_, is the uid 32011 for android compat purpose? or asked differently, is that needed or desktop or should it be 1000? [14:54] sergiusens, right [14:54] seb128: you can subscribe to https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init [14:54] if you want [14:55] seb128, 1000 is hardcoded in android for the "system" user [14:55] sergiusens, thanks [14:55] seb128, the 32011 is just to be sure we dont clash with any of these hardcoded andrpid groups [14:56] ogra_, k, so 1000 should do for desktop I guess :-) [14:56] for multi user phones and convergence we will need to fix that in the adduser config so that the default user gets a high enough UID [14:57] for an initial desktop image 1000 should do indeed ... but you will have to follow the above later too ... since convergence will use the android container most likely [14:57] people, i'm going out over mobile right now, and it's acting up, not giving me 3g (although it fluctuates) [14:57] right, let's see [14:58] my point being, not sure ho will work [15:02] Chipaca, use a proper phone :P [15:03] Chipaca: we are splitting work [15:03] Chipaca: if you are not there... [15:03] :-P [15:03] i'll try! ill try. [15:09] yeah, you just got all the crap stuff assined [15:09] *assined [15:09] bah [15:10] i need a new g ! [15:22] fgimenez: the upgrade test works for me http://paste.ubuntu.com/11799617/ [15:23] elopio, ok, i'll try it again [15:23] fgimenez: I pushed a merge with trunk. [15:24] elopio, thanks, running now [15:25] elopio, http://paste.ubuntu.com/11799655/ [15:26] fgimenez: it's running the upgrade test as part of the command1. [15:27] elopio, command1 should be latest right? [15:27] test command1: debian/integration-tests/snappy-test update.test [15:28] fgimenez: yes. What do you have in your debian/integration-tests/control ? [15:29] elopio, yes that must be it http://paste.ubuntu.com/11799670/ [15:29] elopio, rerunning with clean control [15:29] ogra_, do you know why http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/01-setup_user.chroot create the user with --disable-login? [15:30] seb128: hey, not sure whether cyphermox filled you in, but we do have a grub now in wily whose --removable option will work for snappy personal. Unfortunately when booting under qemu, the kernel then crashes in a loop... that's most likely unrelated though [15:30] fgimenez: right, this is +1 to your control templates, then the index is something we control on main, not something we have to keep in sync. [15:30] elopio, yes, having it unified may prevent errors in the long term [15:32] slangasek, cyphermox, oh, nice ... the kernel loop, what grub entry do you try? the snappy/system-a does that but the "ubuntu" one works [15:32] seb128: ah - we don't get a boot menu, so we're just booting whatever the default is, which I would expect to be snappy/system-a [15:32] slangasek, k, that doesn't work [15:32] seb128, no idea, that script originally comes from the OEM team (when it was still called that) [15:33] unsure how it's created/why we have several entries [15:33] seb128, oh, wait, thats for system and radio users [15:33] ogra_, no, l7 [15:33] adduser --gecos $USER --disabled-login $USER --uid $UGID [15:33] we dont want any hacker to abuse these accounts indeed :) [15:33] echo "I: creating default user $USER" [15:34] ah, right, no idea about that one ... i guess for the actual user it is nonsense [15:34] for radio and system thats surely valid [15:34] right [15:35] ogra_, "With the --disabled-login option, the [15:35] account will be created but will be disabled until a password is set. [15:35] " [15:35] which is done further in the file [15:36] so I guess it's ok [15:36] yeah, as i said, nonsense [15:36] mvo: are you using go benchmark for the squash report? [15:36] someone being over-cautious or something [15:36] seb128: I would assume that snappy personal should have a/b partitions just like snappy core... what are the differences between this 'ubuntu' boot entry and the snappy one? [15:37] elopio, all fine now http://paste.ubuntu.com/11799711/ :) [15:37] slangasek, I don't know, we didn't tweak anything from grub, just copied the hooks from core [15:38] hmm [15:38] fgimenez: phew. Please top approve when you are happy with it. Or leave a needs fixing if you are unhappy, I'll fix it after breakfast. [15:39] fgimenez: so now we have to think about how to declare tests and their requirements, so main.go can parse that. [15:39] doesn't sound too easy if we have to declare channel, release and version, and maybe secondary test bed inside a container. [15:40] elopio, yes, we can begin with the simplest cases [15:40] slangasek, the pastebin I did the other time is still there on http://paste.ubuntu.com/11757708/ if you want to see the configs [15:41] elopio, main.go is becoming a little hairy, maybe we can do this and other related stuff in a separate adtrun library [15:42] slangasek, seems like the snappy one is trying to boot the .efi.signed and the ubuntu one not [15:43] seb128: oh interesting! [15:44] linux /boot/vmlinuz-3.19.0-22-generic.efi.signed root=LABEL=system-a ro init=/lib/systemd/systemd [15:44] vs [15:45] linux /boot/vmlinuz-3.19.0-22-generic root=UUID=c019e487-1263-4559-90d8-af732fa72ef1 ro init=/lib/systemd/systemd [15:45] [15:45] also one uysing disk label [15:45] disk->partition [15:45] but I guess that's not the issue [15:46] uh [15:46] you definitely dont want a UUID in there [15:48] vmayoral|pc: pong [15:48] ppisati: hi [15:48] vmayoral|pc: hi [15:49] ppisati: I'm trying to update our images on the BeagleBone Black with the newer kernels (our images still rely on http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_beagle_3.8) [15:50] fgimenez: +1 to that too. If we make main.go an adt-run setup script, then it will be a lot easier for the CI machinery, if we ever get that. [15:50] ppisati: do you think I could have access to the kernel sources from the newer kernels (e.g. 3.19) [15:50] ppisati: or maybe even better, 4.+ [15:51] vmayoral|pc: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/ [15:51] vmayoral|pc: that's the src code for the 3.19 kernel [15:52] vmayoral|pc: we don't support 4.x yet [15:52] ppisati: ok, is there a specific branch for the BeagleBone Black? [15:52] vmayoral|pc: nope, it's the master branch [15:52] vmayoral|pc: just compile it for armhf [15:53] vmayoral|pc: here is an howto for cross compilation [15:53] vmayoral|pc: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile [15:54] vmayoral|pc: branch master [15:54] ppisati: thanks, unfortunately, I believe that won't do because we make use of the patches from BeagleBoard. [15:54] fgimenez: we have a lot of lint errors, mainly for missing comments. I'll fix that. [15:54] ppisati: do you believe it's possible to rebase Ubuntu's patches on top of https://github.com/beagleboard/linux? [15:54] elopio: I'm not using go-benchmark, its currently not very reproducable, but go benchmark is a nice idea [15:55] ppisati: i tried doing so with the apparmor ones you did before at http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_beagle_3.8 [15:55] ppisati: but I failed miserably [15:55] vmayoral|pc: isn't that the 3.8 kernel you are talking about? [15:57] ppisati: mmm maybe i didn't express myself appropriately, 3.8 kernel is working great after your help last time, however we'd like to move to 3.19 (and make use of the latest Snappy image release by you guys) [15:58] vmayoral|pc: so you don't want the ubuntu patches on top of the beagleboard kernel [15:58] vmayoral|pc: you want the beaglebone patches on top of the ubuntu vivid kernel [15:59] vmayoral|pc: and sorry, but it's too much work [15:59] ppisati: i'm fine having the ubuntu patches on top of beagleboard's if that's possible [15:59] i tried that myself [15:59] but failed [15:59] vmayoral|pc: but that's your situation now [15:59] vmayoral|pc: isn'it? [15:59] ppisati: for the 3.8 yes, but not for newer kernels [16:00] is that still the old capemgr issue ? [16:01] or what are these BBB patches ? [16:01] ogra_: yes, it's that [16:01] * ogra_ thought there would be a proper replacement by now [16:01] i believe capemgr has been integrated in 4+ kernels which is why I started that way the conversation [16:04] elopio, ok thanks flycheck can catch these too http://i.imgur.com/uKG1pll.png [16:08] fgimenez: my goal for today is to have a pretty emacs like you :) [16:08] ogra_: mvo builds are broken -> cp: cannot stat 'debian/tmp/share': No such file or directory [16:08] any idea what caused that? [16:08] alos, what's up with all the 'ar: `u' modifier ignored since `D' is the default (see `U')' [16:09] sergiusens, ? [16:09] got a log or something ? [16:09] ogra_: https://launchpadlibrarian.net/210353958/buildlog_ubuntu-wily-powerpc.ubuntu-snappy_1.2-1%2B538~ubuntu15.10.1_BUILDING.txt.gz [16:10] ogra_: or here https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily-wily [16:11] ogra_: that ar thing only shows up on powerpc, but the cannot stat on all [16:11] elopio, didn't know of this nicety before! :) [16:12] sergiusens, that looks to me like there is a wrong path in a .install or .dirs file [16:12] ogra_: yeah, I'm not aware of approving anything like this from the queue though [16:13] ogra_: I'll check after lunch [16:13] * sergiusens is starving [16:14] i guess the ar message can be ignored (not sure though) since you newly create the archive ... so "u" = update ... wouldnt update anything [16:14] nice evening everyone o/ [16:15] ppisati: I quickly tried grabbing the latest image provided by you guys and replaced the kernel with the 3.8 [16:16] ppisati: seems promising, so i think we can go that way [16:16] ppisati: long term, i'd like to put some of my time supporting newer kernels [16:19] ppisati: If you don't mind, i'd like to run my thoughts through you regarding "the beaglebone patches on top of the ubuntu vivid kernel". You already shared that it'll be a substancial amount of work. My approach will be to find a common commit and start analyzing commits from that point [16:20] ppisati: is there a better way to approach it? [16:21] sergiusens, looking at debian/rules i dont even see why it would do this extra dh_install call at all ... i wonder if the golang debhelper bits changed [16:22] sergiusens, it definitely finishes fine in the "override_dh_auto_install" part ... [16:30] sergiusens, hmm though i see the dh_install in a successfull build too... very weird [16:48] sergiusens, http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/revision/527 ... that has changes to debian/rules ... blame mvo :P [16:53] ogra_: oh, I broke it? let me see [16:54] mvo, https://launchpadlibrarian.net/210353958/buildlog_ubuntu-wily-powerpc.ubuntu-snappy_1.2-1%2B538~ubuntu15.10.1_BUILDING.txt.gz [16:54] make[1]: Leaving directory '/«PKGBUILDDIR»' [16:54] dh_install -a -O--buildsystem=golang -O--fail-missing [16:54] cp: cannot stat 'debian/tmp/share': No such file or directory [16:54] dh_install: cp --reflink=auto -a debian/tmp/share debian/ubuntu-snappy-cli//usr/ returned exit code 1 [16:55] * mvo looks [16:55] thanks ogra_ [17:07] webdm seems to be failing with the new BBB image https://gist.github.com/vmayoral/371b1c10fdaed445353d [17:07] tried restarting the service but keeps failing [17:07] (the BBB doesn't have access to Internet but i'd be surprised if this is the cause) [17:08] well, if there is no network interface up it cant start avahi [17:08] so i think thats kind fo expected ... (how would you access webdm without network anyway) [17:12] ogra_: there're network interfaces up but none with access to the Internet. Previous Snappy images didn't fail when launching webdm in this scenario [17:12] good to know though, thanks [17:13] well, does the interface have an IP ? [17:13] or is it just up [17:13] launchpad is angry today. [17:14] yeah, i had various 503's here tha last hour [17:14] ogra_: they've got IP addresses (e.g. I'm using usb0 in an ethernet-over-usb configuration for debugging) [17:16] vmayoral|pc: pastebin the output of sudo journalctl -u webdm_snappyd_0.9.service (or the corresponding version number) [17:18] sergiusens: https://gist.github.com/vmayoral/a6995881699d05a6d3ea [17:18] systemd-analyze plot has been fixed in the new image :)! [17:19] vmayoral|pc: yeah, as ogra_ says, it's avahi, I might need to do something for this not to happen, do you mind sharing your network config? (with ifconfig or ip) [17:20] sergiusens: https://gist.github.com/vmayoral/d24efe6b378e0d959237 [17:20] any chance someone can have a look at this svg https://gist.github.com/vmayoral/61f880c0663ac6187316? [17:21] Snappy takes 73s to finish booting, i'd to love to reduce this [17:22] because you have no eth0 i bet [17:22] bah, that svg cant be easily opened from the browser [17:22] we've had a few demos with Snappy and people always ask why it takes so long to boot :( [17:23] ogra_: let me export to it png and upload it somewhere [17:23] no, its fine ... [17:23] my snappy boots in 3 seconds [17:23] dropping the RAW url into eog works [17:24] longsleep: 3 seconds! that'll be sweet [17:24] yeah, looks like cloud-init starts really late there ... [17:24] most likely due to waiting for some network timeout [17:24] i still haven't tinkered much into the image so i presume most BBBs should have a similar booting time [17:25] s/tinkered/hacked [17:27] cloud-init-local.service takes about 18 seconds [17:27] vmayoral|pc, try removing /etc/network/interfaces.d/eth0 and reboot ... see if that changes anything [17:27] Is this the first boot? [17:27] cloud init creates all the keys and stuff on first boot [17:27] that takes a while [17:27] longsleep, no, but it behaves like the first boot ... [17:27] ah [17:28] well - then i do not know why cloud init ever should be blocking [17:28] even if it takes 18 seconds [17:28] becaue its slow ... python on arm etc etc :P [17:29] depends on the arm i guess - quad core 1.5GHz is fast [17:29] this is a 1 GHz single core cortex-A8 [17:29] well, you are spoiled :P [17:29] hehe - true i guess [17:29] vmayoral|pc, single ? [17:29] i thought it is dual [17:30] ogra_: the BBB has a single ARM core [17:30] oh [17:30] * ogra_ always thought it was a dual core [17:30] but it includes 2 additional PRUs (programmable real time units) [17:30] well then - you will not get 3 seconds boot with that :) [17:30] quite useful but not in this particular case i'm afraid [17:30] no, but 30+ should be achievable [17:30] if everything behaves [17:31] that's sort of like what i was aiming for, I got those booting times with previous Ubuntu images [17:31] (Trusty images) [17:31] mhm ok - if half of it is cloud init with 18s .. [17:31] still feels way to long [17:32] i wonder if cloud-init can even handle usb0 interfaces [17:32] might be that that is confusing it and making it generate new ssh keys every boot or some such [17:33] ogra_: i've debugged the boot of the BBB with a serial cable and i don't see the keys being generated every time [17:33] yeah that sounds plausible - the webdm error indicates that the system is busy and fails to start webdm in time [17:33] well, then it is something else in cloud-init [17:34] mvo: native? [17:34] thats one thing i wanted to ask - why is cloud-init even in there? [17:34] well, at least that avoids future quilting... [17:35] here's the booting process https://gist.github.com/vmayoral/1c6831bbbb2444ba8fe6 [17:35] it seems half of cloud-init is disabled anyway - i was investigating how i can resize the app space to use full card on boot [17:36] well it takes 8 seconds to load and unpack the initramfs already [17:39] so it essentially booted up after 10 seconds which is fine. All the rest is systemd doing startup. [17:39] i would uninstall webdm first as this seems broken and then disable cloud-init to start on boot and see how this goes [17:42] longsleep: let me try that [17:47] improved to 51 seconds [17:48] no cloud-init ? [17:48] sorry, 59, not 51. [17:49] I did "systemctl disable cloud-init" [17:49] but didn't seem to disable it, am i missing something [17:49] ? [17:49] i guess it is with some .service suffix [17:49] try systemctl status to get the names [17:50] it has even 4 services [17:50] elopio: is lp still behaving badly for you? [17:50] cloud-init-local.service, cloud-init.service, cloud-config.target, cloud-config.service, cloud-final.service [17:51] i am travelling right now, and do not have a snappy at hand to check the exact way to disable it [17:53] ok, all disabled, retrying [17:55] mmm odd, still something's going on [17:55] https://gist.github.com/vmayoral/eac1c483fc97547281d2 [17:56] vmayoral|pc: check if cloud-init is really disabled. I have to leave now - if this does not help then start to disable even more to figure out where it is loosing time [17:56] longsleep: sure, thanks for your help! [17:56] hey so if i use this u-d-f for downloading personal image....what happens ? does it simply download it into ~/.cache? or does it actually try to install ? [17:56] it still runs cloud-init [17:57] kgunn: it creates an img you can put anywhere that you see fit [17:57] sergiusens: ah...really, creates it on the fly ? [17:57]