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: Fix Committed => 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/1692087

Title:
  check_partition_layout has false positives when partitioned with gpt

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]
  The disk setup module (disk_setup) of cloud-init had several issues
  when dealing with GPT formatted devices.  The result was that the user
  didn't get expected behavior if they were requesting GPT disk labels
  or if the disk present already had a GPT label.

  [Test Case]
  1.) launch an instance with a second disk "/dev/vdb".
      This can be done on openstack or azure.

  2.) write a config to system.
     $ sudo tee /etc/cloud/cloud.cfg.d/disk-setup.cfg <EOF
  #cloud-config
  disk_setup:
    /dev/vdb:
      table_type: gpt
      layout: [66, [33, 82]]
      overwrite: True
  fs_setup:
   - device: /dev/vdb
     partition: 1
     filesystem: ext4
   - device: /dev/vdb
     partition: 2
     filesystem: swap
  mounts:
      - ["/dev/vdb1", "/mnt"]
  EOF

  3. Partition the second disk with a gpt partition table.
     download a paritioning tool and use it.
     $ wget https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bugs/lp-1686514/disk-setup -O disk-setup
     # format /dev/vdb with GPT disk label and 2 partitions.
     $ sudo LABEL=gpt ./disk-setup ntfs2 /dev/vdb

  4. remove state from the instance and reboot.  We expect that the desired
     partitioning will be done and the mount written and used on reboot.

     $ sudo rm -Rf /var/lib/cloud/ /var/log/cloud-init*
     $ sudo reboot

  5. ssh back in and look around
     $ grep vdb /proc/mounts
     $ grep mnt /etc/fstab

     $ sfdisk -l /dev/vdb

  6. sudo reboot
  7. ssh back in and look around.

  [Regression Potential]
  Regressions will be limited to places where the disk_setup module is used.
  That is
   a.) Azure (by default on new instances or re-deployed instance)
   b.) instances with custom user-data or system configuration.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=3507b59eaa4

  === End SRU Template ===

  As reported in bug 1686514 (comment 11), there is a bug in the code
  that determines if a device layout is "the same" and will thus be re-used.

  Even when functional, this code has some serious shortcomings:
  a.) it does not check sizes at all, only partition types
  b.) it does not check the partition table correctly

  The bug to fix here is simply some issues with its usage of sgdisk.
   * 'sgdisk -p' was being used to determine the size of a disk.
     this can fail if it believes there is a bad gpt partition table.
   * parsing of sgdisk -p output assumed that the 'name' of the partition
     type would not have any spaces (Microsoft basic data)
   * interaction with sgdisk did not realize that sgdisk wants input
     of '8300' rather than '83'.

  Related bugs:
   * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks
   * bug 1691489: fstab entries written by cloud-config may not be mounted

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1692087/+subscriptions