MATLAB Answers


Why can't I activate MATLAB or start the license manager in a newer Linux environment?

Asked by MathWorks Support Team on 18 Sep 2013
Latest activity Commented on by Walter Roberson
on 26 Jan 2016 at 19:09

When trying to activate MATLAB on newer Linux versions, the activation fails. Checking the Host ID shows that the Host ID is 000000000000 which does not work. I also experience issues with the license manager where it will not start on these new distributions. How can I activate MATLAB or use the license manager in this environment?


Krish Pillai
on 1 Jun 2015

I ran into the same issue while attempting to reinstall Matlab 2010b on a Fedora 20 (3.19.5-100.fc20.x86_64) system. The reinstall failed after Fedora was upgraded.

Symptom: Activation fails with the following error: "Error 1,714. Unable to activate your machine. This activation process cannot detect a valid Hist ID which utilizes a currently supported naming convention. Please refer to the following solution ID to help resolve the issue 1-661QJD"

Reason: Apparently, Matlab is looking for an eth0 device and fails to find it. This was confirmed by Matlab Technical support Case Number is 01379776 and I was directed to this site. The accepted answer at this site did not work on Fedora 20, and hence this comment. It did help me find a solution.

Observations: My configuration uses and ASROCK X-58 Supercomputer Motherboard with 2 on-board ethernet devices. Fedora 20 systemd supports BIOS provided numbers and if that is not supported it looks for a higher level scheme provided either by PCIe index numbers, or if even that isn't available, it resorts to geographical location numbering. Typically biosdevname makes naming consistent by referring to embedded devices as em[123..], PCI cards as p<slot>p<port> etc. And on the target machine, the ports were being numbered em0, em1.

The recommended steps using dev rules did not work since the 70-persistent-net.rules didn't exist and udev rules created were being ignored.

Solution: The following did work. The package biosdevname was removed with "yum erase biosdevname" "biosdevname=0" was added to kernel boot arguments in /etc/sysconfig/grub .

Adding this to kernel boot args is probably an indication of paranoia, but in case biosdevname gets reinstalled, you don't want the device names to get changed.

Removing biosdevname alone won't suffice since the system will now fall back to geographical numbering and start numbering devices as enp2s0 etc, if you were to reboot. To stop it from auto naming entirely, also add the following to the kernel boot argument "net.ifnames=0". A sample entry in /etc/sysconfig/grub that disables biosdevname, the nouveau driver and ifnaming is as shown: GRUB_CMDLINE_LINUX=" vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param :) rhgb quiet rd.driver.blacklist=nouveau biosdevname=0 net.ifnames=0" There is some overlap in functionality between biosdevname and ifnames and how udev/rules are used, and it would probably go away once Fedora cleans it up. Run "grub2-mkconfig -o /boot/grub2/grub.cfg" to generate a new grub.cfg. Don't reboot yet. You have to rename your network scripts in /etc/sysconfig/network-scripts/ifcfg-em* to if cfg-eth* and edit them so NAME="em*" reads the corresponding "eth*". Now reboot and confirm your devices show eth* (use "ifconfig -a").

If you do figure out a more optimal way to do this, please let me know or post it here.

Joe VanAndel
on 2 Jun 2015

Thanks, your procedure worked for me.


No tags are associated with this question.


2 Answers

Answer by MathWorks Support Team on 18 Oct 2013
 Accepted answer

Some newer Linux distributions have adopted the Consistent Network Device Naming convention for naming Network Interface Cards. Traditionally, Network Interface Cards were named using the ethX standard. This standard was known to cause trouble on machines with multiple network devices as the device names would change based on when it was detected by the kernel in the boot sequence. As of R2014a, MATLAB and the License Manager can be activated to devices using the Consistent Network Device Naming convention.  


In an effort to move away from the ethX standard, modern distributions have began implementing naming schemes based on the physical location of the network devices in the computer. The two main new naming standards are:

1. em[0-9] for Network Interface Cards embedded in the motherboard

2. ens<slot_number>p<port_number> or p<slot_number>p<port_number> for PCI cards

3. There may be other naming schemes based on your distribution and type of ethernet device


MathWorks software must be locked and activated to the MAC address of an ethernet device on Linux. We are currently able to activate to the ethX and enX device names. If your machine is using one of the naming conventions listed above, then you will need to rename your device to match one of the naming conventions that we utilize. 


NOTE For releases R2008b and earlier MATLAB must be locked to an eth0 device. In general, a Linux machine with an ethernet device should always have an eth0, but the device may be named eth1, eth2, etc. The eth0 device may just be disabled, in which case you would just have to enable eth0. To activate MATLAB on a machine with no eth0, you can rename the eth device to eth0.


Typically, the most consistent way to change the name of the ethernet device, and have the name preserved across reboots, is to create a udev rule.


udev is a relatively new way of managing the /dev directory and populating it with device nodes. It was introduced in the Linux 2.5 kernel, and will be present on most modern Linux systems.


udev rules are constructed as a series of matching conditions and action commands. When a device matches all of the conditions, the assignment commands will be executed. udev rules are stored in /etc/udev/rules.d and must have a .rules extension. They are read and processed in lexicographical order. The udev rule to change the Network Interface Card's will typically be named 70-persistent-net.rules


The simplest udev rule to change the name of an ethernet device, with MAC address xx:xx:xx:xx:xx:xx, to eth0 will be:

ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="eth0"


If you are unsure how to find your MAC address, please try running the following command: ifconfig


There are other methods of changing the name of the ethernet device, but many of them are distribution specific and can not be guaranteed work on all distributions. udev rules take priority on all systems running the udev framework.


If you would like more information about this naming convention change and writing udev rules please take a look at the following links:


If you would like assistance renaming your ethernet device feel free to contact MathWorks Installation and Licensing Support.


George Wilkie
on 26 Jan 2016 at 14:40

What a silly and arbitrary demand to make of customers. I suppose I will not be using Matlab, at least until you fix your licence manager.

Walter Roberson
on 26 Jan 2016 at 19:09

Mathworks does not create the license manager; Mathworks uses the FlexNet (FlexLM) license manager that most major programs use, including all of the major competition to MATLAB.

Answer by Julian
on 24 Jan 2014

The real solution to this issue is that the Mathworks fix their license manager and not that users are supposed to fiddle with their network device names.

So, here is the full story: from udev/systemd 197 on, udev automatically assigns predictable network interface names. See here for the upstream documentation and here for the relevant Fedora page.

So, predictable interface names are the recommended way to go now (and as pointed out in the upstream documentation, this means that you can come up with any fancy custom name you want, but NOT ethX/wlanX), so please, fix your license manager.


Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi test

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

MATLAB Academy

New to MATLAB?

Learn MATLAB today!