| 2017-03-29 20:41:05 |
Scott Moser |
bug |
|
|
added bug |
| 2017-03-29 20:41:21 |
Scott Moser |
cloud-init: assignee |
|
Steve Langasek (vorlon) |
|
| 2017-03-29 20:41:28 |
Scott Moser |
cloud-init: status |
New |
In Progress |
|
| 2017-03-29 20:41:30 |
Scott Moser |
cloud-init: importance |
Undecided |
Medium |
|
| 2017-03-29 20:41:37 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2017-03-29 20:42:17 |
Scott Moser |
merge proposal linked |
|
https://code.launchpad.net/~vorlon/cloud-init/+git/cloud-init/+merge/321245 |
|
| 2017-03-29 20:42:28 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2017-03-29 20:42:30 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-03-29 20:49:42 |
Scott Moser |
cloud-init: status |
In Progress |
Fix Committed |
|
| 2017-03-31 11:51:03 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2017-04-03 16:17:19 |
Scott Moser |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-04-03 16:17:19 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Yakkety) |
|
| 2017-04-03 16:17:19 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-04-03 16:17:19 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2017-04-03 16:17:59 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-04-03 16:18:01 |
Scott Moser |
cloud-init (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-04-03 16:18:04 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-04-03 16:18:05 |
Scott Moser |
cloud-init (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2017-04-04 15:52:30 |
Steve Langasek |
description |
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good. |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them. |
|
| 2017-04-04 16:22:07 |
Steve Langasek |
description |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them. |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
Because there are not yet any official Ubuntu images that boot without initramfs, the test case is somewhat opaque. Here is a test case that should work with public branches, though I will be doing validation in GCE using a private branch.
1. Build livecd-rootfs from lp:~vorlon/livecd-rootfs/minimizing/ and upload it to a ppa.
2. bzr branch lp:launchpad-buildd
3. run the following setup commands:
export BUILDID=cloud-init-test
export CHROOT_ROOT=$HOME/build-$BUILDID/chroot-autobuild
wget http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /tmp/root.tar.xz
mkdir -p $CHROOT_ROOT/build
tar -C $CHROOT_ROOT -x -f /tmp/root.tar.xz
rm $CHROOT_ROOT/etc/resolv.conf
launchpad-buildd/mount-chroot $BUILDID
launchpad-buildd/update-debian-chroot $BUILDID
4. Run a build without -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none
5. Boot the resulting image ($HOME/build-$BUILDID/chroot-autobuild/build/binary/boot/disk.ext4) in an openstack environment.
6. Verify that the image boots but does not expand the root partition.
7. Run a build again with -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none --proposed
8. Boot the resulting image in an openstack environment.
9. Verify that the image boots, and that this time the root partition is expanded to use the full disk.
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them. |
|
| 2017-04-10 22:27:09 |
Brian Murray |
cloud-init (Ubuntu Yakkety): status |
Confirmed |
Fix Committed |
|
| 2017-04-10 22:27:11 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-04-10 22:27:17 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-04-10 22:27:23 |
Brian Murray |
tags |
|
verification-needed |
|
| 2017-04-10 22:48:53 |
Brian Murray |
cloud-init (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-04-17 23:01:11 |
Steve Langasek |
tags |
verification-needed |
verification-done-xenial verification-needed |
|
| 2017-04-19 21:48:13 |
Steve Langasek |
tags |
verification-done-xenial verification-needed |
verification-done-xenial verification-done-yakkety |
|
| 2017-04-20 18:16:46 |
Scott Moser |
description |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
Because there are not yet any official Ubuntu images that boot without initramfs, the test case is somewhat opaque. Here is a test case that should work with public branches, though I will be doing validation in GCE using a private branch.
1. Build livecd-rootfs from lp:~vorlon/livecd-rootfs/minimizing/ and upload it to a ppa.
2. bzr branch lp:launchpad-buildd
3. run the following setup commands:
export BUILDID=cloud-init-test
export CHROOT_ROOT=$HOME/build-$BUILDID/chroot-autobuild
wget http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /tmp/root.tar.xz
mkdir -p $CHROOT_ROOT/build
tar -C $CHROOT_ROOT -x -f /tmp/root.tar.xz
rm $CHROOT_ROOT/etc/resolv.conf
launchpad-buildd/mount-chroot $BUILDID
launchpad-buildd/update-debian-chroot $BUILDID
4. Run a build without -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none
5. Boot the resulting image ($HOME/build-$BUILDID/chroot-autobuild/build/binary/boot/disk.ext4) in an openstack environment.
6. Verify that the image boots but does not expand the root partition.
7. Run a build again with -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none --proposed
8. Boot the resulting image in an openstack environment.
9. Verify that the image boots, and that this time the root partition is expanded to use the full disk.
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them. |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
Because there are not yet any official Ubuntu images that boot without initramfs, the test case is somewhat opaque. Here is a test case that should work with public branches, though I will be doing validation in GCE using a private branch.
1. Build livecd-rootfs from lp:~vorlon/livecd-rootfs/minimizing/ and upload it to a ppa.
2. bzr branch lp:launchpad-buildd
3. run the following setup commands:
export BUILDID=cloud-init-test
export CHROOT_ROOT=$HOME/build-$BUILDID/chroot-autobuild
wget http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /tmp/root.tar.xz
mkdir -p $CHROOT_ROOT/build
tar -C $CHROOT_ROOT -x -f /tmp/root.tar.xz
rm $CHROOT_ROOT/etc/resolv.conf
launchpad-buildd/mount-chroot $BUILDID
launchpad-buildd/update-debian-chroot $BUILDID
4. Run a build without -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none
5. Boot the resulting image ($HOME/build-$BUILDID/chroot-autobuild/build/binary/boot/disk.ext4) in an openstack environment.
6. Verify that the image boots but does not expand the root partition.
7. Run a build again with -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none --proposed
8. Boot the resulting image in an openstack environment.
9. Verify that the image boots, and that this time the root partition is expanded to use the full disk.
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them.
Related bugs:
* bug 1684869: growing root partition does not always work with root=PARTUUID= |
|
| 2017-04-20 19:33:34 |
Launchpad Janitor |
cloud-init (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2017-04-20 19:35:32 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-04-20 19:35:54 |
Launchpad Janitor |
cloud-init (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-04-21 15:47:50 |
Scott Moser |
description |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
Because there are not yet any official Ubuntu images that boot without initramfs, the test case is somewhat opaque. Here is a test case that should work with public branches, though I will be doing validation in GCE using a private branch.
1. Build livecd-rootfs from lp:~vorlon/livecd-rootfs/minimizing/ and upload it to a ppa.
2. bzr branch lp:launchpad-buildd
3. run the following setup commands:
export BUILDID=cloud-init-test
export CHROOT_ROOT=$HOME/build-$BUILDID/chroot-autobuild
wget http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /tmp/root.tar.xz
mkdir -p $CHROOT_ROOT/build
tar -C $CHROOT_ROOT -x -f /tmp/root.tar.xz
rm $CHROOT_ROOT/etc/resolv.conf
launchpad-buildd/mount-chroot $BUILDID
launchpad-buildd/update-debian-chroot $BUILDID
4. Run a build without -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none
5. Boot the resulting image ($HOME/build-$BUILDID/chroot-autobuild/build/binary/boot/disk.ext4) in an openstack environment.
6. Verify that the image boots but does not expand the root partition.
7. Run a build again with -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none --proposed
8. Boot the resulting image in an openstack environment.
9. Verify that the image boots, and that this time the root partition is expanded to use the full disk.
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them.
Related bugs:
* bug 1684869: growing root partition does not always work with root=PARTUUID= |
[SRU Justification]
When booted without an initramfs, the root device will be /dev/root, not a
named device. There is partial support for this when resizing filesystems,
but not for growing partitions, without which it doesn't do much good.
A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing.
[Test case]
Because there are not yet any official Ubuntu images that boot without initramfs, the test case is somewhat opaque. Here is a test case that should work with public branches, though I will be doing validation in GCE using a private branch.
1. Build livecd-rootfs from lp:~vorlon/livecd-rootfs/minimizing/ and upload it to a ppa.
2. bzr branch lp:launchpad-buildd
3. run the following setup commands:
export BUILDID=cloud-init-test
export CHROOT_ROOT=$HOME/build-$BUILDID/chroot-autobuild
wget http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /tmp/root.tar.xz
mkdir -p $CHROOT_ROOT/build
tar -C $CHROOT_ROOT -x -f /tmp/root.tar.xz
rm $CHROOT_ROOT/etc/resolv.conf
launchpad-buildd/mount-chroot $BUILDID
launchpad-buildd/update-debian-chroot $BUILDID
4. Run a build without -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none
5. Boot the resulting image ($HOME/build-$BUILDID/chroot-autobuild/build/binary/boot/disk.ext4) in an openstack environment.
6. Verify that the image boots but does not expand the root partition.
7. Run a build again with -proposed enabled:
launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series <release> --build-id $BUILDID --image-target=none --proposed
8. Boot the resulting image in an openstack environment.
9. Verify that the image boots, and that this time the root partition is expanded to use the full disk.
[Regression potential]
Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them.
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 |
|
| 2017-05-08 19:20:43 |
Steve Langasek |
cloud-init: status |
Fix Committed |
Fix Released |
|
| 2023-05-10 22:51:45 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2847 |
|
