unRAID 6.8.2 - Boot to 169.x.x.x after Update


mifronte

Recommended Posts

I just updated to 6.8.2 from 6.8.1 and the server is booting up to some unknown IP Address of 169.264.246.72.  My network is in the 10.168.192.x range so I don't know where it is getting the IP address instead of from my DHCP.  This means I cannot access the server via GUI.  I am using IPMI remote console to access the console.

Edited by mifronte
  • Like 1
Link to comment

I have rebooted several times, including completely turning the the power.  The server keeps booting to the IP address of 169.254.246.72.

 

I will need help with executing console commands to get it the correct IP address.  It is not getting it from my DHCP server.  My unRAID is configure to bond the dual Intel NIC in my server.

Edited by mifronte
Link to comment
3 hours ago, mifronte said:

Hopefully someone can figure out why my server is not getting an IP address on reboot. 

There seems to be some trouble to get the bonded interface up and ready.

Feb  5 15:50:42 Beanstalk dhcpcd[1527]: br0: carrier lost
Feb  5 15:50:42 Beanstalk kernel: br0: port 1(bond0) entered disabled state
Feb  5 15:50:44 Beanstalk kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Feb  5 15:50:44 Beanstalk dhcpcd[1527]: br0: carrier acquired
Feb  5 15:50:44 Beanstalk kernel: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex
Feb  5 15:50:44 Beanstalk kernel: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
Feb  5 15:50:44 Beanstalk kernel: bond0: first active interface up!

Does your switch/router have proper support for LACP (802.3ad)?

 

Instead of using mode 4, try mode 6 as bonding protocol. This requires no special configuration on your switch/router

Link to comment

Yes, my Cisco SG350 switch supports 802.3ad.  It has always worked prior to 6.8.1 and it is working now after I ran the command

 

inet restart

after the server boots.  Starting with 6.8.1, I started having problems with the server not acquiring an IP address during boot.  Actually with 6.8.1, it happened the first reboot after updating. Then it worked when I rebooted the server again.  Now with 6.8.2, the server does not obtain an IP address during the boot process at all.

 

Could it be a timing issue and the boot process does not allow enough time to obtain an IP address before defaulting to the 169.x.x.x?  Something starting with 6.8.1 that is giving me this problem.

 

I would rather not have to change the bonding protocol because I do not want to mess with my switch LAG configuration since my current bonding setup has been working flawlessly for years.

Edited by mifronte
  • Like 1
Link to comment
8 minutes ago, bonienl said:

You could also change to a static IP address and avoid any race condition.

Not quite sure what "race condition" means.  I do have the DHCP server configured to give my unRAID server a static IP.  I guess the last resort is to hard code in the IP address into the unRAID settings if there is no other solution.

Edited by mifronte
Link to comment
2 minutes ago, mifronte said:

I don't see any "active" mode settings.

When you configure an interface and make it a member of a port-channel, you would do something like

channel-group 1 mode active

 

2 minutes ago, mifronte said:

Not quite sure what "race condition" means.

DHCP is trying to obtain an IP address while at the same time the bond channel is initializing.

This results in a "no answer" for DHCP which gives the 169.254.x.x address assignment.

 

When you set a fixed IP address on the server (something I recommend), there is no more dependency and it doesn't matter how long the bond initialization takes.

 

Link to comment
4 minutes ago, bonienl said:

When you configure an interface and make it a member of a port-channel, you would do something like


channel-group 1 mode active

 

DHCP is trying to obtain an IP address while at the same time the bond channel is initializing.

This results in a "no answer" for DHCP which gives the 169.254.x.x address assignment.

 

When you set a fixed IP address on the server (something I recommend), there is no more dependency and it doesn't matter how long the bond initialization takes.

 

My SG350 Cisco switch is a small business switch which uses a GUI interface and it does not use Cisco's IOS like the enterprise switches.

 

So starting with 6.8.1, there must have been some changes in how the bond channel initializes and when DHCP client requests are made?  I can definitely configure unRAID with a fixed IP, but this means starting at unRAID 6.8.1, it no longer can support DHCP or is this a bug that can be fixed?

Link to comment

LACP needs time to exchange settings and characteristics of the bonded interface between both parties.

It might well be that this process takes longer due to different/more characteristics being exchanged. Your switch plays a role here too.

 

In your case apparently this is on a critical path and results in DHCP not getting an answer in time. The most viable solution is using a static IP assignment.

 

Actually, I am pretty sure it is a timing issue, because the DHCP request which is done a little later for the VLAN interface proceeds normally, indicating the bonded interface is up and running at that point.

 

Edited by bonienl
Link to comment

That explanation sounds reasonable since running the command

inet restart

at the console after the server boots gets the correct IP.  Would it be a good idea for me to put this command in my go script file if I prefer to keep my server using DHCP to get all of its networking configuration (i.e. local DNS, gateway, IP address)?

Link to comment
On 2/6/2020 at 8:51 AM, bonienl said:

As a temporary solution you can add the command to the 'go' file

 

As a permanent solution I've made an update to deal with the timing. Will come in the next version.

So I added the "inet restart" to the 'go' file and rebooted to test and it did not work.  So I tried running the command through the console with the same result.  It only worked after I first ran "inet" to clear the current 169.x.x.x IP and then "inet restart" got the correct IP from my DHCP.  I did logged out between running the two commands just to see my current IP assignment on the login console since I did not know the command to show my current network configurations.

 

Funny thing was, I was just trying to get help on the inet command and accidentally ran it without any arguments.  So if I was to use the 'go' file, what would be a more elegant set of commands to clear the current IP assignment and request a new one from DHCP?

Edited by mifronte
Link to comment
On 2/6/2020 at 12:05 AM, bonienl said:

There seems to be some trouble to get the bonded interface up and ready.


Feb  5 15:50:42 Beanstalk dhcpcd[1527]: br0: carrier lost
Feb  5 15:50:42 Beanstalk kernel: br0: port 1(bond0) entered disabled state
Feb  5 15:50:44 Beanstalk kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Feb  5 15:50:44 Beanstalk dhcpcd[1527]: br0: carrier acquired
Feb  5 15:50:44 Beanstalk kernel: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex
Feb  5 15:50:44 Beanstalk kernel: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
Feb  5 15:50:44 Beanstalk kernel: bond0: first active interface up!

Does your switch/router have proper support for LACP (802.3ad)?

 

Instead of using mode 4, try mode 6 as bonding protocol. This requires no special configuration on your switch/router

I'm also having a similar issue - 6.7.2 didn't have this problem, but starting 6.8.x bonded LACP DHCP is having trouble on a SuperMicro board. The current workaround is to use a static IP address and this does fix the issue for now.

Edited by coolspot
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.