[Puppet Users] Having trouble with facter - "invalid argument"

can you please provide the output of

     facter -v

(this should return the version you are using) and

     facter --debug --trace virtual

When running the last command, you'll hopefully see a strack trace
so we can see where the error actually happens.

-Stefan

I did discover that Puppet appears to be running just fine. I think the
problem may be isolated to facter and puppet appears to forgive the
problem. 8-)

Here's the output you requested. (I don't see a trace.)

[[email protected] log]# facter -v

Ok can you then please run `facter --debug --timing virtual`. This
should give you something like

     % facter --debug --timing virtual
     kernel: 2.94ms
     virtual: 0.06ms
     virtual: 0.44ms
     lsbdistid: 20.66ms
     operatingsystem: 22.72ms
     hardwaremodel: 2.37ms
     architecture: 30.14ms
     virtual: 57.26ms
     physical

So the `--timing` option has the neat benefit that we see what other
facts facter has to resolve to get to the `virtual` fact. If you
could provide the values for these facts as well I should be able to
follow the actual code path and see where facter may have problems.

-Stefan

[[email protected] ~]# facter --debug --timing virtual
kernel: 2.97ms
Could not retrieve virtual: Invalid argument -
/sys/firmware/dmi/entries/1-0/raw
virtual: 50.26ms
lsbdistid: 0.53ms
value for lsbdistid is still nil
operatingsystem: 2.00ms
hardwaremodel: 3.36ms
architecture: 10.61ms
virtual: 34.97ms
physical


Charlie

Still not sure what is going on here. I guess the "Invalid argument"
is the output of an external command that is failing. So if you
could make the following modification in `util/resolution.rb` (the
exact path may be different on your machine, on mine it
is
`/usr/lib/ruby/gems/1.9.1/gems/facter-1.7.0/lib/facter/util/resolution.rb`)

goto line 171 and change


     begin
       out = %x{#{code}}.chomp
       [...]

to

     begin
       Facter.debug "about to execute #{code}"
       out = %x{#{code}}.chomp
       [...]

if you now run `facter --debug virtual` you should see the exact
external commands facter is executing. This migh be helpful when
finding the root cause of your problem here.

-Stefan

Hi all,

I am seeing the same error recently and here's the output after the last
modification:

facter --debug --trace virtual
about to execute /bin/uname -s
Could not retrieve virtual: Invalid argument -
/sys/firmware/dmi/entries/1-0/raw
about to execute /sbin/virt-what 2>/dev/null
value for lsbdistid is still nil
about to execute /bin/uname -m
about to execute /sbin/lspci 2>/dev/null
physical

facter --debug --timing virtual
about to execute /bin/uname -s
kernel: 2.50ms
Could not retrieve virtual: Invalid argument -
/sys/firmware/dmi/entries/1-0/raw
about to execute /sbin/virt-what 2>/dev/null
virtual: 32.02ms
lsbdistid: 0.23ms
value for lsbdistid is still nil
operatingsystem: 0.85ms
about to execute /bin/uname -m
hardwaremodel: 2.33ms
architecture: 5.50ms
about to execute /sbin/lspci 2>/dev/null
virtual: 25.62ms
physical

Hopefully this helps 'cause I can't figure it out.

Thank you for your help.

I just want to provide some more information on this one. Recently it
started to show the following output when doing puppet runs:
puppet agent --test
/usr/share/rubygems/rubygems/custom_require.rb:36:in `require': iconv will
be deprecated in the future, use String#encode instead.
notice: Ignoring --listen on onetime run
info: Retrieving plugin
info: Loading facts in /var/lib/puppet/lib/facter/libvirt_uuid.rb
*Could not retrieve virtual: Invalid argument -
/sys/firmware/dmi/entries/1-0/raw*
*connect: No such file or directory*
*Please make sure that the zfs-fuse daemon is running.*
*internal error: failed to initialize ZFS library*
*connect: No such file or directory*
*Please make sure that the zfs-fuse daemon is running.*
*internal error: failed to initialize ZFS library*
/usr/share/ruby/vendor_ruby/puppet/provider/service/bsd.rb:12: warning:
class variable access from toplevel
/usr/share/ruby/vendor_ruby/puppet/provider/service/freebsd.rb:8: warning:
class variable access from toplevel
/usr/share/ruby/vendor_ruby/puppet/provider/service/freebsd.rb:9: warning:
class variable access from toplevel
/usr/share/ruby/vendor_ruby/puppet/provider/service/freebsd.rb:10: warning:
class variable access from toplevel
info: Caching catalog for host26.lvs.cloudsigma.com
info: Applying configuration version '1368002053'
notice: Finished catalog run in 3.09 seconds

The strange thing is that I am installing fedora with kickstart using
foreman and puppet and no ZFS. The repo has been "frozen" awhile ago and
there aren't new packages there.

Here's the version output if needed.
On the agent:
puppet --version
/usr/share/rubygems/rubygems/custom_require.rb:36:in `require': iconv will
be deprecated in the future, use String#encode instead.
2.7.20
facter --version
1.7.0

On the master:
puppet --version
2.7.20
puppetmasterd --version
2.7.20
facter -v
1.7.0

Thanks for any help.

- Angel

This appears related to new code in Facter 1.7.0 that is intended to detect
whether the node is running the Google compute engine, Facter issue #17612
(http://projects.puppetlabs.com/issues/17612). You should be able to work
around it by reverting to the Facter 1.6.x series. Meanwhile, I encourage
you to file a ticket.

Examining the code doesn't reveal any obvious error. Facter uses this:

   def self.read_sysfs_dmi_entries(path="/sys/firmware/dmi/entries/1-0/raw")
     if File.exists?(path)
       File.read(path)
     end
   end

That /sys/firmware/... path does not appear anywhere else in Facter that I
(and Google) can find. That suggest that either the exists? test or the
read must be causing the error to be emitted in your environment, but it's
not clear which, or why. Does it happen when you run Facter with privilege
(e.g. via sudo), with SELinux in permissive mode or disabled? The error
message doesn't appear to indicate a permission problem, but perhaps it's
misleading.


John

So I guess the best would be to collect the following output

     % ruby --version
     % ls -l /sys/firmware/dmi/entries/1-0/raw
     % stat /sys/firmware/dmi/entries/1-0/raw
     % ruby -e 'puts :ok if File.exists?("/sys/firmware/dmi/entries/1-0/raw")'
     % ruby -e 'puts :ok if File.read("/sys/firmware/dmi/entries/1-0/raw")'

-Stefan

Here's the output for the commands you requested. Thanks again for looking
into it.


+* ruby --version*

I also did the modification that Stefan requested and my output is the same
as yours:

[[email protected] ~]# facter --debug virtual
Regards,
Charlie

Sorry... I forgot to answer John's questions (above).

Facter produces the same error messages running under sudo. Also, I have
SELinux turned off.

[[email protected] ~]# *facter virtual*
Charlie

SELinux is disabled and the commands were ran as root.

Downgrading the facter to 1.6.18 version seems fixing the problem.

Thank you very much for the support guys.

Best Regards,
Angel Angelov