Network interfaces on T2000 - e1000g1 and ipge1

Installed Solaris 0509 from DVD and it configured network interfaces as e1000g1 to e1000g4.

Problem is after installation it fails to plumb this interface.

Weird thing is if I do sys-unconfig it then tries to configure ipge1 to ipge4.

Confused. Which is correct?

p.s. Cross posted to oracle forums also.

try a newer version of solaris 10 and/or patch the system with the latest patch cluster.

How do you know that it fails to plumb? What is the error message?

If the install process configures e1000g1 thru' e1000g4 it should create /etc/hostname.e1000g1 thru /etc/hostname.e1000g4 files.

A booting Solaris knows that it should plumb these interfaces by the presence (or not) of these files. If this file(s) do not exist then create them manually. (The only text in the files will be the nodename for that interface as a single ASCII string. Nothing else.)

Ensure that /etc/hostname.e1000g1 exists (or otherwise create it yourself) and reboot the system. What happens?

Also, tell us what /etc/hostname.* files exist on your root hard disk filesystem.

Got to use 0509. And have installed S10 recommended cluster.

---------- Post updated at 09:48 AM ---------- Previous update was at 09:38 AM ----------

Failed to plumb IPv4 interface(s): e1000g0
Feb 9 11:22:28 svc.startd[7]: svc:/network/physical:default: Method "/lib/svc/method/net-physical" failed with exit status 96.
Feb 9 11:22:28 svc.startd[7]: network/physical:default misconfigured: transitioned to maintenance (see 'svcs -xv' for details)

ls -al /etc/hostname*
-rw-r--r-- 1 root root 10 Feb 8 19:38 /etc/hostname.e1000g0
-rw-r--r-- 1 root root 12 Feb 8 19:38 /etc/hostname.e1000g1

svcs -xv
svc:/network/physical:default (physical network interfaces)
State: maintenance since Sat Feb 09 11:22:28 2013
Reason: Start method exited with $SMF_EXIT_ERR_CONFIG.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /usr/share/man -s 1M ifconfig
See: /etc/svc/volatile/network-physical:default.log
Impact: 6 dependent services are not running:
svc:/milestone/network:default
svc:/network/rpc/bootparams:default
svc:/system/webconsole:console
svc:/network/shares/group:default
svc:/network/ipfilter:default
svc:/network/ssh:default

svc:/system/fpsd:default (FP Scrubber - Online Floating Point Unit Test)
State: offline since Sat Feb 09 11:22:30 2013
Reason: Dependency svc:/system/system-log:default is absent.
See: http://sun.com/msg/SMF-8000-E2
See: man -M /usr/share/man -s 1M fpsd
Impact: This service is not running.

Interestingly, if I try ifconfig -a plumb it finds all the ipge interfaces now.

Don't understand how it thinks its e1000g during install but after a reboot it can't find this and think they're all ipge?

In 2006 I think, Sun switched from the ipge-driver to the more advanced e1000g driver for the Intel PRO/1000 adapter present in a T2000.

I can't explain, why this setup fault happened. But there is a shellscript /usr/sbin/e1000g_transition which will help you to switch your configuraion to the e1000g driver.

The help text taken from the script:

This script allows you to perform an optional driver upgrade
for the Intel PRO/1000 device present on this system from the "ipge"
network driver to the Sun standard "e1000g" network driver. The
e1000g driver include features such as link aggregation as well as
superior performance in most environments.  Moving forward, e1000g
will benefit from new features as they become available, bug fixes,
and performance enhancements.  The disadvantage is that some
applications configuration files may require modification to use
e1000g if they reference the ipge network interface.

This script must be run in single user mode.
This script will alter network interfaces and related system
configuration files. Configuration files for 3rd party applications
will NOT be changed. After running this script, applications present
on the system may require maintenance. The system may be in an
unsecured state. The effects of this script may be reversed using
the backout (-b) option.


For the latest information regarding this script, please refer
to Sun Alert ID 102502. This Sun Alert can be accessed from
http://sunsolve.sun.com.
Use the Sun Alert ID (102502) as the search query and choose
"Sun Alert Notifications" under "Sun Solve Collections."

Once the script has completed a system reboot will be required
to complete the upgrade.
1 Like

That is weird but since it's a T2000 I would check that the firmware/OBP/hypervisor versions are up to date.

I've had some nasty experiences with Solaris version upgrades and/or putting on patchsets where the system crashes. Assuming it was caused by just a glitch I've recovered the system and done it over and over before searching and finding that the firmware was incompatible but Sun (Oracle) gave no warning in version release notes and/or patchset release notes. I've only ever had this problem with T2000's.

Do you know the history of your box? What version of firmware does it have and is it up to date?

Search unix.com for stuff like "T2000 patching".

After all the bad experience I have my own rule that if a T2000 gives any trouble always upgrade firmware/OBP/hypervisor before anything else.

Hope that helps.

1 Like

Thanks. Very interesting - I will try this.

To be honest, I'm wondering whether its just going to be OK to sys-unconfig and let it start back up as ipge. Might be quicker.

---------- Post updated at 11:59 AM ---------- Previous update was at 11:57 AM ----------

Thanks. Yes, will do this I think.

Sun-Fire-T2000 System Firmware 6.7.6 2009/10/29 16:06

Host flash versions:
OBP 4.30.4 2009/08/19 07:24
Hypervisor 1.7.3.a 2009/10/29 15:50
POST 4.30.4 2009/08/19 07:47

It might work that way but a T2000 with recent Solaris versions should be configured e1000g1-e1000g4 so something would be wrong in using ipge1-ipge4.

I ran into this exact same thing. I ended up leaving it with the IPGE because I simply could NOT get it to work on the e1000g. When I ran the e1000g script to update to that driver the entire system refused to boot.

I ended up doing the install from the CD/DVD without setting up any networking. That way, it didn't try to force the e1000g. After booting, I plumbed the ipge and did all the setup and it works just fine. I filed an SR with Oracle, and they were no help at all in getting it to run on the e1000g, and since it was working fine with the ipge, I closed the case and got on with life.

Out of interest, I tried running the script. This is what I got:-

WARNING:
The script detected that both "ipge" and "e1000g" interfaces
exist in the system. The script can not handle this situation, as
there are potential conflicts between existing "ipge" and "e1000g"
instances. You will need to manually resolve device instance numbers
and configure your system configuration files.

---------- Post updated at 04:08 PM ---------- Previous update was at 04:08 PM ----------

Yeh. Wondering if it might be an idea. So you've experienced no problems?

---------- Post updated at 04:30 PM ---------- Previous update was at 04:08 PM ----------

UPDATE

Think I've cracked it. This is what I did:-

cp /etc/path_to_inst /etc/old.path_to_inst
rm /etc/path_to_inst
init 0
ok> boot -ar
(accept defaults and let it rebuild /etc/path_to_inst)
init s
cd /usr/sbin
./e1000g_transition -e
init 6

And it works with e1000g now....

Many thanks to hergp for the info about this script....

I tried letting it rebuild the path_to_inst and rebooting and all that. The script ran fine, but the box would not reboot. I had an Oracle engineer on site who tried a couple of things, too, and could not get it to boot after doing that.

You'll find this interesting. I have four T2000s (dev, test, prod and spare) that I inherited when I started here in Nov. 2012. All of the boxes need serious updates. Both dev and test use the e1000g. The prod box uses the ipge0 (and there's evidence that someone tried to switch it to the e1000g in the past).

Before updating the real boxes, I cloned dev and test to the spare using a FLAR image. Everything went fine. When I cloned prod to the spare during testing, I simply could not get the e1000g to work no matter what I did. I decided that I wasn't going to spend any more time than I already have trying to solve the e1000g/ipge issue because we plan to move to RedHat boxes later this year. As long as I can get the ipge to run when new CPUs come out, I'll hold off and not worry about it.

You are welcome, paulfoel. Glad, I could help.