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.
2 Comments
Direct link to this comment
https://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-matlab-or-start-the-network-license-manager-in-a-newer-linux-environment#comment_561912
Direct link to this comment
https://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-matlab-or-start-the-network-license-manager-in-a-newer-linux-environment#comment_561912
Direct link to this comment
https://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-matlab-or-start-the-network-license-manager-in-a-newer-linux-environment#comment_561940
Direct link to this comment
https://www.mathworks.com/matlabcentral/answers/100235-why-can-t-i-activate-matlab-or-start-the-network-license-manager-in-a-newer-linux-environment#comment_561940
Sign in to comment.