Bug #14523

no such interface error from facter on solaris 10

Added by Tim Mooney about 1 year ago. Updated about 1 month ago.

Status:AcceptedStart date:05/15/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Keywords:solaris Affected Facter version:
Branch:

Description

This happens with both facter 1.6.6 and 2.0.0rc1.

I’m using facter on x86_64-sun-solaris2.10 with ruby 1.9.3p125

When I run either version of facter, the first few lines of output are

ifconfig: status: SIOCGLIFFLAGS: e1000g0:1: no such interface
ifconfig: status: SIOCGLIFFLAGS: e1000g0:1: no such interface
ifconfig: status: SIOCGLIFFLAGS: e1000g0:1: no such interface
ifconfig: status: SIOCGLIFFLAGS: e1000g0:1: no such interface
ifconfig: status: SIOCGLIFFLAGS: e1000g0:1: no such interface
ifconfig: status: SIOCGLIFFLAGS: e1000g0:1: no such interface

It seems to be complaining about one of my interfaces associated with ipv6:

# /sbin/ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 134.129.106.23 netmask ffffff00 broadcast 134.129.106.255
        ether 0:1c:c0:82:51:84 
iprb0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 172.17.110.23 netmask ffff0000 broadcast 172.17.255.255
        ether 0:2:b3:15:6f:12 
vboxnet0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
        inet 192.168.56.1 netmask ffffff00 broadcast 192.168.56.255
        ether 8:0:27:a0:5d:7c 
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128 
e1000g0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        inet6 fe80::21c:c0ff:fe82:5184/10 
        ether 0:1c:c0:82:51:84 
e1000g0:1: flags=2080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
        inet6 2001:4930:106::23/64 

Relevant portions of the facter output:

interfaces => lo0,e1000g0,iprb0,vboxnet0,e1000g0_1
ipaddress => 134.129.106.23
ipaddress6 => 2001:4930:106::23
ipaddress_e1000g0 => 134.129.106.23
ipaddress_iprb0 => 172.17.110.23
ipaddress_lo0 => 127.0.0.1
ipaddress_vboxnet0 => 192.168.56.1
netmask => 255.255.255.0
netmask_e1000g0 => 255.255.255.0
netmask_iprb0 => 255.255.0.0
netmask_lo0 => 255.0.0.0
netmask_vboxnet0 => 255.255.255.0
network_e1000g0 => 134.129.106.0
network_iprb0 => 172.17.0.0
network_lo0 => 127.0.0.0
network_vboxnet0 => 192.168.56.0

Related issues

Related to Facter - Bug #15001: ipaddress fact fails on Fedora 17 Merged - Pending Release 06/13/2012

History

#1 Updated by Hailee Kenney about 1 year ago

  • Status changed from Unreviewed to Accepted

#2 Updated by Andriy Yurchuk 3 months ago

Just encountered the same issue on Solaris 11 SPARC. This is caused by the fact that for some reason Solaris is not able to display ifconfig info for a virtual interface.

root:~$ ifconfig  -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
net0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.1.2.2 netmask ff000000 broadcast 10.255.255.255
        ether 1:2:3:4:5:6
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128
net0: flags=20002004841<UP,RUNNING,MULTICAST,DHCP,IPv6> mtu 1500 index 2
        inet6 fe80::8:20ff:fe2e:2e2e/10
        ether 1:2:3:4:5:6
net0:1: flags=20002000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        inet6 fdd0:54e1:a26a:4f4f::3:6/64


root:~$ ifconfig net0
net0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.1.2.3 netmask ff000000 broadcast 10.255.255.255
        ether 1:2:3:4:5:6


root:~$ ifconfig net0:1
ifconfig: status: SIOCGLIFFLAGS: net0:1: no such interface

#3 Updated by Andriy Yurchuk about 1 month ago

It seems that this problem raises if a network interface is not plumbed. After doing ‘ifconfig net0:1 plumb’ those errors no longer appear. Anyway, such a situation should be handled gracefully inside Facter code.

Also available in: Atom PDF