[00:09] cool that seemed to work ok cheers sarnold for the assistance [00:09] manukapua: don't forget to put back the -meta kernel package if you removed it earlier, to keep getting kernel updates [00:10] its still there : ) [00:22] Anyone know if when 'unattended-upgrades' is set to download the packagelist, does it download an entire packagelist or just the 'allowed' repository parameters you have set, like 'security' === Tsunami is now known as Guest18089 [06:20] Good morning [11:50] coreycb, rbasak at SWITCH testing our new Xenial/Newton setup we figured out that we are hitting this bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389 This must be fixed before we can move on from Trusty/Mitaka. We need to bug fixed to be able to live-migrate VMs safely, because we evacuate the nova-compute nodes to reprovision them with [11:50] Xenial/Newton. Do you know about this bug ? [11:50] Launchpad bug 1647389 in qemu (Ubuntu Xenial) "Regression: Live migrations can still crash after CVE-2016-5403 fix" [High,Confirmed] [11:52] I don't know about it, sorry. [11:52] I'd ask cpaezler but he's out [11:52] jgrimm: ^ [11:53] rbasak: but you commented on the bug :O ! [11:54] are you Robie Basak (racb) ? [11:54] zioproto: not with any knowledge, just referring more relevant people. [11:54] Yes. [11:54] ah ok :) [11:54] I all come back here when is daytime in the US :) [11:57] zioproto, did you see the workaround mentioned? [11:57] zioproto, i'm just scrolling through the bug coming up to speed [11:59] coreycb: if you mean 'virsh dommemstat --live --period 0 ' we tried this and did not work [12:00] zioproto, it looks like turning live_migration_tunnelled off is a work around too [12:03] coreycb: ok, I found something else to check. We had the default value for live_migration_tunnelled [12:04] zioproto: FYI, there are _untested_ pre-release packages to work around that bug here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages [12:04] now it looks like Mitaka has live_migration_tunnelled default to True and Newton has live_migration_tunnelled default to False [12:04] thanks mdeslaur [12:05] they haven't had any sort of QA yet, but you're welcome to try them out in a test environment [12:05] mdeslaur: thanks ! I will try them ! [12:09] mdeslaur: the source server is Trusty, the destination server is Xenial. It is enough to install the qemu package on the Xenial server to test the live migration fix ? [12:10] zioproto: I think so, but I'm not sure, sorry. [12:11] rbasak: here chiluk is the expert on this bug [12:11] * cpaelzer is not here [12:13] and I see mdeslaur is also here, perfect [12:13] so I can be away then [12:13] * cpaelzer silences his speaker to not get back to the office on a highlight [12:16] I have a question on live_migration_tunnelled in nova.conf [12:16] so this is an important setting to be explicit in nova.conf on the controller or on the compute nodes ? [12:30] mdeslaur: so we installed qemu-system-x86_2.5+dfsg-5ubuntu10.11_amd64.deb and qemu-block-extra_2.5+dfsg-5ubuntu10.11_amd64.deb only. These packages we installed them only on the Xenial target compute-node. We did not touch at all the source Trusty compute node. I can confirm this packages fixed the bug #1647389 for me [12:30] bug 1647389 in qemu (Ubuntu Xenial) "Regression: Live migrations can still crash after CVE-2016-5403 fix" [High,Confirmed] https://launchpad.net/bugs/1647389 [12:31] zioproto: oh, great, thanks for testing it [12:31] my team here is thanking you, because these package repo is not linked on the bug report [12:32] I guess if the link was there more people had tested the packages, because 12 people are watching the bug [12:32] zioproto: they will be released as security updates once they have been through QA...probably in a couple of weeks [12:32] I'll add a comment to the bug [12:32] thank you [15:10] cpaelzer: re: LP: #1673714, what is dquilt? [15:10] Launchpad bug 1673714 in usd-importer "provide a subcommand to convert a git sha to ubuntu patch" [Undecided,New] https://launchpad.net/bugs/1673714 === JanC is now known as Guest75772 === JanC_ is now known as JanC === Guest18089 is now known as PacketSCan [16:00] /w/win 8 === Guest96888 is now known as IdleOne === nchambers is now known as Guest99703 === Guest99703 is now known as dtscode [16:40] quick question [16:40] the command route add is permanent [16:44] erick3k: that's not a question, but no [16:45] erick3k: if you reboot, the routes will be gone [16:53] hehe [16:55] nacc whats the best way to add them permanent that don't involve puting them in /etc/network/interfaces? [16:55] and apart from puting them in /etc/rc.local [16:55] or rc.local best way? [16:56] erick3k: any reason for not using /e/n/i ? [16:57] Yes, cloud-init will remove the post up / post down commands [16:57] in interfaces [16:57] so it has to be somewhere else [16:58] erick3k: that seems like soething to ask cloud-init about, i assume there is either a way to not do that or some config option [16:59] yes am sure cloud-init has an option, but my current system won't allow me [16:59] so forget about cloud-init [16:59] back to first question hehe [16:59] erick3k: will c-i remove /e/n/i.d entries too? [17:00] well am wrong, and you are kind of right [17:01] thats where ci puts the config [17:01] so i guess it doesn't touch interfaces [17:01] there you go :) [17:01] thats the best place anyway to put them permanent routes? [17:01] erick3k: aiui, but i'm not necessarily an expert on it :) [17:02] kool ty [17:02] erick3k: np [17:13] ummm [17:13] any ideas what can be wrong? looks good to me https://i.imgur.com/dyJhjhD.png [17:15] erick3k: do you have the `route` command? or what is happenig? [17:15] not sure, i am following this guide http://docs.ovh.ca/en/guides-network-bridging.html [17:16] but yea route command is there [17:16] i can use it manually to add the routes and works [17:16] erick3k: oh sorry misread the bottom f it [17:16] erick3k: which line is 14? [17:17] first post-up command [17:18] erick3k: oh of course [17:19] erick3k: it's an iface option [17:19] erick3k: what are you post-up'ing in that file? :) [17:19] umm the routes [17:19] erick3k: as in, post "what"'s up state woudl that command run? [17:19] erick3k: routes aren't up [17:19] it should run route add when the interface goes up [17:19] erick3k: right, *which* interface [17:19] erick3k: syntactically your file makes no sense [17:19] is on /.d [17:20] erick3k: post-up only makes sense in the context of a interface definition [17:20] ok so can't put them on .d cuz is gonna be modified by ci [17:20] so am stuck to rc.local then? [17:22] erick3k: so you want to add a route to a iface that c-i configures? [17:22] correct [17:22] ci configures on /e/n/i/.d [17:23] without having to tell ci to do it because i can't [17:24] i don't understand fully why you can't but ok [17:24] erick3k: you don't control your cloud-config? [17:24] erick3k: it seems like you can define routes vai systemd.network as well [17:25] yes and no, is limited. That would be the obvious solution but perhaps why am here looking for another solution [17:25] rc.local is gonna work, ive used before but i don't think is the best way [17:26] nacc i would have to somehow modify rhev completly, templates etc to be able to add routes on cloud-init launch [17:26] that is beyond me [17:26] thats why [17:26] erick3k: huh? [17:26] rhev / orvirt [17:26] erick3k: you aren't able to pass cloud-config to your instances? [17:26] yes [17:26] but limited config [17:27] so ovirt which is the system i use [17:27] erick3k: hrm, dunno [17:27] doesn't have an option to pass routes throught cloud-init [17:27] erick3k: but ok [17:27] so i simple can't use cloud init to pass routes [17:27] very simple [17:28] so i want permanent routes on the O.S [17:28] that has nothing to do with cloud-init [17:29] erick3k: but you can write arbitrary files? i'm super confused :) [17:34] nacc sorry got dced [17:35] but nvm i'll just stick to adding routes with rc.local [17:35] erick3k: yeah, i think that's easiest for wht you've described [18:27] has anyone had an issue where an upgrade on Xenial of mysql-server-5.7 would totally lag out and just consume all the memory and swap? [18:27] because that happened on my mail server :/ [18:44] hi [18:44] i see in ubuntu 16.04 /etc/init/rc-sysinit.conf was removed [18:44] what is it now? [18:46] I can't figure out what that thing's supposed to do.. [18:47] what thing [18:47] ? [18:47] erick3k: systemd aims to run multi-user.target, and runs whatever is supposed to be run to make that happen [18:47] erick3k: if you want to change the systemd target, this might help https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Targets.html#sect-Managing_Services_with_systemd-Targets-Change_Default [18:48] ummm [18:48] i just wanted to change start on (filesystem and static-network-up) or failsafe-boot [18:48] but is no longer in ubuntu 16 [18:49] 14 the file is there [18:49] what's the task that you're actually trying to solve? [18:51] my problems is network timeouts on boot [18:52] so i want to disable network to start on boot [18:52] or bypass all timeouts or waits for network [18:52] in centos i put ONBOOT=no [18:52] ubuntu 14 change start on (filesystem) [18:53] now on 16 i don't know [18:53] doesn't have same options as 14 [18:54] the root of the problem is that i don't use dhcp for network, instead i use static but is injected by cloud-init [18:54] and is done after the network is started [18:54] so it will timeout [18:56] sarnold this worked perfectly on ubuntu 14 [18:56] http://askubuntu.com/questions/185515/disable-network-configuration-services-during-boot-time [18:56] i want the same for ubuntu 16 [18:56] simple [18:57] ... I'm assuming you mean 14.04 and 16.04 respectively [18:57] correct [18:57] ( Y.ear Y.ear . M.onth M.onth ) -- sorry, that's a pet peeve of mine [18:57] but those files are not present on ubuntu 16.04 only in 14.04 [18:58] Right because it operates differently [18:58] You're seeing the timeout/delay? [18:58] yes [18:58] very long [18:58] Oh wait ... "instead I use static but is injected by cloud-init" [18:58] This is in what cloud provider? [18:58] yes [18:59] erick3k: please join #cloud-init and we can help debug from there [18:59] oh trust me [18:59] already tried [18:59] only one that can help is smores and he busy all the time [19:00] I work on cloud-init as well, have you filed a bug with the details ? [19:00] i know cloud-init has a timeout on cloud-init-nonet.conf that i already removed [19:00] am not looking for cloud-init timeouts but the looking for network in ubuntu 16 while booting [19:00] erick3k: Have you looked at /etc/network/interfaces yet? [19:01] yep, no timeout [19:01] No there wouldn't be there; that's not even a concept. [19:01] in general, the 'networking' service in 16.04 will look at the eni and for each iface thats marked 'auto'; it will wait for all of those to become up [19:01] Care to share your /etc/network/interfaces ? [19:02] if one or more of those marked auto does not come up, then the networking service itself blocks; [19:02] Yeah -- I was going to suggest changing the device from "auto" to "manual" in the config and then let cloud-init handle initializing it [19:02] It's not so much that it *blocks* [19:02] But that you never pass the network target and so never reach the multi-user target [19:02] but the service itself does block [19:02] that's by design [19:02] lord i just want the corresponding files /etc/init/failsafe.conf and /etc/init/rc-sysinit.conf but for ubuntu 16.04 that are no longer present [19:02] rharper: I'm saying this in systemd terminology [19:02] you told it, bring all of these interfaces up [19:02] I mean, it's a oneshot service, calling ifup and friends [19:03] so, is it systemd is it the unit script? [19:03] erick3k: The concept doesn't exist anymore; there is no corresponding files. [19:03] right [19:03] doesn't really matter; the effect is to block until all interfaces in eni marked auto are up [19:03] so i want to know where are the waiting for dhcp timeouts on boot [19:03] erick3k: The thing that those files were doing, that you needed to tweak -- it no longer exists. [19:03] You have a different problem. [19:04] logos01 i understand they no longer exist perhabs why am asking for a 16.04 solution [19:04] rharper: Well if you speak it in systemd nomenclature it helps you to troubleshoot/diagnose what/where is going on. [19:04] it does an ifquery --allow-auto to list the interfaces from eni which are marked auto; until ifup on each of those interfaces returns and they're up it blocks (for some fixed time) [19:04] erick3k: Right. Are the interfaces marked auto or manual in /etc/network/interfaces ? [19:05] logos01 they will be auto after cloud-init injects it [19:06] now say i seal the vm before using cloud-init [19:06] erick3k: Right but they're *NOT* auto when the VM is booting. [19:06] what should be on interfaces to avoid any timeouts [19:06] correct [19:06] so what should i put there [19:06] to avoid them timeouts [19:06] erick3k: Can we see your /etc/network/interfaces file? [19:07] auto lo [19:07] iface lo inet loopback [19:07] source /etc/network/interfaces.d/*.cfg [19:07] thats it [19:07] Okay what's in the /etc/network/interfaces.d/ directory? [19:07] so cloud-init will write a 'dhcp on "first" interface' on instances which do not provide a network configuration; if do not want cloud-init to attempt to configure networking via fallback, you can tell cloud-init to disable network configuration [19:07] https://i.imgur.com/EJDmklx.png [19:07] there's a 50-cloud-init eni file which will attemtp to dhcp on one of the interfaces [19:08] yes i can delete that 50-cloud-init.cfg before sealing the vm [19:08] thats not a problem [19:08] erick3k: lpaste the output of: `grep -H '' /etc/network/interfaces.d/*.cfg` [19:08] the only file that is on inderfaces.d will be deleted [19:09] before sealing the vm logos01 [19:09] so makes no sense showing you that file [19:09] Well this is where your problem is ... because the machine is attempting to dhcp up -- it has to, because that's how cloud-init *works* [19:09] right [19:09] Even if you get a static lease on whatever the following interface/address is, that's different. [19:10] no, you need to tell cloud-init via config that you don't want it to attempt ot configure networking; you can write out "network: {config: disabled}" into a /etc/cloud/cloud.cfg.d/network-disable.cfg [19:10] You're getting blocked because you're not *getting* dhcp addressing the machine is looking for. [19:10] so on ubuntu 14 i fixed by using those commands or mods i showed you on ask ubuntu [19:10] that prevents cloud-init from attempt to configure networking for you [19:10] erick3k: That didn't actually fix the problem in question. 14.04 used a *completely different* networking model than 16.04 [19:10] All it did was make the problem non-blocking to boot. [19:10] You cannot do that in 16.04. It cannot be done. [19:11] You have to either resolve the problem or have a successful startup of the networking service that doesn't depend on the problem's being solved. [19:11] ok so i will get 15 minutes time out while booting no matter what i do? [19:11] Did I just say that? [19:11] (No.) [19:11] well the solution would be not to get network up until cloud-init injects the static ip [19:12] but that is not how is happening [19:12] how are you injecting networking in cloud-init ? [19:12] config drive / nocloud [19:12] then you have control over what gets rendered in the 50-cloud-init.cfg file [19:13] and it works [19:13] in the network config in the nocloud seed, make sure you don't attempt to dhcp on non-existent interfaces [19:13] https://i.imgur.com/PXBt5N2.png [19:13] perfectly [19:13] only after 15 minutes of timeouts [19:14] so I suspect that your first nic isn't getting the name 'eth0' [19:14] 16.04 uses persistent nic naming, so it'll be like ens3 or ens1p1 [19:14] yea i did the grub biosdevicename thingy [19:15] na, it must be eth0 [19:15] that looks fine, if eth0 is present, then ifup on eth0 should be just fine; [19:15] right but when i seal the vm [19:15] eth0 will not exist until cloud-init injects it [19:15] so ubuntu will timeout trying to get it with dhcp [19:16] so you must not be embedded the datasource into /var/lib/cloud/seed/nocloud-net/ [19:16] ummm [19:16] let me try [19:16] when you boot it soemwhere else, it'll have a new instance id, in which case the previous config may not apply [19:16] in there you'll also set a meta-data with an instance-id: [19:17] yes that i delete before sealing [19:17] correct? [19:17] /var/lib/cloud/instances [19:18] if this is a template then, yes; [19:22] okay no timeout [19:23] that worked [19:23] i think i wasn't clearing /var/lib/cloud/instances and caused the problem [19:23] you can also write a network-config file for the nocloud-net seed like so [19:24] http://paste.ubuntu.com/24335893/ [19:25] format is documented here: http://curtin.readthedocs.io/en/latest/topics/networking.html ; I've an PR to get that published under the cloud-init docs [20:18] Guys, I'm trying to launch an Instance on Ocata / Ubuntu 16.04, with DPDK and hugepages, the following error is appearing on nova-compute.log: [20:18] can't open backing store /dev/hugepages-1048576/libvirt/qemu for guest RAM: Permission denied [20:18] Any tips? [20:18] Might be related to https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1524737 ? [20:18] Launchpad bug 1524737 in libvirt (Ubuntu Wily) "systemd presents hugetblfs at /dev/hugepages" [Undecided,New] [20:21] I'm also seeing "apparmor="DENIED"" at my syslog... =/ [20:25] ThiagoCMC: ubuntu-bug libvirt, please, and make sure to include those DENIED lines [20:25] Damn... ok! [20:25] =P [20:27] "ubuntu-bug libvirt0", right? [20:27] never mind, sending [20:28] https://help.ubuntu.com/lts/serverguide/DPDK.html [20:28] may be of help as well [20:29] rharper: nice, thanks [20:29] all thanks go to cpaelzer [20:30] cpaelzer, thanks for the nice https://help.ubuntu.com/lts/serverguide/DPDK.html guide it looks like good reading :) [20:33] Reported: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1524737 [20:33] Launchpad bug 1524737 in libvirt (Ubuntu Wily) "systemd presents hugetblfs at /dev/hugepages" [Undecided,Confirmed] [20:33] Oops [20:33] Damn clipboard are... [20:33] https://bugs.launchpad.net/cloud-archive/+bug/1680956 [20:33] Launchpad bug 1680956 in Ubuntu Cloud Archive "Fail to launch an OpenStack Instance with hugepages on top of OVS+DPDK" [Undecided,New] [20:33] I can easily use Ubuntu with DPDK for my VMs... [20:34] Problem is when with OpenStack... Plain KVM is fine. [20:35] ThiagoCMC: do you know ifthe libvirt in openstack has the fix to LP: #1524737 in it? [20:35] Launchpad bug 1524737 in libvirt (Ubuntu Wily) "systemd presents hugetblfs at /dev/hugepages" [Undecided,Confirmed] https://launchpad.net/bugs/1524737 [20:36] It is: libvirt-bin 2.5.0-3ubuntu5~cloud0 [20:36] ThiagoCMC: do you know ifthe libvirt in openstack has the fix to LP: #1524737 in it? [20:36] Launchpad bug 1524737 in libvirt (Ubuntu Wily) "systemd presents hugetblfs at /dev/hugepages" [Undecided,Confirmed] https://launchpad.net/bugs/1524737 [20:36] bah [20:36] ThiagoCMC: do you know ifthe libvirt in openstack has the fix to LP: #1524737 in it? [20:36] i'm also a bit confused why that bug was closed by 1.2.21-2ubuntu3 [20:36] Hmmm.. I don't... [20:37] If it was fixed a long time ago... [20:37] ThiagoCMC: sorry bad keystroke earlier [20:37] np [20:37] ah it was fixed in 1.2.21-2ubuntu2 and lp is being weird [20:37] maybe re-introduced? [20:38] ThiagoCMC: about to eat lunch but i can check on it [20:38] Enjoy it! :-D [21:15] omg help [21:16] rharper you still on? [21:16] !help | erick3k [21:16] erick3k: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience [21:16] the machine now gets stuck here https://i.imgur.com/DVpf0RX.png [21:16] why is raid loading am using no raid thing [21:29] erick3k: that's mdadm reloading [21:29] erick3k: *loading [21:29] erick3k: it has to know what raid levels are allowed so that you can use raid if you want or not [21:29] erick3k: i'm 99% sure that's not what' [21:29] *that's not what's hanging [21:31] ThiagoCMC: back, sorry for the delay [21:32] nacc ok checking [21:33] nacc, oh, that's totally ok! ^_^ [21:34] ThiagoCMC: ok, so 2.5.0-3ubuntu5, in the source, does have [21:34] # for access to hugepages [21:34] owner "/run/hugepages/kvm/libvirt/qemu/**" rw, [21:34] owner "/dev/hugepages/libvirt/qemu/**" rw, [21:35] Hmm... [21:35] =/ [21:36] ThiagoCMC: should be abel to confirm by looking at /etc/apparmor.d/abstractions/libvirt-qemu on the host [21:36] Checking... [21:37] ThiagoCMC: oh! [21:37] ThiagoCMC: the path changed! [21:37] ThiagoCMC: why is it /dev/hugepages-1048576 ? [21:37] ThiagoCMC: can you pastebin `ls -ahl /dev/hugepages*`? [21:38] Yes, /etc/apparmor.d/abstractions/libvirt-qemu have those two lines. [21:40] ls -ahl output: https://paste.ubuntu.com/24336518/ [21:40] ThiagoCMC: is this the system where you were using 1g hugepages? [21:41] yep [21:42] I can launch an Instance on top of OVS+DPKD (OVN topology), but, when I try the hugepages on OpenStack's flavor, it doesn't boot because of this apparmor stuff [21:42] sarnold: being completely dumb about apparmor, can you look at LP: #1689056 ? I am unable to put my comment in lp, due to timeouts righ tnow, but: http://paste.ubuntu.com/24336524/ [21:42] Error: Launchpad bug 1689056 could not be found [21:42] bah [21:42] LP: #1680956 [21:42] Launchpad bug 1680956 in Ubuntu Cloud Archive "Fail to launch an OpenStack Instance with hugepages on top of OVS+DPDK" [Undecided,New] https://launchpad.net/bugs/1680956 [21:43] sarnold: also, why does `man apparmor` on 17.04 refer to upstart? :) [21:43] "Ubuntu systems use upstart(8) instead of a traditional SysV init system." [21:43] ugh [21:45] Nevertheless, something else is going on here... I mean, this is for sure a problem (LP 1680956). And, when I try it without hugepages, the VM boots up but, it can't ping OVN L3 Router... But, this is a different problem entirely. [21:45] Launchpad bug 1680956 in Ubuntu Cloud Archive "Fail to launch an OpenStack Instance with hugepages on top of OVS+DPDK" [Undecided,New] https://launchpad.net/bugs/1680956 [21:45] Oh this ubottu... lol [21:45] =P [21:45] sarnold: and one last thing for the security time, the manpage refers to : http://wiki.apparmor.net/index.php/Distro_ubuntu [21:46] which, um, is as currnet as 11.04 :) [21:54] nacc what could it be? [21:54] i can't find out why is getting stuck [21:55] nacc now booted, where can i look for that ugly timeout [21:55] ? [21:55] erick3k: i'd look in syslog, messages, dmesg, etc [21:55] k [21:57] nacc is the stupid network again [21:57] i can reproduce by using cloud-init network as dhcp [21:57] erick3k: ah [21:57] i use static btw [21:57] erick3k: do you not have network on first boot or something? or using dhcp but not really? [21:58] this is the options on the template hold on [21:58] nacc: wow, nice bugs all around :) [21:58] https://i.imgur.com/IG9URrT.png [21:58] sarnold: my guess on profile seems ok, at least :) but will probably need a fix and sru, cpaelzer [21:58] should i remove the start on boot? [21:59] erick3k: i have no idea how ovirt works so i don't know [21:59] or untick network [21:59] nice back to square 1 again :( [21:59] thats why [21:59] before [21:59] erick3k: i would guess you could try those options, but i wonder if it will just fail to boot at all [21:59] i wanted to attack the stupid timeouts [22:00] not cloudinit or ovirt who cares [22:00] is stupid ubuntu timing out looking for dhcp [22:00] all other O.S work great, including 14.04 [22:01] 5 days trying to fix the stupid timeout, bout to give up on ubuntu [22:01] my customers can stick to 14.04 lol [22:04] this seems relevant: https://review.openstack.org/#/c/416664/ [22:04] https://bugs.launchpad.net/tripleo/+bug/1653812 [22:04] Launchpad bug 1653812 in tripleo "Five minute delay DHCP'ing isolated nics" [High,Fix released] [22:04] looks like ONBOOT is the issue, but i'm not sure if you actually need it for your case [22:05] nacc on centos 7 yes i put ONBOOT=no and thats it issue fixed [22:05] is there an option like that in ubuntu? [22:05] erick3k: where do you put that? [22:06] centos /etc/sysconfig/network-scripts/ifcfg-eth0 [22:07] is there a way to completly block the network from starting on boot and then just rc.local a command to start it? [22:07] am desperate [22:07] anything works i dont care [22:08] erick3k: ip=off maybe [22:08] erick3k: on the kernel commandline [22:08] but i don't understand, if you're cloud based, you depend on network in order to boot, i'd assume [22:08] not really since am not using dhcp [22:08] am using static network [22:09] that doesn't matter [22:09] i put the ip's [22:09] you still depend on network [22:09] it sounds like you've got a configuration issue [22:09] somewhere, id on't understand your deployment [22:09] but it should not be doing dhcp, i think is your root point [22:09]