I notice that the common denominator is Intel firmware.
I don't know if they're working on that firmware, or not, but it could well be that all of a sudden all that mayhem just goes away.
You mean for the Broadwell soundcard?
I could, but first I'll have to get that install on the Helix in a pristine state again. 
im a bit confused following this thread 
i mean i got lost at on where is the issue and what was the cause, so let's start again... what is the thing that is not working on the "default elive" and how to fix it? (if), there's a 6.9 kernel update and the link i shown where individual firmwares can be tried independently
Well we've been doing quite a back-and-forth about the soundcard, until you threw the wifi card into the mix....so I'll recap:
The issue is that (builtin Intel) Broadwell-rt268 soundcards do not work on Bookworm (or any recent distro). It works on older Buster and on Bodhi 7 (based on Ubuntu22.04) but NOT on newer Ubuntu versions.
The cause is unknown to me but probably mismatched firmware. I will quote myself here because IMO the issue was clearly worded in the first post:
and:
Here's ascreenshot of the working modules (Bodhi)
and the loaded modules on Elive:
snd_soc_bdw_rt286 20480 0
snd_hda_codec_hdmi 94208 1
snd_soc_catpt 86016 1
snd_hda_intel 61440 1
snd_soc_rt286 53248 1
snd_soc_rl6347a 12288 1 snd_soc_rt286
snd_soc_acpi 16384 1 snd_soc_catpt
snd_hda_codec 225280 2 snd_hda_codec_hdmi,snd_hda_intel
snd_soc_core 434176 3 snd_soc_catpt,snd_soc_rt286,snd_soc_bdw_rt286
snd_hda_core 147456 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_compress 28672 1 snd_soc_core
snd_intel_dspcfg 36864 2 snd_soc_catpt,snd_hda_intel
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_hwdep 20480 1 snd_hda_codec
snd_intel_sdw_acpi 16384 1 snd_intel_dspcfg
snd_pcm_oss 69632 0
snd_mixer_oss 28672 1 snd_pcm_oss
snd_pcm 192512 10 snd_soc_catpt,snd_hda_codec_hdmi,snd_hda_intel,snd_soc_rt286,snd_hda_codec,snd_compress,snd_pcm_oss,snd_soc_core,snd_hda_core,snd_pcm_dmaengine
snd_timer 53248 1 snd_pcm
snd 155648 14 snd_soc_catpt,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_compress,snd_pcm_oss,thinkpad_acpi,snd_soc_core,snd_pcm,snd_mixer_oss
soundcore 16384 1 snd
dw_dmac_core 40960 2 snd_soc_catpt,dw_dmac
That is quite something else.
And the working card choice in 'alsamixer' on Bodhi:
whereas on Elive 'alsamixer' crashes with an error when choosing the rt268 stating:
cannot load mixer controls:Invalid argument
And dmesg fills up with the same errors as before:
Doing a complete fresh install on that machine today, after which I will upgrade to kernel 6.9.7
Addendum:
Which again didn't go very well.
A total fresh install using the whole disk froze while checking UUID tree.
A reboot and new try did work (and used BTRFS ??? 
) but again refused to boot requiring a "sudo dpkg-reconfigure grub-efi-amd64".
Upgrading to 6.9.7 errored out and wont boot with a kernel panic, alas.
try these commands to see what is happening:
dmesg | grep -i firmware
tail -f /var/log/{syslog,kern.log}
reading on internet seems like after kernel 5.10.142 (or similar) the audio card doesn't works, so you may want to try to boot an elive iso using the second kernel option to see if works
is this a still-existing issue in the installer? I can't recall now if this was fixed or not
yes, btrfs is now the default choice . About grub, there was some fixes too in the last month... it is still an existing bug?
Exactly!
Using only an older kernel doesn't work .... it requires the modules to be called and initiated correctly i.e Buster NOT Bullseye.
Which choice, by the look of things makes the "upgrade" option buggy i.e doesn't find the previous installation.
hum... it is possible that this was an old bug fixed the last weeks, because should be not the case (when upgrade mode, the filesystem is not "selected" but "read", so if is ext4 it should use ext4 and not another one). I added a note in my TODO to make a betatest of that...
Here's another TODO for testing:
Today I tried to upgrade an existing Elive 3.8.19 (5.7.0 kernel) from 2020 to 3.8.43. which refuses to do so.
There's an initial caveat I noticed, that when asking about the EFI partiion, it includes the partition on the USB drive (in my case sda2) which might confuse a lot of people,
An hour after starting the upgrade (i.e showing the zenity widget) .... nothing changes.
Looking at the current tasks (through 'top') I can see 'zenity' but no activity like 'cp' or anything related to disk activity. It just hangs there.
The same happened a week ago on that machine, it's not a coincidence I fear. 
On a sidenote:
This machine has audio built into the MoBo, which is broken. This gives a warning pop-up that does not go away (you can see it in the background). After closing it 16x I gave up and later found out that only by clicking 'OK' actually killed it. 
On another sidenote: "$USER/.local/share/bin/" isn't kept intact by the upgrader. Python pip (and personal apps get put there) so but it might be nice to keep that alongside the other kept directories.
ADDENDUM:
I found out that closing the "info" widget makes the installer continue. Gaaaahh !! 
And once finished and rebooted twice, after closing the audio warning, there's 3 authenticate widgets I have to do (
) then an error is reported and a 4th authenticate widget
.....and then the audio warning requires being killed 6x again.
This happens on every log-in unless I comment out "audio-fixes" in .e16/startup-applications.list 
The EFI from the usb should not be shown on this case, I think this has been improved in the last months in the code to not show these cases, so tell me if you see it again
Which one exactly ? the one about the audio not found ?
It should... I need to betatest with that. BTW is .local/bin and not .local/share/bin (you may want to verify that)
BTW I want to integrate better python "by default" in elive, but there's many ways to use python... "venv, pip, pipx, etc...", since im not much familiar nor I use python, which one/ones I should include by default? I have recently used "pipx" to install a software and seems to be well managed, but installing "pipx" by default in Elive is 5 mb more
Mmmh... I just "disabled audio" in my vbox machine, restarted a new desktop, and this message only appears once per desktop login (due to the elive-audio-fixes autostart app), not 6x times and not any "privileges" window if still happening on you we must check what is causing that (ps aux, pstree, etc?)
Note: 3.8.46 going to be released soon
Depends on the distro. Both places are allowed/used.
.local/bin is autodetected and added to the path, but not .local/share/bin (not standard)
If I run 3.8.40 in live mode I have no /bin directory in either .local/ or .local/share/ .
That makes me unsure why it got installed there.
Maybe if there is an existing (empty) '.local/bin' all apps will go there automatically.
At the least it will show the preferred path for those having their own scripts. 
'pipx' is not really necessary unless you want to install some very specific python scripts with very specific python dependencies ..... not really 'normal-user' stuff, and there are certain vulnerability risks.
I use it if I want to have a python script that runs on Apple and Windows too. Quite often there are version compatibility issues between python packages on the platforms. Using 'pip' on each platform solves that.
Most needed python dependencies and often used python applications are usually catered for through the debian repositories.
mmh not sure to understand but basically, if you don't have .local/bin things there, it will not be included in your PATH variable, if you have something, a new shell will have it added into your PATH variable (dynamic). On the other hand .local/share/bin should be not a correct directory, i don't think its a correct standard, bin goes before share, so im curious about "which" (bad) applications installs on that directory, of in the case of distros, bad distros
About pipx, I used it to install locally (user mode) a python software that i had difficult using "pip" alone, pipx did the job in a very automated way
Yes, from what I gather /share is for exactly that: sharing common stuff like icons, etc. So let's stick to .local/bin
That's weird, considering 'pipx' just runs pip with a gui.
Anyway ..... when considering using 'pip(x)' to install something, first also do an 'apse' to see if it's already on offer through the repositories. Quite often, they are there already and if they aren't: They're either very, very new/recent or not good/safe enough.
