3:45 p.m.
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
Jun 12 15:38:19 localhost pulseaudio[2016]: [pulseaudio] module.c:
Failed to load module "module-x11-xsmp" (argument: "display=:0
session_manage
Jun 12 15:38:19 localhost gsd-rfkill[3443]: Error setting up rfkill:
Could not open RFKILL control device, please verify your installation
Jun 12 15:38:19 localhost gnome-session-binary[3059]: WARNING: App
'pulseaudio.desktop' exited with code 1
Jun 12 15:38:19 localhost gsd-sharing[3448]: Failed to StopUnit
service: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit
gnome-user-share-
Jun 12 15:38:20 localhost gnome-shell[3157]: Error looking up
permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No
entry for geoloc
Jun 12 15:38:49 localhost abrt-notification[3967]: Process 1897
(blueman-applet) of user 1000 encountered an uncaught GLib.GError
exception
Jun 12 15:39:06 localhost gnome-software[2443]: failed to resolve
third party repo: Timeout was reached as packagekit took too long to
return results
Jun 12 15:51:51 localhost dbus-daemon[1431]: [session uid=1000
pid=1426] Activated service 'org.freedesktop.systemd1' failed: Process
org.freedesktop.systemd1 exited with status 1
Thanks,
Alex
3:58 p.m.
Hi, I should add that I tried to boot into runlevel 3 and it made no
difference. How do I determine at what point it went to a black screen
and just stopped booting?
I also noticed there's a packagekit core dump, but is that enough to
prevent it from booting?
On Tue, Jun 12, 2018 at 4:45 PM, Alex <mysqlstudent(a)gmail.com> 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
>
> Jun 12 15:38:19 localhost pulseaudio[2016]: [pulseaudio] module.c:
> Failed to load module "module-x11-xsmp" (argument: "display=:0
> session_manage
> Jun 12 15:38:19 localhost gsd-rfkill[3443]: Error setting up rfkill:
> Could not open RFKILL control device, please verify your installation
> Jun 12 15:38:19 localhost gnome-session-binary[3059]: WARNING: App
> 'pulseaudio.desktop' exited with code 1
> Jun 12 15:38:19 localhost gsd-sharing[3448]: Failed to StopUnit
> service: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit
> gnome-user-share-
>
> Jun 12 15:38:20 localhost gnome-shell[3157]: Error looking up
> permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No
> entry for geoloc
>
> Jun 12 15:38:49 localhost abrt-notification[3967]: Process 1897
> (blueman-applet) of user 1000 encountered an uncaught GLib.GError
> exception
>
> Jun 12 15:39:06 localhost gnome-software[2443]: failed to resolve
> third party repo: Timeout was reached as packagekit took too long to
> return results
>
> Jun 12 15:51:51 localhost dbus-daemon[1431]: [session uid=1000
> pid=1426] Activated service 'org.freedesktop.systemd1' failed: Process
> org.freedesktop.systemd1 exited with status 1
>
> Thanks,
> Alex
4:09 p.m.
On 06/12/2018 01:58 PM, Alex wrote:
Hi, I should add that I tried to boot into runlevel 3 and it made no
difference. How do I determine at what point it went to a black screen
and just stopped booting?
Can you access it remotely using ssh?
You could try adding the "nomodeset" parameter to the kernel command
line and see if that makes a difference.
I also noticed there's a packagekit core dump, but is that enough
to
prevent it from booting?
Unlikely.
4:44 p.m.
Is it <Alt-F7> to get the log session or is it F6?
On 06/12/2018 05:09 PM, Samuel Sieb wrote:
On 06/12/2018 01:58 PM, Alex wrote:
> Hi, I should add that I tried to boot into runlevel 3 and it made no
> difference. How do I determine at what point it went to a black screen
> and just stopped booting?
Can you access it remotely using ssh?
You could try adding the "nomodeset" parameter to the kernel command
line and see if that makes a difference.
> I also noticed there's a packagekit core dump, but is that enough to
> prevent it from booting?
Unlikely.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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.o...
5:17 p.m.
No. During boot, on the main session <Alt-d> shows what is transpiring,
but one of the other screens shows all the messages.
On 06/12/2018 06:00 PM, Samuel Sieb wrote:
On 06/12/2018 02:44 PM, Robert Moskowitz wrote:
> Is it <Alt-F7> to get the log session or is it F6?
What log session? Are you thinking of the installer?
5:16 p.m.
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.
It contains....
Jun 12 15:47:27 localhost dracut[5060]: Executing: /usr/bin/dracut -f
/boot/initramfs-4.16.14-200.fc27.x86_64.img 4.16.14-200.fc27.x86_64
Which happens when a new kernel is being installed. It also contains references to
sessions with uid=1000 which is normally the first user created at install time and
would only appear at a successful login or ssh session.
Your subject seems to imply that you never get to login screen at either a graphical
or run level 3 boot.
Suggest you also edit your boot parameters to remove "rhgb" and
"quiet" to watch the
boot process more closely.
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
9:47 p.m.
Hi,
On Tue, Jun 12, 2018 at 6:16 PM, Ed Greshko <ed.greshko(a)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
It was a little confusing trying to identify them. There was more than
one failure to boot, but it didn't appear like they were all reflected
in the "journalctl --list-boots" output.
$ journalctl --list-boots
-5 1567da53b9a9461c9a9ca930b997e3cf Sat 2018-05-12 20:46:01 EDT—Wed
2018-05-23 09:37:48 EDT
-4 cf03a8527dda41aa867a290ad6151229 Wed 2018-05-23 09:39:05 EDT—Sun
2018-06-10 10:15:41 EDT
-3 53ce200a71154fed8d05878ad84b2a4a Sun 2018-06-10 10:15:52 EDT—Sun
2018-06-10 12:30:04 EDT
-2 8ae904ef7456460ab323e9e8250e3a73 Tue 2018-06-12 15:35:46 EDT—Tue
2018-06-12 15:48:27 EDT
-1 80c821560eec4977b1f25562bb7ecda3 Tue 2018-06-12 15:50:49 EDT—Tue
2018-06-12 16:44:09 EDT
0 936866212c9b43c4a165bc7c32d09775 Tue 2018-06-12 16:48:06 EDT—Tue
2018-06-12 22:11:01 EDT
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.
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.
Samuel Sieb wrote:
Can you access it remotely using ssh?
No, it's completely catatonic - no ping, no ssh, no disk activity.
10:10 p.m.
On 06/13/18 10:47, Alex wrote:
Hi,
On Tue, Jun 12, 2018 at 6:16 PM, Ed Greshko <ed.greshko(a)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
kbuild(a)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.
11:05 a.m.
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.greshko(a)gmail.com> wrote:
> On 06/13/18 10:47, Alex wrote:
>> Hi,
>>
>> On Tue, Jun 12, 2018 at 6:16 PM, Ed Greshko <ed.greshko(a)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
> kbuild(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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.o...
>
8:05 p.m.
On Sat, Jun 16, 2018 at 7:11 PM, Samuel Sieb <samuel(a)sieb.net> wrote:
On 06/16/2018 09:05 AM, Alex wrote:
>
> 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.
What video device do you have? Look in the output of "lspci" for a line
containing "VGA".
Ah, I meant to post that with my last message:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Cypress PRO [Radeon HD 5850]
Thanks,
Alex
2149
days inactive
2154
days old
11 comments
5 participants
participants (5)
-
Alex -
Ed Greshko -
Ed Greshko -
Robert Moskowitz -
Samuel Sieb