The officially official Devuan Forum!

You are not logged in.

#1 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-27 13:48:02

It would appear that libc6 version 2.31-13+deb11u5 has now reached chimaera-updates.

apt policy libc6

libc6:
  Installed: 2.31-13+deb11u5
  Candidate: 2.31-13+deb11u5
  Version table:
*** 2.31-13+deb11u5 500
        500 http://deb.devuan.org/merged chimaera-updates/main amd64 Packages
        100 http://deb.devuan.org/merged chimaera-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.31-13+deb11u4 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages

hence solving the original query.

Geoff

#2 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-23 14:35:11

I have now tried your version with :-

Package: *
Pin:  release a=chimaera-proposed-updates
Pin-Priority: 100

and it does not change the priority :-

apt policy libc6

libc6:
  Installed: 2.31-13+deb11u5
  Candidate: 2.31-13+deb11u5
  Version table:
*** 2.31-13+deb11u5 500
        500 http://deb.devuan.org/merged chimaera-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.31-13+deb11u4 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages

while :-

Package: *
Pin:  release n=chimaera-proposed-updates
Pin-Priority: 100

does change the priority :-

apt policy libc6

libc6:
  Installed: 2.31-13+deb11u5
  Candidate: 2.31-13+deb11u5
  Version table:
*** 2.31-13+deb11u5 100
        100 http://deb.devuan.org/merged chimaera-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.31-13+deb11u4 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages

My original version also included o=Devuan which also worked, as above.
I originally used n= rather than a= as the output from apt policy gave this :-

...
100 http://deb.devuan.org/merged chimaera-proposed-updates/main amd64 Packages
     release v=4.0.0,o=Devuan,a=stable-proposed-updates,n=chimaera-proposed-updates,l=Devuan,c=main,b=amd64
     origin deb.devuan.org
...

and I wanted to use chimaera rather than stable, which generally seems to be the recommended approach.

#3 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-22 10:24:02

I now have proposed-updates enabled and have set its priority to 100, so that it will not pull in stuff from there without being told to!

My sources.list looks like this :-

cd /etc/apt
grep -v '#' sources.list | grep -v '^$'

deb http://deb.devuan.org/merged/ chimaera non-free contrib main
deb http://deb.devuan.org/merged/ chimaera-security non-free contrib main
deb http://deb.devuan.org/merged/ chimaera-updates non-free contrib main
deb http://deb.devuan.org/merged/ chimaera-proposed-updates non-free contrib main

cat preferences.d/99devuan-proposed-updates 

Package: *
Pin:  release o=Devuan, n=chimaera-proposed-updates
Pin-Priority: 100

apt policy libc6

libc6:
  Installed: 2.31-13+deb11u5
  Candidate: 2.31-13+deb11u5
  Version table:
*** 2.31-13+deb11u5 100
        100 http://deb.devuan.org/merged chimaera-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.31-13+deb11u4 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages

I think that it is set up correctly and that I could, similarly, add in backports with a priority of 100.

Geoff

#5 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-21 07:16:33

I have now upgraded my system and it seemed to go smoothly.

Geoff

#6 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-21 06:55:13

Indeed, if I change devuan for merged in sources.list, then following an update, I can see libc6 with version u5.

I presume that it is safe to proceed with that and that there is an error on the web page :-

https://www.devuan.org/os/packages

Geoff

#7 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-21 06:48:14

I thought that I should carefully check my sources.list.

I notice that I have :-

deb http://deb.devuan.org/devuan/ chimaera-proposed-updates main contrib non-free 

The important point being that it is using devuan rather than merged, which does follow the advice in :-

https://www.devuan.org/os/packages

but I thought that I should check that it really should be devuan rather than merged.

#8 Re: Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-20 15:29:41

Thank you. You are right that I am still on u3.

With chimaera-proposed-updates enabled apt policy reports that it has a priority of 500 like the rest of the repo, while for libc6 :-

apt policy libc6

libc6:
  Installed: 2.31-13+deb11u3
  Candidate: 2.31-13+deb11u4
  Version table:
     2.31-13+deb11u4 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages
*** 2.31-13+deb11u3 100
        100 /var/lib/dpkg/status

When I ask for it as you suggest I get :-

apt -t chimaera-proposed-updates install libc6

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libc-dev-bin libc6:i386 libc6-dev
Suggested packages:
  glibc-doc glibc-doc:i386 locales:i386
Recommended packages:
  libc-devtools libnss-nis libnss-nisplus libnss-nis:i386 libnss-nisplus:i386
The following packages will be upgraded:
  libc-dev-bin libc6 libc6:i386 libc6-dev
4 upgraded, 0 newly installed, 0 to remove and 138 not upgraded.
Need to get 0 B/8,213 kB of archives.
After this operation, 229 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
critical bugs of libc6 (2.31-13+deb11u3 → 2.31-13+deb11u4) <Resolved in some Version>
b1 - #1019855 - Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system (Fixed: glibc/2.31-13+deb11u5 glibc/2.35-2)
critical bugs of libc6:i386 (2.31-13+deb11u3 → 2.31-13+deb11u4) <Resolved in some Version>
b2 - #1019855 - Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system (Fixed: glibc/2.31-13+deb11u5 glibc/2.35-2)
Summary:
libc6(1 bug), libc6:i386(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n

#9 Installation » [SOLVED] libc6 bug fix has not reached chimaera-proposed-updates » 2022-10-20 09:53:48

Geoff 42
Replies: 13

when I attempted an update with

apt update
apt upgrade

I got the following warning :-

critical bugs of libc6 (2.31-13+deb11u3 → 2.31-13+deb11u4) <Resolved in some Version>
b4 - #1019855 - Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system (Fixed: glibc/2.31-13+deb11u5 glibc/2.35-2)

My system has 4th gen Intel Core CPUs, so this looks a bit serious.

I have watched the bug report :-

https://bugs.debian.org/cgi-bin/bugrepo … ug=1019855

and it appears that this has now been fixed and is available in version: 2.31-13+deb11u5 of glibc/libc6.

When I look at the Devuan package info at

https://pkginfo.devuan.org/cgi-bin/poli … 6&x=submit

it seems to report that 2.31-13+deb11u5 is available in chimaera-proposed-updates.

I have added chimaera-proposed-updates to the repositories and updated, however, instead of being at u5 it is still at u4, which has the bug. The bug report had the fix on Fri 14 Oct, which is nearly a week ago. How long should it take for the fix to reach chimaera-proposed-updates?

All the best

Geoff

#10 Re: Other Issues » [SOLVED] Runit - sym-linking sv » 2022-03-23 14:57:55

I have now got a run script working for Xen and will report separately.

The use of sym-linking sv, taken from the link xinomilo gave above, seems to be as follows, assuming you have the foo daemon (food) working via a Runit run file :-

/etc/init.d/food stop
dpkg-divert --add /etc/init.d/food
mv /etc/init.d/food /etc/init.d/food.distrib &&
   ln -s /usr/bin/sv /etc/init.d/food
update-service --add /etc/sv/food

you can then use either of the following styles of command :-

sv status food

or

/etc/init.d/food status

to access the foo service under Runit.

Geoff

#11 Re: Other Issues » [SOLVED] Runit - sym-linking sv » 2022-03-22 16:47:58

OK, thank you for that link. I think it is saying that Runit still requires a proper Runit setup for the service, but you can have it controlled as though it were a SysV init script.

I have not found a Runit setup for xen and have been trying to convert the SysV init script into a Runit run script. To stop it looping I have added

sv once xen

which has the desired effect of stopping the looping when it is not booted on Xen, but more testing is required ;-)

Geoff

#12 Other Issues » [SOLVED] Runit - sym-linking sv » 2022-03-22 14:48:20

Geoff 42
Replies: 3

xen services seem a bit tricky to set up as it does some setting up and then runs 3 daemons.
If the OS is not running under the Xen hypervisor, then the SysV init script exits.
When I try and do this under Runit, the run script exits, looping once a second.

Can I get Runit to run the old SysV init script?

The man page says :-

The sv program can be sym-linked to /etc/init.d/ to provide an LSB init script interface. The service to be controlled then is specified by the base name of the ‘‘init script’’.

I don't know how to interpret that, so I'll tried this :-

cd /etc/service
ln -s /usr/bin/sv xen
ls -alF xen
lrwxrwxrwx 1 root root   11 Mar 22 10:32 xen -> /usr/bin/sv*

and the xen script exists in /etc/init.d

ls -alF /etc/init.d/xen
-rwxr-xr-x 1 root root 7929 Jul 10  2021 /etc/init.d/xen*

Test to see if it works :-

sv status xen
fail: xen: unable to change to service directory: not a directory

So, no, that is not the way to do it and it may well be that this would never do what I was after,
but I really don't understand the man page bit about sym-linking to /etc/init.d. Does anyone?

#13 Re: Other Issues » Runit and backwards compatibility » 2022-03-14 11:52:03

It would appear that the links to, e.g. https://salsa.debian.org/runit-team/run … /tree/next do not work from Pale Moon,
but do work from Falkon.

Edit: and it works in Chromium.

Geoff

#14 Re: Other Issues » Runit and backwards compatibility » 2022-03-14 10:49:44

Lorenzo!

thank you for your detailed response to my comments.

Before I get onto the details, might I ask about the salsa.debian.org URL,
as it opens, but does not display the actual content for me. Does it need me to create an account?

The situation with /etc/sv versus /etc/service is interesting and may depend on your
point of view. I am currently working through services and converting them from SysV to Runit.
Therefore, I would like the SysV service to keep running until I have the Runit version correctly
set up, in which case the use of /etc/service seems to work better for me. But I accept your
point about disabling a service, once everything is set up.

just use 'servicename-wip' and keep it disabled by default untill your service is ready for use.

I'm sorry, but I don't understand the bit about 'servicename-wip'. (Ah! does 'wip' stand for 'work in progress', so that it doesn't match the real name?)

As for a dependency, I see that the Man page for sv says that sv start is the same as sv up but that it waits for the command to take effect, calling the check script if present. This would seem to mean that sv start dbus is the same as sv up dbus && sv check dbus. I assume that the || exit 1 will cause Runit to recognise that the dependency has not started and retry later (1s ?).

I have used the run line :-

exec dbus-daemon --system --nofork --nopidfile

and have a check file :-

#!/bin/sh
exec dbus-send --system / org.freedesktop.DBus.Peer.Ping > /dev/null 2> /dev/null

I may have copied these from Void Linux.

Thank you for all of your work on Runit.

Geoff

#15 Re: Other Issues » Runit and backwards compatibility » 2022-03-13 16:33:15

With the services which are running under runsvdir, I have tried indicating when they need another service to have been started. Thus I have :-
avahi-daemon, cups, ddclient, elogind
depending on dbus.

As mentioned earlier there seem to be 2 different versions of this

sv start dbus

or

sv check dbus >/dev/null || exit 1

I have seen messages in the logs where dbus fails to start correctly the first time, only to start correctly 1s later, thus :-

2022-03-11_18:11:17.33232 warning: dbus: unable to open supervise/ok: file does not exist
2022-03-11_18:11:17.34982 Found user 'avahi' (UID 104) and group 'avahi' (GID 111).
2022-03-11_18:11:17.34983 Successfully dropped root privileges.
2022-03-11_18:11:17.34983 avahi-daemon 0.8 starting up.
2022-03-11_18:11:17.34983 dbus_bus_get_private(): Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
2022-03-11_18:11:17.34983 WARNING: Failed to contact D-Bus daemon.
2022-03-11_18:11:17.34983 avahi-daemon 0.8 exiting.
2022-03-11_18:11:18.33051 ok: run: dbus: (pid 2007) 1s
2022-03-11_18:11:18.33159 Found user 'avahi' (UID 104) and group 'avahi' (GID 111).
2022-03-11_18:11:18.33163 Successfully dropped root privileges.
2022-03-11_18:11:18.33173 avahi-daemon 0.8 starting up.
2022-03-11_18:11:18.33227 Successfully called chroot().

This type of message is intermittent and was produced with

sv start dbus

I will try it with

sv check dbus >/dev/null || exit 1

and see if that works better. I assume that this might suppress the warning message if it is redirected to /dev/null, but I will need to look out for the daemon failing and then trying again 1s later and succeeding.

#16 Re: Other Issues » Runit and backwards compatibility » 2022-03-10 20:18:51

Replacing /etc/sv with /etc/service in /lib/runit/run_sysv_scripts did seem to have the expected result that disabling a service in Runit caused it to be started via /etc/rc2.d on a reboot.

If this service then failed to start correctly because of a sequencing problem, then adding e.g. :-

sv start dbus

to the file in rc2.d also failed, probably because runsvdir had not been started yet,
causing the sv command itself to fail.

It was possible to get avahi-daemon to start correctly under Runit by adding the line :-

sv start dbus

to its run file and the sequencing then worked as expected.

#17 Re: Other Issues » Runit and backwards compatibility » 2022-03-10 11:23:24

I have now edited run_sysv_scripts to to use /etc/service instead of /etc/sv and it has not broken anything yet, but I will need to check what happens when I disable services under Runit, etc.

#18 Re: Other Issues » Runit and backwards compatibility » 2022-03-10 10:33:35

Thank you for your helpful observations.

I more or less copied the elogind run file from Void Linux. It starts :-

# elogind doesn't work right if it starts before dbus
sv check dbus >/dev/null || exit 1

which I assume will leave the elogind startup looping until dbus is running, while

sv start dbus

will hang until dbus is running. The latter sounds better. I suppose that that line could be included in an init.d script, although would that work if runsvdir has not been started yet?

Geoff

#19 Other Issues » Runit and backwards compatibility » 2022-03-09 16:46:41

Geoff 42
Replies: 9

The Debian port of Runit has introduced some backwards compatibility, so that it can start services from /etc/init.d if they are not yet set up for Runit. To do this it uses the script /lib/runit/run_sysv_scripts.

This will look through the directory it has been passed (typically /etc/rcS.d and /etc/rc2.d) and it will run the scripts starting with "S" but only run them if they do not exist in /etc/sv. It uses rcS.d for stage 1 and rc2.d for stage 2. This seems reasonable, but there are problems.

I would have thought that all of the services in rcS.d would need to be started as the baseline for the system to be running and that they are probably not started by runsv.

As for stage 2, it starts the scripts in rc2.d if they are not in /etc/sv. It then starts runsvdir, which starts the services set up to run under Runit. There are two problems here. I suspect the /etc/sv is not the correct directory to check against, as the services here have not necessarily been enabled and indeed, people like me may not have finished setting up a service! I suspect that it may be better to check against /etc/service rather than /etc/sv, as those are the ones which have been enabled.

The other problem is that the sequencing may be wrong. So that if you have dbus set up to be run by runit and avahi has not yet been done, then avahi will fail as it will be started by run_sysv_scripts before runsv starts dbus. I am not sure what the answer might be for this.

#20 Other Issues » Runit and background daemons » 2022-02-22 16:35:21

Geoff 42
Replies: 0

Runit is designed to work with daemons that stay in the foreground, so that the daemon may be supervised easily. Many daemons do try and run in the background but there is often an option that can be given to tell it to run in the foreground. Thus ntpd can use the -n (--nofork) option to run in the foreground.

Occasionally, there is a daemon which only runs in the background. I have found noip2 which updates my dynamic IP address. I have not found a way to tell it to run in the foreground. There are one or two things which you can do to handle this.

Runit comes with a program to change the process status (chpst).
This has a number of things it can do, such as changing the user or group it runs as.
The options which are useful here are -l & -L which can open a lock file for writing and obtain an exclusive lock on it, creating the file if necessary. -l will wait for the file to become available, while -L will fail immediately if it is not available.

The file /etc/sv/noip2/run looks like this :-

#!/bin/sh -eu
exec 2>&1

echo "executing /etc/sv/noip2/run"

chpst -L supervise/runlock /usr/local/bin/noip2 || exit 1
exec chpst -l supervise/runlock true

The echo message is logged if logging has been set up.

The daemon noip2 is run by chpst with an exclusive lock on the file /etc/sv/noip2/supervise/runlock

The second instance of chpst is ready to run the command true and waits for the lock file to become available, i.e. when noip2 stops running. When the lock file becomes available the command true will be run, which returns immediately and runit becomes aware that noip2 is no longer running and can take the appropriate actions.

But what happens if we want to stop the daemon? If

sv down noip2

is run then runit will stop the waiting chpst process, but not noip2.
After it has stopped chpst it will then look for the file finish and run it if it exists.
As we know the name of the lock file, we can find the PID of the process which has it open, using lsof, which may need installing.

apt install lsof

We can find the processes which have the lock file open :-

lsof /run/runit/supervise/noip2/runlock

COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chpst   2006   root    3w   REG   0,23        0 1738 /run/runit/supervise/noip2/runlock
noip2   2051 nobody    3w   REG   0,23        0 1738 /run/runit/supervise/noip2/runlock

We could find the PID of the daemon by looking through the output for the process run by nobody
and then printing the second field :-

PID=`lsof /run/runit/supervise/noip2/runlock | grep nobody | awk '{ print $2 }' -`

although awk can do the search as well :-

PID=`lsof /run/runit/supervise/noip2/runlock | awk '/nobody/ { print $2 }' -`

However, a study of the lsof man page shows that there are lots of options available and the -t option just prints out the PIDs

lsof -t /run/runit/supervise/noip2/runlock

2006
2051

Also, there is the -c option which can select the process of a particular command or filter out processes of certain commands with the negation ^. In this case we don't want the chpst process.

lsof -t -c ^chpst /run/runit/supervise/noip2/runlock

2051

which can be incorporated into the file /etc/sv/noip2/finish :-

#!/bin/sh
exec 2&>1

# use lsof to find the process with a lock on our file.

PID=`lsof -t -c ^chpst /run/runit/supervise/noip2/runlock`

echo "executing /etc/sv/noip2/finish. PID = $PID"

[ -z $PID ] && exit 1

# We could do something like "kill -TERM $PID", but in this case "noip2 -K $PID" works.

/usr/local/bin/noip2 -K $PID

This seems to work nicely. With run and finish set up the daemon can be started, supervised and stopped.

#21 Re: Installation » The best init system » 2022-02-13 11:47:25

If your main interest is in having a running system, then go with the default, SysVinit, in the case of Devuan.

If you are interested in playing with the init system, or you are running a service which must be kept going, then Runit and OpenRC are interesting and can supervise the services.
OpenRC is probably easier for setting up new services, with its declarative style of script.
Runit seems to get rave reviews from people who understand the internals, but it does require setting up a directory structure for each service.

It depends a bit on how they are installed, as both Runit and OpenRC can be installed to be started from SysVinit, which takes its initial instructions from /etc/inittab. Runit can add an entry at the end on inittab :-

#-- runit begin
SV:123456:respawn:/etc/runit/2
#-- runit end

While OpenRC replaces /etc/init.d/rcS and /etc/init.d/rc, which are called from inittab.

Both Runit and OpenRC can replace the SysV init, in which case inittab is not referenced.
This has the effect that the gettys would not be started and they must be set up using the features of your new init system. If you install them from scratch, then this may have already been taken care of.

The Runit init does seem to work well.
I did have problems with the OpenRC init, resulting in the system not being shutdown cleanly, so that the file systems needed checking at boot time. When it boots from SysV init, it has an extra run state to pass through and this work nicely and the system shuts cleanly.
I have tried patching the OpenRC init to add this extra run state, but I failed to pursuade the Debian maintainers on this point.

https://dev1galaxy.org/viewtopic.php?id=2788
with details of the patching here :-
https://dev1galaxy.org/viewtopic.php?pid=21180#p21180

Geoff

#22 Desktop and Multimedia » Cursor redraws very slowly » 2022-01-19 11:23:07

Geoff 42
Replies: 0

I have an odd artifact involving the cursor redrawing very slowly
when it changes between cursors, say from the "I" cursor to the
"drag and stretch" cursor. It can take several seconds to complete
the redraw and seems to redraw by random scan lines. This also
similarly affects a certain type of pop-up.

My graphics card is an integrated Intel i915.

This artefact only occurs when I boot using the Xen hypervisor.
Booting on bare metal is ok, but booting with Xen produces this
slow redraw. I am currently on Devuan Chimaera, kernel 5.10.0-10-amd64
and Xen 4.14.4-pre although my failing memory tells me that I
had this effect earlier!

Devuan is booting in paravirtual mode (PV), as the controlling host
(Dom0). When I boot a guest system (DomU), the frame buffer of DomU
uses qemu, which runs in Dom0 and I can connect a vncviewer on
Dom0 to the qemu vncserver to access the X session on the DomU.
In this case the VNC display does not have this artefact.
If, however, I open an ssh connection to DomU and run a vncserver on DomU and
connect to it from Dom0 with a vncviewer, then the artefact
still occurs but to a lesser amount.

I wonder if anyone has encountered the slow redrawing of the
cursor and pop-ups. It would be really wonderful if anyone knows
how this ties in with Xen and even better if you know how to fix it!

Geoff

#23 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-21 14:48:38

Reading the ps man page I discovered the command :-

ps -eo pid,user,start,args

which prints the start time for each process. I spotted that the 30s delay came between some power management daemons and the first user applications (Claws and Pale Moon). I went into :-

Preferences>LXQt settings>LXQt Configuration Centre
and selected the Session Settings.
In Basic settings I turned off Power Management and in
Autostart I turned off Power Manager.
On a reboot there was no delay.
I then turned these power management things back on and at a reboot there was still no delay.
I notice that I am running /usr/bin/xfce4-power-manager, which I don't remember being there before, as well as /usr/libexec/upowerd and /usr/bin/lxqt-powermanagement. I could not guaranty that the xfce one was not there before!

I will leave it as it is and see if the delay really has gone.

#24 Hardware & System Configuration » Chimaera upgrade - no sound » 2021-10-21 09:55:31

Geoff 42
Replies: 0

Following my upgrade to Chimaera, I noticed that sound was not working, in my browser, Pale Moon.
I also noticed that Pulseaudio had become installed. Once I had removed Pulseaaudio I could get sound from VLC, but not from Pale Moon. What was required was a reboot, and then it was working.

Geoff

#25 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-21 08:05:36

I don't know that command! Anyway it reports :-

loginctl session-status
1 - user1 (1026)
           Since: Thu 2021-10-21 08:59:18 BST; 2min 0s ago
          Leader: 3182 (lxdm-session)
            Seat: seat0; vc7
             TTY: tty7
         Service: lxdm; type x11; class user
           State: active

I don't know if that is ok, but it looks sensible to me. (I have edited out my real username)

Geoff

Board footer

Forum Software