provisioning a lite system created by pi-gen results in a root Busybox shell (similar to #81)

[T-droneops]

Found this bug while provisioning CM4 with RPi5. On RPi5: full OS installed via official Imager tool. On CM4: simple lite system generated by pi-gen (stages 0 to 2, with 3,4,5 skipped, no modification to stages). Post-generation modification of /bootfs/config.txt: enabled uart and camera. This .img works well when programmed on unsecured module via Imager.

rpi-sb-provisioner installed with dpkg, as recommended. If the RPI_DEVICE_RETRIEVE_KEYPAIR is set, provisioner log ends abruptly at "Starting Capturing device keypair to /home/taras/Documents/", but it creates only an empty .der file. Monitor.sh doesn't show the provisioned device serial neither in finished, nor in failed. If the RPI_DEVICE_RETRIEVE_KEYPAIR is not set, monitor shows successfully finished provisioning.

CM4 after provisioning boots into Bysybox. I've captured boot log via UART.

With the same .img, the result is the same every time. I have one older .img, also created with pi-gen with the same stages, and it can be provisioned successfully every time (but the keypair will not be stored), but no new pi-gen generated .img succeeds. Also I've tried with an .img obtained via dd from another CM4, and the result is the same: Busybox shell. I'm attaching these logs.

provisioner.log
system.log
uart.log

[tdewey-rpi]

Breaking this into the two major threads:

provisioner log ends abruptly at "Starting Capturing device keypair to /home/taras/Documents/", but it creates only an empty .der file.

As mentioned on the other issue, this will happen if you attempt to extract the keypair at any time other than initial provisioning. A future release will make this failure benign.

CM4 after provisioning boots into Bysybox. I've captured boot log via UART.

Thanks for the logs!

[T-droneops]

I would be happy to assist in further debugging, if you need any help. I am personally very very interested in sb-provisioner tool as we use it in production.

[tdewey-rpi]

Handing over to @roliver-rpi, who I've handed my CM4 secure-boot rig to.

[roliver-rpi]

I'm able to reproduce the abrupt exit at "Starting Capturing device keypair".

rpi-sb-provisioner.sh performs get_variable private-key. This fails when a device is being re-provisioned causing the script to exit abruptly due to lack of error handling, this can be demonstrated as follows:

pi@richard-pi5:~ $ grep -C 2 'get_variable()' /usr/local/bin/rpi-sb-provisioner.sh 
check_command_exists grep

get_variable() {
    [ -z "${DEMO_MODE_ONLY}" ] && fastboot getvar "$1" 2>&1 | grep -oP "${1}"': \K.*'
}
pi@richard-pi5:~ $ get_variable() { fastboot getvar "$1" 2>&1 | grep -oP "${1}"': \K.*' ; }
pi@richard-pi5:~ $ get_variable private-key
pi@richard-pi5:~ $ echo $?
1

Additionally, the get_variable() function seems to have an issue retrieving the public-key whereas a fastboot getvar public-key succeeds.