Activity log for bug #1725067

Date Who What changed Old value New value Message
2017-10-20 00:44:33 Steve Langasek bug added bug
2017-10-20 00:44:52 Steve Langasek bug task added cloud-init (Ubuntu)
2017-10-20 00:45:04 Steve Langasek cloud-init (Ubuntu): importance Undecided Medium
2017-10-20 01:13:22 Steve Langasek description A freshly build 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). 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).
2017-10-20 16:31:54 Steve Langasek tags regression-proposed
2017-10-20 16:33:37 Steve Langasek cloud-init (Ubuntu): status New Triaged
2017-10-20 17:10:39 Scott Moser description 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). 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
2017-10-23 13:58:18 Scott Moser cloud-init: status New Confirmed
2017-10-23 13:58:21 Scott Moser cloud-init: status Confirmed Triaged
2017-10-23 13:58:24 Scott Moser cloud-init: importance Undecided High
2017-10-23 15:31:49 Chad Smith merge proposal linked https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332634
2017-10-23 15:31:59 Chad Smith cloud-init: status Triaged In Progress
2017-10-23 15:32:01 Chad Smith cloud-init: assignee Chad Smith (chad.smith)
2017-10-23 15:32:03 Chad Smith cloud-init (Ubuntu): status Triaged In Progress
2017-10-23 15:32:05 Chad Smith cloud-init (Ubuntu): assignee Chad Smith (chad.smith)
2017-10-23 20:55:54 Launchpad Janitor merge proposal linked https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332670
2017-10-23 20:58:59 Launchpad Janitor merge proposal linked https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332671
2017-10-23 21:08:52 Launchpad Janitor merge proposal linked https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332673
2017-10-23 21:26:12 Scott Moser description 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 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
2017-10-23 21:27:43 Scott Moser description 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 === 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'. [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
2017-10-23 21:28:02 Scott Moser nominated for series Ubuntu Zesty
2017-10-23 21:28:02 Scott Moser bug task added cloud-init (Ubuntu Zesty)
2017-10-23 21:28:02 Scott Moser nominated for series Ubuntu Artful
2017-10-23 21:28:02 Scott Moser bug task added cloud-init (Ubuntu Artful)
2017-10-23 21:28:02 Scott Moser nominated for series Ubuntu Xenial
2017-10-23 21:28:02 Scott Moser bug task added cloud-init (Ubuntu Xenial)
2017-10-23 21:28:28 Scott Moser cloud-init (Ubuntu Xenial): status New Confirmed
2017-10-23 21:28:32 Scott Moser cloud-init (Ubuntu Zesty): status New Confirmed
2017-10-23 21:31:13 Scott Moser description === 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'. [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 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
2017-10-24 03:24:53 Chad Smith cloud-init (Ubuntu Xenial): status Confirmed Fix Committed
2017-10-24 03:24:56 Chad Smith cloud-init (Ubuntu Zesty): status Confirmed Fix Committed
2017-10-24 03:25:00 Chad Smith cloud-init: status In Progress Fix Released
2017-10-24 03:25:04 Chad Smith cloud-init (Ubuntu Artful): status In Progress Fix Committed
2017-10-24 03:25:12 Chad Smith cloud-init (Ubuntu Xenial): importance Undecided Medium
2017-10-24 03:25:14 Chad Smith cloud-init (Ubuntu Zesty): importance Undecided Medium
2017-10-24 15:43:24 Launchpad Janitor merge proposal linked https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/332722
2017-10-25 00:34:09 Chris Halse Rogers bug added subscriber Ubuntu Stable Release Updates Team
2017-10-25 00:34:13 Chris Halse Rogers bug added subscriber SRU Verification
2017-10-25 00:34:17 Chris Halse Rogers tags regression-proposed regression-proposed verification-needed verification-needed-artful
2017-10-25 03:21:24 Chris Halse Rogers tags regression-proposed verification-needed verification-needed-artful regression-proposed verification-needed verification-needed-artful verification-needed-zesty
2017-10-25 03:30:11 Chris Halse Rogers tags regression-proposed verification-needed verification-needed-artful verification-needed-zesty regression-proposed verification-needed verification-needed-artful verification-needed-xenial verification-needed-zesty
2017-10-25 19:10:48 Chad Smith tags regression-proposed verification-needed verification-needed-artful verification-needed-xenial verification-needed-zesty regression-proposed verification-done verification-done-artful verification-done-xenial verification-done-zesty
2017-10-25 22:58:52 Chad Smith 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 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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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
2017-10-25 23:01:59 Chad Smith 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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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 http://pad.lv/1725067 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067 === Begin SRU Template === [Impact] Growing the root partition would not resize and leave a Traceback in /var/log/cloud-init.log if both:  a.) The device /dev/root did not exist -- this case only hit xenial only because zesty already had a /dev/root created in the image so resize succeeded.  b.) the kernel command line included PARTUUID=<value> -- This occurred because of code restructuring that still discovered (and logged) but didn't use the discovered kernel_cmdline root device path when resizing. [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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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
2017-10-25 23:02:22 Chad Smith description http://pad.lv/1725067 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067 === Begin SRU Template === [Impact] Growing the root partition would not resize and leave a Traceback in /var/log/cloud-init.log if both:  a.) The device /dev/root did not exist -- this case only hit xenial only because zesty already had a /dev/root created in the image so resize succeeded.  b.) the kernel command line included PARTUUID=<value> -- This occurred because of code restructuring that still discovered (and logged) but didn't use the discovered kernel_cmdline root device path when resizing. [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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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 http://pad.lv/1725067 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067 === Begin SRU Template === [Impact] Growing the root partition would not resize and leave a Traceback in /var/log/cloud-init.log if both:  a.) The device /dev/root did not exist      -- this case only hit xenial only because zesty already had a /dev/root created in the image so resize succeeded.  b.) the kernel command line included PARTUUID=<value>      -- This regression occurred because of code restructuring that still discovered (and logged) but didn't use the discovered kernel_cmdline root device path when resizing. [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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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
2017-10-25 23:02:41 Chad Smith description http://pad.lv/1725067 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067 === Begin SRU Template === [Impact] Growing the root partition would not resize and leave a Traceback in /var/log/cloud-init.log if both:  a.) The device /dev/root did not exist      -- this case only hit xenial only because zesty already had a /dev/root created in the image so resize succeeded.  b.) the kernel command line included PARTUUID=<value>      -- This regression occurred because of code restructuring that still discovered (and logged) but didn't use the discovered kernel_cmdline root device path when resizing. [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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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 http://pad.lv/1725067 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1725067 === Begin SRU Template === [Impact] Growing the root partition would not resize and leave a Traceback in /var/log/cloud-init.log if both:  a.) The device /dev/root did not exist      -- this case only hit xenial only because zesty already had a /dev/root created in the image so resize succeeded.  b.) the kernel command line included PARTUUID=<value>      -- This potential SRU regression occurred because of code restructuring that still discovered (and logged) but didn't use the discovered kernel_cmdline root device path when resizing. [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 NOTE: By default the images downloaded start off as 2Gig partitions, by requesting a 10G sparse qcow2 image resizefs should find the partition and resize it to the full 10Gig. If resizefs fails, we'd still be stuck with a 2GB response for "df -h /". This is what failed on our previous SRU proposal. The disk stayed at 2G instead of being resized to 10G. 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
2017-10-26 08:49:10 Launchpad Janitor cloud-init (Ubuntu): status Fix Committed Fix Released
2017-11-02 17:55:22 Launchpad Janitor cloud-init (Ubuntu Artful): status Fix Committed Fix Released
2017-11-02 17:55:42 Brian Murray removed subscriber Ubuntu Stable Release Updates Team
2017-11-07 17:08:10 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2017-11-07 17:08:15 Łukasz Zemczak tags regression-proposed verification-done verification-done-artful verification-done-xenial verification-done-zesty regression-proposed verification-done-artful verification-done-xenial verification-needed verification-needed-zesty
2017-11-07 17:18:39 Łukasz Zemczak tags regression-proposed verification-done-artful verification-done-xenial verification-needed verification-needed-zesty regression-proposed verification-done-artful verification-needed verification-needed-xenial verification-needed-zesty
2017-11-07 21:09:41 Chad Smith tags regression-proposed verification-done-artful verification-needed verification-needed-xenial verification-needed-zesty regression-proposed verification-done verification-done-artful verification-done-xenial verification-done-zesty
2017-11-14 22:23:59 Launchpad Janitor cloud-init (Ubuntu Zesty): status Fix Committed Fix Released
2017-11-15 01:07:42 Launchpad Janitor cloud-init (Ubuntu Xenial): status Fix Committed Fix Released