I recently had a pretty nasty power surge which I thought fried my motherboard. I just installed an MSI A68H E33 V2 and am having the following issue. Ubuntu boots to a grey screen with black borders, then to a full grey screen, then a black screen, and then reboots. I can get the system to boot just fine with nomodeset added to my /etc/default/grub. This is obviously not ideal as things like redshift don’t work. What is also interesting is that I can get Ubuntu to boot normally, but I have to mash the up and down arrows as soon as I get the second grey screen. I have disabled the splash screen thinking that might help, but the issue persists. I ran a two pass Memtest and that came back clean. I did notice a weird ACPI error in dmesg, but that was there prior to the motherboard change. The acpi=off flag in grub doesn’t help matters either. I am kind of at a loss for where to go from here, so any help would be greatly appreciated!
I had an old AMD based laptop with integrated graphics and had the same issue, and just decided to live with nomodeset.
My system seemed to work fine, including compiz 3D and accelerated video, and the info I found about it seemed to indicate that it was mainly about pretty graphics during boot.
The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts.. This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesnt work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded.
The key words above being "until X is loaded", so once your desktop loads, and the graphical video driver should take over and everything should work well if the video driver is up to snuff, though I am not surprised that you are seeing minor issues. Some video drivers work better with nomodeset than others so I guess "your mileage may vary" applies here.
Did you try installing the alternate AMD proprietary video drivers? They could eliminate the need for nomodeset, or at least restore some of the missing functionality you mentioned.
I have avoided the proprietary AMD drivers in the past, because they were buggy as hell, but I have heard that they are much better now, so you might want to give them a try.
The cutting edge AMD drivers may not pop up as an option under Control Center -> Additional Drivers, but you can Google "Install latest AMD proprietary video drivers in 18.04".
Unfortunately there is no linux driver on AMD’s website for my integrated graphics. My processor is an A6-5400 with onboard HD 7540d graphics. Like I said, I would be okay with using nomodeset, but apparently the kernel does not load the drivers when X starts as my display is no longer recognized and other nice features won’t work (mainly redshift, but I can’t change the gamma with xgamma either). I am starting to suspect I may need a different processor/gpu.
I see what you mean, I thought you were dealing with a "Kaveri" generation or newer APU.
I also couldn't find a AMD driver that explicitly lists your APU, but I am still a little bit surprised that it isn't 'close enough' for the generic AMD open source driver to at least boot up without crashing.
You could indeed replace your current AMD CPU/APU with a newer version, but that's kind of a crap shoot since your problem could be related to other motherboard related issues.
So before you do that, if you haven't already, you might want to try some other kernel options like noapic, nolapic. I just checked my old AMD laptop, and found that after initially running with the 'nomodeset' option to get it to boot, I eventually commented that out in my grub config and switched to 'nolapic' instead, which let my particular hardware load the video driver.
That was back in the Ubuntu 12 days, so there is no telling if the same fix would even work today with 18.04, since I haven't updated that old machine, but it does show that sometimes other issues can crash your video driver - in my case the way the kernel was setting up the LAPIC interrupt handler.
So it's kind of fifty-fifty whether changing the CPU is going to work, though it might be worth a try if you can get another FM2+ socket AMD replacement APU on eBay or elsewhere at a good price.
Another option would be to switch over your whole graphics stack by installing something like an NVIDIA GT 1030 based GPU card which you can pick up on ebay for as little as 50 or 60 dollars. I just did a quick check and see a brand new EVGA card for $59.99.
I can highly recommend NVIDIA based cards, as I have owned several PC's over the years with NVIDIA graphics (the last two specifically with NVIDIA based EVGA GPU cards) and found that NVIDIA offers MUCH better driver support in both Windows and Linux. NVIDIA still supports graphics chipsets much older than your current AMD APU, and although there are occasional issues, like when 18.04 was released, things never stay broken for long, because unlike AMD, Nvidia still supports their products in Linux after they sell them (not just when they are newly released and they trying to get you to buy them).
Either option, a new/used AMD APU or a new/used external GT 1030 based GPU card will set you back about the same amount of cash, but the GPU card would remain useful if you later upgrade to another motherboard with a faster CPU.
To put it in perspective, the GT1030 has about 4 times the graphics processing power of the IGPU that is provided by your current AMD processor, and would still be about twice as powerful as the highest end APU you are likely to install, even if you upgraded to something like an A10-7700K.
Of course an A10-7700K would about double your non-graphical CPU performance over what you are running now, so that's a factor, but as I said above, whether or not it will fix your graphical driver issues is a bit of a toss up.
Maybe someone who has an FM2/FM2+ AMD APU running WHICH DOES WORK WELL IN UBUNTU 18.04 would be kind enough to chime in here and help out . . .
Over the years, I have had nothing but trouble with the Ubuntu splash screen system (Plymouth) so I no longer display a splash screen anywhere.
The following grub boot options may be helpful:
(1) acpi_enforce_resources=lax (if you have hardware overlapping i/o addresses - unfortunately, too common!)
(2) radeon.audio=0 (Turns off HDMI audio)
(3) loglevel=4 (See important boot messages)
You will want to add a line:
GRUB_GFXPAYLOAD_LINUX=textHere is what my /etc/default/grub looks like
[code]# 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=5
GRUB_DISTRIBUTOR=Ubuntu
GRUB_CMDLINE_LINUX_DEFAULT=“acpi_enforce_resources=lax net.ifnames=0 biosdevname
=0 loglevel=4”
GRUB_CMDLINE_LINUX=""
#net.ifnames=0 biosdevname=0
radeon.audio=0 turns off HDMI digital audio channel
net.ifnames=0 biosdevname=0 turns off Predictable Network Device Names
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=1024x768
GRUB_GFXPAYLOAD_LINUX=text
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”
[/code]
I’ve got several Llano APU systems running OK.
If you can get the system to boot and can copy the “dmesg” output to a pastebin somewhere I’ll look through it to see if there are some of the usual problems.
djb
Additional boot option:
iommu=soft (Use this if you see “AMD-Vi: Event logged [IO_PAGE_FAULT” type errors)
Thanks for the tips guys. I will try your suggestions this evening when I return from work and let you know the results.
It also could be this ACPI error:
Firmware Bug: ACPI: No _BQC method, cannot determine initial brightnessUbuntu expects the BIOS to set the LCD background brightness. Since no brightness level is found, the boot code (Plymouth?) sets the backlight OFF.
His first post referenced an MSI A68H E33 V2 so he is dealing with an external monitor, so hopefully backlight control isn't an issue - unless Ubuntu is so screwed up that it can't figure that out.
Sorry if my earlier reference to how I fixed issues with my old AMD laptop confused the issue, but I agree 100% which your earlier suggestion to try disabling the graphic boot screen, as I have also had systems in the past that required that I drop back to a text based boot screen to avoid crashing.
I’ve had the backlight issue with All-In-One systems with an AMD APU that Ubuntu thinks is a laptop. The MSI A68H E33 V2 BIOS doesn’t set the backlight and for whatever reason, with an AMD APU, Ubuntu (or the Linux kernel) expects the backlight level to be set.
I was able to find a “dmesg” listing for the MSI motherboard…
djb