Newer versions of Openrc

Geoff 42 · 2020-03-15 16:09:11

In posts on the thread about "openrc-init failure" :-

https://dev1galaxy.org/viewtopic.php?id=2788

I described what I did, looking at using Openrc including replacing SysV init with openrc-init. I found that there was a bug in Openrc 0.40.1 which got the sequencing of the start wrong. This bug was fixed in 0.41.2, although this version is not available yet in Beowulf (or Ceres ?).

I worked around this by simply compiling the original source (from Gentoo ?) and copying over openrc-init binary. This does work, but is clearly not the correct way to do things.

I have been looking at how the packaging for Debian is done and have managed to produce the packages for my own use and have moved on to version 0.42.1. I report on it here in case anyone else is interested in discovering how it is done! Useful sources of info are :-

https://wiki.debian.org/UsingQuilt
but especially :-
https://raphaelhertzog.com/2012/08/08/h … -packages/
as well as the more general :-
https://www.debian.org/doc/manuals/main … ex.en.html

The process involves copying over the previous Debian mods. It is necessary to edit the changelog to add a new entry at the top for the new version. Then use quilt to look after the patches, use debmake to generate any new template files and debuild to actually compile and package everything. It was necessary to add some extra packages first, to do the packaging as well some dependencies.

apt-get install packaging-dev debmake libaudit-dev libpam0g-dev libselinux1-dev

I added the sources to my repositories in /etc/apt and then got the current version :-

As me :-

cd ~/src/Devuan/Openrc
apt-get source openrc
ls -alF

drwxr-xr-x 20 user1 user1 4096 Mar 10 16:20 openrc-0.40.3/
-rw-r--r-- 1 user1 user1 26532 Feb 2 2019 openrc_0.40.3-1.debian.tar.xz
-rw-r--r-- 1 user1 user1 2252 Feb 2 2019 openrc_0.40.3-1.dsc
-rw-r--r-- 1 user1 user1 244510 Feb 2 2019 openrc_0.40.3.orig.tar.gz

This gives us the original sources in a tar file as well as a new subdirectory "debian" which contains patches to the sources and other instructions to make things install and work The Debian Way (TM).

For the next versions I got the sources from :-

https://github.com/OpenRC/openrc/releases

I got the tar.gz for 0.41.2 and 0.42.1 so that I could do reasonably small steps at a time.

The building process leaves the new files in the directory where you start so I created subdirectories for each of the new versions.

mkdir build-0.41.2
cp openrc-0.41.2.tar.gz build-0.41.2/
cp openrc_0.40.3-1.debian.tar.xz build-0.41.2/
cd build-0.41.2
mv openrc_0.40.3-1.debian.tar.xz openrc_0.41.2-1.debian.tar.xz
tar xvf openrc-0.41.2.tar.gz
cd openrc-0.41.2
tar xvf ../openrc_0.41.2-1.debian.tar.xz

cd debian

edit debian/changelog to add the new version at the top, something like :-

openrc (0.41.2-1) unstable; urgency=medium
* New upstream release.
-- My Name-Here <my.name-here@example.com> Thu, 12 Mar 2020 15:00:07 +0000

The spacing is very important! There are two spaces before '*' and the date and one space before '--'.

cd ..

Then quilt is used to check the source patches :-

quilt setup debian/patches/series

This leaves some odd paths, so I tidied them up a bit.

cd .pc

edit .quilt_patches to be :-

debian/patches

cd ..
rm patches series

Then the following command works and displays the patches :-

quilt series

Try all of the patches (push applies the next one, -a does all of them) When one fails try push -f to force it and then check the .rej file to see what the problem was. When you have fixed it use refresh to regenerate the patch correctly. If a patch is no longer relevant you delete it. If the patch works with some off-set, then refresh to correct the patch.

quilt push -a
quilt push -f
cat src/Makefile.rej 
edit src/Makefile to correct the problem
quilt refresh
quilt push
quilt delete -r  0005-binutils-ppc64el.patch
quilt push
quilt delete -r  0012-riscv-relocs.patch
quilt push
quilt pop -a
while quilt push; do quilt refresh; done

The PPC64 and RiscV patches were to files which no longer existed.

Get everything ready and the build the packages (a couple of libraries are separate).

debmake
... some output ...
debuild
... some more output...

including :-

install --strip-program=true -d /home/.../src/...
install: WARNING: ignoring --strip-program option as -s option was not specified

This may be deliberate as --strip-program=true seems to indicate using 'true' to do the striping!! Although the syntax for install may be different for Gentoo?

There are warnings about "package could avoid a useless dependency" referring to libaudit and libselinux not being linked against by libeinfo and librc. This would need further investigation.

The signing fails because of the lack of my having a secret key.

cd ..

The build directory now contains the .deb packages. I copied the relevant (non-dev) ones to the file space of my Beowulf VM and then booted the VM, and as root on the VM I installed the packages :-

dpkg -i libeinfo1_0.41.1-2_amd64.deb  librc1_0.41.2-1_amd64.deb openrc_0.41.2-1_amd64.deb

After rebooting the VM the console reports, inter alia, :-

INIT: version 2.93 booting
OpenRC 0.41.2 is starting up Linux 4.19.0-8-amd64 (x86_64) [XENU]

This is correct as SysV init is till being used to get things started! More on that later.

Geoff

edit: Corrected the list of packages required initially, adding libaudit-dev.

Last edited by Geoff 42 (2020-03-16 14:28:20)

Head_on_a_Stick · 2020-03-15 20:22:34

Nice guide, thanks!

Geoff 42 wrote:

edit debian/changelog to add the new version at the top

You can use this to generate the new changelog entry automagically:

dch -v $version_number

Replace $version_number with the actual version number then add in the details for the change. The dch command can be found in the devscripts package.

If you export $DEBEMAIL & $DEBFULLNAME from ~/.bashrc (or whichever shell initialisation file is appropriate) those will also be added in for you. See https://www.debian.org/doc/manuals/debm … mail-setup (the rest of that guide is very good).

Geoff 42 wrote:

The signing fails because of the lack of my having a secret key.

Use this to create unsigned packages:

debuild -us -uc

Geoff 42 · 2020-03-16 10:07:46

Thank you for your comments!

The advice on using dch to generate the changelog entry is very good, as the format is very important, or debmake will get upset!

The failure of signing did not seem to cause any problems but I assume that the -us -uc flags stop the warnings.

Geoff

Geoff 42 · 2020-03-16 10:22:25

The only real problem with the patches was with src/Makefile, as indicated above. The line that it complained about was :-

SUBDIR= test libeinfo librc rc

which I edited to be :-

SUBDIR= libeinfo librc rc lsb2rcconf

I think that the removal of test meant that the original line did not match the patch. I also presume that lsb2rcconf is to accommodate a real source code patch to handle the LSB headers in init files, providing dependency information, for Debian.

Geoff

Geoff 42 · 2020-03-16 15:37:37

Setting up openrc-init

The default set-up in Debian (and hence Devuan) is that SysV init is started at boot time.
SysV init, as usual reads /etc/inittab, which is unchanged and thus sets up the ttys.
Openrc gets called from within inittab by rcS and rc which are scripts that have been
replaced by the openrc package.

If we replace SysV init with openrc-init, then we need to have openrc set up the ttys. The Openrc sources
provide init files for agetty. In various earlier attempts to get this working I had got a copy of agetty
in /etc/init.d and changed it into getty. Then the Gentoo recommendation is to set up a link with the
name of the device appended. As I am testing this in a VM under Xen, the console is called hvc0 and
I also set up tty1.

cd /etc/init.d
chmod a+x getty
ln -s getty getty.hvc0
ln -s getty getty.tty1

These are then activated in the usual Openrc way with

rc-update add getty.hvc0
rc-update add getty.tty1

The next thing was to add init=/sbin/openrc-init to the kernel start-up.
As this was booting up under Xen using pygrub I needed to edit menu.lst.

cd /boot/grub

and edited menu.lst so that the selected entry read :-

title Debian GNU/Linux, kernel 4.19.0-8-amd64
root (hd0,0)
kernel /boot/vmlinuz-4.19.0-8-amd64 root=/dev/xvda2 ro elevator=noop init=/sbin/openrc-init
initrd /boot/initrd.img-4.19.0-8-amd64

Rebooting then worked successfully. The console messages included :-

[ 1.960106] Run /init as init process
Loading, please wait...
... some output ...
OpenRC init version 0.42.1 starting
Starting sysinit runlevel
OpenRC 0.42.1 is starting up Linux 4.19.0-8-amd64 (x86_64) [XENU]
... some more output ...

Having logged in via vnc ps axjf shows, inter alia :-

PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
0 1 0 0 ? -1 S 0 0:01 /sbin/openrc-init
1 2734 1795 1795 ? -1 S 0 0:00 supervise-daemon getty.hvc0 --start --pidfile /run/getty.hvc0.pid --respawn-period 60 /sbin/
2734 2735 2735 2735 hvc0 2735 Ss+ 0 0:00 \_ /sbin/getty --noclear hvc0 38400 linux
1 2759 1795 1795 ? -1 S 0 0:00 supervise-daemon getty.tty1 --start --pidfile /run/getty.tty1.pid --respawn-period 60 /sbin/
2759 2761 2761 2761 tty1 2761 Ss+ 0 0:00 \_ /sbin/getty --noclear tty1 38400 linux

This all appears to be running nicely and it is possible to log in via the console.
Looking at /var/log/rc.log appears to be correct including when the machine gets shut down.

There are error messages about getty is the name of a real and virtual service.
It would be good to get rid of those.

The other thing to do would be to ensure that either the agetty or getty init script
is left somewhere sensible by the package. I am not sure which name should be used and
whether it makes any difference.
It might be possible to put the (a)getty directly in /etc/init.d or maybe somewhere else,
perhaps with the other Gentoo init scripts, as examples.
The Gentoo people seem to like having fairly generic init.d files with corresponding configuration files
in /etc/conf.d, with the expectation that you would only edit the files in conf.d.

The other thing about running openrc-init is that when you shut it down you need to use openrc-shutdown instead of shutdown.
This also takes the usual flags such as -r for reboot and -H for halt.

Geoff

edited to add chmod getty

Last edited by Geoff 42 (2020-03-26 14:57:37)

Geoff 42 · 2020-03-17 11:06:09

The file /etc/init.d/getty

This file was derived from agetty. The name agetty has been changed to getty
and a couple of variables from /etc/conf.d/agetty have been incorporated.
It extracts the name of the device from the end of the name of the file it was started from, e.g. getty.tty
It uses the OpenRC native format of init file and also uses the supervise-daemon which is part of OpenrRC.

cat << "EOF" > /etc/init.d/getty
#!/sbin/openrc-run
# Copyright (c) 2017 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.

description="start getty on a terminal line"
supervisor=supervise-daemon
baud="38400"
port="${RC_SVCNAME#*.}"
respawn_period="${respawn_period:-60}"
term_type="${term_type:-linux}"
getty_options="--noclear"
command=/sbin/getty
command_args_foreground="${getty_options} ${port} ${baud} ${term_type}"
pidfile="/run/${RC_SVCNAME}.pid"

depend() {
	after local
	keyword -prefix
}

start_pre() {
	if [ -z "$port" ]; then
		eerror "${RC_SVCNAME} cannot be started directly. You must create"
		eerror "symbolic links to it for the ports you want to start"
		eerror "getty on and add those to the appropriate runlevels."
		return 1
	else
		export EINFO_QUIET="${quiet:-yes}"
	fi
}

stop_pre()
{
	export EINFO_QUIET="${quiet:-yes}"
}
EOF

Geoff

edited to add quotes round "EOF" to stop substitutions.

Last edited by Geoff 42 (2020-03-26 14:54:07)

Geoff 42 · 2020-03-22 17:22:48

On real hardware

As Openrc 0.42.1 seems to be happy on a VM under Xen I thought that I should check it on real hardware. I tried it on my desktop machine.
This usually boots under the Xen hypervisor with Beowulf as the controlling OS, Dom0. This machine is still using SysV init to start things.
I simply used the deb files I had created earlier, as described above, and the command :-

dpkg -i libeinfo1_0.42.1-1_amd64.deb librc1_0.42.1-1_amd64.deb openrc_0.42.1-1_amd64.deb

The machine rebooted as normal as Dom0 but running 0.42.1 and all looks normal.
I then rebooted with it running on the bare metal and it still looks normal.

I have also installed 0.42.1 on my laptop. I had previously put the Gentoo openrc-init 0.41.2 on this to replace SysV init. I had also hacked up a small script to use openrc-shutdown, which could be used from LXQt. After installing 0.42.1 it still works as before.
It is documented that this later version of openrc-shutdown will also work with SysV init, although I have not tested this.

Geoff

Geoff 42 · 2020-03-28 16:34:38

openrc-shutdown

The script for shutting down is a very crude thing and would not win any awards for beauty, but it does work. It looks like this :-

cat << "EOF" > /usr/local/bin/my-logout-query
#!/bin/bash

xmessage \
    -geometry 650x100+1700+400 \
    -font 10x20 \
    -bd red \
    -bg yellow \
    -fg black \
    -title "Shutdown/Logout" \
    -buttons Shutdown:101,Reboot:102,Logout:103,Cancel:104 \
    "How do you want to leave the computer?"

answer=$?

case "$answer" in
     101)
#        echo shutdown
	sudo /sbin/openrc-shutdown -p now
        ;;
     102)
#        echo reboot
	sudo /sbin/openrc-shutdown -r now
        ;;
     103)
#         echo logout
#        /usr/bin/lxsession-logout
        /usr/bin/lxqt-leave --logout
        ;;
     104)
        echo cancel
        ;;
esac
EOF
chmod a+x /usr/local/bin/my-logout-query

You may need to adjust the geometry to fit your screen.

As myself :-

cd .local/share/applications
cp /usr/share/applications/lxqt-leave.desktop my-leave.desktop

I then edited my-leave.desktop to change the "Exec" line from lxqt-leave to

Exec=/usr/local/bin/my-logout-query

Then it should appear in the LXQt menu under the Leave options. If you have a quicklaunch plugin it is possible to drag a copy of leave and drop it on the quicklaunch as an easy way of shutting down. I have a second quicklaunch on the far right of the LXQt panel, just for this purpose.

I have tried openrc-shutdown while SysV init was still in use and it seems to work correctly, so it is possible to set this up before looking at replacing SysV init with openrc-init.

Geoff

Geoff 42 · 2020-04-18 14:04:29

One thing which I have noticed is that a couple of filesystems are not being unmounted correctly on shutdown. I did report this on the Systems thread, but as I look into this, it seems to me that this is a better location to report it.

In /var/log/rc.log it reports that /tmp, /var and /home failed to unmount as the target is busy. Then on booting fsck has to recover the journal on /var and /home. This only happens when using openrc-init and not with SysV init.

With SysV init being used to start OpenRC, it uses /etc/init.d/rc to get openrc running.
When shutting down rc 0 calls openrc off and then openrc shutdown. This gets logged as rc off and appears to run through default stopping the entries in reverse order. This is because it is leaving the default runlevel and stops any services not in the new runlevel, i.e. off.

Compared to using openrc-init, where it is logged as rc shutdown. This also runs through the entries in default and stops them in reverse order. It then appears to take the entries in sysinit, again, stopping them in reverse order. This includes the umount[nfs|fs|root] scripts, which are notionally started as they are dependencies of other scripts.

The dependencies do my head in. Which way round are the dependencies? The LSB headers are described in the Debian docs :-

https://wiki.debian.org/LSBInitScripts/
https://wiki.debian.org/LSBInitScripts/ … yBasedBoot

In the LSB headers the Required-Start: and Required-Stop: tend to be the same-ish.

Required-Start: Lists those facilities that must start before this script.
Required-Stop: Lists those facilities that must still be running while this script is stopped.

X-Start-Before: Lists the facilites as though they had Should-Start: this script. I think that this means this script should start before(?) the listed facilities.
X-Stop-After: I think this means this script should stop after(?) the listed facilities have been stopped.

Although OpenRC does not use insserv, it is interesting to use it to see the dependencies also using dotty, as described in the Debian docs. You probably have insserv anyway, but you might need to install dotty :-

apt install insserv graphviz

then as yourself :-

cd /tmp
/usr/share/insserv/check-initd-order -g > boot.dot
/usr/share/insserv/check-initd-order -g -k > reboot.dot
dotty boot.dot &
dotty reboot.dot &

Note that you should "read" the graph for reboot/halt from right to left.

Coming up, it brings up the network and mounts the file systems. $remote_fs is taken as the milestone that the FS is available. Then the logger is started and $syslog is taken as the milestone to start the daemons. $all is the milestone that it has all been done so that local stuff can be started.

Going down, the daemons are stopped and then $remote_fs is the milestone to be stopped. This uses sendsigs to stop stuff and then stops rsyslog and then unmounts nfs and stops the networking. After that $local_fs is stopped and finally umountroot.

Comparing the dotty graphs lvm2 has :-

# X-Start-Before: checkfs mountall

and lvm2 appears to be started before mountall has started.

rsyslog has :-

# X-Stop-After: sendsigs

and rsyslog appears to be stopped after sendsigs has been stopped.

I am getting a clearer picture, but more head scratching is required...

Geoff

Geoff 42 · 2020-04-19 08:33:34

The runlevels passed through, when using SysV init, are :-

sysinit, default, off, shutdown

with openrc-init :-

sysinit, boot, default, shutdown

It would appear that the simplest thing to do would be to add in the runlevel off before shutdown in openrc-init.

Both boot and shutdown runlevels are empty. off has the entries savecache, sendsigs and umount[nfs.sh|fs|root]. I think that moving to off will cause the entries in default to be stopped, apart from those also in off. The umount* ones will therefore not be stopped, as they are already "started" as they are dependents on entries in default. These will be stopped when moving to shutdown. Their start routines are no-ops, only stop does anything. In the case of umount, I think this is obvious. The savecache entry does its thing on start.

Of course, the simplest thing is not necessarily the best thing to do! Is it important to keep OpenRC as close as possible to the original, or is compatibility with SysV init more important. Debian has put in quite a bit of effort to bring in SysV init compatibility.

Geoff

Geoff 42 · 2020-04-19 15:58:12

I have now added a line to openrc-init.c to enter the runlevel off before it moves to shutdown and have rebuilt and reinstalled OpenRC. With openrc-init being used instead of SysV init, /var/log/rc.log is now virtually the same as with SysV init, apart from also entering the boot runlevel on the way up. Most importantly, the file systems appear to have been shutdown cleanly and are logged as being clean on the way up.

As it shuts down, there is a warning message on the screen, but I have not been able to read it yet, but will work on this.

Geoff

Geoff 42 · 2020-04-20 08:58:42

I have managed to see a bit of the warning message. It is that it failed to shutdown a couple of processes related to RPC*. openrc-init is quite neat in that it runs pstree to show you what is running, although the info disappears before you can study it!

As my desktop is used for running VMs under Xen, it uses lvm to handle the disks for the VMs. The desktop also boots from BIOS. I have checked my laptop, which boots on the real hardware and boot with UEFI. Before applying my above mod, there was also the problem with the file systems not shutting down properly, particularly /home. This only shows as it boots up. The logging is a bit different from my desktop, and the shutdown runlevel does not get logged. The other logging oddity is that the sysinit runlevel gets logged twice. The documentation seems to suggest that sysinit won't get logged at all!

Geoff

* edited to add that the RPC processes were rpc.statd and rpcbind

Last edited by Geoff 42 (2020-04-23 13:44:18)

Geoff 42 · 2020-04-21 07:48:27

I have now installed and tested my new version of OpenRC, with the new openrc-init, on my laptop and can confirm that it has cured the problem with shutting down the file systems properly. I have also checked my desktop, booting on the bare metal, instead of on the Xen hypervisor and it is, also, still working correctly.

Geoff

Geoff 42 · 2020-04-23 13:39:58

The patch which I used to put the runlevel off before shutdown looks like this :-

cat 0010-init-runlevel-off.patch

Add in the runlevel "off" before "shutdown" in openrc-init.c
--- a/src/rc/openrc-init.c
+++ b/src/rc/openrc-init.c
@@ -108,6 +108,7 @@ static void handle_shutdown(const char *
{
struct timespec ts;
+ do_openrc("off");
do_openrc(runlevel);
printf("Sending the final term signal\n");
kill(-1, SIGTERM);

Geoff

Geoff 42 · 2020-04-24 14:03:19

I finally managed to photograph the shutdown on the console and it can be seen at

http://kulcha.x10host.com/shutdown.jpg

The running of pstree is from sendsigs rather than from openrc-init itself.

After it enters the runlevel shutdown it runs the sendsigs script with stop, which then returns a warning, although I don't see anything really wrong. It then goes on to close things down from the sysinit runlevel, such as the network and unmounting the filesystems.

Geoff

Geoff 42 · 2020-05-15 18:15:19

I requested that version 0.42.1 of Openrc should be packaged in Debian :-

https://bugs.debian.org/cgi-bin/bugrepo … bug=958820

and I have had a positive reply and now 0.42-1 has come through
from sid to Ceres. I have not yet had a chance to test this,
but will report when I have.

Geoff

The officially official Devuan Forum!

#1 2020-03-15 16:09:11

Newer versions of Openrc

#2 2020-03-15 20:22:34

Re: Newer versions of Openrc

#3 2020-03-16 10:07:46

Re: Newer versions of Openrc

#4 2020-03-16 10:22:25

Re: Newer versions of Openrc

#5 2020-03-16 15:37:37

Re: Newer versions of Openrc

#6 2020-03-17 11:06:09

Re: Newer versions of Openrc

#7 2020-03-22 17:22:48

Re: Newer versions of Openrc

#8 2020-03-28 16:34:38

Re: Newer versions of Openrc

#9 2020-04-18 14:04:29

Re: Newer versions of Openrc

#10 2020-04-19 08:33:34

Re: Newer versions of Openrc

#11 2020-04-19 15:58:12

Re: Newer versions of Openrc

#12 2020-04-20 08:58:42

Re: Newer versions of Openrc

#13 2020-04-21 07:48:27

Re: Newer versions of Openrc

#14 2020-04-23 13:39:58

Re: Newer versions of Openrc

#15 2020-04-24 14:03:19

Re: Newer versions of Openrc

#16 2020-05-15 18:15:19

Re: Newer versions of Openrc

Board footer