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
