The Road to Building a real-time (RT) kernel for my favorite OS, Ubuntu 18.04.4

[EXEC SUMMARY]
* My Ubuntu 12.04 RTAI based machine controlling CNC steppers via parallel port started not responding to keyboard and mouse and even ssh
* I went looking for the latest "late-model-os" real-time linuxcnc install and found initially only the debian 7 (wheezy)-based linuxcnc.org offering
* I dutifully installed it but was immediately put off by the human factors; not only were tools not where I had developed the habit of reaching for them (speaking now of "system admin" tools, all apart from linuxcnc) but more importantly some of them were even missing
* I discovered too that Debian wheezy is comparable in OS-years to Ubuntu 12.04; there was no modernization "gain" on that score
* I decided to take the plunge to have my cake and eat it too by rolling my own version of a late-model (18.04) Ubuntu, based on a real-time kernel (whatever that meant); this thread was meant to detail the steps
* I'll repeat here what I began with: I was encouraged by the work done by BigJohnT and RodW's encouragement ( in this thread ) that he had worked his way through it
* As I ran into trouble and reported it here, contrary opinions were received that a) it was a fool's mission to attempt because b) even a fool can follow instructions but c) he won't because fools don't read
* BeagleBrainz graciously created a "re-spin" of a Compleat Sette of deb-files for installing an unbelievably late-model version of Ubuntu w/a classy interface and loads of packages
* I installed it, and owing to my own carelessness in restoring my settings I unintentionally blew away the stepconf (or ini or hal) without realizing it
* I ran a long project and never noticed, until the crash, that by the end of the roughing pass, the gantry (twin-screw) Y-axis had lost its 0; fortunately, no nearly miraculously, it made itself known by "polishing" the top of one low-profile steel clamp, but unfortunately I didn't hear that one and the second one stood a little higher...
* Rather than try to figure out what and where I had overwritten I opted to reinstall
* ...but by that time, that window had closed
* I went back and reinstalled the recommended Debian 7 install
* ... and it does work
* ... but I'm back to where I started, waiting for the system to fail, as they all do, and wondering if there'll be a guru with a solution to hand me
* I decided my original problem might be coming from aging hardware, and although I'm not sure how to monitor the "health" of things like USB ports, one thing I could do, I thought, was at least get smart tools to be watching the hard drive.
* Umm, no, smart tools is not in debian's apt.
* No matter, deal with it later; it's a new install better, at least, upgrade all the apps, esp. the browsers
* Umm, no, wheezy has been out-of-support, says apt, since 2016, 2018, or 2019 depending on version

It has been observed elsewhere in these pages that "an old machine that's WORKING doesn't need upgrading!"
However when they start to fail, and need trouble-shooting, it would be nice to have access to useful tools; as for example, gparted, which is where I came in...
[END SUMMARY]

Finding BigJohn's thread laying out the steps for rolling your own real-time kernel in a variety of fruit flavors, I followed along with keen interest, especially since I have twice experienced my LinuxCNC machine's OS go end-of-life while I worried "how long" will I be able to keep it up?

Having run into recent "dodginess" with the USB keyboard and mouse going incommunicado, followed by the ssh daemon shutting down, I decided my precompiled Ubuntu 12.04 version with the RTAI kernel needed replacing.

I followed my normal pattern of searching for the latest all-in-one install (real-time OS + LinuxCNC package), and even went so far as to download and blast the ISO image for a Debian 7 (wheezy) install which I performed from a USB stick.

Fine. It booted. And it worked. But almost immediately I discovered that "Debian isn't Ubuntu." and I increasingly found that all my muscle memory picked up in the latter wasn't helping with the former. I yearned to have a "modern" Ubuntu-based LinuxCNC install again--something as radical as, say, 14.04 (a Giant Leap for Mankind from 12.04 I figured).

However as I read down John's post, I found testimony from Peter [PCW] that he's actually running the system I dreamed of.

Following Peter's advice to follow John's advice here , I picked the Lubuntu example (to be in the Ubuntu family), but picked my starting kernel and matching patch file from different folders of the //mirrors tree.

Following the letters perfectly (as I always do), I was rewarded with failure at the 'make' step, with a message like:
At this point I realized I was going to have to admit that I didn't quite perfectly follow: figuring "in for a penny, in for a pound," I had researched the newest 5.x kernel for which a RT patch was available and picked that one (5.4.26) for my first try--I mean to say, if it had worked, I'd be in tall cotton right about now.

Unfortunately, it came with not one patch file, but a standalone .patch AND a .tar.gz of others. As John's method didn't cover applying multiple patches (which BTW I'm guessing will involve the 'series' file included with them and another utility named 'quilt'), I just applied the one. I figured my approach was probably doomed from the start anyway, but I'd ride it to the final canyon jump. But I was stopped at the 'make' fail.

Currently, I am following the steps with the same version of Ubuntu as in the Lubuntu example, and am in about the middle of the 'make' step--which means I've probably got another half-day or so before it finishes.

Presuming it fails (I've been diagnosed with 'no luck') where could I look for make errors to cause the making of vmlinux.o to fail?

If all the patches in a series aren't applied you wont have a great deal of luck.
One thing that isn't made clear is to make sure the debug options are turned off or you may end with a kernel you can't boot.

Depending on the age of the machine you are working with, Debian Wheezy with RTAI maybe your best option. A lot will depend if your intended computer is 64 bit compatible. If it's taking as long as you hint to compile the kernel you may not have a machine that is the best candidate for a modern kernel.
the machine I use for building kernels can build the kernel & modules and package them into debian packages in under 30 minutes, 26 minutes is about the average.


If you can post the specs of the computer you intend to use help is at hand.

@BeagleBrainz
This is probably the quickest way to spec it. The machine is dedicated to running LinuxCNC--I've got a dozen other machines running Ubuntu 18 to use when this one is busy. It uses a parallel port with a Chinese mock Mach3-style controller.


@tommylight
...which brings me to why I'm passing for the moment on the much easier options, but with the same gratitude for their existence as everyone else.

#1. I want to have my LinuxCNC platform in the same adminstration fold with all the rest of my machines. I'd prefer to be in the same paradigm when jumping from machine to machine.

#2. I (really) think it's time I try to build my personal kernel--even if it's only aping someone else's...

#3. I'd like to know why in the world it can't be done on this machine, or alternatively that I can follow directions, I can compile and run a real-time kernel, only it sucks on this machine.

With luck (but see preceding diagnosis), I'll get the experience needed to build the right one on a right machine.

Here's the error msg from the attempted 'make' step of an Ubuntu 5.0.14 kernel:
I ran it as:
% date > START; make; date > STOP; cat ST*
and learned that it took four hours. (Firefox was open with four tabs.)

At first search, Error 137 might be an out-of-memory error.

Oh.

Even if that's not true, it does suggest that "compiling" may require a more powerful machine than simple "running" an app.

Already copying to one of those "other" machines I was so proud of earlier.

Mint 19.2 uses the same repos as Ubuntu 18.04 ie: bionic

For the machine you intend using I’d suggest running Mint 19.2 with XFCE desktop and the RTAI kernel. This will get you to a stage were everything is ready to setup a config in the time it takes to boot, install the system and reboot. This will take about 30 minutes or so.
Compiling a RTAI kernel is a bit more involved than a RT_PREEMPT one. And the one you want for a Parallel Port is RTAI.
Administration wise most Debian\Ubuntu systems are pretty similar, the big difference is the Desktop environment you use. Each one has it’s own particular utilities.
One thing I have found with lubuntu is for some reason xscreensaver has been left out and this causes problems when the system blanks the screen, you can’t get back in without a reboot.
If you are still determined to build your own kernel search the forum for “RTAI packages available for testing” thread and that should have a link to andy’s github browse through that and there are instruction on how to build a kernel. Mind tho it is for a specific kernel and the recommended one.
Or linuxcnc.org/temp has prebuilt packages.
But at least download a Mint XFCE RTAI image boot that and run the latency test from the live session to see if you are in the ballpark latency wise.
If you have used Ubuntu with a XFCE desktop it will feel familiar.

@BeagleBrainz

I'll do that search and do the follow up re-search--but of course while I've been waiting for the make to finish on the other, faster, Ubuntu machine, I decided to rummage around the new 18.04 installed on the LinuxCNC controller and, you know, "straighten up" a few things.

So now, I find I've already installed a number of packages (esp. sshd so I can get into it remotely) to make me reluctant to replace it...

Thanks for the reminder about needing RTAI for the parallel port; it had completely slipped my mind. So my current compile attempt is already doomed. (Oh! The make just finished on the faster machine: 5 hr 20 m. But it did succeed, so I can move on to the next steps.)

As for the differences between Debian and Ubuntu, the very first util I reached for, gparted, to make some room on my HDD for the new OS, wasn't in the Debian rollup, and rather than just installing it, I decided I didn't want to learn any more differences, but would try going the straight Ubuntu route.

Some day, when my one of my grown grandchildren asks me, "Granpa, did you ever build a kernel?", I'd like to be able to look them in the eye and say, "Yes. Yes, I did."

("Still, in the end, two years after I started, I had to buy an entirely new set of hardware when I had a perfectly good set of older stuff that would have worked if I'd've just installed one of the perfectly fine prebuilt images, but my life has been filled with stuff like that. Did I ever tell you about investing in 'irradiated food?'")

You know Debian and Ubuntu use the same tools to install packages ?
2 minutes on google would have saved a whole lot of time and you would be up and running by now.
I’m not trying to make light of your efforts but I think you may be heading for a world of hurt.
If Ubuntu allowed it I would have made you a custom install disc to suit, I have it down to almost a fine art now, but the Ubuntu people are quite protective about their branding. The guys at Linux Mint are protective as well but have given permission for remastered images pre installed with linuxcnc to be made without having to remove all of the Mint branding, as long as it is clear it is not an official Mint release. So I feel it’s a good reason to support Mint as a distro.
Don’t be afraid, anything Ubuntu can do Mint can do, most of the Mint packages are from the Ubuntu repos.