From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lmTP4-0001SQ-VF for mharc-grub-devel@gnu.org; Thu, 27 May 2021 23:43:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmTP3-0001SD-NL for grub-devel@gnu.org; Thu, 27 May 2021 23:43:17 -0400 Received: from de-smtp-delivery-102.mimecast.com ([194.104.109.102]:34802) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmTP0-0003Ye-9h for grub-devel@gnu.org; Thu, 27 May 2021 23:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=mimecast20200619; t=1622173390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D2cVnj+VlhW9ARVGTCQMRXWq8roxCSyx93B3/B8Oqyw=; b=e4i/eaPsewAr73CVNpxDWK+9nycv7uGMHaJi1WWq573yzEgNR4xj54tjN//mDYQYy1jwdp sTbBuigvQfaVU4V6+xMJ1WgdLLzXNNV75AA+cBx613UOnqw4xLMJognf71aI+MFJqUiCAT zlffwlczuwMwOm0aMLDF5qmqQPk8xqs= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2053.outbound.protection.outlook.com [104.47.14.53]) (Using TLS) by relay.mimecast.com with ESMTP id de-mta-29-loxdoCd2OUSox4aX6egMFQ-1; Fri, 28 May 2021 05:43:08 +0200 X-MC-Unique: loxdoCd2OUSox4aX6egMFQ-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ccj2MbXu00YKKAuWbuxVvfmpXYV4QqR4wDGn+1N6kKM6arSYG6rRboeHYeDyMQ89wyh55X77Z2vUjIXEY1dqXjS1+PrM2JWt5vx/8D16u2EoK3YRnwR4RFFyu/wwMrQryJRBf9/jKganFC6PzREsnOInOQqC+i1VIF6SBTy/HQ92X9vpiZSDUeQ1iJmoLwBDKOsE/CgO7H67Q3l689kJAP9cS2sxtm3IUnUmrkj8ge2HUmgVm/l1nWydJhunKbezx4ikOeYa2UsPnvEvYBZqTZDeOWk72ke8Is3HLUu5PX04wW/Cb3cWg37Ih5n0zG44u/xFfHeczzQNmY+f1//qTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D2cVnj+VlhW9ARVGTCQMRXWq8roxCSyx93B3/B8Oqyw=; b=QrhN2WrsTX0M9gdQ9E7dQ0fPbOlGVhw9oYoRYB/uRyrl/Grwd8UBwMq3lgK3OaL1Yx6MXIscVy2W0R3XLe6SFoAnM6rGbRQWCbqKBl768GP3nowAXiysw5RDuVgEjXonKrqwiTqotDHC0fBh2vRdQmH45yQBzs95HnoSobs0IgT6QgGueZOT/POQd9WD3qqMEyRR+Ou6+ocW32gPav85S8MmgfIkms68c5nJCmDlfPs1tpQNdQ578TyBUKhpzSnrplrJcKjgrAXpd0coBKtx8Q0ORimbhzZntjwpQNlV3CKeLqcQDZY+gVTm//2LrQTO7vla21qflrkzHRDjXOgmbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=suse.com; Received: from DU2PR04MB8648.eurprd04.prod.outlook.com (2603:10a6:10:2df::21) by DU2PR04MB8936.eurprd04.prod.outlook.com (2603:10a6:10:2e3::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21; Fri, 28 May 2021 03:43:07 +0000 Received: from DU2PR04MB8648.eurprd04.prod.outlook.com ([fe80::ac9d:93ea:c7a:6033]) by DU2PR04MB8648.eurprd04.prod.outlook.com ([fe80::ac9d:93ea:c7a:6033%3]) with mapi id 15.20.4173.026; Fri, 28 May 2021 03:43:07 +0000 Date: Fri, 28 May 2021 11:42:58 +0800 From: Michael Chang To: Luiz Angelo Daros de Luca Cc: The development of GNU GRUB , Chris Murphy Subject: Re: RFC: A partition for grubenv, etc. Message-ID: <20210528034258.GA5871@mercury> References: <20210526091621.GB3985@mercury> <20210527085942.GA8422@mercury> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [114.36.82.44] X-ClientProxiedBy: HKAPR03CA0028.apcprd03.prod.outlook.com (2603:1096:203:c9::15) To DU2PR04MB8648.eurprd04.prod.outlook.com (2603:10a6:10:2df::21) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mercury (114.36.82.44) by HKAPR03CA0028.apcprd03.prod.outlook.com (2603:1096:203:c9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.9 via Frontend Transport; Fri, 28 May 2021 03:43:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 45423905-b354-4733-6d4a-08d9218ab4e5 X-MS-TrafficTypeDiagnostic: DU2PR04MB8936: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n+tWGdrjpT7KytAn0ijobcAqUJ8h1WD9TuTZMso5ZKrGhkjwaRPhMdsv6Uz56J5+cIqcU2BIznCT7AXhyBKf7ob+3z0J2a9jdlK44VOA+wXIPFVqZcDntep+ZEyxQIUm+Bi5fS9TQIaATEt+S6/vmRW9urPQa3Zm9kil/yupVq1zwjS+vd6I4L6tZoTtqsBTsqztSYUob9cKjWdmLS7EQFlVwx8kKD1ZCl7zUfzvDWTSEXnV9TlY7MuXiEUagq1rpICZID9skw9k/dCkK9Uyjy5zySTjIusoBhmWaeAZPUlFbVg7BZ2JgdM0jGzNQFA5r9uH9YD1jjlHRusKfjg/8l6H7x1E5eHI+pG2haEeG5fxbGcW65dvQoPGh7j6byjMbpvnyuy8UBQxnMCwm0eGTYeN3/wT0LVbO7JGWjUqVBoMFvRpbaPZBxC+6WHNCizguV1c1eIZvZB7c+4XXTHFcoQ51QVul7kAMmGMsgzF2fEc4/1i06L3KyGl2R9E8csge28vwJ45g+42BmnI0mYVeWG9qsWh4KG81OjrJCx6ElwdvCUk9FSXEoP70HAvwl+bzTRFziDkGnXN/YmF3+0DHS7Zkhwt3RgDs6IBniahNKVo4yoi/1G2aJEBMZzSsxOmpO+VvHYS0V4HHT8JSlSz/ylM0KkihFzp7MiJ9pK1p7ayL1eOp+BdED7P7er3yAkbBcBLC7UtXz7/O91zYIxBSwY1bBSOK1eg6rLeweFKWKtFf5ddJUPdYT/Uf62jqy0nz2r9wHgLgkjxRxJR5QuV74Bd5FPSxlUWqBZAIP6j/Bk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2PR04MB8648.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(396003)(376002)(366004)(9686003)(52116002)(83380400001)(86362001)(1076003)(26005)(6496006)(6666004)(316002)(55016002)(16526019)(54906003)(6916009)(8676002)(8936002)(186003)(478600001)(956004)(33716001)(66476007)(66556008)(66946007)(33656002)(5660300002)(9576002)(38350700002)(966005)(4326008)(38100700002)(2906002)(11716005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?Tjnu7x+kKbQ81VOqj6Mym6YT/9nfO4bNwiSd7cOwlWvudIxBJQUBIRLpwoyo?= =?us-ascii?Q?fdU0n0N83NC0HmAbYsbK4RobeuC9Jcwih90E9NLCjMn5reAcnFIbgfTQkYCo?= =?us-ascii?Q?mkI0+nePY8Nu2gg81r6U9aZhL+k23FdNsiblSyo0Ew4D3MksV5kEoFPZCXKv?= =?us-ascii?Q?gtQboVrL8HkjuYV6HrYXn+YKLVpujsRNwMuie1493dEQGGeKIm4ApkRNd143?= =?us-ascii?Q?09/E0naDUkSe4YdJwT6qdrzGjHcneQwfNzIpPhMbsTTsNBDPQ/eoxdq7ru68?= =?us-ascii?Q?DNv+dhy/anpPTj03iQ7/lPyYEasxXgYnvldMS3RVyDukHE5XZeFLdONp2kV0?= =?us-ascii?Q?j76Swg/fGlbsLmE6jDdGxprwypBerTF6qKKT67yVjghRXbheGLJMmUCcHyyC?= =?us-ascii?Q?HNfZMoV/yKjha+PTv15I21FWh45YX49v8/ogG1rsUqxU8T5eApgVShbNsHjW?= =?us-ascii?Q?pggeAnsM3FbHmgnlrpLVwIlHBNs5ILt9rZAZTd+9qk9qKOqYDURpFsXuSq9k?= =?us-ascii?Q?lDVcOvUxWSQzo20aw6Fjm2DmF/whRC7QPmUv4uhIW5iaag8bz+TFRXMi0BtK?= =?us-ascii?Q?+k8qCbi+dR/VyOqohbSoFNo9ebfvDkXq+utOS3GXnMjijyVDjE8hhKxUDP5s?= =?us-ascii?Q?nf8w01mheg5cnjIrTOh4jR+AGuiJpbqRYZjito5x74p6lw98luTIjJPQbiGO?= =?us-ascii?Q?QZwXnupLLpiSNl2bWywfMVYtVZugf0+4pBBCG4aRWcnJs+UE3uyRYHNL5DLk?= =?us-ascii?Q?JOCQvUY5ay9lOLYljA/FVTqh5hPiC1TcLCHouQJ2kPCS4zCWNNlSgHFORp0v?= =?us-ascii?Q?rJrUJc8ggHt84pTlhXSoALXC9EA30yARUtDaORjTCngiclf7WDqDx97rfHV/?= =?us-ascii?Q?bKhAzuYDfNEQtaKR+zRVNa2auWyMdQ58y+0Csd7phI7DCI7rcvjh0Pzi+9S+?= =?us-ascii?Q?J07bbGYWeXsSRJikiy0/FeJSH0Ys9BkhnctxWaOyNwT46l+iGB7IcTOPh1VT?= =?us-ascii?Q?GX7HxD4AsOs94hI7y140ZKbvIMh+yVg6n85FX8TPG8YJTBEDdow2FjjUIN8t?= =?us-ascii?Q?L/vgCkekNjqMwQXXXbHEmqHCmQhX1qHglV/rpVw7+Mf9LqxRUVd9SX88Srn4?= =?us-ascii?Q?0TBTapVQcbDtXN8bKVS6AWPQLphdcivhe/xie+1UDpIAy1ZLR5V8ZhZ1uorA?= =?us-ascii?Q?6r7iqC3LOb7rG6RaIVcBxYlvRaQ2jIaQZHIIAMTA6n31T9XOEBNRpZgNHd/y?= =?us-ascii?Q?Tn06LZ4bHzcCXXHe0uy4DM+ik6q8qLQLnNPiLnWUtUFucKZwamouBL2j2Vkk?= =?us-ascii?Q?DQng+n/Kerp4C1QwYAYw0/gW?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45423905-b354-4733-6d4a-08d9218ab4e5 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8648.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2021 03:43:07.5605 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IlBfHRpPcmDHMs+79AaY2CHrP7V5fe43HHPdBUiOdRNkn4ad0xFECNL6S+KT3Qyo X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR04MB8936 Received-SPF: pass client-ip=194.104.109.102; envelope-from=mchang@suse.com; helo=de-smtp-delivery-102.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 03:43:17 -0000 On Thu, May 27, 2021 at 03:49:14PM -0300, Luiz Angelo Daros de Luca wrote: > This was already discussed in this ML a couple of times. > > It is not uncommon for some FS to have an unused header space. This > happens for btrfs and SUSE patches grub2 to use it: > https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-grubenv-in-btrfs-header.patch?expand=1. > It is a "workaround", specific for a single FS that needs to be > redesigned for each FS where grub cannot write to. > Its complexity grows with each new FS. > > I think that grub should offer an alternative way to store grubenv > independently from FS in use. Grub already requires some spare space > for stage 1.5 and grub could use the remaining space after that for > grubenv. For BIOS with DOS partitions, it uses the blocks between > MBR and the first partition (sector 63 or 2048 for recent disks). For > BIOS with GPT, grub already requires a grub-bios partition (normally > way bigger than needed). And for UEFI, as it was already mentioned, > there is an EFI partition. I know I'm not considering anything > but x86 but it is where this issue happens. A new dedicated partition > might be overkill and only mostly only useful for GPT, where there > are already partitions dedicated for booting (grub bios boot or EFI). > > My proposal would be an additional source for grubenv. SUSE still uses > the FS /boot/grub2/grubenv to store a > env_block variable (as well as other variables) that, if present, will > point to where an additional grubenv should be. My proposal is quite > the same, > but not limited to BTRFS. > > grub2-mkconfig could be opportunistic, using only /boot/grub2/grubenv > when it is writable by grub, /boot/EFI when present, btrfs first > blocks or stage1.5 data when everything > else fails. Grub and userland tools would only need to check if the > "normal" grubenv does define a "$grubenv_device", "$grubenv_block" or > "$grubenv_include". > > As it was mentioned, grubenv should be grub.cfg specific, not image > specific. As /boot/grub2/grubenv is still in use, each grub.conf would > still point to a different grubenv file that would include > a different grubenv_{device,block,include}. grubenv could contain an > uuid variable to help grub2-mkconfig and grub iteratively look for a > matching grub_block or allocate a new slot. > Something like this: > > /boot/grub2/grubenv > grubenv_device=(hd0,msdos4) > grubenv_block=0 # for btrfs > grubenv_maxblock=64 # for btrfs 0x10000 (btrfs header location) / > 0x400 (grubenv size) > # grubenv_block=1234 for stage1.5 area where 1234 is the stage1.5 size in blocks > grubenv_uuid=3dfd5d2a-7314-47dc-ba5a-e02aa2b00749 > > (hd0,msdos4)@0 > grubenv_uuid=3dfd5d2a-7314-47dc-ba5a-e02aa2b00749 > next_boot=2 > > With a simple grub.cfg scriptlet (using not valid syntax): > > if [ "$grubenv_include" ]; then > # for EFI > load_env $grubenv_include > fi > if [ "$grubenv_device" ] && [ "$grubenv_block" ]; then > for n in {1..$grubenv_maxblock}; do > if [ "$grubenv_uuid" ]; then > expected_uuid=$grubenv_uuid > load_env -d $grubend_device -b $grubenv_block grubenv_uuid > if [ "$grubenv_uuid" != "$expected_uuid" ]; then > grubenv_uuid=$expected_uuid > grubenv_block++ > continue > fi > fi > # I hope it checks the header... > if ! load_env -d $grubend_device -b $grubenv_block; then > # not found or failed > grubenv_device= > grubenv_block= > fi > break > fi > ... > if [ "$grubenv_device" ] && [ "$grubenv_block" ]; then > save_env -d $grubend_device -b $grubenv_block grubenv_uuid > fi > > The problem is that the location of every single /boot/grub2/grubenv > is not deterministic. It would be hard to safely garbage-collect > unused grubenv blocks. > I think that whenever grub2-editenv writes a block, it should > rightshift the available area ($grubenv_maxblock) and add or move the > modified grubenv to position 0 > (the hottest block). Eventually all unused grubenv blocks will be > dropped during the rightshift. > > I'm not trying to solve every single corner case but I'm suggesting > changes that would empower the OS to solve the issue (requiring a > partition with writable FS for grubenv). > For most cases where grubenv is not writable today, it could > automatically solve the issue. For others where multiple complex > grub.conf/grubenv are in use, > it would give tools to the advanced user to manually solve the issue. > I'm not worried about advanced users because they can today create a > dedicated fat32 partition with > manually defined grubenv path. I'm thinking about distributions and > the general user that marginally knows what grub is. This looks good to me, and the best thing to have is that this opens the possibility to do in place upgrade and then you will have the writable grubenv. :) However I'd like to add one thing to the list. As long as this will have to deal with very sensible block areas. The tool (grub-editenv?) should be enhanced to understand the usable blocks of the filesystem or partition table in use, and therefore prohitbiting those who tries to set out any settings of writing out of bound. It is important to make sure no data corruptio will happen before usability. Thanks, Michael > > Regards, > > --- > Luiz Angelo Daros de Luca > luizluca@gmail.com >