The officially official Devuan Forum!

You are not logged in.

#1 Re: News & Announcements » Beowulf Beta is here! » Yesterday 09:57:51

Sorry, I'm getting a bit OT here, but I have discovered how to increase the resolution of the vnc display of a Dom0 under Xen.

https://wiki.xenproject.org/wiki/Xen_Co … console.3F

I needed to add an item to the kernel command line, which in practice means adding it to the Xen config file for the VM. Thus, for booting from the installed image the "extra" line now looks like this :-

# Boot info for the installed OS :-

bootloader = '/usr/lib/xen-4.11/bin/pygrub'
extra      = 'console=hvc0 xen-fbfront.video=32,1600,1000'
root       = '/dev/xvda2 ro'

Obviously, you may want to adjust the size from 1600x1000 to suit your set up.

The only problem is that the mouse scaling goes wrong. The real cursor and the vnc cursor coincide at the top left hand corner, but as you move down and right, the vnc cursor moves further than the real cursor!

Geoff

#2 Re: News & Announcements » Beowulf Beta is here! » 2020-05-26 10:52:49

Geoff 42 wrote:

One problem is the root password not working. I wonder whether this is a problem with keyboard mapping changing betweeen install and use, between C and en-gb. (Or is it en-us and en-gb?)

I believe that this was probably my fault. I have tried setting the keymap in the configuration file for the VM, and the VNC display via qemu now uses the key mapping I want. In my case this line in the Xen config file for this VM is :-

# Graphic display

vfb         = [ 'vnc = 1, keymap = "en-gb"' ]

Geoff

#3 Re: Hardware & System Configuration » CPU frequency scaling on Devuan Beowulf RC » 2020-05-26 06:37:09

Head_on_a_Stick wrote:

Alpine Linux have an OpenRC init script but you would have to switch to /sbin/openrc-init as PID1: https://git.alpinelinux.org/aports/tree … mald.initd

I think that you could use OpenRC as installed, which uses SysVinit as PID 1. I feel that using openrc-init as PID 1 is not quite there yet, as there are problems shutting down.

https://dev1galaxy.org/viewtopic.php?pid=21756#p21756

Geoff

#4 Re: News & Announcements » Beowulf Beta is here! » 2020-05-24 13:59:57

I tried the desktop live and the netinstall isos :-

devuan_beowulf_3.0.0_RC_amd64_desktop-live.iso
devuan_beowulf_3.0.0_RC_netinstall-amd64.iso

I tried them as DomU under Xen. While the straightforward way would be to use debootstrap, I wanted to try using the installers on the isos.
The desktop live install was very straight forward, although I report a few things to watch. One is mainly related to Xen. I don't know if the others are.

I failed to get netinstall to go passed the disks.
Xen passes over 2 disk areas

/dev/xvda1 swap
/dev/xvda2 /

While the live desktop can just use them, the netinstall wants to repartition them and fails.

Things to watch

Under Xen, the framebuffer can be passed through qemu to a vncserver, which is running in the host OS (Dom0).
You can then simple run:-

vncviewer :0

in Dom0 and you are presented with the login under slim.
The only problem is the size, which is 800x600. Fortunately you can select larger or smaller fonts from the XFCE desktop. I have not been able to work out how to make this framebuffer larger, so I install vnc4server on the new OS and ssh in to it, setting up a tunnel with

ssh -L 5901:localhost:5901 beowulf

and running the vncserver with :-

vncserver -geometry 1600x1000

Then, back on Dom0 I can then run

vncviewer :1

This works well, but does not test slim.

One problem is the root password not working. I wonder whether this is a problem with keyboard mapping changing betweeen install and use, between C and en-gb. (Or is it en-us and en-gb?)
One workround is to use a simpler temporary password which avoids characters that change between mappings and then setting the real password once fully installed.

If installing openrc, then it has to do a lot of dependency loop breaking. Most include live-tools, so if you are not using them, uninstall live-tools.

dmesg reports :-

udevd[1057]: specified group 'kvm' unknown

so add kvm to /etc/group. I don't know if this is related to my running under Xen.

It is able to use the disk partitions given it by Xen.
/dev/xvda1 swap
/dev/xvda2 /
when asked to select which partition you want to use, it is important to select one! I was offered only one partition for swap. It is important to select it before continuing as I couldn't see anyway to go back and try again!

Geoff

#5 Re: DIY » Newer versions of Openrc » 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

#6 Re: DIY » Newer versions of Openrc » 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

#7 Re: DIY » Newer versions of Openrc » 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

#8 Re: DIY » Newer versions of Openrc » 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

#9 Re: DIY » Newer versions of Openrc » 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

#10 Re: DIY » Newer versions of Openrc » 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

#11 Re: DIY » Newer versions of Openrc » 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

#12 Re: DIY » Newer versions of Openrc » 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

#13 Re: Hardware & System Configuration » /var & /home not unmounting correctly under OpenRC » 2020-04-18 13:32:30

I have been looking into this and scratching my head!

As my set-up is a bit experimental, I will take this over to my earlier thread under DIY, where I discussed using newer versions of OpenRC :-

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

Geoff

#14 Hardware & System Configuration » /var & /home not unmounting correctly under OpenRC » 2020-04-16 10:47:27

Geoff 42
Replies: 1

I am runnning OpenRC in Beowulf.

When I look in the log file /var/log/rc.log I can see that /home and /var are failing to unmount properly on shutdown and that on the following boot, they are both recovered from their journals.

I would assume that things are not being shutdown in the correct order and/or the dependencies are incorrect. I see that umountfs is in /etc/runlevel/off I also see that /etc/runlevel/shutdown is empty.

With some pruning, the log file looks like this :-

[....] Unmounting temporary filesystems...umount: /tmp: target is busy.
[FAILfailed.
[....] Deactivating swap...[ ok done.
[....] Unmounting local filesystems...umount: /var: target is busy.
umount: /home: target is busy.
[FAILfailed.
[....] Stopping hot-plug events dispatcher: udevd[ ok .

rc shutdown logging stopped at Wed Apr 15 20:49:49 2020

followed by :-

rc sysinit logging started at Thu Apr 16 07:34:11 2020

   OpenRC 0.42.1 is starting up Linux 4.19.0-8-amd64 (x86_64) [XENU]

* /proc is already mounted

etc, etc...

[....] Activating swap...[ ok done.
[....] Setting up LVM Volume Groups...[ ok done.
[....] Checking file systems...fsck from util-linux 2.33.1
/dev/mapper/SSD0-home: recovering journal
/dev/mapper/SSD0-home: clean, 169879/2531328 files, 7506728/10125312 blocks
var: recovering journal
var: clean, 18460/610800 files, 1319940/2441216 blocks
/dev/mapper/HDD0-Flightgear: clean, 48736/155648 files, 290643/600064 blocks
boot: clean, 358/64000 files, 206879/256000 blocks
/dev/mapper/HDD0-archive: clean, 270513/21626880 files, 32926707/86507520 blocks
fsck.fat 4.1 (2017-01-24)
/dev/mapper/HDD0-xen--boot: 3 files, 9637/261629 clusters
[ ok done.
[....] Cleaning up temporary files... /tmp[ ok .
[....] Mounting local filesystems...[ ok done.

etc...

This is not the standard set-up as I have replaced SysV init with openrc-init.

Geoff

#15 Re: News & Announcements » Beowulf Beta is here! » 2020-04-10 10:49:53

Thank you!

I had failed to spot that the web pages, themselves, were beta!

Geoff

#16 Re: News & Announcements » Beowulf Beta is here! » 2020-04-10 08:21:18

golinux wrote:

It already is in a "normal" installation:
https://beta.devuan.org/os/packages

The above link says :-

Devuan 3.0.0 Beowulf (stable)

I thought that ASCII is still stable and that Beowulf is testing.

Have I missed an announcement?

Geoff

#17 Re: Hardware & System Configuration » Having trouble with tmpfs » 2020-04-02 15:39:26

Have you looked in /etc/default/tmpfs?

You can set things like :-

# mount /tmp as a tmpfs.  Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled).  /tmp may also be
# configured to be a separate mount in /etc/fstab.
RAMTMP=yes

Geoff

#18 Re: DIY » Newer versions of Openrc » 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

#19 Re: DIY » the benefits of highlighting console output » 2020-03-26 08:32:47

The default is color=auto according to man dmesg. The man page also has a section on COLORS and it apparently also uses settings in /etc/terminal-colors.d/dmesg.disable. It refers us to man terminal-colors.d. It would appear that it is possible to have some control over what colours are used for different parts of the output.

I use rxvt as my terminal and it is able to display colours.

Geoff

#20 Re: DIY » the benefits of highlighting console output » 2020-03-25 15:51:35

I think that dmesg auto detects whether the output is to the screen or not and turns on colour or not!
There is a switch --color=[auto|always|never], so I think what you need is :-

dmesg --color=always | cat

Geoff

#21 Re: DIY » Newer versions of Openrc » 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

#22 Re: DIY » Newer versions of Openrc » 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.

#23 Re: DIY » Newer versions of Openrc » 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

#24 Re: DIY » Newer versions of Openrc » 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

#25 Re: DIY » Newer versions of Openrc » 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

Board footer

Forum Software