templater.py: KeyError 'u' on cloud-final.service.tmpl
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Invalid
|
Undecided
|
Unassigned |
Bug Description
cloud-init version: 22.4
source: https:/
target platform: Rocky Linux 9, aarch64
hypervisor: Parallels 18
error output included at the bottom
--
Have successfully used this same process to build cloud-init during the packer image creation on Rocky (CentOS) 8 for x86 vbox and AMIs for a couple of years, and Rocky 7 before that. Obviously this was done on x86 hardware.
None of this might matter, but for the sake of transparency - I'm now trying to build a Rocky 9 Parallels VM on an M1 mac (so aarch64), as above, using packer. I can't compare to Rocky 8 arm because Parallels won't boot a Rocky 8 arm iso, and virtualbox won't boot much of anything on arm.
cloud-init appears to build (python3 setup.py build) fine, but is crashing during the install phase, trying to do something with a template.
> File "/tmp/packer/
> return str(selected_
I don't think I'm doing anything special. The provisioner script[1] that packer is running to build/install cloud-init is pretty simple.
As to the python error specifically, I see two references to a var named 'u' in cloud-final.
> ExecStartPost=
> out=$(systemctl show --property=SubState $u) || exit; \
> [ "$out" = "SubState=running" ] || exit 0; \
> systemctl reload-
but I'm still trying to figure out what the replacer() method is doing when it tries to return and hits the KeyError.
[1] https:/
Error output:
[root@rockylinux-9 cloud-init-22.4]# python3 setup.py install --init-
Traceback (most recent call last):
File "/tmp/packer/
main()
File "/tmp/packer/
templater.
File "/tmp/packer/
contents = (render_
File "/tmp/packer/
return renderer(content, params)
File "/tmp/packer/
return BASIC_MATCHER.
File "/tmp/packer/
return str(selected_
KeyError: 'u'
Traceback (most recent call last):
File "/tmp/packer/
"systemd": [
File "/tmp/packer/
render_tmpl(f)
File "/tmp/packer/
subprocess.run(
File "/usr/lib64/
raise CalledProcessEr
subprocess.
Have mysteriously resolved this while working on what I thought were unrelated dependency/ permissions issues in the x86 vbox version of the same box. Wish I had a better answer to provide as to why this was happening, but seems to be fixed now.