[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
This bug was fixed in the package grub2 - 2.02~beta2-9ubuntu1.16 --- grub2 (2.02~beta2-9ubuntu1.16) trusty; urgency=medium [ Ivan Hu ] * debian/patches/0001-i386-linux-Add-support-for-ext_lfb_base.patch: Add support for ext_lfb_base. (LP: #1785033) [ dann frazier ] * Add grub2/update_nvram template to allow users to disable NVRAM updates during package upgrades (LP: #1642298). [ Mathieu Trudel-Lapierre ] * debian/patches: Rework linuxefi/SecureBoot support and sync with upstream SB patch set: (LP: #1696599) - linuxefi_backport_arm64.patch: backport basic arm64 chainload/linux command support from 17.04. - linuxefi_arm_sb_support.patch: add Secure Boot support for arm for its chainloader. - linuxefi_fix_validation_race.patch: Fix a race in validating images. - linuxefi_chainloader_path.patch: honor the starting path for grub, so images do not need to be started from $root. - linuxefi_chainloader_sb.patch: Fix some more issues in chainloader use when Secure Boot is enabled. - linuxefi_loaders_enforce_sb.patch: Enforce Secure Boot policy for all loaders: don't load the commands when Secure Boot is enabled. - linuxefi_re-enable_linux_cmd.patch: Since we rely on the linux and initrd commands to automatically hand-off to linuxefi/initrdefi; re- enable the linux loader. - linuxefi_chainloader_pe_fixes.patch: PE parsing fixes for chainloading "special" PE images, such as Windows'. - linuxefi_rework_non-sb_cases.patch: rework cases where Secure Boot is disabled or shim validation is disabled so loading works as EFI binaries when it is supposed to. - Removed linuxefi_require_shim.patch; superseded by the above. - Removed linuxefi_amd64_only.patch; superseded by the above. - Refreshed patches. * debian/rules: disable the use of -Werror while building grub; the EFI patches have subtle cases which trip it up unnecessarily. * debian/patches/arm64-set-correct-length-of-device-path-end-entry.patch: dropped; included in linuxefi_backport_arm64.patch. * debian/patches/linuxefi_fix_relocate_coff.patch: fix typo in relocate_coff() causing issues with relocation of code in chainload. (LP: #1792575) * debian/patches/linuxefi_truncate_overlong_relocs.patch: The Windows 7 bootloader has inconsistent headers; truncate to the smaller, correct size to fix chainloading Windows 7. (LP: #1792575) -- Mathieu Trudel-Lapierre Tue, 08 Jan 2019 12:36:49 -0500 ** Changed in: grub2 (Ubuntu Trusty) Status: Fix Committed => Fix Released ** Changed in: grub2-signed (Ubuntu Trusty) 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Trusty: Fix Released Status in grub2-signed source package in Trusty: Fix Released Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: Fix Released Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Released Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
This bug was fixed in the package shim-signed - 1.33.1~16.04.3 --- shim-signed (1.33.1~16.04.3) xenial; urgency=medium * debian/control: Depends: on grub2 2.02~beta2-36ubuntu3.20 to ensure shim cannot be installed without the new grub2 version that fixes chainloading issues. (LP: #1792575) shim-signed (1.33.1~16.04.2) xenial; urgency=medium * Update to the signed 15+1533136590.3beb971-0ubuntu1 binary from Microsoft. (LP: #1790724) -- Mathieu Trudel-Lapierre Tue, 11 Dec 2018 15:37:58 -0500 ** Changed in: shim-signed (Ubuntu Xenial) 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Trusty: Fix Committed Status in grub2-signed source package in Trusty: Fix Committed Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: Fix Released Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Released Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.20 --- grub2 (2.02~beta2-36ubuntu3.20) xenial; urgency=medium * debian/patches/linuxefi_fix_relocate_coff.patch: fix typo in relocate_coff() causing issues with relocation of code in chainload. (LP: #1792575) * debian/patches/linuxefi_truncate_overlong_reloc_section.patch: The Windows 7 bootloader has inconsistent headers; truncate to the smaller, correct size to fix chainloading Windows 7. (LP: #1792575) grub2 (2.02~beta2-36ubuntu3.19) xenial; urgency=medium * debian/patches/0001-i386-linux-Add-support-for-ext_lfb_base.patch: Add support for ext_lfb_base. (LP: #1785033) -- Mathieu Trudel-Lapierre Fri, 02 Nov 2018 13:08:47 -0400 ** Changed in: grub2 (Ubuntu Xenial) Status: Fix Committed => Fix Released ** Changed in: grub2-signed (Ubuntu Xenial) 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: Confirmed Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Released Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
This bug was fixed in the package grub2 - 2.02-2ubuntu8.6 --- grub2 (2.02-2ubuntu8.6) bionic; urgency=medium * debian/patches/linuxefi_fix_relocate_coff.patch: fix typo in relocate_coff() causing issues with relocation of code in chainload. (LP: #1792575) * debian/patches/linuxefi_truncate_overlong_reloc_section.patch: The Windows 7 bootloader has inconsistent headers; truncate to the smaller, correct size to fix chainloading Windows 7. (LP: #1792575) grub2 (2.02-2ubuntu8.5) bionic; urgency=medium * debian/patches/grub-reboot-warn.patch: Warn when "for the next boot only" promise cannot be kept. (LP: #788298) -- Mathieu Trudel-Lapierre Thu, 27 Sep 2018 17:00:43 +0200 ** 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Xenial: Confirmed Status in grub2-signed source package in Xenial: Confirmed Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: Confirmed Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Released Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
This bug was fixed in the package shim-signed - 1.37~18.04.2 --- shim-signed (1.37~18.04.2) bionic; urgency=medium * debian/control: add Breaks: grub-efi-amd64-signed (<< 1.93.7), as the new version of shim exercises a bug in relocation code for chainload that was fixed in that upload of grub, affecting Windows 7, Windows 10, and some netboot scenarios where chainloading is required. (LP: #1792575) shim-signed (1.37~18.04.1) bionic; urgency=medium * Backport shim-signed 1.37 to Ubuntu 18.04. (LP: #1790724) shim-signed (1.37) cosmic; urgency=medium * Update to the signed 15+1533136590.3beb971-0ubuntu1 binary from Microsoft. * debian/real-po: replace debian/po to make sure things are translatable via Launchpad. -- Mathieu Trudel-Lapierre Fri, 28 Sep 2018 11:02:56 -0400 ** Changed in: shim-signed (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: grub2-signed (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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Xenial: Confirmed Status in grub2-signed source package in Xenial: Confirmed Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: Confirmed Status in grub2 source package in Bionic: Fix Committed Status in grub2-signed source package in Bionic: Fix Released Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Released Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
Not a bug in shim, but we are adding a Breaks in shim-signed for the purposes of SRUs to avoid people upgrading into a broken state. As such, the task for cosmic in Invalid; but absolutely in progress / committed for other releases. ** Changed in: shim-signed (Ubuntu) Status: New => Invalid ** Changed in: shim-signed (Ubuntu Bionic) Status: New => 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Xenial: New Status in grub2-signed source package in Xenial: New Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: New Status in grub2 source package in Bionic: Fix Committed Status in grub2-signed source package in Bionic: Fix Committed Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Committed Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
This does not appear to be a bug in shim at all, closing the shim tasks as Invalid. ** Changed in: shim (Ubuntu) Status: New => Invalid ** Changed in: shim (Ubuntu) Assignee: Canonical Foundations Team (canonical-foundations) => (unassigned) ** Changed in: shim (Ubuntu Xenial) Status: New => Invalid ** Changed in: shim (Ubuntu Bionic) Status: New => Invalid ** Also affects: shim-signed (Ubuntu) Importance: Undecided Status: New -- 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in shim-signed package in Ubuntu: Invalid Status in grub2 source package in Xenial: New Status in grub2-signed source package in Xenial: New Status in shim source package in Xenial: Invalid Status in shim-signed source package in Xenial: New Status in grub2 source package in Bionic: Fix Committed Status in grub2-signed source package in Bionic: Fix Committed Status in shim source package in Bionic: Invalid Status in shim-signed source package in Bionic: Fix Committed Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1792575] Re: Boot failure with efi shims from 20180913.0
** Description changed: + [Impact] + Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. + + [Test cases] + 1) Deploy UEFI system using MAAS + 2) After deployment, have the system reboot to local disk (via netboot). + + [Regression potential] + It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. + + --- + We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 ** Also affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: shim (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub2 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: shim (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Bionic) Importance: Undecided Status: New -- 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/1792575 Title: Boot failure with efi shims from 20180913.0 Status in MAAS: Invalid Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim package in Ubuntu: New Status in grub2 source package in Xenial: New Status in grub2-signed source package in Xenial: New Status in shim source package in Xenial: New Status in grub2 source package in Bionic: New Status in grub2-signed source package in Bionic: New Status in shim source package in Bionic: New Bug description: [Impact] Chainloading grub via grub in a netboot context using MAAS's Boot to local disk feature. [Test cases] 1) Deploy UEFI system using MAAS 2) After deployment, have the system reboot to local disk (via netboot). [Regression potential] It is possible that the changes to chainloading logic that evaluates the sizes for various sections of code that gets copied to memory to load the next bootloader might fail to correctly evaluate the sections, or otherwise copy sections incorrectly, but this regression scenario is indistinguishable from the current case, there the system fails to load the next bootloader anyway. Error messages may vary, but the net result for a regression would be an incorrectly loaded bootloader, and thus error messages at boot from grub. --- We have had several nodes that had been deployed on Sept. 12 and were booting correctly fail to boot. On the console and during tracing we could see they were getting dhcp and pxe information, but then errored out with "relocation failed", dropping into a fallback grub menu with a Local boot option. After copying over bootx64.efi grubx64.efi from https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/ instead of 20180913.0/ and rebooting, boot would commence successfully. Hardware: Dell R640 maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
