On 06/13/18 10:47, Alex wrote: > Hi, > > On Tue, Jun 12, 2018 at 6:16 PM, Ed Greshko <ed.greshko@xxxxxxxxxxx> 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 kbuild@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) (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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/5BHX4BB2NYPIVHYOMXID5MVKA3DRJ3OG/
