From: Daniel Kiper <dkiper@net-space.pl>
To: Miguel Arruga Vivas <rosen644835@gmail.com>
Cc: guix-devel@gnu.org, grub-devel@gnu.org
Subject: Re: Reproducible grub-install
Date: Wed, 23 Oct 2019 11:09:07 +0200 [thread overview]
Message-ID: <20191023090907.6sfuq6ne5mipdc5r@tomti.i.net-space.pl> (raw)
In-Reply-To: <20191021163021.1a3ca543@gmail.com>
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?
> From what I currently understand:
>
> - boot.img/core.img and load.cfg: The written images must be replaced
> on each installation. This is one task performed by grub-install.
Yep.
> - /boot/grub/*: The contents of these folders should be reproducible,
> such as the modules or the localization binaries, as currently
> grub.cfg is. This is the other task performed by grub-install.
I am not sure why grub.cfg have to be reproducible. OK, to some extent
it has but...
>
> - /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."?
> 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?
> To everyone: Are you aware of any other way to achieve this? What do
> you think?
>
> To grub-devel: I'd be able to send patches for the latter if you think
Patches are always welcome...
> it is a good idea without help, but I guess that the first kind of
> modification would need some and deeper study of grub code.
>
Yep...
Daniel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
next prev parent reply other threads:[~2019-10-23 9:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 14:30 Reproducible grub-install Miguel Arruga Vivas
2019-10-23 9:09 ` Daniel Kiper [this message]
2019-10-28 11:25 ` Granularity of grub-install (was Re: Reproducibility of grub-install) Miguel Arruga Vivas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191023090907.6sfuq6ne5mipdc5r@tomti.i.net-space.pl \
--to=dkiper@net-space.pl \
--cc=grub-devel@gnu.org \
--cc=guix-devel@gnu.org \
--cc=rosen644835@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).