This bug is believed to be fixed in cloud-init in 17.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: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1687712
Title:
cc_disk_setup: fs_setup with cmd doesn't work
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Yakkety:
Fix Released
Status in cloud-init source package in Zesty:
Fix Released
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.cfg.d/disk-setup.cfg <<EOF
#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/cloud-init*
## remove the old entry in /etc/fstab, which can cause LP: #1691489
$ sudo sed -i.dist '/comment=cloudconfig/d' /etc/fstab
## 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(-(len(buf)), 2)
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://git.launchpad.net/cloud-init/commit/?id=4f0f171c2
=== 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-g1c795b9-0ubuntu1~16.04.1
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).
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1687712/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
