From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 16F501381F3 for ; Fri, 3 Jul 2020 14:52:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4D40DE0882; Fri, 3 Jul 2020 14:52:49 +0000 (UTC) Received: from smarthost03a.mail.zen.net.uk (smarthost03a.mail.zen.net.uk [212.23.1.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E1E25E083B for ; Fri, 3 Jul 2020 14:52:48 +0000 (UTC) Received: from [82.69.80.10] (helo=peak.localnet) by smarthost03a.mail.zen.net.uk with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jrN3X-0003lv-6V for gentoo-user@lists.gentoo.org; Fri, 03 Jul 2020 14:52:47 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] EFI booting problem - understanding it Date: Fri, 03 Jul 2020 15:52:46 +0100 Message-ID: <12579080.uLZWGnKmhe@peak> In-Reply-To: References: <2538456.mvXUDI8C0e@peak> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-smarthost03a-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: d5facf27-a7a5-472a-89de-18616bd1c2b2 X-Archives-Hash: 8d178d280833d800f6693cff09ecfb33 On Friday, 3 July 2020 03:05:34 BST Andrew Udvare wrote: > On 02/07/2020 06:56, Peter Humphrey wrote: > > But then, > > # bootctl set-default 30-gentoo-5.7.7.conf > > Failed to update EFI variable: Invalid argument > > Probably the kernel is blocking write access to EFI. This is on purpose > for safety as you can damage your firmware quite easily. systemd-boot > and others do not have this restriction. Is there some way for me to remove this restriction temporarily? > You also should be careful writing to the EFI too much as the NVRAM flash may > not be of high quality. Yes, I do only write to it when I have to. I hope Asus would use decent- quality components though. > https://lwn.net/Articles/674940/ Interesting - thanks. > You can try using `chattr -i` against the files like: > > chattr -i /sys/firmware/efi/efivars/Boot* > > Then you can try with bootctl and others, but this is not guaranteed to > work. Those files were already among the 17 that were mutable. It seems I need to find which of the other 117 files I need to make mutable. > On my ASUS motherboard I haven't been able to write to EFI variables > from within Linux for a long time. I have to add my keys in the BIOS and > set the default in systemd-boot. Looks like I'm in the same boat. Except that setting the default in systemd- boot is exactly what I can't do! > The logic to write to a file in efivars is here: > > https://github.com/torvalds/linux/blob/master/fs/efivarfs/file.c#L15 > > If you use strace with bootctl you'll probably see one of these errno > values. I think what I'm seeing comes from this: if (attributes & ~(EFI_VARIABLE_MASK)) return -EINVAL; Perhaps I should just stop here and revert to setting the default at the UEFI boot-choice screen. Many thanks for your help, Andrew. -- Regards, Peter.