[00:00] <genii> Maybe check if there's some settings related to video cards in /etc/default/grub  ( like nomodeset or VGA=### )
[00:00] <bigstu80> genii: yeah I've tried a few /etc/default/grub settings like nomodeset nofb and others
[00:01] <bigstu80> sarnold: OK I'll check that log location
[00:02] <genii> All settings related to video cards in /etc/default/grub should be removed and grub-update and update initramfs   ran. Because trying to have grub do actions on nonexistent hardware often makes it choke
[00:03] <bigstu80> genii: OK I didn't do update initramfs, just update grub
[00:03] <bigstu80> I'll take another look at the settings
[00:03] <genii> Also if you installed proprietary drivers for the videao card that was in it at the time, remove those
[00:04] <bigstu80> nope, all vanilla
[00:04]  * genii wanders off for beer and hockey
[00:06] <bigstu80> genii: thanks for the input o/
[00:07] <genii> :)
[00:09] <Industrial> Hi. I am trying to run conjure-up but I get an error about /home/tom/.config/juju/accounts.yaml not existing
[00:09] <Industrial> I want to deploy Kubernetes locally
[00:09] <nacc> stokachu: --^
[00:09] <bigstu80> also thanks sarnold
[00:10] <Industrial> For development purposes.
[00:11] <Industrial> Well, for learning to write apps for and deploy apps in kubernetes.
[00:12] <sarnold> my pleasure bigstu80 :) I hope this one works out fo ryou :)
[00:12] <Industrial> I have this React + Redux + GraphQL + PostgreSQL blog (yes :p) that I want to use to achieve continuous deployment with in a development/test environment
[00:14] <sarnold> Industrial: are you trying to install strictly on localhost or are you trying to install to a public cloud or private lcoud? I know next to nothing about conjure-up but I do know it's pretty flexible..
[00:24] <Industrial> sarnold: on localhost
[01:47] <stokachu> Industrial, ah
[01:48] <stokachu> Industrial, can you pastebin ~/.cache/conjure-up/conjure-up.log
[01:48] <stokachu> i really need to surface that error better
[01:50] <Industrial> stokachu: https://gist.github.com/Industrial/bf0b1b812f21252d0add2d2a5209054e
[01:50] <Industrial> when I run the IPv6 ting it says not found
[01:51] <stokachu> what version of lxc?
[01:51] <stokachu> lxc version
[01:51] <stokachu> im going to fix that incorrect error now too
[01:52] <stokachu> Industrial, ^
[01:53] <Industrial> 2.4.1
[01:53] <stokachu> Industrial, what does `lxc network set lxdbr0 ipv6.nat false` show?
[01:54] <Industrial> error: not found
[01:54] <stokachu> Industrial, what about sudo lxd init
[01:55] <Industrial> https://gist.github.com/Industrial/6b7543151c058998152d19721f313d2a
[01:55] <stokachu> hmm looks right
[01:56] <stokachu> Industrial, ive got some new code that does add some better lxd handling. you'll need to `apt-get remove conjure-up`, `sudo snap install --classic --edge conjure-up`
[01:57] <stokachu> Industrial, also you installed lxd from their ppa?
[01:59] <stokachu> brb grabbing drink
[02:00] <Industrial> I think I had it installed. I'm not sure.
[02:00] <Industrial> (as in I didnt know it was installed)
[02:00] <stokachu> Industrial, you on xenial?
[02:01] <stokachu> b/c 2.0.8 is the latest from the archive which is nbd i jsut wanted to try to reproduce with your version
[02:02] <Industrial> No, on yakkety
[02:02] <stokachu> ah ok
[02:02] <stokachu> well the snap version doesn't work on yaketty because of some iptables rules changes
[02:02] <stokachu> lemme install from the ppa
[02:05] <stokachu> Industrial, whats `lxc network show lxdbr0` print out?
[02:06] <Industrial> name: lxdbr0
[02:06] <Industrial> config: {}
[02:06] <Industrial> managed: false
[02:06] <Industrial> type: bridge
[02:06] <Industrial> usedby: []
[02:07] <stokachu> Industrial, can you do `lxc network delete lxdbr0`; `sudo lxd init` again
[02:07] <Industrial> What happened what this I think: I did a `sudo lxd init` configuration wrong and it made the networks. Is there a way I can undo everything lxd init does and retry it clean?
[02:07] <Industrial> ok
[02:07] <Industrial> right that
[02:08] <Industrial> stokachu: hmm. it says error: not found on that delete :S
[02:08] <Industrial> show shows it :S
[02:08] <stokachu> hrm
[02:09] <Industrial> It does it too on other networks (just tried docker0 for example)
[02:09] <stokachu> Industrial, whats lxc network list
[02:10] <Industrial> https://gist.github.com/Industrial/afe1deda3881be35d92b98c0d4570b8d
[02:10] <stokachu> ah it's not managed by lxc
[02:10] <stokachu> Industrial, do `sudo ip addr flush dev lxdbr0`; `sudo ip link set dev lxdbr0 down`
[02:11] <stokachu> then try to re-run sudo lxd init
[02:12] <Industrial> https://gist.github.com/Industrial/d5681d7b278996da2acbdaa884aeae9d
[02:12] <Industrial> stokachu: ^
[02:12] <Industrial> am I filling it in correctly though?
[02:12] <Industrial> I'm just saying yes to everything except ipv6
[02:12] <stokachu> yea you are doing it right
[02:12] <Industrial> ok
[02:12] <stokachu> one sec
[02:14] <stokachu> Industrial, ok, `sudo apt-get install bridge-utils`; `sudo brctl delbr lxdbr0`
[02:22] <Industrial> stokachu: sorry, ISP disconnected :S
[02:22] <stokachu> Industrial, all good, did you see the "  `sudo apt-get install bridge-utils`; `sudo brctl delbr lxdbr0`"
[02:23] <Industrial> ok done
[02:23] <Industrial> LXD has been successfully configured.
[02:24] <Industrial> \o/
[02:24] <stokachu> \o/
[02:24] <stokachu> give conjure-up another go
[02:24] <Industrial> thx man :)
[02:24] <stokachu> Industrial, actually
[02:24] <Industrial> k
[02:24] <stokachu> Industrial, do `conjure-up -d kubernetes-core localhost`
[02:24] <stokachu> that'll doa headless and surface any other errors
[02:25] <sarnold> does that send errors right to stdout or stderr and bypass logs?
[02:25] <stokachu> well does both
[02:25] <stokachu> journalctl -f is nice too
[02:26] <stokachu> but yea conjure-up tui needs to surface that juju != ipv6 behavior better
[02:26] <stokachu> Industrial, if you get pass the bootstrapping part you're good
[02:28] <stokachu> Industrial, yea just ran it on my yaketty with those commands and it works
[02:29] <Industrial> https://gist.github.com/Industrial/fed01c80695bf3008c7f9b8d6dfc0dba
[02:29] <Industrial> is what I'm getting
[02:29] <Industrial> I must have a broken ubuntu install allready =(
[02:29] <stokachu> nah thats a bug
[02:29] <Industrial> I wish you could like "diff" your whole system vs the base image to find out what you have changed :P
[02:30] <stokachu> Industrial, do you have an /etc/default/lxd-bridge file?
[02:30] <Industrial> no
[02:30] <stokachu> hmmm
[02:30] <sarnold> Industrial: heh yeah that'd be nice
[02:31] <stokachu> Industrial, try this for me
[02:31] <stokachu> Industrial, sudo apt-add-repository ppa:conjure-up/daily-git
[02:31] <stokachu> sudo apt-get update && sudo apt-get upgrade
[02:31] <stokachu> i got some better lxd code handling in there
[02:31] <stokachu> looks like youre running 2.0.1 conjure-up
[02:34] <Industrial> ah it's running now :D
[02:34] <stokachu> cool
[02:34] <Industrial> Bootstrapping juju-controller
[02:34] <stokachu> yea should be good
[02:35] <stokachu> Industrial, https://gist.github.com/battlemidget/677aab92efa6347a61b724410d454baa
[02:35] <stokachu> that's what you shoudl see at the end
[02:35] <Industrial> I'm doing this all just to try out kubernetes, to see if I can deploy my docker/docker-compose app to kubernetes
[02:36] <stokachu> Industrial, you'll need some sort of storage which we dont setup automatically on lxd
[02:36] <stokachu> easiest thing is to setup nfs and have kubernetes use that
[02:37] <stokachu> but this is vanilla kubernetes so most tutorials online will work
[02:37] <Industrial> Ok cool. So what did I just install really? Can I compare it to like a Vagrant setup of Kubernetes (which I also found)
[02:38] <stokachu> Industrial, if you run `juju status` it'll list all the components
[02:38] <Industrial> Or it all runs on docker containers right on the host
[02:38] <stokachu> so kubernetes and it's deps run in seperate lxd containers
[02:38] <stokachu> but when you deploy your apps on kubernetes it's all docker
[02:38] <Industrial> aw i got an error
[02:38] <Industrial> https://gist.github.com/Industrial/cfb4e09506dda9aed3bf619efa2e1360
[02:39] <Industrial> right ok
[02:39] <stokachu> what's juju status show
[02:39] <stokachu> sorry `juju status`
[02:39] <Industrial> its taking a while
[02:40] <stokachu> https://gist.github.com/battlemidget/1f51b834b59b2e3be216a8d8c2a07dbf
[02:40] <stokachu> that's what you should see
[02:41] <Industrial> it's not printing anything
[02:41] <Industrial> it hangs
[02:41] <stokachu> how about `juju controllers`
[02:42] <Industrial> conjure-up-localhost-777*  conjure-up-kubernetes-core-2f1  admin  superuser  localhost/localhost       2         1  none  2.0.0
[02:42] <stokachu> hmm
[02:42] <stokachu> so thats the initial 2.0 juju release
[02:43] <stokachu> Industrial, do `juju kill-controller conjure-up-localhost-777`
[02:43] <stokachu> then, `sudo apt-add-repository ppa:juju/stable && sudo apt-get update && sudo apt-get upgrade`
[02:43] <stokachu> make sure youre on juju version 2.0.2
[02:43] <stokachu> then re-run `conjure-up -d kubernetes-core localhost`
[02:46] <Industrial> right. Thanks for all the help, by the way :-)
[02:46] <stokachu> Industrial, anytime, we should get thsi going soon
[02:46] <Industrial> so these lxd containers start at ubuntu startup? So Kubernetes as well?
[02:47] <stokachu> Industrial, yea
[02:47] <stokachu> they're set to autostart in the lxc config
[02:47] <Industrial> cool, really nice
[02:47] <stokachu> yea keeps things really clean so it doesn't mess with your host system
[02:51] <Industrial> I got the same error, but with juju 2.0.2
[02:52] <stokachu> Industrial, does juju status return anythign?
[02:52] <Industrial> no
[02:52] <stokachu> hmm
[02:53] <stokachu> Industrial, is this system accessible for me to login too?
[02:54] <Industrial> no, it's my laptop unfortunately :)
[02:55] <stokachu> ok hmm
[02:55] <stokachu> Industrial, can you paste ~/.cache/conjure-up/conjure-up.log
[02:57] <Industrial> https://gist.github.com/Industrial/dd4b41f59dff1737d7f84e4c78660404
[02:59] <stokachu> Industrial, there should be a ~/.cache/conjure-up/kubernetes-core/*.err/*.out can you paste thsoe as well?
[03:01] <Industrial> https://gist.github.com/Industrial/5084668e11d46dd7d0bf231a1596cade
[03:01] <Industrial> the out is empty
[03:02] <stokachu> Industrial, juju status still not responding?
[03:03] <Industrial> none
[03:04] <stokachu> well that's disappointing
[03:04] <stokachu> Industrial, what about `juju models`
[03:07] <Industrial> also hangs
[03:07] <Industrial> controllers shows the one again
[03:08] <stokachu> Industrial, try this, `juju bootstrap --debug lxd/localhost`
[03:08] <stokachu> once that finishes try just a `juju status`
[03:20] <Industrial> stokachu: okay
[03:20] <stokachu> Industrial, work?
[03:21] <Industrial> copying image now
[03:21] <stokachu> ah lxd image?
[03:22] <Industrial> seeing a bunch of 200 response jsons now
[03:22] <stokachu> talking to lxd
[03:29] <Industrial> it keeps on doing that
[03:30] <stokachu> Industrial, yea there is something screwy going on
[03:30] <stokachu> not sure if it's lxd related
[03:30] <stokachu> Industrial, can you paste the log?
[03:37] <Industrial> stokachu: it's way more then my terminal can log before it stops
[03:38] <stokachu> ok
[03:38] <Industrial> when it stops it floods some more into the terminal and the rest is gone
[03:38] <Industrial> so I only see the stop requests
[03:38] <stokachu> Industrial, does lxc list show any vms?
[03:38] <stokachu> containers i should say
[03:38] <Industrial> https://gist.github.com/Industrial/28b3c013a646e808e0dfd7926244b616
[03:40] <stokachu> ah
[03:40] <stokachu> i see
[03:40] <tsimonq2> @s/or
[03:40] <tsimonq2> Whoopsie
[03:40] <stokachu> Industrial, lxc delete  juju-6fa2a6-0 --force; lxc delete  juju-6fa2a6-1 --force; lxc delete juju-79d91c-0 --force
[03:41] <stokachu> Industrial, once lxc list is empty
[03:41] <stokachu> re-run conjure-up -d kubernetes-core localhost
[03:41] <Industrial> okay
[03:42] <Industrial> ok its doing some new stuff now; creating a juju model
[03:42] <stokachu> w0rd
[03:46] <stokachu> Industrial, where is it at now?
[03:46] <stokachu> Industrial, whats lxc list look like as well
[03:47] <Industrial> still the same
[03:48] <Industrial> ] Using controller 'conjure-up-localhost-d20'
[03:48] <Industrial> [info] Creating new juju model named 'conjure-up-kubernetes-core-b7e', please wait.
[03:48] <Industrial> lxc list is empty
[03:48] <stokachu> ctrl + c that
[03:48] <stokachu> does juju controllers return anything?
[03:49] <Industrial> yes, one
[03:49] <stokachu> what's that output
[03:55] <stokachu> Industrial, ^
[03:56] <Industrial> conjure-up-localhost-d20*  conjure-up-kubernetes-core-c18  admin  superuser  localhost/localhost       2         1  none  2.0.2
[03:56] <stokachu> Industrial, juju kill-controller conjure-up-localhost-d20
[03:56] <stokachu> Industrial, them rm -rf ~/.local/share/juju
[03:56] <stokachu> Industrial, then conjure-up -d kubernetes-core localhost
[03:57] <Industrial> ok
[04:09] <Industrial> stokachu: same thing. I think I might go with Vagrant for testing Kubernetes for now :-)
[04:09] <stokachu> heh
[04:09] <stokachu> ok
[04:14] <stokachu> mmcc, ^ apparently juju and lxd didnt cooperate here
[06:50] <pyromax> Hi?
[06:53] <pyromax> Does anybody have any experience with LVM?
[07:28] <pyromax> help?
[07:57] <alkisg> pyromax: can you phrase your question again?
[12:10] <zenirc369> Hi guys
[12:10] <zenirc369> Chain INPUT (policy DROP)
[12:10] <zenirc369> DROP       all  --  anywhere             anywhere
[12:10] <zenirc369> ACCEPT     tcp  --  IP1         anywhere            tcp dpt:Port1 state NEW,ESTABLISHED
[12:10] <zenirc369> ACCEPT     tcp  --  IP2         anywhere            tcp dpt:Port2 state NEW,ESTABLISHED
[12:11] <zenirc369> In the above case how does the DROP rule behave?
[13:35] <jayjo> how do I exclude filepaths in scp?
[13:35] <jayjo> I want to scp my home directory, but skip any directory titled venv (which is a python virtualenv and the directories are massive)
[13:36] <hateball> jayjo: use find to filter what you want, pass to scp with xargs?
[13:36] <hateball> I dont think scp has any form of exclude flag
[13:36] <jayjo> ok, thank you
[13:39] <coreycb> cpaelzer, zul, ok seeing this in b3 ocata-staging testing now: http://paste.ubuntu.com/23918074/
[13:40] <zul> erm...
[13:41] <zul> coreycb: try just installing qemu-kvm and seeing what happens?
[13:52] <zul> coreycb: going to try to reproduce it here
[13:54] <cpaelzer> coreycb: zul: yeah I see it - but only on ppc
[13:55] <cpaelzer> zul: if you are already retrying please let me know what it is or should I try as well?
[13:56] <cpaelzer> zul: coreycb: the new qemu hit proposed - see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:56] <cpaelzer> zul: coreycb: maybe something missing there - the error there is the nova ppc issue zul tried to recreate but didn't show up
[13:56] <cpaelzer> on the retries
[13:56] <coreycb> cpaelzer, zul: i have to guess that's related to this
[13:57] <zul> cpaelzer: i think it might it be different not sure yet
[13:57] <coreycb> zul, cpaelzer: because deploying xenial-ocata-staging yesterday didn't hit this.  and staging just got the new qemu 18 hours ago.
[13:57] <zul> cpaelzer: did you mention something about xen?
[13:57] <cpaelzer> zul: yep
[13:58] <cpaelzer> zul: it is also waiting
[13:59] <smb> cpaelzer, To answer the question ahead: I had no chance yet to talk to Andy
[13:59] <cpaelzer> smb: I just wanted to point to you :-)
[13:59] <smb> :) Hence the answer. But I still will try to look into it today
[13:59] <cpaelzer> zul: coreycb: the TL;DR of the bit I know is that xen and libvirt (rebuild for xen) currently don't migrate as the detection says they make certain packages uninstallable
[14:00] <cpaelzer> zul: coreycb, but tested effectively all are fine
[14:00] <zul> ok
[14:00] <cpaelzer> zul: coreycb: I had a writeup and smb (who did the xen/libvirt upload) wanted to talk to Andy as AA what it might be
[14:01] <cpaelzer> zul: coreycb: since it has nova in the names FYI http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[14:01] <cpaelzer> zul: coreycb: I beg a pardon for the initial german chat :-)
[14:01] <cpaelzer> but I couldn't find whats going on without help :-)
[14:02] <zul> cpaelzer: no worries im still waking up so everything is german
[14:03] <cpaelzer> hehe
[14:07] <zul> coreycb: we need a newer seabios
[14:08] <coreycb> zul, is that it?
[14:08] <zul> coreycb: http://pastebin.ubuntu.com/23918257/
[14:08] <coreycb> zul, gotcha i see it now
[14:09] <coreycb> zul, cpaelzer, not sure why that was hit on ppc too but maybe seabios pkg wasn't available yet
[14:09] <coreycb> zul, cpaelzer: makes sense on xenial-ocata-staging because we have an older seabios
[14:11] <cpaelzer> coreycb: zul: I'm in meetings from now on the rest of the day - if the end of your checks end up thinking that I could/should do something would you drop me a mail so I can pick it up on Monday?
[14:11] <cpaelzer> If it is trivial I might do so on Weekend, but I just don't want to miss it
[14:12] <cpaelzer> the run before FF is usually a lot of depending on each other - I don't want to be the blocker here :-)
[14:12] <zul> cpaelzer: no worries well scream :)
[14:13] <cpaelzer> zul: since you could not reproduce it I'll hit retry on the dep8 test and see if it shows up again
[14:13] <cpaelzer> zul: ok with that?
[14:13] <zul> cpaelzer: i am
[14:14] <zul> coreycb: ^^^
[14:14] <coreycb> cpaelzer, sounds good
[14:14] <coreycb> zul, i'm  backporting seabios
[14:15] <zul> coreycb: i saw
[14:15] <zul> coreycb: there could possibly be others
[15:13] <kyle__> What is the deciding factor for which drivers make it into linux-image-<kernelver>-generic, and which end up in linux-image-extra-<kernelver>-generic?
[15:17] <ddstreet> coreycb i'll create a bzr repo, will take a bit as i'm not very familiar with bzr :)
[15:18] <coreycb> ddstreet,  i hear you.  i'll msg you some basics :)
[15:20] <lucidguy> Ok, when I het ~. It types out ~. .. not the exit/kill response of ssh or ipmitool .. what am I doing wrong?
[15:20] <coreycb> ddstreet, you can probably get away with just  'bzr branch lp:ubuntu-dev-tool', make your changes, 'bzr commit', write commit message, then 'bzr push lp:~ddstreet/ubuntu-dev-tool'
[15:21] <ddstreet> ok lemme try that :)
[15:23] <ddstreet> coreycb ok i think this has it https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/ubuntu-dev-tools
[15:23] <coreycb> ddstreet, i think so. taking a look.
[15:23] <ddstreet> i had to use 'bzr push lp:~ddstreet/ubuntu-dev-tools/ubuntu-dev-tools', just using one ubuntu-dev-tools was 'too short' apparently
[15:24] <ddstreet> thnx!
[15:54] <coreycb> ddstreet, ok i pushed that, now if we can get a debian developer to upload to deiban.  thanks for the updates!
[15:55] <coreycb> ddstreet, nice improvements
[15:55] <ddstreet> coreycb thanks!
[17:16] <EmilienM> coreycb: FYI on trove https://review.openstack.org/428816
[17:16] <EmilienM> not sure you test it (we do)
[17:22] <coreycb> EmilienM, do you have a link for the failure?
[17:22] <EmilienM> coreycb: sure, a sec
[17:23] <EmilienM> http://logs.openstack.org/88/428788/2/check/gate-puppet-openstack-integration-4-scenario003-tempest-ubuntu-xenial/302daab/console.html#_2017-02-03_16_30_24_398990
[17:23] <EmilienM> coreycb: ^
[17:23] <coreycb> EmilienM, thanks
[17:32] <coreycb> EmilienM, that appears to be fixed in b3 of trove: https://github.com/openstack/trove/commit/6d5c082d54001b29b262c9a2a1a4d7222911f2ba
[17:33] <coreycb> EmilienM, which we have in ocata-staging but we're debugging some issues before we promote to proposed
[17:33] <EmilienM> ok
[17:34] <EmilienM> coreycb: thx!
[17:35] <coreycb> EmilienM, np hope to have b3 promoted soon, or it might just be rc1 since that's already out
[17:36] <EmilienM> coreycb: please ping me or mwhahaha
[17:36] <coreycb> EmilienM, ok
[17:49] <joseki> hi all. i'm having a problem with multipath where i seem to have lost a superblock on a filesystem after trying to resize via rm/mkpart in parted
[17:50] <joseki> what options do i have for trying to find a valid superblock? I tried mke2fs -n /dev/mapper/mpatha-part1 and using the "backup location" reported there
[17:51] <joseki> i'm not using LVM
[18:05] <lucidguy> From my workstation I can ssh -A etc just fine into specific servers.  If I ssh into my workstation from another box and try the -A to the box that always worked it no longer does.  It's something to do with an ssh agent or something running, can someone remind how to resolve this?
[18:37] <sarnold> lucidguy: does your 'another box' have forwardagent turned off in the ssh configs?
[20:04] <coreycb> zul, cpaelzer, nova-compute seems better now with the new seabios
[20:10] <zul> coreycb: cool
[20:33] <shambat> I'm using Ubuntu 16.04 and I'm copying some files between harddrives, and it's very slow. I'm getting this over and over in my dmesg: https://hastebin.com/izixekibok.css /dev/sde is the device I'm writing to. My drives are attached via a LSI Fusion MPT SAS2 controller card.
[20:36]  * genii ponders https://hastebin.com/izixekibok.css
[20:37] <sarnold> shambat: you might want to give this tool a try http://blog.disksurvey.org/blog/2014/08/10/decoding-lsi-loginfo-codes/
[20:37] <sarnold> or look up0 the codes by hand http://blog.disksurvey.org/knowledge-base/lsi-loginfo/
[20:38] <genii> Looks suspiciously like this bug that's been known since 2013 at https://bugzilla.kernel.org/show_bug.cgi?id=60644
[20:41] <shambat> hm
[20:42] <sarnold> the final comments on the bug suggest disabling ASPM
[20:42] <sarnold> most reports involved sata drives, I wnoder if that's just because a lot of people use them, or if there's something slightly amiss with the sata tunnelling protocol they have to use
[20:44] <shambat> sarnold: that has to be done in the bios I take it?
[20:44] <shambat> disabling ASPM
[20:45] <sarnold> I think so
[20:46] <shambat> I may suddenly disappear :)
[20:50] <smoser> dannf, able to show me uname -a from a 64bit arm
[20:51] <dannf> Linux mustang 4.9.0-11-generic #12-Ubuntu SMP Mon Dec 12 16:21:56 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
[20:52] <dannf> smoser: ^
[20:52] <smoser> aarch64. thanks.
[20:52] <smoser> dannf, is that hardware or vm ?
[20:52] <dannf> smoser: hw
[20:53] <smoser> do youhappen to have a openstack anywhere with that ?
[20:53] <dannf> smoser: though, don't see why it would differ
[20:53] <dannf> smoser: i have a non-openstack vm
[20:54] <smoser> well, looking for wheter or not oipenstack puts dmi data into the system like it does on intel
[20:55] <genii> smoser: Someone in #ubuntu-arm might know
[20:56] <dannf> smoser: there is dmi data - but in the uname?
[20:56] <dannf> Linux ubuntu 4.9.0-15-generic #16-Ubuntu SMP Fri Jan 20 15:29:58 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[20:56] <dannf> smoser: ^
[20:57] <dannf> that's a vm that has dmi tables
[20:57] <dannf> but no, no openstack setup atm
[20:58] <smoser> right.
[20:59] <dannf> smoser: beisner may have an arm openstack up
[21:00]  * beisner checks a thing..
[21:09] <beisner> smoser, yep, got stuff online if you need it.
[21:10] <beisner> smoser, from an aarch64 xenial nova instance: Linux xenial-uefi-20170119b210515 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:37:14 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[21:13] <smoser> beisner, ah.
[21:13] <smoser> can hyou
[21:13] <smoser> sudo grep -r . /sys/class/dmi/id
[21:13] <smoser> rharper, ^
[21:14] <beisner> smoser, http://pastebin.ubuntu.com/23920627/
[21:14] <rharper> beisner: cool!
[21:14] <rharper> boo
[21:15] <rharper> it really should have OpenStack Nova in there like on x86
[21:15] <beisner> ha!
[21:15] <rharper> same issue on power as well
[21:16] <rharper> % cat /sys/class/dmi/id/product_name
[21:16] <rharper> OpenStack Nova
[21:17] <beisner> KVM Virtual Machine
[21:17] <rharper> right that's not specific enough to know it's a VM on Openstack Cloud
[21:18] <rharper> you'll get that with any qemu-system-$arm_arch machine
[21:18]  * beisner is missing context but trusts that smoser and rharper know way more than i've ever forgotten about that.
[21:18] <rharper> we're looking at ways for clouds to identify what they are w.r.t DataSource we can expect
[21:19] <rharper> on x86, all the VMs in Openstack have the 'OpenStack Nova'  this is set via qemu's -smbios parameter for x86;
[21:19] <rharper> aarm64 has DMI tables now, but I'm guessing since their uefi vs. bios-based qemu probably hasn't exposed an interface for auto-generating those tables at runtime;  however, they do for example pass -uuid through in 'product_uuid'
[21:20] <rharper> so, it can be done, it's a matter for getting it upstream I suppose (or if upstream, getting libvirt to set the value)
[21:20] <budfox> Hi! Anybody ever experienced abrupt npm ECONNRESET errors on Ubuntu Server 16.04.1/VirtualBox 5.1.4? https://gist.github.com/anonymous/aca183d181bec293c619133922f07fe6
[21:22] <beisner> rharper, ah tricky
[21:23] <rharper> beisner: would you be able to paste the qemu command line running that instance on the compute node ?
[21:24] <beisner> rharper, libvirt log for that instance shows the cmd i believe: http://paste.ubuntu.com/23920679/
[21:25] <beisner> rharper, that's xenial-mitaka, firing up a mitaka instance.
[21:25] <beisner> err, xenial instance ;-)
[21:28] <jge> hey all, anyone ever played with FastNetMon?
[21:29] <blueking> is it doable to disable dhcpd server without removing config files/setup ?
[21:30] <blueking> ubuntu server 16.04
[21:30] <compdoc> you should be able to stop the service from running
[21:30] <blueking> stop et restart at boot ..
[21:31] <compdoc> not just that. I mean disable it
[21:31] <blueking> just mv file from init ?
[21:31] <rharper> beisner: one more, if you can: on the node, qemu-system-aarch64 --help &>  help.out ;  I'm interested in the cli switches exposed there
[21:31] <compdoc> no, just a command
[21:32] <compdoc> systemctl disable SERVICE - Turns the service off on the next reboot or on the next stop event. It persists after reboot.
[21:33] <beisner> rharper, sure: http://paste.ubuntu.com/23920715/
[21:33] <compdoc> dont want to move files frm init
[21:33] <rharper> ah ha!
[21:34] <rharper> smbios type=1[,manufacturer=str][
[21:34] <beisner> rharper, also - happy to let you poke around the compute node + instance.  it'll be online at least through monday mid-day.  after that i'll be doing crazy things with the kit.
[21:34] <rharper> looks like we can get an update to nova-compute on aarch64 nodes to pass in the OpenStack Nova string to the type 1 table
[21:35] <rharper> beisner: ok; it would be fun to shutdown an instance, update the xml to include the manufacture element used on x86  and reboot to confirm that we can see OpenStack Nova in the aarch64 dmi tables
[21:36] <beisner> our perspectives on fun may differ, rharper ;-)  send you the fun keys momentarily
[21:36] <rharper> hehe
[22:13] <budfox> Oh well, guess npm won't work on Ubuntu either, next stop Debian!