You are not logged in.
https://www.linux.org.ru/news/novell/17 … d=17542939
But I think, it looks like a trolling from Was2023.
IMHO he tries to promote Russian Alt Linux, which is IMHO not good for DevOps because not popular like Debian.
> Although the thread started as a proposal for a systemd-to-sysvinit converter, I certainly consider this idea more feasible for s6/66.
Very good idea to translate ready service definitions from one init system to another and I would also offer from one distribution to another because some distributions have more complete definitions e.g. for OpenRC than Devuan, etc.
So translator shall allow choosing a ready distribution (for example URL to another distro LiveCD ISO) and automatically detect its init system. Then translate from foreign distro systemd/OpenRC -> Devuan OpenRC/S6 for example in a CI/CD pipeline.
Also a tool may have a method to pull service definitions from standalone application source repositories on Github, Gitlab, etc. or repository of another distribution packages.
If someone is interested to sponsor such work I would be glad to try to develop it using Nelua and/or Ion and/or Haxe and/or Crystal:
Nelua: https://nelua.io/ - traspiler from LUA dialect to C, very easy to use, as productive as LUA, generates very light executable about 10Kb for a Hello World test application or a small C source file. IMHO it is an absolute winner for writing portable precompiled CLI applications (though relatively young yet):
We love to script in Lua.
We love C performance.
We want best of both worlds in a single language and with a unified syntax.
We want to reuse or mix existing C/C++/Lua code.
We want type safety and optimizations.
We want to have efficient code while maintaining readability and safety.
We want the language features and manual to be minimal and fit our brain.
We want to deploy anywhere C runs.
We want to extended the language features by meta programming or modding the compiler.
We want to code with or without garbage collection depending on our use case.
We want to abuse of static dispatch instead of dynamic dispatch to gain performance and correctness.
Though Nelua did not build on OpenBSD out of the box, I was able to fix this in about a few minutes, it was a minor incompatibility of OpenBSD time function with Linux.
Haxe: https://haxe.org/documentation/introduc … ction.html
It is the most mature multi-target (JS, Python, Lua, JVM, C++, etc.) transpiler known to me.
IMHO it has the most pleasant and clear syntax, easy to program. Generates very light JS and Python code.
One day its Lua target output may become compatible with Nelua input which would allow it to produce very light AOT binaries.
Haxe transpiling to C++ produces relatively heavy binaries about 1.5Mb for a Hello World test application like Crystal.
Crystal: https://crystal-lang.org/ - very productive powerful full blown programming language with a pleasant Ruby syntax. It can be a single binary too but large enough, at least 1.5 Mb for a Hello World test application.
Ion: Powerful and still easy with clear syntax Ion shell: https://doc.redox-os.org/ion-manual/var … rrays.html - it is a bash like single binary shell interpreter.
Microsoft C#: IMHO C# on Mono is good only for executing with JIT compilation with full runtime deployed (the same way as for Python without Nuitka) because full AOT of Mono is very buggy and development of Mono seems to be stalled. That is why it is IMHO not good for generating self enough binaries like in Golang, Crystal, Nelua, etc. Though there is another tool IL2CPP from Unity, I am not sure how good it is for compiling CLI tools without Unity game engine. And regarding to modern .NET 8 AOT, it is not as good for cross-platform development as other options. .NET Native AOT compilation works only for Linux/Android/Windows/Apple, x86/ARM: https://learn.microsoft.com/en-us/dotne … native-aot, unfortunately it lacks support of OpenBSD OS and hardware architectures like MIPS, PowerPC, SPARC, etc.
I can offer price based on number of lines of very DRY code or per hour (say $10-$20/h).
Also I learn to become a DevOps engineer.
Hello Dear Devuan users!
Please explain me in more details why there is so much worry about systemd-boot?
May be some of following issues (not sure):
If I understood correctly, I was told on another forums, that Debian kernel in the future may lack support for non UEFI mode of booting?
So we could not boot a new kernel ? Actually I do not understand why.
Is not it easy to replace (rebuild with other options) a kernel which is compatible with old legacy boot without need for UEFI boot loader?
For old legacy PCs there is a boot loader with UEFI emulator:
https://wiki.archlinux.org/title/Clover
Or may be (I am not sure) an UEFI mode can be emulated on legacy PC by software like OVMF:
https://wiki.osdev.org/UEFI#Emulation_w … U_and_OVMF
?
Or may be it is because new kernel can be tied to exactly systemd-boot?
It looks like corporations would like to put kernel and squeeze it in a vice from two sides: [boot] -> KERNEL <- [userland system manager]
to get more control over users may be even like locking their boot process under some conditions.
If there is no direct tie between kernel and systemd-boot, then why we cannot replace systemd-boot with alternative boot loader?
There are a lot of other boot loaders available which have nothing to do with systemd:
What do you think about creating a systemd like CLI and service definitions for Devuan with S6 init ?
My idea is to create a wrapper which would automatically translate somehow config files looking like systemd into S6 syntax when any such config file has been changed and its syntax has been linted without an error.
It is not related to binding to actual systemd software except adding compatibility at user/admin syntax level familiar with systemd CLI, etc.
So nothing from systemd system manager would be imitated by such a CLI except init system service definitions language (may be a subset of it).
IMHO it would make it much easier to migrate existing Debian systems to Devuan with S6 init and make creating new service config files much easier. When such S6 looking like systemd is ready it would be more difficult to argue for using systemd instead of S6 just for its service definitions language.
There are many examples of transpiling from one programming language to another. IMHO it is much easier for systemd config files.
I would even offer two modes for new init syntax: legacy (compatible with systemd) and new YAML syntax still similar to systemd but more modern and advanced. And S6 under the hood without any actual systemd dependencies of course
It is my current desktop look:
https://pasteboard.co/CGcCPgm9l2vu.jpg
Btw., it works fine even with dbus STOPPED on the host. Hyperbola style
Devuan ASCII + Libre Kernel 4.19.latest + ZFS v0.8.6 + Trinity Desktop + KVM + Chimaera Guest where Telegram runs.
All this works fine on a single old PC: Core2 Quad with 4GB RAM (extendable to 8Gb if needed)
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.
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
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
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.
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
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.
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 ?
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 ...
I've had some luck using "-pix_fmt yuyv422" and "scale=-1:720"
Unfortunately this does not work for me in Chromium (the same way as my settings mentioned earlier).
Regarding to codec, I guess Opus can be used:
https://www.reddit.com/r/ffmpeg/comment … pus_codec/
http://www.pogo.org.uk/~mark/trx/stream … audio.html
My goal is to improve video session stability by executing video chat client on the modern Linode host with a fast internet in their datacenter.
So if my connection brokes or sometimes becomes slow I would not drop from the video session completely but rather only will miss some UDP packets from ffmpeg which is acceptable for me.
Also I am going to protect my Internet line between my home and Linode by some type of a VPN, may be UDP Wireguard.
I am thinking about trying to use Zoom and Google Meet on a remote computer, for example inside a Linode guest with Tiger VNC + JWM.
I need to pass sound in both directions somehow. Open source VNC by its own AFAIK does not support remote sound.
I would not like to use Pulse Audio because I do not like anything from this systemD programmer
Also I would prefer to avoid popular sound servers like NAS.
What do you think about trying to use ffmpeg and ALSA loopback for the task?
So I could make two streams:
1) From my workstation to Linode VPS:
VideoCam + Microphone -> local ffmpeg streaming -> UDP -> remote ffmpeg -> loopback devices (ALSA and V4L) -> Zoom / Google Meet
https://trac.ffmpeg.org/wiki/StreamingGuide
https://trac.ffmpeg.org/wiki/Capture/ALSA
2) From Linode VPS to my workstation:
Zoom / Google Meet on Linode VPS -> ALSA loopback -> remote ffmpeg streaming -> UDP -> some player capable to open a sound stream
Also I will look at VNC to see another party.
There is even a place for improvement. I can try to capture program window like Zoom or Chromium directly to ffmpeg too and pass remote video from another party via multimedia stream too and see it in a player instead of VNC client.
Please help me to make this video cam working in browsers based on Google Chrome.
Hello,
Google Meet works on Firefox for me including video (which is actually a loopback device),
but there is no video if trying to do the same in Chromium.
Chrome does not see video camera too
I have wrote following script for converting a video stream from chines fish eye video camera to a /dev/video compatible with Zoom:
rmmod v4l2loopback;
modprobe v4l2loopback;
sleep 1s;
set -x;
URL="rtsp://192.168.x.x:554/user=vasya&password=xxx&channel=&stream=1.sdp?real_stream--rtp-caching=100";
#---Cut region, scales are specific to region size:
Crop=" crop=210:300:210:250,";
#--- Slim:
Scale="300:350";
#--- Normal:
#Scale="300:300";
PixFormat=" -pix_fmt yuv420p ";
nice -n 7 ffmpeg -rtsp_transport tcp -r 1 -i "$URL" -vf $Crop"hflip,scale="$Scale $PixFormat -f v4l2 /dev/video0;
#-reorder_queue_size 4000 -max_delay 10000000
#-target pal-dvd
#-loglevel debug
rmmod v4l2loopback;
It works very well in Zoom and Firefox, but if trying to use default video camera setting with full resolution without a crop it would work too slow.
Also as I already told it does not work with Chrome and Chromium.
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
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
I have added echo $PATH manually to the /lib/rc/sh/supervise-daemon.sh
root@kube:~# service k3s restart
/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/bin/
/lib/rc/sh/supervise-daemon.sh: line 26: ebegin: command not found
/lib/rc/sh/supervise-daemon.sh: line 52: eend: command not found
* ERROR: k3s failed to start
root@kube:~# ls /lib/rc/bin/ebegin
/lib/rc/bin/ebegin
Also I get a message about missing shell_var (/lib/rc/bin/shell_var) during booting the system.
root@kube:~# dpkg -al | grep openrc
ii openrc 0.42-2.1 amd64 dependency based service manager (runlevel change mechanism)
Why rc scripts cannot find binaries from /lib/rc/bin/ ?
Removing /etc/alsa/asound.conf still keeps sound in zoom working, but it does not influence firefox at all, so Mic still does not work anyway.
Is /etc/alsa/asound.conf file taken into account by the ALSA at all?
Can you please suggest an URL with modern guides for custom configuration of ALSA in Debian v11 or Chimaera without pulseAudio?
I have found a workaround of executing browser by apulse command.
But then why headphones work even without apulse via ALSA while microphone works only via apulse for me ?
Hello,
I have sound working fine in Zoom (both Mic and Headphones), but unfortunately there is no microphone sound in Firefox.
On the other hand Firefox plays any sounds to the headphones fine.
It is a Chimaera installation.
dpkg -al | grep pulse
ii libpulse-mainloop-glib0:amd64 14.2-2 amd64 PulseAudio client libraries (glib support)
ii libpulse0:amd64
I have following asound.conf:
root@chimaera:/etc/alsa# cat asound.conf
##### Hardware Aliases #####
pcm.system_card {
type hw;
card 0;
}
ctl.system_card {
type hw;
card 0;
}
ctl.system_dm ctl.system_card;
####################### MIXERS ########################
# --- System
pcm.system_mixer {
type dmix;
ipc_key 1024;
ipc_key_add_uid false; # let multiple users share
ipc_perm 0777; # IPC permissions (octal, default 0600)
slave {
pcm system_card;
period_time 0;
period_size 2048;
buffer_size 32768;
# rate 48000;
rate 44100;
}
bindings {
0 0;
1 1;
}
}
pcm.system_dm {
type plug;
slave.pcm "system_mixer";
}
pcm.system_volume {
type softvol
slave {
# pcm system_card;
pcm "system_mixer"
}
control {
name "Pre-Amp";
card 0;
}
min_dB -10.0
max_dB 25.0
resolution 12
}
pcm.system_sv {
type plug;
slave.pcm "system_volume";
}
#ctl.system_sv ctl.system_card;
pcm.asymed {
type asym
playback.pcm "system_mixer"
capture.pcm "hw:0,0"
}
ctl.asymed ctl.system_card;
##### Defaults #####
pcm.dsp0 {
type plug
slave.pcm "asymed"
}
pcm.!default {
type plug
slave.pcm "asymed"
}
pcm.default {
type plug
slave.pcm "asymed"
}
ctl.!default ctl.asymed
ctl.default ctl.asymed
Solution: just add current user to the plugdev group