I've updated the SRU template providing one that should work.
The original config provided did not have any way to create a partitioned
device , but tried to put a filesystem on the first partition.
** Description changed:
+ === 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
+ - 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:
+ 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).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1687712
Title:
cc_disk_setup: fs_setup with cmd doesn't work
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1687712/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
