| Puppet Version: 6.21.1
Puppet Server Version: N/A
OS Name/Version: Ubuntu 18.04 and 20.04 Executing `puppet resource service puppet enable=true` during the Ubuntu install process will incorrectly use the `debian` provider instead of the `systemd` provider, causing the command to fail. This command is commonly used in provisioning scripts to enable puppet, and having the command fail leaves puppet disabled after provisioning. Desired Behavior: The service is enabled Actual Behavior: An error occurs and the service is not enabled Here is the syslog output from the installer when it runs the command: Mar 12 03:37:23 in-target: [[1;31mError: Execution of '/usr/sbin/update-rc.d puppet defaults' returned 1: update-rc.d: error: unable to read /etc/init.d/puppet[[0m
Mar 12 03:37:23 in-target: ^[[1;31mError: /Service[puppet]/enable: change from 'false' to 'true' failed: Execution of '/usr/sbin/update-rc.d puppet defaults' returned 1: update-rc.d: error: unable to read /etc/i
nit.d/puppet^[[0m
Mar 12 03:37:23 in-target: Running in chroot, ignoring request.
Mar 12 03:37:23 in-target: service { 'puppet':
Mar 12 03:37:23 in-target: enable => 'false',
Mar 12 03:37:23 in-target: provider => 'debian',
{{Mar 12 03:37:23 in-target: }}} It looks like this was recently attempted to be fixed back in Feb: https://github.com/puppetlabs/puppet/commit/27957cf25a894cd604309857c32b2b8fe3fac9d7 Note that once the OS boots properly, the command works as intended. It is only during the installation shell that it fails. Noticed by Foreman users around March 1: https://community.theforeman.org/t/puppet-agent-disabled-after-build-process/22605 |
