The officially official Devuan Forum!

You are not logged in.

#1 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-31 15:34:49

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

Got it. I'm not worried about Daedalus, but Ceres.
I checked and I did NOT had libsystemd0 installed in my Ceres machine. Only the usual stub files that are found in Devuan stable and that would mean the sshd wasn't compromised. Do I understand it correctly?

#2 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-31 13:12:55

Thanks. That's a little more reassuring.
I saw in other thread being mentioned that Ceres and Excalibur are affected and I want to know to what extent.
I believe this guy is wrong as libsystemd0 is not installed in Devuan - at least in Daedalus: https://gist.github.com/thesamesam/2239 … nt-5007060

#3 Re: Devuan » liblzma CVE-2024-3094 » 2024-03-30 16:04:30

Excalibur and Ceres are affected.

I guess there are levels of granularity to this. Does libelogind use notifyd underneath? Or in more layman terms are Excalibur/Ceres vulnerable to the same extent as Debian sid?
I rolled back from Ceres to Daedalus (with Timeshift) on one of my machines. I'm not sure if this is enough, I'll monitor firewall logs to see if there is any suspicious traffic.
I use this machine mainly for testing new GPU-related packages, and unfortunately I used it for the past week.

#4 Devuan » liblzma CVE-2024-3094 » 2024-03-29 22:44:56

uther
Replies: 28

Subject: backdoor in upstream xz/liblzma leading to ssh server compromise:

https://www.openwall.com/lists/oss-secu … 24/03/29/4

I wanted to check if Devuan is vulnerable to this so I've checked with `ldd /usr/sbin/sshd` and it looks that in Devuan liblzma is not a shared library for sshd.

#5 Re: Desktop and Multimedia » [SOLVED] Xorg update and broken GPU drivers in daedalus » 2021-12-22 16:54:18

Will do as soon as I make GitLab account.

On a sidenote. There is an ongoing effort between Debian maintainers and AMD of packaging opensource AMD compute drivers under the name ROCm for Debian. ROCm and particularly HIP replaces OpenCL as a compute stack in modern AMD GPUS.

Look for it on this mailing list:
https://lists.debian.org/debian-ai/2021 … html#00054

The goal is the ability to install compute driver stack for AMD gpu with sudo apt install rocm or something similar.

#6 Re: Desktop and Multimedia » [SOLVED] Xorg update and broken GPU drivers in daedalus » 2021-11-23 18:47:50

Head_on_a_Stick wrote:

Please include *all* relevant information in future threads.

Sorry about that. Won't happen again.

Head_on_a_Stick wrote:

Why are you using AMDGPU PRO?

I know they are shit, but you can't compute 3d rendering on a AMD GPU in Blender without them. That's why I have installed only OpenCL parts of proprietary driver. OpenGL and display is handled by mesa.

I do it that way because there is no better alternative to have both smooth display and compute stack for 3d rendering.

ED:
Wait. I was wrong. I thought that installing PRO drivers with --headless installs only compute part of the driver. But I followed the link you provided and voila I have working OpenCL and no problem described in the first post! Did I ran this machine for so long only THINKING that I'm using mesa as a display driver? LOL if true.

So the problem seems to be a conflict between mesa and PRO display drivers when they are both installed.
Marking as solved.

#7 Re: Desktop and Multimedia » [SOLVED] Xorg update and broken GPU drivers in daedalus » 2021-11-23 15:46:24

I found the temporary fix.
Uninstalling proprietary AMD GPU drivers fixed the problem. Also I tested previous drivers back to 20.40 and installing any versions from 20.40 onwards brings the problem back, so this is probably some conflict with mesa and/or xorg.

#8 Desktop and Multimedia » [SOLVED] Xorg update and broken GPU drivers in daedalus » 2021-11-22 19:05:45

uther
Replies: 6

Hi,
Today's Xorg and mesa AMD driver update broke OpenGL parts of xfce desktop and other applications in daedalus.
Updated among others:
xserver-xorg-video-amdgpu:amd64 (19.1.0-2, 21.0.0-2),
liobdrm-amdgpu1:amd64 (2.4.107-8, 2.4.108-1),

I'm running two screens and there is a lot of issues after this update:

- certain windows on main display are giga-sluggish and leave that funny trace of itself, but only for a brief moment
- navigation in some app is broken, menus are closing after moving cursor inside them (Firefox), clicks are not registered (Mullvad)
- the only title bars that are visible are fat, Gnome ones, rest are not rendered
- can't maximize/minimize windows
- system don't recognize shortcuts like Alt+F4 (but Ctrl+Q works)
- Alt+RMB windows resize don't work
- mouse cursor is displayed as 'x' symbol/icon
- can't switch between workspaces
- in xfce panel there are no application bars although apps are opened
... plus a lot more

Running Blender from CLI reveals:

libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
Error! Unsupported graphics card or driver.
A graphics card and driver with support for OpenGL 3.3 or higher is required.

Is rolling back an option here? INB4 - yes, to Chimaera :^)
Thanks for any advice.

ED: I reinstalled all mesa packages including libgl1-mesa-glx and mesa-utils, but no effect.
ED2: glxgears gives identical output as Blender plus: Error: glCreateContext failed
ED3: After checking there is no /usr/lib64 directory, but in /usr/lib/x86_64-linux-gnu/dri there is swrast_dri.so

#9 Re: Off-topic » It's a sad day . . . » 2021-10-10 20:27:46

@zapper Blender's interface, viewport and pretty much all that is displayed on a screen is OpenGL based. That works fine on mesa drivers! Most functions require CPU compute to perform operation on data, and the GPU is used in couple places to accelerate that compute side - like rendering final image/frame. OpenCL drivers are needed to enable this on AMD hardware. Do not mistake display rendering in a form of pushing frames to the display render buffer on a GPU to be passed on screen with rendering of the final product like image or animation that you export and save on a disc.

#10 Re: Off-topic » It's a sad day . . . » 2021-10-10 09:36:39

GPU rendering in Blender require OpenCL drivers if you have AMD GPU, otherwise Blender won't see your card at all.
However with recent Cycles rewrite AMD will have completly different backend (HIP) and OpenCL was dropped. We (Blender users) still don't know what drivers we will need or what hardware will be supported, as HIP implementation isn't finished.

#11 Re: Off-topic » It's a sad day . . . » 2021-10-09 23:13:56

Open drivers don't have OpenCL support. And I need that.
Also I have installed only OpenCL parts of AMDGPU-PRO. Display is handled by mesa, and indeed it's great.

#12 Re: Off-topic » It's a sad day . . . » 2021-10-09 23:06:55

hevidevi wrote:

Ive been using chimaera all year, stable for me too.

Same here. In fact it is so stable that after couple tests I made a bold move and switched main production machine to daedalus.
So far the only thing that borked itself were old AMDGPU-PRO drivers (20.40) which I don't need that bad as of now. Still waiting for 5.14 kernel with RT patch, so I can try to install newer versions.

#13 Re: Off-topic » [SOLVED] New kernel adoption policy in Debian » 2021-07-27 20:12:53

Thank you all for responses, I think they answer my questions. I don't have account on Debian forums, so I asked here first.

#14 Off-topic » [SOLVED] New kernel adoption policy in Debian » 2021-07-26 17:25:27

uther
Replies: 6

Usually I'm not very keen to learn about Debian's internal policies about release and mainteneance, but recently as latest 5.13 kernel is required for some software that I use in my work, so I started to search how Debian's new kernel adoption looks. Unfortunately Debian pages can be little overwhelming and I couldn't find anything relevant. So here are going my noob questions:

Will versions 5.11 and 5.12 land before 5.13?
If not what are the criterias for landing a kernel in a specific distro versions?
Are there a specific time frames for landing a new kernel versions in Debian, or the rule is 'when it's ready'?
Is there a shedule a user can track in order to plan one's software updates/upgrades?

Thanks in advance,
uther

#15 Re: News & Announcements » Devuan Beowulf 3.1.0 point release » 2021-07-20 15:49:27

Congratulations to the whole team and keep it going!
I jumped to Chimaera some time ago and its surprisingly stable

#16 Re: Other Issues » [SOLVED] How to change default storage pool location in virt-manager? » 2021-01-11 13:10:01

Thanks @xinomilo. I moved to Chimaera and 'll give it another try when I'll have more time.
Can you tell me if the newly created pool permissions should be the same as /var/lib/libvirt/images?
I can't find any information about that.

#17 Re: Hardware & System Configuration » [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x » 2021-01-11 13:05:59

The install is not Full Disk Encryption (FDE). Only one partition is encrypted. The disk has an extended partition which indicates that it uses DOS partitioning scheme.
/dev/sda is the boot disk.
/dev/sda1 is the unencrypted /boot partition.
/dev/sda2 is the extended partition. Required on DOS partitioned disk in order to have more than four (4) partitions.
/dev/sda5 is the OS partition with swap on LVM on luks encryption.
In this case the OS partition contains swap and the root (/) tree excluding /boot, all on top of LVM. Which in turn is on top of luks encryption.
The Debian Installation (di) uses that method as the default installation method using encrypted storage. It is arguably not the best method but it makes things easy for beginners.

GRUB requires access to /boot, in this case /boot is not on an encrypted device, therefore, the cryptdevice definition on the /etc/defautl/grub GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>" line entry should not be there. Additionally, the initramfs option is not needed in /etc/crypttab, though it does not hurt.

Thank you for clarification, you are right about that. I forgot that this is an accual state and used laymans term. Thou in Devuan installer i belive there is explicitly said about using 'full disk encryption' to describe the default LUKS crypt partitioning scheme. Maybe the description should be improved.

As for the problem, I moved all my systems to Chimaera and so far it's gone.
Thanks everybody for help.

#18 Re: Hardware & System Configuration » [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x » 2020-11-14 18:35:55

machine #1 sda1_crypt UUID=xxx none luks
machine #2 sda1_crypt UUID=xxx none luks,discard
machine #3 sda5_crypt UUID=xxx none luks,discard

Above refers to 3 different machines which I wrote about earlier. The problematic one is the third one (#3). I might wrote it badly, sorry for that.

Thing is I can boot the system - but only with the older kernel like 4.19.0-12-amd64.

Here are all requested dumps from problematic machine. Please bear in mind that this is fresh OOTB install before any configuration and optimisation.

cat /etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="cryptdevice=UUID=123456789:sda5_crypt"
GRUB_ENABLE_CRYPTODISK=y

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

cat /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>			<mount point>   <type>  <options>		<dump>  <pass>
/dev/mapper/dux--vg-root	/               ext4    errors=remount-ro	0       1
# /boot was on /dev/sda1 during installation
UUID=987654321			/boot           ext2    defaults		0       2
/dev/mapper/dux--vg-home	/home           ext4    defaults	        0       2
/dev/mapper/dux--vg-tmp		/tmp            ext4    defaults	        0       2
/dev/mapper/dux--vg-var		/var            ext4    defaults	        0       2
/dev/mapper/dux--vg-swap_1	none            swap    sw      	        0       0

cat /etc/crypttab

sda5_crypt UUID=123456789 none luks,initramfs

lsblk -f -o +size

NAME                 FSTYPE      LABEL     UUID            FSAVAIL FSUSE% MOUNTPOINT             SIZE
sda                                                                                            931.5G
├─sda1               ext2                  987654321	   178M    19%    /boot                  243M
├─sda2                                                                                             1K
└─sda5               crypto_LUKS           123456789	                                       931.3G
  └─sda5_crypt                                                                                 931.3G
    ├─user--vg-root                                            18G    16% /                     23.3G
    ├─user--vg-var                                            8.3G     3% /var                   9.3G
    ├─user--vg-swap_1                                                     [SWAP]                 3.2G
    ├─user--vg-tmp                                            1.7G     0% /tmp                   1.9G
    └─user--vg-home                                         833.8G     0% /home                893.6G

fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x--------------

Device     Boot  Start        End    Sectors   Size Id Type
/dev/sda1  *      2048     499711     497664   243M 83 Linux
/dev/sda2       501758 1953523711 1953021954 931.3G  5 Extended
/dev/sda5       501760 1953523711 1953021952 931.3G 83 Linux

Disk /dev/mapper/sda5_crypt: 931.3 GiB, 999930462208 bytes, 1952989184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-root: 23.3 GiB, 24998051840 bytes, 48824320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-var: 9.3 GiB, 9999220736 bytes, 19529728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-swap_1: 3.2 GiB, 3418357760 bytes, 6676480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-tmp: 1.9 GiB, 1996488704 bytes, 3899392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-home: 893.6 GiB, 959480594432 bytes, 1873985536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

#19 Re: Hardware & System Configuration » [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x » 2020-11-14 14:18:42

I've added the following to the grub config file with the proper drive UUID and updated the grub. Still without the effect.

GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>"

After disabling quiet boot option I'm getting the following just before passphrase request:

Begin: Mounting root filesystem ... Begin: Running /scripts/local-top ...  Volume group "user--vg" not found
 Cannot process volume group user--vg
 Volume group "user--vg" not found
 Cannot process volume group user--vg

After typing passphrase:

cryptsetup: ERROR: sda5_crypt: cryptsetup failed, bad password or options?

With the 4.19.0-12-amd64 kernel I'm getting the same message as above but the crypt is openning without a problem.
After checking - the same message about not founding volume group is present on all machines mentioned in my last post.

The sda5 have DOS partition table.
As for the device number - that's the number given during guided partitioning, so I didn't change that. There are no other drives in the system.
During boot there is this however:
[] sda: sda1 sda2 < sda5 >
But there is no sign of sda3 and sda4.

Thanks for the tip about swap! Here I have one question - will changing swap entry in fstab automatically free the diskspace that the swap is using right now?

I don't know if this is relevant but it looks like Beowulf is using 'discard' option in crypttab as a default now:
machine #1 sda1_crypt UUID=xxx none luks
machine #2 sda1_crypt UUID=xxx none luks,discard
machine #3 sda5_crypt UUID=xxx none luks,discard

#20 Other Issues » [SOLVED] How to change default storage pool location in virt-manager? » 2020-11-13 22:12:01

uther
Replies: 3

I'm making my first steps in VMs, so sorry for any stupid questions.

I'm using KVM+QEMU plus GUI frontend VMM and I found that I can't change the location of a default storage pool - either in virt-manager settings or during setting up a new VM.
I don't know if this is a good practice, but my goal is to have default storage pool for VMs on a separate drive with full disc encryption. The drive is working correctly.

After some digging I found this advice: https://serverfault.com/questions/84051 … om-libvirt
I've tried solutions from both posts, but with no results. The default pool location in virt-manager is still pointing to /var/lib/libvirt/images.

I'm on Beowulf. My user account is in libvirt libvirt-qemu groups, the libvirtd is running, virtualisation is enabled.
As for the packages I've installed:
qemu-kvm
libvirt-clients
libvirt-daemon-system
bridge-utils
libguestfs-tools
genisoimage
virtinst
libosinfo-bin
virt-manager

The other information that I've found is related to permissions, but I don't know where to start with it or how precisely its related to storage pools.
Is having default pool on a /var/ partition a recommendded solution? I can sacrifice part of my /home partition and make /var bigger, but that's my last resort.

Thanks for any advice
uther

#21 Re: Hardware & System Configuration » [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x » 2020-11-13 21:31:40

xinomilo - I have cryptsetup-initramfs installed

stevendemeritus - thanks for detailed response

I run update-grub every time after updating the kernel just to be sure anyway, so we can rule that one out.
And after running the above plus update-initramfs -u -k all there are no error messages during boot - its just like before.

I'm using guided partitioning with LUKScrypt and LVM during OS installation.
The partitioning is as follows:

─sda5   
 └─sda5_crypt  
   ├─user--vg-root
   ├─user--vg-var
   ├─user--vg-swap_1
   ├─user--vg-tmp
   └─user--vg-home

As for GRUB the installed version is 2.02+dfsg1-20+deb10u2

/etc/default/grub looks pretty normal, considering that the OS is freshly reinstalled:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Same goes for the /etc/initramfs-tools/*

After further investigation with cryptsetup luksDump /dev/... it looks like this might be luks version issue.

For further explanation - I have 3 machines with Beowulf:

#1 new desktop - grub 2.02+dfsg1-20+deb10u2, luks1, kernel 5.8 - works (upgraded from ASCII)
#2 new laptop - grub 2.02+dfsg1-20+deb10u2, luks2 + kernel 5.8 - wasn't working but works after reinstall
#3 old laptop - grub 2.02+dfsg1-20+deb10u2, luks2 + kernel 5.8 - doesn't work before and after reinstall

Both #2 #3 laptops have Devuan installed from the same iso image and the issue with encryption was present only on them.
#3 is an old Core2Duo.
All 3 machines have proper linux-headers package installed.

You said that the current GRUB cannot decrypt luks2, but on laptop #2 listed above it seems to be working, or am I missing something (aside from hardware)?

Thanks again,
uther

#22 Re: Hardware & System Configuration » [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x » 2020-10-31 10:32:57

Hello, thanks for responses.
Yes, FDE means Full Disk Encryption. After upgrading the kernel I cannot open the cryptsetup during boot. The only message is as if I made a typo during typing passphrase, but when I'm trying to boot with older kernel the passphrase works.
I've managed to resolve this issue on one machine with wiping the drive and reinstallation but that's overkill.

#23 Re: Desktop and Multimedia » Automating post-installation steps » 2020-10-28 18:02:59

Thank you bgstack15, that's very useful information!

#24 Hardware & System Configuration » [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x » 2020-10-26 22:01:43

uther
Replies: 13

I have FDE made with guided partitioning during install and after upgrading kernel to 5.8.0 I can't open it anymore. I'm getting standard response as if I made a typo. However I can open the crypt with older kernels like 4.19.x.

The issue is present on two different hardware configs. I'm using vanilla Beowulf installs and the 5.8.0 kernel is installed from backports.
This wasn't happening on 5.7.x IIRC.

#25 Re: Desktop and Multimedia » Automating post-installation steps » 2020-10-26 21:26:13

Thanks all of you.
GlennW - your approach is interesting even for a scenario when you do have internet connection. I've never considered home folder to be on a separate drive maily because I'm too lazy to learn how to install manually whole system with full disc encryption and separate partitions. I'll eventually do it ... tommorow :^).

HoaS - very efficient indeed, but a little above my skills right now.

As for the questions - I'm lookig where xfce writes custom keyboard shortcuts. I've foud file /home/user/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml but I'm not sure if this is it?

Board footer

Forum Software