| 2019-08-19 15:58:31 |
Pat Viafore |
bug |
|
|
added bug |
| 2019-08-19 18:31:00 |
Robert C Jennings |
bug task added |
|
cloud-init |
|
| 2019-08-20 12:22:19 |
Francis Ginther |
tags |
|
id-5d484a6466c79944a30e4644 |
|
| 2019-08-20 13:45:14 |
Pat Viafore |
description |
CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0".
This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37.
patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd
Description: Ubuntu 16.04.6 LTS
Release: 16.04
patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp
ii linux-gcp 4.15.0.1037.51 amd64 Complete Google Cloud Platform (GCP) Linux kernel and headers
ii linux-gcp-headers-4.15.0-1037 4.15.0-1037.39~16.04.1 amd64 Header files related to Linux kernel version 4.15.0
To reproduce:
1) Create an image with a disk size of 3072 using a serial that has GPT
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
Reboot the instance
2) It will hang on reboot and you cannot connect
3) Please note that later serials have the GPT change reverted.
You can replace xenial with bionic in the above commands to get a bionic instance instead.
To test this out in a more slower fashion:
1) Create an image with a disk size of 2048 using a serial that has GPT
gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048
2) Resize the disk to 3072
3) Issue growpart /dev/sda 1
4) Issue resize2fs /dev/sda1
5) Issue rsize2fs /dev/sda1 instead
On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize.
I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. |
CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0".
This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37.
patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd
Description: Ubuntu 16.04.6 LTS
Release: 16.04
patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp
ii linux-gcp 4.15.0.1037.51 amd64 Complete Google Cloud Platform (GCP) Linux kernel and headers
ii linux-gcp-headers-4.15.0-1037 4.15.0-1037.39~16.04.1 amd64 Header files related to Linux kernel version 4.15.0
To reproduce:
1) Create an image with a disk size of 3072 using a serial that has GPT
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
Reboot the instance
2) It will hang on reboot and you cannot connect
3) Please note that later serials have the GPT change reverted.
You can replace xenial with bionic in the above commands to get a bionic instance instead.
To test this out in a more slower fashion:
1) Create an image with a disk size of 2048 using a serial that has GPT
gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048
2) Resize the disk to 3072
3) Issue growpart /dev/sda 1
4) Issue resize2fs /dev/sda1
5) Issue rsize2fs /dev/sda1 again
On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize.
I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. |
|
| 2019-08-20 13:56:11 |
Dan Watkins |
cloud-init: status |
New |
Won't Fix |
|
| 2019-10-10 19:34:01 |
Sultan Alsawaf |
bug task added |
|
grub |
|
| 2019-10-10 19:34:16 |
Sultan Alsawaf |
linux-gcp (Ubuntu): status |
New |
Won't Fix |
|
| 2019-10-10 19:34:39 |
Sultan Alsawaf |
bug task added |
|
grub (Ubuntu) |
|
| 2019-10-10 19:35:01 |
Sultan Alsawaf |
bug task deleted |
grub |
|
|
| 2019-10-10 19:35:24 |
Sultan Alsawaf |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-10-10 19:35:24 |
Sultan Alsawaf |
bug task added |
|
grub (Ubuntu Xenial) |
|
| 2019-10-10 19:35:24 |
Sultan Alsawaf |
bug task added |
|
linux-gcp (Ubuntu Xenial) |
|
| 2019-10-10 19:36:00 |
Sultan Alsawaf |
bug task deleted |
linux-gcp (Ubuntu) |
|
|
| 2019-10-10 19:36:10 |
Sultan Alsawaf |
bug task deleted |
linux-gcp (Ubuntu Xenial) |
|
|
| 2019-10-16 11:01:30 |
Brian Murray |
grub (Ubuntu): status |
New |
Fix Released |
|
| 2019-10-16 11:04:12 |
Brian Murray |
grub (Ubuntu Xenial): status |
New |
Triaged |
|
| 2019-10-16 11:05:48 |
Brian Murray |
grub (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2019-10-19 06:35:04 |
Matthew Ruffell |
grub (Ubuntu Xenial): assignee |
|
Matthew Ruffell (mruffell) |
|
| 2019-10-19 06:35:09 |
Matthew Ruffell |
grub (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2019-10-19 06:35:21 |
Matthew Ruffell |
tags |
id-5d484a6466c79944a30e4644 |
id-5d484a6466c79944a30e4644 sts |
|
| 2019-10-19 06:50:30 |
Matthew Ruffell |
description |
CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0".
This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37.
patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd
Description: Ubuntu 16.04.6 LTS
Release: 16.04
patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp
ii linux-gcp 4.15.0.1037.51 amd64 Complete Google Cloud Platform (GCP) Linux kernel and headers
ii linux-gcp-headers-4.15.0-1037 4.15.0-1037.39~16.04.1 amd64 Header files related to Linux kernel version 4.15.0
To reproduce:
1) Create an image with a disk size of 3072 using a serial that has GPT
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
Reboot the instance
2) It will hang on reboot and you cannot connect
3) Please note that later serials have the GPT change reverted.
You can replace xenial with bionic in the above commands to get a bionic instance instead.
To test this out in a more slower fashion:
1) Create an image with a disk size of 2048 using a serial that has GPT
gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048
2) Resize the disk to 3072
3) Issue growpart /dev/sda 1
4) Issue resize2fs /dev/sda1
5) Issue rsize2fs /dev/sda1 again
On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize.
I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. |
[Impact]
GCP wishes for xenial images to use GPT instead of MBR as a part of their efforts to change to efi based booting, but they have hit an issue where after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0".
This is a problem in grub2 where the system would become unbootable after ext* online resize if no resize_inode was created at ext* format time.
[Test Case]
To reproduce:
1) Create an image with a disk size of 3072 using a serial that has GPT:
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) Reboot the instance
The instance will hang on reboot and you cannot connect. If you go to GCP console and select Logs > Serial port 1 (console), you will see the boot process has stopped at "Booting Hard Disk 0".
I have built a test package, which is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test
If you do step 1) but do not reboot, and instead add the PPA, install the new grub like so:
1) gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) sudo add-apt-repository ppa:mruffell/lp1840686-test
3) sudo apt-get update
4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common
5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common
6) sudo grub-install /dev/sda
7) sudo reboot
The instance will boot successfully and you will be able to connect.
Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image, as it is enabled for GPT and efi. GCP was reverted back to MBR and bios booting because of this bug, so the latest images will not reproduce the problem.
[Regression Potential]
Grub is a core package and every care must be taken in order to not introduce any regressions.
The commit is present in B, D, E and F, and is considered well tested and widely adopted by the community.
The commit comes with its own testcase, to test the ext4_metabg fix.
The changes are localised to ext* based filesystems, although since they are the most popular family of filesystems used by the community, this does not reduce risk of breakage by much.
If a regression were to happen, a regression would have a large impact, and in the worst case, can lead to unbootable systems and data loss for users who are not technical enough to reinstall grub from a working package inside the broken system chroot.
[Other Info]
In comment #4, Sultan identifies the fix as:
commit e20aa39ea4298011ba716087713cff26c6c52006
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date: Mon Feb 16 20:53:26 2015 +0100
Subject: ext2: Support META_BG.
This commit is from upstream grub2, and can be found here:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006
Looking at when this was merged:
$ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
2.02-beta3~429
This commit is present in B, D, E and F, leaving X as the only version needing an SRU.
The commit cleanly cherry picks to X, because the delta from 2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small. |
|
| 2019-10-19 06:55:43 |
Matthew Ruffell |
description |
[Impact]
GCP wishes for xenial images to use GPT instead of MBR as a part of their efforts to change to efi based booting, but they have hit an issue where after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0".
This is a problem in grub2 where the system would become unbootable after ext* online resize if no resize_inode was created at ext* format time.
[Test Case]
To reproduce:
1) Create an image with a disk size of 3072 using a serial that has GPT:
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) Reboot the instance
The instance will hang on reboot and you cannot connect. If you go to GCP console and select Logs > Serial port 1 (console), you will see the boot process has stopped at "Booting Hard Disk 0".
I have built a test package, which is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test
If you do step 1) but do not reboot, and instead add the PPA, install the new grub like so:
1) gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) sudo add-apt-repository ppa:mruffell/lp1840686-test
3) sudo apt-get update
4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common
5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common
6) sudo grub-install /dev/sda
7) sudo reboot
The instance will boot successfully and you will be able to connect.
Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image, as it is enabled for GPT and efi. GCP was reverted back to MBR and bios booting because of this bug, so the latest images will not reproduce the problem.
[Regression Potential]
Grub is a core package and every care must be taken in order to not introduce any regressions.
The commit is present in B, D, E and F, and is considered well tested and widely adopted by the community.
The commit comes with its own testcase, to test the ext4_metabg fix.
The changes are localised to ext* based filesystems, although since they are the most popular family of filesystems used by the community, this does not reduce risk of breakage by much.
If a regression were to happen, a regression would have a large impact, and in the worst case, can lead to unbootable systems and data loss for users who are not technical enough to reinstall grub from a working package inside the broken system chroot.
[Other Info]
In comment #4, Sultan identifies the fix as:
commit e20aa39ea4298011ba716087713cff26c6c52006
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date: Mon Feb 16 20:53:26 2015 +0100
Subject: ext2: Support META_BG.
This commit is from upstream grub2, and can be found here:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006
Looking at when this was merged:
$ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
2.02-beta3~429
This commit is present in B, D, E and F, leaving X as the only version needing an SRU.
The commit cleanly cherry picks to X, because the delta from 2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small. |
[Impact]
GCP wishes for xenial images to use GPT instead of MBR as a part of their efforts to change to efi based booting, but they have hit an issue where after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0").
This is a problem in grub2 where the system would become unbootable after ext* online resize if no resize_inode was created at ext* format time.
[Test Case]
To reproduce:
1) Create an image with a disk size of 3072 GB using a serial that has GPT:
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) Reboot the instance
The instance will hang on reboot and you cannot connect. If you go to GCP console and select Logs > Serial port 1 (console), you will see the boot process has stopped at "Booting Hard Disk 0".
I have built a test package, which is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test
If you do step 1) but do not reboot, and instead add the PPA, install the new grub like so:
1) gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) sudo add-apt-repository ppa:mruffell/lp1840686-test
3) sudo apt-get update
4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common
5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common
6) sudo grub-install /dev/sda
7) sudo reboot
The instance will boot successfully and you will be able to connect.
Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image, as it is enabled for GPT and efi. GCP was reverted back to MBR and bios booting because of this bug, so the latest images will not reproduce the problem.
[Regression Potential]
Grub is a core package and every care must be taken in order to not introduce any regressions.
The commit is present in B, D, E and F, and is considered well tested and widely adopted by the community.
The commit comes with its own testcase, to test the ext4_metabg fix.
The changes are localised to ext* based filesystems, although since they are the most popular family of filesystems used by the community, this does not reduce risk of breakage by much.
If a regression were to happen, a regression would have a large impact, and in the worst case, can lead to unbootable systems and data loss for users who are not technical enough to reinstall grub from a working package inside the broken system chroot.
[Other Info]
In comment #4, Sultan identifies the fix as:
commit e20aa39ea4298011ba716087713cff26c6c52006
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date: Mon Feb 16 20:53:26 2015 +0100
Subject: ext2: Support META_BG.
This commit is from upstream grub2, and can be found here:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006
Looking at when this was merged:
$ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
2.02-beta3~429
This commit is present in B, D, E and F, leaving X as the only version needing an SRU.
The commit cleanly cherry picks to X, because the delta from 2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small. |
|
| 2019-10-29 21:03:22 |
Matthew Ruffell |
attachment added |
|
grub2 debdiff for xenial https://bugs.launchpad.net/cloud-init/+bug/1840686/+attachment/5301264/+files/lp1840686_xenial.debdiff |
|
| 2019-10-29 21:03:50 |
Matthew Ruffell |
tags |
id-5d484a6466c79944a30e4644 sts |
id-5d484a6466c79944a30e4644 sts sts-sponsor |
|
| 2019-10-29 21:23:50 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2019-10-29 21:47:30 |
Matthew Ruffell |
description |
[Impact]
GCP wishes for xenial images to use GPT instead of MBR as a part of their efforts to change to efi based booting, but they have hit an issue where after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0").
This is a problem in grub2 where the system would become unbootable after ext* online resize if no resize_inode was created at ext* format time.
[Test Case]
To reproduce:
1) Create an image with a disk size of 3072 GB using a serial that has GPT:
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) Reboot the instance
The instance will hang on reboot and you cannot connect. If you go to GCP console and select Logs > Serial port 1 (console), you will see the boot process has stopped at "Booting Hard Disk 0".
I have built a test package, which is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test
If you do step 1) but do not reboot, and instead add the PPA, install the new grub like so:
1) gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) sudo add-apt-repository ppa:mruffell/lp1840686-test
3) sudo apt-get update
4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common
5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common
6) sudo grub-install /dev/sda
7) sudo reboot
The instance will boot successfully and you will be able to connect.
Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image, as it is enabled for GPT and efi. GCP was reverted back to MBR and bios booting because of this bug, so the latest images will not reproduce the problem.
[Regression Potential]
Grub is a core package and every care must be taken in order to not introduce any regressions.
The commit is present in B, D, E and F, and is considered well tested and widely adopted by the community.
The commit comes with its own testcase, to test the ext4_metabg fix.
The changes are localised to ext* based filesystems, although since they are the most popular family of filesystems used by the community, this does not reduce risk of breakage by much.
If a regression were to happen, a regression would have a large impact, and in the worst case, can lead to unbootable systems and data loss for users who are not technical enough to reinstall grub from a working package inside the broken system chroot.
[Other Info]
In comment #4, Sultan identifies the fix as:
commit e20aa39ea4298011ba716087713cff26c6c52006
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date: Mon Feb 16 20:53:26 2015 +0100
Subject: ext2: Support META_BG.
This commit is from upstream grub2, and can be found here:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006
Looking at when this was merged:
$ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
2.02-beta3~429
This commit is present in B, D, E and F, leaving X as the only version needing an SRU.
The commit cleanly cherry picks to X, because the delta from 2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small. |
[Impact]
On Xenial images which use GPT instead of MBR to enable efi based booting, there is an issue where after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0").
This is a problem in grub2 where the system would become unbootable after ext* online resize if no resize_inode was created at ext* format time.
[Test Case]
To reproduce:
1) Create an image with a disk size of 3072 GB using a serial that has GPT:
gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) Reboot the instance
The instance will hang on reboot and you cannot connect. If you go to GCP console and select Logs > Serial port 1 (console), you will see the boot process has stopped at "Booting Hard Disk 0".
I have built a test package, which is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test
If you do step 1) but do not reboot, and instead add the PPA, install the new grub like so:
1) gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072
2) sudo add-apt-repository ppa:mruffell/lp1840686-test
3) sudo apt-get update
4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common
5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common
6) sudo grub-install /dev/sda
7) sudo reboot
The instance will boot successfully and you will be able to connect.
Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image, as it is enabled for GPT and efi. GCP was reverted back to MBR and bios booting because of this bug, so the latest images will not reproduce the problem.
[Regression Potential]
Grub is a core package and every care must be taken in order to not introduce any regressions.
The commit is present in B, D, E and F, and is considered well tested and widely adopted by the community.
The commit comes with its own testcase, to test the ext4_metabg fix.
The changes are localised to ext* based filesystems, although since they are the most popular family of filesystems used by the community, this does not reduce risk of breakage by much.
If a regression were to happen, a regression would have a large impact, and in the worst case, can lead to unbootable systems and data loss for users who are not technical enough to reinstall grub from a working package inside the broken system chroot.
[Other Info]
In comment #4, Sultan identifies the fix as:
commit e20aa39ea4298011ba716087713cff26c6c52006
Author: Vladimir Serbinenko <phcoder@gmail.com>
Date: Mon Feb 16 20:53:26 2015 +0100
Subject: ext2: Support META_BG.
This commit is from upstream grub2, and can be found here:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006
Looking at when this was merged:
$ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
2.02-beta3~429
This commit is present in B, D, E and F, leaving X as the only version needing an SRU.
The commit cleanly cherry picks to X, because the delta from 2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small. |
|
| 2019-10-29 22:20:07 |
Eric Desrochers |
tags |
id-5d484a6466c79944a30e4644 sts sts-sponsor |
id-5d484a6466c79944a30e4644 sts sts-sponsor sts-sponsor-slashd |
|
| 2019-10-30 12:04:46 |
Eric Desrochers |
removed subscriber STS Sponsors |
|
|
|
| 2019-10-30 12:04:50 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2019-10-30 12:05:07 |
Eric Desrochers |
tags |
id-5d484a6466c79944a30e4644 sts sts-sponsor sts-sponsor-slashd |
id-5d484a6466c79944a30e4644 sts |
|
| 2019-11-04 14:45:08 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-11-04 14:45:10 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2019-11-04 14:45:13 |
Łukasz Zemczak |
tags |
id-5d484a6466c79944a30e4644 sts |
id-5d484a6466c79944a30e4644 sts verification-needed verification-needed-xenial |
|
| 2019-11-05 00:51:52 |
Eric Desrochers |
bug task added |
|
grub2-signed (Ubuntu) |
|
| 2019-11-05 00:52:00 |
Eric Desrochers |
grub2-signed (Ubuntu): status |
New |
In Progress |
|
| 2019-11-05 00:52:04 |
Eric Desrochers |
grub2-signed (Ubuntu): importance |
Undecided |
High |
|
| 2019-11-05 00:52:07 |
Eric Desrochers |
grub2-signed (Ubuntu): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-11-05 00:57:33 |
Eric Desrochers |
grub2-signed (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-11-05 00:57:36 |
Eric Desrochers |
grub2-signed (Ubuntu): assignee |
Eric Desrochers (slashd) |
|
|
| 2019-11-05 00:57:41 |
Eric Desrochers |
grub2-signed (Ubuntu): importance |
High |
Undecided |
|
| 2019-11-05 05:50:25 |
Adam Conrad |
affects |
grub (Ubuntu) |
grub2 (Ubuntu) |
|
| 2019-11-05 06:49:21 |
Adam Conrad |
grub2-signed (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2019-11-05 06:49:36 |
Adam Conrad |
grub2 (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-11-05 12:30:31 |
Eric Desrochers |
grub2-signed (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2019-11-05 12:30:39 |
Eric Desrochers |
grub2-signed (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2019-11-06 23:07:09 |
Matthew Ruffell |
tags |
id-5d484a6466c79944a30e4644 sts verification-needed verification-needed-xenial |
id-5d484a6466c79944a30e4644 sts verification-done-xenial |
|
| 2019-11-11 16:00:13 |
Launchpad Janitor |
grub2 (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-11-11 16:00:37 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-11-11 16:10:28 |
Launchpad Janitor |
grub2-signed (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2023-05-11 22:41:10 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/3431 |
|
