5700xt on popos

So just to supplement the bit about man a little:

apropos, whatis, and man are of course the holy trinity of learning as you go on Unix and Unix-likes. You should also know about info, which is basically the same as man but some programs put their most detailed manuals in info instead of man pages.

There’s also a more recent man-like program that you should know and learn to love called tldr, which is like man but instead of giving you all the deets, it tells you how to do a few of the most common things a command is used for, and it tells you in a really concise way.

This, for example, is the output of tldr for pdftk, a common command-line utility for manipulating PDF files en masse in scripts.

pdftk
PDF toolkit.More information: https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit.

 - Extract pages 1-3, 5 and 6-10 from a PDF file and save them as another one:
   pdftk {{input.pdf}} cat {{1-3 5 6-10}} output {{output.pdf}}

 - Merge (concatenate) a list of PDF files and save the result as another one:
   pdftk {{file1.pdf file2.pdf …}} cat output {{output.pdf}}

 - Split each page of a PDF file into a separate file, with a given filename output pattern:
   pdftk {{input.pdf}} burst output {{out_%d.pdf}}

 - Rotate all pages by 180 degrees clockwise:
   pdftk {{input.pdf}} cat {{1-endsouth}} output {{output.pdf}}

 - Rotate third page by 90 degrees clockwise and leave others unchanged:
   pdftk {{input.pdf}} cat {{1-2 3east 4-end}} output {{output.pdf}}

or for sed, which we’ve discussed:

sed
Edit text in a scriptable manner.

 - Replace the first occurrence of a regular expression in each line of a file, and print the result:
   sed 's/{{regex}}/{{replace}}/' {{filename}}

 - Replace all occurrences of an extended regular expression in a file, and print the result:
   sed -r 's/{{regex}}/{{replace}}/g' {{filename}}

 - Replace all occurrences of a string in a file, overwriting the file (i.e. in-place):
   sed -i 's/{{find}}/{{replace}}/g' {{filename}}

 - Replace only on lines matching the line pattern:
   sed '/{{line_pattern}}/s/{{find}}/{{replace}}/' {{filename}}

 - Delete lines matching the line pattern:
   sed '/{{line_pattern}}/d' {{filename}}

 - Print only text between n-th line till the next empty line:
   sed -n '{{n}},/^$/p' {{filename}}

 - Apply multiple find-replace expressions to a file:
   sed -e 's/{{find}}/{{replace}}/' -e 's/{{find}}/{{replace}}/' {{filename}}

 - Replace separator / by any other character not used in the find or replace patterns, e.g., #:
   sed 's#{{find}}#{{replace}}#' {{filename}}

 - Print only the n-th line of a file:
   sed '{{n}}q;d' {{filename}}

Really, really, lovely if you’re CLI-curious but sometimes you feel a little overwhelmed working your way through all those manuals. Perfect when you just want a quick and dirty example to solve a common problem. You can grab it on Ubuntu-based distros with sudo apt install tldr

2 Likes

sudo apt update && sudo aptitude dist-upgrade threw a couple of exceptions, don’t know if they’re important:
E: The repository ‘http://ppa.launchpad.net/paulo-miguel-diaz/pkppa/ubuntu eoan Release’ does not have a Release file.
E: The repository ‘https://dl.winehq.org/wine-builds/ubuntu eoan Release’ does not have a Release file.

Maybe I should have mentioned that earlier I installed Padoka stable ppa and Wine in an effort to get things working.

It would have been good for you to mention that earlier, but it’s fine. Those errors are expected. You can remove those PPAs if you want by deleting the corresponding files in /etc/apt/sources.list.d.

So && is a special syntax that means ‘run the next command if the previous one succeeded’. Because of those errors, aptitude dist-upgrade never ran. If you like, run that sudo aptitude dist-upgrade command separately. It should think for a little while, then tell you about an upgrade plan, possibly warning you about conflicts. In general, you want to avoid resolutions that uninstall a lot of packages, but removing a few is okay. Most changes should be upgrades and some new packages will likely get pulled in.

Once the upgrade gets going, something will probably break, and we may need to massage things with apt, apt-get, or aptitude to get the upgrade going again.

If you don’t feel comfortable fielding aptitude's questions about how to go about the upgrade and whether to keep looking for solutions or accept one or the other, you can try apt-get dist-upgrade or apt full-upgrade instead. Those ones will just decide to remove some packages to make the complete upgrade happen and go for it.

aptitude can be a little more flexible in showing you multiple ways that conflicts on your upgrade path can be resolved. Trying to get it to show you the outcome you want is a bit of a game, and it can make things go smoother to play it. But if you feel like the prompts are basically meaningless to you at your current knowledge level, don’t worry about it and use one of the other ones.

(In the future, as in this post, I’ll omit sudo from the APT commands I’m describing, because package management on Debian-based distros always requires root access to make changes, so you should always expect it. Just searching or describing available and installed packages does not require sudo, but all (un)installation and upgrade commands do.)

Here’s some errors I encountered running sudo aptitude dist-upgrade:

ERROR (dkms apport): kernel package linux-headers-5.0.0-29-generic is not supported
Error! Bad return status for module build on kernel: 5.0.0-29-generic (x86_64)
Consult /var/lib/dkms/system76-io/1.0.1~1559663713~19.10~ea5f61a/build/make.log for more information.
dpkg:error processing package system76-io-dkms (–configure):
installed system76-io-dkms package post-installation script subprocess returned error exit status 10

Errors were encountered while processing:
system76-dkms
system76-io-dkms

Current status: 0 (-1294) upgradable.

1 Like

Oh, sweet! So the update finished, huh? Are you on one of System76’s laptops or desktops?

Would you mind installing tree (apt install tree) and showing me the output of

tree /etc/apt

please?

Don’t reboot just yet— those errors with respect to system76-dkms will probably mean, if you have a Thelio, that you have no storage when you reboot. Those are probably the drivers for their storage backplane.

Also please show me once again the output of

aptitude search '~i?or(radeon,amdgpu,xserver-xorg-core,linux-image-)' -F '%p %v' --disable-columns

Ok, looks like system76-dkms is actually just used for fan control and special keys on System76 laptops. If that’s not what you’re running on, you can actually just go ahead and uninstall it, with apt remove system76-dkms. system76-io-dkms is the driver for the IO backplane in the Thelio, so if you’re not running a Thelio desktop you can likewise remove that. And with that, dpkg (the lower-level counterpart to APT, which handles installing and uninstalling individual packages, whereas APT figures out how to make combinations of packages work together) will be happy about the state of your system.

If when you remove those, apt says it’s gonna remove a bunch of other package, that may be just fine, or not. Show me which packages it says doing so will remove, if it names any.

Edit: JK, I’m a big goof. Those errors you see are fine, as they’re with respect to your old kernel (where the old kernel modules are presumably still installed anyway).

A bit of an explainer: so Linux device drivers that live outside of the kernel’s source code tree are installed via a mechanism called ‘kernel modules’. When you switch to a new kernel, you want to bring those drivers with you, which usually means compiling them (or otherwise somehow treating them, this is usually called ‘compilation’ even for kernel modules distributed more or less as binaries, like NVIDIA’s drivers) against the new kernel and then putting them in a directory where the kernel will find them.

DKMS stands for ‘Dynamic Kernel Module System’ or something like that. It’s a way for Debian-based distros like Ubuntu, Pop_OS, and Linux Mint to make sure that when you change kernels, the out-of-tree modules you use with it also get updated and installed for the new kernel. It’s also used so that (as in the case that produced these errors), when you upgrade out-of-tree drivers, their new kernel modules get installed for all of your installed kernels. The error message we’re seeing in this case occurred because our upgrade pulled in a new version of these System76 drivers. These updated drivers have been modified to work with the kernel that comes with the upcoming release of Ubuntu (and so the upcoming release of Pop_OS), 19.10, codenamed Eoan Ermine. Those changes rendered the driver incompatible with the older 5.0.0.0 kernel, so when the triggers associated with that package update were processed, it tried and failed to build those drivers for your old kernel. But that’s not the kernel you’re going to boot anymore, so we don’t care.

Even though it says 0 upgradeable, go ahead and run

apt list --upgradeable

for me. Other than that, reboot and run that aptitude-based version check again. I think we may still need to upgrade your Mesa, but that may not be true since your PPAs got brought along on this upgrade.

From here, though, it looks like you may be ready to install that graphics card. If your version for xserver-xorg-video-radeon is 19.2 or higher, you should be good to go with the Mesa drivers. There may be one last step in telling the system to use those and not amdgpu, not sure.

Also, just a heads up: in about an hour and a half I have to leave to go knock on like 50 doors to help secure immigrants’ rights in my city. I should be free again by 18:30 (my timezone is UTC -7).

If you need some help in the meantime and no one here is responsive to you, you can hit me up on Wire, where my handle is, as here, @pxc. If it’s something simple like everything so far, I can shoot off a reply on my phone in between houses.

/etc/apt
├── apt.conf.d
│ ├── 01autoremove
│ ├── 01autoremove-kernels
│ ├── 01-vendor-ubuntu
│ ├── 20apt-esm-hook.conf
│ ├── 20dbus
│ ├── 20packagekit
│ ├── 50appstream
│ ├── 50command-not-found
│ ├── 51ubuntu-advantage-esm
│ ├── 60icons
│ ├── 60icons-hidpi
│ ├── 60icons-large
│ ├── 60icons-large-hidpi
│ ├── 60pop-shop
│ └── 70debconf
├── auth.conf.d
├── preferences.d
│ └── pop-default-settings
├── sources.list
├── sources.list~
├── sources.list.d
│ ├── paulo-miguel-dias-ubuntu-pkppa-disco.list
│ ├── system76-ubuntu-pop-disco.list
│ └── system76-ubuntu-pop-disco.list.save
├── sources.list.save
├── trusted.gpg
├── trusted.gpg~
└── trusted.gpg.d
├── paulo-miguel-dias_ubuntu_pkppa.gpg
├── system76_ubuntu_pop.gpg
├── ubuntu-keyring-2012-archive.gpg
├── ubuntu-keyring-2012-cdimage.gpg
└── ubuntu-keyring-2018-archive.gpg

libdrm-amdgpu1 2.4.99-1ubuntu1
libdrm-amdgpu1:i386 2.4.99-1ubuntu1
libdrm-radeon1 2.4.99-1ubuntu1
libdrm-radeon1:i386 2.4.99-1ubuntu1
linux-image-5.0.0-21-generic 5.0.0-21.22+system76
linux-image-5.0.0-29-generic 5.0.0-29.31
linux-image-5.3.0-13-generic 5.3.0-13.14
linux-image-generic 5.3.0.13.14
xserver-xorg-core 2:1.20.5+git20190820-0ubuntu3
xserver-xorg-video-amdgpu 19.0.1-1
xserver-xorg-video-radeon 1:19.0.1-1

The report after reboot is exactly the same. From apt list --upgradeable I get:

gir1.2-gnomedesktop-3.0/eoan 3.34.0-2ubuntu1 amd64 [upgradable from: 3.33.91-1ubuntu2]
gnome-desktop3-data/eoan,eoan 3.34.0-2ubuntu1 all [upgradable from: 3.33.91-1ubuntu2]
intel-microcode/eoan 3.20190918.1ubuntu1 amd64 [upgradable from: 3.20190618.0ubuntu0.19.04.1]
libgnome-desktop-3-18/eoan 3.34.0-2ubuntu1 amd64 [upgradable from: 3.33.91-1ubuntu2]
libgnutls30/eoan 3.6.9-5ubuntu1 amd64 [upgradable from: 3.6.9-5]
libgnutls30/eoan 3.6.9-5ubuntu1 i386 [upgradable from: 3.6.9-5]

xserver-xorg-video-radeon appears to be less than 19.2. Should I proceed with the drivers anyway?

Oh dang, sorry I missed this. Next, the easiest thing to do is (although not the best in some ways, because it’s newer than you actually need) upgrade your Mesa version.

The same guy whose (other?) PPA you added before has another one with the latest Mesa. That will give you the needed driver upgrade.

Replace the Padoka PPA you subscribed to before with this one, then upgrade again (apt update and apt full-upgrade), then reboot. After that you should be good to go :crossed_fingers:

https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa?field.series_filter=disco

After Mesa 19.2+ makes its way into Ubuntu and derivatives, you’ll likely want to downgrade to the stable version and remove the PPA.

sorry for the delay, @schwebbz

No problem at all, you’re not amd tech support (are you?) and I’m in no hurry. :slight_smile: I’m not quite good to go yet, though: mesa haven’t done the trick. I tried running dist-upgrade and found that the navi10 firmware files were missing. Trying to install amdgpu does not fix this, and produces more errors. If I try rebooting now, I have a feeling it won’t work without the navi10 files, but at least the screen didn’t black out on installation this time, so that’s progress, right? :stuck_out_tongue:

My apologies for showing initiative, in hidsight that was a bad idea. Are you willing to keep going with this, or is it time I started looking for a distro that supports the 5700xt ootb? I’m learning a lot, so regardless of the outcome I don’t feel it’s a waste of time for me, but it may be for you.

No worries! This is the approach I’d take on my own machine, and your evident enthusiasm and desire to learn makes it a gratifying experience for me, too.

I wouldn’t worry about the fact this has taken extra steps and some tinkering. It’ll probably still pan out. And it’s the approach I’d take on my own machine. Distro-hopping is fun, but it’s best done to explore the deep difference between distros, or to compare complete experiences holistically, not for shallow differences like what versions of this or that happen to be packaged yet for what.

Eventually, you’ll be able to run through all the steps we have so far in an hour or two (or less), with most of the time being waiting for updates to download (not requiring your active attention). I just don’t want to see you get too frustrated by the inherent delays of this back-and-forth support format.

But if you’re down to plod along and learn to solve this for ourselves, I’m also down.

I’ll do a little bit of reading on where the firmware installation is expected. For now, why don’t you apt purge the amdgpu driver, and I’ll see about extracting the firmware from that package or from elsewhere and let you know what I find.

Alright. So get yourself a nice workspace directory. I like to use one called Playground under my home directory, which I use similarly to a Downloads directory, but one that I actually do things in. Then occasionally when I want to reclaim space I’ll remove it all with a rm -rf ~/Playground/*.

Anyway, drop into that directory and start taking apart the AMDGPU driver installer:

tar -xJvf ~/Playground/amdgpu-pro-19.30-855429-ubuntu-18.04.tar.xz

If you take a look inside those .deb, you’ll find the firmware we want. You can follow my process for exploring this here, if you like. You can also use that process to grab the firmware manually.

But this will be faster:

The extraction command below is both kinda advanced and tedious, so I am not going to explain it tonight, but if you’d like I can do it tomorrow. It should extract the firmware you want in one command. But first, let’s prepare by grabbing an extraction tool:

sudo apt install p7zip-full

And then by creating the directory where we’ll extract the firmware files:

mkdir -p ~/Playground/navi-fw

Then change into that directory with cd ~/Playground/navi-fw, and from there, run (assuming you have the AMD drivers in your Downloads folder):

fwdeb=$(mktemp --suffix .deb); 7z -so x ~/Downloads/amdgpu-pro-19.30-855429-ubuntu-18.04.tar.xz | 7z -si -ttar x -ir'!amdgpu-dkms*_all.deb' -so > $fwdeb; 7z -so x $fwdeb | 7z -si -ttar -ir'!navi10*.bin' e; rm $fwdeb

This is what that produces on my system:

total 2388
-rw-r--r-- 1 pxc users  86528 Jul 24 23:52 navi10_asd.bin
-rw-r--r-- 1 pxc users 263296 Jul 24 23:52 navi10_ce.bin
-rw-r--r-- 1 pxc users    772 Jul 24 23:52 navi10_gpu_info.bin
-rw-r--r-- 1 pxc users 263424 Jul 24 23:52 navi10_me.bin
-rw-r--r-- 1 pxc users 268592 Jul 24 23:52 navi10_mec2.bin
-rw-r--r-- 1 pxc users 268592 Jul 24 23:52 navi10_mec.bin
-rw-r--r-- 1 pxc users 263424 Jul 24 23:52 navi10_pfp.bin
-rw-r--r-- 1 pxc users  43744 Jul 24 23:52 navi10_rlc.bin
-rw-r--r-- 1 pxc users  33792 Jul 24 23:52 navi10_sdma1.bin
-rw-r--r-- 1 pxc users  33792 Jul 24 23:52 navi10_sdma.bin
-rw-r--r-- 1 pxc users 267970 Jul 24 23:52 navi10_smc.bin
-rw-r--r-- 1 pxc users 163696 Jul 24 23:52 navi10_sos.bin
-rw-r--r-- 1 pxc users 455840 Jul 24 23:52 navi10_vcn.bin

You’re going to want to put those files, one way or another, into /lib/firmware/amdgpu/, i.e.,

sudo cp ~/Playground/navi-fw/*.bin /lib/firmware/amdgpu/

I’m not sure if there’s anything else you need to actually load the firmware. You can try using the 5700 XT with just that done, and let me know whether that works. Additionally, I’ll check if anything else needs to be added tomorrow.

Btw, it looks like while that amdgpu-dkms package contains the firmware, it doesn’t actually install it into /lib/firmware. I’m not really sure how the firmware ends up getting installed, but I suspect it may happen one way or another after successfully building the AMDGPU firmware modules and processing other packages. If that goes awry for any reason, the firmware is likely not installed.

Yep, that definitely broke something. Couldn’t reboot, so I did a clean install of pop!_os and repeated the process towards mesa. Problem is Padoka PPA won’t install:

E: The repository ‘http://ppa.launchpad.net/paulo-miguel-dias/mesa/ubuntu eoan Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Apparently, I can override this with apt-get, but I can’t figure out how to use it to get repositories

Also, regarding amdgpu: In addition to the navi10 .bin files I was apparently missing raven_kicker_rlc.bin and vega20_ta.bin

Oh, and glxinfo produces the following error:

name of display: :1
Error: couldn’t find RGB GLX visual or fbconfig

so I’m guessing I shouldn’t reboot until the mesa issue is resolved.

Oh, that’s my mistake. I could have sworn it included packages for Eoan. Try Oibaf’s PPA instead: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers?field.series_filter=eoan

Also, if you have openssh-server installed, you should be able to access a terminal on your machine even when the display is totally broken using the ssh command from another Linux machine or using PuTTY on Windows.

Should it break again, try logging in with

ssh <username>@<IP address or hostname>

omitting the angle brackets, of course.

Alternatively, try to access a virtual terminal by hitting one of CTRL+ALT+F[2-6] and waiting a couple seconds. (Usually the display server lives on VT7 or VT1, so you can get back to it with CTRL+ALT+F7 or CTRL+ALT+F1).

then look through the output of dmesg | less (jump to the end by typing G , or back to the beginning using g) and look for errors that mention your GPU.

Also take a look at the Xorg log at /var/log/Xorg.0.log for similar.

Make sure that boot altogether was failing and not the graphics system by checking your VTs and SSH access as described agove. Additionally, should you end up with a totally unbootable system again, we can repair and diagnose it from your Pop_OS install media without reinstalling.

Once you run a handful of commands, you can, while using the Pop_OS install media (presuming it’s a LiveCD), log into your installed system at the terminal to edit config files, read logs, or even install/upgrade/remove packages using apt, aptitude, etc. (This also works if you’re dual-booting multiple Linux distros.)

Because the chroot feature that accomplishes this is commonly used for the installation of ‘advanced’ Linux distros, there are lots of good instructions online. This is how you can spare yourself reinstalling in the future.

Don’t worry about the Usage section of that manual. Once you’ve got the bind mounts and the proc mount set up, just use chroot /mnt/mychroot /bin/bash and then bash -l -i again to get a root terminal or su - <username> to login as your normal user.

See also the Arch wiki instructions for using chroots.

I settled for ubuntu 18.04 and the pro driver. Got my dual monitors working etc. Not perfect but working and gaming.