Hi <@U2S1MUUQ7>. I've done the following (using b...
# bolt
g
Hi @vchepkov. I've done the following (using bolt 5.0.0) and this doesn't replicate the issue that you're seeing
Copy code
# initialize brand new bolt project
mkdir initializing
cd initializing
bolt project init test --modules puppetlabs-inifile

# verify that the inifile is present both in Puppetfile and bolt-project.yaml
cat Puppetfile
cat bolt-project.yaml

# run the "--force"
bolt module install --force
Sample output:
Copy code
➜  broken git:(development) bolt module install --force
Installing project modules

  → Resolving module dependencies, this might take a moment

  → Writing Puppetfile at
    /Users/gavin.didrichsen/@REFERENCES/github/app/parent/dump/testing/broken/Puppetfile

  → Syncing modules from
    /Users/gavin.didrichsen/@REFERENCES/github/app/parent/dump/testing/broken/Puppetfile
    to
    /Users/gavin.didrichsen/@REFERENCES/github/app/parent/dump/testing/broken/.modules

  → Generating type references

Successfully synced modules from /Users/gavin.didrichsen/@REFERENCES/github/app/parent/dump/testing/broken/Puppetfile to /Users/gavin.didrichsen/@REFERENCES/github/app/parent/dump/testing/broken/.modules
➜  broken git:(development)
Keep in mind that the latest version of
puppetlabs-inifile
drops support for puppet 7 and ruby 2.7. If you are still consuming any of those versions or an older bolt version, you are likely to run into incompatibility issues like these.
v
I reported before, that version crashes
and I can't install version 5 either
Copy code
"puppet-bolt-5.0.1-1-installer.pkg" can't be opened because Apple cannot check it for malicious software.
Managed to install bolt 5, it fails same way bolt4 does
Copy code
/opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:78:in `each_pair': stack level too deep (SystemStackError)
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:78:in `create_model'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:1151:in `contained_current'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:1136:in `factory_to_model'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:78:in `block in create_model'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:78:in `each_pair'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:78:in `create_model'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:1151:in `contained_current'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/model/factory.rb:1136:in `factory_to_model'
	 ... 367 levels...
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pops/evaluator/runtime3_support.rb:286:in `external_call_function'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.16.0/lib/puppet/pal/compiler.rb:30:in `call_function'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/bolt-5.0.1/lib/bolt/pal.rb:763:in `block (2 levels) in run_plan'
	from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/bolt-5.0.1/lib/bolt/fiber_executor.rb:46:in `block in create_future'
so, bolt 3 is the only viable version
g
Hi @vchepkov. The crash root:
Copy code
stack level too deep (SystemStackError)
puppet/pops/model/factory.rb: create_model, factory_to_model...
... hundreds of recursive levels ...
Bolt::PAL.run_plan → Puppet PAL → POPS Model Factory recursion
seems to indicate a recursive loop, maybe while trying to compile a plan or task. Might this be caused by an old or incompatible puppet module or plan, possibly autoloaded by bolt? Something beneath
site-modules
or
~/.puppetlabs
? Some kind of recursive data?
v
Hi. I am using this plan - https://github.com/EncoreTechnologies/puppet-patching Authors didn't publish it in forge for awhile, so I use it from github. I don't think plan does any recursion, it is not seen in the output. but it crashes every time after need for reboot is detected, never performing the reboot
bolt 3 doesn't have this issue, only 4 and later
That's the only file I have and ~/.puppetlabs
Copy code
$ cat ~/.puppetlabs/etc/bolt/bolt-defaults.yaml 
---
color: false

disable-warnings:
  - dotted_fact_name

inventory-config:
  ssh:
    host-key-check: false
    encryption-algorithms:
      - aes256-ctr
      - aes128-ctr
      - chacha20-poly1305

log:
  bolt-debug.log: disable
no site modules
$ ls .modules/ bash_task_helper inifile package pe_status_check purge_node service format node_manager patching peadm ruby_task_helper stdlib
b
can you run bolt again with
--log-evel=trace --verbose --trace
?
v
Well, I have openbolt now 🙂 so I would need to back that out and I also need a VM that needs a reboot. because otherwise plan finishes without issues
b
then try it with openbolt 😄
I guess the underlying issue is the same
v
most likely, but I do need VM requiring reboot. Next time I will create a snapshot so we can try it man y times
👍 1
Unknown argument '--log-evel=trace'
level, presumably
b
Yes :D
v
trying, fedora has glibc updates
where do you want the trace - gist?
b
In a gist.github.com maybe
👍 1
v
that's openbolt. I can repeat the same with perforce bolt, @Gavin Didrichsen
Fancy, you are using IPv6 ?
b
Of course!
v
I might enable it here one day 🙂
b
I need some time to properly read it. Olympics are still on
👍 1
v
what's interesting there, that it crashes and none of the task/plans detect a failure
b
Ha, that's what I was looking for and I thought I am blind
v
you are not 🙂
b
We need a simpler plan to reproduce this
v
yep. I will ask AI to write me plans/tasks to repeat the same stack depth
So I made chatgpt to analyze traces from both runs this is what it found failure begins at
reboot::wait
bolt 5 returns
Copy code
Task reboot::last_boot_time returned:
ActiveEnterTimestampMonotonic=
bolt 3 returns
Copy code
2026-02-22 03:14
so, bolt 3 used
who -b
, bolt 5 uses
systemctl show -p ActiveEnterTimestampMonotonic
I bet whatever that returns is no longer handled properly
since there is
TypeError: no implicit conversion of nil into Integer
there
so, I think the problem is with reboot module and not the bolt. I will try to install old reboot with new bolt and test this theory
but, bolt shouldn't crash anyway
Chatgpt could be hallucinating too :)