cc_disk_setup: fs_setup with cmd doesn't work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Medium
|
Paul Meyer | ||
cloud-init (Ubuntu) |
Fix Released
|
Medium
|
Vishnu C | ||
Xenial |
Fix Released
|
Medium
|
Unassigned | ||
Yakkety |
Fix Released
|
Medium
|
Unassigned | ||
Zesty |
Fix Released
|
Medium
|
Unassigned |
Bug Description
=== Begin SRU Template ===
[Impact]
If the user specifies cloud-config with a 'fs_setup' entry containing
a 'cmd', then warning will appear in cloud-init.log and expected filesystem
will not be created.
This is because cloud-init would essentially try to execute a name like:
"mkfs -t TYPE -L LABEL DEVICE"
rather than a name 'mkfs' with arguments '-t', TYPE, ...
No split was done on space. The fix was to enable
shell intrepretation so that the split would be done.
[Test Case]
This test case assumes a disk will be attached named '/dev/vdb'.
You can change the 'dev=' to be 'sdb' if that will be the device name.
The test cases boots an instance, ads proposed and then 'cleans' the
instance, but similarly this will work if the config is provided
in user-data.
$ dev=vdb
$ sudo tee /etc/cloud/
#cloud-config
disk_setup:
/dev/$dev:
table_type: gpt
layout: [[100, 83]]
fs_setup:
- cmd: mkfs -F -t %(filesystem)s -L %(label)s %(device)s
filesystem: ext4
device: /dev/$dev
partition: 1
label: repro
mounts:
- [/dev/${dev}1, /mnt]
EOF
$ sudo rm -Rf /var/lib/cloud /var/log/
## remove the old entry in /etc/fstab, which can cause LP: #1691489
$ sudo sed -i.dist '/comment=
## wipe the disk so that we make sure we format it.
$ sudo python3 -c "import sys;
buf = b'\\0' * 1024 * 1024 * 8
with open(sys.argv[1], 'wb+') as fp:
fp.write(buf)
fp.seek(
fp.write(buf)" /dev/$dev
$ sudo reboot
## Now ssh back in, and expect to have a filesystem on /dev/vdb1
## that is mounted at /mnt
[Regression Potential]
Regression could occur if a user had provided a string to the 'cmd'
argument that had special shell characters in it.
For example:
cmd: "/my/cmd *foo*"
That would previously have executed the command "/mnt/cmd *foo*", but
will now execute the command /mnt/cmd with argument shell filename
expansion of *foo*
[Other Info]
Upstream commit at
https:/
=== End SRU Template ===
This reproduces on Azure, but it should fail similarly elsewhere. Consider repro.yml:
#cloud-config
fs_setup:
- special:
cmd: mkfs -t %(filesystem)s -L %(label)s %(device)s
filesystem: ext4
device: /dev/sdb1
label: repro
Create a VM with this cloud config:
$ az vm create -g $rg -l westus2 --custom-data @repro.yml --image UbuntuLTS -n repro2
Then cloud-init will fail with:
Failed to exec of 'mkfs -t ext4 -L repro /dev/sdb1':
Unexpected error while running command.
Command: mkfs -t ext4 -L repro /dev/sdb1
Exit code: -
Reason: [Errno 2] No such file or directory: 'mkfs -t ext4 -L repro /dev/sdb1'
$ dpkg-query -W -f='${Version}' cloud-init
0.7.9-48-
Bug is in mkfs() in cc_disk_setup.py, which creates a shell-like string in the case that cmd was specified and a exec-like array in the other case (around line 913).
Related branches
- Chad Smith: Approve
- Server Team CI bot: Approve (continuous-integration)
- cloud-init Commiters: Pending requested
-
Diff: 130 lines (+66/-8)3 files modifiedcloudinit/config/cc_disk_setup.py (+14/-5)
doc/examples/cloud-config-disk-setup.txt (+3/-3)
tests/unittests/test_handler/test_handler_disk_setup.py (+49/-0)
Changed in cloud-init: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu): | |
assignee: | nobody → Vishnu C (chalil) |
Changed in cloud-init: | |
assignee: | nobody → Paul Meyer (paul-meyer) |
Changed in cloud-init (Ubuntu): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Zesty): | |
importance: | Undecided → Medium |
Additionally, the docs for fs_setup have uppercase mapping keys, while the code expects lowercase keys.