The officially official Devuan Forum!

You are not logged in.

#1 Re: Hardware & System Configuration » [Solved] openrc-init failure » 2020-06-19 08:37:14

I have also had a look at getting a newer version of OpenRC running. I have reported on
this under the DIY thread :-

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

A newer version is now available in Ceres, although there remains a bug related to openrc-init during shutdown.

Geoff

#2 Re: Installation » quick note on chimaera installs (attn: fsmithred) » 2020-06-12 10:43:18

Investigating the x2apic report in dmesg :-

[    0.078322] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    0.078323] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.

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

After a reboot, dmesg reports :-

[    0.077685] DMAR: Host address width 39
[    0.077687] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.077694] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 7e1ff0505e
[    0.077697] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.077702] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da
[    0.077705] DMAR: RMRR base: 0x000000dce3d000 end: 0x000000dce4bfff
[    0.077707] DMAR: RMRR base: 0x000000dd800000 end: 0x000000dfffffff
[    0.077711] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.077713] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.077715] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.078240] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.078244] x2apic enabled
[    0.078251] Switched APIC routing to cluster x2apic.
[    0.078815] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1

This is referred to at :-

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

Geoff

#3 Re: Installation » quick note on chimaera installs (attn: fsmithred) » 2020-06-12 08:44:57

Looking further at the Realtek firmware.

The download link at Realtek is for the driver r8152, which we already have, rather than
the firmware. I found this firmware at Google Chromium :-

https://chromium.googlesource.com/chrom … 3/rtl_nic/

I downloaded the tgz file and unpacked it and then copied
rtl8153a-2.fw to /lib/firmware/rtl/

I rebooted and now dmesg has no lines in red and reports :-

dmesg|grep 8153

[    1.990237] usb 2-3: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
[    3.732900] r8152 2-3:1.0: firmware: direct-loading firmware rtl_nic/rtl8153a-2.fw
[    3.764785] r8152 2-3:1.0: load rtl8153a-2 v1 10/23/19 successfully

Geoff

#4 Re: Installation » quick note on chimaera installs (attn: fsmithred) » 2020-06-11 18:41:23

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

#5 Re: Installation » quick note on chimaera installs (attn: fsmithred) » 2020-06-11 15:18:29

Booting an older kernel Linux version 4.19.0-9-amd64

dmesg|grep -i firm

[    0.276745] Spectre V2 : Enabling Restricted Speculation for firmware calls
[    2.259278] psmouse serio4: elantech: assuming hardware version 4 (with firmware version 0x381f00)
[    3.568715] iwlwifi 0000:02:00.0: firmware: direct-loading firmware iwlwifi-7265D-29.ucode
[    3.570990] iwlwifi 0000:02:00.0: loaded firmware version 29.1044073957.0 op_mode iwlmvm

dmesg|grep -i DMAR

[    0.014851] ACPI: DMAR 0x00000000DB73D600 0000A8 (v01 INTEL  BDW      00000001 INTL 00000001)
[    0.253577] DMAR: Host address width 39
[    0.253579] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.253586] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 7e1ff0505e
[    0.253589] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.253594] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da
[    0.253598] DMAR: RMRR base: 0x000000dce3d000 end: 0x000000dce4bfff
[    0.253600] DMAR: RMRR base: 0x000000dd800000 end: 0x000000dfffffff
[    0.253604] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.253606] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.253608] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    0.253609] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[    0.254139] DMAR-IR: Enabled IRQ remapping in xapic mode

So it seems that several of the errors only come with the newer kernel.

Checking up on the regulatory db, I found this :-
https://www.linuxquestions.org/question … 175622954/

crda is not installed so I installed it.
I can now see :-

v /lib/firmware/regu*

lrwxrwxrwx 1 root root   31 Jun 11 14:47 /lib/firmware/regulatory.db -> /etc/alternatives/regulatory.db
-rw-r--r-- 1 root root 4248 Apr 12 19:28 /lib/firmware/regulatory.db-debian
lrwxrwxrwx 1 root root   35 Jun 11 14:47 /lib/firmware/regulatory.db.p7s -> /etc/alternatives/regulatory.db.p7s
-rw-r--r-- 1 root root 1225 Apr 12 19:28 /lib/firmware/regulatory.db.p7s-debian
-rw-r--r-- 1 root root 1182 Apr 12 19:28 /lib/firmware/regulatory.db.p7s-upstream
-rw-r--r-- 1 root root 4248 Apr 12 19:28 /lib/firmware/regulatory.db-upstream

v /etc/alternatives/regulatory.db*

lrwxrwxrwx 1 root root 34 Jun 11 14:47 /etc/alternatives/regulatory.db -> /lib/firmware/regulatory.db-debian
lrwxrwxrwx 1 root root 38 Jun 11 14:47 /etc/alternatives/regulatory.db.p7s -> /lib/firmware/regulatory.db.p7s-debian

after a reboot, dmesg now reports

[    3.538453] platform regulatory.0: firmware: direct-loading firmware regulatory.db
[    3.540418] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s

Checking on the Realtek firmware I found this :-

https://unix.stackexchange.com/question … 68g-3-fw-2

I installed firmware-realtek. This seems to have installed some likely looking files,
although not the exact numbered one reported in the error.

https://askubuntu.com/questions/898128/ … untu-16-10

suggests getting it from Realtek
https://www.realtek.com/en/component/zo … 0-software

which seems to want my email address.

https://www.realtek.com/en/products/com … em/rtl8153

https://www.pcsuggest.com/install-rtl8153-driver-linux/

suggests that the generic cdc_ether driver is often used.

lsmod| grep ether

cdc_ether              24576  0
usbnet                 53248  1 cdc_ether
usbcore               315392  8 xhci_hcd,usbnet,usbhid,uvcvideo,btusb,xhci_pci,cdc_ether,r8152

which also mentions the r8152 module.

The wired ether seems to work ok with the error messages in dmesg.

https://wiki.debian.org/Firmware

doesn't seem to find this driver.

Geoff

#6 Re: Installation » quick note on chimaera installs (attn: fsmithred) » 2020-06-10 12:55:10

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

Error: Sub-process /usr/bin/dpkg returned an error code (1)

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

[    0.102714] Spectre V2 : Enabling Restricted Speculation for firmware calls
[    1.938244] psmouse serio4: elantech: assuming hardware version 4 (with firmware version 0x381f00)
[    3.714040] platform regulatory.0: firmware: failed to load regulatory.db (-2)
[    3.716311] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[    3.718592] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    3.762349] r8152 2-3:1.0: firmware: failed to load rtl_nic/rtl8153a-2.fw (-2)
[    3.764731] r8152 2-3:1.0: Direct firmware load for rtl_nic/rtl8153a-2.fw failed with error -2
[    3.766146] r8152 2-3:1.0: unable to load firmware patch rtl_nic/rtl8153a-2.fw (-2)
[    3.844857] iwlwifi 0000:02:00.0: firmware: direct-loading firmware iwlwifi-7265D-29.ucode
[    3.847508] iwlwifi 0000:02:00.0: loaded firmware version 29.1044073957.0 7265D-29.ucode op_mode iwlmvm
[    4.383327] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[    4.383331] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[    4.696649] Bluetooth: hci0: Intel firmware patch completed and activated

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

dmesg | grep -i DMAR

[    0.014217] ACPI: DMAR 0x00000000DB73D600 0000A8 (v01 INTEL  BDW      00000001 INTL 00000001)
[    0.078292] DMAR: Host address width 39
[    0.078294] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.078301] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 7e1ff0505e
[    0.078304] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.078309] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da
[    0.078312] DMAR: RMRR base: 0x000000dce3d000 end: 0x000000dce4bfff
[    0.078315] DMAR: RMRR base: 0x000000dd800000 end: 0x000000dfffffff
[    0.078318] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.078320] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.078322] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    0.078323] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[    0.078853] DMAR-IR: Enabled IRQ remapping in xapic mode
[    0.363921] pci 0000:00:02.0: DMAR: Disabling IOMMU for graphics on this chipset
[    0.963647] DMAR: No ATSR found
[    0.963679] DMAR: dmar1: Using Queued invalidation
[    0.966059] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    3.548242] DMAR: DRHD: handling fault status reg 3
[    3.550361] DMAR: [DMA Read] Request device [00:16.7] PASID ffffffff fault addr dcfff000 [fault reason 02] Present bit in context entry is clear
[    5.546801] DMAR: DRHD: handling fault status reg 3
[    5.546808] DMAR: [DMA Read] Request device [00:16.7] PASID ffffffff fault addr dcfff000 [fault reason 02] Present bit in context entry is clear
[    5.547152] DMAR: DRHD: handling fault status reg 3
[    5.547159] DMAR: [DMA Write] Request device [00:16.7] PASID ffffffff fault addr dcfff000 [fault reason 02] Present bit in context entry is clear
[    5.547274] DMAR: DRHD: handling fault status reg 3

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

I had no problems with polkit.

Geoff

#7 Re: News & Announcements » Beowulf Beta is here! » 2020-06-01 14:41:31

I have now managed to install the new netinstall iso under Xen

devuan_beowulf_3.0.0_netinstall-amd64.iso

To avoid going too far off topic here, I have described what I did at the end of this earlier thread.
https://dev1galaxy.org/viewtopic.php?pid=22226#p22226

Geoff

#8 Re: Installation » Xen and the art of VM » 2020-06-01 14:37:08

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

/dev/HDD0/net-disk (20GB)
/dev/HDD0/net-swap (4GB)

As root check the config is set up :-

cd /etc/xen
cat net.cfg

#
# Configuration file for the Xen instance "net" for a Devuan iso
#

# Boot info for the iso. Don't forget to mount it at /mnt/inst_iso with something like :-
# mount -t iso9660 /archive/isos/devuan_beowulf_3.0.0_netinstall-amd64.iso /mnt/inst_iso/

# You can choose whether to get a larger VNC window with the
# xen-fbfront.video option but you do get two cursors!

kernel = '/mnt/inst_iso/boot/isolinux/linux'
ramdisk = '/mnt/inst_iso/boot/isolinux/initrd.gz'
extra  = 'boot=boot/isolinux username=devuan console=hvc0 xen-fbfront.video=32,1600,1000'

# Boot info for the installed OS. We need kernel and ramdisk if grub failed to install :-
# We can use pygrub if grub was installed.

# kernel      = '/vmlinuz'
# ramdisk     = '/initrd.img'
# # bootloader  = '/usr/bin/pygrub'
# extra       = 'console=hvc0 xen-fbfront.video=32,1600,1000'
# root        = '/dev/xvda2 ro'

#
#  Disk device(s).
#

disk        = [
                  'format=raw, vdev=xvdc,  access=r, devtype=cdrom, target=/archive/isos/devuan_beowulf_3.0.0_netinstall-amd64.iso',
                  'format=raw, vdev=xvda2, access=w, target=/dev/HDD0/net-disk',
                  'format=raw, vdev=xvda1, access=w, target=/dev/HDD0/net-swap',
              ]

#
#  Local set-up
#
#   Limits

vcpus       = '2'
memory      = '2048'

#
#  Hostname
#
name        = 'net'

#
#  Networking
#

vif         = [ 'mac=00:16:3E:00:00:06, bridge=xenbr0' ]

# Graphic display

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

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

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

kernel      = '/vmlinuz'
ramdisk     = '/initrd.img'
# bootloader  = '/usr/bin/pygrub'
extra       = 'console=hvc0 xen-fbfront.video=32,1600,1000'
root        = '/dev/xvda2 ro'

and comment out the CD/iso.

disk        = [
#                  'format=raw, vdev=xvdc,  access=r, devtype=cdrom, target=/archive/isos/devuan_beowulf_3.0.0_netinstall-amd64.iso',
                  'format=raw, vdev=xvda2, access=w, target=/dev/HDD0/net-disk',
                  'format=raw, vdev=xvda1, access=w, target=/dev/HDD0/net-swap',
              ]

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

E:grub-pc: installed grub-pc package post-installation script
subprocess returned exit status 255

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.

# Boot info for the installed OS. We need kernel and ramdisk if grub failed to install :-
# Use pygrub if grub was installed.

# kernel      = '/vmlinuz'
# ramdisk     = '/initrd.img'
bootloader  = '/usr/bin/pygrub'
extra       = 'console=hvc0 xen-fbfront.video=32,1600,1000'
root        = '/dev/xvda2 ro'

then :-

xl create net.cfg -c

pyGRUB  version 0.6
┌────────────────────────────────────────────────────────────────────────┐
│ Debian GNU/Linux                                                                                                                     │
│ Debian GNU/Linux, with Linux 4.19.0-9-amd64                                                                             │
│ Debian GNU/Linux, with Linux 4.19.0-9-amd64 (recovery mode)                                                    │
│                                                                                                                                                │
│                                                                                                                                                │
│                                                                                                                                                │
│                                                                                                                                                │
│                                                                                                                                                │
└────────────────────────────────────────────────────────────────────────┘
     Use the ^ and v keys to select which entry is highlighted.           
     Press enter to boot the selected OS, 'e' to edit the     
     commands before booting, 'a' to modify the kernel arguments
     before booting, or 'c' for a command line.

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.

#9 Re: News & Announcements » Beowulf Beta is here! » 2020-05-27 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

#10 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

#11 Re: Hardware & System Configuration » [Solved] 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

#12 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

#13 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

#14 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

#15 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

#16 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

#17 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

#18 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

#19 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

#20 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

#21 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

#22 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

#23 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

#24 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

#25 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

Board footer

Forum Software