I've removed the dmidecode patch because it no longer cleanly applies and doesn't seem to be getting tracked upstream anymore. Needs more investigation and then potentially porting the patch to the 2.x series.
When run as a non-root user, facter would always spew "/dev/mem:
Permission denied" because it called dmidecode without redirecting
stderr.
This was filed upstream as FACT-86¹. It's unclear what is insufficient
about this method, but failing tests that are not visible aren't as much
of a concern to me as clearly useless output on every run of the
command.
¹ https://tickets.puppetlabs.com/browse/FACT-86
The previous patch caused spurious warnings from facter when the
virt-what command produced no output, as it would if run by root on a
physical host:
$ sudo facter virtual
Could not retrieve virtual: private method `gsub' called for nil:NilClass
physical
Josh Cooper from Puppet Labs caught and fixed this.
With the additional requirement of virt-what that was added in
facter-1.6.18-1, the virtual fact was incorrect when facter was not run
by root:
$ facter | egrep '^(facterversion|virtual)'
facterversion => 1.6.18
virtual => virt-what: this script must be run as root
This is upstream ticket #19989¹. It was applied to the 1.7.x branch².
¹ https://projects.puppetlabs.com/issues/19989
² https://github.com/puppetlabs/facter/commit/b7784a3
For whatever reason, the install.rb sript doesn't install the prebuilt
man page that is in the tarball when rdoc is not present. It simply
skips the man page.
Prior to 1.6.14, facter did not reliably return when a host was running
under KVM (and RHEV). The upstream fix depends on the virt-what
utility. This is a small shell script with no dependencies other than
dmidecode, which we already require.
This was also discussed in upstream issue #12879¹. No clear solution
was found, so a condrestart of puppet seems like the best band-aid for
the time being.
¹ http://projects.puppetlabs.com/issues/12879