Still no love with Ryzen 2400G and Linux (ubuntu 16.04)

There is still no success trying to get my Ryzen 5 2400G to work for more than 4 hours with Ubuntu 16.04.

Ruffalo and sgtawesomesauce both suggested kernel 4.17, and Michael at phoronics has a stable system with Ubuntu 18, 4.17 and Mesa 18.2. My problems are that 1) I can’t get a kernel higher than 4.16.2 to boot, 2) Ubuntu 18.04 breaks my file sharing despite trying the workarounds, and 3) I have no idea how to upgrade Mesa to 18.2.

I’ve used Ukuu to upgrade my kernel from the 4.13 in Ubuntu 16.04 to 4.16.2, as I can’t find a tutorial on upgrading the kernel via terminal that isn’t in master race-speak (I figure that will be my problem with Mesa as well). Synaptic and the software updater in Ubuntu are not helpful, not is a terminal update and upgrade (apt-get).

Again, any guidance is greatly appreciated.

aw

It’s been a long time since I last used Ubuntu, but could you not upgrade the kernel from either one of those software tools you listed? Either way, I don’t think it matters what way in which you get a new kernel.

Someone with more experience here will be able to help you find the failed boot up logs and deduce as to why this is happening.

There are plenty guides out there to install Mesa via the command line. Some are easier to digest then others. OMGUbuntu.co.uk has a pretty easy guide to follow to install a new version of Mesa on Ubuntu 16.04. The guide is a little old, and Mesa 17.0.2 is mentioned, but the process is ideally still the same.

I will also add the helpdesk tag to your thread.

Based on my Vega 64 experience… unless you really are stuck on 16.04 for some reason, I’d suggest upgrading to Ubuntu 18.04 or Fedora 28.

Ubuntu 16.04 is a previous version LTS release, whilst your hardware is fairly bleeding edge (sure, it’s been out for a few months now, but in Linux land “bleeding edge” hardware is anything newer than a year or two generally :smiley: .

Hacking new packages onto an older distribution in my experience, you end up diverging from the supported baseline and it just complicates upgrades in the future.

I don’t think it’s just Ubuntu 18.04. And at least on Fedora 27/28, file sharing / samba work, it’s network discovery that fails. Seems to be a bug with gvfs: https://bugzilla.redhat.com/show_bug.cgi?id=1513394

Same or similar problem with Solus: https://dev.solus-project.com/T1223

2 Likes

Goalkeeper, thanks for the links … I’ve got them bookmarked for future reference!

thro , I’m not wedded to 16.04 but I don’t _need_to upgrade except to get my computer to function at a basic level … it certainly doesn’t help when the upgrade breaks things. The Samba functionality is specifically for Kodi and I’d gladly switch to NFS if I could find a good, normie-level tutorial.

Thanks for the help!

aw

@Goalkeeper’s links are great I would read them however its possible that in order to get kernel 4.16.2 and above to make ubuntu 16.04 boot that you need to do a few things. 1 go into your grub cfg and make sure that your not in quiet nor splash mode so at least you can see whats hanging the boot. Once youve figured that out dump it here. Also it might be required that you find a proper backport of the kernel with the correct modules and stuff to load everything 16.04 requires but this is unlikely. I have never known a distribution that many times to be kernel dependent.

@akwusmc you need to do the following to upgrade your kernel. I think starting with 4.17 there is a kernel modules package in the ubuntu mainline.

Here would be what I did as a first attempt.

Open the terminal or use tty and do the following:
(Dont fear the terminal. I assume when you say master race speak thats probably what you mean)

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.8/linux-headers-4.17.8-041708_4.17.8-041708.201807180730_all.deb

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.8/linux-headers-4.17.8-041708-generic_4.17.8-041708.201807180730_amd64.deb

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.8/linux-image-unsigned-4.17.8-041708-generic_4.17.8-041708.201807180730_amd64.deb

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.8/linux-modules-4.17.8-041708-generic_4.17.8-041708.201807180730_amd64.deb

sudo dpkg -i *.deb

these links were sourced from here
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.8/
in the AMD 64 section

If these directions do not work for you let me know. Ill see how else I can help

Thanks for the info, Heimdallr … I may try updating the kernel that way this weekend!

Not sure how to tell if grub is in quiet or splash mode … i can look at my grub.cfg and find ‘quiet’ and ‘splash’ but I don’t know how to tell if that means it’s active or not. Nor do I know how to recover the failed boot messages to post outside of hand-copying what’s on the screen and transcribing it here.

And I’m not scared of the terminal (I like Terminator and I enjoy using the cmd line for certain things, like updating my system); but when most of the ‘help’ directs a user to do things like ‘clone the git to get that fixed’ or requiring administrator-level fluency … that’s not very helpful to me. In other words, I can follow directions but my actual knowledge about linux is barely above ‘normie’!

I’ll try to upgrade that kernel this weekend and let you know how it went! Thanks again.

aw

This is what mine looks like… Change anything that says quiet or splash to nothing. Most distributions put that optin in the cmdline default section and you can safely erase them before you install the next kernel and update the grub so at least you can perform diagnostics

 If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT="0"
GRUB_HIDDEN_TIMEOUT_QUIET="true"
GRUB_TIMEOUT="-1"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
GRUB_CMDLINE_LINUX_DEFAULT="nouveau.modeset=0 nouveau.runpm=0"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="1920x1080"

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID="true"

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

export GRUB_MENU_PICTURE="/home/kareem/Pictures/499786.png"
export GRUB_COLOR_NORMAL="light-gray/black"
export GRUB_COLOR_HIGHLIGHT="white/black"
GRUB_FONT="/boot/grub/unicode.pf2"

thats just retarded. they should ascertain your knowledge level first. This is normal though the communities can sometimes be esoteric and/or toxic

"This is what mine looks like… "

Yeah, mine’s a lot more complicated, and a LOT longer. I’ll post it if someone can tell me how to put it in one of those scrollable boxes (or link to forum instructions) like you did the wget code.

I exaggerated a bit for the sake of brevity regarding the help found on the internet. The places that have the most technically adept individuals I only go to in the hopes that there might be some snippet of help that I might understand (which I usually don’t!).

Other sites where questions are asked that are similar to ones I might ask (I’m looking at you, stackexchange) often will shut the question down as having been substantially answered before (with no link to the answer) or it’s in the wrong section or someone pissed in the moderators Wheaties that day.

I prefer help that is terminal-based as that’s more universal than relying on having the correct distro and just the right DE …‘What? You’re using Nemo and not Nautilus? Can’t help ya …’

I had hoped to not get into that particular rant!

Anyway, I’ll post my grub.cfg if it won’t increase the length of this thread by a factor of 20!

Thanks again.

aw

Vega Pro-Tip: Blacklist the ‘radeon’ kernel module. There’s some gnarly bugs where radeon will attempt to initialize a Vega GPU and then panic. Vega cards are supported by ‘amdgpu’, not ‘radeon’.

There’s a few ways to do that.

You can do it permanently by editing /etc/default/grub file and adding the following at the GRUB_CMDLINE_LINUX_DEFAULT section.

blacklist.radeon=yes

Alternatively, you can do it as a one-time thing by adding that exact same thing to the GRUB boot promp. Reboot your system and hold SHIFT during boot to force the GRUB menu to display. Press ‘e’ to edit, type in the blacklist option, and CTRL+x to boot. There’s on-screen text for help during.

As to getting it working on an older Ubuntu release, I’d suggest upgrading. Updating the kernel, mesa, and xorg to get things running is a huge part of a working graphical system. You’re sticking to an LTS release for stability, and then immediately crushing the foundation of a stable by replacing so much.

In the long run, it’ll probably be less of a pain to fix your Samba issue and upgrade than to shoehorn in bleeding-edge hardware into an intentionally old and stable system. Vega is still very much ‘there be dragons’ territory for Linux, but the progress in recent releases has been amazing.

I’ve had really good experiences with Arch and Gentoo for my 2400G. Fedora kernel panics 100% of the time, even aside from the radeon related issues. Debian has an open bug making all releases a no-go for the Vega chipset (Processor works fine). Ubuntu 16.04 is officially supported by AMD, but Vega isn’t supported in the Pro driver as a week or two ago.

Even worse, a bug was found affecting some Linux 4.17 users using the Vega HDMI port as a primary display. 4.18-rc2 seemed to have it fixed.

I’ve shoved an RX580 in and use that to work around Vega’s issues, but I’d probably be doing that anyway for the DisplayPort.

1 Like