Home / ubuntu / Questions / 1333512
In Process
Akeo
Asked: 2021-04-24 14:35:01 +0800 CST

error: symbol 'grub_register_command_lockdown' not found when installing Ubuntu 21.04 in BIOS mode

  • 772

This is a pre-emptive report (since I am going to post a solution below) for people facing this error when trying to install the recently released Ubuntu 21.04 in BIOS mode (UEFI mode should be fine).

When doing so, and if you happened to have created your media through Rufus (or you installed your GRUB bootloader yourself from the official GRUB 2.04 release) you may find that you get the message:

error: symbol 'grub_register_command_lockdown' not found

Press any key to continue...

and that pressing a key will return you to the GRUB selection screen.

grub2

1 Answers

  1. [Disclaimer: I am the main developer of Rufus]

    Short answer:

    • If using Rufus, you will need to download Rufus 3.14 or later to create your media, which you can download here.
    • If installing your own GRUB bootloader, you need to apply this patch on top of the GRUB 2.04 source, so that the missing symbol is defined.

    Long answer:

    This problem actually stems from two issues, and I'm afraid that, as much as I'd like to sugarcoat it, I have no choice but to be somewhat critical of projects that I'd really have expected to know a lot better, in order to avoid precisely this kind of situation.

    1. Because the GRUB project currently appears to have issues with producing releases in a timely manner, even when there are critical vulnerabilities that do warrant an urgent release (such as UEFI BootHole, which was reported close to one year ago, and which has still not resulted in a formal release), distros like Ubuntu have logically taken upon themselves to cherry pick patches from GRUB and apply them on top of the last GRUB release (version 2.04), that was put out ~2 years ago. So the first problem is that, despite people repeatedly expressing concerns, on the GRUB mailing list, that the lack of formal GRUB releases was in fact generating major problems downstream, with distros like Ubuntu having to literally apply and maintain a hundred of patches on top of the last GRUB release, instead of simply being able to update to an out of band release like GRUB 2.05-1 or GRUB 2.05-2 where BootHole or lockdown vulnerabilities would have been fixed, the GRUB project still does not appear to consider that their delayed approach to releasing anything is ultimately hurting users that depend on GRUB for booting Linux installation media.

    2. Unfortunately, rather than give their GRUB 2.04 + patches a version name such as grub-2.04-ubuntu, which would have allowed a utility like Rufus to detect that the GRUB version being used by Ubuntu 21.04 was not the vanilla unmodified 2.04 release (which, really, should only ever be the one version that can be labelled as grub-2.04), and therefore automatically download a version of GRUB that includes the lockdown fix, the Ubuntu maintainers decided to label their custom version of GRUB 2.04 + hundreds of patches as grub-2.04.

    The end result of all this is that, since some of the patches that are applied on top of GRUB are actually breaking, what Ubuntu labels as "GRUB 2.04" is actually no longer compatible with vanilla GRUB 2.04 release, which means that, when you need to convert an optical GRUB bootloader to a disk bootloader (because, while DD imaging of ISOHybrid works fine most of the time, there actually exist situations where it may be better for first time users not to use DD imaging to create their installation media), and rely on the reported GRUB version to find a matching bootloader, things can and do go wrong in spectacular fashion.

    Hopefully, the GRUB maintainers will eventually realize that not producing releases in a timely manner, especially when there are major vulnerabilities requiring urgent fixing, is actually generating issues downstream. And in the same vein, I can only hope that Ubuntu maintainers will come to realize that, if you are applying tons of patches on top of software that was released 2 years ago, and that some of those are likely to break compatibility, you probably ought to add a suffix somewhere to your versioning, so that your altered software doesn't report itself the same as the vanilla release.

    • 16