Arch linux and dwm

So this is not the first time that I use arch and dwm, but after getting a new video card and cpu I took a break from using it and went back to windows.

Now that I’ve used windows for a while I decided to take a look at arch again. Sadly, like last time I used it, I had a few annoying issues when installing it. But those were mostly faults on my side.

Arch linux is a really customizable linux distribution which allows you to modify it from the ground up to fit your needs. That also means that installing process takes place in the console. No fancy GUIs. But the basic installation is a pretty straight forward process if you follow the guide.

What you get when booting the installation medium

Sounds like a doable thing, right? Well when I did this the first time the only issues I had were with dualbooting. Which ended up toasting my bootmanager. But that can be fixed with a windows installation disk. So booting the installation medium this time just got me a black screen. Fantastic. Later I found out that that is because I have a “fairly” new nvidia card which need the extra kernel parameter nomodeset to even get to the console.

So after all that and making sure that grub played nice with my windows partition I ended up installing xserver and other things I needed. That was when arch asks you which package you want for libgl. Theres a vesa package (I think that’s the opensource one) and three nvidia packages. Great. Now on the wiki it tells you which you need for your video card but reading the wiki is for loosers so I used the next best package. After installing the nouveau driver, which is the opensource driver for nvidia cards everything looked good. Until I rebootet and got a blackscreen instead of dwm. Now that’s not the first time I had that happend, I once had that on ubuntu as well when I installed the video card driver.

So the first thing where I don’ goofed is in the .xinitrc file. That file is executed when you start the xserver (which is responsible for the fancy nancy graphical stuffs). In there you tell it what window manager to start. But before starting my window manager I ran another command which prevented my window manager from starting. Soo yeah, that explained the blackscreen. After fixing that I found my desktop to be in a very low resolution, but at least I saw a desktop.

I spend about an hour trying to fix this problem by intalling the nvidia drivers from the repositories and the offical website switching between blackscreens and a low res desktop and ended up reinstalling arch completely.

This time I directly installed the proprietary drivers and tadaa, everything worked out fine. I still need to configure a few things like auto mountin usb drives and mounting my windows partition. But all in all I’m happy to get a break from windows from time to time and use linux.

My current setup (Open programs are caja and surf)

For dwm I applied the following patches systray and pertag so I have a sytem tray aswell as seperate modes for all virtual desktops.

That’s it. I also installed mpd and ncmpcpp, just because it looks cool 😀

2 thoughts on “Arch linux and dwm

  1. Hey! I appreciate this post very much! Arch linux is notoriously regarded as a difficult install, but I don’t know exactly why. I don’t know if anyone knows exactly why, but if you’re interested in entertaining my guess, I suppose it is because its popularity catches many unsuspecting newish linux users off guard. Just another guess, but maybe the heavily manual installation process simply complicates things just enough that it becomes enough of a distraction, encouraging human error, which is would especially true for me, personally.

    With a different machine and a different set of issues, the arch linux install guide (which you linked) went very smoothly for me, but my unfamiliarity with the issues of my video specific video card and the video related linux kernel boot parameters caused me the same problem that you ran into, seemingly requiring the “nomodeset” parameter just to get my display to show the virtual console, before even starting a graphical environment. This was a problem because I needed to enable kernel modesetting for proper video driver support. It is mostly unrelated to your video problem, but thankfully I ran into an article addressing a problem with my specific dual hybrid GPU configuration, in which the discrete GPU would fail to modeset if the kernel had loaded its module prior prior to loading the integrated GPU. My workaround was blacklisting the module and then loading it in a systemd service upon boot.

    In the long run, I ran into a world of new problems and learning that I had never before experienced because I had been strictly only familiar with running purely headless linux (e.g., no desktop). This resulted in a lengthy discovery process for me, mostly involving learning to manually configure Xorg in order to handle things that normally “just work”, because of issues related to my obsolete and pretty uncommon hybrid video card configuration. It’s also been noted that my specific issue can be resolved by configuring some partition flags, and some kernel and grub options in order to boot in legacy/BIOS mode, then dumping the firmware from my GPU ROM, finally then reconfiguring kernel/grub/disk again in a specific way that future UEFI boots will allow the kernel to load the proper GPU BIOS. This is the result of UEFI’s security though, not a flaw with linux and simply downloading the firmware online was impossible, even after my educated attempts at finding clones and unofficial download hosts. I could have foregone the headache altogether and restricted my use to a single GPU, but I was determined by seeming obsession to make it fully work. I’m sure I’m not the only person to encounter or resolve the problem, but any reports I could find on the matter only addressed individual parts of the greater solution, which I had to peace together, largely through the process of trial and error.

    In summary, it was a combination of my unfamiliarity with linux desktop environments and my antique machinery that I feel led me down a mostly futile rabbit hole that I would never recommend anyone attempt, but there are certainly plenty of niche use-cases that linux cannot always address when presented with security or proprietary hardware roadblocks, although I imagine most people avoid them by making a educated decisions to choose recommended hardware OEMs (e.g. not an old hybrid GPU Macbook Pro, in my own example.) It is worth noting that I ran into the exact same set of problems installing and configuring the stable Ubuntu 16.04 and 14.04 LTS as well. I stuck with archlinux and i3wm (pretty similar to dwm) for the mere reason that I appreciate the continual discovery process I encounter when I avoid using the popular and user-friendly desktop applications. If I’m playing audio on a desktop, it’s strictly ncmpcpp, for me. It handles everything I throw at it: live streams, podcasts, spotify, you name it! For my home use, I have a Makefile to build a few different configs so I can alias it depending on which host speakers I want to use. I should probably do separate pulseaudio configs instead, but it works and it was much easier for me to implement. You do great work! I owe you many beers!

    Liked by 1 person

    1. Heey, thanks for your comment!
      Looks like you ran into a lot more trouble while installing arch than me. I probably would’ve given up if I had faced these kind of issues, but anyways glad to help^^


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s