Prevent do-agent/dotty-agent from installing

Question

I’m switching VMs to bootc, and it seems digitalocean is attempting to install do-agent/dotty-agent through cloud-init. I presume this is because this was not turned off during VM creation, and I can’ change this setting after the fact (or can I ?)

So now I have scripts frantically attemptig to install the DO agents, only to be denied because bootc keeps /usr/ as readonly, flooding the console durig startup

Is there a way to prevent cloud-init from running these scripts, or to prevent these scripts from doing any work - without having to fully disable cloud-init?

alexdo · Accepted Answer

Heya,

For any droplet you create going forward, since you’re rebuilding onto bootc anyway, setting both to false at creation avoids this entirely rather than fighting cloud-init after the fact:

doctl compute droplet create my-bootc-droplet \
  --image my-bootc-image \
  --size s-1vcpu-1gb \
  --region nyc1 \
  --droplet-agent=false \
  --no-monitoring

Or via the API directly with “monitoring”: false and “with_droplet_agent”: false in the create request.

For the droplet you’re already stuck with, the flag is baked into that instance’s metadata and there’s no way to flip it after creation, but the install script is very likely delivered through cloud-init’s vendor-data channel specifically, DigitalOcean’s metadata service exposes vendor-data as a distinct endpoint alongside user-data, and cloud-init has a built-in, official way to opt out of vendor-data entirely while keeping user-data active:

#cloud-config
vendor_data:
  enabled: false

That should stop whatever DigitalOcean pushes through vendor-data, likely including the agent install script, without touching cloud-init’s own handling of your user-data. One caveat worth knowing before you rely on it: cloud-init only reads user-data on first boot by default, so this needs to go in at rebuild time (DigitalOcean’s Droplet rebuild feature lets you resupply user-data) rather than injected into the already-running, already-failing instance. I haven’t been able to confirm the do-agent script specifically travels through vendor-data rather than some other DigitalOcean-side mechanism, so worth testing on one droplet before rolling it out everywhere, but it’s the most direct, cloud-init-native lever available for exactly this situation.

Regards

KFSys · Answer

Heya, You’ve diagnosed it correctly — DigitalOcean delivers the do-agent/droplet-agent install as cloud-init vendor-data (served from the metadata service at boot), not as part of your image. That’s exactly why bootc’s read-only /usr fights it: the vendor-data scripts fire on every boot and get denied. A couple of things up front: There’s no control-panel toggle to turn this off, before or after creation. The only built-in opt-out is at creation time via the API , passing "with_droplet_agent": false. Panel-created Droplets can’t opt out that way, and you can’t flip it after the fact. But you don’t need to rebuild — you can tell cloud-init to ignore vendor-data while keeping user-data, networking, etc. working normally. The targeted fix: disable vendor-data only Drop a config file in /etc/cloud/cloud.cfg.d/ (that dir is on writable /etc, so bootc is fine with it): # /etc/cloud/cloud.cfg.d/99-disable-vendor-data.cfg vendor_data: enabled: false vendor_data2: enabled: false That stops cloud-init from processing DO’s agent scripts entirely, but leaves the rest of cloud-init (your user-data, network config, SSH keys) intact. No need to disable cloud-init wholesale. Because it’s bootc — bake it into the image Since the vendor-data runs at first boot, you want this config present before that happens. Add it during your image build so it ships baked in, e.g. in your Containerfile: RUN printf 'vendor_data:
 enabled: false
vendor_data2:
 enabled: false
' \ > /etc/cloud/cloud.cfg.d/99-disable-vendor-data.cfg Now every VM built from that image comes up with vendor-data already disabled, so the agent scripts never get a chance to spam the console. Handy checks To see exactly what DO is sending before you disable it: cloud-init query vendordatacat /var/lib/cloud/instance/vendor-data.txt And if you ever do want the agent on a normal (non-bootc) box later, it’s just the droplet-agent package via your package manager — nothing lost by disabling the auto-install here. For future Droplets If you’re spinning these up programmatically, add "with_droplet_agent": false to your API create call and DO won’t inject the vendor-data agent bits in the first place — belt and suspenders alongside the image-baked config. Hope that gets your boot console quiet again.