# kickstart.sh random install to either /etc/netdata or /opt/netdata/etc/netdata

**URL:** <https://community.netdata.cloud/t/kickstart-sh-random-install-to-either-etc-netdata-or-opt-netdata-etc-netdata/3655>\
**Category:** Help\
**Created:** [December 18, 2022, 6:04am UTC](https://community.netdata.cloud/t/kickstart-sh-random-install-to-either-etc-netdata-or-opt-netdata-etc-netdata/3655 "2022-12-18T06:04:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![servermatter](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/servermatter/32/1844_2.png) [@servermatter](https://community.netdata.cloud/u/servermatter)\
**Post date:** [December 18, 2022, 6:04am UTC](https://community.netdata.cloud/t/kickstart-sh-random-install-to-either-etc-netdata-or-opt-netdata-etc-netdata/3655/1 "2022-12-18T06:04:21Z")

</div>

I am installing Netdata using the method shown here [Install Netdata with kickstart.sh | Learn Netdata](https://learn.netdata.cloud/docs/agent/packaging/installer/methods/kickstart)

I am installing on 4 seemingly or at least near identical Ubuntu 22.04 servers.

I have purged all things netdata from the filesystem on all systems. Every nook and cranny have been policed.

Yet, upon running that script in the identical fashion ie; netdata-kickstart.sh --install-prefix=/opt --reinstall-clean --non-interactive --disable-telemetry --disable-cloud

Some of them install in /etc/netdata and the others in /opt/netdata/etc/netdata

I am trying to end up with a predictable and repeatable outcome but I cannot figure out why one

What sayeth the group?

Thanks.

Jay  
CompuMatter

---

<div class="post-metadata">

**Author:** ![Austin\_Hemmelgarn](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/austin_hemmelgarn/32/4495_2.png) [@Austin\_Hemmelgarn](https://community.netdata.cloud/u/Austin_Hemmelgarn)\
**Post date:** [December 18, 2022, 1:45pm UTC](https://community.netdata.cloud/t/kickstart-sh-random-install-to-either-etc-netdata-or-opt-netdata-etc-netdata/3655/2 "2022-12-18T13:45:05Z")

</div>

With that exact set of options, you actually should be getting a fatal error about the use of `--install-prefix` without `--build-only` (we are only able to support custom install prefixes when building locally).

If you just want things under `/opt`, you can achieve that by forcing use of a static build using the `--static-only`option (without the `--install-prefix` option), or by adding `--build-only` to the list of options you’re passing the kickstart script.

If you just want things under `/`, you can enforce that by either:

- Ensuring the systems in question have a working internet connection and can reliably access [https://packagecloud.io](https://packagecloud.io) (note though that this will change to [https://repos.netdata.cloud](https://repos.netdata.cloud) at some point within the next few months), and then using the `--native-only` option without any `--install-prefix` option. This will use native DEB packages, allowing you to manage updates with APT.

or:

- Using `--build-only` to build locally, without using any `--install-prefix` option.

* * *

As far as why you’re seeing this inconsistent behavior, my guess is that you’ve got issues with your internet connection that are preventing reliable access to [https://packagecloud.io](https://packagecloud.io). If that access happens to work, you end up with a native package (which installs under `/`), if it fails at any of about half a dozen points during the install the installer will instead fall back to a static build (which installs under `/opt/netdata`).

---

<div class="post-metadata">

**Author:** ![servermatter](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/servermatter/32/1844_2.png) [@servermatter](https://community.netdata.cloud/u/servermatter)\
**Post date:** [December 19, 2022, 5:15am UTC](https://community.netdata.cloud/t/kickstart-sh-random-install-to-either-etc-netdata-or-opt-netdata-etc-netdata/3655/3 "2022-12-19T05:15:45Z")

</div>

Thank you Austin for that well presented reply. Indeed I did NOT include --install-prefix. That was one of the many iterations I was attempting while trying to arrive at a predictable install location. Your reply highlights some clear methods to insure locations are /opt or /etc as desired.

I did try using --native-install last night but was getting an error (going by memory) regarding not being able to find the pkg. Today however I ran an install as --native-install and all went perfectly.

I am curious why you say installing to ‘/’ instead of installing to ‘/etc’. I assume we are speaking of the same thing.

---

<div class="post-metadata">

**Author:** ![Austin\_Hemmelgarn](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/austin_hemmelgarn/32/4495_2.png) [@Austin\_Hemmelgarn](https://community.netdata.cloud/u/Austin_Hemmelgarn)\
**Post date:** [December 19, 2022, 2:36pm UTC](https://community.netdata.cloud/t/kickstart-sh-random-install-to-either-etc-netdata-or-opt-netdata-etc-netdata/3655/4 "2022-12-19T14:36:00Z")

</div>

> I did try using --native-install last night but was getting an error (going by memory) regarding not being able to find the pkg. Today however I ran an install as --native-install and all went perfectly.

Yeah, we’ve had issues occasionally with some people not being able to install the native packages reliably. We’re unfortunately not sure exactly what’s going on there, but in general retrying a bit later usually does get things working. We’re in the process though of migrating to new hosting infrastructure for our native package repositories, and I’m hopeful that that should resolve most of these types of issues.

> I am curious why you say installing to ‘/’ instead of installing to ‘/etc’. I assume we are speaking of the same thing.

You’re mentioning where the config files end up, while I’m talking about the install prefix itself. We’re essentially saying the same thing, just in slightly different ways.
