On a Raspberrypi 4 running UC20, I’d like to modify the uboot bootdelay parameter (so it never enters the uboot shell). On UbuntuServer, I would simply enter the shell and type in
setenv bootdelay -2
saveenv
which would create an uboot.env.
However, I am struggling to get this on UC20:
I cannot enter the uboot shell (ignores my key-presses)
copying uboot.env (from a UbuntuServer) results in failure to boot
Doing a bit of digging in the pi-gadget I found that uboot.env’s been replaced with uboot/ubuntu/boot.sel, I tried generating my own boot.sel with mkenvimage (and setting bootdelay=-2) without success.
I noticed a comment about snapd taking care of installing boot.sel (which is why the gadget’s one is empty). Is there a way to inform snapd that I would like it to change the bootdelay parameter?
here is a gadget that uses bootdelay=-2 (to allow using a RAK2245 HAT that uses GPS on serial (preventing any boot in a similar way))
particulary you want to look at the snapcraft.yaml changes in that commit to re-build u-boot:
sadly it was decided to use boot.scr instead of a uboot.env binary file with UC20, so you can not easily override any early-boot config anymore like bootdelay= is one …
UC20 also does not build u-boot from upstream source anymore but uses the binary deb from the ubuntu archive so it is not easily customizable for special hardware, the patch above re-builds the deb and allows adding additional patches as needed during that build…
Most likely not, we tend to not expose gadget (i.e. bootloader) configuration like this in snap set system ... (the pi-config stuff withstanding, that was arguably something of a mistake for us to start supporting, but now we are stuck with it). Of course this is not to stop a gadget from exposing it’s own config via something like
snap set pi uboot.bootdelay=...
which then fiddles with the bootloader config via a configure hook in the pi gadget snap. That would require some new interfaces perhaps, but is more likely to happen than snapd exposing uboot config through the system config.
I can imagine the idea is to get people to make their own gadget with their needed special configs instead of supporting a general pi-gadget with user settable configurations. Indeed, I don’t imagine ever needing to change this once a product using the gadget snap is set for production.
Trying to build the linked pi-gadget-loragw gives me this:
Building noserial-uboot
+ set -x
+ sed -i 's/# deb-src/deb-src/' /etc/apt/sources.list
+ apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease
Hit:2 http://ppa.launchpad.net/snappy-dev/image/ubuntu focal InRelease
Hit:3 http://ports.ubuntu.com/ubuntu-ports focal InRelease
Hit:4 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
+ apt-get source u-boot-rpi
Reading package lists... Done
E: You must put some 'deb-src' URIs in your sources.list
Failed to run 'override-build': Exit code was 100.
Opening a shell into the lxd container, I can confirm /etc/apt/sources.list is empty. I built with
thats very weird … though i do never use --use-lxd but run snapcraft manually inside the container, i documented this here:
must be that the lxd containers that snapcraft spawns when using --use-lxd are using a smaller/more cut down image then … (the normal focal lxd image comes with deb-src lines inluded but commented in sources.list)
Alright, looks like there are two lxd container variants. I tried to get it working with the --use-lxd flag by injecting the the src url instead of uncommenting it from sources.list
+ /usr/bin/echo -e 'arm64\trpi\t\trpi_3\t\tu-boot.bin'
/bin/bash: line 50: /usr/bin/echo: No such file or directory
Failed to run 'override-build': Exit code was 127.
Which was easily remedied by removing the full path to echo (that’s not present in the lightweight container). After another error, I added bc in the build-packages since it’s used in uboot’s Makefile (and it’s not shipped in the lightweight container).
After a while of compiling, I’m greeted with
I’m now considering using the “heavyweight” lxd container to build snaps (lxc launch ubuntu:20.04 focal), as it resembles more the Ubuntu Server development environment that I’m more used to.
It feels a bit upside-down to create a full UbuntuServer 20.04 container inside UC20 as opposed to a lightweight container inside a full UbuntuServer 20.04 host. I think I can see how it makes sense though, as building the snap this way can never “contaminate” the host (UC20) and offers a familiar environment.
(fingers crossed)
EDIT: It snapped successfully. Now to make an UC20 image with it…
