The officially official Devuan Forum!

You are not logged in.

#1 Hardware & System Configuration » Infinite Noise TRNG daedalus » 2023-10-04 06:35:41

devujan
Replies: 0

I own a usb infnoise TRNG device and had the idea of using it with devuan. I was surprised to see there is a package for it (infnoise_0.3.3%2bdfsg-1_amd64.deb) for my architecture in daedalus.
Fortunately I tried to use it before on a chimera installed box and had to intstall the software manually.
The maintainer for this package is stated as skitt@debian.org.
But I dare to doubt that he placed that (on first sight very nice) sysV startup file /etc/init.d /infnoise  there .

From my point of view that init.d file badly needs a.

--- infnoise    2023-10-03 18:18:39.908014899 +0000
+++ infnoise.orig       2023-10-04 07:48:39.115944604 +0000
@@ -23,11 +23,6 @@
 
 set -e
 
-if [ -e /etc/infnoise.conf ]; then
-  . /etc/infnoise.conf
-fi
-
-
 case "$1" in
        status)
                status_of_proc $DAEMON $NAME

to source the /etc/infnoise.conf file for sourcing the environment variables that the binary needs for proper working.

Imho

INFNOISE_SERIAL=DO0032ZA

with the correct serial number of the device should be set for the infnoise binary to work properly.

(The TRNG device user can read that number from the labels printed on that device or read it with infnoise --list-devices. )

Another issue that puzzled me - was the content of the file /lib/udev/rules.d/60-infnoise.rules .

The second line

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015" ,TAG+="systemd", ENV{SYSTEMD_WANTS}="infnoise.service"

does what I would have expected it to do in Devuan - nothing.
I changed it for

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", OPTIONS:="nowatch", RUN+="/etc/init.d/infnoise start"

and it starts the infnoise binary as it is supposed to do - when inserting the TRNG usb device.
(As a side effect this hack temporarily generates a "[infnoise] <defunct>" init.d process - which (to me mysteriously) gets killed after some time.)

Imho there is  legacy files contained in that package too.
I have no clue what the file /lib/systemd/system/infnoise.service is good for - in that package.

Also to help inexperienced users to run that device there should be a mentioning of adding the serial number to  /etc/infnoise.conf in the man pages.

Jan

#2 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2023-02-12 19:59:08

the code is essentially boughtonps line

 [ -x /sbin/lvm ] && /sbin/lvm vgchange -a n >/dev/null 2>&1

behind line 188 in /lib/cryptsetup/cryptdisks-functions

------------------to check -------------------------------------------

# diff -Naur cryptdisks-functions.orig cryptdisks-functions
--- cryptdisks-functions.orig   2023-01-31 21:00:09.967829315 +0100
+++ cryptdisks-functions        2023-02-11 20:17:49.665380782 +0100
@@ -186,6 +186,7 @@

 do_stop() {
     local devno_rootfs devno_usr
     dmsetup mknodes
+    [ -x /sbin/lvm ] && /sbin/lvm vgchange -a n >/dev/null 2>&1
     log_action_begin_msg "Stopping $INITSTATE crypto disks"
 
     devno_rootfs="$(get_mnt_devno /)" || devno_rootfs="" 

------------------to check/-------------------------------------------

I use a byzantine fstab with 13 entries for mounted lvs  - almost all mounted with different - very restrictive mount options ( with very sharp fitted excessive file space). /boot lives on an encrypted "real" gpt 512 MB partition. /home sits on a dm raid1 on a vg in an lv of it's own. All vgs sit on pvs on LUKS devices.
As systemd gets a hiccup on partition systems like this - this might cause side effects - as some programmers might be tempted to falsely rely on big "complete" root partitions...

#3 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2023-02-11 19:43:14

Dear boughtonp you are a hero.
I tried all versions against each other....
(by 100% scientific loud counting :-) )
--- cryptdisks-functions.orig   2023-01-31 21:00:09.967829315 +0100
+++ cryptdisks-functions        2023-02-11 20:17:49.665380782 +0100
@@ -186,6 +186,7 @@
do_stop() {
     local devno_rootfs devno_usr
     dmsetup mknodes
+    [ -x /sbin/lvm ] && /sbin/lvm vgchange -a n >/dev/null 2>&1
     log_action_begin_msg "Stopping $INITSTATE crypto disks"

     devno_rootfs="$(get_mnt_devno /)" || devno_rootfs=""

This version took the same ~ 6 seconds to shut down my desktop as the version looping over the vgs.
The lvm manual was right. :-)
I also counted the time for the original version and that was ~ 40 seconds to shutdown.
Thank you!

#4 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2023-02-11 15:41:13

rolfie wrote:

Well, I have my desktop running with Daedalus, lightdm & Cinnamon, up-to-date, openrc and amd64, traditional unencrypted /boot, a luks-encrypted container holding a LVM for / and /swap. Working fine, just tried it, no shutdown delays.

Update: also checked my laptop running Daedalus with similar setup: no problems with shutdown delays.

I looked into my update history. The last update of the cryptsetup-stuff was before Chrismas. Why do we suddenly have a problem?

I set up a laptop for my smallest daughter in December with Daedalus and had the problem - and I renewed my desktop in January with the next netinstall.iso from Daedalus and had the same issue again. (Both with two VGs - the desktop has additional a raid 1 md device which caused also grub problems (but that is another story). Both FDE with separate /boot partition on LUKS1. Both with xfs (and few ext2) on lvm on LUKS2.)

#5 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2023-02-11 15:28:00

boughtonp wrote:

On reflection, no need for Awk either, the whole change can potentially be simplified to:

[ -x /sbin/lvm ] && /sbin/lvm vgscan | while IFS=\" read -r _ vg _
do
   [ -n "$vg" ] && /sbin/lvm vgchange -a n "$vg" >/dev/null 2>&1
done

Or:

[ -x /sbin/lvm ] && /sbin/lvm vgs --options vg_name --noheadings | while read -r vg
do
   /sbin/lvm vgchange -a n "$vg" >/dev/null 2>&1
done

Dear boughtonp all your code suggestions look cool.
What makes me like (even realy ugly looking) sed code one liners over awk or shell loops is resource considerations.
This code is run once at shutdown. To me it is unlikely that parts of the code are somewhere cached in the CPU caches.
sed has an extremely small footprint (in memory and CPU usage).
This patch adds to 99% of all systems an additional slowdown of less than a 1ms during shutdown due to the check for lvm

 if [ -x /sbin/lvm ];

which I think is a fair deal, because 100% of all systems running lvm on top of LUKS will benefit from that with additional 120 seconds less waiting for a shutdown.
Because cryptsetup does check for open VGs living on LUKS devices and does oppose to a possible premature closing of those devices with the VGs still online.
(I like that kind of error caching.)
Usually I run my laptops with at least two different VGs each holding different PVs.
If you come up with a solution which is small, easy to read and faster than the one I wrote - may rolfie decide ....

#6 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2023-02-10 09:50:35

rolfie wrote:

Outlook to Chimaera: there the issue is fixed.

rolfie

In Daedalus the problem is back....

--------------------------patch-----------------------------------------------
--- /lib/cryptsetup/cryptdisks-functions.orig   2023-01-31 21:00:09.967829315 +0100
+++ /lib/cryptsetup/cryptdisks-functions        2023-01-31 21:10:31.023816298 +0100
@@ -184,8 +184,16 @@
# Removes all mappings in crypttab, except the ones holding the root
# file system or /usr
do_stop() {
-    local devno_rootfs devno_usr
+    local devno_rootfs devno_usr vgs vg
     dmsetup mknodes
+       if [ -x /sbin/lvm ]; then
+        vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+         if [ -n "${vgs}" ]; then
+          for vg in ${vgs}; do
+           /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1
+          done
+         fi
+       fi
     log_action_begin_msg "Stopping $INITSTATE crypto disks"

     devno_rootfs="$(get_mnt_devno /)" || devno_rootfs=""
--------------------------patch/----------------------------------------------

Above patch mitigates the problem for me (Daedalus FDE && LVM).

Best wishes

Jan

#7 Re: Hardware & System Configuration » Badly missing uswsusp in chimaera » 2021-05-04 16:24:55

The the AMD graphics firmware is installed and AMD Graphics works from the very start beautifully.
I guess I have to give GRUB_CMDLINE_LINUX in /etc/default/grub a closer look and have check for pm scripts to remove and reinsert kernel modules.
My problem is that my wife is using that particular notebook very productive in school now - and I have to wait for a timeslot to tackle that issue. 
I'll report any news here.

#8 Hardware & System Configuration » Badly missing uswsusp in chimaera » 2021-04-26 19:54:02

devujan
Replies: 3

I set up an nice FDE laptop with chimaera (AMD 4700U working out of the box) - but I can not suspend chimaera.
Suspend works in principle somehow - but how do I unload and reload the realtek modules and how do I stabilize the graphic system?
After suspend the machine sometimes "freezes" and loses network connection - all erratically.
With uswsusp I was able to solve these problems in ascii and beowulf....
Are there newer, better tools in place, to help with suspend - or has just the only really working tool been abandoned?

#9 Re: Installation » to what extent can /usr/share actually be shared? » 2021-04-26 19:39:31

Imho you can share /usr - in ro mode - if you never ever come to the point and do updates. apt can't handle this. If you are creative and like playing - you can try overlay file systems to overcome that to a certain point where complexity breaks you neck.
In non systemd systems it is practically possible to share [ro]  /usr between identical machines, which are painstakingly kept synchronized concerning their package configuration. (We used to run SunOS servers ("clusters")  this way in another century.)
Just do it - and see what happens!
For the systems with the [ro] /usr - you will need to find a way to fool apt. (snapshot && overlay && throw away -> actual updated /usr from mount - would be my first guess - but maybe there is a simpler solution? Maybe you can do it all with translucent logical volume caches?)

#10 Re: Hardware & System Configuration » /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED] » 2021-04-06 16:27:41

It looks like this problem is reoccurring with chimera.
The line

ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &

is missing in

/etc/init.d/eudev

#11 Re: Desktop and Multimedia » [SOLVED] Beowulf: Xserver native mode in AMD Ryzen 5 Pro 4650G » 2021-03-22 11:41:37

A quick reply to this thread.
To me stability, and low administrative workload generation is a target I pursue with every laptop I configure for my clients (family mostly). Also privacy and usability are important to me.
The last 30 years I learned that the operating system should ripe and age with the hardware in use - to keep administration effort on the lowest possible level.
I recently got a Tuxedo "Aura 15"  (a Clevo OEM)  with AMD Ryzen 4700U and thus RENOIR graphic integrated.
As there is no (at least I didn't find it) ISO for chimera I booted a beowulf 3.1 iso and installed a fde chimera on it.
I painstakingly installed all the necessary firmware packages and the graphics just worked out of the box.
Ok chimera is testing ... (but a lot better the the preinstalled Ubuntu Frankendebian).
I only found that the KDE akonadi was even more crap than expected ('apt-mark hold "akonadi* packages"' helps to keep that uninstalled stuff out)- but I guess the overall workload to keep that laptop patched and functional the next 5 years is significantly lower than starting with (a heavily patched MX-Franken-)beowulf - and because of that reinstalling a chimera once it is officially released.
Your mileage may vary.
I just want to point out installing minimal beowulf and migrating it to chimera is an option for that brand new hardware.

#12 Re: Installation » SDDM - login sreen missing » 2021-02-21 20:29:29

I have the same problem with an Intel Laptop. I mitigated the problem and booted it into runlevel 3. So network is there and sshd is running - on default runlevel sddm is the last process before the machine is black and unresponsive. I replaced that Laptop with my old devuan ascii laptop. (With the migrated data from runlevel 3 via ssh...)
sddm is complaining about the absence of existing file in /usr in /var/log/syslog. SMART looks fine - but I also trace down the hints to dying storage hardware. (Anyway that laptop is a 5 year old discounter bargain...)  /var/log/Xorg.0.log is ok but wayland seems to suffer... - time to say goodbye

Medion E6424

#13 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2020-08-15 11:48:13

@fsmithred

Thank you! Works like a charm. I'll include that in my tutorial on full disk encrypted devuan.

#14 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2020-08-04 19:02:36

@fsmithred until now 4. Aug CEST 2020 the patch is not active in beowulf. I am installing an pcengines apu with beowulf and get well known errors on shutdown.

Best wishes Jan

#15 Re: Desktop and Multimedia » (beowulf) mac samba share no longer accessible » 2020-06-08 19:02:28

Dear kapqa - this topic seems to me less distribution specific but SAMBA version specific. @work I run several SAMBA installations with several Windows fileshares - and every 2-4 years SAMBA or Microsoft or both break the working configurations. So a smb.conf on a linux running SAMBA 4.6 with for an M$-file server running on Windows 2003 fails with SAMBA 4.7. Fixed that -a  few month later the concept is broken with Windoz2012 replacing Windows 2003....
I don't want to blame SAMBA - they do a horrific job for me and M$- but they have to shot on a moving target - and backward configuration compatibility - as well as a configuration beauty contest isn't top one on their list.
As I don't have your environment here I cannot diagnose your problem - but maybe I can give you some hints.
1) You really don't care for security and need a quick and dirty fix - here you are:
Get the source of the last version which worked - spend an weekend in getting the necessary environment to get it compiled - install and enjoy.
2) If you like hacking - and like to learn more from your system setup SAMBA is a good starting point. (Good character building stuff!)
- Try to get your MAC Server to go to debug mode (RTFM)
- Read and try several documented and less documented modes and parameters in the samba client.
- Google for the error messages.
- Reconfigure smb.conf on both sides (and restart services)
- Succeed or fail. - Even if you fail you have learned a lot.

#16 Desktop and Multimedia » Howto enable HW accel in vlc on ASCII with e.g. AMD radeonsi driver » 2020-01-04 22:06:56

devujan
Replies: 0

When running vlc 3.0.8 from deb-multimedia.org on my ASCII Ryzen 5 2500U driven laptop i encountered:
"Failed to open VDPAU backend libvdpau_nvidia.so:...."
on the terminal after starting there vlc and opening a video.
On beowulf the same vlc version works as expected and does not require environment variable support.

The build in GPU "AMD Radeon Vega 8" has the ability to accelerate videos if you have the following packages installed

vdpau-driver
vdpau-video
libvdpau-va-gl1
libvdpau1
mesa-vdpau-drivers
vdpau-driver-all
vdpau-va-all
for testing helpful packages are
vdpauinfo
vainfo

Unfortunately vlc relies on environment variables to determine the hardware acceleration possibilities of the GPU and defaults to "nvidia".

To "convince" vlc to use the build in video decoding acceleration of the AMD GPU you add the following lines to /etc/environment

sudo echo -e "export LIBVA_DRIVER_NAME=radeonsi\r\nexport VDPAU_DRIVER=radeonsi" >> /etc/environment

should give you the following contence of  /etc/environment.

$ cat /etc/environment
export LIBVA_DRIVER_NAME=radeonsi
export VDPAU_DRIVER=radeonsi

After logout and logging in again, you can check in the terminal with

$ set | grep radeon
LIBVA_DRIVER_NAME=radeonsi
VDPAU_DRIVER=radeonsi

for success.
vlc will now run smooth for all local users.

A sample output on the terminal would look like this

$ vlc
VLC media player 3.0.8 Vetinari (revision 3.0.8-0-gf350b6b5a7)
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0

In this mini howto I only tested my laptop with 2016 HW  "AMD Radeon Vega 8" running on a backported 4.19.0-0.bpo.1-amd64 kernel with mesa-va-drivers and mesa-vdpau-drivers (version 18.2.8 ...).
If you have Intel GPUs you might need "LIBVA_DRIVER_NAME=iHD" or "LIBVA_DRIVER_NAME=i965" or ...
Also "VDPAU_DRIVER=va_gl" might be a good choice - or not.
You have to find out the combinations yourself.

Testing with your hardware is easy.
1) Make sure you have hardware acceleration turned on.
run

glxinfo | grep Mesa 

in a terminal and if it outputs something like

...
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.8
OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.8
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.2.8

your  acceleration is turned on.

2) check for vdpau and va packages on your system.
e.g. by

$ dpkg --get-selections | grep vdpau

3) set your environment variables in a terminal

$ export LIBVA_DRIVER_NAME=radeonsi
$ export VDPAU_DRIVER=radeonsi

4) run vlc in terminal

$ vlc

and open a video file

5) check for error messages of vlc in the terminal

.....
Failed to open VDPAU backend libvdpau_nvidia.so:...
.....

6) goto 3) and change the variables...

Good luck!

Jan

#17 Re: Desktop and Multimedia » Fail start pulseaudio in KDE Beowulf (Devuan 3) » 2019-12-04 14:40:49

Additionally pulseaudio wants ofono to be installed.
When having it installed you get something like:

pulseaudio: modules/bluetooth/backend-ofono.c:376:hf_audio_agent_register_reply:Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.34" (uid=1010 pid=3528 comm="/usr/bin/pulseaudio --start ") interface="org.ofono.HandsfreeAudioManager" member="Register" error name="(unset)" requested_reply="0" destination="org.ofono" (uid=0 pid=2904 comm="/usr/sbin/ofonod ")

in /var/syslog.
To get this to work edit
/etc/dbus-1/system.d/ofono.conf

and add
...
  <policy group="bluetooth">
    <allow send_destination="org.ofono"/>
  </policy>
...
below
<policy user="root">
...
  </policy>

Make sure the users of the desktop are members of the group "bluetooth".

#18 Re: Desktop and Multimedia » Fail start pulseaudio in KDE Beowulf (Devuan 3) » 2019-12-03 20:11:31

Solved it:

Add the line

/usr/bin/pulseaudio --start --log-target=syslog

below the line

"set -e"

in /usr/bin/start-pulseaudio-x11

This starts it automatically for all users on the system, when they log on.
If you have some time you should file a bug for that - as pulseaudio under KDE in beowulf is mute by default without it...

#19 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2019-10-28 17:49:25

Thank you - but to my experience - “using a initramfs hook after root device has been unmounted” is not necessary.
It is completely sufficient to vary off the volume groups with vgchange - as demonstrated in my patch. (My computers (with root on encrypted lvm) running with that patch - shut down immediately, when I click on shutdown...)
The only concerns that might arise with that patch - are possible compatibility problems for high availability frame works. But to my experience those are usually that generic - that you have to “tattoo” the hardware environment into their surrounding scripts anyway. So this additional “feature” of safely shutting down all  volume groups - might be in there in another way already - and would be redundant with this patch in place...

#20 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2019-10-27 19:41:43

Dear fsmithred, thank you for having somebody looking on how to incorporate that solution to another package - which will replace the cryptdisks.functions in the future.
It would be nice if #720340 could be closed with the help of:

--- /lib/cryptsetup/cryptdisks-functions.orig   2019-09-30 21:17:28.999962846 +0200
+++ /lib/cryptsetup/cryptdisks-functions        2019-09-30 21:24:53.219944630 +0200
@@ -180,6 +180,15 @@
 # Removes all mappings in crypttab
 do_stop() {
     dmsetup mknodes
+    local vgs vg
+       if [ -x /sbin/lvm ]; then
+        vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+         if [ -n "${vgs}" ]; then
+          for vg in ${vgs}; do
+           /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1
+          done
+         fi
+        fi
     log_action_begin_msg "Stopping $INITSTATE crypto disks"

     crypttab_foreach_entry _do_stop_callback

I just failed with submitting that solution via reportbug.

#21 Re: Hardware & System Configuration » Shutdown encrypted LVM on Beowulf » 2019-10-26 19:30:51

I had the same problem with DEVUAN ASCII.
I filed a bug and a patch - but nobody was/felt responsible....
https://bugs.devuan.org/db/23/237.html

For beowulf I had to change it slightly - I didn't file it yet. Here is the part
from my ascii patch which basically needs other line numbers is beowulf.
(The obvious problem is still there - unpatched.)
If you look for the file "cryptdisks.functions" and change the function "do_stop()" accordingly the problem is solved.
In beowulf I also adjusted the local variables to only "vgs" and "vg" as far as I remember.
I plan to file the next day a patch for beowulf.
Maybe this time - this quality issue can be resolved.

------------------------patch------------------------------------------------------
--- /lib/cryptsetup/cryptdisks.functions.orig   2018-08-14 17:12:31.543227705 +0200
+++ /lib/cryptsetup/cryptdisks.functions        2018-08-23 16:36:23.849064962 +0200
@@ -763,9 +763,17 @@
 
 # Removes all mappings in crypttab
 do_stop () {
-       local dst src key opts opencount major minor
+       local dst src key opts opencount major minor vgs vg
 
        dmsetup mknodes
+       if [ -x /sbin/lvm ]; then
+        vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+         if [ -n "${vgs}" ]; then
+          for vg in ${vgs}; do
+           /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1 
+          done 
+         fi
+        fi
        log_action_begin_msg "Stopping $INITSTATE crypto disks"
 
        egrep -v "^[[:space:]]*(#|$)" "$TABFILE" | while read dst src key opts; do
------------------------patch/-----------------------------------------------------

.

The above patch silently varys off the VGs and makes handle_crypttab_line_stop work

So shame on the cryptsetup admins of debian and devuan.
They never tested the system with a encrypted root partition.

Board footer

Forum Software