You are not logged in.
Thank you for the replies.
I am definitely no init expert - I wouldn't even class myself as "intermediate". I do however have an interest.
My intention was that the "Init System" heading would be for discussing everything (bugs, tips, experiences etc) about init etc in Devuan, or init slated for Devuan. So, maybe I should have been more specific, including suggesting "Devuan Init" as the title??
E.g. I have recently reinstalled Artix + s6 because I have an interest in the latter, and I see it is slated for Devuan in the (distant?) future. My aim is to understand how it is configured in Artix (the s6 suite has changed moderately compared to 2 years ago), and post any significant/interesting findings somewhere here. I am also interested in whether s6 is seen as an improvement or not, when compared to the existing Devuan inits (does it do anything better?)
I wholeheartedly agree that we don't want time-wasting "versus systemd" discussions. Apologies for my poor suggestion of a heading.
That DNG mail list is interesting reading; thank you for that.
I do very much appreciate all the volunteer time that goes into Devuan.
Please select one of the following ...
No reply to this thread means:
(a) Oops, I didn't see this post! Let me read it now.
(b) I'm ignoring this because it has already been discussed in another thread.
(c) I'm ignoring this because init systems have already been thrashed to death.
(d) This is a great idea but I forgot about it/was too busy; I am going to implement it immediately!
(e) This is a good idea but I forgot about it/was too busy; I am going to implement it with some mods.
(f) None of the above.
(g) I hate multiple choice questions.
How about adding to this forum the heading "Init System" (or similar), under the Index >> Discuss section?
I.e. for discussing init + process supervision + service management?
It seems to me that ...
1/ The s6 documentation has been updated, and is clearer than it was. (Perhaps it hasn't changed but I understand more about how it works?)
2/ s6-linux-init, s6-svscan and s6-supervise are good to go.
3/ The new s6-rc is still WIP but the current ("old") one is good to go.
4/ There needs to be a distro-specific effort to write s6 service file(s) for each daemon - e.g., to translate the SysVinit ones into s6-compatible ones.
5/ However, work is also underway on a "turnkey" s6 installation process - "s6-frontend" - which will provide a default set of s6 service files. However that is still a while away.
(I wonder how easy it would be to transplant Artix s6 service files into Devuan?)
11 months ago, the Alpine Linux team withdrew firejail from their repositories, citing security concerns with it:
This looks like it was a sudden thing, and is a little annoying because the suggested Bubblejail replacement is not working properly for me (Alpine v3.15.4; not edge).
Does anyone know if it is likely to vanish from Debian/Devuan for similar reasons? If so, is there/will there be a good, KISS, easy-to-use alternative?
I confirm that, after installing the chromium packages per c0rnelius above, chromium now works. (The Chrome "Citrix Workspace" extension also works in chromium.) Thank you for your help.
On RPi Devuan build rpi-4-devuan-chimaera-5.10.95-v8-ext4-2022-03-27.zip ...
... I ran sudo dpkg --simulate -i etc per above, and it did not report any issues (just "unpacking" messages), so I went ahead and ran:
sudo dpkg -i chromium_89.0.4389.114-1~deb10u1_arm64.deb chromium-common_89.0.4389.114-1~deb10u1_arm64.deb chromium-sandbox_89.0.4389.114-1~deb10u1_arm64.deb
Unfortunately the output was:
Selecting previously unselected package chromium.
(Reading database ... 106751 files and directories currently installed.)
Preparing to unpack chromium_89.0.4389.114-1~deb10u1_arm64.deb ...
Unpacking chromium (89.0.4389.114-1~deb10u1) ...
Selecting previously unselected package chromium-common.
Preparing to unpack chromium-common_89.0.4389.114-1~deb10u1_arm64.deb ...
Unpacking chromium-common (89.0.4389.114-1~deb10u1) ...
Selecting previously unselected package chromium-sandbox.
Preparing to unpack chromium-sandbox_89.0.4389.114-1~deb10u1_arm64.deb ...
Unpacking chromium-sandbox (89.0.4389.114-1~deb10u1) ...
dpkg: dependency problems prevent configuration of chromium:
chromium depends on libevent-2.1-6 (>= 2.1.8-stable); however:
Package libevent-2.1-6 is not installed.
chromium depends on libicu63 (>= 63.1-1~); however:
Package libicu63 is not installed.
chromium depends on libjsoncpp1 (>= 1.7.4); however:
Package libjsoncpp1 is not installed.
chromium depends on libminizip1 (>= 1.1); however:
Package libminizip1 is not installed.
chromium depends on libre2-5 (>= 20160901); however:
Package libre2-5 is not installed.
chromium depends on libvpx5 (>= 1.6.0); however:
Package libvpx5 is not installed.
chromium depends on libxslt1.1 (>= 1.1.25); however:
Package libxslt1.1 is not installed.
dpkg: error processing package chromium (--install):
dependency problems - leaving unconfigured
This downgrading stuff is all a bit new to me. Am I doing anything wrong?
I assume I was just meant to downgrade chromium ... not Devuan also?!
(I'm going to apt purge and apt autoremove to get rid of all this.)
PS: I notice the Devuan arm64 version of chromium ticked over to 99.0.4844.84-1~deb11u1 ... but it is still smashes those stacks.
Sorry, I got that last bit back to front; my setting is:
dtoverlay=gpio-fan,gpiopin=14,temp=60000
The fan starts when the temp is 60 degC or above.
The fan cuts out when the temp drops to/below 60 - 10 degC.
(Thanks @dave and @c0rnelius; I'll give them a try when I get the chance.)
Just thought I'd answer my own question about betting the official case + official fan combination to work on an RPi 4B ...
Edit file:
/boot/config.txt
and add (at the bottom):
dtoverlay=gpio-fan,gpiopin=14,temp=50000
This assumes the fan GPIO lead is plugged into GPIO14; it will turn the fan off when the CPU gets to/below 50 degrees Celsius.
Tested and works on the rpi-4-devuan-chimaera-5.10.95-v8-ext4-2022-03-27.zip installation.
Edit: Once the fan is off, it stays off until the temp reaches 50 + 10 deg C. Not sure if that can be adjusted.
Thank you dave.
FYI, I tried:
devuan_chimaera_4.0.0_arm64_rpi4.img.zip
and then:
rpi-4-devuan-chimaera-5.10.95-v8-ext4-2022-03-27.zip
Standard installation + xfce4 + xfce4-goodies + chromium (+ others)
So far they both work well ... except for Chromium:
chromium/stable,stable-security,now 99.0.4844.74-1~deb11u1 arm64 (chimaera-5.10.95)
Chromium doesn't even get to the GUI:
...
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
[5901:5901:0329/135843.805763:ERROR:gpu_process_host.cc(972)] GPU process exited unexpectedly: exit_code=6
...
But it looks to be somewhat similar to a recent upstream Debian bug with Chromium:
https://bugs.debian.org/cgi-bin/bugrepo … ug=1004368
So I won't report it as a Devuan bug.
Anyone concur? (Or found a workaround?)
[Edit: Hmmm ... probably not related to the Debian bug.]
Cheers for the work.
How can I get the fan-cpu temperature control working after installation? (Like how it works in raspi-config.)
thanks for the hardwork by developers!
Agree. Thank you very much, all you Devuan people, for all your work on getting this done.
[Edit: Corrected the quote formatting]
Oho, just discovered that:
doas -s
is a handy workaround while persist is not working.
I've uninstalled sudo. (There were no dependencies in my installation.)
@H_O_A_S/@zapper: Thanks for the tip about doas.
I note it can be installed from the repository (http://deb.devuan.org/merged chimaera/main amd64 Packages).
Tried it, but the one thing I need is its "persist" functionality, which doesn't work for me; here's my /etc/doas.conf contents:
permit persist <my-username> as root
doas runs fine but *always* asks me for the password.
I understand persist doesn't work because the package must have been compiled without first enabling persist. I assume it comes directly from Debian ... https://bugs.debian.org/cgi-bin/bugrepo … bug=983505
I looked up Hyperbola Linux and their website says:
"Due to the Linux kernel rapidly proceeding down an unstable path, we are planning on implementing a completely new OS derived from several BSD implementations."
... and:
"Future versions of Hyperbola will be using HyperbolaBSD which will have the new kernel, userspace and not be ABI compatible with previous versions."
What the!
They give reasons. That's somewhat concerning as a Linux user! But is the Linux kernel really heading significantly down that way, or is the Hyperbola site being slightly alarmist??
I've noticed that Distrowatch's page hit rankings for Artix have been rising over the past weeks, and Arch's dropping. It looks like it will go even further that way in the weeks to come.
I wonder if that is an informal vote against systemd, or something else? Or do Distrowatch page hits not really mean much (too easily influenced by bots)?
Anyone got any insights?
[Edit: "rise" not "risk"!]
Installed devuan_chimaera_4.0.beta-20210913_amd64_netinstall.iso just now. (Bare metal UEFI installation.)
Got the message: "... missing firmware files ... regulatory.db".
Ignored this and proceeded with installation anyway. Installation was successful; no further issues.
Installer bug?
(First time using Chimaera; looks good; so far everything works; seems to be faster than Beowulf!)
I'm hoping @andyprough can give use his thoughts on s6 v runit speed.
My 2 cents: Devuan + runit is very fast to boot up on an Xfce desktop installation. Artix + s6 was faster on the same PC. I would guess (relying on my memory of when I had Artix installed, 1.5 years ago) that Artix + s6 felt like an order of magnitude faster, but both are so quick that we're only really talking about a difference of a few seconds. Might be a different story, in favour of s6, for a server installation?
Laurent Bercot now has a sponsor ...
Update: the project has found a sponsor! Expect more news in this space in the months to come.
...
My estimate is that it needs about one year of work...
Also, I've just asked Distrowatch to update their "Init Software" details for Devuan. Please check ... in case I haven't got that quite right.
Cooool!!: runit is now in the Beowulf 3.1 installer (though I have been happily using it in 3.0, for the past 2-3 months) and it works well. Thank you Devuan developers!
Is s6 now an "almost certainty" for Chimera?
Yes, thank you very much to all you hard workers at Devuan. An amazing, functional and free operating system!
I had to boot my USB installer in legacy (BIOS) mode rather than UEFI, on my particular PC. If I installed through UEFI, the post-installation boot would end up at the GRUB2 command line.
I installed using ethernet, with the runit init software, and configured wifi after the first reboot. To avoid subsequent slow booting ("ifup: waiting for lock on /run/network/interfaces/ifstate.eth0"), I had to comment out the following lines in /etc/network/interfaces:
# The primary network interface
#allow-hotplug eth0
#iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
#iface eth0 inet6 auto
Yes, thank you Ron; your creative answer does of course work.
Searching the Forum for keyword "s6" (with or without quotes, or wildcards) returns the following:
"You have to enter at least one keyword and/or an author to search for."
Is there a trick I can use to get it to work?
Thank you for the reply.
I see s6 as a potential systemd killer, in terms of s6 being able to do the important stuff that systemd does, but in a well-designed and UNIX-friendly manner.
If s6 can be implemented in a few more distros, then perhaps other distros will have to take notice, and hopefully jump on board? (Why use systemd when there is a better alternative?)
https://skarnet.org/software/s6/ (s6 developer's site.)
https://github.com/CasperVector/up2020/releases ("Unix Philosophy 2020" book by Casper Vector.)
Any thoughts amongst the main Devuan developers on how good (or not so good) the s6 suite is?