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

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

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

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 :-

Rebooting then worked successfully. The console messages included :-

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

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

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

VLC

I had downloaded a couple of programs from the BBC with get_iplayer and them tried viewing them with VLC and the video did not work. If I fiddled with the settings, VLC seemed to hang. I have now tried viewing with Kodi and these programs display correctly. I believe that VLC was working correctly before I upgraded to Beowulf.

Geoff

Postgresql

The section about setting the path for Postgresql is unnecessary. There are a set of wrapper scripts in /usr/bin which sort out the version for you, so that you do not need to add anything special to your path.

Geoff

What should I have done

Make sure that there is enough disc space!

If you have /var as a separate partition you may need to tidy the apt cache :-

apt-get autoclean

If /boot is a separate partition you may need to remove a few old kernels.

Apt is reasonably resiliant and does check the disk space and will not run if there is not enough, although grub does not spot the lack of space in /boot until the upgrade is under way.

Wine and i386

There do seem to be difficulties with Wine and i386 on an amd64 installation.

If you do not need it, remove it. If you do need it, study this :-

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

upower

I think that there is no alternative to manually forcing the version of upower as the old version has "1:" in front of the version number, which makes it look newer that the real new one! It therefore looks like a downgrade, but this is what you should accept.

Postgresql

I have included the path to the Postgresql commands in my .profile and this needed to be updated for the new version so that .profile includes the lines :-

if [ -d "/usr/lib/postgresql/11/bin" ] ; then
    PATH="/usr/lib/postgresql/11/bin:$PATH"
fi

Geoff

Postgresql

As I have a small Postgresql database on my desktop machine, I wanted to check that this would be ok when I upgrade. I also use LibreOffice Base for adding new info to the database using SDBC.

I installed Postgresql on my Beowulf laptop, along with libreoffice-sdbc-postgresql.
On the ASCII desktop, I dumped the database as user "postgres" as given in the man page with :-

pg_dumpall -c > db.out

The "-c" adds commands to clean out anything in the new database before adding the dumped data.

On the Beowulf laptop, as user postgres, I restored this data with :-

psql -f db.out postgres

This worked and having also copied over the .odb file I tried accessing the database from LibreOffice Base, which also "just worked".

This has given me confidence that should there be any problems with the upgrade, that I have a work-a-round.

Geoff

Reviewing what I did earlier at I think that simply running OpenRC under Beowulf should be fairly straightforward, whereby it still uses SysV init to get things started, but uses OpenRC to start up services and daemons.

Using openrc-init to replace SysV init completely is a bit more complicated, not helped by a bug in version 0.40 which doesn't sequence things correctly. This has been fixed by version 0.41.2, although this does not appear to be available via Deian/Devuan.

It is possible to compile v 0.41.2 and move in openrc-init, as detailed at :-

https://dev1galaxy.org/viewtopic.php?pid=15539#p15539

It is also necessary to use openrc-shutdown instead of shutdown.

I notice that openrc has moved on to version 0.42.1. I have not yet tried this and, indeed, have only tried openrc-init from 0.41.2. If Devuan is getting OpenRC from Debian, then I wonder how quickly it is likely to get updated. Might we need to get it directly from the authors?

Geoff

While LXQt is running nicely under ASCII, the other point to mention is that it also stops nicely, in that you can shutdown via the leave options in the menu. I am running OpenRC. Under ASCII, SysV init is still used but control is passed to openrc to start all of the other processes.

On my laptop, under Beowulf, OpenRC ships with a replacement for SysV init, and I am using this replacement. I cannot recall whether this is how it is installed, or whether I had to configure it to do that. Anyway, this affects how the system id shut down. If you just run shutdown, OpenRC seems to notice that things are stopping and seems to restart them. There is a replacement /usr/bin/openrc-shutdown which works correctly. There is just the question of how you run it from the GUI. I have hacked up a very crude pop-up with xmessage, which doesn't look very good, but does work. I am just checking what I did, as it was some time ago!

Geoff