As excalibur is not released and still in testing...
when it breaks you get to keep all the pieces

And that is the *only* source of packages you should install from if you don't want system wide breakage (whats wrong with vlc ?)

Ha, just tried it for fun and even that fails

nginx is still trying to compile OpenSSL (which looks like it requires 'cmake' not 'make' anyway).
Where did these come from, they look suspicious to me ?

Shoudn't the paths be

/home/drm/openssl-3.5.1/install/include
/home/drm/openssl-3.5.1/install/lib64

Your guide is

./configure --help

That error is caused by a missing system header file.
Ensure you have installed the package corresponding to your compiler version,

gcc -v 2>&1 | tail -1
gcc version 12.2.0 (Debian 12.2.0-14+deb12u1)

for me that is

apt install libgcc-12-dev

Do you have a module plugged in ?

The installation media will install itself in the same mode that it is booted in.
Turning off Legacy is one way to ensure it boots and install in UEFI.

@steve_v

Oh we are, Trinity Desktop Environment ships with a (probably updated for compatibility) KDE 3 implementation.

Ok gotcha, thanks for the clarification.
I always think of video with audio as two separate streams ...
Been using ALSA with RTP for a while, but only on the local net.

@steve_v, nice to read that history of ALSA sound, I can relate to your comments.
I currently use arts, and have not had one issue with it in the last eight years.
There is nothing that I have wanted to do that ALSA has not been able to do, once I have learnt how.
However I am confused by your statement that ALSA is not capable of 'streaming', could you please elaborate on exactly what you mean ?
Being a dinosaur 'streaming' may have a different meaning for me than the context you are using it in.

@delgado, do you have multiple /boot/grub/grub.cfg files, that is, multiple /boot partition mounts ?
Which EFI/<directory>/grub64.efi is being loaded by your PC UEFI, so which EFI/<directory>/grub.cfg is chain loading which /boot/grub/grub.cfg ?

Hit F1,F2,F11,<add whatever key here> during boot to access your PC UEFI boot priority to see which one it is going for.
Installing UEFI bootloaders can rewrite your PC UEFI variables without telling you it has done so.

N.B. UEFI has been forced on you to make your PC more secure and straight forward to configure because as the owner of the PC you are not capable of making those decisions for yourself.

@Eeqmcsq, have you blocked md autodetction at boot ?
The results that you have posted suggest md raid was activated during boot, not after.

nodmraid is an alternative to removing the UDEV, rule.

@Eeqmcsq, looking at my daedalus /lib/udev/rules.d/64-md-raid-assembly.rules as an alternative to removing the script, 'nodmraid' on the kernel command line will cause the script to jump to the end bypassing all of the 'ACTION' directives.

# "nodmraid" on kernel command line stops mdadm from handling
#  "isw" or "ddf".
IMPORT{cmdline}="noiswmd"
IMPORT{cmdline}="nodmraid"

ENV{nodmraid}=="?*", GOTO="md_inc_end"

What needs to be considered is whether a user is expecting to be able to install (onto md storage) from a Live image ?

FWIW: My experience has been mainly with hardware raid, but if i remember correctly the kernel md modules probed for raid at boot.
That means that the Live media kernel version which may be different from the on disk version may come into play.
If it is still done that way you might be able to blacklist the md? modules or pass something like raid=noautodetect?.
Looking...
Running 'modinfo md-mod' gives two parameters ' start_dirty_degraded:int' and 'create_on_open:bool' but grepping
drivers/md/md-autodetect.c does give a hit on 'noautodetect', suggest that warrants further investigation.