From: Miguel Arruga Vivas <rosen644835@gmail.com>
To: guix-devel@gnu.org
Cc: grub-devel@gnu.org
Subject: Reproducible grub-install
Date: Mon, 21 Oct 2019 16:30:21 +0200 [thread overview]
Message-ID: <20191021163021.1a3ca543@gmail.com> (raw)
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.
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.
- /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.
- /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.
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.
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.
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
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.
To guix-devel: Even though the procedure I have in mind needs
changes in grub, there are alternative ways to achieve this with the
current tools, as copying the files and using the installation as an
"implicit" guix-challenge, but they are not as neat an clean as the
split between reproducible binaries installation and global state,
which includes the disk preparation for the load of the bootloader.
Happy hacking to all!
Miguel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
next reply other threads:[~2019-10-21 14:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 14:30 Miguel Arruga Vivas [this message]
2019-10-23 9:09 ` Reproducible grub-install Daniel Kiper
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=20191021163021.1a3ca543@gmail.com \
--to=rosen644835@gmail.com \
--cc=grub-devel@gnu.org \
--cc=guix-devel@gnu.org \
/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).