Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
Weird conflict/dependency/maybe-bug hell with Debian Bookworm and RTL8188FTV (0bda:f179)
There's some weird situation, for me at least, where apparently I can't install the headers of linux 6, due to failure in dkms building the module for this USB wireless adapter. Which in turn depends on the headers themselves being installed, if I'm not misunderstanding, which may well be the case.
Additionally, there were some reported bugs in some stuff, G++ and/or GCC, while updating from frankendebian-pre-Bookworm to what may be a more proper bookworm release. Although I think they may not even really affect this, but only relevant to some other architecture, I'm not sure.
I ended up nevertheless having at least two different error logs while trying to build the module, seemed like a dead end. I really should document better what I'm doing and the error logs.
Anyway, the github site for the wireless adapter module had this notice that it would sort of be incorporated in 6.2+ versions of the Linux kernel (or some other code for the same hardware, I don't know). While the stock Linux 6 for Debian Bookworm is below that, luckily the Liquorix kernel is already 6.3, and the native module of the kernel indeed works
The whole situation had me in some kind of dependency hell even to install liquorix, the same error, basically, as dkms tried to compile the module even for the kernel that doesn't need it, leaving it and its headers unconfigured. But I guess I circumvented it by then just setting the kernel alone to be installed, in synaptic (instead of re-running the install inscript, which nevertheless adds the repository lines). Or somehow the previous failure in building the module had some key difference that happened to solve just that, but I guess it was just not installing the headers that "fixed" it.
Not an ideal situation yet, but better than pre-Bookworm frankendebian with kernel 5, I guess. It seems an added bonus is that the native module is far less needleslly verbose than the one I had/have compiled for earlier kernels. I even had to alias or script-wrap dmesg into negative-grepping a bunch of stuff that pretty much was 99% of dmesg output.
It also didn't require to change anything related to blacklistings, apparently, which is luckily preventing some nuisance if I eventually see myself needing to boot in older kernels, for some reason. Hopefully not.
...............
Edit. While trying to install liquorix' own headers, which ironically I may not even end up using, since the only thing I guess I was using them for recently was this module, I stumbled into some weird problems with dkms.
The module dkms conf had it set to build for all kernels, which I changed by adding:
And removing the "all" from the make line, which may be unrelated and perhaps cause failure in case I have to build again for a "new" kernel 5.
(it's indeed unrelated to which kernels it's building for, but rather refers to what it builds, it probably should be put back there, unless it happened to be redundant. Maybe this explains: https://code.whatever.social/questio...e-and-make-all )
But even then, Debian's dkms system was making dpkg/apt fail on the configuration of the 6+ kernels, based on that, as this directive would make it return error.
Then I edited /usr/sbin/dkms itself, copying and deleting (commenting-out) some lines based on some commit that reverted this problem, based on some discussion I found before, but can't find again. The dkms script was "significantly" different in some parts, I even left out some new additions that apparently were related only with messages to the user, rather than exit signals and the mechanics of the script.
Apparently it worked, I wish I wasn't googling for it on "incognito" mode so I wouldn't need to look for it again now.
Finally:
https://bugs.launchpad.net/ubuntu/+s...s/+bug/2018226
The seemingly critical things were between the lines 2263 and 2272, which I altered correspondingly.
Additional related stuff I don't get yet, and may be source of problems: apparently the dkms.conf file is copied to a different location at some point, so I'm not even sure which one I need to edit. I edited both, one at /usr/src/<module-name> and other somewhere in "/var/lib/dkms/rtl8188fu/1.0/build"
I was also at some point under the impression you could just rename some directory with the dkms module for it to be ignored, but then it's really just read under the different directory name. It has to be moved somewhere else, if for some reason you're tweaking things and deleting it may seem to be part of the solution.
Additionally, there were some reported bugs in some stuff, G++ and/or GCC, while updating from frankendebian-pre-Bookworm to what may be a more proper bookworm release. Although I think they may not even really affect this, but only relevant to some other architecture, I'm not sure.
I ended up nevertheless having at least two different error logs while trying to build the module, seemed like a dead end. I really should document better what I'm doing and the error logs.
Anyway, the github site for the wireless adapter module had this notice that it would sort of be incorporated in 6.2+ versions of the Linux kernel (or some other code for the same hardware, I don't know). While the stock Linux 6 for Debian Bookworm is below that, luckily the Liquorix kernel is already 6.3, and the native module of the kernel indeed works
The whole situation had me in some kind of dependency hell even to install liquorix, the same error, basically, as dkms tried to compile the module even for the kernel that doesn't need it, leaving it and its headers unconfigured. But I guess I circumvented it by then just setting the kernel alone to be installed, in synaptic (instead of re-running the install inscript, which nevertheless adds the repository lines). Or somehow the previous failure in building the module had some key difference that happened to solve just that, but I guess it was just not installing the headers that "fixed" it.
Not an ideal situation yet, but better than pre-Bookworm frankendebian with kernel 5, I guess. It seems an added bonus is that the native module is far less needleslly verbose than the one I had/have compiled for earlier kernels. I even had to alias or script-wrap dmesg into negative-grepping a bunch of stuff that pretty much was 99% of dmesg output.
It also didn't require to change anything related to blacklistings, apparently, which is luckily preventing some nuisance if I eventually see myself needing to boot in older kernels, for some reason. Hopefully not.
...............
Edit. While trying to install liquorix' own headers, which ironically I may not even end up using, since the only thing I guess I was using them for recently was this module, I stumbled into some weird problems with dkms.
The module dkms conf had it set to build for all kernels, which I changed by adding:
Code:
BUILD_EXCLUSIVE_KERNEL="^5.*"
(it's indeed unrelated to which kernels it's building for, but rather refers to what it builds, it probably should be put back there, unless it happened to be redundant. Maybe this explains: https://code.whatever.social/questio...e-and-make-all )
But even then, Debian's dkms system was making dpkg/apt fail on the configuration of the 6+ kernels, based on that, as this directive would make it return error.
Then I edited /usr/sbin/dkms itself, copying and deleting (commenting-out) some lines based on some commit that reverted this problem, based on some discussion I found before, but can't find again. The dkms script was "significantly" different in some parts, I even left out some new additions that apparently were related only with messages to the user, rather than exit signals and the mechanics of the script.
Apparently it worked, I wish I wasn't googling for it on "incognito" mode so I wouldn't need to look for it again now.
Finally:
https://bugs.launchpad.net/ubuntu/+s...s/+bug/2018226
Quote:
Kernel upgrades fail if DKMS packages are currently installed that include BUILD_EXCLUSIVE directives which skip the DKMS build. In this case, the dkms tool incorrectly returns a non-zero exit status.
[...]
Upstream commit that introduced the regression: https://github.com/dell/dkms/commit/...3ccf033c7c8349
Juerg Haefliger (juergh) wrote on 2023-05-01: #4
And upstream commit that fixed it: https://github.com/dell/dkms/commit/...3876ff512e8eb0
[...]
Upstream commit that introduced the regression: https://github.com/dell/dkms/commit/...3ccf033c7c8349
Juerg Haefliger (juergh) wrote on 2023-05-01: #4
And upstream commit that fixed it: https://github.com/dell/dkms/commit/...3876ff512e8eb0
Additional related stuff I don't get yet, and may be source of problems: apparently the dkms.conf file is copied to a different location at some point, so I'm not even sure which one I need to edit. I edited both, one at /usr/src/<module-name> and other somewhere in "/var/lib/dkms/rtl8188fu/1.0/build"
I was also at some point under the impression you could just rename some directory with the dkms module for it to be ignored, but then it's really just read under the different directory name. It has to be moved somewhere else, if for some reason you're tweaking things and deleting it may seem to be part of the solution.
Total Comments 0
