Dev1 Galaxy Forum / Something strange happens to OpenRC after upgrade to Chimaera

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Wed, 23 Feb 2022 02:18:49 +0000

Well, I have uninstalled some service like SafeNET cryptography and now the problem seems to disappear.

On the other hand it worked in the previous version of Devuan Beowulf from which I have upgraded this host.

Actually there were many warnings displayed about something wrong in SafeNET service LSB specifications even on Beowulf, but at least it worked ...

The SafeNET software is obsolete about 5-10 years old.

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Wed, 23 Feb 2022 01:48:10 +0000

I have added echo $PATH before shell_var command:

root@kube:/download# service k0scontroller restart
 * Caching service dependencies ...
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/lib/rc/sh/rc-functions.sh: line 118: shell_var: command not found
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
/lib/rc/sbin:/lib/rc/bin:/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
 * Found a solvable dependency loop: mountall-bootclean.sh p> mountall-bootclean u> zfs-import a> checkfs n> mountall.sh p> mountall n> mountall-bootclean.sh.
 * Solving the loop by breaking mountall-bootclean u> zfs-import.
 * Found a solvable dependency loop: mountall.sh p> mountall u> zfs-import a> checkfs n> mountall.sh.
 * Solving the loop by breaking mountall u> zfs-import.                                                                                                                                                    [ ok ]
 * You are attempting to run an openrc service on a
 * system which openrc did not boot.
 * You may be inside a chroot or you may have used
 * another initialization system to boot this system.
 * In this situation, you will get unpredictable results!
 * If you really want to do this, issue the following command:
 * touch /run/openrc/softlevel
 * ERROR: k0scontroller failed to start

As you can see above one call for some reason missed the path:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/lib/rc/sh/rc-functions.sh: line 118: shell_var: command not found

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Wed, 23 Feb 2022 01:19:18 +0000

I have tried a simple test script:

root@kube:/download# cat test.sh
export set PATH=$PATH:/lib/rc/bin;
echo $PATH;
ebegin hello
eend hello

root@kube:/download# sh test.sh
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/lib/rc/bin
 * hello ...
 * hello

Some more tests on problematic host kube:

root@kube:/etc/init.d# /etc/init.d/k0scontroller restart
 * Caching service dependencies ...
/lib/rc/sh/rc-functions.sh: line 117: shell_var: command not found
 * Found a solvable dependency loop: mountall-bootclean.sh p> mountall-bootclean u> zfs-import a> checkfs n> mountall.sh p> mountall n> mountall-bootclean.sh.
 * Solving the loop by breaking mountall-bootclean u> zfs-import.
 * Found a solvable dependency loop: mountall.sh p> mountall u> zfs-import a> checkfs n> mountall.sh.
 * Solving the loop by breaking mountall u> zfs-import.                                                                                                                                                    [ ok ]
Starting hot-plug events dispatcher: udevd1 ... (warning).
Waiting 15 seconds and trying to continue anyway ... (warning).
Synthesizing the initial hotplug events (subsystems)...done.
Synthesizing the initial hotplug events (devices)...done.
Waiting for /dev to be fully populated...done.
Starting boot logger: bootlogdActivating swap...done.
Checking file systems...setterm: terminal xterm-256color does not support --msg
setterm: terminal xterm-256color does not support --msg
done.
Cleaning up temporary files... /tmp.
Mounting local filesystems...done.
Activating swapfile swap, if any...done.
Cleaning up temporary files....
Configuring network interfaces...done.

So: /lib/rc/sh/rc-functions.sh: line 117: shell_var: command not found

Continuation of the execution is in the next code fragment, please pay your attention to the "system which openrc did not boot."

Actually I had some problems with OpenRC after upgrade, I even could not boot to any run-level, only to something like Ctrl-D (is it level 1?). So I had to install sysv-rc at first, reboot and then reinstall OpenRC once again.

But after second install debsums integrity check passes fine, does not it mean all files installed correctly? Then why I still have no OpenRC from the point of view of k0s for example? It seems like it is not completely working OpenRC, even during boot it displays an error about something like above:

/lib/rc/sh/rc-functions.sh: line 117: shell_var: command not found

 * You are attempting to run an openrc service on a
 * system which openrc did not boot.
 * You may be inside a chroot or you may have used
 * another initialization system to boot this system.
 * In this situation, you will get unpredictable results!
 * If you really want to do this, issue the following command:
 * touch /run/openrc/softlevel
 * ERROR: k0scontroller failed to start

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (zapper) — Tue, 22 Feb 2022 02:27:58 +0000

I was going to say never had a problem with openrc before even when Chimaera came out, but I just read more carefully...

But anyways...

I wonder what changed since Beowulf to cause such an issue to the op...

Hmm...

Aka:

Kubernetes

Btw, never used the light version or the other one.

Also, looked it up, not sure what would be a good replacement even looking it up on wikipedia.org...

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (chris2be8) — Mon, 21 Feb 2022 17:01:31 +0000

Check running ebegin and eend manually work. Then call them from a small dummy script as a double check.

Look at /lib/rc/sh/supervise-daemon.sh to see if it's changing the PATH anywhere relevant.
Temporarily add echo $PATH to it just before it calls ebegin. Compare with what you get by adding echo $PATH to the start of the script.
If PATH gets changed then work out where it gets changed by adding echo $PATH at suitable places.

If all else fails post the whole of the original version of /lib/rc/sh/supervise-daemon.sh here to let someone who knows shell scripting look at it.

Chris

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Mon, 21 Feb 2022 05:23:09 +0000

Another Chimaera based host with name kube is unfortunately still broken, OpenRC displays already mentioned errors about missing /lib/rc/bin/ files even during boot process and not related to Kubernetes at all.

How can I find the reason comparing kube and ice hosts? (both with Chimaera installed on them).
Which areas shell I compare? Btw, debsums do not find any problems with integrity.

I used command:

wajig integrity

for the verification.

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Mon, 21 Feb 2022 05:00:39 +0000

Anyway k0s at least starts now:

root@chimaera:/# pstree
init─┬─agetty
     ├─anacron───run-parts───apt-compat───sleep
     ├─containerd-shim─┬─kube-router───9*[{kube-router}]
     │                 ├─pause
     │                 └─11*[{containerd-shim}]
     ├─containerd-shim─┬─kube-proxy───8*[{kube-proxy}]
     │                 ├─pause
     │                 └─11*[{containerd-shim}]
     ├─containerd-shim─┬─metrics-server───8*[{metrics-server}]
     │                 ├─pause
     │                 └─10*[{containerd-shim}]
     ├─containerd-shim─┬─coredns───9*[{coredns}]
     │                 ├─pause
     │                 └─10*[{containerd-shim}]
     ├─cron
     ├─2*[dbus-daemon]
     ├─dbus-launch
     ├─dhclient───3*[{dhclient}]
     ├─elogind-daemon
     ├─6*[getty]
     ├─jitterentropy-r
     ├─matchbox-deskto───16*[{matchbox-deskto}]
     ├─qasmixer───14*[{qasmixer}]
     ├─sshd───sshd───bash───pstree
     ├─supervise-daemo───k0s─┬─containerd───13*[{containerd}]
     │                       ├─kine───226*[{kine}]
     │                       ├─kube-apiserver───16*[{kube-apiserver}]
     │                       ├─kube-controller───13*[{kube-controller}]
     │                       ├─kube-scheduler───9*[{kube-scheduler}]
     │                       ├─kubelet───15*[{kubelet}]
     │                       └─30*[{k0s}]
     ├─udevd
     └─vncserver─┬─Xtigervnc───12*[{Xtigervnc}]
                 └─jwm

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Mon, 21 Feb 2022 04:58:01 +0000

I was able to start k0s on both Beowulf and Chimaera.

On both I had to rename networking service to net, not sure if it is wrong for something else, but at least it makes k0s working.

cd /etc/init.d; mv networking net

rc-update add net

On Beowulf I then was able just to issue the command:

service k0s start

But on Chimaera I had to use commands:

rc-service -s k0scontroller stop

and

rc-service -S k0scontroller start

And still get some warning like:

root@chimaera:/etc/init.d# rc-service -S k0scontroller start
 * Caching service dependencies ...                                                                                                                                                                        [ ok ]
Configuring network interfaces...warning: vrf: cache v6: cmd '/bin/ip -6 rule show' failed: returned 255 (RTNETLINK answers: Address family not supported by protocol
Dump terminated
)
done.

I have disabled IPv6 on that host.

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Sun, 20 Feb 2022 19:40:03 +0000

Can you please suggest a light Kubernetes distribution which works fine on Devuan?

My experience with k0s on Chimaera is even worse than with k3s

I just need to learn and experiment and may be use it for a light (not HL) hosting service.

Even Minikube looks like a too heavy for me since it requires 2 cores and 2 Gb of RAM which does not fit a small VPS.

May be kind ?

https://kind.sigs.k8s.io/

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (Head_on_a_Stick) — Sun, 20 Feb 2022 18:46:20 +0000

chris2be8 wrote:

Try reading the man pages for ebegin and eend (if they have them) to see what they should do.

They just provide status messages for startup and rc-status.

The OP has clearly been modifying their system in various ways because I can't get the k3s service running under OpenRC without changing the source bashism to .. Since they can't be bothered telling us what they have done to either of their systems or even share more information about this k3s service I really can't be bothered digging deeper...

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Sun, 20 Feb 2022 18:10:42 +0000

chris2be8 wrote:

Does anyone who has OpenRC installed have any suggestions? Even just to say it works for them.
And one last thought, are you on a x86-64 CPU? x86-64 won't work on ARM etc.
Chris

I have another installation of Chimaera where OpenRC works very fine.

root@chimaera:~# service k3s restart
 * Starting k3s ...

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (chris2be8) — Sun, 20 Feb 2022 17:40:24 +0000

I don't have OpenRC on my system so I'm just guessing here.

Try reading the man pages for ebegin and eend (if they have them) to see what they should do.
Try calling them directly (passing ebegin a suitable message as a parameter). Do they work?

The part of the script you posted defines a function the script will call further on. Does it change the PATH before calling it?

Does anyone who has OpenRC installed have any suggestions? Even just to say it works for them.

And one last thought, are you on a x86-64 CPU? x86-64 won't work on ARM etc.

Chris

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Sun, 20 Feb 2022 00:01:20 +0000

root@kube:~# head -n 60 /lib/rc/sh/supervise-daemon.sh
# start / stop / status functions for supervise-daemon

# Copyright (c) 2016 The OpenRC Authors.
# See the Authors file at the top-level directory of this distribution and
# https://github.com/OpenRC/openrc/blob/master/AUTHORS
#
# This file is part of OpenRC. It is subject to the license terms in
# the LICENSE file found in the top-level directory of this
# distribution and at https://github.com/OpenRC/openrc/blob/master/LICENSE
# This file may not be copied, modified, propagated, or distributed
#    except according to the terms contained in the LICENSE file.

extra_commands="healthcheck unhealthy ${extra_commands}"

supervise_start()
{
        if [ -z "$command" ]; then
                ewarn "The command variable is undefined."
                ewarn "There is nothing for ${name:-$RC_SVCNAME} to start."
                return 1
        fi

        ebegin "Starting ${name:-$RC_SVCNAME}"
        # The eval call is necessary for cases like:
        # command_args="this \"is a\" test"
        # to work properly.
        eval supervise-daemon "${RC_SVCNAME}" --start \
                ${retry:+--retry} $retry \
                ${directory:+--chdir} $directory  \
                ${chroot:+--chroot} $chroot \
                ${output_log+--stdout} ${output_log} \
                ${error_log+--stderr} $error_log \
                ${pidfile:+--pidfile} $pidfile \
                ${respawn_delay:+--respawn-delay} $respawn_delay \
                ${respawn_max:+--respawn-max} $respawn_max \
                ${respawn_period:+--respawn-period} $respawn_period \
                ${healthcheck_delay:+--healthcheck-delay} $healthcheck_delay \
                ${healthcheck_timer:+--healthcheck-timer} $healthcheck_timer \
                ${command_user+--user} $command_user \
                ${umask+--umask} $umask \
                ${supervise_daemon_args:-${start_stop_daemon_args}} \
                $command \
                -- $command_args $command_args_foreground
        rc=$?
        if [ $rc = 0 ]; then
                [ -n "${chroot}" ] && service_set_value "chroot" "${chroot}"
                [ -n "${pidfile}" ] && service_set_value "pidfile" "${pidfile}"
        fi
        eend $rc "failed to start ${name:-$RC_SVCNAME}"
}

supervise_stop()
{
        local startchroot="$(service_get_value "chroot")"
        local startpidfile="$(service_get_value "pidfile")"
        chroot="${startchroot:-$chroot}"
        pidfile="${startpidfile:-$pidfile}"
        ebegin "Stopping ${name:-$RC_SVCNAME}"
        supervise-daemon "${RC_SVCNAME}" --stop \
                ${pidfile:+--pidfile} $chroot$pidfile

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (bimon) — Sat, 19 Feb 2022 23:58:22 +0000

Thank you very much for trying to help me.

root@kube:~# file /lib/rc/bin/ebegin
/lib/rc/bin/ebegin: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=06fede7e085916fa8a23de855fd26a1dbaaf2227, for GNU/Linux 3.2.0, stripped

root@kube:~# ls -al /lib/rc/bin/ebegin
-rwxr-xr-x 1 root root 35496 Apr  2  2021 /lib/rc/bin/ebegin

Re: Something strange happens to OpenRC after upgrade to Chimaera

dummy@example.com (chris2be8) — Fri, 18 Feb 2022 17:09:36 +0000

Run ls -l /lib/rc/bin/ebegin and check if it's marked executable. If it's a symlink to somewhere run ls -l against the destination (repeat until you reach the end if that's a symlink too). Post full output here if you can't understand it.

Then run file /lib/rc/bin/ebegin to see what it is. If it's some kind of script look at the first line of it to see which interpreter it's trying to use. And check that exists. Trying to run a script that tries to use an interpreter that does not exist might produce that message.

Also look at /lib/rc/sh/supervise-daemon.sh to see if it's changing the path anywhere relevant. And post lines 26 and 52 from it here if you are not sure what they are trying to do.

Chris