| 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 |
|
| 2023-05-11 06:56:07 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/3036 |
|
