MATLAB Answers

0

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 3 May 2016

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?

  0 Comments

Tags

No tags are associated with this question.

Products

2 Answers

Answer by MathWorks Support Team on 4 May 2016
 Accepted answer

For MATLAB R2014a and later, licenses can be activated to devices using the Consistent Network Device Naming convention. 

For MATLAB R2013b and earlier, licenses can be activated on a machine with no eth0 using a udev rule to rename the device to eth0.

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"

 

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:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

http://www.reactivated.net/writing_udev_rules.html

 

For releases R2008b and earlier MATLAB must be locked to an eth0 device.

  0 Comments


Answer by Krish Pillai
on 3 May 2016
Edited by Walter Roberson
on 3 May 2016

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="rd.lvm.lv=fedora00/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora00/swap $([ -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.

  1 Comment

Thanks for writing that up!


Join the 15-year community celebration.

Play games and win prizes!

Learn more
Discover MakerZone

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

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!