Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3873032pxj; Tue, 11 May 2021 13:59:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwj8reECT+iXN77wwUVW9lZsvpNWfN2/5v1M9x2f2xjzs9+9XdSBfwDZceeVzQtlpCz9zHZ X-Received: by 2002:a17:906:4e82:: with SMTP id v2mr34574346eju.278.1620766779748; Tue, 11 May 2021 13:59:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620766779; cv=none; d=google.com; s=arc-20160816; b=uO/gYC2M5l4+zE/i8FxVS8MNDnmic6XXhnZDbh3twsQE9TZzqZjpA3v/tG4EzEv1b6 /O0PXOL1h+0a+YgD6cFUbdnYvRlUpaOOaVXqb9dvI2UQKspMvt5MAaGz7YKRs9tvpXPm yMn1MvA75Xqi5p21B2XJd0XwbXyzBA358ip1wtu2qE64zL+ZT9bw5JKUpYIrDrzUu4TM rGBE/EieIEdnr+mGSgRWbQVYyNk6VwwD2HCm2Ji8OSGhf3iS8hwZKd6ftqi/6DYuYaGk niu3CftUv7YTWvGq+2W8A2ee5ytbhYYryV5viM0a32f4+eZ5YLDS75/R902IfDSqqce0 fW9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=wyDATmmojm1yX56kKgnfFb3YQDNmm1YO+zeUSYiICbM=; b=K+AOxKfz/u80kQt74/SUcq53YEV2jtrQX7wtyCx7HJ3pTWpsDDq4mu8z6D+lS0tXea MpK16u4i2aK0JXZSGa9UaiJJb4Mv+I31SPm5hBkXD/78hgglWUVcQlZQpXMDn53NMXl3 5Xwzij1Sw7qANzw3S0kfYK63PbXPAqHDgBDDuLxKr2/bnwqPNGVBplsjFxO3jLKxMTqR lv6RUy5hGaFiAw0+ECDH1z/vxapzKtudzKHwZkERXdMxb3HBdNgWt5BtghyikZlmEA/7 p6r/Bmj0e3DBzQjey9Inx4TsyTQPanEmwZHftEAt3YDLNuHe37ygGMEoWvqeaRssP9Ee nR9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gv37si17242264ejc.229.2021.05.11.13.59.15; Tue, 11 May 2021 13:59:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229924AbhEKU7R (ORCPT + 99 others); Tue, 11 May 2021 16:59:17 -0400 Received: from mx3.molgen.mpg.de ([141.14.17.11]:41739 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229637AbhEKU7R (ORCPT ); Tue, 11 May 2021 16:59:17 -0400 Received: from [192.168.0.7] (ip5f5aeee8.dynamic.kabel-deutschland.de [95.90.238.232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id A8CAE61E646CA; Tue, 11 May 2021 22:58:09 +0200 (CEST) Subject: Re: efivarfs fails with `No such device` when EFI runtime is missing From: Paul Menzel To: Ard Biesheuvel , Matthew Garrett , Jeremy Kerr Cc: linux-efi@vger.kernel.org, LKML References: Message-ID: <706be699-7f79-391c-bbac-a4b3820511d8@molgen.mpg.de> Date: Tue, 11 May 2021 22:58:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Use Ard’s current email, and add other maintainers] Am 11.05.21 um 22:55 schrieb Paul Menzel: > Dear Linux folks, > > > I migrated a 32-bit GNU/Linux installation from BIOS to EFI. Trying to > edit the entries in UEFI’s Boot Manager with `efibootmgr`, I got the error: > >    EFI variables are not supported on this system > > `sudo modprobe efivarfs` fails with > >    No such device > > After several tries, I found > >    [    0.000000] efi: No EFI runtime due to 32/64-bit mismatch with > kernel > > logged by Linux, and then I found the Stack Overflow thread *How could > 32bit kernel read efivars from 64bit UEFI?* [1]. > > I would have thought, setting EFI variables is just directly writing to > some storage. But probably not. > > Could the error message for the efivarfs load failure be improved, that > *device* means the runtime service (if I am not mistaken)? > > > Kind regards, > > Paul > > > [1]: https://stackoverflow.com/questions/46610442/how-could-32bit-kernel-read-efivars-from-64bit-uefi