Azure reboot with unformatted ephemeral drive won't mount reformatted volume

Bug #1825596 reported by Jason Zions on 2019-04-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

If an Azure VM is rebooted after being moved to a different host (e.g. after a deallocate operation or after a service-heal to remove a bad host from service), the ephemeral drive exposed to the VM is reset to the default state (NTFS format). The Azure data source detects this and marks cc_disk_setup and cc_mounts to be run. While cc_disk_setup reformats the volume as desired, cc_mounts determines that the appropriate mount request was already in /etc/fstab (as setup during initial provisioning). Since the normal boot process would already have mounted everything according to fstab, the cc_mounts logic is "no mount -a is required". This is not true in this scenario.

Related branches

Ryan Harper (raharper) wrote :

Could you supply the systemd journal from the system and a cloud-init collect-logs?

I'd like to confirm that the .mount units for the ephemeral drive were attempted, but failed due to the disk not being ext4 (yet).

Changed in cloud-init:
importance: Undecided → High
status: New → Incomplete
Jason Zions (jasonzio) wrote :

I confirmed that myself in the logs; the timestamp on the failed mnt.mount is about three seconds earlier than the timestamp on the cloud-init startup message. The error message is indeed a complaint about not being able to mount an "ntfs" formatted volume. I'll try to find a relevant repro and get you the logs you seek.

Jason Zions (jasonzio) wrote :

Per your request, the results of collect-logs

Jason Zions (jasonzio) wrote :

The contents of /var/log/messages on this CentOS system, corresponding to the VM start-after-deallocate operation covered by the previously-uploaded collect-logs bundle. In particular, see Apr 23 00:06:05 (date/times in UTC) for the attempt to mount the NTFS ephemeral volume. Meanwhile, in cloud-init.log, you'll see that cc_disk_setup doesn't run until 00:06:27.

When this VM was first created, /var/log/messages said nothing at all about /dev/disk/cloud/azure_resource-part1 or about NTFS, which is exactly as one would expect for the first-time-ever boot of the VM.

Jason Zions (jasonzio) on 2019-04-23
Changed in cloud-init:
status: Incomplete → New
Ryan Harper (raharper) on 2019-04-26
Changed in cloud-init:
status: New → In Progress

This bug is fixed with commit acc25d8d to cloud-init on branch master.
To view that commit see the following URL:

Changed in cloud-init:
status: In Progress → Fix Committed

This bug is believed to be fixed in cloud-init in version 19.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
Changed in cloud-init:
assignee: nobody → Roufique Hossain (roufique)
Steve Langasek (vorlon) on 2020-04-21
Changed in cloud-init:
assignee: Roufique Hossain (roufique) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers