RX 4XX: Getting AMDGPU to work in Manjaro Linux

RX460 Woes

I finally found a solution to getting my RX460 to work in Manjaro. Since I did something a little different, I am recording it here for myself and anybody else who finds this post.

While this is written using Manjaro, it should work with Arch and other distributions (some files might be in a different location, though). It should also work with any supported card.

I use nano to edit the files below. Use whatever you are most comfortable with, but remember to run it with sudo.

The Process

Make sure Catalyst drivers aren’t installed:

We will need these packages:1)Pacman will fail if you don’t have an up-to-date repository.

Update: See comment by Tids. Click here to reveal the removed steps.

Then, edit /etc/default/grub, changing:


After this, run:

Then edit /etc/modprobe.d/radeon_blacklist.conf (it might create a new file) and add:

Next, inside of /etc/X11/xorg.conf.d/90-mhwd.conf, delete everything in the file and add:2)Confession: I didn’t empty out 90-mhwd.conf.

I then restarted. This let me boot into the latest linux kernel (4.10.0-1-MANJARO) with amdgpu support!

I hope this helps others!

   [ + ]

1. Pacman will fail if you don’t have an up-to-date repository.
2. Confession: I didn’t empty out 90-mhwd.conf.

Adding i3 support to satellite

There’s a really cool Go application written by avinashbot named satellite, which you can use to update your background from an image downloaded from Himawari-8 or DSCOVR. I was super excited to use it but quickly realized that it didn’t support i3, the window manager I use in Linux.

Now, I have never touched a line of Go until now, but it was a breeze to add i3 support.

All I really needed to do was add these lines to background_linux.go:

Then, down in the switch in Set, add:


[remedios]sina ~ $ satellite -desktop i3
2016/08/20 14:40:45 Starting download…
2016/08/20 14:40:52 Done! Download took 6.906361896s.
2016/08/20 14:40:54 Setting image as background…

The full changes can be seen on the (now closed) Pull Request.

Securing Shell Access via SSH

Goal: Mitigate and securing shell access via ssh from:

  • SSH brute force attacks
  • SSH dictionary attacks
  • Buffer overflow attack

This assumes your sshd_config is located at /etc/ssh/sshd_config. In your sshd_config and that you have sudo and nano.

Open sshd_config for editing: sudo nano /etc/ssh/sshd_config

  • Change Port 22 to something unused on your server.
  • Update iptables/ufw/firewall to deny 22 and allow new port.
  • Bind to a single IP address: ListenAddress
  • Ensure Protocol 2 is used.
  • Set PermitRootLogin to no
  • Set DenyUsers root

Optionally, you can set a banner ( Banner /path/to/bannertext). This is useful if you want to show a legal disclaimer regarding login attempts:

Now restart the ssh daemon:

  • Debian-based: sudo systemctl restart sshd.service
  • RedHat-based: sudo service sshd restart
  • Arch-based: sudo systemctl restart sshd.service

Disable SSH Password Login

The best way you can secure from login attempts is to use a key pair login. This portion assumes you do not have an ssh public/private key pair. If you do, skip the generation step. Please note that <port> should be the port you chose above.

  • On a local terminal, issue ssh-keygen -t rsa and follow the prompts. Accept the highest key instead of the default 2048.
  • When that is finished, issue ssh-copy-id -i ~/.ssh/id_rsa.pub user@host to send the server your key1)Thank you, Tiger!P, for commenting about this..

Now we can ssh -p <port> user@host into your server. Upon sucess, you can edit your sshd_config and set PasswordAuthentication no and then restart the ssh daemon.

Since the ssh key pair handles authentication, we do not need to have a password login for ssh. Depending on how you set up your ssh key, you may still be prompted for a password. This is the key pair password, not your ssh user.

Please understand that you must back up your local ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub or you will lose access to your server. If you have multiple computers that connect to your server, I suggest you generate keys for each and add them to your ~/.ssh/authorized_keys2 on the server.

   [ + ]

1. Thank you, Tiger!P, for commenting about this.