• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ICEcube2 licensing on Linux where network interface is not eth0 (solution)
#1
Background:
While trying to build the demo project for the CU using the 1.0.3 version of the Alchitry IDE and IceStorm, I had found the same .sdc constraint issue later mentioned by kitlaan in the General Questions forum.  Seeing that the IDE was looking to arachne-pnr instead of nextpnr, and that nextpnr had a qt GUI dependency that I didn't want to deal with, falling back to ICEcube2 looked to be the solution.  ICEcube2 did not seem to recognize the free license.

The system in question here is a Fedora 28 64bit, though it does apply to other distributions as well.


Problem found:
ICEcube2 want's it's license bound to the MAC address of the network device eth0 when on Linux.

Some modern Linux systems name the network interfaces based upon the slot, or more accurately which data bus it connects to the CPU through, such as enp5s2.  This is great on server systems with multiple wired interfaces, as the kernel could swap the interface that eth0 and eth1 were bound to under some circumstances otherwise.  However useful this may be, it doesn't really serve much purpose on systems with one interface.


Solution found:
Adding two parameters ( net.ifnames=0 biosdevname=0 ) to the kernel boot command as per this StackExchange article solved the problem.


Extra notes:
Comments in the article also mention it working for versions of CentOS and Ubuntu.

If the system was set up with a static IP address in it's network settings, then that will have to be configured again as well.
Also check firewall configuration if the system has rules based on interface names.

If the system does not have a standard wired interface at all, then other methods may be necessary.  Renaming an interface using udev rules instead for example.

On the Fedora system running Gnome desktop, for some reason I was unable to lock the screen after applying this fix.  The dconf setting for org.gnome.desktop.lockdown disable-lock-screen had toggled to true for unknown reasons and needed set back.  This change didn't make sense and may have been coincidental.
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)