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 D8BA2138359 for ; Fri, 3 Jul 2020 20:58:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3158E081B; Fri, 3 Jul 2020 20:58:05 +0000 (UTC) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 46446E0809 for ; Fri, 3 Jul 2020 20:58:05 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id B9D68C4E for ; Fri, 3 Jul 2020 16:58:01 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 03 Jul 2020 16:58:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aeam.us; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=bU2A+o7Qm4JzXrnmO9Ga5+TbVq4IB04 rEPjoVLQU5Sc=; b=aLeGoLffwBEhFQY7h1SLMseSVQF9r/PuUvo243SF70aKEVE r+Mz/A7M199lL9Y/hKb2k7aoh/Gputfg1kUPEsZs/t7Vc12Tp18eON8DLgdzpdiU +Eh318yvObTXT4G0kzMqheT0sigJAu272YmHLzylC7Vjtm+xgeglmDKJ0vO5PSnC UUFlcvXHyXY75uiRYxsjsuAwOwwBZo43ty4vst/hQN8Nxwax6UXBtUaHVePV1NVv R944nlU7WW8X+wwB2iVrUdYVKSh/Y21e1povUUfTfrm69YFZTd+C3SrEqwZ2iBPK /sgJ5+pJvdWQjCLBvJyt+dnLjIHgTxh7I5SB6FQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bU2A+o 7Qm4JzXrnmO9Ga5+TbVq4IB04rEPjoVLQU5Sc=; b=pKK/8y47MD/JYq0l9sMncm gIFN8YdS23jfbbn4UmGFjDZ/IaNU3suK4axKcZRPRRxItdvZcc7B2TDAWLEbjzQS 9KVmKU7SNY8hOBNa19MKf//bZIGaeCz8/oSekko0y5VsP44IPv8/DfTHyk/WdWrl arDD2pZ3IjF8vp4JjvtR2qrKPbtXiAmj9cNDtOJRw9SS5kJZ7fuqsaqILuoattwi q8gHh96hEmzSxaf5tsoetu3Zgl/3X56cpL1G/+FG/CxChayY1l04td7lMw3vKLh2 Zg3z7xMhRIG2gy3S8MzYS4pshC03Z6dukyrMo9zlLU0+grf/8dIFc47qOV0hyg3A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdeigdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfufhiugcuufhprhihfdcuoehsihgusegrvggrmhdruhhs qeenucggtffrrghtthgvrhhnpeevgfdvhfdvvdffvdevkeejffeiieeivedvkefhudeuge dttdeugeetuedtteffgfenucffohhmrghinheplhifnhdrnhgvthdpghhithhhuhgsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsh hiugesrggvrghmrdhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F2CC966007E; Fri, 3 Jul 2020 16:57:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 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 Message-Id: In-Reply-To: <12579080.uLZWGnKmhe@peak> References: <2538456.mvXUDI8C0e@peak> <12579080.uLZWGnKmhe@peak> Date: Fri, 03 Jul 2020 15:57:37 -0500 From: "Sid Spry" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] EFI booting problem - understanding it Content-Type: text/plain X-Archives-Salt: daf82e5b-280d-4311-8daf-d1cecc6ed9b4 X-Archives-Hash: 583fc77570c1684faa5eaba1b9e6d864 On Fri, Jul 3, 2020, at 9:52 AM, Peter Humphrey wrote: > 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. > They may not have a choice. The flash memory made for "embedded" applications can be very low quality. Typically I see write capability maxing out at 100k. Some devices only offer 10k due to inappropriate cost optimization. These numbers can be particularly visible if there is no wear levelling, which there usually isn't. Anything higher seems to be only available for storage applications. > > 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. > > > > >