b/grub.go: add support for riscv64

[dilyn-corner]

What has been done:

Given the additions to support arm64 systems booting with GRUB, analogous changes have been done to likewise support riscv64.

Note that currently, no shim binaries are produced for riscv64. So, at least for now, only the GRUB binary is used when the runtime machine is riscv64. We also don't ship a grub binary for RISC-V in the archives it seems, so folx have to build their own (a la this).

These changes include:

• modifying the grub CFG files in bootloader/assets/data (and regenerating the corresponding .go files)
• updating the grub bootloader logic in grub.go to recongize riscv64 as a valid architecture
• adding a new snippet for riscv64

I have tested these changes two different devices, the Nezha and the VisionFive2. Both appear to be working, though my testing has been very limited and I have not tested anything except core24. I can test core22 or even earlier if desired, though that will take some time (it's on my todo list).

One issue: I have to manually update systems/<date>/grubenv as the snapd_full_cmdline_args value is set to the amd64 snippet and not the riscv64 snippet at image creation, even though I have a self-built ubuntu-image which includes the snapd from this PR. I cannot determine how this snippet gets generated. The only real blocker on this is that there is no console output, but the system installs itself just fine. Console output is a Nice to Have :tm: tho :)

[dilyn-corner]

I don't have any immediate ideas on where you may be seeing the wrong environment from. Perhaps it's in the grubenv file somehow? Have you grepped files in the produced image?

snapd_full_cmdline_args is set in systems/<date>/grubenv by snapd during image build time, presumably it gets the information to put there from the snippets in bootloader/assets/grub.go. Using an ubuntu-image built against this PR's version of snapd, I can see that the value is set to:

snapd_full_cmdline_args=console=ttyS0 console=tty1 panic=-1

This looks conspicuously like snippet edition one for amd64.

If I use this image, the device(s) boot(s) just fine, albeit without any output on the serial console. This would be expected, as console has to be set to ttyS0,115200n8 earlycon in this case. If I enter normal mode instead of allowing the system to autoboot and I set the kernel commandline myself when chainloading, I likewise get console output. So I just need to identify where snapd is setting the grubenv file's content, but that has thus far eluded me.

[alfonsosanchezbeato]

Re: ubuntu-image if you recompile it changing the dependency in go.mod to this branch it should pick up the changes in theory.

[dilyn-corner]

Otherwise, the fact that we cannot have a shim make me hesitant on what we should do here. Ideally we want it so we can eventually have TPM-backed FDE, and if in the future there is a riscv shim we would need to handle both cases for this arch which would complicate maintenance.

I totally agree that the lack of shim leaves a bit of a gap between the architectures here. Because we don't support Core on RISC-V in any official capacity, it might be "fine" that we do a breaking change once a shim exists, but that's just My Opinion :tm: :)

Which are the reasons for not having a shim on riscv? Is it something that will eventually happen or it is not the case? Does upstream compile for riscv?

I don't entirely know! I imagine it's because there isn't a platform (supported by us or not, afaik) which supports SB/FDE, and so there hasn't been any real need for a shim on this platform. But this would be a question for Foundations, and I have not asked them.

Re: ubuntu-image if you recompile it changing the dependency in go.mod to this branch it should pick up the changes in theory.

Yes during my testing I was doing that and it appeared to work for everything aside from the snippet :(

[dilyn-corner]

@alfonsosanchezbeato I've updated things to reflect your comments, though I am still encountering the issue where grubenv is not correctly populated 🤔

I can confirm that I get no output unless the commandline includes console=ttyS0,115200n8 earlycon so those do have to make it in there regardless; if you're right, they should be getting in there. So either I'm doing something wrong or we're all missing something :)

I also can no longer reliably test this PR as something has changed in the initrd or EFI package generation in ubuntu-core-initramfs, as I can no longer boot core24 base systems. But that's a separate conversation!

[github-actions[bot]]

Thu Jan 30 17:02:36 UTC 2025 The following results are from: https://github.com/canonical/snapd/actions/runs/13056906688

No spread failures reported