Bug#983475: shim-signed-common: failure to install w/o SetVariable()

[Frieder Schrempf]

Hi,

Am 30.04.21 um 20:16 schrieb Heinrich Schuchardt:
> Am 30. April 2021 20:06:22 MESZ schrieb Steve McIntyre <steve at einval.com>:
>> Control: reassign -1 grub2-common
>>
>> Hi Heinrich,
>>
>> [ reassigning to grub2-common, the package which includes grub-install
>> ]
>>
>> On Wed, Feb 24, 2021 at 09:08:15PM +0100, Heinrich Schuchardt wrote:
>>> Package: shim-signed-common
>>> Version: 1.33+15+1533136590.3beb971-7
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> on systems using U-Boot as firmware the UEFI runtime service
>>> SetVariable() is not available. Variable Boot0000 has to be set
>> manually
>> >from the U-Boot console.
>>>
>>> The installation of shim-signed-common fails with:
>>>
>>> The following NEW packages will be installed:
>>>  shim-signed-common
>>> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
>>> Need to get 0 B/13.3 kB of archives.
>>> After this operation, 50.2 kB of additional disk space will be used.
>>> Preconfiguring packages ...
>>> Can't exec "/tmp/shim-signed-common.config.PoZZwF": Permission denied
>> at
>>> /usr/lib/aarch64-linux-gnu/perl-base/IPC/Open3.pm line 178.
>>> open2: exec of /tmp/shim-signed-common.config.PoZZwF configure 
>> failed:
>>> Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
>>> Selecting previously unselected package shim-signed-common.
>>> (Reading database ... 149437 files and directories currently
>> installed.)
>>> Preparing to unpack
>>> .../shim-signed-common_1.33+15+1533136590.3beb971-7_all.deb ...
>>> Unpacking shim-signed-common (1.33+15+1533136590.3beb971-7) ...
>>> Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ...
>>> Installing for arm64-efi platform.
>>> grub-install: warning: Cannot set EFI variable Boot0000.
>>> grub-install: warning: efivarfs_set_variable: failed to create
>>> /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
>>> for writing: Read-only file system.
>>> grub-install: warning: _efi_set_variable_mode: ops->set_variable()
>>> failed: Read-only file system.
>>> grub-install: error: failed to register the EFI boot entry: Read-only
>>> file system.
>>> dpkg: error processing package shim-signed-common (--configure):
>>> installed shim-signed-common package post-installation script
>>> subprocess returned error exit status 1
>>> Errors were encountered while processing:
>>> shim-signed-common
>>>
>>> To make the package usable with U-Boot the installation should not
>> fail
>>> but complete with a warning.
>>
>> Apologies for not responding earlier...
>>
>> This is a complicated situation, and there is no single right answer
>> at the moment. On platforms where EFI variables are settable
>> (e.g. most x86 machines, arm64 server machines), we absolutely *must*
>> report failure to install boot variables - this will make the system
>> fail to boot after installation. But on other platforms (e.g. most
>> current U-Boot systems), we can't install variables and instead we'll
>> have to install to the removable media path. AFAIK the U-Boot
>> developers are trying to add support for setting EFI variables on many
>> of their platforms, so hopefully this problem will go away soon.
> 
> This will require OP-TEE and StandAloneMM. The problem will persist on most boards
> 
>>
>> In the meantime, to do a better job we need a reliable way to detect
>> if the platform can't support writing of EFI variables. Suggestions
>> welcome. :-/
> 
> SetVariable() must return EFI_UNSUPPORTED in this case. With UEFI 2.8+ you could also look at the EFI_RT_PROPERTIES_TABLE configuration table to identify unsupported runtime services. But Linux will only provide access to the table with CONFIG_EFI_TEST=y.
> 

Are there any news to this issue?

I stumbled upon this while trying to install Debian on an ARM64 device
(using U-Boot without OP-TEE) and the installer fails with the error above.

I also discovered, that installing Ubuntu on the same device works just
fine and doesn't show any issue like this.

It would be really great if we could solve this to allow Debian being
used on a whole lot of devices that seem to be affected by this.

Thanks for any help!
Frieder