Most of the ROCm 5.2 stack is already packaged in Debian and is available on Daedalus. Look for `rocminfo`, `rocm-smi`, `libhsa-runtime64`, `libamdhip64`, `librocmsmi64`, etc.
And ROCm 5.7 is available on ceres if you dare.

At some point AMD in their infinite wisdom decided to change how they package AMDGPU-PRO drivers. All hacks that relied on extracting individual .deb from the official Ubuntu installer package stopped working.

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?

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.

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.

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.

@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.

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.

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

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

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.

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

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