[Group.of.nepali.translators] [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
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-pc/install_devices_failed and grub-pc/install_devices_empty 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-reconfigure grub-pc. LP: #1892526 -- Dimitri John Ledkov Thu, 22 Oct 2020 15:01:52 +0100 ** Changed in: grub2 (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: Fix Released Status in grub2 source package in Xenial: Confirmed Status in grub2 source package in Bionic: Fix Released Status in grub2 source package in Focal: Fix Released Status in grub2 source package in Groovy: Fix Released 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.d/usr.sbin.grub-install profile "/usr/sbin/grub-install" { capability, mount, ptrace, signal, unix, file, deny /dev/* w, } and load it with sudo apparmor_parser -r usr.sbin.grub-install * 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/grub/i386-pc * Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install * 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/install_devices to a non existing device (e.g. /dev/sdk) * 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/grub/i386-pc * 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/grub/i386-pc contents, and is different from the backup taken at the start. * 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
[Group.of.nepali.translators] [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
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-pc/install_devices_failed and grub-pc/install_devices_empty 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-reconfigure grub-pc. LP: #1892526 -- Dimitri John Ledkov Tue, 08 Sep 2020 11:24:35 +0100 ** Changed in: grub2 (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: Fix Released Status in grub2 source package in Xenial: Confirmed Status in grub2 source package in Bionic: Confirmed Status in grub2 source package in Focal: Fix Released Status in grub2 source package in Groovy: Fix Released 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.d/usr.sbin.grub-install profile "/usr/sbin/grub-install" { capability, mount, ptrace, signal, unix, file, deny /dev/* w, } and load it with sudo apparmor_parser -r usr.sbin.grub-install * 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/grub/i386-pc * Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install * 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/install_devices to a non existing device (e.g. /dev/sdk) * 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/grub/i386-pc * 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/grub/i386-pc contents, and is different from the backup taken at the start. * 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.
[Group.of.nepali.translators] [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
** Changed in: grub2 (Ubuntu Focal) Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: Fix Released Status in grub2 source package in Xenial: Confirmed Status in grub2 source package in Bionic: Confirmed Status in grub2 source package in Focal: Fix Committed Status in grub2 source package in Groovy: Fix Released 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.d/usr.sbin.grub-install profile "/usr/sbin/grub-install" { capability, mount, ptrace, signal, unix, file, deny /dev/* w, } and load it with sudo apparmor_parser -r usr.sbin.grub-install * 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/grub/i386-pc * Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install * 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/install_devices to a non existing device (e.g. /dev/sdk) * 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/grub/i386-pc * 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/grub/i386-pc contents, and is different from the backup taken at the start. * 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
[Group.of.nepali.translators] [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
** Changed in: grub2 (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: Fix Released Status in grub2 source package in Xenial: Confirmed Status in grub2 source package in Bionic: Confirmed Status in grub2 source package in Focal: Fix Released Status in grub2 source package in Groovy: Fix Released 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.d/usr.sbin.grub-install profile "/usr/sbin/grub-install" { capability, mount, ptrace, signal, unix, file, deny /dev/* w, } and load it with sudo apparmor_parser -r usr.sbin.grub-install * 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/grub/i386-pc * Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install * 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/install_devices to a non existing device (e.g. /dev/sdk) * 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/grub/i386-pc * 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/grub/i386-pc contents, and is different from the backup taken at the start. * 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
[Group.of.nepali.translators] [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
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-pc/install_devices_failed and grub-pc/install_devices_empty 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-reconfigure grub-pc. LP: #1892526 -- Dimitri John Ledkov Tue, 01 Sep 2020 20:04:44 +0100 ** Changed in: grub2 (Ubuntu Groovy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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: Fix Released 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: Fix Released 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.d/usr.sbin.grub-install profile "/usr/sbin/grub-install" { capability, mount, ptrace, signal, unix, file, deny /dev/* w, } and load it with sudo apparmor_parser -r usr.sbin.grub-install * 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/grub/i386-pc * Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install * 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/install_devices to a non existing device (e.g. /dev/sdk) * 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/grub/i386-pc * 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/grub/i386-pc contents, and is different from the backup taken at the start. * 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