I've set up a provisioner on a bookworm install and am seeing problems with the network settings, both in the manual which is no longer up to date and after installing the provisioner, with files like /etc/dhcpcd.conf no longer being he correct ones to use.

Are there plans to upgrade the provisioner/documentation to work with bookworm?

The bcm2711-rpi-cm4s.dtb file is missing from the scriptexecute firmware. Without it, the scriptexecute firmware fails to boot on the CM4S. With it, the scriptexecute firmware boots, but does not start the provisioning process.

Regardless adding bcm2711-rpi-cm4s.dtb to the scriptexecute firmware appears to be part of the solution to get provisioning over USB to work on the CM4S.

Related discussion at https://forums.raspberrypi.com/viewtopic.php?p=2120656

Hi,
I have some problems with the Provisioning the Raspberry Pi Compute Module. The problem is right now, that I connected CM4 modules on a carrierboard via USB (alternative ETH) to a raspi4 (server) and do not see any CM4 modules via the webfrontend.

What I did so far:

• installed the Provisioning server on the raspi4 with the file cmprovision4_1.6.3_all.deb
• access to the webfrontend is succesfull
• uploading image is successfull
• check the CM4 modules on a windows PC with rpiboot and they can be detected
• contacted James Hughes several times for support (he leads me here)
• I tried to update the firmware via the webfrontend, its listed with the file pieeprom-2023-01-11.bin
• I do have access to the server via SSH

Can you please give me an advise or a teams call for checking the issue?
Happy to get a reply. Thanks in advance.
Nils

Some logs from the server with connected CM4
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file recovery8.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file recovery8-32.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file recovery7l.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file recovery7.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file recovery.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file kernel8.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file kernel8-32.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file kernel7l.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file kernel7.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Loading: /var/lib/cmprovision/scriptexecute/kernel.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: Cannot open file armstub8-32-gic.bin
Apr 05 11:48:07 raspberrypi rpiboot[402]: Loading: /var/lib/cmprovision/scriptexecute/kernel.img
Apr 05 11:48:07 raspberrypi rpiboot[402]: File read: kernel.img

Hello,
i want to use the scripts to get connected to an online server after flashing. Is this possible and is there any example i can try?
Can the script start AFTER flashing the CM4?

The timezone of the device running the provisioner is not respected. The provisioning software seems to read the time in UTC and present in the dashboard, rather than the timezone that has been set on the device.

The server is set up but in some cases, it starts all o ver again the new flasing process.

Any idea about this?

I also see this, when connecting a new CM4 to the server. Then all the process starts from the beginning.
I also can not flash 4 CM4 at one time unfortunately.

At my company's assembly location, we require shutting down and turning on the server intermittently. I was wondering if it could be possible to add a shutdown command to gracefully shutdown the server without corrupting anything through the web application.

I've been following the setup guide to install CM4 Provisioning on a Pi4 in order to flash CM4 on a custom board.

CM4 is connected via Ethernet to a (non managed) switch connected to the Pi4, as per the instructions, but the provisioning server never detects the CM4.

A project is created and an image is uploaded and ready.

In the dnsmasq log I see this:

Feb 19 10:40:20 mortrix-provisioning systemd[1]: Starting cmprovision-dnsmasq.service - cmprovision-dnsmasq...
Feb 19 10:40:20 mortrix-provisioning dnsmasq[10667]: dnsmasq: syntax check OK.
Feb 19 10:40:20 mortrix-provisioning dnsmasq[10673]: started, version 2.89 DNS disabled
Feb 19 10:40:20 mortrix-provisioning dnsmasq[10673]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Feb 19 10:40:20 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP, IP range 172.20.0.2 -- 172.20.255.255, lease time 1h
Feb 19 10:40:20 mortrix-provisioning dnsmasq-tftp[10673]: TFTP root is /var/lib/cmprovision/scriptexecute
Feb 19 10:40:20 mortrix-provisioning systemd[1]: Started cmprovision-dnsmasq.service - cmprovision-dnsmasq.
Feb 19 10:58:31 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
Feb 19 10:58:39 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
Feb 19 10:58:55 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
Feb 19 10:59:33 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
Feb 19 10:59:41 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
Feb 19 10:59:57 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
Feb 19 11:00:39 mortrix-provisioning dnsmasq-dhcp[10673]: DHCP packet received on eth0 which has no address
...

With a new entry of DHCP packet received on eth0 which has no address every time the CM4 retries PXE boot.

cat /etc/dhcpcd.conf
gives me:

interface eth0
static ip_address=172.20.0.1/16

(Instructions says "add ... to the bottom of the file", but the file was empty to begin with?)

cat /var/lib/cmprovision/etc/dnsmasq.conf
results in:

# No DNS
port=0

# tftp
enable-tftp
tftp-root=/var/lib/cmprovision/scriptexecute

# dhcp
dhcp-match=set:client_is_a_pi,97,0:52:50:69:34
dhcp-match=set:client_is_a_pi,97,0:34:69:50:52

log-dhcp
dhcp-range=172.20.0.2,172.20.255.255,255.255.0.0
pxe-service=tag:client_is_a_pi,0,"Raspberry Pi Boot"
dhcp-leasefile=/var/lib/cmprovision/etc/dnsmasq.leases
no-ping

And the CM4 keep trying to boot like this:

Any clues as to how to fix this? Did I miss something obvious?

At the end of the guide it is mentioned that the CM4 bootloader FW might be out of date. How to check this?

Using v1.6.2, provisioning doesn't proceed unless I assign a create a static IP address for the CM4 that I'm trying to provision. (for this case 172.20.0.2) I create the static IP from the Other Settings - DHCP Server Settings page. Here's a snippet of dnsmasq log before and after I assign the static IP address:

-- Journal begins at Mon 2023-02-20 20:08:04 PST, ends at Tue 2023-03-28 12:17:02 PDT. --
...
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 requested options: 66:tftp-server, 67:bootfile-name, 128, 129,
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 requested options: 130, 131, 132, 133, 134, 135
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 next server: 172.20.0.1
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 1 option: 53 message-type 2
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 54 server-identifier 172.20.0.1
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 51 lease-time 1h
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 58 T1 30m
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 59 T2 52m30s
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 1 netmask 255.255.0.0
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 28 broadcast 172.20.255.255
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 3 router 172.20.0.1
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 17 option: 97 client-machine-id 00:34:69:50:52:41:31:a0:00:01:f8:de:b9:60...
Mar 28 11:57:24 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 10 option: 43 vendor-encap 06:01:08:0a:04:00:50:58:45:ff
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 available DHCP range: 172.20.0.2 -- 172.20.255.255
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 vendor class: PXEClient:Arch:00000:UNDI:002001
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 DHCPDISCOVER(eth0) e4:5f:01:f8:de:b9
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 tags: eth0
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 DHCPOFFER(eth0) 172.20.38.21 e4:5f:01:f8:de:b9
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 requested options: 1:netmask, 3:router, 43:vendor-encap, 60:vendor-class,
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 requested options: 66:tftp-server, 67:bootfile-name, 128, 129,
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 requested options: 130, 131, 132, 133, 134, 135
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 next server: 172.20.0.1
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 1 option: 53 message-type 2
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 54 server-identifier 172.20.0.1
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 51 lease-time 1h
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 58 T1 30m
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 59 T2 52m30s
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 1 netmask 255.255.0.0
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 28 broadcast 172.20.255.255
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 4 option: 3 router 172.20.0.1
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 17 option: 97 client-machine-id 00:34:69:50:52:41:31:a0:00:01:f8:de:b9:60...
Mar 28 11:57:32 RPI-Imager dnsmasq-dhcp[509]: 1592577310 sent size: 10 option: 43 vendor-encap 06:01:08:0a:04:00:50:58:45:ff
Mar 28 11:57:40 RPI-Imager dnsmasq[509]: exiting on receipt of SIGTERM
Mar 28 11:57:40 RPI-Imager systemd[1]: Stopping cmprovision-dnsmasq...
Mar 28 11:57:40 RPI-Imager systemd[1]: cmprovision-dnsmasq.service: Succeeded.
Mar 28 11:57:40 RPI-Imager systemd[1]: Stopped cmprovision-dnsmasq.
Mar 28 11:57:40 RPI-Imager systemd[1]: cmprovision-dnsmasq.service: Consumed 11.532s CPU time.
Mar 28 11:57:40 RPI-Imager systemd[1]: Starting cmprovision-dnsmasq...
Mar 28 11:57:40 RPI-Imager dnsmasq[7895]: dnsmasq: syntax check OK.
Mar 28 11:57:40 RPI-Imager dnsmasq[7898]: started, version 2.85 DNS disabled
Mar 28 11:57:40 RPI-Imager dnsmasq[7898]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Mar 28 11:57:40 RPI-Imager dnsmasq-dhcp[7898]: DHCP, IP range 172.20.0.2 -- 172.20.255.255, lease time 1h
Mar 28 11:57:40 RPI-Imager dnsmasq-tftp[7898]: TFTP root is /var/lib/cmprovision/scriptexecute
Mar 28 11:57:40 RPI-Imager systemd[1]: Started cmprovision-dnsmasq.
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 available DHCP range: 172.20.0.2 -- 172.20.255.255
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 vendor class: PXEClient:Arch:00000:UNDI:002001
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 DHCPDISCOVER(eth0) e4:5f:01:f8:de:b9
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 tags: client_is_a_pi, known, eth0
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 DHCPOFFER(eth0) 172.20.0.2 e4:5f:01:f8:de:b9
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 requested options: 1:netmask, 3:router, 43:vendor-encap, 60:vendor-class,
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 requested options: 66:tftp-server, 67:bootfile-name, 128, 129,
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 requested options: 130, 131, 132, 133, 134, 135
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 next server: 172.20.0.1
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 1 option: 53 message-type 2
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 54 server-identifier 172.20.0.1
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 51 lease-time 1h
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 58 T1 30m
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 59 T2 52m30s
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 1 netmask 255.255.0.0
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 28 broadcast 172.20.255.255
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 3 router 172.20.0.1
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 17 option: 97 client-machine-id 00:34:69:50:52:41:31:a0:00:01:f8:de:b9:60...
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 32 option: 43 vendor-encap 06:01:03:0a:04:00:50:58:45:09:14:00:00:11...
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 available DHCP range: 172.20.0.2 -- 172.20.255.255
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 vendor class: PXEClient:Arch:00000:UNDI:002001
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 DHCPREQUEST(eth0) 172.20.0.2 e4:5f:01:f8:de:b9
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 tags: client_is_a_pi, known, eth0
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 DHCPACK(eth0) 172.20.0.2 e4:5f:01:f8:de:b9
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 next server: 172.20.0.1
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 1 option: 53 message-type 5
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 54 server-identifier 172.20.0.1
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 51 lease-time 1h
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 58 T1 30m
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 59 T2 52m30s
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 1 netmask 255.255.0.0
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 28 broadcast 172.20.255.255
Mar 28 11:57:48 RPI-Imager dnsmasq-dhcp[7898]: 1592577310 sent size: 4 option: 3 router 172.20.0.1
Mar 28 11:57:48 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/63f70360/start4.elf not found
Mar 28 11:57:48 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/63f70360/start.elf not found
Mar 28 11:57:48 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:48 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recover4.elf not found
Mar 28 11:57:48 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery.elf not found
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/start4.elf to 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/fixup4.dat to 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery.elf not found
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/dt-blob.bin not found
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery.elf not found
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:50 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:51 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/bootcfg.txt not found
Mar 28 11:57:51 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:51 RPI-Imager dnsmasq-tftp[7898]: failed sending /var/lib/cmprovision/scriptexecute/scriptexecute.img to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/scriptexecute.img to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: failed sending /var/lib/cmprovision/scriptexecute/bcm2711-rpi-cm4.dtb to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/bcm2711-rpi-cm4.dtb to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/overlays/overlay_map.dtb not found
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/config.txt to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/overlays/dwc2.dtbo to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/overlays/dwc2.dtbo to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/overlays/spi-gpio40-45.dtbo to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/overlays/spi-gpio40-45.dtbo to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/cmdline.txt to 172.20.0.2
Mar 28 11:57:52 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/cmdline.txt to 172.20.0.2
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery8.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery8-32.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery7l.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery7.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/recovery.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/kernel8.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/kernel8-32.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/kernel7l.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/kernel7.img not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: failed sending /var/lib/cmprovision/scriptexecute/kernel.img to 172.20.0.2
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: file /var/lib/cmprovision/scriptexecute/armstub8-32-gic.bin not found
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: failed sending /var/lib/cmprovision/scriptexecute/kernel.img to 172.20.0.2
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: error 0 Early terminate received from 172.20.0.2
Mar 28 11:57:53 RPI-Imager dnsmasq-tftp[7898]: failed sending /var/lib/cmprovision/scriptexecute/kernel.img to 172.20.0.2
Mar 28 11:57:55 RPI-Imager dnsmasq-tftp[7898]: sent /var/lib/cmprovision/scriptexecute/kernel.img to 172.20.0.2
Mar 28 11:58:05 RPI-Imager dnsmasq-dhcp[7898]: DHCP packet received on eth0 which has no address
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 available DHCP range: 172.20.0.2 -- 172.20.255.255
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 vendor class: udhcp 1.31.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 DHCPDISCOVER(eth0) e4:5f:01:f8:de:b9
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 tags: client_is_a_pi, known, eth0
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 DHCPOFFER(eth0) 172.20.0.2 e4:5f:01:f8:de:b9
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 requested options: 1:netmask, 3:router, 6:dns-server, 12:hostname,
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 requested options: 15:domain-name, 28:broadcast, 42:ntp-server
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 next server: 172.20.0.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 1 option: 53 message-type 2
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 54 server-identifier 172.20.0.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 51 lease-time 1h
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 58 T1 30m
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 59 T2 52m30s
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 1 netmask 255.255.0.0
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 28 broadcast 172.20.255.255
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 3 router 172.20.0.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 available DHCP range: 172.20.0.2 -- 172.20.255.255
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 vendor class: udhcp 1.31.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 DHCPREQUEST(eth0) 172.20.0.2 e4:5f:01:f8:de:b9
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 tags: client_is_a_pi, known, eth0
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 DHCPACK(eth0) 172.20.0.2 e4:5f:01:f8:de:b9
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 requested options: 1:netmask, 3:router, 6:dns-server, 12:hostname,
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 requested options: 15:domain-name, 28:broadcast, 42:ntp-server
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 next server: 172.20.0.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 1 option: 53 message-type 5
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 54 server-identifier 172.20.0.1
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 51 lease-time 1h
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 58 T1 30m
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 59 T2 52m30s
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 1 netmask 255.255.0.0
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 28 broadcast 172.20.255.255
Mar 28 11:58:08 RPI-Imager dnsmasq-dhcp[7898]: 2030322732 sent size: 4 option: 3 router 172.20.0.1

I've installed CM Provisioning, but need help to get started, I cannot see the connected CM4 devices on the web application, and don't know how to start.

23:17:52 Error during preinstall. Return code 1. Script output:

===
Running pre-installation script 'Flash EEPROM firmware (stable/pieeprom-2023-01-11.bin)'

#!/bin/sh
set -e
curl --retry 10 --silent --show-error -g -o pieeprom.bin "http://172.20.0.1/uploads/pieeprom.bin"
echo "d9cd69334b26953eb66509ae751960b51aa1103786a736d9f63eefeb2e2cffc8 pieeprom.bin" | sha256sum -c
pieeprom.bin: OK
flashrom -p "linux_spi:dev=/dev/spidev0.0,spispeed=16000" -w "pieeprom.bin"
flashrom v1.1 on Linux 5.4.83-scriptexec (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
linux_spi_init: failed to open /dev/spidev0.0: No such file or directory
Error: Programmer initialization failed.

I am currently using

#!/bin/sh
set -e
echo 'i2c-dev' >> /etc/modules

as a script in the cm4 provision tool to try and enable i2c. When I boot the CM4 the /etc/modules file does not have i2c-dev appended to it.

What am I missing?

Hi,

we have been using the CM-Provision for quite a while now and it is a great tool. Thank you for that!

We never had any problems provisioning our CM4 modules until a few weeks ago. Since the tool version we used still had the MAC-filter, we did ran into problems with a new batch of CM4. Hence, I updated our provision station to the newest version 1.6.3 (without the MAC-filter) which seemed to fixed the problem. After the update we were able to flash ~15 CM4 modules without any problems. However since about a week nearly all attempts to flash new CM4 boards are suddenly resulting in the following error:

Here a corresponding detail-page of a failing CM4:

Before we never encountered this error. In the last week 15 out of 20 CM4 boards showed it.

I already had a look through the existing issues. While issue #15 seems to talk about a similar error, the proposed solution does not fit to our problem since our image only has an uncompressed size of 4.3GB while the CM4 modules provide 32GB of storage.

We would really appreciate, if somebody could help us.

Thank you!

Created new image using rpi-imager and a lite image. Set the Wifi password, hostname, pi password and enabled ssh.

Logged in, did sudo apt update and full-upgrade

scp'd the .deb across to the device

sudo apt install file.deb

Got

N:Download is performed unsandboxed as root as file '/home/pi/cmprovision4_1.0_all.deb couldn't be accessed by user '_apt' . - pkgAcquire::Run (13: Permission denied)

Sounds like a simple access to /home/pi issue, but I've never seen such a problem before...

Gordon

We are a tad hesitant to run a production process off an SD card. Is it possible for this software to run on a CM4 with EMMC and IO board? Or is there something that specifically requires the default Pi 4?

For my project a post install reboot script would be useful. I implemented a simple one:

#!/bin/sh
set -e
reboot -f

It executes successfully and newly flashed Pi reboots, however the CM Provision webserver still reports that Pi "Provisioning complete" as "No". So it appears this reboot command prevents CM Provisioning server confirming the Pi Provisioning is done. Perhaps the Pi reboots before the script exits successfully.

Is there a trick I am missing here? I have tried using a delay to the reboot (reboot -f -d 5) but that didn't work.

Thanks

I would like the CM4 system to boot the newly-installed image immediately after provisioning is complete. I have attempted to add a postinstall script that calls the reboot command, however this does not appear to work.

Hello, hoping to get some help.

Perhaps I just haven't left it long enough, but not sure it should take more than a few hours.

Setup:

Provisioner:
Pi 4b 8GBram, 64GB micro SD with latest 64bit Raspberry Pi OS Lite (as of 31/01/2024 - yesterday)

Web interface working (over WiFi), images uploaded and projects set up.

Tried to provision / flash a CM3+ 32GB:

• connected the Slave USB on the official IO Board to the Pi 4
• powered on CM3+
• from the logs it looks like this is detected as I can see the bootloader messages you would normally see from running rpiboot on windows etc

Pi doesn't appear to be flashed with image.

Balena etcher would take around 16 minutes to flash this image, what should I expect from this?
Is there any steps for CM3+ not listed on this repo? Can't find much online.
Is there any other logs that would show anything after the bootloader stuff?

Many thanks,

Steven

I'm trying to provision a cluster of RPi 4Bs with 2022-09-22-raspios-bullseye-arm64.img.xz (downloaded directly from the rpi website), from another 4B acting as the server.

First Pi I tried to provision without updating to the latest EEPROM firmware failed. A blank/generic error message printed to the web dashboard but plugging in a display the following is visible:

Seems like the destination storage device /dev/mmcblk0 is not found.

Additionally, I tried to provision another Pi while updating to the latest EEPROM firmware. This failed with an error that actually printed to the web dashboard:

22:16:52 Error during preinstall. Return code 1. Script output:

===
Running pre-installation script 'Flash EEPROM firmware (stable/pieeprom-2023-01-11.bin)'
===
#!/bin/sh
set -e
curl --retry 10 --silent --show-error -g -o pieeprom.bin "http://172.20.0.1/uploads/pieeprom.bin"
echo "a4b5a34e264907f3eb2d7156bdfc93c9db7d7d9388f5055a0021b808b4c1960b pieeprom.bin" | sha256sum -c
pieeprom.bin: OK
flashrom -p "linux_spi:dev=/dev/spidev0.0,spispeed=16000" -w "pieeprom.bin"
flashrom v1.1 on Linux 5.4.83-scriptexec (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
linux_spi_init: failed to open /dev/spidev0.0: No such file or directory
Error: Programmer initialization failed.

Again, a missing file or directory: /dev/spidev0.0.

I assume these two instances are connected. How can I troubleshoot this as someone with minimal linux configuration experience?

I did remove the three default scripts that were populated in the dashboard by default. Are those required? I just couldn't figure out exactly what they did.

Downloading new firmware from GitHub is not working. It returns firmware updated; the newest in the list is pieeprom-2023-01-11.bin. But there are 3 newer images available:

pieeprom-2023-05-11.bin
pieeprom-2024-01-18.bin
pieeprom-2024-01-22.bin

Is there a procedure to add the new images by hand? Thanks -Mar

Hello,

We have LTE modules connected to the CM4 over USB. Is it possible to access the LTE module to get the IMEI of the module during provisioning?

Thanks

Hi,
When adding a new image the popup shows that I have 0.1 GiB available, while in fact I have more than 20 GiB.
How is the available space calculated?
And where are the images stored in the filesystem?

Thanks!

Hi,

This might be a feature request. Though i don't know if this works for RPI.
I'm using the CMprovisioner with success and provisioning works (thanks for this).

The default setting (first SD/MMC/USB etc then PXE boot) of the Pi's is kind of strange as you would need to wipe the SD card or remove the /boot/ partition to get it going again. For example the CM/RPI could detect that it can boot from SD but later in the process somehow still fails to boot due to a config error. The provisioning becomes unusable in this case as it detects dat it can boot from the SD card and to overcome this you will have to clear the SD card manually or remotely (if you still can).

You can set the RPI to first try to PXE boot and if this fails then boot from the SD card (and this works on a pi4 for example)
It would be nice if the boot process on the server would be aware if a device is already provisioned and skip PXE/netbooting when the status Provisioning complete is set to a date. This will require adjusting the PXE/netboot routine.

You would also need to be able to set the device to status provisioning complete to "no" manually for it to be provisioned again instead of always blindly copy the SD card whenever a boot request is made. Setting a RPI4 to first PXE/Netboot leaves you in a loop of always booting from the network and recopying the image to the device.

The provided scriptexecute.img appears to be an XZ compressed initrd produced by buildroot, however the source to build this has not been provided.

How does one keep track of which device is which when hooking it up with the switch. If you only hook up 1 device at at time this is easy of-course, but how does it work if you have a 16 port switch and you connect 15 devices. If a labels is printed after each successful flash you wouldn't know for which hooked up cm4 it is intended.

One possible solution I could think of is using a managed switch that has support for a MAC Address Table. You could lookup which mac address is hooked up to which port in the switch.

Interested to learn what strategies others are deploying.

(Not a feature I'm need, I'm just asking out of curiosity...)

IIRC the same usbboot works with both CM1 and CM3, so is there any specific reason why this cmprovision repo won't/can't also work for CM1? And if it does already work with CM1, it might be useful to mention that in the README.

I noticed in the guide that you set 172.20.0.1 as the IP address for the provisioner. Is there any specific reason for this?

At least with my UniFi router it was quite easy to use another IP.

Here's the configuration I did on the router:

1. Create a separate network
2. Map the provisioner device's port to this new network
3. Do the same for the CM4-to-provision port
4. Set a fixed IP for the provisioner so that it doesn't change
5. Configure DHCP TFTP server IP in settings to the provisioner's fixed IP address

Now all I needed to do on the CM4 device was to change the hardcoded IP address in /var/lib/cmprovision/scriptexecute/cmdline.txt to the provisioner's IP. Then voila, provisioning works smoothly!

To avoid hardcoding - Perhaps you could add a setting in the Webui for the provisioner server IP? Defaulted to 172.20.0.1 for backwards compatibility.

If I recognize correctly, the network boot image does not support NVMe. There is currently an exciting project https://computeblade.com/ and support for NVMe alongside eMMC would be very helpful.

Hello,
if I set the host name after writing the image via postscript, I would like to print the new host name on the label. is that possible?

Hi!
It would be amazing for our possible use case that you could re-write the OS of a device that have OS already installed. Based on my testing of the program it was not possible, please correct me if I'm wrong.

I built cmprovision from source using dpkg-buildpackage. I then compared my local deb against the 1.6.3 release and noticed that /var/lib/cmprovision/public/uploads was missing from my local deb. This causes the /images endpoint to return a 500 error (Images.php:21).

I suspect this is because the uploads directory is not included in the Git source. I solved the problem by creating a debian/dirs file and adding the directory to it, but the documentation suggests this is generally not desirable.

Should I be building the source differently, or is this a bug that a PR should be submitted for?

Is it possible to provision the CM4 over USB only rather than ethernet? The carrier board we are using in a project does not have an ethernet port but we'd still like to use the cmprovision to provision the CM4s, similarly to how the CM3's are provisioned?

Specifically I'm wondering if rpi-otp-private-key is available in a post install script.

There is a newer rev 5 version of CM4 hardware that requires RPi firmware newer than July 2021. The boot firmware in the scriptexecute folder is older than than (VC_BUILD_ID_TIME is Jan 25 2021). As such, the provisioning never starts.

I am an admitted newb. trying to set up an easy way to image 1000+ cm4 units. I can manually flash each using rpiboot and pi imager software but would love to automate this with cmprovision. The logs just get to the 'second stage boot' and then hang on the message waiting for BCM2835/6/7/2711 and thats it. Not sure what else to do. Any help much appreciated. thank you so much .

Hello,

I am wondering if cmprovision is able to update EEPROM binary after flashing raspberry pi os image.

In rpi-eeprom-update manual, it is written : "The CM4 ROM does not support running recovery.bin from the EMMC on CM4 so this service
is disabled by default. SELF_UPDATE from USB or Network boot is supported but this
must first be enabled by removing ENABLE_SELF_UPDATE=0 from the EEPROM config
via usbboot" so it seems that EEprom update can be achieved via network boot (this is what cmprovision is using right ?).

Does anyone have an idea how eeprom can be achieved along with cmprovision ? Or is there a way to execute a custom script after provisionning (to use rpiboot to flash the eeprom bin) ?

Hi,

I connected two CM4s to the server via USB and ETH using a switch. This is working. Adding two more CM4 via ETH to the switch and power the board through another power supply which is not the server, the modules does not come up. I can see this because the ETH connection does not give any light and also the CMs are not listed in the webfrontend.

Can anyone acknowledge this way of powering the modules: I have to power through the server because of a communication (rpiboot).

regards

Hi all

I am trying to provision a CM4 with a custom image and have uploaded the file as a .gz, plugged in the CM4 and recieved the following

000 (0) 100000003cc4cabe 10:59:47 Error during dd. Return code 1. Script output:
000 (0) 100000003cc4cabe 10:50:05 Preinstall script complete. Starting to write image.
000 (0) 100000003cc4cabe 10:49:57 Provisioning started. Starting preinstall scripts.

I have checked the logs in the 'other settings' tab but nothing in there. I have also looked in the CM4 infomation and have the following

===
Running pre-installation script 'Flash EEPROM firmware (stable/pieeprom-2022-04-26.bin)'

#!/bin/sh
set -e
curl --retry 10 --silent --show-error -g -o pieeprom.bin "http://172.20.0.1/uploads/pieeprom.bin"
echo "514e49703834474a9ac10317895ed1cbf72f01ee55ee8391bd659df383aa8b80 pieeprom.bin" | sha256sum -c
pieeprom.bin: OK
flashrom -p "linux_spi:dev=/dev/spidev0.0,spispeed=16000" -w "pieeprom.bin"
flashrom v1.1 on Linux 5.4.83-scriptexec (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25X40" (512 kB, SPI) on linux_spi.
Reading old flash chip contents... done.

Any ideas what went wrong? I have tried two CM4s with seperate projects but this one produced an output on the CM4 informaiton.

I am using a raspberry pi4 as the server and CM4 16gb and a dual gigabit carrier board foir the CM4

Firmware: stable/pieeprom-2022-04-26.bin

Thanks

Matt

Hello,

To flash the Raspberry Pi Compute Module 4 (CM4), we are utilizing the cmprovision tool. We have successfully flashed thousands of CM4s with this tool, without any issues.

However, we have encountered problems with flashing new batches of CM4s. Despite this, we are still able to flash older versions of the CM4 without any problems.

In these new CM4, we are stuck at the following.

Not sure, how to proceed from here.
Let me know if you need any logs.

Thank you

After creating a 1:1 image of the cmprovisoning Pi SD Card using the builtin Raspbian disk imager software tool, running the newly created SD Card results in its nginx instance failing to start due to /var/log/nginx folder missing from /var/log directory.

Creating this folder manually and restarting the nginx service will result in the cmprovison web ui running successfully.

Original SD Card from which the copy is made is not affected.

Hello everyone,

I'm encountering a problem while trying to program my CM4 (with eMMC) board via Ethernet. When I connect both Ethernet and USB cables, everything works fine. However, when I try programming solely through Ethernet, it doesn't seem to be working (with the cm4 card formatted). I suspect it might be a formatting issue causing the master to not recognize the board and initiate programming via Ethernet.

Has anyone else experienced a similar problem? I would greatly appreciate any insights or solutions you might have. Thank you in advance for your help!

Best regards,

hi,

i'm currently trying to use the provisioning software to load an image onto a new compute 4 board.
The software sees the compute 4 and starts working.
I see the following happening on the dashboard:
12:35:21 Provisioning started. starting preinstalled scripts
12:35:22 preinstall script complete. starting to write image.
12:36:20 error during dd. return code 1. script output
2403438+59826 records in
1187+1 records out
I was trying to upload the Raspios bullseye-armhf.img.xz image . It allways ends with the same error.
What's going wrong?