Machinekit on BBB - long boot times with PREEMPT kernel

[Malte Schmidt]

Dear all,

this may be the wrong forum but my questions seem to fit neither perfectly the Machinekit nor Beaglebone forums

I've been following this manual to setup Machinekit with Preempt_RT on a BBB. 

https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/

Resulting in a Strech installation with preempt_rt kernel v4.4. With this kernel I'm getting long-long boot times of ~2-3 minutes. In the "default" installation this seems to be related to generic board startup service:

The output of systemd-analyze blame with 

         51.582s dev-mmcblk1p1.device

         47.793s generic-board-startup.service

          8.600s NetworkManager-wait-online.service

          4.290s systemd-udev-trigger.service

          ...

When I disable this serivce I'm getting thisd-analyze blame

    1min 30.559s dev-mmcblk1p1.device

          9.837s NetworkManager-wait-online.service

          4.739s systemd-udev-trigger.service

          ...

And I can't make something out of the critical path analysis which shows:

graphical.target @55.127s

└─multi-user.target @55.121s

  └─getty.target @54.807s

    └─serial...@ttyGS0.service @54.785s

      └─dev-ttyGS0.device @54.762s

This issue does not seem to exist with v4.14 or v4.19 but for these kernels I'm not able to get the additional firmware images. i.e. 

(sudo apt install linux-firmware-image-`uname -r`)

fails. 

So I went back to v4.4

My var log messages shows this (excerpt, full messages attached)

Dec 26 18:43:30 beaglebone kernel: [    1.876960] of_cfs_init: OK

Dec 26 18:43:30 beaglebone kernel: [    1.882563]  remoteproc0: remote processor wkup_m3 is now up

Dec 26 18:43:30 beaglebone kernel: [    1.882629] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 0x193

Dec 26 18:43:30 beaglebone kernel: [    1.890647] Freeing unused kernel memory: 744K

Dec 26 18:43:30 beaglebone kernel: [    2.382866] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy ava

<snip - repeated a few times>

Dec 26 18:43:30 beaglebone kernel: [    2.409655] random: udevadm: uninitialized urandom read (16 bytes read, 2 bits of entropy available)

Dec 26 18:43:30 beaglebone kernel: [   52.999288] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)

Dec 26 18:43:30 beaglebone kernel: [   53.569319] ip_tables: (C) 2000-2006 Netfilter Core Team

Dec 26 18:43:30 beaglebone kernel: [   55.098407] EXT4-fs (mmcblk1p1): re-mounted. Opts: errors=remount-ro

Dec 26 18:43:32 beaglebone kernel: [   62.508226] nf_conntrack version 0.5.0 (7787 buckets, 31148 max)

Dec 26 18:43:32 beaglebone kernel: [   62.766767] random: nonblocking pool is initialized

Which seems to be related to this: https://github.com/systemd/systemd/issues/4167

But I'm not sure if this is really the root cause.

I got three questions now. 

a) are there any hints / clues what to do regarding the boot time? Should I try and post this question to the Beagle Bone forum?

b) is trying to resolve the issues with linux-firmware-image and using kernel 4.14 or 4.19 the recommended approach

c) is using the preempt_rt kernel still the preferred / recommended way of setting up a new system on a BBB?

Any hints would be appreciated.

BR,

Malte

[schoo...@gmail.com]

I don't know if this is related  and know nothing specifically about BBB, but the line
1min 30.559s dev-mmcblk1p1.device
raises some suspicions.

The newer linux kernels are prone to hanging for 1min 30 secs where there are problems with a 'start job'
which usually relates to mounting a drive.

What usually happens is often related to the 'resume / suspend to disk' capability of the kernel, whether you use it or not.

Take this scenario:
You install a distro on a spare partition.
The Debian install program will format the partition you have chosen plus the swap partition.
However the reformatting of the swap partition also changes the UUID

Next boot of your original partition, the UUID in /etc/fstab for the swap partition is wrong and you
get a 90 sec wait with the 'A start job for dev-disk-by-uuid-xxx' message

So now you adjust your fstab file to point to the right UUID and reboot

On booting there is another wait whilst the kernel repeatedly tries to access the UUID it holds for Resume (which is the old swap partition UUID)

You then need to go to /etc/initramfs-tools/conf.d/resume and change the UUID in that file for the new one for the swap partition
Then you need to run 'makeinitramfs' for each bootable kernel, to create a new ram image which has the correct UUID for swap in it

THEN your original partition will boot quickly.

I would study the elements described above to make sure that the device designation matches the UUID held in fstab / initramfs-<kernel-version> etc etc

If you have introduced a new kernel whose initramfs is not matched to your system, that is a possible cause.

Either way, would be interested to hear the answer when you find it

regards

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Bas de Bruijn]

On 29 Dec 2018, at 09:31, "schoo...@gmail.com" <schoo...@gmail.com> wrote:

I don't know if this is related  and know nothing specifically about BBB, but the line
1min 30.559s dev-mmcblk1p1.device
raises some suspicions.

The newer linux kernels are prone to hanging for 1min 30 secs where there are problems with a 'start job'
which usually relates to mounting a drive.

What usually happens is often related to the 'resume / suspend to disk' capability of the kernel, whether you use it or not.

Take this scenario:
You install a distro on a spare partition.
The Debian install program will format the partition you have chosen plus the swap partition.
However the reformatting of the swap partition also changes the UUID

Next boot of your original partition, the UUID in /etc/fstab for the swap partition is wrong and you
get a 90 sec wait with the 'A start job for dev-disk-by-uuid-xxx' message

I got the exact situation a few months ago when installing Buster along side Stretch on my laptop. When booting Stretch again it was looking for the ‘newer’ UUID of the swap partition.

Changed that uuid in fstab file and problem was solved.

[Malte Schmidt]

Thanks all. I will give that a try

[Malte Schmidt]

I changed fstab to contain UUID and uncommented uuid in uEnv.txt. I don't think this is it. 

Kernel boots with the commmandline containing the UUID for root. UUID set in fstab but still no improvement :-(

machinekit@beaglebone:~$ uname -a

Linux beaglebone 4.14.79-ti-rt-r84 #1 SMP PREEMPT RT Tue Nov 13 20:33:45 UTC 2018 armv7l GNU/Linux

machinekit@beaglebone:~$ cat /proc/cmdline

console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=UUID=94daacb3-de67-41a5-8087-c68a02c7e893 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet

machinekit@beaglebone:~$ cat /etc/fstab

UUID=94daacb3-de67-41a5-8087-c68a02c7e893 /  ext4  noatime,errors=remount-ro  0  1

debugfs  /sys/kernel/debug  debugfs  defaults  0  0

machinekit@beaglebone:~$ systemd-analyze blame

     1min 4.570s generic-board-startup.service

         20.171s dev-mmcblk0p1.device

          5.046s systemd-udev-trigger.service

machinekit@beaglebone:~$ blkid

/dev/mmcblk0p1: LABEL="rootfs" UUID="94daacb3-de67-41a5-8087-c68a02c7e893" TYPE="ext4" PARTUUID="e086444d-01"

/dev/mmcblk1p1: LABEL="rootfs" UUID="ab7cd6a9-12eb-434d-b05b-3a51654aec76" TYPE="ext4"

[schoo...@gmail.com]

OK, it was just a thought.

The 4.14 kernel seems to be problematic.
There are quite a few references to problems on RPi forums as well as some on this forum, where
users went back to the 4.4 or 4.9.

[mugginsac]

Did anyone find an answer to this problem?

[Malte Schmidt]

Not yet.

I asked the same question here:

https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-black/wEv-JGvom8U

and was suggested to go with 4.19. I tried this and it does indeed boot fast. The current issue is that I lack the PRU drivers (rproc) for this kernel. My next try would be to investigate if the rproc drivers can be replaced by the UIO version. 

... and I totally don't know if this approach makes sense at all as I'm far from exactly knowing what I'm doing / using and how rproc or UIO differ ....

It's on my todo list but will be continued in a few weeks.

Off topic: The machine works meanwhile with machinekit and BBB and touchy as UI: https://forum.zerspanungsbude.net/download/file.php?id=188369

BR 

Malte

[Charles Steinkuehler]

On 2/4/2019 1:15 AM, Malte Schmidt wrote:
> Not yet.
>
> I asked the same question here:
> https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-black/wEv-JGvom8U
>
> and was suggested to go with 4.19. I tried this and it does indeed boot
> fast. The current issue is that I lack the PRU drivers (rproc) for this
> kernel. My next try would be to investigate if the rproc drivers can be
> replaced by the UIO version.
> ... and I totally don't know if this approach makes sense at all as I'm far
> from exactly knowing what I'm doing / using and how rproc or UIO differ ....

Have you tried configuring U-Boot to load the UIO driver?

Robert tries to keep this working with all kernel flavors so you
should just have to set:

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

Details:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

Sadly post v4.18.x the uio-pru driver on mainline is broken for
"uio".. Around the same time Roger from TI posted his first pass at
remoteproc for mainline, so I've been focusing on that instead.

RFC 2 was just posted today:

https://marc.info/?l=linux-omap&m=154929024724527&w=2

PS, last week another user asked about uio on v4.19.x too.. So we have
2 users asking about it.. Last i looked at it we need to revert all
the uio changes back down to v4.17.x... I don't think i'll have time
to personally hack this up, (projects for Embedded World). I think
zmatt on beagleboard irc was going to look at it.

Regards,


--
Robert Nelson
https://rcn-ee.com/

[Charles Steinkuehler]

On 2/4/2019 12:32 PM, Robert Nelson wrote:
> On Mon, Feb 4, 2019 at 6:36 AM Charles Steinkuehler
> <cha...@steinkuehler.net> wrote:
>>
>> On 2/4/2019 1:15 AM, Malte Schmidt wrote:
>>> Not yet.
>>>
>>> I asked the same question here:
>>> https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-black/wEv-JGvom8U
>>>
>>> and was suggested to go with 4.19. I tried this and it does indeed boot
>>> fast. The current issue is that I lack the PRU drivers (rproc) for this
>>> kernel. My next try would be to investigate if the rproc drivers can be
>>> replaced by the UIO version.
>>> ... and I totally don't know if this approach makes sense at all as I'm far
>>> from exactly knowing what I'm doing / using and how rproc or UIO differ ....
>>
>> Have you tried configuring U-Boot to load the UIO driver?
>>
>> Robert tries to keep this working with all kernel flavors so you
>> should just have to set:
>>
>> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
>>
>> Details:
>> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options
>
> Sadly post v4.18.x the uio-pru driver on mainline is broken for
> "uio".. Around the same time Roger from TI posted his first pass at
> remoteproc for mainline, so I've been focusing on that instead.

Looks like this just got fixed:

https://groups.google.com/forum/#!msg/beagleboard/poKd5tCRD04/Zjc1hNxLAwAJ

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Mon, Feb 11, 2019 at 12:25 PM Charles Steinkuehler

Yeap, Matthijs fixed it, the new "4.19.15-ti-rt-r8" should be
available in a few hours..

[mugginsac]

So, does that mean there will be a new Stretch-Machinekit image, or is it just the new kernel for the moment?

[Robert Nelson]

On Mon, Feb 11, 2019 at 4:39 PM mugginsac <mugg...@gmail.com> wrote:
>
> So, does that mean there will be a new Stretch-Machinekit image, or is it just the new kernel for the moment?

Please give this a shot:

https://rcn-ee.net/rootfs/bb.org/testing/2019-02-11/stretch-machinekit/

ps, let me know what else you want installed in it by default.

[Condit Alan]

Robert,

I tried updating the kernel first on my other image, but when I tried to start machinekit I got a message unable to setuid need sudo makesetuid. So I am trying the image that you gave me the link to.

I can invoke "ssh -Y machi...@beaglebone.local” but when I try to start machinekit I see this:

machinekit@beaglebone:~$ machinekit

MACHINEKIT - 0.1

application-specific initialization failed: no display name and no $DISPLAY environment variable

Error in startup script: invalid command name "image"

    while executing

"image create photo -file $f/$i.gif"

    invoked from within

"if [file exists $f/$i.gif] {

            return [image create photo -file $f/$i.gif]

        }"

    (procedure "linuxcnc::image_search" line 7)

    invoked from within

"linuxcnc::image_search machinekit-wizard"

    invoked from within

"set logo [linuxcnc::image_search machinekit-wizard]"

    (file "/usr/lib/tcltk/linuxcnc/bin/pickconfig.tcl" line 31)

So I did "sudo apt-get install xorg openbox”, and reboot.

Now I get:

machinekit@beaglebone:~$ machinekit

MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex'

Machine configuration file is 'Xylotex.ini'

Starting Machinekit...

Warning - /usr/libexec/linuxcnc/rtapi_app_posix not setuid

'sudo make setuid' missing?

rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288

rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_posix --instance=0

/usr/bin/realtime: line 237: /usr/libexec/linuxcnc/rtapi_app_posix: No such file or directory

rtapi_app startup failed; aborting

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

io started

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd loadusr io started

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

Shutting down and cleaning up Machinekit...

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

Warning - /usr/libexec/linuxcnc/rtapi_app_posix not setuid

'sudo make setuid' missing?

Cleanup done

Machinekit terminated with an error.  For simple cases more information

can be found in the following files:

    /home/machinekit/linuxcnc_debug.txt

    /home/machinekit/linuxcnc_print.txt

For other cases get more meaningfull information by restarting after

    export DEBUG=5

and look at the output of:

    /var/log/linuxcnc.log

    dmesg

When looking for errors, specifically look for libraries that fail to load

by looking for lines with 'insmod failed' as per example below.

insmod failed, returned -1:

do_load_cmd: dlopen: nonexistant-component.so: cannot open shared object file:

No such file or directory

For getting help, please have a look here: www.machinekit.io/docs/getting-help/

Alan

[schoo...@gmail.com]

Check what is installed.

The error re not setuuid is misleading, the main question is why are you trying to use rtapi_app_posix, it should be rt-preempt

[Condit Alan]

Schooner,

That was running an image from Robert C Nelson to test out the fixes in a new kernel.

I have an image that has been running OK except for horrendous boot times. I updated the kernel with

4.19.19-bone-rt-r21 and now I get this:

machinekit@beaglebone:~$ machinekit

MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex'

Machine configuration file is 'Xylotex.ini'

Starting Machinekit...

Warning - /usr/libexec/linuxcnc/rtapi_app_posix not setuid

'sudo make setuid' missing?

rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288

rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_posix --instance=0

/usr/bin/realtime: line 237: /usr/libexec/linuxcnc/rtapi_app_posix: No such file or directory

rtapi_app startup failed; aborting

halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

So can you tell did I choose the wrong kernel???

I used this from elinux:

4.19.x All BeagleBone Variants + RT
sudo /opt/scripts/tools/update_kernel.sh --bone-rt-kernel --lts-4_19

Alan

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/sOWj5I7fVpo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

[schoo...@gmail.com]

I know nothing about the BBB images generally and this one in particular.
I don't know if the script you ran, even looks in the right place for the new kernel.

I think you need to actually test Robert's new image, not hope you can update your old one.

What I do know, is that the most common cause of this error, is running a posix kernel with only rt-preempt packages installed.

The 'rtapi_app_posix not setuid' in this case means it tested if it was setuid and that failed,
but that was because it did not exist at all, as per the later error.

If you have /usr/libexec/linuxcnc/rtapi_app_rt-preempt on your system and were running what was recognised as a
rt-preempt kernel, it would try to use that.

[mugginsac]

cd  /usr/libexec/linuxcnc
machinekit@beaglebone:/usr/libexec/linuxcnc$ ls
flavor  inivar  pci_read  pci_write  rtapi_app_rt-preempt  rtapi_msgd

machinekit@beaglebone:/usr/libexec/linuxcnc$

So I have rtapi_app_rt-preempt on the uSD. So why is it reporting the other error message.

Alan

[mugginsac]

I buily a new uSD using the image that Robert sent me the link for.

I ran uname -r and it reports 4.19.15-ti-rt-r8.

I am guessing that the rt stands for rt-preempt???

I ran machinekit:

machinekit@beaglebone:~$ machinekit
MACHINEKIT - 0.1
Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex'
Machine configuration file is 'Xylotex.ini'
Starting Machinekit...

rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288

rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0
rtapi: no service UUID (-R <uuid> or environment MKUUID) present

rtapi_app startup failed; aborting
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
io started
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd loadusr io started
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
Shutting down and cleaning up Machinekit...
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present
halcmd: no service UUID (-R <uuid> or MACHINEKIT_INI [GLOBAL]MKUUID) present

[schoo...@gmail.com]

You are going to have to do what it says at the end of the printout to narrow it down.

At least it is now a new error:-P

[schoo...@gmail.com]

If you added the new kernel to a working image and had this problem, then tried the new image with the new kernel and had the same problem,
it tends to point squarely at the new kernel.

Either it is not a rt-preempt kernel, or it does not give off the right signals.

The second line in your dmesg is way short of what would be expected from an x86_64 rt-preempt kernel
You just have SMP
I would expect SMP RT PREEMPT

The kernel name having 'rt' in it irrelevant, as the kernel builder can attach `-giraffe` prefix, but that does not make it one.

If you want to look in src/rtapi/ and grep 'flavor' you will see where the determination is done.

The MKUUID issue was probably caused by using a new version of machinekit on an old image base which did not contain 'genuuid'

The root cause is that the new kernel is not recognised as rt-preempt and flavour defaults to posix.

Since you only have rt-preempt binaries etc. it errors.

On 14/02/19 22:37, Condit Alan wrote:

I built another fresh uSD from the image I got from Robert Nelson, I installed ssh, xorg, openbox, and uuid-runtime. I tried running Machinekit again. And it is back to trying to load rtapi_app_posix.

Where does machinekit find “flavor”?

Here is a link to the output from the attempt to start Machinekit, the output from linuxcnc.log, linuxcnc_debug.txt, linuxcnc_print.txt, machinekit.ini and mkuuid. And yes, I know the the output from /var/log/linuxcnc.log is only one line long.

Here is a link to output from dmesg:

https://pastebin.com/UFveVH2f

Alan

On Feb 14, 2019, at 10:00 AM, schoo...@gmail.com wrote:

I don't know why this would fail, unless new packages were somehow installed on a system that does not have `uuidgen` installed.

Just generate a new MKUUID with uuidgen (if you don't have it, that is your problem right there, you need to install `uuid-runtime`)
and put it in your /etc/linuxcnc/machinekit.ini

Then try again.

(Need a link to the whole linuxcnc.log for the failed run next time, not just the line you think is important.  There is no context otherwise)

On 14/02/19 16:44, Condit Alan wrote:

after first startup and fail there was a 0 length file mkuuid in /etc/linuxcnc

and "MKUUID=" in machinekit.ini

on subsequent attempts to run it it tries to load rtapi_app_posix

Is there a simple way to reset machinekit to its initial state (like it has never been run yet)???

machinekit@beaglebone:~$ cat linuxcnc_debug.txt

2081

  PID TTY      STAT   TIME COMMAND

Stopping realtime threads

Unloading hal components

machinekit@beaglebone:~$ cat linuxcnc_print.txt

RUN_IN_PLACE=no

LINUXCNC_DIR=

LINUXCNC_BIN_DIR=/usr/bin

LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc

LINUXCNC_SCRIPT_DIR=

LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc

LINUXCNC_CONFIG_DIR=

LINUXCNC_LANG_DIR=/usr/share/linuxcnc/tcl/msgs

INIVAR=/usr/libexec/linuxcnc/inivar

HALCMD=halcmd

LINUXCNC_EMCSH=/usr/bin/wish8.6

INIFILE=/home/machinekit/machinekit/configs/ARM.BeagleBone.Xylotex/Xylotex.ini

PARAMETER_FILE=pru-stepper.var

TASK=milltask

HALUI=halui

DISPLAY=axis

Starting Machinekit server program: linuxcncsvr

Loading Real Time OS, RTAPI, and HAL_LIB modules

Starting Machinekit IO program: io

Starting HAL User Interface program: halui

Killing task linuxcncsvr, PID=2081

Removing HAL_LIB, RTAPI, and Real Time OS modules

Removing NML shared memory segments

machinekit@beaglebone:~$ cat /var/log/linuxcnc.log

Feb 14 00:03:43 beaglebone msgd:0: no [MACHINEKIT]MKUUID found in /etc/linuxcnc/machinekit.ini

[mugginsac]

I went back to the 1/27/2019 image "bone-debian-9.7-machinekit-armhf-2019-01-27-4gb.img.xz" until Robert can furnish a new kernel that will get rid of the slow boot times.

I still had to install uuid-runtime, ssh, xorg, and openbox in order to run machinekit via ssh. Actually ssh is only required because openssh evidently doesn't support scp. My

understanding is that the new release of machinekit will take care of uuid-runtime.

I appreciate everybody's patience and help while I tried to figure this out.

Alan

[mugginsac]

I loaded Robert Nelsons Stretch 9.8 from 02/24/2019.

<https://rcn-ee.com/rootfs/bb.org/testing/2019-02-24/stretch-machinekit/bone-debian-9.8-machinekit-armhf-2019-02-24-4gb.img.xz>

Except for having to update machinekit. I runs good "out of the box" with a reasonable boot time.

[Malte Schmidt]

Finally I was also able to test this.

Both thumbs up. Works like a charm