The officially official Devuan Forum!

You are not logged in.

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Newer versions of Openrc

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)

Offline

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

Head_on_a_Stick
Member
From: London
Registered: 2019-03-24
Posts: 556  
Website

Re: Newer versions of Openrc

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

"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher." — Antoine de Saint-Exupéry

Offline

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Re: Newer versions of Openrc

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

Offline

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Re: Newer versions of Openrc

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

Offline

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Re: Newer versions of Openrc

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)

Offline

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Re: Newer versions of Openrc

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)

Offline

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Re: Newer versions of Openrc

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

Offline

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

Geoff 42
Member
Registered: 2016-12-15
Posts: 312  

Re: Newer versions of Openrc

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

Offline

Board footer