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

Bug #1825596 reported by Jason Zions
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Fix Released
High
Unassigned

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

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Jason Zions (jasonzio) wrote :

Per your request, the results of collect-logs

Revision history for this message
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)
Changed in cloud-init:
status: Incomplete → New
Ryan Harper (raharper)
Changed in cloud-init:
status: New → In Progress
Revision history for this message
Server Team CI bot (server-team-bot) wrote :

This bug is fixed with commit acc25d8d to cloud-init on branch master.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=acc25d8d

Changed in cloud-init:
status: In Progress → Fix Committed
Revision history for this message
Chad Smith (chad.smith) wrote : Fixed in cloud-init version 19.1.

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)
Changed in cloud-init:
assignee: Roufique Hossain (roufique) → nobody
Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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