grub-pc needs to detect when debconf points to invalid drive and stop in preinst, before unpacking files, and also treat this as a failure in postinst
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| grub2 (Ubuntu) |
Critical
|
Dimitri John Ledkov | ||
| Xenial |
Critical
|
Unassigned | ||
| Bionic |
Critical
|
Unassigned | ||
| Focal |
Critical
|
Unassigned | ||
| Groovy |
Critical
|
Dimitri John Ledkov |
Bug Description
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* First we will test a case where target boot device exists, yet writes to it are denied, thus one can update modules, but cannot update the MBR.
* install /etc/apparmor.
"/usr/sbin/
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/* w,
}
and load it with
sudo apparmor_parser -r usr.sbin.
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/
* Remove the apparmor profile /etc/apparmor.
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Now we will test a case where a non-existing device ended up being configured in debconf. For example, due to old buggy cloud-init having been used during first boot, or because the VM got migrated from one hardware configuration to another (i.e. offline switch from SCSI sda, to VIRTIO vda).
* Configure invalid grub-pc/
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails (out of disk space),
in such scenario MBR is not rolled back to previous one. Or a case
where MBR updates have succeeded, but only on some devices.
A choice has been made to update modules in /boot, if at least one
device has a successful MBR update. No backup, or rollback of MBR is
performed if module updates fail. This is tricky to do, as it is
uncertain if current MBR matches the core.img & boot.img from /boot, or
if some other bootsectors code was in use before. Ideally in the
future, grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report description
Currently on upgrade if the debconf variable for the drive to install grub-pc to point to a non-existent drive, the grub package will nevertheless happily carry on and the postinst will exit 0 - as a result leaving the /boot/grub contents and the MBR in an inconsistent state, which due to recent ABI changes will leave the system unbootable on reboot.
Three changes required in order to make grub upgrades more resilient:
- exit non-zero from the postinst when the drive targets are invalid, so that we signal to the user that there is a problem BEFORE they reboot and give them the opportunity to deal with it. This is addressed by https:/
- include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall. This is addressed by https:/
- modify grub-install so that it handles the flaky part of the install - updating the BIOS disks - FIRST, and aborts if this fails; instead of the current behavior, which is that /boot/grub is updated on disk first, then it attempts to install to the BIOS disk, and if this part fails, no rollback of the contents of /boot/grub is possible.
Related branches
- Steve Langasek: Approve on 2020-08-31
- Julian Andres Klode: Pending requested 2020-08-28
- Ubuntu Core Development Team: Pending requested 2020-08-28
-
Diff: 391 lines (+283/-20)7 files modifiedconfigure.ac (+1/-1)
debian/.git-dpm (+2/-2)
debian/changelog (+12/-0)
debian/patches/grub-install-backup-and-restore.patch (+175/-0)
debian/patches/series (+1/-0)
debian/postinst.in (+2/-2)
util/grub-install-common.c (+90/-15)
Changed in grub2 (Ubuntu): | |
importance: | Undecided → Critical |
Changed in grub2 (Ubuntu Focal): | |
importance: | Undecided → Critical |
Changed in grub2 (Ubuntu Bionic): | |
importance: | Undecided → Critical |
Changed in grub2 (Ubuntu Xenial): | |
importance: | Undecided → Critical |
description: | updated |
Launchpad Janitor (janitor) wrote : | #1 |
Changed in grub2 (Ubuntu Bionic): | |
status: | New → Confirmed |
Changed in grub2 (Ubuntu Focal): | |
status: | New → Confirmed |
Changed in grub2 (Ubuntu Xenial): | |
status: | New → Confirmed |
Changed in grub2 (Ubuntu): | |
status: | New → Confirmed |
Dimitri John Ledkov (xnox) wrote : | #5 |
First point => yes
Second point => mostly yes, but I am not sold on having it a must in preinst. dpkg-reconfigure does not call preinst, it only calls "prerm config postinst", and we must have the same checks and error recovery in postinst. (Because things can change between preinst and postinst, and/or fail to apply).
Third point => it is slightly more elaborate. Even when asking grub-install to not install any modules, or bootcode, the following files are still updated none-the-less
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/lib/
grub-install: info: copying `/usr/share/
grub-install: info: grub-mkimage --directory '/usr/lib/
grub-install: info: copying `/usr/lib/
And for example since we do not provide prebuild core.img it needs to be generated somewhere first before applying it to the MBR.
grub-install only takes one device at the time. So I'm not sure what to do with updating modules, if multiple devices need MBR updates, all exist, yet some of them fail to apply MBR. I feel like erroring on the optimistic side, if at least one MBR update was successful, update the modules.
What can be achieved, with very minimal amount of code is to separate bootcode updates from the /boot/ modules updates. And if any bootcode updates are successful, only then attempt to install modules.
Changed in grub2 (Ubuntu Groovy): | |
status: | Confirmed → In Progress |
assignee: | nobody → Dimitri John Ledkov (xnox) |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Dimitri John Ledkov (xnox) wrote : | #6 |
I disagree that preinst changes are needed.
I have fixed error reporting in non-interactive postinst case.
And made grub-install resilient, w.r.t. operating against non-existent devices or devices that refuse writing to. In all such cases, backup is created and restored. Thus there is no need to abort at preinst. Consistency between MBR & /boot is required and fixed here, without reimplementing postinst in preinst.
tags: | added: id-5f36bab45785997ba0092e8a |
Changed in grub2 (Ubuntu Groovy): | |
status: | In Progress → Fix Committed |
Launchpad Janitor (janitor) wrote : | #7 |
This bug was fixed in the package grub2 - 2.04-1ubuntu29
---------------
grub2 (2.04-1ubuntu29) groovy; urgency=medium
* grub-install: cherry-pick patch from grub-devel to make grub-install
fault tolerant. Create backup of files in /boot/grub, and restore them
on failure to complete grub-install. LP: #1891680
* postinst.in: do not exit successfully when failing to show critical
grub-
prompts in non-interactive mode. This enables surfacing upgrade errors
to the users and/or automation. LP: #1891680
* postinst.in: Fixup postinst.in, to attempt grub-install upon explicit
dpkg-
-- Dimitri John Ledkov <email address hidden> Tue, 01 Sep 2020 20:04:44 +0100
Changed in grub2 (Ubuntu Groovy): | |
status: | Fix Committed → Fix Released |
Andrei Shevchuk (shevchuk) wrote : | #8 |
Will this fix be backported to Focal? This is the only bug blocking upgrades from 18.04 to 20.04, afaik.
Tero Gusto (tero-gusto) wrote : | #9 |
Yes, it looks that way:
"Focal Fossa (20.04.1 LTS) Point-Release Status Tracking"
https:/
Changed in grub2 (Ubuntu Focal): | |
status: | Confirmed → In Progress |
ded (ded-launchpad) wrote : | #10 |
Is there an ETA when we can finally do-release-upgrade from 18.04 to 20.04?
costinel (costinel) wrote : | #11 |
@ded, the bug says for groovy
Started work: 2020-08-18
Completed: 2020-09-02
for focal,
Started work: 2020-09-08
so one can only guess it would take another two weeks, if the same work conditions apply
Hello Steve, or anyone else affected,
Accepted grub2 into focal-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in grub2 (Ubuntu Focal): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed verification-needed-focal |
costinel (costinel) wrote : | #13 |
@vorlon,
some of us here are innocent 18.04LTS users waiting for canonical to enable do-release-upgrade to focal, because this issue is blocking the LTS to LTS upgrade process (link in comment #9)
with that in mind, how can we help testing without access to focal?
On Wed, Sep 09, 2020 at 08:51:49PM -0000, costinel wrote:
> some of us here are innocent 18.04LTS users waiting for canonical to
> enable do-release-upgrade to focal, because this issue is blocking the LTS
> to LTS upgrade process (link in comment #9)
There is a test case in the description that explains how this SRU will be
verified.
If you are not sure how to access focal, it is best not to attempt to test.
The testing will be handled by the development team as a matter of course,
and the packages released when they are ready for general consumption.
All autopkgtests for the newly accepted grub2 (2.04-1ubuntu26.4) for focal have finished running.
The following regressions have been reported in tests triggered by the package:
grubzfs-
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Dimitri John Ledkov (xnox) wrote : | #16 |
Installed from 18.04.4 media, in bios mode.
Added and loaded apparmor profile.
Enabled focal, focal-updates, focal-proposed archives.
Exported DEBIAN_
Started upgrade of grub-pc grub-pc-bin grub2-common grub-common.
Configuration of grub-pc 2.04-1.ubuntu26.4 failed (GOOD) iF state
in /boot/grub git diff shows only one change => fonts/unicode.pf2 has changed. (not ideal, but nothing else important has changed, i.e. all modules are the same and modinfo.sh still says 2.02-2ubuntu8.18 as the package version) (GOOD)
executed
echo grub-pc grub-pc/
to set install_devices to invalid /dev/sda, instead of the correct /dev/vda for the next test case. And removed the apparmor profile.
Reboot. Still worked (good)
exported DEBIAN_
configuration/
Finally performing dpkg --configure -a worked, got asked which drive to update, elected the correct /dev/vda and all modules got updated in the /boot/grub dir. Reboot works. (GOOD)
Just to be sure, executed dpkg-reconfigure grub-pc and all questions got asked and grub got installed onto /dev/vda again. (GOOD)
tags: |
added: verification-done verification-done-focal removed: verification-needed verification-needed-focal |
Changed in grub2 (Ubuntu Focal): | |
status: | Fix Committed → Fix Released |
Louis Fall (yoshi2602) wrote : | #17 |
Sorry, didn't meant to change the status, I cannot revert the change.
Changed in grub2 (Ubuntu Focal): | |
status: | Fix Released → Fix Committed |
Marco Antonio Abreu (mabreu-ti) wrote : | #18 |
Hi, Louis.
You made me happy for a few minutes.
Regards.
Launchpad Janitor (janitor) wrote : | #19 |
This bug was fixed in the package grub2 - 2.04-1ubuntu26.4
---------------
grub2 (2.04-1ubuntu26.4) focal; urgency=medium
* grub-install: cherry-pick patch from grub-devel to make grub-install
fault tolerant. Create backup of files in /boot/grub, and restore them
on failure to complete grub-install. LP: #1891680
* postinst.in: do not exit successfully when failing to show critical
grub-
prompts in non-interactive mode. This enables surfacing upgrade errors
to the users and/or automation. LP: #1891680
* postinst.in: do not attempt to call grub-install upon fresh install of
grub-pc because it it a job of installers to do that after fresh
install. Fixup for the issue unmasked by above. LP: #1891680
* grub-multi-install: fix non-interactive failures for grub-efi like it
was fixed in postinst for grub-pc. LP: #1891680
* postinst.in: Fixup postinst.in, to attempt grub-install upon explicit
dpkg-
-- Dimitri John Ledkov <email address hidden> Tue, 08 Sep 2020 11:24:35 +0100
Changed in grub2 (Ubuntu Focal): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for grub2 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Saurabh Minni (the100rabh) wrote : | #21 |
Does this not need to be backported all the way to Xenial and Bionic ?
costinel (costinel) wrote : | #22 |
ok, so now that this is fixed, why is ubuntu 18.04 to 20.04.1 still blocked?
Crashbit (crashbit-gmail) wrote : | #23 |
As you can see, Bionic status is Confirmed, not fix released!
Hadmut Danisch (hadmut) wrote : | #24 |
So for upgrading from release X to Y both X and Y must not have critical bugs?
On September 20, 2020 5:09:37 AM PDT, Hadmut Danisch <email address hidden> wrote:
>So for upgrading from release X to Y both X and Y must not have
>critical bugs?
Nothing of the sort. This bug is no longer a blocker now that it's fixed in focal, and I believe the intent is to turn on upgrades this coming week.
--
Steve Langasek
Saurabh Minni (the100rabh) wrote : | #26 |
I wonder why this is still mentioned as upgrade blocker at https:/
Chris (iversc) wrote : | #27 |
Since this is the final blocker, I think they're just leaving that status alone until they actually publish 20.04.1 for upgrade, so they don't get a deluge of people asking why it's not released yet if there's no blockers.
Probably running final tests on the upgrade path.
Brian Murray (brian-murray) wrote : | #28 |
On Fri, Sep 25, 2020 at 05:57:15PM -0000, Chris wrote:
> Since this is the final blocker, I think they're just leaving that
> status alone until they actually publish 20.04.1 for upgrade, so they
> don't get a deluge of people asking why it's not released yet if there's
> no blockers.
>
> Probably running final tests on the upgrade path.
That is correct, our intent is to turn on upgrades next week.
--
Brian Murray
BDisp (bdisp) wrote : | #29 |
The strange is that the Ubuntu 20.04 LTS is already available from the Windows 10 store.
It's possible to install this version and transfer all the configuration, applications and repositories from Ubuntu 18.04.5 LTS to 20.04 LTS?
Roger Peris (rugeps) wrote : | #30 |
Upgrade (from v18.04 to 20.04) is already released!
Thanks to everybody for your debbuging and support!
BDisp (bdisp) wrote : | #31 |
I was unable to upgrade and this link (https:/
regenpfeifer (regenpfeifer) wrote : | #32 |
Unfortunately, this bug seems not fixed for me.
I am using a remote server at 1&1 Hosting with a RAID 1 configuration and logical volumes (LVM). I am starting with a fresh image of Ubuntu 18.04 LTS. With do-release-upgrade I can upgrade to Ubuntu 20.04 LTS, but I am ending with this error:
Errors were encountered while processing:
grub-pc
Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1)
After that my system is unusable. It cannot be updated, no packages can be installed. I can reboot, but when I try to fix the error with re-installing grub-pc it becomes unbootable.
Guss (guss-d) wrote : | #33 |
I can confirm that this bug is not fixed. Today Ubuntu informed me of 20.04 and I started the distribution upgrade. I got the following message:
"Could not install 'grub-pc'. The upgrade will continue but the 'grub-pc' package may not be in a working state. Please consider a bug report about it. Installed grub-pc package post-installation script subprocess returned error exit status 1."
I can reboot normally and so far I can tell everything is working. When I do a # apt autoremove I get the following error:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up grub-pc (2.04-1ubuntu26.4) ...
dpkg: error processing package grub-pc (--configure):
installed grub-pc package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-crashdump:
linux-crashdump depends on grub-pc (>= 1.96+20090611-
Package grub-pc is not configured yet.
Package grub-efi-ia32 is not installed.
Package grub-efi-amd64 is not installed.
Package grub is not installed.
dpkg: error processing package linux-crashdump (--configure):
dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup erro
r from a previous failure.
grub-pc
linux-crashdump
E: Sub-process /usr/bin/dpkg returned an error code (1)
Steve Langasek (vorlon) wrote : | #34 |
> "Could not install 'grub-pc'. The upgrade will continue but the 'grub-
> pc' package may not be in a working state. Please consider a bug report
> about it. Installed grub-pc package post-installation script subprocess
> returned error exit status 1."
This is not evidence that this bug is not fixed. If your grub was misconfigured prior to upgrade, this is the INTENDED outcome: the package upgrade breaks, but importantly, it doesn't break in a way that leaves your system unbootable.
You should be able to run 'sudo dpkg-reconfigure grub-pc' to reconfigure grub to properly point at your boot disk, so that it is actually possible to upgrade grub on your system, and configure from there.
regenpfeifer (regenpfeifer) wrote : | #35 |
Hello Steve,
thank you for your explanation. In my case I am quite sure, that my grub was correctly configured BEFORE the upgrade to 20.04. I am starting with an absolutely fresh installation of 18.04 which is working flawlessly and reboots without any problems.
I have tried the upgrade to 20.04 with several fresh installations and am always ending up with this grub-pc error. sudo dpkg-reconfigure grub-pc gives me this error:
/usr/sbin/
I have tried to remove grub-pc and to install it again, which lets me choose the boot disk where grub should be located. This can be done without an error message, but after that my system is in an unbootable state.
costinel (costinel) wrote : | #36 |
this bionic to focal upgrade still fails. not sure if this is the proper place to discuss.
18.04.5 installed minimal in vmware player then do-release-upgrade:
https:/
18.04.5 setup deviations from defaults: root on thin lv created manually in terminal in live installer. lvm on gpt disk. /boot on second disk, mbr. grub fails to install on bionic, I booted with a recovery cd and manually forced install.
I had to make this adjustment to enable thin lv support in initrd (copied from somewhere i don't remember):
# cat /etc/initramfs-
#!/bin/sh
PREREQ="lvm2"
prereqs()
{
echo ""
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/
copy_exec /usr/sbin/thin_dump
copy_exec /usr/sbin/
copy_exec /usr/sbin/
copy_exec /sbin/dmeventd
copy_exec /lib/x86_
copy_exec /lib/x86_
copy_exec /lib/x86_
copy_exec /usr/sbin/
ln -s pdata_tools ${DESTDIR}
ln -s pdata_tools ${DESTDIR}
manual_add_modules dm-cache
manual_add_modules dm-cache-smq
manual_add_modules dm-thin-pool
costinel (costinel) wrote : | #37 |
I have enabled debugging on /var/lib/
but I don't understand from the above output why it fails
costinel (costinel) wrote : | #38 |
manually installing grub works like this:
# grub-install --force --removable --boot-
Installing for i386-pc platform.
Installation finished. No error reported.
meanwhile as a workaround I have symlinked /var/lib/
Julian Andres Klode (juliank) wrote : | #39 |
@costinel It's failing due to bug 1896608 in your case which is a regression from this update.
costinel (costinel) wrote : | #40 |
@juliank thank you.
accordingly #1896608 shouldn't be listed as a blocker on https:/
tags: | added: fr-114 |
Hello Steve, or anyone else affected,
Accepted grub2 into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in grub2 (Ubuntu Bionic): | |
status: | Confirmed → Fix Committed |
tags: |
added: verification-needed verification-needed-bionic removed: verification-done |
regenpfeifer (regenpfeifer) wrote : | #42 |
Unfortunately I have switched to Debian 10 meanwhile, so I cannot test the bugfix. Nevertheless thank you for your efforts. I will certainly return to Ubuntu in the future.
Dimitri John Ledkov (xnox) wrote : | #43 |
@regenpfeifer
Some of the identified issues affect debian too. we are working with debian maintainers to resolve them there too. It is unfortunate that some of the updates got pushed out rapidly, thus causing distress.
All autopkgtests for the newly accepted grub2 (2.02-2ubuntu8.19) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:
ubuntu-
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
Dimitri John Ledkov (xnox) wrote : | #45 |
started with xenial install.
grub2 is at 2.02~beta2-
put apparmor profile in place, and upgrading non-interactively
upgrade to 2.02-2ubuntu8.19 fails as expected with grub-install saying that error cannot open /dev/vda permission denied.
grub-pc package remains in iF state.
in /boot/grub everything is unchanged, but fonts/unicode.pf2 which should be relatively harmless.
reboot works with still old 3.28 in the grub-menu title
installing with invalid device (sda, whereas vda is in use) failed
new devices got offered to install grub onto
calling dpkg-reconfigure also installed grub onto the selected device
git status in /boot/grub confirms that all modules got updated, since new bootloader was installed onto the block device successfully.
reboot worked with the 2.02 (newstyle) menu header.
all is good.
tags: |
added: verification-done verification-done-bionic removed: verification-needed verification-needed-bionic |
Launchpad Janitor (janitor) wrote : | #46 |
This bug was fixed in the package grub2 - 2.02-2ubuntu8.19
---------------
grub2 (2.02-2ubuntu8.19) bionic; urgency=medium
* grub-install: cherry-pick patch from grub-devel to make grub-install
fault tolerant. Create backup of files in /boot/grub, and restore them
on failure to complete grub-install. LP: #1891680
Also cherry-pick patch to make atexit work correctly.
* postinst.in: do not exit successfully when failing to show critical
grub-
prompts in non-interactive mode. This enables surfacing upgrade errors
to the users and/or automation. LP: #1891680 LP: #1896608
* postinst.in: do not attempt to call grub-install upon fresh install of
grub-pc because it it a job of installers to do that after fresh
install. Fixup for the issue unmasked by above. LP: #1891680
* postinst.in: Fixup postinst.in, to attempt grub-install upon explicit
dpkg-
-- Dimitri John Ledkov <email address hidden> Thu, 22 Oct 2020 15:01:52 +0100
Changed in grub2 (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Status changed to 'Confirmed' because the bug affects multiple users.