Help I have no option to select a wired internet connection

[claydoh]

You have to install the driver again.


Sent from my LM-V600 using Tapatalk

[Victel]

You have to install the driver again.

Sent from my LM-V600 using Tapatalk

That's what I was trying to do and it gave me that message.

[claydoh]

You just need to run the autorun file as you did before, that's the only steo you need to do.

Sent from my LM-V600 using Tapatalk

[Victel]

You just need to run the autorun file as you did before, that's the only steo you need to do.

Sent from my LM-V600 using Tapatalk

When I try running:
sudo ./autorun.sh

Check old driver and unload it.
rmmod r8168
Build the module and install
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76
sign-file: certs/signing_key.pem: No such file or directory
Warning: modules_install: missing 'System.map' file. Skipping depmod.
DEPMOD 5.8.0-29-generic
load module r8168
Updating initramfs. Please wait.
update-initramfs: Generating /boot/initrd.img-5.8.0-29-generic
Completed.

When I type in sudo apt install build-essential I get:


Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version (12.8ubuntu3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Still no internet

[claydoh]

did you reboot?

The messaging may not be fatal, as the rest of the process finished without any, particularly the important parts at the end.


You don't need to install build-essential any longer, that was only needed to get you the utilities to compile the code, so you already have them.


If after rebooting it still does not work, delete the entire folder with the autorun file, then extract it again from the tar.bz2 file, and run the autorun again, maybe it needs to be compiled fresh each time.

[Victel]

did you reboot?

The messaging may not be fatal, as the rest of the process finished without any, particularly the important parts at the end.

You don't need to install build-essential any longer, that was only needed to get you the utilities to compile the code, so you already have them.

If after rebooting it still does not work, delete the entire folder with the autorun file, then extract it again from the tar.bz2 file, and run the autorun again, maybe it needs to be compiled fresh each time.

I tried deleting the file and re-extracting and running the command. This is what I got:

Check old driver and unload it.
Build the module and install
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76
sign-file: certs/signing_key.pem: No such file or directory
Warning: modules_install: missing 'System.map' file. Skipping depmod.
DEPMOD 5.8.0-29-generic
load module r8168
Updating initramfs. Please wait.
update-initramfs: Generating /boot/initrd.img-5.8.0-29-generic
Completed.

[claydoh]

I have no idea, tbh.
You can for the time being select the previous kernel from your grub menu during boot,

[Victel]

I re-installed it and it's now working, What steps do I need to take so it doesn't break again? Thanks

[oshunluvr]

I re-installed it and it's now working, What steps do I need to take so it doesn't break again? Thanks

Basically, if you update the kernel you have to rebuild the module. This was what we had to do to use the nVidia drivers in the old days until a dkms version was made available by Ubuntu.

IMO, you don't actually need to update to every dot release of the kernel unless there's a reason. You might want to read through the release notes of each kernel to see what changed and decide if you need to upgrade or not. You can just not install kernel updates until (if ever) the module is built into the kernel. If the changes in the kernel are important to you (like a security fix) then just do it knowing you'll have to rebuild the module.

You probably could trigger the module build automatically if you wanted to get fancy, but doing it manually doesn't seem too difficult as long as you are prepared and ready to do it.

[Victel]

Basically, if you update the kernel you have to rebuild the module. This was what we had to do to use the nVidia drivers in the old days until a dkms version was made available by Ubuntu.

IMO, you don't actually need to update to every dot release of the kernel unless there's a reason. You might want to read through the release notes of each kernel to see what changed and decide if you need to upgrade or not. You can just not install kernel updates until (if ever) the module is built into the kernel. If the changes in the kernel are important to you (like a security fix) then just do it knowing you'll have to rebuild the module.

You probably could trigger the module build automatically if you wanted to get fancy, but doing it manually doesn't seem too difficult as long as you are prepared and ready to do it.

Before updating and choosing to accept an update what should I look for as it concerns to this issue? Are there specific keywords I need to look at?

[oshunluvr]

I'd just go to the kernel change logs that Ubuntu publishes and read through them.

The problem with new or obscure or just unsupported hardware is you end up does these sorts of "dances" until support arrives.

IMO, you might just want to "hold" your kernel then stop worrying about it. Then you can run "updates" without your kernel being touched.

I'm sure someone will come along to spread FUD and tell you how dangerous this would be, but I doubt your attack vector would be large enough to cause any real concern. "Emergency" kernel patched that contain a critical security based patch are ALWAYS heavily published and are usually posted about on here. Simply reading up periodically on kernel releases would provide the info you might need without leaving you without the internet every week when Ubuntu releases a dot update to the kernel.

To hold (not update automatically) your kernel (any package really) version you need to "mark" it. You will still be able to run manually updates, it just won't be included in the update list. This single console command should do it in one step:

sudo apt-mark hold `uname -r`

Here's a couple posts so you can read about it:
https://askubuntu.com/questions/7423...present-in-the
https://askubuntu.com/questions/9384...d-notification

[jglen490]

Listen to oshunlvr!

If your kernel works on install, and everything else works, the only kernel updates that should be pushed (normally) will be patches (i.e., 5.4.0-53 -> 5.4.0-54). Those patches are usually security related, but on occasion may alter kernel modules. If you are going outside the box and bringing in another kernel level (i.e., 5.4 -> 5.9) against no other changes in your set of software, you're introducing another level of challenge, and risk to the stability of your platform. It won't break everything, but it may break some important things, and it will be one of those rules that says that the hardest thing to fix will break.

It's your choice, but just because you can, doesn't mean you should.

[Victel]

Listen to oshunlvr!

If your kernel works on install, and everything else works, the only kernel updates that should be pushed (normally) will be patches (i.e., 5.4.0-53 -> 5.4.0-54). Those patches are usually security related, but on occasion may alter kernel modules. If you are going outside the box and bringing in another kernel level (i.e., 5.4 -> 5.9) against no other changes in your set of software, you're introducing another level of challenge, and risk to the stability of your platform. It won't break everything, but it may break some important things, and it will be one of those rules that says that the hardest thing to fix will break.

It's your choice, but just because you can, doesn't mean you should.

I'll likely be referencing information here and coming back to this as updates are released for the good information mentioned here. It has all been useful.

I'd just go to the kernel change logs that Ubuntu publishes and read through them.

The problem with new or obscure or just unsupported hardware is you end up does these sorts of "dances" until support arrives.

IMO, you might just want to "hold" your kernel then stop worrying about it. Then you can run "updates" without your kernel being touched.

I'm sure someone will come along to spread FUD and tell you how dangerous this would be, but I doubt your attack vector would be large enough to cause any real concern. "Emergency" kernel patched that contain a critical security based patch are ALWAYS heavily published and are usually posted about on here. Simply reading up periodically on kernel releases would provide the info you might need without leaving you without the internet every week when Ubuntu releases a dot update to the kernel.

To hold (not update automatically) your kernel (any package really) version you need to "mark" it. You will still be able to run manually updates, it just won't be included in the update list. This single console command should do it in one step:

sudo apt-mark hold `uname -r`

Here's a couple posts so you can read about it:
https://askubuntu.com/questions/7423...present-in-the
https://askubuntu.com/questions/9384...d-notification

I suppose that's one of the sacrifices of using linux on new hardware. People I know think I'm crazy for switching to Linux after just putting together a new system because they view it as wasting the relevant life of my new hardware on a system where games and the software I use aren't well supported. Those threads seem very informative. I hope they update my hard officially so I don't have to do this for long especially with the security risks. Alternatively I wouldn't mind finding out how to re-install the driver after a kernel update so I don't need to reformat everytime without running into the problem I did earlier in this thread.

[jglen490]

Never be concerned with what others think about your system and your use of it

As long as you are aware of the risk of going outside the reservation, you're good, and you will always get help here and elsewhere. Chances are someone has a solution on github, even if it may be a bit dicey! But that's the beauty of open source.