ALHP/ALHP.GO

Fork 9

modules linked to 'linux' fail with x86_64-v3 'linux' #68

New Issue

Open

opened 2021-11-25 23:01:00 +01:00 by Eris420 · 7 comments

Eris420 commented

2021-11-25 23:01:00 +01:00

After updating and installing the v3 kernel, I was no longer able to start x, as it couldn't load the nvidia driver. After a fair bit of messing around to figure out what the problem was, i realized that using the v3 kernel doesn't work with nvidia and requires nvidia-dkms instead. See attached image for Xorg logs

After updating and installing the v3 kernel, I was no longer able to start x, as it couldn't load the `nvidia` driver. After a fair bit of messing around to figure out what the problem was, i realized that using the v3 kernel doesn't work with `nvidia` and requires `nvidia-dkms` instead. See attached image for Xorg logs

PXL_20211125_162307310.jpg

334 KiB

anonfunc commented

2021-11-25 23:27:12 +01:00

Owner

Good find. After thinking about how to fix this for a moment, there are multiple solutions, but only one 'truly' fixes this issue:

building nvidia and other packages directly linking to linux with ALHP's version of linux (the 'true' fix)
issue a warning about kernel modules directly linked to linux while upgrading linux if nvidia (or others directly linking) is installed
adding it to FAQ in the README

I personally think only 3) is too weak a warning for a graphic-breaking 'bug' as this one. 1) is the 'real' fix, but not that quickly implemented (generate a new pacman.conf with alhp included and implement separate logic for kernel modules to be build after the kernel itself). 2) may be a good compromise for now until 1) is implemented.

Good find. After thinking about how to fix this for a moment, there are multiple solutions, but only one 'truly' fixes this issue: 1. building `nvidia` and other packages directly linking to `linux` with ALHP's version of `linux` (the 'true' fix) 2. issue a warning about kernel modules directly linked to `linux` while upgrading `linux` if `nvidia` (or others directly linking) is installed 3. adding it to FAQ in the README I personally think only 3) is too weak a warning for a graphic-breaking 'bug' as this one. 1) is the 'real' fix, but not that quickly implemented (generate a new pacman.conf with alhp included and implement separate logic for kernel modules to be build after the kernel itself). 2) may be a good compromise for now until 1) is implemented.

anonfunc added the

bug

label 2021-11-25 23:31:49 +01:00

anonfunc referenced this issue

2021-11-30 22:40:25 +01:00

virtualbox host modules don't work with v3 kernel #71

anonfunc changed title from ~~x can't find nvidia proprietary driver when using x86_64-v3 kernel~~ to modules linked to 'linux' fail with x86_64-v3 'linux'

2021-12-01 07:59:40 +01:00

Urgau commented

2021-12-29 11:55:11 +01:00

Any update on that front ? Would you like some help ?

It would be cool, if I had not to worry about not forgetting to update the kernel and kernel modules separatly.

Any update on that front ? Would you like some help ? It would be cool, if I had not to worry about not forgetting to update the kernel and kernel modules separatly.

anonfunc commented

2021-12-29 12:08:34 +01:00

Owner

You can just use the dkms variant in the meantime. There are no extra manual steps required with these.

I currently plan to fix this by installing linux with mkchrootpkg's -I option, therefore it should be linked to that kernel. I have not tested this yet, I just assume pacman does not reinstall linux while installing dependencies for the package to-be-build.
If my assumption turns out to be wrong plan B would involve modifying the pacman.conf used in the chroots, including [core], [extra] and [community] in their respecting x86-64-vN version by passing mkarchchroot's -C option on chroot creation. This would involve a lot more work, since no pacman.conf modifying is happening currently.

Besides this I need logic to determine if a package links to linux. One possible (but not perfect) option would be to check for linux-headers as makedep and linux as depends.

You can just use the dkms variant in the meantime. There are no extra manual steps required with these. I currently plan to fix this by installing `linux` with `mkchrootpkg`'s `-I` option, therefore it should be linked to that kernel. I have not tested this yet, I just assume pacman does not reinstall linux while installing dependencies for the package to-be-build. If my assumption turns out to be wrong plan B would involve modifying the `pacman.conf` used in the chroots, including **[core]**, **[extra]** and **[community]** in their respecting x86-64-vN version by passing `mkarchchroot`'s `-C` option on chroot creation. This would involve a lot more work, since no pacman.conf modifying is happening currently. Besides this I need logic to determine if a package links to `linux`. One possible (but not perfect) option would be to check for `linux-headers` as `makedep` and `linux` as `depends`.

Urgau commented

2022-02-28 11:13:00 +01:00

@anonfunc Hi, is this moving forward ? It's still a bit annoying to ignore linux and all of it's module, than force update them from the official repo.

You can just use the dkms variant in the meantime.

Sorry, can't, I use r8168 who doesn't have a dkms variant. (There is one in AUR, but I don't trust AUR enough for this essential piece of software).

@anonfunc Hi, is this moving forward ? It's still a bit annoying to ignore `linux` and all of it's module, than force update them from the official repo. > You can just use the dkms variant in the meantime. Sorry, can't, I use `r8168` who doesn't have a `dkms` variant. (There is one in AUR, but I don't trust AUR enough for this essential piece of software).

anonfunc commented

2022-03-04 13:49:13 +01:00

Owner

I'm currently somewhat busy with work, I'm not sure when I can find the time working on this.

I'll accept PRs for this of course, but this is not exactly first-PR material.

I'm currently somewhat busy with work, I'm not sure when I can find the time working on this. I'll accept PRs for this of course, but this is not exactly first-PR material.

anonfunc referenced this issue

2022-03-22 23:04:55 +01:00

Modules from package virtualbox-host-modules-arch in wrong path #105

anonfunc referenced this issue

2022-05-29 23:07:30 +02:00

[Suggestion] Blacklist Nvidia drivers #126

blackout commented

2022-07-19 08:38:03 +02:00

I installed the nvidia package and found out that there are 2 modules folder:

5.18.12-arch1-1 which contains a folder extramodules with the nvidia*.ko.xz
5.18.12-arch1-1.1 with all our kernel modules

I think that this is an issue

_kernver="$(</usr/src/linux/version)"
should be replaced by
_kernver=$(uname -r)

I installed the `nvidia` package and found out that there are 2 modules folder: * 5.18.12-arch1-1 which contains a folder `extramodules` with the `nvidia*.ko.xz` * 5.18.12-arch1-1.1 with all our kernel modules I think that this is an issue `_kernver="$(</usr/src/linux/version)"` should be replaced by `_kernver=$(uname -r)`

anonfunc commented

2022-07-19 13:44:21 +02:00

Owner

I installed the nvidia package and found out that there are 2 modules folder:

5.18.12-arch1-1 which contains a folder extramodules with the nvidia*.ko.xz

5.18.12-arch1-1.1 with all our kernel modules

That is the whole point of this issue, to fix this.

I think that this is an issue

_kernver="$(</usr/src/linux/version)"
should be replaced by
_kernver=$(uname -r)

Nope, that would link it against the kernel currently running on the build machine, which is obviously not what we want. The only way to solve this is to install our respective kernel package into the chroot before building.

> I installed the `nvidia` package and found out that there are 2 modules folder: > * 5.18.12-arch1-1 which contains a folder `extramodules` with the `nvidia*.ko.xz` > * 5.18.12-arch1-1.1 with all our kernel modules That is the whole point of this issue, to fix this. > I think that this is an issue > > `_kernver="$(</usr/src/linux/version)"` > should be replaced by > `_kernver=$(uname -r)` Nope, that would link it against the kernel currently running on the build machine, which is obviously not what we want. The only way to solve this is to install our respective kernel package into the chroot before building.