| 2020-09-22 11:06:19 |
Michael Vogt |
bug |
|
|
added bug |
| 2020-09-23 07:43:03 |
Michael Vogt |
summary |
grub-multi-install fails with exit 1 when question grub-efi/install_devices_empty is skipped |
[regression-in-stable] grub-multi-install fails with exit 1 when question grub-efi/install_devices_empty is skipped |
|
| 2020-09-25 16:09:26 |
Łukasz Zemczak |
tags |
|
regression-update rls-ff-incoming |
|
| 2020-09-28 11:20:27 |
Dimitri John Ledkov |
description |
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
|
| 2020-09-28 13:06:56 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-09-28 13:06:56 |
Dimitri John Ledkov |
bug task added |
|
grub2 (Ubuntu Groovy) |
|
| 2020-09-28 13:06:56 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-09-28 13:06:56 |
Dimitri John Ledkov |
bug task added |
|
grub2 (Ubuntu Bionic) |
|
| 2020-09-28 13:06:56 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Focal |
|
| 2020-09-28 13:06:56 |
Dimitri John Ledkov |
bug task added |
|
grub2 (Ubuntu Focal) |
|
| 2020-09-28 13:07:40 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xnox/grub/+git/grub/+merge/391438 |
|
| 2020-09-28 13:12:46 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xnox/grub/+git/grub/+merge/391439 |
|
| 2020-09-29 09:58:39 |
Dimitri John Ledkov |
description |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
|
| 2020-09-29 10:00:19 |
Dimitri John Ledkov |
description |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
Test #1 can also be done in chroot as follows:
mkdir -p /boot/grub/x86_64-efi
touch /boot/grub/x86_64-efi/core.efi
dpkg-reconfigure grub-efi-amd64-signed
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-efi-amd64-signed
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
|
| 2020-09-29 10:01:32 |
Dimitri John Ledkov |
description |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
Test #1 can also be done in chroot as follows:
mkdir -p /boot/grub/x86_64-efi
touch /boot/grub/x86_64-efi/core.efi
dpkg-reconfigure grub-efi-amd64-signed
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-efi-amd64-signed
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
Test #1 can also be done in lxd as follows:
mkdir -p /boot/grub/x86_64-efi
touch /boot/grub/x86_64-efi/core.efi
dpkg-reconfigure grub-efi-amd64-signed
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-efi-amd64-signed
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
|
| 2020-09-29 10:16:46 |
Dimitri John Ledkov |
description |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
Test #1 can also be done in lxd as follows:
mkdir -p /boot/grub/x86_64-efi
touch /boot/grub/x86_64-efi/core.efi
dpkg-reconfigure grub-efi-amd64-signed
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-efi-amd64-signed
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
Test #1 can also be done in a VM as follows:
mkdir -p /boot/grub/x86_64-efi
touch /boot/grub/x86_64-efi/core.efi
dpkg-reconfigure grub-efi-amd64-signed
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-efi-amd64-signed
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
|
| 2020-09-29 10:54:01 |
Dimitri John Ledkov |
description |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
[Test Case]
* Install in bios mode. Ensure that shim-signed is installed, configure debconf to have seen grub-efi/install_devices_empty question and have it as true, and have grub-efi/install_devices seen and empty.
* Attempt reconfigure of grub-efi-*-signed, it should be successful. (test #1)
Test #1 can also be done in a VM as follows:
mkdir -p /boot/grub/x86_64-efi
touch /boot/grub/x86_64-efi/core.efi
dpkg-reconfigure grub-efi-amd64-signed
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-efi-amd64-signed
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful. (test #2)
Test #2 can also be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix is not regressed). (test #3)
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
[Impact]
* When both grub-pc & grub-efi-*-signed are installed, it is ok for one of them to not install onto any devices and mark install_devices_empty as true such that machine is booted with just one boot loader type, and not both.
* In such cases, the recently SRUed postinst will behave incorrectly upon reconfigure, instead demanding user to install both types of bootloaders somewhere.
* Error can only be triggered by abandonned grub-pc install, as grub-multi-install validates install_devices values and resets configuration logic.
[Test Case]
* Install in efi mode. Ensure that grub-pc is installed, configure debconf to have seen grub-pc/install_devices_empty question and have it as true, and have grub-pc/install_devices seen and empty.
* Attempt reconfigure of grub-pc, it should be successful.
All this can be done in chroot as follows:
mkdir -p /boot/grub/i386-pc
touch /boot/grub/i386-pc/core.img
dpkg-reconfigure grub-pc
(answer defaults, and choose to not install GRUB to any devices)
Then:
dpkg-reconfigure -u grub-pc
should succed, with exit code 0, when this bug is fixed. The current broken packages return exit code 1.
* Populate grub-efi/install_devices & grub-pc/install_devices with invalid devices and set install_devices_empty to false, attempt non-interactive reconfigure. It should still fail. (A check that previous bug-fix does not regress).
[Regression Potential]
* This partially revert previous update which made that code path error out. One too many error paths got added by xnox. The other bug, to ensure when installing onto missing devices noninteractively the package configure fails is still being check for (test #3).
[Other Info]
* original bug report
A 20.04 machine with grub-efi-amd64-signed that recently got upgraded fails with:
"""
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
"""
unfortunately not much more context was provided. After some debugging it turns out that there are the following lines in /usr/lib/grub/grub-multi-install:
"""
db_get "$question"
if [ -z "$RET" ]; then
# Reset the seen flag if the current answer is false, since
# otherwise we'll loop with no indication of why.
db_get grub-efi/install_devices_empty
if [ "$RET" = false ]; then
db_fset grub-efi/install_devices_empty seen false
fi
if db_input critical grub-efi/install_devices_empty; then
db_go
db_get grub-efi/install_devices_empty
if [ "$RET" = true ]; then
break
else
db_fset "$question" seen false
db_fset grub-efi/install_devices_empty seen false
fi
else
exit 1 # noninteractive
fi
"""
when grub-efi/install_devices_empty has the flag "seen" the line
if db_input critical grub-efi/install_devices_empty; then
will return "30" if the question was already shown but the rfset eset happens only if the anser was "false" earlier. So the code jumps to "exit 1".
So either the code need to always reset the seen flag ( db_fset grub-efi/install_devices_empty seen false) or deal with exit code 30 from "db_input critical grub-efi/install_devices_empty" more gracefully.
I can provide a /var/cache/debconf/config.dat to reproduce. I'm not entirely sure how to reproduce from a clean install, the bug will only happen after the first upgrade. |
|
| 2020-10-01 14:52:25 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xnox/grub/+git/grub/+merge/391699 |
|
| 2020-10-01 15:33:02 |
Brian Murray |
tags |
regression-update rls-ff-incoming |
regression-update |
|
| 2020-10-05 07:38:26 |
DEXTER |
bug |
|
|
added subscriber DEXTER |
| 2020-10-05 09:28:06 |
Launchpad Janitor |
grub2 (Ubuntu): status |
New |
Confirmed |
|
| 2020-10-05 09:28:06 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2020-10-05 09:28:06 |
Launchpad Janitor |
grub2 (Ubuntu Focal): status |
New |
Confirmed |
|
| 2020-10-05 14:14:50 |
mkurz |
bug |
|
|
added subscriber mkurz |
| 2020-10-06 17:19:39 |
Launchpad Janitor |
grub2 (Ubuntu Groovy): status |
Confirmed |
Fix Released |
|
| 2020-10-06 23:03:36 |
Brian Murray |
grub2 (Ubuntu Focal): status |
Confirmed |
Fix Committed |
|
| 2020-10-06 23:03:38 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-10-06 23:03:41 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2020-10-06 23:03:45 |
Brian Murray |
tags |
regression-update |
regression-update verification-needed verification-needed-focal |
|
| 2020-10-07 03:33:52 |
Mike |
bug |
|
|
added subscriber Mike |
| 2020-10-07 12:57:52 |
Scott Talbert |
bug |
|
|
added subscriber Scott Talbert |
| 2020-10-13 13:37:09 |
Gianfranco Costamagna |
tags |
regression-update verification-needed verification-needed-focal |
regression-update verification-done verification-done-focal |
|
| 2020-10-14 15:34:19 |
Florent Fortin |
bug |
|
|
added subscriber Florent Fortin |
| 2020-10-22 15:58:06 |
Matthew Montgomery |
bug |
|
|
added subscriber Matthew Montgomery |
| 2020-10-26 11:05:29 |
Launchpad Janitor |
grub2 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-10-26 11:05:42 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-10-27 13:17:30 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xnox/grub/+git/grub/+merge/392865 |
|
| 2020-10-27 20:11:02 |
Brian Murray |
grub2 (Ubuntu Bionic): status |
Confirmed |
Fix Committed |
|
| 2020-10-27 20:11:05 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-10-27 20:11:14 |
Brian Murray |
tags |
regression-update verification-done verification-done-focal |
regression-update verification-done-focal verification-needed verification-needed-bionic |
|
| 2020-10-28 00:41:23 |
Jim Kleckner |
bug |
|
|
added subscriber Jim Kleckner |
| 2020-11-10 10:50:14 |
Dimitri John Ledkov |
tags |
regression-update verification-done-focal verification-needed verification-needed-bionic |
regression-update verification-done verification-done-bionic verification-done-focal |
|
| 2020-11-12 12:27:57 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-11-12 14:43:18 |
Matthew Montgomery |
removed subscriber Matthew Montgomery |
|
|
|
