From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1iP3C6-000173-Jq for mharc-grub-devel@gnu.org; Mon, 28 Oct 2019 07:28:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45887) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iP3C1-00013S-QK for grub-devel@gnu.org; Mon, 28 Oct 2019 07:28:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iP3Bz-0007ok-Sa for grub-devel@gnu.org; Mon, 28 Oct 2019 07:28:13 -0400 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:53855) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iP3Bt-0007nN-Ue; Mon, 28 Oct 2019 07:28:06 -0400 Received: by mail-wm1-x344.google.com with SMTP id n7so9035203wmc.3; Mon, 28 Oct 2019 04:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NQALsKk30kjC3ZhUm4/my63o0EdOiR0ia8zfxIu0Bso=; b=Dk3rsNf4KuGzgYZM1tkgypSAFmuyi/pIIt0nsJWZkzsVZ/W9DUpx1a+xHSwM0sdkMH D9P5/o9giSQ9O/hoAhe2S/BWeuf4MKZLRQRIEoKgf2M1AW6sGZfaHkUDiwnRs8V3cAb7 IioK73a+i8sUVH5nQyenGBfGs+niiMfxK4Zzdpi37lFGCMRumMsC5K8o7AUuo+BeSJwK iHOrn1YVNy3m16dajAofFKHz1UHYutpkbtvgAE81Vz0tH4bk+qLvZeRgK6Rz9CAFQeFr eX5bcDWk7BmkIyl/2jLo5crQ/MWZsIsnnlFmZGJqKkdCXiBovnKMogHgXgPSDGRb1FNh IypA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NQALsKk30kjC3ZhUm4/my63o0EdOiR0ia8zfxIu0Bso=; b=CdqmJ6CtSTXq4gy00ifHt0bdgvO1NwTat27ZdorERI6UAZc0WjmGZmN1yH4Bt0bWse 3TMTvufZFG9YDwBhsE3pXMt+JIRkV7pIbG9oViGBlU2dScBrw7CKZCxHcxTgIVkdlzKx 2fJeZpq1Emnq2Eva04fIObnUgHmGT2Zu0o1dmgMqNClFhZ6zwoWFKpKeLVFpEEdM/mfI 5vvJDipR2FcMRlVXt3D4URnlMe/RH4lzekPS0sRj2zlgl+B3G8nemoRDzpGjvuwCnFe2 nYdcJfw1S/XIC2PPul+rwxgBJp9sBsvYG2a+exiFjC/yZmK5UkYXqhzRtwhbwViXhNLo mVYQ== X-Gm-Message-State: APjAAAXldNc21tjqst2ComHgQWr0W1Pg897zOhOTamswZVyYjMng17R3 LpOydtXhwaL/3hqNv7Nv4KM= X-Google-Smtp-Source: APXvYqyZH8YOcQh9qQnomGkp8SNio0gceE/OOnNmxvZ7lWYQASNv+GFb0Aw+Z+3AoI35aRmYCLmnBw== X-Received: by 2002:a1c:41c1:: with SMTP id o184mr16070358wma.81.1572262084840; Mon, 28 Oct 2019 04:28:04 -0700 (PDT) Received: from localhost (115.201.218.87.dynamic.jazztel.es. [87.218.201.115]) by smtp.gmail.com with ESMTPSA id u1sm15087290wru.90.2019.10.28.04.28.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2019 04:28:04 -0700 (PDT) Date: Mon, 28 Oct 2019 12:25:31 +0100 From: Miguel Arruga Vivas To: Daniel Kiper Cc: guix-devel@gnu.org, grub-devel@gnu.org Subject: Granularity of grub-install (was Re: Reproducibility of grub-install) Message-ID: <20191028122531.188744b3@gmail.com> In-Reply-To: <20191023090907.6sfuq6ne5mipdc5r@tomti.i.net-space.pl> References: <20191021163021.1a3ca543@gmail.com> <20191023090907.6sfuq6ne5mipdc5r@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::344 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: Mon, 28 Oct 2019 11:28:15 -0000 Hi, First of all, thank you for your comments. My answers are inline, although the bad subject was a main issue of misunderstanding. I changed it, as I think it reflects better my current idea. I'm sorry for the confusion it certainly caused. Wed, 23 Oct 2019 11:09:07 +0200 Daniel Kiper wrote: > On Mon, Oct 21, 2019 at 04:30:21PM +0200, Miguel Arruga Vivas wrote: > > Hi, everybody! > > > > After taking a deeper look into our (guix's) grub installation > > procedure, I have the thought that it could be a neat idea to make > > the boot directory an actual derivation instead something of the > > global status. > > I do not understand what you mean by "make the boot directory an > actual derivation instead something of the global status". Could you > elaborate more about that? Currently, the /boot directory is partially a system-wide directory, even though most of its contents are direct copies of the ones from grub's installation prefix: /usr/... in most distributions including BSD world, /{nix,gnu}/store/-grub-2.04 in Nix/Guix. Most of its contents don't depend at all on the actual machine and that can be shared between machine-dependent boot-sector/efi-variables "activations". These contents include all grub modules and message object files. On the other hand, the task of the platform-specific installation cannot be "shared", as it must be performed directly "on the metal". And there is a third task between these two: the generation of the raw image, that depends on the hardware configuration through the provided configuration file *and* the binary installation. > (...) > I am not sure why grub.cfg have to be reproducible. OK, to some extent > it has but... Guix doesn't generate grub.cfg through grub-mkconfig, as each kernel is also associated with the configuration for the init system too--GNU Shepherd in Guix--, and one kernel may boot up different systems, so it is generated with Guile scripts. My understanding is that grub-mkconfig is a portable tool, not only intended for this case, whose output is system dependant. I mixed up concepts here, sorry. > > > > - /boot/grub/grubenv: IIUC, this file must be writable by grub. > > This should not be on the store, and not sharing the path may be the > > main problem right now to implement this. > > I do not understand this. > > > AFAIK, the grubenv problem requires a modification of the grub code > > if we try to use a different path for this kind-of-modifiable file, > > so this would require modify grub to being able to lookup for that > > file somewhere else. This way the global state can be made > > explicit. > > What do you mean by "This way the global state can be made explicit."? Sorry again. We do not use load_env nor save_env in our configuration. I misunderstood the creation in grub-install.c as a hidden requirement for it, but I'd just had to read the manual. That global state already is explicit enough. I think now that its creation should be optional, even though it's created by default as grub-mkconfig makes use of it. Should I send a patch for it? > > The image installation into the device is a separate issue from the > > binaries installation, that could be separated into two separate > > binaries, or two steps/flags for grub-install, one for binaries > > installation into ${boot-directory}/grub and the other one for > > load.cfg generation and core/boot.img installation. > > Why do you need to separate this thing into two steps? I'd like being able to have different grub /boot-like folders, maybe through unions in the file system (as hard links) of the shared contents and the physical system dependencies, and activate them selectively without writing into them any more. This is intended for Guix's store[1], but other use cases are possible, in order to roll-back to a previous generation of the system by only writing core.img/grub.efi/etc. into platform-dependant locations. As I said before, I see them now as three steps. The middle one is already there with grub-mkimage. The bios-like installation can be performed with grub-setup, but EFI systems need grub-install to copy the image and activate it, the reason behind grub-setup deprecation if I understand the code correctly. And the copy of the correct files to the boot-directory needs no modification at all of grub-install. > > To grub-devel: I'd be able to send patches for the latter if you > > think > > Patches are always welcome... I'll send just to grub-devel following this mail a patch for a minor problem I've found reading the code. The code for an --only-platform-installation flag (the name I'm using right now) needs more work but I'll send it as soon as I have something I've tested on x86 BIOS and x86_64 EFI. From my current understanding it would replace completely grub-setup, wouldn't it? Happy hacking! Miguel [1] https://guix.gnu.org/manual/en/html_node/Features.html