I now use lxqt-sudo as my replacement for gksu.

Geoff

Investigating the x2apic report in dmesg :-

I added intremap=no_x2apic_optout to GRUB_CMDLINE_LINUX_DEFAULT
in /etc/default/grub and ran update-grub.

After a reboot, dmesg reports :-

This is referred to at :-

https://lkml.org/lkml/2011/7/31/201

Geoff

I had a look at the DMAR errors and found this :-

https://bugzilla.kernel.org/show_bug.cgi?id=202723

which suggests

intel_iommu=igfx_off

This didn't stop the errors but

intel_iommu=off

does now stop all of the DMAR errors in dmesg.
I added this in /etc/default/grub to

GRUB_CMDLINE_LINUX_DEFAULT="earlyprintk=vga,keep net.ifnames=0 init=/sbin/openrc-init intel_iommu=off"
and then ran update-grub.
There is documentation about this at :-

https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB

Geoff

I did a fresh netinstall of Beowulf on a Xen VM (Dom0).
I had installed claws-mail, but that was about all and
then upgraded it to Chimaera. This went with no problems.

So I then tried upgrading my laptop. I can't remember
how it got to Beowulf, but probably started with Debian
and migrated via Jessie, ASCII to Beowulf.

Trying to upgrade with apt suggested some problems, so
I used aptitude, which suggested a way round the incompatibilities.
I accepted these and let it proceed. It had almost finished but
ended with :-

I ran aptitude full-upgrade again and it removed fdisk.
A further run ended without doing anything.

I then then tried to reboot, although I am running OpenRC
and have replaced SysV init with openrc-init. The reboot
failed to shut down, so I did sync;sync and hit the power
button. After this it booted ok and I have since been
able to shutdown and to reboot ok.

I am running Postgresql. This needs some action on upgrades,
but this failed as version 12 had failed to install! All I
needed to do was install postgresql v12 (I used Synaptic).
Then I could do the upgrade from 11 to 12 and then remove v11.

I have spotted some messages in red from dmesg. These seem
to suggest problems with firmware. I wonder whether these
may be related to the new kernel. Linux version 5.6.0-2-amd64
Most of these messages seem to involve firmware or DMAR.

dmesg | grep -i firm

I guess that the regulatory.db is related to the wi-fi

dmesg | grep -i DMAR

I must try booting with an older kernel to check that these
messages do not occur there.

I had no problems with polkit.

Geoff

netinstall of Beowulf

I have managed to install Beowulf under Xen using the netinstall iso,
devuan_beowulf_3.0.0_netinstall-amd64.iso

After some intial difficulty with partitioning the disk used by Xen
I now have it running.

I had already allocated two chunks of file space using lvm. On
my machine these were :-

As root check the config is set up :-

cd /etc/xen
cat net.cfg

With this file set up and the iso mounted we can boot the netinstaller, as root :-

xl create net.cfg -c

select languages etc.
set up host name etc.
For the disk set up I selected "manual"
The disk had been used and I set up partition 1 on xvda2
as ext4 for /
This worked.

If it doesn't work try this ...
disk set-up choose <Go Back>
we get the main menu, choose "Execute a shell"

fdisk -l
mkfs.ext4 -n -L root /dev/xvda2
mkfs.ext4 -L root /dev/xvda2
mkswap -L swap /dev/xvda1

exit back to the menu.
select partition the disk and select manual.

Continue here ...
select the partition under /dev/xvda2
set up the one partition on /dev/xvda2 as ext4 to use as /
Finish partitioning and write changes to disk
continues to install base system
it couldn't read the CD, tell it to continue
it then goes on to select a repository
and continues
Software selection, I chose
LXQt, SSH and Console productivity
check it has got going
go and make a cup of tea
I then selected openrc as the init system, because I have been playing with it.

Install grub fails
continue with no grub
finishes up and shutsdown

Back on Dom0

xl list
xl destroy net
xl list

Comment out the boot info for the iso and
set up the kernel and ramdisk info in the config file

and comment out the CD/iso.

Now we can boot the installed OS

xl create net.cfg
xl console net

and it boots. So, it doesn't need grub to boot, as you have
pointed Xen at the kernel and initrd.

As yourself run :-

vncviewer :0 &

You should have the Lightdm login screen.
There is a problem with the vnc cursor getting its units
wrong and moving faster than the real cursor, depending
on how large you have made your VNC screen!

Could try :-

grub-install /dev/xvda2

except that grub-install isn't there!

Running Synaptic :-
Only grub-common has been installed.
install grub-pc

but the three packages are installed.

grub-install /dev/xvda2

this fails

grub-mkconfig -o /boot/grub/grub.cfg

This works.

Shutdown and edit the Xen config file to enable PyGrub.

then :-

xl create net.cfg -c

This then boots as expected. It does set the screen to 24x80 but you
can choose your kernel etc. If all is well and you just want to
boot the standard kernel use this and avoid the 24x80 screen :-

xl create net.cfg
xl console net

To get VNC working properly (i.e. with the cursor behaving) :-

On the new VM (net)

apt install vnc4server

Then from Dom0 as yourself :-

ssh -L 5901:localhost:5901 net

and on "net" (DomU)

vncserver -geometry 1600x1000

leave this window running to keep the ssh tunnel open.

and back on the host OS (Dom0)

vncviewer :1

You should have a nice big screen where the cursor works
properly and where you can copy and paste with Dom0 windows.
It does not test the lightdm login screen, as you are already
logged in when you run vncserver.

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

Geoff

I tried the desktop live and the netinstall isos :-

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

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

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

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

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

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

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.

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

and lvm2 appears to be started before mountall has started.

rsyslog has :-

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

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

Geoff