My 2018 Linux Test

Manjaro did work until it didn't. There is nothing wrong with my comps.
99% of the time I managed to bork my linux installs was when I tried to force install a closed source graphics driver. It typically fails to boot to desktop on next restart if you used a driver that really wasn't working or compatible.
 
OK that did not help me 99% of the time.The point is Ubuntu worked 100% of the time
 
OK that did not help me 99% of the time.The point is Ubuntu worked 100% of the time
That might be because Ubuntu packages in the closed source drivers ready for you if you choose to.
 
I had a machine bork out on me during a simple reboot of Ubuntu. No idea why it happened then. The machine had been running fine for 7 years.
 
I installed X and Gnome but kept having a problem with nothing working inside of the shell. I was about to just wipe and start over when I discovered, for some reason, the locale.gen file didn't save for some reason when I created it earlier. So, I used the USB disc to boot up where I could modify the file, did a chroot, recreated the locale.gen file using nano instead of Vi, saved it, rebooted and viola! Things started working in gnome.
 
I really find Linux drive mounting to be fun. I decided to dual boot Linux on my main machine which is UEFI/GPT. So I had to learn some differences between MBR/BIOS vs UEFI/GPT. The interesting thing is the EFI partition. I had to mount the Windows EFI partition from a separate drive with my Windows install to have Linux kind of share it. I thought that was pretty neat.

Linux drive mounting reminds me a lot of C++ pointers. It feels like you just create a pointer in the Linux file structure to say, 'Hey, the drive you want is over here. Let me take you to it."
 
Haven't had that problem at all with any of the distributions I've tried dual-booting. Windows and Linux share the EFI partition; hell, I have them sharing an exFAT partition for some stuff as well.

That's with Ubuntu, Manjaro, and Fedora- haven't tried OpenSUSE yet.
 
I assumed with the thread being this old, you'd already have gone far past this point.

I've used Rufus for everything for years at this point, including creating windows USBs. With a USB3 stick it takes a matter of a few minutes to completely recreate your install media if for some reason you need to DD instead of create it from ISO.

Also I do agree that Arch is really just making your life difficult for no good reason. It's a much more complex distro to use and maintain, and with it being a rolling release, it's much more common to get updates that break things temporarily.

Personally I think if you're interested in running a more complex distro that won't get in your way when you want to change something, but also works well out of the box, you should be looking at Fedora.

https://getfedora.org/

Installing Drivers on Fedora can be a pain if you do it the old way, but they did recently make it much easier to do.

Not sure how I missed your post GlacierNine but I apologize.

It isn't an issue of getting past the install point. For me, I learn doing things so I've wiped and started over quite a few times. Not to mention the original machine I was using died and I had to resurrect an older machine to play on.

Up to this point I had been using a program very similar to Rufus called Universal USB Installer. Overall it is pretty similar looking, and I hadn't heard of Rufus at the time, and I didn't know it was the problem. However, now that I'm using Rufus, my USB sticks seem to be working fine as install devices for Linux.

Why do you say Arch is more complex to maintain? pacman -Syu seems pretty easy a command to get updates. Is there something I'm missing? I actually like not having release version numbers like 18.0X.
 
Haven't had that problem at all with any of the distributions I've tried dual-booting. Windows and Linux share the EFI partition; hell, I have them sharing an exFAT partition for some stuff as well.

That's with Ubuntu, Manjaro, and Fedora- haven't tried OpenSUSE yet.

Which problem are you referring to? I didn't say I was having a problem dual booting.

I'm guessing most distributions cover marking the EFI partition Windows uses automatically. But it's nice to know what steps the install is taking.
 
Not sure how I missed your post GlacierNine but I apologize.

It isn't an issue of getting past the install point. For me, I learn doing things so I've wiped and started over quite a few times. Not to mention the original machine I was using died and I had to resurrect an older machine to play on.

Up to this point I had been using a program very similar to Rufus called Universal USB Installer. Overall it is pretty similar looking, and I hadn't heard of Rufus at the time, and I didn't know it was the problem. However, now that I'm using Rufus, my USB sticks seem to be working fine as install devices for Linux.

Why do you say Arch is more complex to maintain? pacman -Syu seems pretty easy a command to get updates. Is there something I'm missing? I actually like not having release version numbers like 18.0X.
Arch is a pain to maintain simply because there's not really any idea of a "known good" configuration shared by most users. Everything in Arch is customisable and they expect users to have customised it, potentially heavily.

As a result, if they push a broken package, it's a lot less simple to fix on Arch than it is on Ubuntu, because you're likely to be the only person with that issue and the only person who needs to fix it.

That'd be fine if Arch's userbase wasn't so packed with gatekeeping, but unfortunately a lot of the time if you need help with something, the attitude you'll see from other Arch users is essentially "Fuck you, go read the wiki, and if you don't understand it you're not the kind of person we want using arch anyway".


It's really that if you want to learn, they make it very difficult, and then it also becomes somehow your fault that you don't know things they're mostly refusing to help you understand.
 
Arch is a pain to maintain simply because there's not really any idea of a "known good" configuration shared by most users. Everything in Arch is customisable and they expect users to have customised it, potentially heavily.

As a result, if they push a broken package, it's a lot less simple to fix on Arch than it is on Ubuntu, because you're likely to be the only person with that issue and the only person who needs to fix it.

That'd be fine if Arch's userbase wasn't so packed with gatekeeping, but unfortunately a lot of the time if you need help with something, the attitude you'll see from other Arch users is essentially "Fuck you, go read the wiki, and if you don't understand it you're not the kind of person we want using arch anyway".


It's really that if you want to learn, they make it very difficult, and then it also becomes somehow your fault that you don't know things they're mostly refusing to help you understand.

Wow, that sounds horrible. Sounds like a very toxic community. :(

While I like the idea of a rolling release distribution like Arch, I can definitely see the downside with an update borking your system, waiting for a fix, and then having the fix need customization on your end.

Well, I'm not dead set on any distribution to be honest. The things I like about Arch is it is helping me learn, but I'm also running into a lot of issues I can't really figure out because I don't know enough to ask the correct questions.

What are the benefits of Fedora over say Debian? I've been considering trying out Debian because a local friend of mine uses it along side Arch.
 
As a result, if they push a broken package, it's a lot less simple to fix on Arch than it is on Ubuntu, because you're likely to be the only person with that issue and the only person who needs to fix it.

Not entirely correct. With Arch any package you install, a copy of it is kept in the cache (/var/cache/pacman/pkg). That means if you update a file and it borks the system (I've used Arch heavily for years and never had it bork on me) you can simply re-install the old package from that directory and be up and running again.

That'd be fine if Arch's userbase wasn't so packed with gatekeeping, but unfortunately a lot of the time if you need help with something, the attitude you'll see from other Arch users is essentially "Fuck you, go read the wiki, and if you don't understand it you're not the kind of person we want using arch anyway".

It's really that if you want to learn, they make it very difficult, and then it also becomes somehow your fault that you don't know things they're mostly refusing to help you understand.

That statement is only half correct. There's always a toxic part of any community. The Arch community is incredibly helpful but they do expect people to attempt to solve their problems first alone. It's how you learn and Arch is a wonderful learning experience.

Part of the toxicity people complain about is because Arch users have a very low tolerance for users coming from a distro like Mint and wanting to use Arch simply to brag about using Arch. These are people that never really bothered to learn anything about Linux and just used it as a talking point or want to "stick it to the man". These are people that come in and want to be hand fed everything and feelings of entitlement. Sorry but that type of attitude doesn't fly. If those same users come into the Arch community and post a legit problem and what they've done to try to fix it then they get great help. However, if they come in and say "I just installed Arch for the first time and I have no audio" with no other information they get pointed directly to the wiki and then those users piss and moan about not being helped.

I miss Arch itself and I'm looking at moving back again. There are just certain things that Manjaro for whatever reason just doesn't do as well. Decryption of drives during boot up for example. Even though Manjaro uses LUKS, which is what I use when I built a pure Arch system, Manjaro is much slower than Arch is on boot up after entering the password and it drives me mad. Manjaro is faster than Ubuntu or some other distro like that but it's still not as fast as Arch with daily usage. I know that's kind of subjective but after using Arch for so many years and after using it on the same laptop for so long it's pretty easy for me to tell which is faster on my hardware.
 
Wow, that sounds horrible. Sounds like a very toxic community. :(

While I like the idea of a rolling release distribution like Arch, I can definitely see the downside with an update borking your system, waiting for a fix, and then having the fix need customization on your end.

Well, I'm not dead set on any distribution to be honest. The things I like about Arch is it is helping me learn, but I'm also running into a lot of issues I can't really figure out because I don't know enough to ask the correct questions.

What are the benefits of Fedora over say Debian? I've been considering trying out Debian because a local friend of mine uses it along side Arch.

Go Gentoo! You can customize as much as you like (or not) and either use the package manager or not, or even half-way (fetch the package, but compile it manually, and then use the manager to install. Out of tree compilations can be injected so dependencies are still met. The forums are pretty helpful too.
 
Wow, that sounds horrible. Sounds like a very toxic community. :(

There were a lot of Linux users who used it primarily as a status thing. Linux wasn't as easy to install and configure so it put them in their own made up elite club of people who could actually use Linux. Over time, things changed and Linux became a lot more accessible. There were GUI's for installing the OS, you didn't have to manually partition to install, you didn't have to understand file systems and swap, and everything you needed would come working out of the box. Hell it wasn't too long ago that using Linux on a laptop was a huge nightmare because 99% of the time, it wouldn't come with wireless or ethernet drivers. Now installing Ubuntu is easier and objectively better than Windows. You can still configure everything like you used to, or you could click 5 things that are all in very plain english and it will install a full GUI desktop, all your drivers will work, and every piece of software you could ever want is installed and ready to use.

The gap was closed between regular computer users and the "elite few" in that special made up club I was talking about earlier. People had issues with Linux being more accessible so they moved to one of the least accessible versions - Arch. Installing Arch isn't hard, it just takes a little effort and maybe a little research. This was enough for some users to fill their gatekeeping jollies. This lasted a couple years until Manjaro came out and became popular. It was Arch, but any person who had even a little bit of computer savyness could install and use it. The gap closed just a little more between regular users and the "elite few". Now the community has turned on itself for Arch. You try and get any kind of help, even something moderately hard to fix, and you get ridiculed for even asking. You even bring up that you use Manjaro and you can practically feel the rage of some Arch users coming through your monitor.
 
A week or so ago I decided to work on dual booting Linux and Windows on my main machine. I learned a lot about UEFI, GPT, and lot of other alphabet soup items but for the life of me, I could not get a GUI to run on Arch. Over the past few days I've done a ton of research and nothing seemed to work.

I tried messing with Display Server settings, different desktop environments (Gnome, KDE, XFCE), different desktop managers, display managers, goodness man, things got deep. Come to find out NOTHING seems to play nice with nVidia proprietary drivers. So, I removed them and voila! XFCE is up and running.

I don't know who's at fault with the hot mess that nVidia is on Linux, but whether it is nVidia, Arch, Wayland, X, whoever, this is the kind of stuff that will drive you mad.

Anyway, at least I was able to figure out the problem.
 
Things I've learned this week.

One thing I've learned is that if you've hosed your Linux OS, you don't have to wipe and start over (which is what I typically would do). With the base Arch install, if you make a mistake, you can always boot from your thumb drive, chroot into your install, and undo whatever it is you just did.

As an example, after booting into the setup USB stick, I would mount the device my Arch Linux is installed to with:

mount /dev/sda1 /mnt

Then, chroot to that install:

arch-chroot /mnt

Once here, if I set something to run at bootup using Systemctl, such as enabling GDM (Gnome Display Manager) to startup with the command

systemctl enable gdm.service

And on reboot the system hangs, all I have to do is boot with the flash drive, mount my install, chroot to /mnt, then type

systemctl disable gdm.servce

Exit the chroot with exit then reboot and voila, my install of arch is back to running and the offending application causing the boot to hang has been disabled.
 
I'm kind of at a loss as to what I should do with Arch on my main machine. From what I'm reading, nVidia drivers have been an issue for a couple of years now, particularly with Wayland. However, even trying to run a GUI based solely on X, X doesn't seem to get along well with the nVidia drivers either.

My main machine is setup with (2) video cards in SLI. I get the impression there is supposed to be a way to designate within X conf files which card to set as primary so there's no confusion.

Anyone have any experience running Linux with an SLI setup? If so, I'd appreciate your input.

Thanks
 
Things I've learned this week.

One thing I've learned is that if you've hosed your Linux OS, you don't have to wipe and start over (which is what I typically would do). With the base Arch install, if you make a mistake, you can always boot from your thumb drive, chroot into your install, and undo whatever it is you just did.

As an example, after booting into the setup USB stick, I would mount the device my Arch Linux is installed to with:

mount /dev/sda1 /mnt

Then, chroot to that install:

arch-chroot /mnt

Once here, if I set something to run at bootup using Systemctl, such as enabling GDM (Gnome Display Manager) to startup with the command

systemctl enable gdm.service

And on reboot the system hangs, all I have to do is boot with the flash drive, mount my install, chroot to /mnt, then type

systemctl disable gdm.servce

Exit the chroot with exit then reboot and voila, my install of arch is back to running and the offending application causing the boot to hang has been disabled.

For reference, this is usually true with any OS, depending on how you borked it.
 
For reference, this is usually true with any OS, depending on how you borked it.

Absolutely true! Learning how to undo what you've done though seems a lot easier on Linux. Well, unless you did some due diligence and saved a restore point on windows, and if it works when you use it.
 
I'm kind of at a loss as to what I should do with Arch on my main machine. From what I'm reading, nVidia drivers have been an issue for a couple of years now, particularly with Wayland. However, even trying to run a GUI based solely on X, X doesn't seem to get along well with the nVidia drivers either.

My main machine is setup with (2) video cards in SLI. I get the impression there is supposed to be a way to designate within X conf files which card to set as primary so there's no confusion.

Anyone have any experience running Linux with an SLI setup? If so, I'd appreciate your input.

Thanks

I'm in the middle of putting my youngest to bed but I know how to make it work with one gpu. It's the same method I have to use on my 5510 laptop due to Optimus.

Search the arch wiki for Nvidia Optimus. The instructions for using xrandr and setting a GPU are there. Hard to say more right this second with a naked kid in my other arm.

Just be careful as it can render your system non-bootable if you do the wrong thing with xrandr. Fucked myself earlier while reloading to Arch after my SSD died this morning. Actually just had to chroot back in and disable lightdm to fix it.
 
Absolutely true! Learning how to undo what you've done though seems a lot easier on Linux. Well, unless you did some due diligence and saved a restore point on windows, and if it works when you use it.

Yeah it really depends on what happened. There are many things that are typically easier to fix in Linux then they are in Windows, but then also Windows has included some really easy to use tools to backup and restore that are simple to turn on.

The major benefit of Linux in this is the way everything is configured using flat files. A lot of times it is just a matter of using a rescue disk, mounting the system and fixing the configuration file. But you can screw up in Linux just as badly as people screw up in Windows. Knowing how to properly update the kernel/programs is key. For instance on RHEL based systems you can easily screw yourself over by doing an "update" to the kernel rather than an "install". You can reverse an update to the kernel. What you can do is reload a previous kernel (which is normally saved when you use an "install" feature).
 
OK kid in bed...

https://wiki.archlinux.org/index.php/NVIDIA_Optimus#Disabling_switchable_graphics

You can use that and force the system to use a single specific GPU.

If you want to make use of SLI: https://wiki.archlinux.org/index.php/NVIDIA/Tips_and_tricks#Enabling_SLI

My problem was i put the command in xinitrc and lightdm. I was in a rush and forgot to take it out of xinitrc before enabling lightdm. But right now XFCE running great with Nvidia drivers. Just need to re-enable lightdm again now that I corrected the xinitrc.

Screenshot_2019-03-07_19-08-14.png
 
Anyone have any experience running Linux with an SLI setup? If so, I'd appreciate your input.

Some side input: I'd tried to get Manjaro to run on my desktop, which doesn't have SLI, but is running the main display from an Nvidia GPU and three secondary displays from an AMD GPU.

Manjaro saw the AMD GPU, which output a black/blank signal to all three side monitors, and had no problem running the primary monitor off of the Nvidia GPU- but I couldn't get it to extend the desktop to the monitors attached to the Nvidia GPU. Booted a Ubuntu live image... hey look, there's my monitors!

As far as Nvidia drivers or AMD drivers- I don't see either as a problem. Both Manjaro and Ubuntu loaded up the open-source AMD drivers and 'non-free' Nvidia drivers together without issue.
 
OK kid in bed...

https://wiki.archlinux.org/index.php/NVIDIA_Optimus#Disabling_switchable_graphics

You can use that and force the system to use a single specific GPU.

If you want to make use of SLI: https://wiki.archlinux.org/index.php/NVIDIA/Tips_and_tricks#Enabling_SLI

My problem was i put the command in xinitrc and lightdm. I was in a rush and forgot to take it out of xinitrc before enabling lightdm. But right now XFCE running great with Nvidia drivers. Just need to re-enable lightdm again now that I corrected the xinitrc.

View attachment 146599

I will definitely need this article when installing Linux on my laptop as it has an Intel and nVidia graphics card. I'm not really seeing how this will help with getting my desktop up and running with the proprietary drivers..

Because I use the machine for Windows Gaming, I don't want to have to manually disable one of the cards every time I want to boot into Linux. Not to mention I don't even know if there is an option to disable a given card in the BIOS considering it isn't really an Optimus situation.
 
Some side input: I'd tried to get Manjaro to run on my desktop, which doesn't have SLI, but is running the main display from an Nvidia GPU and three secondary displays from an AMD GPU.

Manjaro saw the AMD GPU, which output a black/blank signal to all three side monitors, and had no problem running the primary monitor off of the Nvidia GPU- but I couldn't get it to extend the desktop to the monitors attached to the Nvidia GPU. Booted a Ubuntu live image... hey look, there's my monitors!

As far as Nvidia drivers or AMD drivers- I don't see either as a problem. Both Manjaro and Ubuntu loaded up the open-source AMD drivers and 'non-free' Nvidia drivers together without issue.

That's the thing, with the open source nouveau drivers it works, but you can tell it isn't proprietary level performance.
 
I will definitely need this article when installing Linux on my laptop as it has an Intel and nVidia graphics card. I'm not really seeing how this will help with getting my desktop up and running with the proprietary drivers..

Because I use the machine for Windows Gaming, I don't want to have to manually disable one of the cards every time I want to boot into Linux. Not to mention I don't even know if there is an option to disable a given card in the BIOS considering it isn't really an Optimus situation.

It doesn't disable a card. It just forces the system to use the one you choose. For example right now I have forced mine to use the Nvidia card which is running the Nvidia proprietary drivers instead of the Intel chip but the Intel chip is technically still active.
 
It doesn't disable a card. It just forces the system to use the one you choose. For example right now I have forced mine to use the Nvidia card which is running the Nvidia proprietary drivers instead of the Intel chip but the Intel chip is technically still active.

I know the driver doesn't disable the card. I was referring to disabling one of the cards in BIOS so the system only detects one card on boot to Linux. I was just stating I don't think that's an option in the BIOS.

I understand what the optimus thing is supposed to do. I even found something that may work better than Optimus or Bumblebee. I read someone mention nvidia-xrun solving some of the problems with laptop dual video card issues.
 
So, I reinstalled the proprietary nVidia driver and once again XFCE would not load. It just kind of gets stuck and doesn't do anything.

So, I then ran the nvidia-xconfig file, and it hangs at a different point, but still hangs and won't load Xfce.

Still working the problem.
 
So, I'm getting some kind of strange SystemD message in my Xorg.0.log file.

My brain is off so I'll post more details soon.
 
So, I'm getting some kind of strange SystemD message in my Xorg.0.log file.

My brain is off so I'll post more details soon.

Ever get it all figured out?

Much to my chagrin my Precision 5510 is dying. It wasn't a bad SSD. New installs of any distro were dog shit slow even with just the Intel video driver. Even now all my data is being yanked off it and moved to this Latitude E7270.

Screenshot_2019-03-09_16-37-26.png
 
Ever get it all figured out?

Much to my chagrin my Precision 5510 is dying. It wasn't a bad SSD. New installs of any distro were dog shit slow even with just the Intel video driver. Even now all my data is being yanked off it and moved to this Latitude E7270.

View attachment 147022

Thanks for checking.

Honestly I've written a response at least 5 times and as I was writing it decided I had one more thing left to try.

And one more thing...

And one more thing...

But, now I'm at the point where I've wiped the install just to try from a fresh beginning because things just seemed messed up beyond recovery.

So, the gist of it is nothing graphical will work with the nVidia driver installed. Here's the process I've gone through that always gets me to that point.

Ok, so I really have no idea how to fix this nVidia driver issue. I'm currently writing this post from Xfce on Arch running the nouveau driver. Installation of the nVidia proprietary driver requires a reboot after installation.
However, every time I install the nVidia proprietary driver, once I've completed the reboot, X will just hang and nothing will load. Doesn't matter whether I'm logged in as root or another user.
So here are the steps I'm taking to install the driver:

1. pacman -S nvidia *this installs the video driver* then reboot
2. after login, I confirm the nvidia driver is installed with lspci -k | grep -A 2 -E "(VGA|3D)" which returns Kernal Driver in use: nvidia
3. next I use nvidia-xconfig to generate the xorg.conf file. I then check the generated file and update the horizontal and vertical refresh rates based on my monitor's manufacturer defined settings which are 73 - 88 H/30 - 100 V
4. next I attempt to start Xfce using startxfce4. This is when the machine freezes. I am able to change terminals using CTRL+ALT FKey and the machine still responds, but TTY1 is completely inoperable at this point.

Looking at the Xorg log file I see an entry regarding systemd-logind that I've done research on and it seems like I'm not the only person having this problem but I can't find a solution.
 
So Arch is back up and running, setup dhcpcd and did a system update with pacman -Syu.

Now I'm reading the GUI setup instructions on the Arch Wiki.

The first thing it says is to install the xorg-server package. Then to install the xorg-apps group. Then finally it says install the xorg group.

Next, it says to install the video drivers. So for my 1080s it says to pacman -S nvidia. This downloads and installs the nvidia proprietary driver. After install a reboot is required. Something about nvidia blacklisting the nouveau driver. Whatever that means. lol

After reboot I can tell the nvidia driver activated because the text onscreen looks completely different.

Next I run the nvidia-xconfig and it generates the xorg.conf file in /etc/X11.

Looking at the xorg.conf file I don't have any confidence the issue has been resolved. It doesn't look like my monitor or video card is really represented by the xorg.conf file the nvidia-config tool generated.

Under the monitor section it shows
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Unknown"
HorizSyng 28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"

Uner the device section it shows
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
 
Yep, same thing. Installed Xfce and sure enough, it hangs on startup. Xorg log once again has some weird systemd-logind: got pause for 13:xx where xx just seems like some random 2 digit numbers.

*sigh*
 
So Arch is back up and running, setup dhcpcd and did a system update with pacman -Syu.

Now I'm reading the GUI setup instructions on the Arch Wiki.

The first thing it says is to install the xorg-server package. Then to install the xorg-apps group. Then finally it says install the xorg group.

Next, it says to install the video drivers. So for my 1080s it says to pacman -S nvidia. This downloads and installs the nvidia proprietary driver. After install a reboot is required. Something about nvidia blacklisting the nouveau driver. Whatever that means. lol

After reboot I can tell the nvidia driver activated because the text onscreen looks completely different.

Next I run the nvidia-xconfig and it generates the xorg.conf file in /etc/X11.

Looking at the xorg.conf file I don't have any confidence the issue has been resolved. It doesn't look like my monitor or video card is really represented by the xorg.conf file the nvidia-config tool generated.

Under the monitor section it shows
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Unknown"
HorizSyng 28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"

Uner the device section it shows
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"

https://wiki.archlinux.org/index.php/Kernel_module#Blacklisting

Blacklisting is something you want to do if there are 2 kernel drivers that can access the same bit of hardware.

The open source Nvidia driver... in general needs to be blacklisted to avoid issues. The nvidia install script does this... and I assume the arch script does as well. But I would double check.
/etc/modprobe.d/
or
/usr/lib/modprobe.d/
In those spaces you should see a .conf file that is blacklisting the open source driver... if not you'll need to create one. The arch package really should have done this already... but it never hurts to double check.

Also check
/etc/X11/xorg.conf.d/ As this location will be preferred. (I'm sure you would have noticed... but doesn't hurt to mention it)
 
Also assume when you install the Nvidia driver you are using..

sudo pacman -S nvidia nvidia-utils and not just installing the nvidia package.

I would also install the packages
nvidia-settings
and
xorg-server-devel

You can double check that the open source driver is blacklisted with
cat /usr/lib/modprobe.d/nvidia.conf
Which should return
blacklist nouveau

If not create that conf file with that bit of text it it.
 
Also assume when you install the Nvidia driver you are using..

sudo pacman -S nvidia nvidia-utils and not just installing the nvidia package.

I would also install the packages
nvidia-settings
and
xorg-server-devel

You can double check that the open source driver is blacklisted with
cat /usr/lib/modprobe.d/nvidia.conf
Which should return
blacklist nouveau

If not create that conf file with that bit of text it it.

I verified nvidia, nvidia-utils, nvidia-settings, xorg-server-devel were all installed

I verified that nouveau is indeed blacklisted.

I reran nvidia-xconfig after all of this and the xorg.conf file still looks the same.

I attempted to start Xfce and same thing.
 
I don't see any errors in the Xorg log. I'm removing the nvidia drivers now so I can get into Xfce and I'll paste the log here for you to see.
 
https://wiki.archlinux.org/index.php/Kernel_module#Blacklisting

Blacklisting is something you want to do if there are 2 kernel drivers that can access the same bit of hardware.

The open source Nvidia driver... in general needs to be blacklisted to avoid issues. The nvidia install script does this... and I assume the arch script does as well. But I would double check.
/etc/modprobe.d/
or
/usr/lib/modprobe.d/
In those spaces you should see a .conf file that is blacklisting the open source driver... if not you'll need to create one. The arch package really should have done this already... but it never hurts to double check.

Also check
/etc/X11/xorg.conf.d/ As this location will be preferred. (I'm sure you would have noticed... but doesn't hurt to mention it)

I've checked xorg.conf.d and I don't nor have I ever seen any files in there.
 
Back
Top