Debian Jessie Install

I do not wish to run version 2.7 on this particular computer. I have loaded my missing reported dependencies and had to temporarily remove libboost-python1.55.0 to make installation of version 1.49 happy. I was able to load uspace and Synaptic Package Manager reports that I have linuxcnc-uspace 1:2.8.0~pre1.1249 installed. I assume this is correct for running the 2.8 development version on jessie. The v2.8 is installed and compiled properly. I ran into the new requirement for one additional step to allow the . scripts/rip-environment / linuxcnc /path to configure file/ steps to work. I don't fully understand what I'm supposed to do here. See below.

"Refusing to run as root without fallback UID specified
To run under a debugger with I/O, use e.g.,
sudo env RTAPI_UID=`id -u` RTAPI_FIFO_PATH=$HOME.rtapi_fifo gdb rtapi_app"

I have tried "sudo env RTAPI_UID=`id -u` gdb /home/john/linuxcnc-dev/bin/rtapi_app" in a seperate terminal window to make the debugger happy but linuxcnc dies like this:

john@CNC1:~/linuxcnc-dev$ linuxcnc /home/john/cnc-configs/cnc1-dev/cnc1-dev.ini
LINUXCNC - 2.8.0~pre1
Machine configuration directory is '/home/john/cnc-configs/cnc1-dev'
Machine configuration file is 'cnc1-dev.ini'
Starting LinuxCNC...
Found file(REL): ./cnc1-dev.hal
./cnc1-dev.hal:6: execv(/home/john/linuxcnc-dev/bin/rtapi_app): Permission denied
./cnc1-dev.hal:6: waitpid failed /home/john/linuxcnc-dev/bin/rtapi_app trivkins
./cnc1-dev.hal:6: /home/john/linuxcnc-dev/bin/rtapi_app exited without becoming ready
./cnc1-dev.hal:6: insmod for trivkins failed, returned -1
Shutting down and cleaning up LinuxCNC...
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more information in the log:
/home/john/linuxcnc_debug.txt
and
/home/john/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
john@CNC1:~/linuxcnc-dev$

I think I have my last problem fixed. When I changed owner of the development folder it appears that it only changed the top level folder and the files in that folder and not the other sub folders. I had used nautilus to do that. The debug messages are really nice. Now all I have to do is install the 5 axis version of gmocappy since it died when complaining of the five axis in my .ini file and move on.

I was running a ping test to see how fast my 7i80 board was able to respond from a newly installed Debian Jessie 8.2 install with my Realtek RTL8169 PCI card and found it to be around 0.87ms average on a Dell T3500 dual processor machine using AMD64. I find this speed to be rather poor.. After this I downloaded the Linux driver from Realtek for the card and followed the instructions on how to change the stock kernal network module that controls loading this driver. The ping response time dropped down to 0.015ms which made me happy. Then I installed the RTpreempt kernal v4.1.0-1 for AMD64 and the kernel grabs the original 8169 driver that comes with Debian 8.2 and the ping time went back to about 0.87ms. Thus the kernel is not configured optimally. Since the "make kernel module" function and other processes of the replacement driver install routine are not compatible with the real time kernel I wonder if there is a way to do this. I do not wish to buy replacement NIC cards on a gamble they they will cure this problem but replacing the cards with known cards not to have this issue is likely the best cure. If someone can anyone supply a make and model of a card that has been proven not to have this issue it would be much appreciated.

RTK8169s are normally OK (as are the 10/100BT 8139s)
I've done lots of testing with RTK8169/8111 chips on motherboards and they work fine
A 0.87 ms ping time indicates some rather major pathology but a .015 ms 7I80 ping time is
not likely either so may also be an indication of trouble

In general I would choose the motherboard Ethernet port for real time and add a PCI/PCIE/USB
Ethernet interface for general network use

In my experience MB ports with RTK 8169s, 8168s, or 8111s are fine as are all intel MACs
(intel MACS need to have their RX interrupt coalescing option turned off )

Avoid Broadcom or Atheros Ethernet MACs like the plague

BTW if you are using ping to check realtime network performance you need to set the priority of the ping command
otherwise lower priority processes can interrupt the command and you will have occasional long ping times:

If my system gave me that kind of figure I would be extremely happy. I did try to to load the realtek driver into the real time kernel before but it would not allow it to be done. I think that this may be associated with a bigger problem as mentioned. I have been looking at the systemctl log and it indicates that I have a problem with loading kernel system modules and wonder if this is the main reason why I'm having such a hard time getting things to work properly. The . scripts/rip-environment - linuxcnc refuse to run under root. I don't know how to interpolate what the below info is trying to tell me other that there is a serious problem and that I have no idea on how to fix it.

root@CNC1:/home/john/Desktop# systemctl -l status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
Active: failed (Result: exit-code) since Fri 2015-11-27 10:20:37 AKST; 36min ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 269 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
Main PID: 269 (code=exited, status=1/FAILURE)

Nov 27 10:20:37 CNC1 systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Nov 27 10:20:37 CNC1 systemd[1]: Failed to start Load Kernel Modules.
Nov 27 10:20:37 CNC1 systemd[1]: Unit systemd-modules-load.service entered failed state.
root@CNC1:/home/john/Desktop#

Part of a UNIT FILE listing that I made earlier gave me the below info which I suspect may be relevant:

runlevel0.target disabled
runlevel1.target disabled
runlevel2.target static
runlevel3.target static
runlevel4.target static
runlevel5.target static
runlevel6.target disabled

You should not run (or need to run) the rip environment script as root

I have installed linuxcnc uspace from source under wheezy, ubuntu 12.04, ubuntu 14.04 and linux Mint 17.x
and have not had any serious issues other than random missing libs and dueling tcl versions,
I will try Jessie when I get a bit of free time.

This is what I believe to be correct based on many days of frustration. I have had several missing dependencies that appear to be at least part of my problem as my hal file executed just past the point were my 7i80 board had a solid connection and was happy. I think at that point in time in started talking to the rtapi_app and also likely halui.

My issues appear to be related to the dependencies that gmocappy depends on. When standard linuxcnc installation guidelines are followed as in the past it may not be possible to install all the dependencies currently required to run gamocappy on jessie. My missing depends were all found to be related to those required by gmoccapy. My only missing one right now is libboost-python-dev1.49.0-4 which will not install because uspace which is installed runs on version 1.55. this present an immediate conflict.

So my problem appears to be mainly caused with the older dependencies that gmocappy depends on that are not supported by the repositories for jessie. The depends that have given me the most problems have been libboost-python1.49 and its dev version, libnomeprint , libgonomeprint2.2, libgnomecups1.0, gccxml_0.90, libgcrypt11_1.5.0-5 and libgnomeprintui2.2-dev. I may have missed one but these are the main ones. Forgive my spelling errs.

It looks to me that in order to run gmocappy on jessie these depends need to be installed very very early during a jessie system build. It would be so nice if there was a .deb file that contained all these older depends for gamocappy to load unto jessie system build time. I wonder if it is possible to pull these depends out of a wheezy based system for transfer into jessie for installation. Looking for them on the Internet is extremely time consuming. I will take a break and start a new build now that I have a good idea what is needed for gmocappy in jessie that is hard to find. I hope I don't miss one that turns out later not to be able to be installed.

I have the exact same problem when I try and run gmocappy under jessie and Preempt-RT. I hope someone can post a step by step solution as I don't have the knowledge yet to start altering install orders or package definitions.

I ended up with a working system but did not feel secure since it turned out to be a none standard. So I reloaded everything to insure it would be as stable as possible.

With the link info Norbert gave me in the gmoccapy thread and taking some additional steps I have successfully loaded both linuxcnc-dev (2.7) and linuxcnc-mirror (v2.8) on jessie. Each one runs fine using run in place with my .INI, Hal and associated files with the gmocappy gui. linuxcnc-dev will install real time 3.16.0-4. You have to have git installed as per Norberts to clone these into your /home/user/ directory.

I right after debian jessie was loaded. I did modify the /ect/sudoers file to give me full disk access rights when needed with the sudo cmd. Using "su" all the time may give file ownership problems and other problems depending what is being commanded. Thus sudo is much more desirable at times since it gives super cow powers just to the current cmd line. I Also made sure all the source repository files are in /ect/apt/sources.list and the backports and nonefree in /ect/apt/sources.list.d/ lists files. Keyring function must be installed to get the key files for the linuxcnc and buildbot repositories. I also set up the /ect/apt/interfaces file for my network connections manually. Debian appears to have a bad habit of renaming the eth ports by it self on a random bases at boot up at times without this being done.

The most difficult thing to find is the linux-image for upgraded real time. I use v4.1.0-1 but do not have the header common file for that version so the header file will not install. But that is only needed to make some kernel changes. I do need to load new firmware into the kernel for my network card that will talk to my ACRA milling machine.

I use the v2.7 linuxcnc-dev version with the gmoccapy gui in five axis mode. The v2.8 linuxcnc-mirror dev version is limited to four axis with gmoccapy right now and loaded it just to keep and eye on current development work. It took about three hours to get everything set up. Do a "apt-get build-dep linuxcnc" while in the top folder of the linuxcnc-dev install to install the dependencies not supplied with the linuxcnc-dev cloned package . I installed uspace v2.8 just before compiling linuxcnc-dev. As I recall about three more dependency issues where found during the last step (the compile process). These were easy to cure since the message in the terminal window tells what to do.

The first time I ran the program with these normal . ./scripts/rip-environment followed by linuxcnc.
After the that I run it in place by pointing it to my ini file which for me is: linuxcnc /home/john/linuxcnc-dev/configs/cnci/cnc1.ini

Initially the best way to check out the initial install is to point the load point to one of the ini files in the: linuxcnc /home/user/linuxcnc-dev/configs/sim/ folder. user = your name. Change all as required.