[Bug 1891680] Re: 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

Dimitri John Ledkov 1891680 at bugs.launchpad.net
Tue Aug 18 13:59:16 UTC 2020


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/i386-pc/efiemu32.o' -> `/mnt/boot/grub/i386-pc/efiemu32.o'.
grub-install: info: copying `/usr/lib/grub/i386-pc/efiemu64.o' -> `/mnt/boot/grub/i386-pc/efiemu64.o'.
grub-install: info: copying `/usr/lib/grub/i386-pc/moddep.lst' -> `/mnt/boot/grub/i386-pc/moddep.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/command.lst' -> `/mnt/boot/grub/i386-pc/command.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/fs.lst' -> `/mnt/boot/grub/i386-pc/fs.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/partmap.lst' -> `/mnt/boot/grub/i386-pc/partmap.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/parttool.lst' -> `/mnt/boot/grub/i386-pc/parttool.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/video.lst' -> `/mnt/boot/grub/i386-pc/video.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/crypto.lst' -> `/mnt/boot/grub/i386-pc/crypto.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/terminal.lst' -> `/mnt/boot/grub/i386-pc/terminal.lst'.
grub-install: info: copying `/usr/lib/grub/i386-pc/modinfo.sh' -> `/mnt/boot/grub/i386-pc/modinfo.sh'.
grub-install: info: copying `/usr/share/grub/unicode.pf2' -> `/mnt/boot/grub/fonts/unicode.pf2'.
grub-install: info: grub-mkimage --directory '/usr/lib/grub/i386-pc' --prefix '(,msdos1)/boot/grub' --output '/mnt/boot/grub/i386-pc/core.img'  --dtb '' --format 'i386-pc' --compression 'auto'  'ext2' 'part_msdos' 'biosdisk' 
grub-install: info: copying `/usr/lib/grub/i386-pc/boot.img' -> `/mnt/boot/grub/i386-pc/boot.img'

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1891680

Title:
  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

Status in grub2 package in Ubuntu:
  Confirmed
Status in grub2 source package in Xenial:
  Confirmed
Status in grub2 source package in Bionic:
  Confirmed
Status in grub2 source package in Focal:
  Confirmed
Status in grub2 source package in Groovy:
  Confirmed

Bug 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://code.launchpad.net/~xnox/grub/+git/grub/+merge/388383
  - 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://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423
  - 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1891680/+subscriptions



More information about the foundations-bugs mailing list