Deployed CentOS image changes the MAC address?

[salted_cashews]

So on capturing an image with CentOS, and then deploying to a different machine (that is not identical hardware) I get a MAC that isn’t even listed in the fog server. It’s been captured as a “Linux” OS type and a “Multiple Partition Single Disk” image type. Why does this happen? What could I do to fix this?

Original MAC: 60:45:cb:a2:86:bd
New MAC: 60:45:cb:a2:86:b4

[Sebastian Roth]

@salted_cashews I might be wrong here but to me it sounds like you are not aware of the concept of MAC addresses.

Every network card in the entire world is meant to have a distinct MAC address, no duplicates. So each and every machine you have has a different MAC address burned into the network cards ROM. And sure you will see different MACs on each client that you deploy an image to.

Re-reading your post again and again but can’t really make sense of it. On the one hand I thing I totally miss-read what you are saying but then I can’t see how you could mean something different. So please tell us more about what happens (where exactly do you see the changed MAC - upload picture!) and what you expect.

[george1421]

@salted_cashews said in Deployed CentOS image changes the MAC address?:

I get a MAC that isn’t even listed in the fog server

First let me say I’m in full agreement with Sebastian on this issue.
Second this quote is the confusing part in that how did you deploy this centos image to the target hardware? Did you register that target hardware with FOG then deploy from the FOG Webgui or did you deploy this centos image directly from the FOG iPXE menu “Deploy Image”?

If you deployed the image from the webgui then you surely did have that new target computer’s mac address in FOG, because it would have been entered as part of the registration process.

If you deployed the image from the FOG iPXE menu “Deploy Image” then that target computer’s mac address would not appear in fog since the system was never registered it only pushed the image to the target computer then reset. Nothing will be registered in this process, nothing remembered. The “Deploy Image” menu in iPXE is intended for system rebuilders to install OS on target computers once since they will never see that system again or need to manage it via FOG. If this is the case I can understand why there is no mac address saved in the webgui.

[salted_cashews]

So we have statically assigned IPs in our dhcpd.conf file that finds the associated MAC and binds the IP. The mac address of the machine in question is not what shows up on the linux box, and is not what was present on the machine I captured from either. It’s a MAC that doesn’t exist in our building.

This does not happen with windows images. Windows images regardless of where they are captured from or deployed to - the physical NIC MAC is respective to the machine it is on/NIC it belongs to. Before, the machine in question had a windows image and it was reporting a different MAC, the correct one and the one that FOG has in it’s registration inventory.

Because “certain MAC” = “certain IP” the machine got a random dhcp IP address and I was unable to remote into it for a period of time until I went to the machine to figure out what was going on.

[Sebastian Roth]

@salted_cashews I kind of get where you are coming from - machine having a MAC not configured in your dhcpd.conf and that’s confusing.

What I can tell you is that MACs have nothing to do with the image or OS being installed. A client booting does request an IP from the DHCP using it’s native MAC address usually. There are ways of faking the MAC on Linux and Windows but I don’t think this is the case here.

Looking at the MACs you posted again I noticed they are very similar. Could it be the machine has multiple network interfaces with consecutive MAC addresses? Possibly it was connected to a different port last time?

[salted_cashews]

Both machines only have one NIC, and I did some research and tried to remove the 70persistent file under udev and still nothing. I might rebuild the image for this hardware which would be a better idea anyway, I was just curious how it would turn out on a completely different system being built on another.

[Sebastian Roth]

@salted_cashews If you would like help you might need to give us more information on where exactly you see the different MAC addresses. Take pictures of the old MAC on the host, then deploy and take a picture of the new MAC on that host.

… 70persistent file under udev …

This is only about naming the network interface within Linux and does not change your MAC address! If you have a persistent rule on host A for example, matching that host’s MAC for eth0. If you capture an image and deploy that to host B with a different MAC you will find that it ignores the original udev rule because it can’t match the MAC and will create a new one with interface name eth1 on that new host. But it does not change the MAC address itself.

[salted_cashews]

I’m unable to take pictures on the moment due to the computers being in use but this is what I’ve got in my notes:

(Original build)
Machine 1>ifconfig
enp0s31f6 (only present physical interface)
60:45:cb:a2:86:bd

(Deployed)
Machine 2>ifconfig
enp0s31f6 (only present physical interface)
ether 60:45:cb:a2:86:b4
Actual MAC (and what fog reports on this host): b8:ac:6f:99:3e:b8

It’s only in the CentOS (after deployment) that it does this. On pxeboot it reports the real MAC.

[Sebastian Roth]

@salted_cashews Possibly something new I have never seen before.

Maybe check /etc/sysconfig/network-scripts/ifcfg-enp0s31f6 (e.g. HWADDR=... or possibly MACADDR=... - see here) on the deployed machine to see if there is anything strange there.

As well run ifconfig -a to see if there are any other adapters on the deployed machine.

[george1421]

@salted_cashews said in Deployed CentOS image changes the MAC address?:

ether 60:45:cb:a2:86:b4

While I can’t really understand what is going on here, but I looked up the vendor code for 60:45:cd and that belongs to an ASUSTek COMPUTER network adapter if that gives any clues. If the deployed computer was in a virtual environment I might suspect it to be a vmware or virtualbox mac owner.

FWIW: b8:ac:6f belongs to Dell.

[george1421]

@Sebastian-Roth said in Deployed CentOS image changes the MAC address?:

Maybe check /etc/sysconfig/network-scripts/ifcfg-enp0s31f6

Along the same thought here, make sure your reference computer doesn’t list any system specific (HWADDR=… or possibly MACADDR=) in the network configuration files. That will cause issues with the cloned machine.

[salted_cashews]

Yeah that’s the weird bit, this is what I get from /etc/sysconfig/network-scripts/ifcfg-enp0s31f6

It doesn’t list a HWADDR or MACADDR which I found baffling. The deployed computer is a Dell PC, and the NIC came with it. The captured image PC is in fact using ASUS hardware under a company called “Ciara”. So that part makes sense.

[Sebastian Roth]

@salted_cashews Please run the following two commands on the deployed machine, take a picture and post here:

yum install ethtool
ethtool -P enp0s31f6
ethtool -e enp0s31f6 | head -3

[george1421]

@salted_cashews The more I think about it, the more I’m inclined to remove /etc/sysconfig/network-scripts/ifcfg-<network_adapter> from the scripts directory before image capture. Most linux distributions will recreate this file if the mac address of the hardware doesn’t match the mac address (and/or UUID) listed in the config file. If I have custom settings in the network scripts config file I will typically just remove the hardware specific values in the config file then capture and deploy as long as its on the same hardware. I’ve found this method keeps the linux OS from just recreating a new ifcfg-xxxx file. Of course deploying to a different hardware with a different netowkr adapter should create a new file naming format since part of the network driver name is embedded in the device name.

[salted_cashews]

@Sebastian-Roth said in Deployed CentOS image changes the MAC address?:

ethtool -e enp0s31f6 | head -3

[Sebastian Roth]

@salted_cashews So even ethtool sees 60:45:cb:a2:86:b4 as the physical MAC on this system. Not sure what to say.

[salted_cashews]

Haha I know that’s why I’m completely dazed. I appreciate the help though, we’ve gained some insight as to how to build our images moving forward because of this.