cloud-init 21.1-19-gbad84ad4-0ubuntu1~18.04.2 failing to properly detect first boot

Bug #1927236 reported by pkaeding
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Expired
Low
Unassigned

Bug Description

I have found that when I upgrade to 21.1-19-gbad84ad4-0ubuntu1~18.04.2 of cloud-init, and create an AMI, instances using that AMI fail to detect they are in 'first boot', so they do not execute the later stages of cloud-init.

Version 21.1-19-gbad84ad4-0ubuntu1~18.04.1 does not exhibit this behavior; it works fine. That is, if I hold cloud-init before updating all packages, and then create my AMI using the same process, everything works fine. I'm running Ubuntu Pro 18.04 in FIPS mode, if that matters.

Looking through the `/var/log/cloud-init.log` and `/var/log/cloud-init-output.log` logs, I don't see any errors, but it is possible I'm not looking in the right place.

```
$ lsb_release -rd
Description: Ubuntu 18.04.5 LTS
Release: 18.04
```

Though, now I'm not sure if I understand what is happening. I see in the output of my AMI build that cloud-init was upgraded when I upgraded all packages. (And if I `hold` it, then this problem doesn't occur). But here, I think I see that the package is not installed?

```
$ apt-cache policy cloud-init
cloud-init:
  Installed: (none)
  Candidate: 21.1-19-gbad84ad4-0ubuntu1~18.04.2
  Version table:
     21.1-19-gbad84ad4-0ubuntu1~18.04.2 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     18.2-14-g6d48d265-0ubuntu1 500
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
```

Revision history for this message
Chad Smith (chad.smith) wrote :

Thanks for filing this bug report and helping make cloud-init and ubuntu better.
Each time cloud-init boots, it creates semaphore files and caches the detected datasource so subsequent boots do not take an exhorbitant amount of time. I'm guessing it's your clone and launch that is seeing both the cached datasource and semophore files that is allowing the cloned VM to treat the next boot as dirty.

 Generally, when cloning and creating your own AMIs, you need to run `sudo cloud-init clean --logs` to prior to cloning the AMI to make sure that the image is seen as "greenfield" or fresh when that image is next launched. That clean will remove all semaphores and cached artifacts and all full cloud-init setup and datasource detection.

If this does not resolve the problem for you. Please run 'sudo cloud-init collect-logs' and attach them to this bug, setting it back to "New".

Changed in cloud-init (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for cloud-init (Ubuntu) because there has been no activity for 60 days.]

Changed in cloud-init (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.