DL_ERROR_ACK qfe0 card problems 2

[AnotherAlan]

Hi all,

Solaris 8.
I have recently cloned an e420 root environment to a spare disk in an exisiting e420.
When booting to the second (cloned) disk I am getting the following errors on boot and when running ifconfig qfe0 plumb;
ifconfig: SIOCSLIFNAME for ip: qfe0: no such interface
ip_rput_dlpi(qfe0): DL_ERROR_ACK for DL_PHYS_ADDR_REQ(49), errno 3, unix 0
ip_rput_dlpi(qfe0): DL_ERROR_ACK for DL_UNBIND_REQ(2), errno 3, unix 0
ip_rput_dlpi(qfe0): DL_ERROR_ACK for DL_DETACH_REQ(12), errno 3, unix 0

I've checked the path_to_inst on the good disk and the bad disk and ran a devfsadm and reconfiguration boot without success.

Everything else works great and as expected.
Any ideas please?

Thanks

 

[AnotherAlan]

OK, this is quite embarrasing but interesting none the less.

As explained I was cloning from another server.
The new server had two qfe cards installed and I removed one.
The interesting element is that even after a devfsadm and reconfiguration boot it did not re-number the existing card.

Hence when running prtconf -v | grep qfe I see the qfe cards but numbered as instances 4,5,6,7.
ifconfig qfe4 plumb worked.

Easy when you know how..;-)

 

[KenCunningham]

A star for posting back, Alan. Too many people hide behind their embarassment!

I want to be good, is that not enough?

 

[AnotherAlan]

Thanks Ken. If I carry on screwing up i'll make it onto the MVP list...;-o

 

[KenCunningham]

..how do you think I'm there! ;-)

I want to be good, is that not enough?

 

[Annihilannic]

The interesting element is that even after a devfsadm and reconfiguration boot it did not re-number the existing card.

This is one of the reasons path_to_inst exists, so that the OS can keep track of device IDs that were previously used and prevent them from changing, even if other devices are removed. You need to remove this file and perform a reconfiguration reboot to force them to be "re-enumerated". Do this at your own risk, rebuilding path_to_inst can result in some tricky situations!

Annihilannic.

 

[AnotherAlan]

Thanks for the explanation Annihilannic.
I guess that makes perfect sense when you think about it.

I should have paid more attention to devices and device paths rather than relying on devfsadm to bail me out.

Cheers

 

[coffeysm]

I usually just remove the references in /etc/path_to_inst to the affected hardware. That way you do not have to rebuild the entire file.