[PATCH] gnu: grub: Fix unicode font loading when booting over TFTP.

from a bootloader profile do not work on a tftp server when network booting.

---

gnu/bootloader/grub.scm | 15 ++++++++++++---

1 file changed, 12 insertions(+), 3 deletions(-)

Hi Stefan,

your patch file arrived mangled in my mailbox.

On Sun, 13 Dec 2020 18:25:24 +0100

Stefan <stefan-guix@vodafonemail.de> wrote:

For example, the original source file had here two spaces before the "define".

But the Patch format needs one control character in front.

In this case (for the Context mark), the control character should also be a

space.

That means there should be three spaces there. But there are two spaces there.

It goes on similarly in the entire patch file.

I've fixed it up manually and pushed to guix master--but you might want

to look into why this happens in general before something important gets

mangled.

Hi Danny and Ludo!

This patch got pushed and later reverted, as it is causing issues, because /gnu/store…-grub…/share/grub/unicode.pf2 is sometimes not visible when building the grub.cfg file.

To understand what is happening here, I modified the creation of the grub.cfg file to write the directory entries of /gnu/store visible at build time into a file.

While the /gnu/store/ on disk shows thousands of entries, when building grub.cfg there are only about 400 entries visible in my case doing a guix system reconfigure. Although the grub-efi package is referred to with a file-append gexp to build the path to the unicode.pf2 in gnu/bootloader/grub.scm, it happens that the grub package is not available in all cases in /gnu/store. The grub-efi package is gotten via (bootloader-package bootloader) and the bootloader possibly from a /run/*-system/parameters file.

I also noticed that even all the Linux kernels and initrds – except for the recent pair –, which end up being referred to from the grub.cfg, are not visible in /gnu/store while building the grub.cfg.

What makes the list of visible entries in /gnu/store when building the grub.cfg? And why might the gexp-referred grub-efi package not always be visible? This feels like a bug to me.

Bye

Stefan

Hi Stefan,

Stefan <stefan-guix@vodafonemail.de> skribis:

Yeah, I wanted to send you a heads-up and then I forgot, apologies!

In general, my suggestion when fiddling with these things is to at least

run:

make check-system TESTS=basic

This one builds and runs quickly and catches the most obvious issues, as

in this case.

Then, when fiddling with the bootloader, file systems, and that kind of

stuff, it’s a good idea to run an installation test, as in:

make check-system TESTS=installed-os

This is more expensive to build (it first has to build ‘guix’, then an

ISO image, and then run the installation), but it’s a good idea when

low-level things are modified. See:

https://guix.gnu.org/manual/en/html_node/Running-the-Test-Suite.html

I’m not sure I understand what this change meant to fix though. What

was the initial problem that led to the addition of this

‘canonicalize-path’ call?

Thanks,

Ludo’.

Hi Ludo’!

When I am booting over TFTP, the Guix related files are located somewhere on that server and therefore symlinks do not work. Let's make an example:

There is some path like /volume/systems/guix-system/. There you can find gnu/store/ and boot/.

That server serves /volume/systems/guix-system/ via NFS as the root file system for a raspberry. That server also serves /volume/systems/guix-system/boot/ as the TFTP root for booting.

Now due to the fact that I need some firmware, configuration files, U-Boot and GRUB, there is now the possibility to create a bootloader-profile, which is basically a collection of symlinks to all this.

Due to this, there is somewhere a /volume/systems/guix-system/gnu/store/…-bootloader-profile/share/grub/unicode.pf2, which is an *absolute* symlink to /gnu/store/…-grub-efi-2.04/share/grub/unicode.pf2.

The generated grub.cfg now normally refers to /gnu/store/…-bootloader-profile/share/grub/unicode.pf2.

When GRUB tries to load gnu/store/…-bootloader-profile/share/grub/unicode.pf2 via TFTP, due to a profile prepared *relative* symlink at /volume/systems/guix-system/boot/gnu/store to the real store location at ../..gnu/store/guix-system/gnu/store/ the TFTP server is able to access gnu/store/…-bootloader-profile/share/grub/unicode.pf2.

And there is the problem: That /gnu/store/…-bootloader-profile/share/grub/unicode.pf2 is an *absolute* symlink with no meaning to the TFTP server, so loading the font fails.

Simply speaking: Files for booting via TFTP must not be *absolute* symlinks.

Meanwhile I know that the font can be referred to as simply "unicode" without any path and extension, as it is installed with install-grub-efi, install-grub-efi-netboot and install-grub. I’m just still unsure about install-grub-disk-image. So hopefully the font reference can be simplified.

Nevermind. I’m sorry to have caused this trouble.

My trouble is that I only have that raspberry with only 1 GB RAM yet, and running tests on it is kind of impossible.

I tried to install Guix in a virtual machine on a NAS system during the weekend. The installation image is working, but the installed system hangs during boot. At least this was enough to find out that a simple "unicode" in grub.cfg is also sufficient for install-grub. :-)

I’m sorry that I broke Guix. I didn’t imagine that a canonicalize-path would not work, when the store path is known during build.

But this brings me back to my original question: Could you please explain why the grub package, which is referred to with a file-append gexp, is finally not visible when the grub.cfg is created?

Bye

Stefan

Hi Stefan,

Stefan <stefan-guix@vodafonemail.de> skribis:

It’s possible to create profiles that use relative symlinks:

(profile-derivation … #:relative-symlinks? #t)

or, for the declarative counterpart:

(profile (content …)

(relative-symlinks? #t))

Would that solve your problem?

BTW, I don’t see “bootloader-profile” in ‘master’; is it on a branch?

Thanks,

Ludo’.

Hi Ludo’!

Oh, that can be helpful. Thanks!

However, the unicode font is the only file referring from grub.cfg to the bootloader-profile inside the store and I’m meanwhile confident that this is not necessary at all, as the font is installed with all the other grub files in /boot/.

It’s in master in gnu/bootloader.scm, the function to use is efi-bootloader-profile. However, there’s still a patch pending.

I’m sorry for my nagging, but I’d really like to understand, why the grub package is not always visible in /gnu/store/ when building the grub.cfg file, although it is referred to by a file-append gexp.

Bye

Stefan

Refer to the installed font, not into the store.

(font-file): Removed obsolete function.

(install-grub): When populating a disk-image, install the unicode font, too.

---

gnu/bootloader/grub.scm | 26 +++++++++++---------------

1 file changed, 11 insertions(+), 15 deletions(-)

Hi!

A friendly ping. :-)

Bye

Stefan

Hi!

Another friendly ping. :-)

Bye

Stefan

Hi Stefan,

On Tue, 22 Dec 2020 16:21:40 +0100

Stefan <stefan-guix@vodafonemail.de> wrote:

I just want to say that I'm not ignoring the question--I honesty don't know.

In any case, until we do know, I've applied your patch

https://issues.guix.gnu.org/issue/45225#7 to guix master as commit

b57056a9fd83c61efb5343853948a798da6e975e--after all, the font was in /boot

for regular Guix Systems anyway, so I don't see a downside loading it from

/boot--especially since it's part of the bootloader anyway, which does not

have different generations for itself. Also, the code is simpler now.

I also want to note that all 4 hunks in that patch had failed to apply with

git am. I implore you to please download the patch files from

https://issues.guix.gnu.org/issue/45225#7using the little blue download arrow

are the top right corner and try to "git am" them yourself. It won't work

because the spaces in your patch files are mangled.

If it's that way because git send-email doesn't work, I have a block like the

following in ~/.gitconfig--and my patches arrive unmangled that way:

[sendemail]

from = Example User <user@example.com>

smtpEncryption = tls

smtpServer = xxx

smtpUser = xxx

smtpPass = xxx

smtpServerPort = 587

Then you can use

git format-patch -1 -o ../outgoing-topic1

git send-email ../outgoing-topic1/0001*

and it will work.

Hi Danny!

OK.

Many thanks! :-)

I’m sorry about this. I think that patch was older than your hint to me about troubles with spaces.

I’ll change my setup. Thanks for the hints.

Bye

Stefan