I’m a bit curious - why on Earth would you blacklist r8169 in /usr/lib/modprobe.d/ ?
Why blacklist that Ethernet module at all during the install and continue to have it blacklisted after the fact?
r8168 is installed and will be used this needs to blacklist r8169 as i can see…
the package is doing this:
If you are sure you need r8169 you can simple uninstall r8168 what will remove the blacklisting.
While this may be true, r8168 is not recognizing my card. So installs are being done via wifi. If I simply remove the blacklist, my nic works perfectly.
There seems to be an issue where the wrong drivers will be loaded and then not working for sure…
And if we do not install r8168 driver package other cards will not working… with it installed you can still uninstall r8168 to make r8169 working … a typical realtek issue…
Not the best solution… but we do use packages from Archlinux itself so we can not change this easely…
1 Like
Appreciate the explanation, and thank you.
I’m going to do just that to see what happens. It does seem odd tho 
This was exactly correct. Thanks again for the reply!!
realtek is causing issues like this very often usually it should not be an issue between different drivers for different cards…
But good that you post this! As you are the first one here with the need for r8169 i was not thinking that this would be an issue, was thinking r8169 cards will be working all also with r8168
1 Like
I had issues with my NIC and until that blacklist was in place the card would not work.
You can juggle around and see which driver works. In my experience the r8169 is rightfully blacklisted. Even if the card was supposed to be supported by both r8168 and r8169 drivers, only r8168 worked.
1 Like
I also have r8169 installed and it works well. Never even tried r8168.
So this seems to be a problem that would need someone to dig deep why some cards need r8168 and some need r8169. And hopefully come up with some simple programmable test (a bash script?) which one to choose at install phase.
1 Like
When it’s up to network problems I highly recommend a script called collectNWdata provided on Framps homepage. It creates a detailed report of your network environment suited for posting in forums to speed up help. Sensitive data is masked and so unreadable for others. It is even useful if you don’t want to post it. You can just create a report for yourself to see all necessary information with just one look. It works with wired and wireless connections. He has been improving this script for years now.
A lot of time network problems are posted in foren in order to find people to help to solve them. A lot of problems are configuration problems which can be fixed easily by the problem poster. This script collects a lot of network information and passes them to the NWEliza component, which analyzes them for common configuration errors. Errormessages point to webpages on this website which help to fix the problems.
Allow me to preface my opinion by stating that I have nothing against helper programs nor do I have anything against the folks that create them. It’s a nice suggestion however…
The vast percentage of that data in the example that is presented should be, in general, already known by and obtainable by the Linux user without the need of helper scripts/apps. That being said, helper scripts/apps are nice for the folks that are new to Linux but in the end, will hamper them from actually knowing what to do when troubleshooting their own systems.
Helper scripts/apps should be obtainable from validated (if not supported) channels. Such as a repo that is endorsed by the distros themselves. Newer Linux folks should not just blindly download/install scripts/apps without at least having some basic knowledge of how they work and what is actually in them.
Again, nothing against the script/app mentioned, just my common sense approach to the unknown.
@Chris
With respect. Don’t misunderstand my words. In theory you are right. I’m a moderator in another forum. Everyday experience taught me something different.
Just a shot in the blue : You’re a user who uses Arch derivates or Arch itself for quite some time?
That sounds like an option. As I was doing this install for a fiend of mine, she had a wireless nic so I was able to work past this. At least for me and moving forward, I know what to look for if this happens again so that during the install (assumed since I have not tried it) I should be able to open a terminal before running the install and simply either remove or rename the conf file. But as I’m talking this through, this might not work, well - maybe it would since I could just probably modprobe it at that point.
But since there has only been one person (me) it may not be such a wide spread issue and may not be worth the extra overhead. Perhaps a small blurb mentioned some place before the install.
Not really - a little over a year ago I moved from Debian to Arch* due to the need to have newer applications at the time. While I miss the stability that Debian offers, I could not continue to use applications that where many times a year or two outdated. Truth be told, while I do love Arch* there have been many times I found myself cursing at my system 
I do understand your point, and of course, no disrespect intended and if it came across that way, I do apologize as that was/is not my intention.
No need to worry about that.
What I learned since I’m using Linux are two things :
- I know that I know nothing
- The more I learn, the more I have to realize that I know nothing
And I remember the times when I started using other OSs than Windows I was really thankful for every straw I could grab. Why do people always think, that people who are using Linux always know how to fight back? Even when it’s up to the lowest (at least in a subjective perspective) level?
Again : No offending. Just a question.
Your 2 points are outstanding guides to govern ones life.
As to your question, new folks have this forum for one. There are other resources that should be considered also. Consider this: Endevour being Arch-based, the very first thing new folks should be getting intimate with is the Arch Wiki. Yes I know, there is tons of stuff in there but the Arch Wiki pretty much is the end all for all Arch* systems (if not for most all Linux systems). While I don’t expressly condone the use of the AUR, that is also an option for other apps too with the caveat that eh new user should know what they are getting into. But you already know the items I mentioned.
If I’m not mistaken, the forums are here to guide new and seasoned users with combined knowledge. But that also means that there should be ample guidance to the new folks as to why they might at least rethink using apps/scripts that don’t necessarily meet guidelines of the developers. Care should be used when guiding new folks as to not inadvertently introduce issues on top of what the new folks are dealing with. That last point will certainly drive new folks back to whatever non-Linux OS they were using previously.
Maybe the misunderstanding is just because I posted this one in this thread. That is my mistake. I maybe should have posted it in a common subforum, so everyone could have seen it. Guilty as charged.
It was supposed to be an advice in general.
And it still is valid. While your view point and mine are from opposite ends, both are equally valid. And this type of discussion points out everything a new user should see! Your advise (and mine) accomplished both, it gives the user something to think about and THAT is the most important thing when it comes to Linux
1 Like
In the end we’re all sitting at the same table. I see your point, which is to motivate users to put some (more?) effort in finding solutions and then ask for help if they don’t succeed. And my motto is : Teach them how to fish and they will never starve.
Both positions are valid as you pointed out. As long as there are people like you and me there will always be a straw to grab for.
@manuel the r8168 driver blacklists r8169 automatically, this is default behavior and is an issue caused by upstream (is the same in all Arch based distros), not Endeavour specific. I had the same in Antergos and Manjaro. I guess the rationale behind this is if you install the driver you know you don’t want the other driver to interfere.
Are you thinking of overriding this behavior in EOS?