ALHP/ALHP.GO
6
43
Fork 9
Code Issues 25 Pull Requests Projects Releases Wiki Activity

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
Copy Link

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
PXL_20211125_162307310.jpg
anonfunc commented 2021-11-25 23:27:12 +01:00
Owner
Copy Link

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.

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 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
Copy Link

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
Copy Link

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
Copy Link

@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
Copy Link

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.
blackout commented 2022-07-19 08:38:03 +02:00
Copy Link

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
Copy Link

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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked upstream
bug
Something is not working
 build-failure
package build fails
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 informational
Provides information about something
 invalid
Something is wrong
 invalid/corrupt package
Package needs to be rebuild
 packaging issue
priority: high
High priority
 question
More information is needed
 support
wontfix
This won't be fixed
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
anonfunc
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ALHP/ALHP.GO#68
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?