The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #11041

facter-1.6.3 rpm is missing dmidecode as dependency

Added by Florian Koch over 4 years ago. Updated over 4 years ago.

Status:ClosedStart date:11/24/2011
Priority:HighDue date:
Assignee:-% Done:

0%

Category:library
Target version:1.6.4
Keywords:vmware rpm demidecode packaging Affected Facter version:1.6.3
Branch:https://github.com/puppetlabs/facter/pull/103

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

Hi,

i have a minimal Scientific Linux installation on a Vmware virtual Server, no dmidecode is installed. I install facter and get

facter | grep virtual
is_virtual => false
virtual => physical

i install dmidecode and get

facter | grep virtual
is_virtual => true
virtual => vmware

so dmidecode is needed by facter to detect vmware and should a rpm dependency

History

#1 Updated by Ken Barber over 4 years ago

  • Category set to library
  • Target version set to 144

#2 Updated by Ken Barber over 4 years ago

  • Status changed from Unreviewed to Accepted

#3 Updated by Adrien Thebo over 4 years ago

I dislike having to force dmidecode as a dependency, because facter really should be able to function without demanding a certain set of detection utilities. That being said, I’ve seen this exact error on minimal installs, which definitely causes problems. The solution that I like more is creating more fallback methods that don’t rely on dmidecode that can resolve this information. The first thing that comes to mind is to check the first three bytes of the mac address for ethernet devices for the manufacturer information, or something equivalent. Ken, thoughts?

#4 Updated by Ken Barber over 4 years ago

MAC addresses can be spoofed/changed. In a virt environment they let you specify your own in some cases so its not perfect. Again – this comes back to the discussion we had regarding gathering a lot of various pieces and weighing it up – but mac addresses being very mutable only carry a little weight.

Like I said the /sys/class/dmi/id/* area is there to use – I would use that in preference for kernels that support it and fall back to dmidecode in its absence. In the cases where OS don’t have /sys/class/dmi/id then is it all bad to really on dmidecode from a package perspective in this case? We are probably talking What is wrong with dmidecode in a minimal system if the information is needed and the other alternatives are complex? As we discussed – it taps /dev/mem which is going to be hard to do on our own :–).

BTW – this does affect Redhat 5 …. it doesn’t have /sys/class/dmi … so you are stuck using other methods anyway … from a package perspective its going to be pciutils or dmidecode …

I think the other side of the coin is a concept of ‘certainty’. If lspci, dmidecode, vmware doesn’t exist, nor the sysfs – how can we be totally sure the system is virtual or not? Falling back to ‘physical’ … is this really correct in this case? Maybe we should default to ‘unknown’? I would see this is a 1.7.x change though :–).

#5 Updated by Adrien Thebo over 4 years ago

  • Keywords changed from vmware rpm demidecode to vmware rpm demidecode packaging

Yep, completely right. dmidecode’s gonna be the best way to do this, but external dependencies are something I’ve been trying to avoid. We can add other detection methods too perhaps.

#6 Updated by Adrien Thebo over 4 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/facter/pull/103

Ken, point this at 1.7.0 or 1.6.x?

#7 Updated by Michael Stahnke over 4 years ago

Pull request: https://github.com/puppetlabs/facter/pull/103

#8 Updated by Ken Barber over 4 years ago

I vote 1.6.x. Its broken – this is a fix. Lets raise another ticket for Debian as well.

#9 Updated by Adrien Thebo over 4 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

Merged into 1.6.x in commit commit:6406c8fd6d05f585b6d1398c89012542f79e0f70

#10 Updated by Ken Barber over 4 years ago

  • Target version changed from 144 to 1.6.4

#11 Updated by Matthaus Owens over 4 years ago

  • Status changed from Merged - Pending Release to Closed

released in facter 1.6.4rc1

Also available in: Atom PDF