From: Stefan <stefan-guix@vodafonemail.de>
To: Mathieu Othacehe <m.othacehe@gmail.com>
Cc: 41011@debbugs.gnu.org
Subject: [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs.
Date: Sun, 10 May 2020 23:13:20 +0200 [thread overview]
Message-ID: <1179D890-7D6C-43D8-A286-DA7A0F61D585@vodafonemail.de> (raw)
In-Reply-To: <87a72gi4kz.fsf@gmail.com>
Hi Mathieu!
Thanks for your reply again! :-)
> Am 10.05.2020 um 10:20 schrieb Mathieu Othacehe <m.othacehe@gmail.com>:
>
> This patch does not apply here. Could you rebase it on top of master?
I’ll try.
>> - ;; Intel and EFI systems need to be switched into graphics mode, whereas
>> - ;; most other modern architectures have no other mode and therefore
>> - ;; don't need to be switched.
>> -
>> - ;; XXX: Do we really need to restrict to x86 systems? We could imitate
>> - ;; what the GRUB default configuration does and decide based on whether
>> - ;; a user provided 'gfxterm' in the terminal-outputs field of their
>> - ;; bootloader-configuration record.
>> - (if (string-match "^(x86_64|i[3-6]86)-" system)
>> - (format #f "
>> + (format #f "
>> set gfxmode=~a
>> insmod all_video
>> - insmod gfxterm~%" gfxmode)
>> - "")))
>> + insmod gfxterm~%"
>> + (string-join
>> + (grub-gfxmode (bootloader-theme config))
>> + ";")))
>
> Why not enable graphic mode only if 'gfxterm' is provided in
> terminal-outputs fields, like suggested by the comment?
Good point.
Looking into this topic it seem's questionable to me that the default of (bootloader-configuration (terminal-output …)) with '(gfxterm) is grub-specific. This doesn't make sense for other boot-loaders, e.g. U-Boot. I expect this to be changed in future. ;-)
>> + (efi-bootloader-link (string-append "boot"
>> + (match arch
>> + ("i686" "ia32")
>> + ("x86_64" "x64")
>> + ("armhf" "arm")
>
> If cross-building for "arm-linux-gnueabihf", arch will be "arm" and
> won't match anything here.
Good catch!
>> + (catch 'system-error
>> + (lambda () (delete-file efi-bootloader-link))
>> + (lambda _ #f))
>
> You can use "false-if-exception" here I think.
Nice trick.
>> + (symlink #$efi-bootloader
>> + efi-bootloader-link)
>> + (catch 'system-error
>> + (lambda () (delete-file store-link))
>> + (lambda _ #f))
>
> Same here.
Sure.
>> +(define* (grub-efi-net-bootloader #:key (target #f) (efi-subdir #f))
>
> #f if implicit if omitted.
I wasn’t aware of this.
>> + (let ((target (or target "boot"))
>> + (efi-subdir (or efi-subdir "efi/boot")))
>
> It would be better to keep grub-efi-net-bootloader as a variable, like
> all other bootloaders. You could default configuration-file to
> "boot/efi/boot/grub.cfg" instead?
Actually there is a problem with all this in guix: There is (bootloader (target …)), which gives the impression that one is able to freely chose a folder for the bootloader files. However, the path “/boot/grub.cfg” is kind of hard coded.
Yes, it’s kind of possible to inherit from grub-efi-bootloader and overwrite the (configuration-file) field. In a first step this seems to work. But when e.g. deleting a system generation, in guix/scripts/system.scm (reinstall-bootloader) there is this code:
;; Use the detected bootloader with default configuration.
;; It will be enough to allow the system to boot.
(bootloader-config (bootloader-configuration
(bootloader bootloader)))
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” of is used, ignoring any value overwritten in (configuration-file).
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.
One is simply to suite my needs. The folder for my tftp server is not “boot” but “boot-nfs”. For my SBC I’m using different operating systems from time to time, e.g. LibreELEC. As I have bad experiences with unreliable micro SD cards and as an nfs root file system is nice for tinkering, I copy such operating systems onto my tftp/nfs server. This includes of corse their “boot” folder. The build-in update functionalities overwrite stuff inside there. But I need to modify stuff for network booting. To not loose these modifications during updates and for later comparisons I keep such modifications in a copy as “boot-nfs”.
The other reason is that I’m not sure, if the efi-dir for network booting should be “efi/Guix” instead of “efi/boot” in other constellations. U-Boot expects “efi/boot“ over tftp like for a removable media by default. I guess this can be changed with DNS options. Also for real UEFI firmware this might be configurable. I don’t know, so I don’t want these paths to be hard-coded.
However, digging up all this and now re-trying to delete a system generation, I get this error with my new boot-efi-net-bootloader as a function:
stefan@guix ~/development/guix$ sudo guix system delete-generations 151
/var/guix/profiles/system-151-link wird gelöscht
guix system: error: grub-efi-net-bootloader: no such bootloader
So thanks for your hint, it can’t be a function! (Not now …)
Bye
Stefan
next prev parent reply other threads:[~2020-05-10 21:13 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 20:32 [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs Stefan
2020-05-10 8:20 ` Mathieu Othacehe
2020-05-10 21:13 ` Stefan [this message]
2020-05-18 21:43 ` Stefan
2020-05-21 15:07 ` Stefan
2020-05-21 18:40 ` Stefan
2020-05-23 8:10 ` Mathieu Othacehe
2020-05-24 0:22 ` Stefan
2020-05-23 8:02 ` Mathieu Othacehe
2020-05-24 10:18 ` Stefan
2020-05-24 11:00 ` Danny Milosavljevic
2020-05-24 13:09 ` Stefan
2020-05-24 13:42 ` Danny Milosavljevic
2020-05-24 13:58 ` Danny Milosavljevic
2020-05-24 17:06 ` Stefan
2020-05-24 16:47 ` Stefan
2020-06-06 13:30 ` Stefan
2020-06-06 13:33 ` Stefan
2020-06-06 17:37 ` Danny Milosavljevic
[not found] ` <46CD97B3-9994-4AB7-AA7D-4DE39AB7A238@vodafonemail.de>
2020-06-09 13:44 ` Danny Milosavljevic
2020-06-09 14:25 ` Stefan
2020-06-11 4:21 ` Maxim Cournoyer
2020-06-11 11:36 ` Stefan
2020-06-11 13:07 ` Maxim Cournoyer
2020-06-11 13:19 ` Danny Milosavljevic
2020-06-12 14:41 ` Stefan
2020-06-14 18:56 ` Maxim Cournoyer
2020-06-11 23:43 ` [bug#41820] [PATCH] file-systems: Add record type <nfs-share> for a file system device Stefan
2020-06-20 13:52 ` Stefan
2020-06-12 0:06 ` [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs Stefan
2020-06-14 19:09 ` Maxim Cournoyer
2020-06-17 13:12 ` Stefan
2020-09-05 11:25 ` Stefan
2020-09-06 13:07 ` Stefan
2020-09-06 14:35 ` Danny Milosavljevic
2020-09-06 15:14 ` Danny Milosavljevic
2020-09-07 22:59 ` Stefan
2020-09-08 22:37 ` Danny Milosavljevic
2020-09-13 17:46 ` [bug#41011] [PATCH] gnu: grub: Support for network boot via TFTP Stefan
2020-09-14 6:59 ` Efraim Flashner
2020-09-15 20:28 ` Stefan
2020-09-16 7:51 ` Efraim Flashner
2020-09-19 17:54 ` Stefan
2020-09-20 11:47 ` Stefan
2020-09-20 11:56 ` Stefan
2020-09-26 10:52 ` Stefan
2020-09-26 10:54 ` Stefan
2020-09-26 16:13 ` Danny Milosavljevic
2020-09-27 10:50 ` Stefan
2020-09-27 10:51 ` Stefan
2020-09-27 11:47 ` Danny Milosavljevic
2020-09-14 12:34 ` Danny Milosavljevic
2020-09-15 22:10 ` Danny Milosavljevic
2020-09-27 11:57 ` bug#41011: " Stefan
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=1179D890-7D6C-43D8-A286-DA7A0F61D585@vodafonemail.de \
--to=stefan-guix@vodafonemail.de \
--cc=41011@debbugs.gnu.org \
--cc=m.othacehe@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).