[master] Grub2 Failed to install "efibootmgr failed to register the boot entry: Block device required. / Could not delete variable: Invalid argument"

Status changed to 'Confirmed' because the bug affects multiple users.

Bug #1800363 for example claims it happened during a bionic to cosmic upgrade

I'm unable to reproduce this. I've tried upgrading from bionic to cosmic, or various partitioning set ups. Clearly there is something special about some set up that can cause this kind of issue, but I'm unsure what it could be.

Could you please tell us more about how your system was installed that could help reproducing the bug?

 - Is it upgraded from previous releases before the bionic -> cosmic upgrade?
 - Is there a special partitioning done?
 - Is "CSM" enabled in the BIOS with the UEFI mode?
 - Is there anything else you can say about the affected systems that could help us reproduce the issue?

Some more questions:

 - Is "Boot Order Lock" enabled on the affected system? (This is another feature in BIOS/firmware).
 - Please include the output of 'sudo efibootmgr -v'

I have been using a workaround submitted by Ronan Mooney, listed as #11
on https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518

The workaround has enabled me to complete upgrades.

On 2/12/19 10:09 PM, Mathieu Trudel-Lapierre wrote:
> I'm unable to reproduce this. I've tried upgrading from bionic to
> cosmic, or various partitioning set ups. Clearly there is something
> special about some set up that can cause this kind of issue, but I'm
> unsure what it could be.
>
> Could you please tell us more about how your system was installed that
> could help reproducing the bug?
>
> - Is it upgraded from previous releases before the bionic -> cosmic upgrade?
> - Is there a special partitioning done?
> - Is "CSM" enabled in the BIOS with the UEFI mode?
> - Is there anything else you can say about the affected systems that could help us reproduce the issue?
>

The output is attached.

On 2/12/19 10:14 PM, Mathieu Trudel-Lapierre wrote:
> sudo efibootmgr -v

Alright; I think I've finally made some progress on this.

Turns out "Block device required" is really a red herring. It's some random value (15) used in efibootmgr code, for any number of causes for failure. We can't read anything into it.

The real error in indeed "Invalid argument", and very much at the point where things are trying to delete the variable. It's either at deleting the variable itself, or updating BootOrder.

Could you please run the following command, so as to give us more information to address this issue?

sudo strace -ff efibootmgr -b 0000 -B

Could you also run:

ls -l /sys/firmware/efi/efivars/

This will give us more information to hopefully fix this issue.

It seems like you're also seeing this on a Dell XPS 13 (9343), seemingly with BIOS revision A15. Judging from https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518/comments/32; there's a BIOS A18 available from Dell that might address the issue. Now, I'm not absolutely certain that the new *revision* fixes the issue, but updating the firmware might clear things that would fix this. That's partly why we need the extra information (so please run the commands above before updating BIOS).

In addition to the above; if anyone has previously had Ubuntu 17.10 installed on the affected system, it is possible this is due to bug 1734147. Please see if the bug's description matched with what you are seeing. If you're unsure, ask here for help.

See attached file with output from both commands.

On Wed, Apr 17, 2019 at 3:50 PM Mathieu Trudel-Lapierre
<email address hidden> wrote:
>
> Alright; I think I've finally made some progress on this.
>
> Turns out "Block device required" is really a red herring. It's some
> random value (15) used in efibootmgr code, for any number of causes for
> failure. We can't read anything into it.
>
> The real error in indeed "Invalid argument", and very much at the point
> where things are trying to delete the variable. It's either at deleting
> the variable itself, or updating BootOrder.
>
> Could you please run the following command, so as to give us more
> information to address this issue?
>
> sudo strace -ff efibootmgr -b 0000 -B
>
> Could you also run:
>
> ls -l /sys/firmware/efi/efivars/
>
> This will give us more information to hopefully fix this issue.
>
> It seems like you're also seeing this on a Dell XPS 13 (9343), seemingly
> with BIOS revision A15. Judging from
> https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518/comments/32;
> there's a BIOS A18 available from Dell that might address the issue.
> Now, I'm not absolutely certain that the new *revision* fixes the issue,
> but updating the firmware might clear things that would fix this. That's
> partly why we need the extra information (so please run the commands
> above before updating BIOS).
>
> ** Package changed: grub2-signed (Ubuntu Disco) => efibootmgr (Ubuntu
> Disco)
>
> ** Changed in: efibootmgr (Ubuntu Disco)
> Status: Triaged => Incomplete
>
> ** Summary changed:
>
> - Grub2 Failed to install "efibootmgr failed to register the boot entry: Block device required."
> + [master] Grub2 Failed to install "efibootmgr failed to register the boot entry: Block device required."
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1801575).
> https://bugs.launchpad.net/bugs/1805490
>
> Title:
> [master] Grub2 Failed to install "efibootmgr failed to register the
> boot entry: Block device required."
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1805490/+subscriptions

I looked at 1734147 but it didn't seem familiar. (That's not saying much though, as I've not really paid close attention other than to note that I'm affected by the grub issues.)

Ugh. Looks like the email attachment didn't survive the trip...

root@laptop:/sys/firmware/efi/efivars# strace -ff efibootmgr -b 0000 -B
execve("/bin/efibootmgr", ["efibootmgr", "-b", "0000", "-B"], 0x7fff3ef3c210 /* 25 vars */) = 0
brk(NULL) = 0x55e921747000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99288, ...}) = 0
mmap(NULL, 99288, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1d82acc000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libefivar.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0203\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=138312, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d82aca000
mmap(NULL, 141136, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d82aa7000
mmap(0x7f1d82aaa000, 69632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f1d82aaa000
mmap(0x7f1d82abb000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f1d82abb000
mmap(0x7f1d82abf000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f1d82abf000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libefiboot.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P$\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=55216, ...}) = 0
mmap(NULL, 57376, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d82a98000
mmap(0x7f1d82a9a000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f1d82a9a000
mmap(0x7f1d82aa2000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f1d82aa2000
mmap(0x7f1d82aa5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f1d82aa5000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260A\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1996592, ...}) = 0
mmap(NULL, 2004992, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d828ae000
mprotect(0x7f1d828d0000, 1826816, PROT_NONE) = 0
mmap(0x7f1d828d0000, 1511424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f1d828d0000
mmap(0x7f1d82a41000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x193000) = 0x7f1d82a41000
mmap(0x7f1d82a8e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1df000) = 0x7f1d82a8e000
mmap(0x7f1d82a94000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1d82a94000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK...

Thanks, I think we have all the information we need right now; this needs further investigation by a developer.

Ubuntu 19.04 reached end of life on January 23, 2020. I am therefore marking this bug 'wontfix' for that release.