Booting a Raspberry Pi

Booting a Raspberry Pi

[Wicki Gabriel (wicg)]

Hello there

I am trying to create an image that boots a Raspberry Pi 4 (64bit) directly into Guix.

I failed for quite some time due to the fact that $(guix system image my/image.scm) quietly built an EFI binary for x86_64 (my host architecture) instead of aarch64 (which is passed to the (image) definition that is returned from the my/image.scm file. Is that a bug?  It sure feels like one. Building with --system=aarch64-linux​ builds efi for aarch64.

Now I've managed to boot (through EFI) into GRUB (i follow guix/gnu/system/examples/raspberry-pi-64.tmpl) but am thrown into the GRUB shell.
Any ideas of what I might be doing wrong? I am currently building on commit c4886c0cb608e1b36969f195eb2f7ea25a37ac89.

I get the following output:

U-Boot 2023.07.02 (Jan 01 1970 - 00:00:01 +0000)
DRAM:  948 MiB (effective 1.9 GiB)
RPI 4 Model B (0xb03112)
Core:  210 devices, 17 uclasses, devicetree: board
MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus usb@7e980000: USB DWC2
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus usb@7e980000 for devices... 1 USB Device(s) found
scanning bus xhci_pci for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
[999;999H
8Card did not respond to voltage select! : -110
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
286720 bytes read in 32 ms (8.5 MiB/s)
Booting /efi\boot\bootaa64.efi
[0;30;47m
[?25hWelcome to GRUB!
[0;37;40m
[0;37;40m
[0;37;40m
[0;37;40m
[0;37;40m
[1;1H
[0;37;40m
[2;30HGNU GRUB  version 2.06
[?25h   Minimal BASH-like line editing is supported. For the first word, TAB
   lists possible command completions. Anywhere else TAB lists possible
   device or file completions.
grub>

--
Gabriel Wicki
Research Assistant

ZHAW, Zurich University of Applied Sciences
InES, Institute of Embedded Systems
High Integrity Systems Group

Technikumstrasse 22, Postfach
CH-8401 Winterthur
--
E-Mail: wicg@zhaw.ch
Web: http://ines.zhaw.ch

Booting a Raspberry Pi

[Stefan]

Hi Gabriel!

I boot my Raspberry from NFS, but it isn’t in use since some time. I experienced a problem ending in the GRUB rescue shell a year ago¹.

At that point my system switched from u-boot 2020.10 to 2022.4. Although I was net-booting, I still used a microSD card with only a bootcode.bin on it to work around known ROM code issues.

Using u-boot 2020.10, GRUB was working. Switching to u-boot 2022.4, GRUB had a similar problem:

Error: variable `root' isn't set.
Entering rescue mode...
grub rescue>

By just removing the microSD card, GRUB had no issues any more being loaded by u-boot 2022.4. I never figured out the root cause of this problem. Anyway, your problem seems to be different. There is no error message and no rescue shell. It seems that GRUB boots into its shell by intention.

Inspect the environment variables in GRUB with the ‘set’ command, to figure out why GRUB doesn’t seem to load a grub.cfg file. The variables ‘root’ and 'prefix' are of special interest.

There should be a file efi/boot/grub.cfg on your microSD card. Check its content. It should contain two lines. Either

search --file --set /gnu/store/…-grub.cfg
configfile /gnu/store/…-grub.cfg

or (actually expected)

search --fs-uuid --set …
configfile /gnu/store/…-grub.cfg

In the latter case, the UUID has to match the one of the Guix file-system on your microSD card. If this is not the case, then correct the UUID. Or change the first line containing ‘search --fs-uuid …’ with the other one containing ‘search --file …’.

The installation function uses ‘grub-probe --target=fs_uuid /gnu/store/…-grub.cfg’ to query this UUID. I could imagine that the installer gets the path to a grub configuration in the host’s store, rather than the store inside the image, leading to the wrong UUID of the host’s file-system.

Also check the presence and the content of that /gnu/store/…-grub.cfg file.

The installation function has only been tested by me with ‘guix system init’ and ‘guix system reconfigure’. I didn’t check an image creation, I think it wasn’t even possible at that time.


Bye

Stefan


¹ https://issues.guix.gnu.org/issue/48314

Re: Booting a Raspberry Pi

[Wicki Gabriel (wicg)]

Hi Stefan

and thanks for that fast and competent answer!

The problem stems from the fact that my configuration places the grub.cfg into /boot/grub/grub.cfg on the second partition (which hosts the system files) while $root is set to (hd0,msdos1) - the first partition on the SD card. I've tried a couple of combinations (an ugly hack would suffice) to make it work, but unfortunately i don't know how to tell GRUB to use the correct grub.cfg​ on the second partition, nor am i able to create a fake redirect grub.cfg​ at the currently configured location (hd0,msdos1)/efi/boot/grub/:

In procedure mkdir: Permission denied: "./tmp-root/efi/boot/grub"
________________________________
From: Stefan <stefan-guix@vodafonemail.de>
Sent: Saturday, October 28, 2023 12:01 PM
To: Wicki Gabriel (wicg) <wicg@zhaw.ch>; help-guix@gnu.org <help-guix@gnu.org>
Subject: Booting a Raspberry Pi

Hi Gabriel!

I boot my Raspberry from NFS, but it isn’t in use since some time. I experienced a problem ending in the GRUB rescue shell a year ago¹.

At that point my system switched from u-boot 2020.10 to 2022.4. Although I was net-booting, I still used a microSD card with only a bootcode.bin on it to work around known ROM code issues.

Using u-boot 2020.10, GRUB was working. Switching to u-boot 2022.4, GRUB had a similar problem:

Error: variable `root' isn't set.
Entering rescue mode...
grub rescue>

By just removing the microSD card, GRUB had no issues any more being loaded by u-boot 2022.4. I never figured out the root cause of this problem. Anyway, your problem seems to be different. There is no error message and no rescue shell. It seems that GRUB boots into its shell by intention.

Inspect the environment variables in GRUB with the ‘set’ command, to figure out why GRUB doesn’t seem to load a grub.cfg file. The variables ‘root’ and 'prefix' are of special interest.

There should be a file efi/boot/grub.cfg on your microSD card. Check its content. It should contain two lines. Either

search --file --set /gnu/store/…-grub.cfg
configfile /gnu/store/…-grub.cfg

or (actually expected)

search --fs-uuid --set …
configfile /gnu/store/…-grub.cfg

In the latter case, the UUID has to match the one of the Guix file-system on your microSD card. If this is not the case, then correct the UUID. Or change the first line containing ‘search --fs-uuid …’ with the other one containing ‘search --file …’.

The installation function uses ‘grub-probe --target=fs_uuid /gnu/store/…-grub.cfg’ to query this UUID. I could imagine that the installer gets the path to a grub configuration in the host’s store, rather than the store inside the image, leading to the wrong UUID of the host’s file-system.

Also check the presence and the content of that /gnu/store/…-grub.cfg file.

The installation function has only been tested by me with ‘guix system init’ and ‘guix system reconfigure’. I didn’t check an image creation, I think it wasn’t even possible at that time.


Bye

Stefan


¹ https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.guix.gnu.org%2Fissue%2F48314&data=05%7C01%7Cwicg%40zhaw.ch%7C338bdc7794374e57637e08dbd79ce043%7C5d1a9f9d201f4a10b983451cf65cbc1e%7C1%7C0%7C638340840999845781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=grx6x0ZNyG7DuRPIQrSjgWzPCJhweijxwQNhkGZBSyc%3D&reserved=0<https://issues.guix.gnu.org/issue/48314>