Hi all, this appears to be a problem with the latest kernels and Radeon cards (at least). Adding 'nomodeset' to the kernel command-line fixes it.
Has anyone else experienced this where the screen goes blank shortly after booting and is completely unresponsive? On Tue, Jun 12, 2018 at 11:10 PM, Ed Greshko <ed.gres...@gmail.com> wrote: > On 06/13/18 10:47, Alex wrote: >> Hi, >> >> On Tue, Jun 12, 2018 at 6:16 PM, Ed Greshko <ed.gres...@greshko.com> wrote: >>> On 06/13/18 04:45, Alex wrote: >>>> Hi, >>>> I have a fedora27 system on an older x86_64 machine and when booting >>>> the latest kernel (I believe it was just released today) as well as >>>> the previous two, the display goes dark and becomes unresponsive. >>>> >>>> I've booted into the rescue kernel (an older 3.14 from fc21) to get it >>>> back online. >>>> $ uname -a >>>> Linux localhost 3.17.4-301.fc21.x86_64 #1 SMP Thu Nov 27 19:09:10 UTC >>>> 2014 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> All other current kernels failed. >>>> >>>> How do I troubleshoot this? >>>> >>>> Based on the output from journalctl, it appears to be something >>>> related with gnome and/or packagekit and/or the display driver. Here's >>>> a few select error messages that look like they could be the cause. >>>> I've also uploaded the journalctl boot entry that I believe is >>>> associated with this boot to pastebin: >>>> >>>> https://pastebin.com/804NfcEB >>>> >>> This does not appear to be a journal from a failed boot. >> My apologies; can we try again? >> >> https://pastebin.com/BjKf0Kdt > > That can't be a "crash" either because.... > > > Jun 12 15:52:27 localhost systemd[1]: Reached target Graphical Interface. > > The Graphic Target has been reached... > > Jun 12 15:52:28 localhost systemd[1]: Startup finished in 2.883s (kernel) + > 4.719s > (initrd) + 1min 44.210s (userspace) = 1min 51.812s. > > The startup is complete. > > Jun 12 15:52:29 localhost dbus-daemon[1431]: [session uid=1000 pid=1426] > Successfully > activated service 'org.gnome.evolution.dataserver.Calendar7' > Jun 12 15:52:29 localhost dbus-daemon[1430]: [session uid=1000 pid=1427] > Successfully > activated service 'org.gnome.evolution.dataserver.Calendar7' > > UID 1000 seems to be set for automatic login and evolution processes are > starting. > > Jun 12 15:52:35 localhost sshd[2954]: Invalid user tech from 42.99.180.167 > port 57531 > > And sshd is running and someone has tried to login.... > >> Is it possible the system crashes prior to logging? I'm assuming the >> current boot is 0, which is the rescue kernel. The previous boot was >> the crash with the latest kernel, so I'm assuming that's -1, which is >> what's posted in the pastebin above. > > Yes, it is possible you won't get to logging.... > > If you look at the very start of a boot you should see something like this... > > [egreshko@acer ~]$ journalctl -b | more > - Logs begin at Fri 2017-11-24 06:58:33 CST, end at Wed 2018-06-13 11:05:48 > CST. - > - > Jun 13 10:38:19 acer.greshko.com kernel: microcode: microcode updated early > to revi > sion 0xa4, date = 2010-10-02 > Jun 13 10:38:19 acer.greshko.com kernel: Linux version > 4.16.14-300.fc28.x86_64 (moc > kbu...@bkernel02.phx2.fedoraproject.org) (gcc version 8.1.1 20180502 (Red Hat > 8.1.1 > -1) (GCC)) #1 SMP Tue Jun 5 16:23:44 UTC 2018 > Jun 13 10:38:19 acer.greshko.com kernel: Command line: > BOOT_IMAGE=/vmlinuz-4.16.14- > 300.fc28.x86_64 root=/dev/mapper/fedora_acer-root ro > rd.lvm.lv=fedora_acer/root rd. > lvm.lv=fedora_acer/swap rhgb quiet nouveau.modeset=0 > rd.driver.blacklist=nouveau vi > deo=vesa:off LANG=en_US.UTF-8 > Jun 13 10:38:19 acer.greshko.com kernel: x86/fpu: x87 FPU will use FXSAVE > Jun 13 10:38:19 acer.greshko.com kernel: e820: BIOS-provided physical RAM map: > Jun 13 10:38:19 acer.greshko.com kernel: BIOS-e820: [mem > 0x0000000000000000-0x00000 > 0000009f7ff] usable > > >> >>> Your subject seems to imply that you never get to login screen at either a >>> graphical >>> or run level 3 boot. >> Yes, that's correct. There are a lot of "failure" and other "fail" >> errors including "Failed to get current display". >> >>> Suggest you also edit your boot parameters to remove "rhgb" and "quiet" to >>> watch the >>> boot process more closely. >> I've done that now. This is actually a friend's computer, located >> about 30 miles away, so I can't reboot it very easily without making >> sure he's there to monitor. > > OK. Someone has to be at the system to see exactly what is going on.... > >> >> Samuel Sieb wrote: >>> Can you access it remotely using ssh? >> No, it's completely catatonic - no ping, no ssh, no disk activity. > > And, as you can see from the above, the info you've put on pastebin shows > sshd to be > running and accepting connections. > > > -- > Conjecture is just a conclusion based on incomplete information. It isn't a > fact. > > > _______________________________________________ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/5BHX4BB2NYPIVHYOMXID5MVKA3DRJ3OG/ > _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/FYIG4BSUBNLDC6J6AXVAYKKWHDTZ6QH3/
