[Solved] How to STOP changing NIC names on reboot?

1

Hi all,

For some reason, my ethxx interface names change a lot. I’m not looking to understand why - frankly I don’t care - but how do I get FreePBX (this SHMZ rubbish) to STOP doing it?

I’ve searched for hours to find this out. Every other distro it has been changing an argument in the grub file, but this distro decides to be different. There’s not even a typical etc/default/grub file!

Quite honestly, the amount of mucking around just to get FreePBX working properly is far more than its worth.

These NIC troubles, the firewall being a total pain in the backside in every way possible, the backup/restore function not working properly, the update system seeming to break every couple of iterations, having to go to a completely different site to change my password for this one, and a host of other things I can’t think of right now put this product top of my ‘problems I wish I didn’t have to deal with’ pile. Which is a shame, because I’ve been using it for quite a few years and I really like working with it when I’m not mired ten feet deep in mucking around with it.

I administer six different linux systems, and only a couple are on common distros. The work required for FreePBX is more than ten times any of the others. I hoped Sangoma might see that the name Schmooze wasn’t the only completely stupid thing about the previous company, but I’m guessing there are bigger priorities.

To be clear, I’m not having a go at anyone in particular, I’m well aware that many people don’t have these problems, and I’m not looking to argue about the merits of the product. If someone could shine a light I’d be most appreciative.

Cheers.

2

Good to know…

… and yet here you are.

I’m going to guess (since you didn’t actually give us dick to work with) that you are running on a VPS on a cloud somewhere. Some VPS systems randomly change the configuration of their Ethernet cards. For most systems, it’s not an issue. For others (like FreePBX which uses the Ethernet information for several things) it is. There are changes to the eth0-up (and kith) files, documented in this self-same forum that you can search for as easily as we can, that tell you how to lock down the Ethernet port names to stop the problems you are seeing.

1 Like
3

I appreciate the suggestion. If you could possibly point me in the direction of this resource you feel might be of use, that would be most welcomed.

Leaders are regulars who have been around forever and seen everything. They set a positive example for the community through their actions and their posts.

4

One positive example you can find repeatedly here in the fora:-

https://wiki.freepbx.org/display/SUP/Providing+Great+Debug

How about you show us yours, and maybe someone will show you theirs :slight_smile:

One missing answer, “Are you running a virtual machine on a cloud server?” if you are not, then that is VERY unlikely to happen, if you ARE then it will likely be a simple udev solution. This will likely be because you chose a ‘container’ not a real machine.

5

I don’t really understand what you’re getting at here. I’m just looking for where I need to go to disable the NIC auto-rename feature for the supplied distro, because all the standard places haven’t proven anything.
Admittedly, I’m on SHMZ something-or-other, but still, it’s prohibitively difficult to find.

At the end of the day, I’m just some dude sharing my frustration.

This is a community forum for people to participate in. It is absolutely required for the project to have life. If leaders don’t set these positive examples, users go elsewhere and that hurts the project. If people stop using it, less people contribute. If less people contribute the project gets harder, and economically it becomes unviable for the parent company (in this case Sangoma).

I am following one open source project in particular that doesn’t have a larger following because the main forum support guy is a complete dick in 90% of his responses and so the forums are a ghost town. It’s unnecessary. Doesn’t matter, it’s a great project so we just make internal changes where necessary.

This is not the first time on these forums that I’ve received a response that, regardless of anything else, isn’t helpful.
I’d like FPBX to succeed, but that’s not really up to me. There are many alternatives.

I’ll ask one more time; can someone please suggest where I might go to disable the renaming of the NICs on certain starts of the machine.

In answer to your question, yes, it is virtualised. That being said, I use 3 different types of architecture to virtualise it, and this problem happens on many of them. I don’t want to debate the functionality, whys or wherefores, I just want to disable it - as I have on all my other systems - and then the problem stops.

Thanks in advance, and apologies for the syntax issues - I’m incredibly hung over today.

6

Holy Moly !!! HOW is it virtualized?, by WHO? and on WHAT platform?.

If you can’t be helpful by providing the absolute basics of what you did then how can anyone . . . . .

You continually refrain from providing ANY concrete info about your system, why is that?

ip addr

will expose the names of your interfaces, some might be able to surmise from that, but being increasingly pissy won’t garner too much support ongoing. Have you thought about why that might happen?

7

This time they’ve gone up to eth19 and eth20.

My config files are for eth0 and eth1, so I just need it to stop changing these names (which I managed to do last time, but I haven’t moved it in over a year so I can’t remember what I did). I deleted the 70-persistent-net-rules (i forget the name, it’s from the udev folder), and that brought one back to eth1 but the other is still eth19.

Interestingly, they both have the same MAC address. This was the next thing I was going to look into.

I have one virtualised with a small company who resells amazon through their own system, then I have two others I host myself with VMWare and VirtualBox. For the most part, VirtIO is my friend because it saves a lot of these issues, but not in this case.

I mean, I run two other CentOS derivatives (one custom and one CloudLinux) and neither of them have this problem.

The equivalent with other distros, as I mentioned, is in the grub config. Where do I find this for SHMZ?
I tried to backup and restore to the current version, as I’m over the moon that Sangoma has taken over, but the backup/restore hasn’t worked, and I can’t afford the time to put into it.

8

We still have no idea of your OS , ‘SHMZ’ is not specific but as RH stumbles onwards ( :wink: )

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming

might help

still waiting for your

ip address

. . . . . .

9

For anyone searching for this in future, I just gave up on this issue, and rebuilt from scratch with the new ISO.

10

I’ve run into a issue something like this running FreePBX distro in a HyperV cluster. For those running in this type of environment, in the configuration of the virtual instance, make sure you select the MAC as static, not dynamic (default). This doesn’t affect reboots, but if you move the machine to a different host, then reboot it, the mac will change, then a new IP will be given.
Had this happen in production once on a couple of systems when we lost the cluster. Had to do the deletion of the “70-persistent-net.rules” files like mentioned above in this thread.

11

Typically a great solution, from what I understand, although I never found HyperV to my tastes.

I managed to rule out MAC issues, NICs changing, and a few other things, unfortunately it just wasn’t worth the time it was taking.

Regrettably, the install from ISO was also fraught with problems. It got stuck at installing the freepbx package - which required me to start again twice - and once I finally managed to work my way past that it then broke when updating PM2 (not for the first time). I finally got sick of the work required to resolve it (despite following direction from the developers themselves) so I have removed FreePBX altogether.

Hugely disappointing after more than 5 years of constant usage, but I will keep an eye on the project and try again when it is somewhat more mature. Look forward to seeing it succeed over the alternatives.
May I suggest leaving the underlying OS alone as much as possible. I’m not sure if that is a concern for anyone else, but you have lost yourselves at least one customer because of all the fuckery.

Great work otherwise. Que the inevitable disagreements from members of the forum, I guess.

12

What would have helped is to provide information on how the solution was being deployed. You were asking the forum how to turn something off. You assumed we know off the top of our heads. Not necessarily the case. What you failed to do was give information to the forum to allow the recreation of the problem.

13

Fair enough, I appreciate the help of those who weighed in anyway.

14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.