Page MenuHomeSolus

Linux 5.15.5 Testing Task
Closed, ResolvedPublic

Description

This task exists for the testing of Linux 5.15. If you are not using the "current" kernel and have specifically opted for linux-lts, this task is probably not for you.

5.15.5 introduces a variety of changes and improvements, you can see a summary of these at https://kernelnewbies.org/Linux_5.15

The goal of this task is to test the following:

NTFS

The new NTFS driver that has been enabled. CONFIG_NTFS3_64BIT_CLUSTER is not enabled and therefore should be compatible with Windows NTFS partitions.

LUKS

LUKS / encrypted setups, namely for those affected by the changes in the kernel in 5.14.11. I have been manually changing CONFIG_FB_SIMPLE back from m to y to ensure it is compiled in-kernel and not as a separate loadable module. The change to m in 5.14.11 seemed to have resulted in breakages for LUKS-based install when those installs used NVIDIA proprietary graphics. As of 5.15, CONFIG_FB_SIMPLE can no longer be enabled if DRM_SIMPLEDRM is, so we'll have to choose between one or the other. I have not seen any indication that it affects non-NVIDIA graphics solutions (or at the very least non-proprietary graphics) and so I'm following the advice of one of the kernel developers responsible for these changes and using this as an opportunity to test if DRM_SIMPLEDRM is a viable option. It is intended to be a drop-in replacement for CONFIG_FB_SIMPLE. Right now it is set to m, however setting it as an in-kernel module is an option and I may try that if NVIDIA testing doesn't provide positive results. It is quite likely I'll need to do that, but hey let us find out.

Testing

NOTE: Be sure to at run the 5.15.5 install command and not just install the modules. Also be sure to run sudo eopkg dc to clear any existing eopkg cache before installing these eopkgs.

If you are interested in testing, please pay attention to the below commands and be mindful of what supplemental kernel drivers you have installed. For example, if you have virtualbox installed, run the virtualbox command. If you have nvidia-glx-driver installed, run that. Do not reboot until you have ensured all of the drivers are installed.

Kernel 5.15.5

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

bbswitch

sudo eopkg install https://joshuastrobl.com/5.15-testing/bbswitch-current-0.8-257-1-x86_64.eopkg

broadcom-sta

sudo eopkg install https://joshuastrobl.com/5.15-testing/broadcom-sta-common-6.30.223.271-321-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/broadcom-sta-current-6.30.223.271-321-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/broadcom-sta-modaliases-6.30.223.271-321-1-x86_64.eopkg

nvidia-390-glx-driver (includes 32bit)

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

nvidia-beta-driver (includes 32bit)

sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-beta-driver-32bit-495.44-164-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-beta-driver-common-495.44-164-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-beta-driver-current-495.44-164-1-x86_64.eopkg

nvidia-developer-driver (includes 32bit)

sudo eopkg install https://joshuastrobl.com/5.15-testing/nvidia-developer-driver-32bit-470.62.07-169-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-developer-driver-common-470.62.07-169-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-developer-driver-current-470.62.07-169-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/nvidia-developer-driver-modaliases-470.62.07-169-1-x86_64.eopkg

nvidia-glx-driver (includes 32bit)

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

open-vm-tools

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

v4l2loopback

sudo eopkg install https://joshuastrobl.com/5.15-testing/v4l2loopback-common-0.12.5-220-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/v4l2loopback-current-0.12.5-220-1-x86_64.eopkg

vhba-module

sudo eopkg install https://joshuastrobl.com/5.15-testing/vhba-module-common-20200106-182-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/vhba-module-current-20200106-182-1-x86_64.eopkg

virtualbox

sudo eopkg install https://joshuastrobl.com/5.15-testing/virtualbox-common-6.1.28-220-1-x86_64.eopkg https://joshuastrobl.com/5.15-testing/virtualbox-current-6.1.28-220-1-x86_64.eopkg

Reporting

Please provide feedback if NTFS and LUKS works or does not work for you. If you have no NTFS partitions, that testing can be skipped. If you are suddenly encountering other hardware issues, please validate that the issue does not exist on 5.14.x before mentioning it.

Prodding @darkness for testing, as original reporter of T9962

Event Timeline

JoshStrobl triaged this task as High priority.
JoshStrobl created this task.
JoshStrobl added a project: Hardware.
JoshStrobl moved this task from Backlog to Improvement on the Software board.
Katoa added a subscriber: Katoa.Mon, Nov 8, 3:02 PM
JoshStrobl updated the task description. (Show Details)Mon, Nov 8, 5:03 PM
JoshStrobl updated the task description. (Show Details)

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

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.

Staudey added a subscriber: Staudey.Mon, Nov 8, 7:29 PM

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

kyrios123 added a subscriber: kyrios123.EditedMon, Nov 8, 8:27 PM

FWIW : booting fine in virtualbox / no fs encryption

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.

gsf added a subscriber: gsf.EditedMon, Nov 8, 9:52 PM

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 :)

livingsilver94 added a subscriber: livingsilver94.EditedMon, Nov 8, 10:23 PM

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.

Harvey added a subscriber: Harvey.Mon, Nov 8, 11:43 PM

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

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
JoshStrobl added a comment.EditedTue, Nov 9, 8:30 AM

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

brent added a subscriber: brent.Tue, Nov 9, 7:03 PM

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,

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

brent added a comment.Tue, Nov 9, 10:07 PM

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

ReillyBrogan added a comment.EditedTue, Nov 9, 10:22 PM

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

Harvey removed a subscriber: Harvey.Tue, Nov 9, 10:23 PM
brent added a comment.Tue, Nov 9, 10:34 PM

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

brent added a comment.Wed, Nov 10, 7:51 PM

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

brent added a comment.Wed, Nov 10, 7:52 PM

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
ReillyBrogan added a comment.EditedWed, Nov 10, 8:43 PM

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

brent added a comment.Thu, Nov 11, 2:48 AM

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

brent added a comment.Fri, Nov 12, 3:03 AM
  1. Wait a minute or so
  2. 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)
  3. cd /var/log
  4. ls -ahl
  5. Figure out which of the Xorg log files has the newest timestamp (should be within a minute or two of your current time)
  6. cp NewestFileName ~/Downloads/
  7. 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.

brent added a comment.Fri, Nov 12, 3:17 AM

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

ReillyBrogan added a comment.EditedFri, Nov 12, 10:02 PM

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?

brent added a comment.Sun, Nov 14, 3:49 AM

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
JoshStrobl added a comment.EditedMon, Nov 15, 10:37 AM

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

brent added a comment.Mon, Nov 15, 7:19 PM

@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!)

JoshStrobl added a comment.EditedMon, Nov 15, 9:29 PM

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.

JoshStrobl renamed this task from Linux 5.15.1 Testing Task to Linux 5.15.5 Testing Task.Sat, Nov 27, 2:43 PM
JoshStrobl updated the task description. (Show Details)
JoshStrobl added a comment.EditedSat, Nov 27, 2:48 PM

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.

algent added a subscriber: algent.EditedSat, Nov 27, 8:48 PM

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
JoshStrobl closed this task as Resolved.Sat, Nov 27, 8:57 PM

Given the IgnoreABI works, going to mark this as resolved and push it. Thanks for the testing folks.

brent added a comment.Sun, Nov 28, 1:23 AM

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