New and Working RTAI debs for 2.9

Newby Linux user, successful install(well software starts anyway!) exactly as Bari' instructions. I did have to purge the previous RTAI version.
Now to Ethercat, do I need to recompile for Ethercat servo, or is that package part of what I have just installed?

Well snap, jealous of those which .279 works. Doesn't seem to like my lenovo & 4ax milling machine for some reason
Reverting back to 5.4.258 sorts it in my case. 

Observations:
1. Upgrade from .258 -> .279 went smooth. RTAI starts and everything. (That's all good).
2. The isocpu grub init is indeed mandatory. Does not start otherwise. (I personally don't care!)
3. On a PC cold boot I can; start linuxcnc, home the machine, jog. (That's all good).
4. I do however get a new RTAPI ERROR. I didn't had this with 5.4.258. (see visual). 
5. If I close linuxcnc, it's impossible to start it up again. Needs a full machine reboot. (see attached logs/traces). 



 

Hey Mecanix, are you able to start and close the latency histogram without rebooting? If not, try a more simple test. The RTAI testsuite is built-in and you can try running that as well.

It's: /usr/realtime*/testsuite/run (Ctrl+C to cancel)

Good and bad news. Bad news first; I've put back 5.4.258 temporarily. I really terrorized myself yesterday when I saw it broken (sweats man lol), knowing I desperately need this mill all of this coming Saturday and Sunday (important project). And so the bad news is I won't be able to test this out, at least not before the coming week.

The good news is; I'll surely reinstall 5.4.279 and give it another go. Let's get to the bottom of this, if not only to improve the making of RTAI. I'll update in 4~5 days max.

Side note. I've just placed a Dell Optiplex 780 w/ a built-in parport on order to backup with. That way I can test on real hardware before making changes to the production-ready kit - yesterday's self-terrorism just can't happen again.

Thanks Mecanix for helping us test. The 5.4.279 kernel shouldn't cause any regressions as it's all just backported fixes, and the respective LinuxCNC package for it restored some files I shouldn't have deleted in the earlier Debian package, so if anything it should be better and not worse, and this is a run-on-sentence.

NTULINUX wrote:

 if anything it should be better and not worse, and this is a run-on-sentence.

Hi NTULINUX. I have no doubt in that statement, doubting my knowledge/skillset is in upgrading linux systems rather. Mind you I was able to use the 5.4.279 release full featured. Only bug was a new timeout error on starting, and ofc not being able to restart lcnc if closed - a full system reboot was required. 

To begin with I have no idea how to clean a previous RTAI installation (if required?), or whether it's okay to simply "upgrade over" which is what I've done.

Additionally (less inspiring!). I've completed a clean Debian 12 install on my newly acquired Dell Optiplex. All updated, all drivers functional, no errors, everything's happy. Then proceeded to installing the RTAI 5.4.279 debs (module, headers, image, then lcnc), to have nothing showing up when starting linuxcnc. It reports that module is not loaded, although re-installed the deb twice now

Not entirely sure what I've done to RTAI to deserve all that, we used to be good friends!!

@NTULINUX. Note that I am not stranded in any way. I have a fully functional and production-ready RTAI kit (5.4.258, lcnc 2.9.2). Couldn't be happier about it and so kudos to the work that went into this!

You know what we're missing though? A tutorial on "How to compile a RTAI Kernel, module and Lcnc". Just so that workload could be offloaded off you, Bari, Andi, and friends. Personally I'd be willing to give that a trial with e.g. the newly released 2.9.3 or perhaps even 2.10.xxx as tests.

Prolly beyond most-of-us skills though, let us know what you think about this idea.

Lots of work to get it done correctly. Look at the challenge many people face just trying to install the debs.

Bari wrote:

Lots of work to get it done correctly. Look at the challenge many people face just trying to install the debs.

I have mentioned on the mailing list that because RTAI Debs exist, it would be quite easy to build a RTAI ISO  by forking our live installer.
Its not that much harder to get the installer build process to compile the debs

Compiling the kernel is easy, where the skill comes in is getting the config correct.
And be thankful it's not the 90's and you're not having to do it on a 486 with 16MB ram.

Joking aside, it's probably best to have one set of debs for the kernel from a known source. Debugging is going to be, I'd like to say easier, rather than having user built kernels that maybe a little different, due to a change in config. Or how gcc's mood was on that day.

After coming from Slackware in the last 4 or so years to debian\ubuntu and going thru "RPM Hell" back in Ye Olden Days, installing packages via debs is pure bliss. I don't want to think about how long it took to install gitlab on a Slackware 14.2 server, just about every dependency had to be compiled. On Ubuntu its a one liner.

Just a suggestion Rod, pin grub so it doesn't get updated. Because somewhere some how it will make someone cry when they go to update it on a UEFI system with an RTAI kernel.