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 
