[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs.
From: |
Stefan |
Subject: |
[bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs. |
Date: |
Sun, 24 May 2020 12:18:38 +0200 |
Hi Mathieu!
> Am 23.05.2020 um 10:02 schrieb Mathieu Othacehe <address@hidden>:
>
>> It reads this information form /var/guix/profiles/system/parameters:
>> (bootloader-name grub-efi-bootloader).
>> With this again the hard-coded path “/boot/grub.cfg” is used, ignoring any
>> value overwritten in (configuration-file).
>
> Oh, we need to fix that! It means that we would need to add a
> "bootloader-configuration-file" field to <boot-parameters> record, is
> that correct?
Yes, I would guess so. But I’m not sure, if the field bootloader-name can be
dropped then from <boot-parameters>. But if, then we could probably also drop
the field name from the <bootloader> record.
>> Another issue is (install-dir (string-append mount-point "/boot")) in
>> (install-grub-efi), which ignores any (configuration-file) setting, too –
>> well, it has no access to that setting –, and implies at least “/boot” to be
>> the prefix of (bootloader (target …)).
>>
>> Beside the wish to avoid this hard-coded “/boot“ assumption, I made this a
>> function with two parameters for two more reasons.
>
> Could it be an option to infer the bootloader installation directory and
> the efi subdir from the install-grub-efi/install-grub-efi-net functions?
> If TARGET is /boot-nfs/efi/Guix", could we suppose that the
> boot-directory is "/boot-nfs" and the efi-subdir is "efi/Guix"?
For the new install-grub-efi-net I see first of all no issue in keeping it a
function. This gives the needed flexibility.
For the existing grub-efi-bootloader the assumption seems to be that there will
always be a /boot/grub.cfg. This is just not stated in the documentation. But
it gave me the impression that there is some control about it with (bootloader
(target …) …). But this is not the case. For the legacy grub-bootlouder the
(bootloader (target …) …) needs to be a device, and the /boot/grub.cfg is
implied and hard coded as well.
Actually thinking about it again, mounting the efi partition at e.g. /foo/efi,
doesn't brake anything in the first place. Then GRUB will be installed at the
target /foo/efi, basically into the efi partition it belongs. It will just read
its configuration from /boot/grub.cfg, from a different partition.
The actual difference to the new grub-efi-net-bootloader is that it has only
TFTP access to its files and its configuration file; there is only one place to
lookup both, instead of two partitions in case of the grub-efi-bootloader.
For deleting system generations the path to the always present, not
configurable /boot/grub.cfg is looked up. This works for the existing
grub-efi-bootloader and grub-bootloader. But it does not work for the
grub-efi-net-bootloader, because its configuration file does not live at
/boot/grub.cfg, as its path is now implicitly configurable via (bootloader
(target …) …). In addition for my setup I used a /boot-nfs folder instead of a
/boot folder, and saw no benefit then in keeping the /boot folder.
I think there is a second possibility. It may be possible to create a symlink
from /boot-nfs/efi/boot/grub.cfg to ../../../boot/grub.cfg. Then the assumption
that there will always be a /boot/grub.cfg file stays valid.
But personally I do not like this idea.
In <boot-parameters> it seems – but I’m not sure yet – that we only keep a
symbol name to figure out the path to the grub.cfg, although it is possible to
just put that path directly there instead. And using the symbol makes it hard
do get a configurable bootloader: A new bootloader has to be a variable, tricks
with macros come up. Also inheriting from a bootloader and overwriting the
configuration-file field – for whatever reason – is problematic: It seems to
work at the beginning, but only fails badly when removing a system generation.
It seems to have subtle bugs. It’s not usable like other parts in guix. It’s
not hackable. I’d really prefer to change this.
> The make-grub-efi-net-bootloader macro is a nice hack, but I fear that
> it makes the bootloader configuration (even more) difficult.
At least it gives me the flexibility which was missing so far. I suggest to
keep it for the moment and do a different patch once we are clear which way to
go. If we add a bootloader-configuration-file field to the <boot-parameters>
record, than the macro can be removed anyway.
Bye
Stefan
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/01
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Mathieu Othacehe, 2020/05/10
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/10
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/18
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/21
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/21
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Mathieu Othacehe, 2020/05/23
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/23
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Mathieu Othacehe, 2020/05/23
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs.,
Stefan <=
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Danny Milosavljevic, 2020/05/24
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/24
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Danny Milosavljevic, 2020/05/24
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Danny Milosavljevic, 2020/05/24
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/24
- [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs., Stefan, 2020/05/24