yahoo-eng-team team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

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