Swapping out your Motherboard? - here are some notes on my experience.

[Ian Carson]

Background
I built a NAS for my business several years ago in fact I started with FreeNAS 9.0. The NAS has run smoothly but new requirements for larger VMs found the machine a bit lacking in the RAM department. Although I wasn't maxxed out on the board RAM, 64Gb wasn't going to be enough for my needs so I settled on the ASRock C3758D4I-4L as the upgrade since it could go to 128Gb RAM using RDIMMs.

The upgrade was to be a straight swap of the MB only so that the LBA, boot drive and L2ARC would not change.

Unfortunately the upgrade was not quite as simple as I had hoped!

Steps taken to upgrade

• Took a backup of the config including all the passwords and secrets (this NB - I would have been lost without it)
  
  
• Took a backup of ssh files in /root/.ssh (didn't need these in the end - better to have and not need than vice versa)
  
  
• Swapped out the Motherboard and reconnected boot and L2ARC drives and the LBA
  
  
• Powered up...

...and got "web interface not found" - couldn't get to the UI at all. Just a little worrying!

Steps taken to resolve the issue

• I tried a reset configuration and a reinstall of the backup config but got the same result
  
  
• Searching through the /var/log/console.log hinted at a problem accessing "igb0", the main interface to the domain
  
  
• An ifconfig revealed that the new MB has differently named interfaces "ix0-4" in this case and of course they each had different MAC addresses from the old MB
  
  
• I tried adding ifconfig_ix0_name="igb0" to /etc/rc.conf but TrueNAS does not allow changes to /etc/rc.conf (or at least overwrites any changes made there manually during startup)
  
  
• I tried adding hint.igb.0.at="pci0:5:0:0" to /boot/devices.hint to get the boot sequence to rename the interface but this did not take

Solution

• In the end I got a copy of SQLiteStudio and opened up the freenas_v1.db file which was in the config backup tar file and manually changed the entry in the "network_interface" table to match the new MB's interface name and MAC address.
  
  
• I then created a new tar file with the modded db file and the original pwenc_secret file
  
  
• Finally I reset the configuration once again and when the vanilla install came up I used the modified backup to get the interface I needed to come up
  
  
• There was a minor issue accessing my VMs
  • the VM NICs were bound to the wrong name
  • the VM VNCs were bound to the wrong IP
  • once changed these came good as well

All good now and I hope these notes may be of use to someone out there

 

[Arwen]

In general, the network interface change is done from the console of the server.
I've not done it, but I've been told it is pretty straight forward. From what it looks
like, much simpler than editing a DB file.

Of course, their would still be VM NIC changes, and possibly a few others.

 

[Ian Carson]

@Arwen
I couldn’t see a way to make that change from the menu presented by the console. Most importantly the UI was unavailable because none of the NICs were “activated” after boot up and all showed “no carrier”.

All attempts I made to bring up the interface I needed with the CLI menu didn’t work although I would love to hear how it could be done from there.

It makes sense that a drastic change like an MB swap would run into glitches like this and I was glad to be able to find a work around.

I was wondering though whether a different strategy might be used in the storage of NIC data in the db to allow for this issue. Perhaps

 

[Ian Carson]

data in support of a “use the first NIC” concept rather than storage of the specific name and MAC would have obviated this problem. I’m not across this in enough depth to know if that would work but it is certainly a valid use case even if it is a bit of an outlier

 

[SMnasMAN]

Super helpful information, thank you VERY MUCH for taking the time to write this up!

Im about to do something very similar (motherboard swap from Intel 2x e5-2640v2 on a supermicro X9, to a single AMD Epyc on a supermicro H11 based board). so your info is great to know.
i will update this post if my swap goes easy, else will write up a new post, like yours, if its more difficult. (am running CORE v13.0u3.1 currently)

 

[weezer562]

Super helpful information, thank you VERY MUCH for taking the time to write this up!

Im about to do something very similar (motherboard swap from Intel 2x e5-2640v2 on a supermicro X9, to a single AMD Epyc on a supermicro H11 based board). so your info is great to know.
i will update this post if my swap goes easy, else will write up a new post, like yours, if its more difficult. (am running CORE v13.0u3.1 currently)

How did it go?

 

[majorgear]

How did it go?

I’m curious , too. In my case, I’m not using the built in NIC , instead I’m using a slotted 10Gbe NIC as bridge interface. All of my apps have unique IPs that use the bridged interface.

Update: In my case, the NIC configuration didn’t change , so that part went smoothly.

 

[danb35]

Regardless of which version of Free/TrueNAS you're using, there's a reasonable likelihood that your network interface names will change, which will mean that if you've done any manual network configuration, you'll need to redo it. If you've been using the onboard interface, the obvious reason is that the new motherboard will use different hardware, which would require a different driver, which would result in a different interface name. If you're using a separate NIC, it's still possible that the interface name will change (that happened to me with my Chelsio T420CR under SCALE when I recently swapped my motherboard). Be prepared for this. You shouldn't need to manually edit the config database; just use the console menu to configure your network at least enough to be able to bring up the web UI. You can do the rest there.