[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 07/04/2020 12:41, Julian Hall wrote:
By built it myself do you mean installed it using apt-get not Mint's Update Manager?
I thought about this last night, and I wondered why Mint's Update Manager listed kernels older than the one I had running. I /think/ what may be happening is that the Update Manager keeps a record of what /it/ has installed and offers updates based on /that/, not what is actually installed.
My apologies. Yes I followed your instructions and got everything matching, kernel, headers etc. uname gives 5.3.0-46-generic.
As above I did that when you advised me to. I think what happened is I didn't spot when Thunderbird replied from the wrong address, so I intended to confirm I had done it but it didn't get to the list.
In a nutshell I am currently running thw kernel you advised above.
No problem, I feel like your Mum telling you off half the time!Speaking of which, try and snip your quoted walls of text a bit as they get very confusing to follow otherwise. *Wags finger*
So far so good. You've got the latest 5.x kernel running complete with all the headers and - I think - the module for the wifi card built and loaded for it. Check with:
* dkms status You should see something like: comrade@drone:~$ dkms status 8812au, 4.2.2, 4.15.0-96-generic, x86_64: installed 8812au, 4.2.2, 5.3.0-45-generic, x86_64: installed 8812au, 4.2.2, 5.3.0-46-generic, x86_64: installedAs you can see the dkms job (you set it up on yours as well remember) automatically rebuilds the 8812au module for you dynamically against every new kernel you install.
So by now you should have the latest kernel and bits and the 8812au module correctly built via dkms and loaded by default. Here we should repeat a previous step to see what happens:
* dmesg -wTAnd unplug/replug the wifi adaptor. Look carefully at (and post) exactly what dmesg spits out during the processs, it will only be 10-20 lines. We need to find out what device name assignation it's getting as it's renamed from default eth0 to it's new alias, which is what we need to control it. That info was curiously missing earlier from your dmesg dump although I hope that's because things just weren't setup as cleanly as they are now. Here's what an example looks like, in my case a USB gigabit adaptor I've got lying around:
[Tue Apr 7 17:25:58 2020] usb 6-3: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd [Tue Apr 7 17:25:58 2020] usb 6-3: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 1.00 [Tue Apr 7 17:25:58 2020] usb 6-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Apr 7 17:25:58 2020] usb 6-3: Product: AX88179 [Tue Apr 7 17:25:58 2020] usb 6-3: Manufacturer: ASIX Elec. Corp. [Tue Apr 7 17:25:58 2020] usb 6-3: SerialNumber: 00000000000040[Tue Apr 7 17:25:58 2020] ax88179_178a 6-3:1.0 eth0: register 'ax88179_178a' at usb-0000:28:00.3-3, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:90:9e:9d:84:44 [Tue Apr 7 17:25:59 2020] ax88179_178a 6-3:1.0 enx00909e9d8444: renamed from eth0
Note especially the bit we really want: "enx00909e9d8444: renamed from eth0". That's the paydirt string we can then feed to another tool to actually configure and bring up the interface. It might seem weird to you but for $REASONS the device may well not be 'visible' to ifconfig straight off the bat. However, as you're on Mint run this after replugging:
* nmcli device statusReport back, surely we can actually get this working at last now. I've specifically marked out the commands that I want to see the results of (why didn't I think of this before?) by putting an * in front of them this time, hopefully that'll make things clearer.
Good job sticking with it so far. -- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq