What do you mean by “I am able to chroot into it.” How did you chroot? and into what?
Show the commands you used.
Have you any idea how I may boot in normally?
If I understand part of what you said, you are adding nomodeset to the end of the kernel line. You should just then press F10 to boot normally with nomodeset active and this should get you up to the greeter where you can log in to the GUI.
To help you get back to a “normal” boot, the users here are not clairvoyant, so we need to know what Desktop Environment you are using, and will then need information about your graphics card, possibly a few other details.
Without that information, my own reply would simply be: “Beats the heck outta me.”
Correct. Do you know of any troubleshooting steps I can take to see if this can be resolved before I report this as a bug? (If I ever figure out how to report bugs. :P)
Wait… you’re telling me that the average user here isn’t telepathic? Outrageous!
I’m dual booting with Ubuntu on a 1TB hard drive. I was able to boot into Ubuntu with Tumbleweed’s variant of GRUB without trouble. To chroot into Tumbleweed, I entered:
sudo mount /dev/sda6 /mnt
sudo chroot /mnt
“If I understand part of what you said, you are adding nomodeset to the end of the kernel line.” You are correct. That is the only way for me to boot with kernel 4.13 that I’ve discovered. I would like to not boot with any sort of “recovery” or temporary option like “nomodeset.” Inside a halfway functioning chassis I call a “computer” is an R7 360, an i5-4690K, an Asus Z97-A motherboard, and a satisfactory eight gigabytes of RAM.
Sounds like you need to boot w/“nomodeset 3”, blacklist nouveau, run nvidia installer, mkinitrd, reboot – whoops sorry, I see that you have an R7 360, I’ll have to let the Radeon experts chime in. It’s FINE if you add nomodeset as a permanent option. It’s why it’s available, sometimes you need it with some video hardware.
If I don’t use nomodeset with the Live or Rescue ISOs, then mine doesn’t usably boot either, my 1050Ti causes the screen to show garbage and that’s all I get. So I too have to use nomodeset
IMO it would be helpful to know where the boot failed.
When you boot using the kernel that fails the boot,
Hit ESC so you can see the stdout of the boot process behind the splash screen.
When the system errors or stops booting, use a camera to take a picture and post to something like a pastebin like paste.opensuse.org and provide a link in your Forum post.
If you can boot successfully booting another kernel, then do so.
Then, from a console you can retrieve the bootlog from a previous boot by using the “-b -n” where n is the incremental number counting backwards. So for instance the following will write the <previous> boot log to a file called bootlog.txt
journalctl -b -1 > bootlog.txt
After you’ve created a file with the bootlog, you can then either copy the contents of that file into a pastebin or upload the file to that pastebin as an attachment… And then again, like for the camera picture above you can provide a link to your paste in a Forum post.
Thank you for the troubleshooting guide! Fortunately, I have figured out that using the kernel module “radeon” as opposed to “amdgpu” allows me to boot without trouble.
Hi!
I’m having a similar problem. I added nomodeset to boot but I’m still unable to (although I can boot into 4.12.9).
After adding nomodeset and ctrl + x I get the following message (which seems to confirm an alternative to amdgpu would do the trick):
Hi! Thank you for your kind replies!
I’m sorry I haven’t answered sooner. I’ve tried booting into text mode with nomodeset (great idea!), adding radeon and blacklisting amdgpu, but it didn’t help. I still cannot boot into the 4.13 kernel.
I get several “possible missing firmware amdgpu/raven…” with amdgpu and no UMS support in radeon module.
I wonder if I should re-install something.
Thanks in advance for all your help!
You need to remove “nomodeset” again to be able to use radeon.
And you need to have kernel-firmware installed.
If it is, try to run “sudo mkinitrd” to add the firmware files and the amdgpu blacklist to the initrd.
plymouth intializes/uses graphics very early in the boot sequence, long before the root filesystem is mounted.
and blacklisted the amdgpu driver at etc/modeprobe.d/50-radeon.conf
Then rebuilt the initrd with
mkinitrd
and rebooted, (without nomodeset), but I get about the same problem and cannot get to the login screen.
Earlier this year I had a similar problem and that’s why I switched to the amdgpu driver. I have a Mullins Radeon R4/R5 card, and it worked perfectly until now. I wonder if I’m missing some crucial step.
Ran into this tonight after updating and thought I’d share my findings (I have a Southern Islands R9 270x). It is caused by some new functionality added to kernel 4.13+, and Phoronix talks a bit about this and even goes into benchmarks of AMDGPU vs radeon on 4.13 here: https://www.phoronix.com/scan.php?page=article&item=linux-413-gcn101&num=1
Their recommendation, which is corroborated elsewhere and working for me, is to add the following to your kernel boot line (GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub) and re-run mkinitrd:
Doing this will allow you to continue using the newer AMDGPU driver rather than the older radeon driver, though, performance is sadly still a bit lacking with AMDGPU. Hoping that will change but by the time it does I’ll probably have a new card anyway.