The boot content for the Spacely will differ from that of the dev kits. The dev kits, if you stick to a single release, would all have the same boot content, but if different dev kits use different releases, then they too would have conflicting boot content.
Basically the failure is that the rootfs is not a clone of everything. This is just the operating system, and booting into the o/s does not mix well when using the wrong boot content.
To expand on this latter topic, consider that when you flash and do nothing but install a new rootfs, that you are (probably) mixing incompatible boot content. Once you use the “
-k APP” option you’ve essentially told the system to not touch anything but rootfs. Whatever the release version is (including not just release, but also if it is Spacely versus dev kit) you need the matching non-rootfs content which was designed to work with that rootfs in combination with that carrier board.
Note that if a rootfs came from a dev kit originally flashed with some release, e.g., R32.1 (just a contrived example), then the rootfs clone could be passed to any other “same model of carrier” which had also been previously flashed with R32.1 non-rootfs content. Failure would be expected for this example if you put the rootfs on a Spacely carrier, or if you restored the clone to an R32.6 system without first setting non-rootfs content to R32.1.