My LVM+LUKS setup booted fine and properly displayed the password prompt during boot.

In T10006#189934, @ReillyBrogan wrote:

My LVM+LUKS setup booted fine and properly displayed the password prompt during boot.

Is this with or without proprietary graphics?

Is this with or without proprietary graphics?

Without. Ah, I see now that you needed it tested with Nvidia. I can test that combination momentarily using a different device.

My work laptop with Nvidia graphics (Nvidia-only, not hybrid) and LUKS encryption booted successfully and properly displayed the encryption password prompt. Seems like SIMPLE_DRM is working at least in my case.

It doesn't work for me unfortunately. I get no prompt for LUKS, but it does continue booting after entering the passphrase.

I ran

sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg

and

sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-32bit-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-common-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-current-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-modaliases-470.82.00-414-1-x86_64.eopkg

I wonder if nvidia-drm.modeset=1 has anything to do with it. Although that flag still has to be set manually iirc.

Just tested the new NTFS support and read+write work without issues. No LUKS to test on my end, unfortunately.

FWIW : booting fine in virtualbox / no fs encryption

In T10006#189941, @joebonrichie wrote:

I wonder if nvidia-drm.modeset=1 has anything to do with it. Although that flag still has to be set manually iirc.

I had nvidia-drm.modeset=1 set when I first tested it, but I re-tested it without it and it still worked for me. It doesn't make sense to me that it would really matter in the first place as the nvidia-drm kernel modules aren't included in the initramfs in the first place so that command line argument would do nothing during the LUKS unlocking phase. (Also side-note you can create a 99-nvidia.conf with contents nvidia-drm.modeset=1 in /etc/kernel/cmdline.d/ and clr-boot-manager will automatically add it to the kernel command line options).

@darkness I can't tell from your original task, but is your device using dedicated Nvidia graphics or hybrid?

@JoshStrobl I just extracted the 5.15.1 initrd and it doesn't appear that the simpledrm module is actually being included. I would expect to see it at /lib/modules/5.15.1-206.current/kernel/drivers/gpu/drm/tiny/simpledrm.ko but it is not present which most likely explains why it isn't working for @darkness (why it's working for me is still a giant ? but that's irrelevant). It most likely just needs to be added to the dracut --add-drivers flag.

FWIW: booting fine in very stock Solus Budgie VM running on VMware ESXi 6.5 w/no fs encryption.

Also added a small second disk, formatted as NTFS, and added to fstab with the ntfs3 FS type. Works great in limited testing!

Installed:

• sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg
• sudo eopkg install https://joshuastrobl.com/5.15-testing/open-vm-tools-11.2.5-232-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/open-vm-tools-modaliases-11.2.5-232-1-x86_64.eopkg

@ReillyBrogan Yes, I know...I stated this in the OP.

@darkness I modified the package. Do sudo eopkg dc (deletes cache) and re-run the installation command for the kernel (shouldn't need it for anything else). Assuming you don't see anything reporting [cached] it should be pulling down the new build. Lemme know if that does it for you and I'll mess with it more tomorrow if it doesn't.

Hi, I cant that any of the testing refered but Im using the 5.15.1 kernel + nvidia beta driver all seems fine, I also switched to unstable bcs it was asking for mesa version which wasnt in shannon I did that then switched back to shannon :)

I managed to mount an NTFS partition. I uninstalled ntfs-3g beforehand.

• With mount everything works out of the box, no special flag needed.
• With udisksctl I had to modprobe ntfs. After that, udisksctl mount -b /dev/sdb3 -t ntfs3 worked.
• Dolphin can't mount the NTFS partition. It's probably calling udisksctl via D-Bus passing ntfs, ntfs-3g or something, certainly not ntfs3.

At any rate, with regards to the sole kernel, it all works.

I had issues but not the ones you expected to find. The system had difficulty booting with 50-70% of the boots I did being unsuccessful, booting to a blank screen and being unable to switch to a TTY.

System:
No LUKs or encryption enabled
Unstable repository, fully up to date, no broken packages.

• 3900X
• Nvidia GTX 1060

Packages from this thread installed

• sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg
• sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-32bit-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-common-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-current-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-modaliases-470.82.00-414-1-x86_64.eopkg

Snippet of sudo journalctl -b -1

Nov 09 10:07:08 sokar audit[1043]: NETFILTER_CFG table=nat family=2 entries=10 op=xt_replace pid=1043 subj=unconfined comm="iptables"
Nov 09 10:07:08 sokar audit[1043]: SYSCALL arch=c000003e syscall=54 success=yes exit=0 a0=4 a1=0 a2=40 a3=10b2f70 items=0 ppid=884 pid=1043 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-legacy-multi" subj=unconfined key=(null)
Nov 09 10:07:08 sokar audit: PROCTITLE proctitle=2F7362696E2F69707461626C6573002D77002D2D7461626C65006E6174002D2D696E73657274004C4942564952545F505254002D2D736F75726365003139322E3136382E3132322E302F3234002D70007463700000002D2D64657374696E6174696F6E003139322E3136382E3132322E302F3234002D2D6A756D70004D415351
Nov 09 10:07:08 sokar audit[1044]: NETFILTER_CFG table=nat family=2 entries=11 op=xt_replace pid=1044 subj=unconfined comm="iptables"
Nov 09 10:07:08 sokar audit[1044]: SYSCALL arch=c000003e syscall=54 success=yes exit=0 a0=4 a1=0 a2=40 a3=7d7970 items=0 ppid=884 pid=1044 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-legacy-multi" subj=unconfined key=(null)
Nov 09 10:07:08 sokar audit: PROCTITLE proctitle=2F7362696E2F69707461626C6573002D77002D2D7461626C65006E6174002D2D696E73657274004C4942564952545F505254002D2D736F75726365003139322E3136382E3132322E302F3234002D2D64657374696E6174696F6E003235352E3235352E3235352E3235352F3332002D2D6A756D700052455455524E
Nov 09 10:07:08 sokar kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  470.82.00  Thu Oct 14 10:24:40 UTC 2021
Nov 09 10:07:08 sokar audit[1046]: NETFILTER_CFG table=nat family=2 entries=12 op=xt_replace pid=1046 subj=unconfined comm="iptables"
Nov 09 10:07:08 sokar audit[1046]: SYSCALL arch=c000003e syscall=54 success=yes exit=0 a0=4 a1=0 a2=40 a3=1289ae0 items=0 ppid=884 pid=1046 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-legacy-multi" subj=unconfined key=(null)
Nov 09 10:07:08 sokar audit: PROCTITLE proctitle=2F7362696E2F69707461626C6573002D77002D2D7461626C65006E6174002D2D696E73657274004C4942564952545F505254002D2D736F75726365003139322E3136382E3132322E302F3234002D2D64657374696E6174696F6E003232342E302E302E302F3234002D2D6A756D700052455455524E
Nov 09 10:07:08 sokar audit[972]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=972 comm="Xorg" exe="/usr/lib64/xorg-server/Xorg" sig=6 res=1
Nov 09 10:07:08 sokar systemd[1]: Starting NVIDIA Persistence Daemon...
Nov 09 10:07:08 sokar sddm[892]: Failed to read display number from pipe
Nov 09 10:07:08 sokar sddm[892]: Could not start Display server on vt 7

@Harvey I'm seeing reports of that for SDDM due to the lack of early KMS for NVIDIA, which means the hardware sometimes is not initialized before sddm starts. There was a similar issue related to amdgpu / radeon initialization that was causing GDM to have issues. Fortunately this seems to be unrelated to Linux 5.15.x. Unfortunately we cannot enable early KMS on NVIDIA hardware as it may negatively impact the use of NVIDIA proprietary graphics.

tldr; NVIDIA sucks and we all should've bought AMD GPUs. - Sincerely, a NVIDIA GPU owner.

D12252 reg SDDM issues

I have Intel i5-4460 + GeForce GT 430 + the repo 390 driver.
I was going to do the new kernel/470/broadcom test.
Quick question first: what's the glx 470? Is that the new 390? Or something for computers newer than mine?
That's all, thanks,

In T10006#189995, @brent wrote:

I have Intel i5-4460 + GeForce GT 430 + the repo 390 driver.
I was going to do the new kernel/470/broadcom test.
Quick question first: what's the glx 470? Is that the new 390? Or something for computers newer than mine?
That's all, thanks,

Your GT 430 is not compatible with the 470 driver and you should stick to the 390 series. So in your case follow the instructions under nvidia-390-glx-driver and broadcom-sta

System:
I have Intel i5-4460 + GeForce GT 430 + the repo 390 driver.
stable repo, no luks, no encyption
Packages from this thread installed:

sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg

sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-390-glx-driver-32bit-390.144-122-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-390-glx-driver-common-390.144-122-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-390-glx-driver-current-390.144-122-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-390-glx-driver-modaliases-390.144-122-1-x86_64.eopkg

Method: installed the two packages above, rebooted, spammed enter bar, hand-selected the 5.15xxx, hit enter. waited patiently.
**If I had not hand-selected it was the kernel the highlight was on so it would have auto-booted to 5.15 anyway.

Issue: unlike @Harvey (who I stole this report model from), I had a 100% failure rate to load OS after 5 attempts.
Blue light stayed on my screen; so HDD (Caviar Platter) was active.
Had TTY access.
Ran

sudo eopkg check

but nothing broken.
Results: 100% failure to load OS from 5 straight attempts. It could not get to login screen. Writing to you from 5.14.16xxx.

sudo journalctl -b -1 had red-highlighted clusters of these messages from time to time. Times in log match times OS was attempting to load:

Nov 09 14:29:52 solus kernel: audit: type=1334 audit(1636493392.314:5): prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus kernel: audit: type=1334 audit(1636493392.314:6): prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus kernel: audit: type=1334 audit(1636493392.314:7): prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus kernel: audit: type=1334 audit(1636493392.314:8): prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus kernel: audit: type=1334 audit(1636493392.314:9): prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus kernel: audit: type=1334 audit(1636493392.315:10): prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus audit: BPF prog-id=0 op=UNLOAD
Nov 09 14:29:52 solus kernel: usb 2-10: new high-speed USB device number 5 using xhci_hcd
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-udev.service:27: Standard output type syslog is obsolete, a>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-udev.service:28: Standard output type syslog+console is obs>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-trigger.service:23: Standard output type syslog is obsolete>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-trigger.service:24: Standard output type syslog+console is >
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-pivot.service:30: Standard output type syslog is obsolete, >
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-pivot.service:31: Standard output type syslog+console is ob>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-mount.service:22: Standard output type syslog is obsolete, >
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-pre-mount.service:23: Standard output type syslog+console is ob>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-mount.service:22: Standard output type syslog is obsolete, auto>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-mount.service:23: Standard output type syslog+console is obsole>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-initqueue.service:24: Standard output type syslog is obsolete, >
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-initqueue.service:25: Standard output type syslog+console is ob>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-cmdline.service:26: Standard output type syslog is obsolete, au>
Nov 09 14:29:52 solus systemd[1]: /usr/lib/systemd/system/dracut-cmdline.service:27: Standard output type syslog+console is obso

Can I uninstall :
sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg
sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-32bit-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-common-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-current-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-modaliases-470.82.00-414-1-x86_64.eopkg??

Or does anyone have any suggestions? Thanks

In T10006#190011, @brent wrote:

Can I uninstall :
sudo eopkg install https://joshuastrobl.com/5.15-testing/linux-current-5.15.1-206-1-x86_64.eopkg
sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-32bit-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-common-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-current-470.82.00-414-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-glx-driver-modaliases-470.82.00-414-1-x86_64.eopkg??

Or does anyone have any suggestions? Thanks

If you wish to revert back to the previous packages you can do so with the following:

sudo eopkg install linux-current nvidia-390-glx-driver-32bit nvidia-390-glx-driver-common nvidia-390-glx-driver-current nvidia-390-glx-driver-modaliases broadcom-sta-common broadcom-sta-current broadcom-sta-modaliases --reinstall

I'd note though that your likely issue is farther along in the logs. Those ones you pasted are a separate known issue (there's an update to dracut in testing that should resolve them) and completely harmless.

Can you run the following to capture the entirety of the journal from your previous boot?
sudo journalctl -b -1 --no-pager > boot.log

No problem.

@brent Could you try booting into the kernel, let it fail for a bit, restart your PC, boot into the working kernel, and provide /var/log/Xorg.1.log? Need more info since the only thing indicating an issue there is lightdm failing.

@JoshStrobl sorry I didn't notice your comment.

After reapplying the kernel updates it works!

(I'm running Nvidia dedicated graphics.)

In T10006#190016, @JoshStrobl wrote:

@brent Could you try booting into the kernel, let it fail for a bit, restart your PC, boot into the working kernel, and provide /var/log/Xorg.1.log? Need more info since the only thing indicating an issue there is lightdm failing.

followed this precisely. the xorg.1.log is dated one year ago (maybe it has hidden attributes?)
the xorg.0.log is dated minutes ago. attached are both{F8406628}

guess I made a mistale will try 1,log again{F8406636}

! In T10006#190021, @brent wrote:

followed this precisely. the xorg.1.log is dated one year ago (maybe it has hidden attributes?)
the xorg.0.log is dated minutes ago. attached are both

Neither of those is useful unfortunately since neither is from the boot with 5.15.1. Any chance you have a Xorg.0.log.old or Xorg.1.log.old file as well? One of the first few lines in it should display the current kernel version and only the one with 5.15.1 is useful.

If neither of those exists you should be able to do the following to get a useful log:

1. Boot into 5.15.1
2. Wait a minute or so
3. Log into a TTY (if you're not already dropped at one due to the failure of lightdm to start you should be able to switch to one with CTRL+ALT+F3)
4. cd /var/log
5. ls -ahl
6. Figure out which of the Xorg log files has the newest timestamp (should be within a minute or two of your current time)
7. cp NewestFileName ~/Downloads/
8. Reboot back into a working kernel and then pull the log file out of your downloads folder and upload it

@brent Once you get that log and upload it can you please try the following?

Create the file /etc/X11/30-nvidia-tmp.conf and paste in the following contents:

Section "ServerFlags"
  Option "IgnoreABI" "true"
EndSection

And then reboot back into the 5.15.1 kernel and let us know if that helps. (if it does then your issue is the same one described here)

@ReillyBrogan
gotcha. day just ended will post all info tomorrow. I apologize for not furnishing what you need yet. I seem to be the only one on this thread (save harvey at 50% success) at failure. It's possible I am an anomalous outlier, but hopefully clearer tomorrow.

2. Wait a minute or so
3. Log into a TTY (if you're not already dropped at one due to the failure of lightdm to start you should be able to switch to one with CTRL+ALT+F3)
4. cd /var/log
5. ls -ahl
6. Figure out which of the Xorg log files has the newest timestamp (should be within a minute or two of your current time)
7. cp NewestFileName ~/Downloads/
8. Reboot back into a working kernel and then pull the log file out of your downloads folder and upload it

Followed all steps.
In /var/log the terminal output gave me the two Xorg's dated today--not in minutes to my surprise although some items were. Attached are both.

In T10006#190024, @ReillyBrogan wrote:

@brent Once you get that log and upload it can you please try the following?

Create the file /etc/X11/30-nvidia-tmp.conf and paste in the following contents:

Section "ServerFlags"
  Option "IgnoreABI" "true"
EndSection

And then reboot back into the 5.15.1 kernel and let us know if that helps. (if it does then your issue is the same one described here)

After the last post above I created the file in terminal after changing directory into X11 and cutting/pasting the script into file.
Rebooted into 5.15, 120 seconds go by, no boot.
/var/log/ still weird inasmuch the Xorg's cryptically date themselves Nov 12 and most else to the clock time (if accessed today).

That's interesting. Xorg is complaining about not having the kernel module loaded but there's no error loading the kernel module in the earlier boot log you grabbed.

I tried to reproduce this issue by installing the 390 driver + 5.15.1 on a Nvidia laptop and was not able to. What do you get if you do a sudo lsmod | grep nvidia and a sudo modprobe nvidia_modeset?

sorry for the wait.

$ sudo lsmod | grep nvidia
Password: 
nvidia_uvm            937984  0
nvidia_drm             53248  2
nvidia_modeset       1060864  6 nvidia_drm
nvidia              15884288  193 nvidia_uvm,nvidia_modeset
drm_kms_helper        303104  1 nvidia_drm
ipmi_msghandler        73728  2 ipmi_devintf,nvidia
drm                   634880  5 drm_kms_helper,nvidia_drm

(I have duplicate 390s from flatpak zoom but one stays unused to the best of my knowledge)

this bears no fruit at all, just goes into next $.

$ sudo modprobe nvidia_modeset -v
$ sudo modprobe --verbose nvidia_modeset
 $ sudo modprobe nvidia_modeset --verbose

Just a heads up for folks, going to be cooking 5.15.2 and module rebuilds sometime today (tomorrow, got busy). Will follow-up and update all the links when it is sorted. Thanks for all the testing done so far (I appreciate you all taking the risk and dogfooding the kernel), it's good to hear that aside from some outliers (poor @brent), the changes done in the configuration for SIMPLEDRM have worked. I might try building with SIMPLEDRM off and FB_SIMPLE on after 5.15.2+rebuilds as well to see if that sorts it for individuals using 390.xx (assuming 5.15.2 doesn't).

So not the end of testing, not going to be pushing any of this to unstable until we have validation across the board.

@brent, just to rule out a potential timing issue between the Nvidia modules and lightdm, could you run the following in a tty after lightdm fails to start: sudo systemctl restart lightdm

@ReillyBrogan

sudo systemctl status lighdm

showed the usual: : loaded, failed, start request repeated too quickly, failed with exit-code

sudo systemctl restart lightdm

went to black screen, blinking cursor, upper left.

still had tty though

@JoshStrobl how will linux-current-5.15.2 be different from linux-current-5.15.1-206-1? besides simpledrm? (I'm holding out hope!)

besides simpledrm? (I'm holding out hope!)

That is already in my 5.15.1 builds. In terms of what is in 5.15.2, you can check the changelog on kernel.org. Likely nothing meaningful but maybe all the added rebuilds will help.

Will be getting this out tomorrow. Ended up getting busy with other things so didn't have time today.

Just tested 5.15.1 on my laptop (Tiger Lake with Iris Xe) with no issues on Solus Budgie. Hard drive is LVM and encrypted.

Hey folks, sorry for the delay. IRL stuff came up related to searching / interviews / assignment for a full-time job, so had to put all this on the backburner.

I have updated the task description to point to 5.15.5, the latest 5.15 point release as of posting. Everything has gotten rebuilt, but just be aware that this will require you to be on the unstable repo and have updated since there is some xorg-server updates, mesalib rebuilds, etc. that eopkg will get cranky about.

The kernel was bumped to rel 207, so this should replace 5.15.1-206 just fine, just be aware that I didn't relbump the drivers, only did rebuilds of them. So be sure to do sudo eopkg dc to clear the cache before running the commands above.

@brent Let us know the situation with your card with 5.15.5 and the rebuilds. As far as I can tell, 390 validation is the only thing that is preventing me from getting this pushed to unstable.

Booting fine on my system with:

linux-current-5.15.5
nvidia-390-glx-driver-32bit
nvidia-390-glx-driver-common
nvidia-390-glx-driver-current
nvidia-390-glx-driver-modaliases
virtualbox-common
virtualbox-current

This workaround in /usr/share/X11/xorg.conf.d/10-nvidia.conf is required by following contents as @ReillyBrogan suggested:

Section "ServerFlags"
  Option "IgnoreABI" "true"
EndSection

In T10006#190526, @JoshStrobl wrote:

@brent Let us know the situation with your card with 5.15.5 and the rebuilds. As far as I can tell, 390 validation is the only thing that is preventing me from getting this pushed to unstable.

Thanks for the heads up. Will report back when this rolls out.

If you still needs some testing done ahead of the 5.15.5 rollout, I'd be glad to oblige.

I tried installing the 5.15.5-207 on my second "test" pc and after the next update (eopkg up) it downgraded to 5.14.21 . Did i do something wrong? , installed just the kernel and the bbswitch , but same think...

@supernova874 That is because this test has concluded, and after the initial update to 5.15 and following revert to 5.14 because of the issues experienced with the former, the release number for the linux-current package in the repository is now higher than the one for these testing packages (210 vs 207), and thus the test package gets replaced on every sudo eopkg up
There will be new packages built if and when another test is scheduled.

ok , i understand , thanks for your time :)