← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1725067] Re: cloud-init resizefs fails when booting with root=PARTUUID=

 

** Description changed:

+ http://pad.lv/1725067
+ https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067
+ 
+ === Begin SRU Template ===
+ [Impact]
+ Growing the root partition would fail in either of two cases:
+  a.) if the device /dev/root existed
+  b.) the kernel command line had upper case letters in PARTUUID=<value>
+ 
+ [Test Case]
+ get-proposed-image is
+   https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
+ It downloads a cloud image of a given release, and then creates a -proposed
+ image with cloud-init upgraded.
+ 
+ A script 'recreate.sh' will run each of the steps below automated.
+   https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh
+ 
+ 
+ 1.) get a (proposed) disk image image.
+   and convert it to raw so you can read the partuuid with sfdisk
+   (get-proposed-image does this, if not,
+   'qemu-img convert -O raw orig.img orig.raw')
+   ./get-proposed-image
+ 
+ 2.) get the partition uuid of the first partition
+    # for xenial images that are dos partition table rather than gpt
+    # we need to convert that with:
+    #    sgdisk --mbrtogpt $raw
+    $ raw=yakkety-server-cloudimg-amd64-proposed.raw
+    $ ptuuid=$(sfdisk --part-uuid $raw 1)
+ 
+ 3.) create a nocloud seed
+    $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
+         "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
+    $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
+    $ cloud-localds my-seed.img my-user-data my-meta-data
+ 
+ 4.) extract kernel from inside the image
+    $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > kernel
+ 
+ 5.) boot instance with disk backed by the raw disk above.
+ 
+    $ qemu-img create -f qcow2 -b $raw disk.img 10G
+    $ qemu-system-x86_64 -enable-kvm \
+        -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
+        -net nic -net user,hostfwd=tcp::2222-:22 \
+        -snapshot -m 768 -nographic -echr 0x05 \
+        -kernel kernel \
+        -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"
+ 
+ 6.) log in, verify / has been resized.
+    log in with 'ubuntu' and password 'passw0rd'
+     $ df -h /
+     Filesystem      Size  Used Avail Use% Mounted on
+     /dev/root       9.6G 1009M  8.6G  11% /
+ 
+ 
+ [Regression Potential]
+ Regressions would surface as the root filesystem not being correctly resized.
+ The user would find themselves with not as much disk as expected.
+ 
+ [Other Info]
+ The qemu-system-x86 command above uses ide devices.  This is because
+ the ide device emulated by qemu is built into the -generic kernel,
+ while the more common virtio-block or virtio-scsi are not.  If you
+ attach those device types, it will fail with 'cant find root'.
+ 
+ [Other Info]
+ Upstream commit at
+   https://git.launchpad.net/cloud-init/commit/?id=17a15f9e0a
+ 
+ === End SRU Template ===
+ 
  A freshly built Ubuntu 17.10 image that's configured to boot without
  initramfs by passing root=PARTUUID=<uuid> on the kernel commandline
  comes up degraded because cloud-init fails to resize the root partition.
  
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,656 - util.py[WARNING]: Failed to resize filesystem (cmd=('resize2fs', '/dev/root'))
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,662 - util.py[WARNING]: Running module resizefs (<module 'cloudinit.config.cc_resizefs' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_resizefs.py'>) failed
  
  Looking at the code, I see that there are two separate implementations
  of rootdev_from_cmdline, one in cloudinit/util.py and one in
  cloudinit/config/cc_resizefs.py; and the second does not handle
  partuuid.
  
  >>> from cloudinit.util import rootdev_from_cmdline
  >>> rootdev_from_cmdline('BOOT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/disk/by-partuuid/f122607f-3631-4411-bd34-de4bed76e0f7'
  >>> from cloudinit.config.cc_resizefs import rootdev_from_cmdline
  >>> rootdev_from_cmdline('OT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7'
  >>>
  
  This is related to bug #1684869; I'm not sure if it's the same bug
  reintroduced or if was never fixed properly on trunk (17.1).
  
- 
  Related bugs:
-  * bug 1684869: growing root partition does not always work with root=PARTUUID=
-  * bug 1685291: RFC: virtio and virtio-scsi should be built in
-  * bug 1677376: growing partitions does not work when booted without initramfs
+  * bug 1684869: growing root partition does not always work with root=PARTUUID=
+  * bug 1685291: RFC: virtio and virtio-scsi should be built in
+  * bug 1677376: growing partitions does not work when booted without initramfs

** Description changed:

- http://pad.lv/1725067
- https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067
- 
  === Begin SRU Template ===
  [Impact]
- Growing the root partition would fail in either of two cases:
-  a.) if the device /dev/root existed
-  b.) the kernel command line had upper case letters in PARTUUID=<value>
+ Growing the root partition would if:
+  a.) if the device /dev/root did not exist
+  b.) the kernel command line included PARTUUID=<value>
  
  [Test Case]
  get-proposed-image is
-   https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
+   https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
  It downloads a cloud image of a given release, and then creates a -proposed
  image with cloud-init upgraded.
  
  A script 'recreate.sh' will run each of the steps below automated.
-   https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh
- 
+   https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh
  
  1.) get a (proposed) disk image image.
-   and convert it to raw so you can read the partuuid with sfdisk
-   (get-proposed-image does this, if not,
-   'qemu-img convert -O raw orig.img orig.raw')
-   ./get-proposed-image
+   and convert it to raw so you can read the partuuid with sfdisk
+   (get-proposed-image does this, if not,
+   'qemu-img convert -O raw orig.img orig.raw')
+   ./get-proposed-image
  
  2.) get the partition uuid of the first partition
-    # for xenial images that are dos partition table rather than gpt
-    # we need to convert that with:
-    #    sgdisk --mbrtogpt $raw
-    $ raw=yakkety-server-cloudimg-amd64-proposed.raw
-    $ ptuuid=$(sfdisk --part-uuid $raw 1)
+    # for xenial images that are dos partition table rather than gpt
+    # we need to convert that with:
+    #    sgdisk --mbrtogpt $raw
+    $ raw=yakkety-server-cloudimg-amd64-proposed.raw
+    $ ptuuid=$(sfdisk --part-uuid $raw 1)
  
  3.) create a nocloud seed
-    $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
-         "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
-    $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
-    $ cloud-localds my-seed.img my-user-data my-meta-data
+    $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
+         "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
+    $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
+    $ cloud-localds my-seed.img my-user-data my-meta-data
  
  4.) extract kernel from inside the image
-    $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > kernel
+    $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > kernel
  
  5.) boot instance with disk backed by the raw disk above.
  
-    $ qemu-img create -f qcow2 -b $raw disk.img 10G
-    $ qemu-system-x86_64 -enable-kvm \
-        -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
-        -net nic -net user,hostfwd=tcp::2222-:22 \
-        -snapshot -m 768 -nographic -echr 0x05 \
-        -kernel kernel \
-        -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"
+    $ qemu-img create -f qcow2 -b $raw disk.img 10G
+    $ qemu-system-x86_64 -enable-kvm \
+        -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
+        -net nic -net user,hostfwd=tcp::2222-:22 \
+        -snapshot -m 768 -nographic -echr 0x05 \
+        -kernel kernel \
+        -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"
  
  6.) log in, verify / has been resized.
-    log in with 'ubuntu' and password 'passw0rd'
-     $ df -h /
-     Filesystem      Size  Used Avail Use% Mounted on
-     /dev/root       9.6G 1009M  8.6G  11% /
- 
+    log in with 'ubuntu' and password 'passw0rd'
+     $ df -h /
+     Filesystem      Size  Used Avail Use% Mounted on
+     /dev/root       9.6G 1009M  8.6G  11% /
  
  [Regression Potential]
  Regressions would surface as the root filesystem not being correctly resized.
  The user would find themselves with not as much disk as expected.
  
  [Other Info]
  The qemu-system-x86 command above uses ide devices.  This is because
  the ide device emulated by qemu is built into the -generic kernel,
  while the more common virtio-block or virtio-scsi are not.  If you
  attach those device types, it will fail with 'cant find root'.
  
  [Other Info]
  Upstream commit at
-   https://git.launchpad.net/cloud-init/commit/?id=17a15f9e0a
+   https://git.launchpad.net/cloud-init/commit/?id=17a15f9e0a
  
  === End SRU Template ===
  
  A freshly built Ubuntu 17.10 image that's configured to boot without
  initramfs by passing root=PARTUUID=<uuid> on the kernel commandline
  comes up degraded because cloud-init fails to resize the root partition.
  
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,656 - util.py[WARNING]: Failed to resize filesystem (cmd=('resize2fs', '/dev/root'))
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,662 - util.py[WARNING]: Running module resizefs (<module 'cloudinit.config.cc_resizefs' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_resizefs.py'>) failed
  
  Looking at the code, I see that there are two separate implementations
  of rootdev_from_cmdline, one in cloudinit/util.py and one in
  cloudinit/config/cc_resizefs.py; and the second does not handle
  partuuid.
  
  >>> from cloudinit.util import rootdev_from_cmdline
  >>> rootdev_from_cmdline('BOOT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/disk/by-partuuid/f122607f-3631-4411-bd34-de4bed76e0f7'
  >>> from cloudinit.config.cc_resizefs import rootdev_from_cmdline
  >>> rootdev_from_cmdline('OT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7'
  >>>
  
  This is related to bug #1684869; I'm not sure if it's the same bug
  reintroduced or if was never fixed properly on trunk (17.1).
  
  Related bugs:
   * bug 1684869: growing root partition does not always work with root=PARTUUID=
   * bug 1685291: RFC: virtio and virtio-scsi should be built in
   * bug 1677376: growing partitions does not work when booted without initramfs

** Also affects: cloud-init (Ubuntu Zesty)
   Importance: Undecided
       Status: New

** Also affects: cloud-init (Ubuntu Artful)
   Importance: Medium
     Assignee: Chad Smith (chad.smith)
       Status: In Progress

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: cloud-init (Ubuntu Xenial)
       Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Zesty)
       Status: New => Confirmed

** Description changed:

+ http://pad.lv/1725067
+ https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067
+ 
  === Begin SRU Template ===
  [Impact]
  Growing the root partition would if:
   a.) if the device /dev/root did not exist
   b.) the kernel command line included PARTUUID=<value>
  
  [Test Case]
  get-proposed-image is
-   https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
+   https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
  It downloads a cloud image of a given release, and then creates a -proposed
  image with cloud-init upgraded.
  
  A script 'recreate.sh' will run each of the steps below automated.
-   https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh
+   https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh
+ 
  
  1.) get a (proposed) disk image image.
-   and convert it to raw so you can read the partuuid with sfdisk
-   (get-proposed-image does this, if not,
-   'qemu-img convert -O raw orig.img orig.raw')
-   ./get-proposed-image
+   and convert it to raw so you can read the partuuid with sfdisk
+   (get-proposed-image does this, if not,
+   'qemu-img convert -O raw orig.img orig.raw')
+   ./get-proposed-image
  
  2.) get the partition uuid of the first partition
-    # for xenial images that are dos partition table rather than gpt
-    # we need to convert that with:
-    #    sgdisk --mbrtogpt $raw
-    $ raw=yakkety-server-cloudimg-amd64-proposed.raw
-    $ ptuuid=$(sfdisk --part-uuid $raw 1)
+    # for xenial images that are dos partition table rather than gpt
+    # we need to convert that with:
+    #    sgdisk --mbrtogpt $raw
+    $ raw=yakkety-server-cloudimg-amd64-proposed.raw
+    $ ptuuid=$(sfdisk --part-uuid $raw 1)
  
  3.) create a nocloud seed
-    $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
-         "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
-    $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
-    $ cloud-localds my-seed.img my-user-data my-meta-data
+    $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
+         "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
+    $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
+    $ cloud-localds my-seed.img my-user-data my-meta-data
  
  4.) extract kernel from inside the image
-    $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > kernel
+    $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > kernel
  
  5.) boot instance with disk backed by the raw disk above.
  
-    $ qemu-img create -f qcow2 -b $raw disk.img 10G
-    $ qemu-system-x86_64 -enable-kvm \
-        -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
-        -net nic -net user,hostfwd=tcp::2222-:22 \
-        -snapshot -m 768 -nographic -echr 0x05 \
-        -kernel kernel \
-        -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"
+    $ qemu-img create -f qcow2 -b $raw disk.img 10G
+    $ qemu-system-x86_64 -enable-kvm \
+        -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
+        -net nic -net user,hostfwd=tcp::2222-:22 \
+        -snapshot -m 768 -nographic -echr 0x05 \
+        -kernel kernel \
+        -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"
  
  6.) log in, verify / has been resized.
-    log in with 'ubuntu' and password 'passw0rd'
-     $ df -h /
-     Filesystem      Size  Used Avail Use% Mounted on
-     /dev/root       9.6G 1009M  8.6G  11% /
+    log in with 'ubuntu' and password 'passw0rd'
+     $ df -h /
+     Filesystem      Size  Used Avail Use% Mounted on
+     /dev/root       9.6G 1009M  8.6G  11% /
+ 
  
  [Regression Potential]
  Regressions would surface as the root filesystem not being correctly resized.
  The user would find themselves with not as much disk as expected.
  
  [Other Info]
  The qemu-system-x86 command above uses ide devices.  This is because
  the ide device emulated by qemu is built into the -generic kernel,
  while the more common virtio-block or virtio-scsi are not.  If you
  attach those device types, it will fail with 'cant find root'.
  
+ Note that this was a regression of changes added in
+  * bug 1684869: growing root partition does not always work with root=PARTUUID=
+  * bug 1677376: growing partitions does not work when booted without initramfs
+ 
+ The issue probably is only seen if using the version of cloud-init
+ in xenial-proposed.  Zesty and artful kernels or userspace made the change
+ actually not regress.  However we will verify functionality for the uploaded
+ version in each of x, z, a.
+ 
+ 
  [Other Info]
  Upstream commit at
-   https://git.launchpad.net/cloud-init/commit/?id=17a15f9e0a
+   https://git.launchpad.net/cloud-init/commit/?id=17a15f9e0a
  
  === End SRU Template ===
  
  A freshly built Ubuntu 17.10 image that's configured to boot without
  initramfs by passing root=PARTUUID=<uuid> on the kernel commandline
  comes up degraded because cloud-init fails to resize the root partition.
  
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,656 - util.py[WARNING]: Failed to resize filesystem (cmd=('resize2fs', '/dev/root'))
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,662 - util.py[WARNING]: Running module resizefs (<module 'cloudinit.config.cc_resizefs' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_resizefs.py'>) failed
  
  Looking at the code, I see that there are two separate implementations
  of rootdev_from_cmdline, one in cloudinit/util.py and one in
  cloudinit/config/cc_resizefs.py; and the second does not handle
  partuuid.
  
  >>> from cloudinit.util import rootdev_from_cmdline
  >>> rootdev_from_cmdline('BOOT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/disk/by-partuuid/f122607f-3631-4411-bd34-de4bed76e0f7'
  >>> from cloudinit.config.cc_resizefs import rootdev_from_cmdline
  >>> rootdev_from_cmdline('OT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7'
  >>>
  
  This is related to bug #1684869; I'm not sure if it's the same bug
  reintroduced or if was never fixed properly on trunk (17.1).
  
  Related bugs:
   * bug 1684869: growing root partition does not always work with root=PARTUUID=
   * bug 1685291: RFC: virtio and virtio-scsi should be built in
   * bug 1677376: growing partitions does not work when booted without initramfs

-- 
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/1725067

Title:
  cloud-init resizefs fails when booting with root=PARTUUID=

Status in cloud-init:
  In Progress
Status in cloud-init package in Ubuntu:
  In Progress
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Zesty:
  Confirmed
Status in cloud-init source package in Artful:
  In Progress

Bug description:
  http://pad.lv/1725067
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067

  === Begin SRU Template ===
  [Impact]
  Growing the root partition would if:
   a.) if the device /dev/root did not exist
   b.) the kernel command line included PARTUUID=<value>

  [Test Case]
  get-proposed-image is
    https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
  It downloads a cloud image of a given release, and then creates a -proposed
  image with cloud-init upgraded.

  A script 'recreate.sh' will run each of the steps below automated.
    https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh

  
  1.) get a (proposed) disk image image.
    and convert it to raw so you can read the partuuid with sfdisk
    (get-proposed-image does this, if not,
    'qemu-img convert -O raw orig.img orig.raw')
    ./get-proposed-image

  2.) get the partition uuid of the first partition
     # for xenial images that are dos partition table rather than gpt
     # we need to convert that with:
     #    sgdisk --mbrtogpt $raw
     $ raw=yakkety-server-cloudimg-amd64-proposed.raw
     $ ptuuid=$(sfdisk --part-uuid $raw 1)

  3.) create a nocloud seed
     $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
          "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
     $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
     $ cloud-localds my-seed.img my-user-data my-meta-data

  4.) extract kernel from inside the image
     $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > kernel

  5.) boot instance with disk backed by the raw disk above.

     $ qemu-img create -f qcow2 -b $raw disk.img 10G
     $ qemu-system-x86_64 -enable-kvm \
         -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
         -net nic -net user,hostfwd=tcp::2222-:22 \
         -snapshot -m 768 -nographic -echr 0x05 \
         -kernel kernel \
         -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"

  6.) log in, verify / has been resized.
     log in with 'ubuntu' and password 'passw0rd'
      $ df -h /
      Filesystem      Size  Used Avail Use% Mounted on
      /dev/root       9.6G 1009M  8.6G  11% /

  
  [Regression Potential]
  Regressions would surface as the root filesystem not being correctly resized.
  The user would find themselves with not as much disk as expected.

  [Other Info]
  The qemu-system-x86 command above uses ide devices.  This is because
  the ide device emulated by qemu is built into the -generic kernel,
  while the more common virtio-block or virtio-scsi are not.  If you
  attach those device types, it will fail with 'cant find root'.

  Note that this was a regression of changes added in
   * bug 1684869: growing root partition does not always work with root=PARTUUID=
   * bug 1677376: growing partitions does not work when booted without initramfs

  The issue probably is only seen if using the version of cloud-init
  in xenial-proposed.  Zesty and artful kernels or userspace made the change
  actually not regress.  However we will verify functionality for the uploaded
  version in each of x, z, a.

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

  === End SRU Template ===

  A freshly built Ubuntu 17.10 image that's configured to boot without
  initramfs by passing root=PARTUUID=<uuid> on the kernel commandline
  comes up degraded because cloud-init fails to resize the root
  partition.

  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,656 - util.py[WARNING]: Failed to resize filesystem (cmd=('resize2fs', '/dev/root'))
  Oct 20 00:07:30 ubuntu cloud-init[493]: 2017-10-20 00:07:30,662 - util.py[WARNING]: Running module resizefs (<module 'cloudinit.config.cc_resizefs' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_resizefs.py'>) failed

  Looking at the code, I see that there are two separate implementations
  of rootdev_from_cmdline, one in cloudinit/util.py and one in
  cloudinit/config/cc_resizefs.py; and the second does not handle
  partuuid.

  >>> from cloudinit.util import rootdev_from_cmdline
  >>> rootdev_from_cmdline('BOOT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/disk/by-partuuid/f122607f-3631-4411-bd34-de4bed76e0f7'
  >>> from cloudinit.config.cc_resizefs import rootdev_from_cmdline
  >>> rootdev_from_cmdline('OT_IMAGE=/boot/vmlinuz-4.4.0-1007-kvm root=PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7 ro console=tty1 console=ttyS0 systemd.log_level=debug')
  '/dev/PARTUUID=f122607f-3631-4411-bd34-de4bed76e0f7'
  >>>

  This is related to bug #1684869; I'm not sure if it's the same bug
  reintroduced or if was never fixed properly on trunk (17.1).

  Related bugs:
   * bug 1684869: growing root partition does not always work with root=PARTUUID=
   * bug 1685291: RFC: virtio and virtio-scsi should be built in
   * bug 1677376: growing partitions does not work when booted without initramfs

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


References