6ac3f350c0
If this seems like deja vu, that is because it is. We had this very same issue with the original CoreOS ramdisk. Since we don't control the whole OS of the ramdisk, it only made sense to teach the agent to umount the folder. The folder is referenced already, and the agent does have safeguards in place, but unfortunately this issue led to a rebuild breaking where cloud-init, glean, and the agent were all trying do the right thing as they thought, and there were just multiple /mnt/config folders present in the OS. These are separate issues we also need to try and remedy. What happens is when the device is locked via a mount, the partition table is never updated to the running OS as the mount creates a lock. So the agent ends up thinking, in the case of a rebuild, that everything including creating a configuration drive on that device has been successful, but when you reboot, there is no partition table entry for the new partition as the change was not successfully written. This state prevented the workload from rebooting properly. This change eliminates that possibility moving forward by attempting to ensure that the cloud configuration folder is no longer mounted. Change-Id: I4399dd0934361003cca9ff95a7e3e3ae9bba3dab
9 lines
319 B
YAML
9 lines
319 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixes an issue where configuration drive volumes which are mounted
|
|
by the operating system could remain mounted and cause a lock to be
|
|
held, which may conflict with actions such as ``rebuild``.
|
|
The agent now always makes sure the folder used by Glean and Cloud-init
|
|
is not mounted.
|