On Wednesday, May 8, 2013 3:50:46 AM UTC-5, Angel Angelov wrote: > > 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 > > > On Wednesday, May 8, 2013 11:35:00 AM UTC+3, Angel Angelov wrote: >> >> 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. >> >> >> On Wednesday, May 8, 2013 12:14:25 AM UTC+3, Stefan Schulte wrote: >>> >>> On Tue, 7 May 2013 13:00:53 -0700 (PDT) >>> Charlie Brune <[email protected]> wrote: >>> >>> > [root@hogwarts ~]# 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 >>> >>
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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
