Just updated my server F37->F38. The display doesn't start (black screen after boot).
journalctl shows many messages like:
May 04 14:32:00 nbecker8 kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 616330 [ PRIVRING ]
nouveau? This was running nvidia driver before the update (from rpmfusion). Any ideas?
Thanks, Neal
On Thu, May 4, 2023 at 2:38 PM Neal Becker ndbecker2@gmail.com wrote:
Just updated my server F37->F38. The display doesn't start (black screen after boot).
journalctl shows many messages like:
May 04 14:32:00 nbecker8 kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 616330 [ PRIVRING ]
nouveau? This was running nvidia driver before the update (from rpmfusion). Any ideas?
I thought RPM Fusion released updates today. Have you updated today?
If not, then many folks are using `dnf update --allowerasing`.
Jeff
On 05/04/2023 12:37 PM, Neal Becker wrote:
nouveau? This was running nvidia driver before the update (from rpmfusion). Any ideas?
Do you run kmod-nvidia or akmod? If the former, the appropriate kmod might not be ready yet. Just boot into the previous kernel, and stay there until the new kmod shows up. If you're using the akmod, boot into a CLI so that neither Xorg or Wayland is running and as root run (I think) akmod --force and see what happens. If it works, reboot; if there are errors, boot into the previous kernel and report this to the rpmfusion bugzilla.
On 5/4/23 14:37, Neal Becker wrote:
Just updated my server F37->F38. The display doesn't start (black screen after boot).
journalctl shows many messages like:
May 04 14:32:00 nbecker8 kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 616330 [ PRIVRING ]
nouveau? This was running nvidia driver before the update (from rpmfusion). Any ideas?
Had this happen to me as well. Booted back to the last F37 kernel and problem went away. Current F38 kernel (6.2.14-300.fc38.x86_64) works ok.
On Thu, May 4, 2023 at 3:09 PM Tim Evans tkevans@tkevans.com wrote:
On 5/4/23 14:37, Neal Becker wrote:
Just updated my server F37->F38. The display doesn't start (black screen after boot).
journalctl shows many messages like:
May 04 14:32:00 nbecker8 kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 616330 [ PRIVRING ]
nouveau? This was running nvidia driver before the update (from
rpmfusion).
Any ideas?
Had this happen to me as well. Booted back to the last F37 kernel and problem went away. Current F38 kernel (6.2.14-300.fc38.x86_64) works ok.
Well I did boot from previous kernel, in this case 6.2.14-200.fc37.x86_64 (don't have an older fc38 kernel, I wasn't able to update to F38 until today), and display is working fine. I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
On Thu, 2023-05-04 at 16:20 -0400, Neal Becker wrote:
I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
Tim via users wrote:
On Thu, 2023-05-04 at 16:20 -0400, Neal Becker wrote:
I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
And if so, this post in the Common Issues area should help adjust the settings:
https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-us...
This doesn't affect Fedora Server, so if the system is only used as a server, installing from the Server image instead of Workstation might help avoid any future changes which are aimed at laptop/desktop users. (I don't care for this change either way -- but it's much easier to deal with on a local system than a remote server.)
On Thu, May 4, 2023 at 5:50 PM Todd Zullinger tmz@pobox.com wrote:
Tim via users wrote:
On Thu, 2023-05-04 at 16:20 -0400, Neal Becker wrote:
I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
And if so, this post in the Common Issues area should help adjust the settings:
https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-us...
This doesn't affect Fedora Server, so if the system is only used as a server, installing from the Server image instead of Workstation might help avoid any future changes which are aimed at laptop/desktop users. (I don't care for this change either way -- but it's much easier to deal with on a local system than a remote server.)
This is used as a server and only usually accessed remotely. Would this
shutdown the machine even if nobody had logged in at the console display?
On Thu, May 4, 2023 at 6:13 PM Neal Becker ndbecker2@gmail.com wrote:
On Thu, May 4, 2023 at 5:50 PM Todd Zullinger tmz@pobox.com wrote:
Tim via users wrote:
On Thu, 2023-05-04 at 16:20 -0400, Neal Becker wrote:
I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
And if so, this post in the Common Issues area should help adjust the settings:
https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-us...
This doesn't affect Fedora Server, so if the system is only used as a server, installing from the Server image instead of Workstation might help avoid any future changes which are aimed at laptop/desktop users. (I don't care for this change either way -- but it's much easier to deal with on a local system than a remote server.)
This is used as a server and only usually accessed remotely. Would this
shutdown the machine even if nobody had logged in at the console display?
Just to clarify, it is used as a server but workstation edition is installed on it.
On 5/4/23 15:14, Neal Becker wrote:
On Thu, May 4, 2023 at 6:13 PM Neal Becker <ndbecker2@gmail.com mailto:ndbecker2@gmail.com> wrote:
On Thu, May 4, 2023 at 5:50 PM Todd Zullinger <tmz@pobox.com <mailto:tmz@pobox.com>> wrote: This doesn't affect Fedora Server, so if the system is only used as a server, installing from the Server image instead of Workstation might help avoid any future changes which are aimed at laptop/desktop users. (I don't care for this change either way -- but it's much easier to deal with on a local system than a remote server.) This is used as a server and only usually accessed remotely. Would this shutdown the machine even if nobody had logged in at the console display?
Just to clarify, it is used as a server but workstation edition is installed on it.
If it's sitting at the GDM login screen, then it will automatically suspend after 15 minutes.
On Thu, May 4, 2023 at 6:50 PM Todd Zullinger tmz@pobox.com wrote:
Tim via users wrote:
On Thu, 2023-05-04 at 16:20 -0400, Neal Becker wrote:
I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
Not at all. Large organizations are trying to reduce power consumption by workstations sitting idle overnight, during meetings, lunch breaks, etc.
And if so, this post in the Common Issues area should help adjust the settings:
https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-us...
This doesn't affect Fedora Server, so if the system is only used as a server, installing from the Server image instead of Workstation might help avoid any future changes which are aimed at laptop/desktop users. (I don't care for this change either way -- but it's much easier to deal with on a local system than a remote server.)
Wake-om-lan fits many use cases (user needs network access to a "sleeping" system. My "daily driver" is an old iMac that lives in an outbuilding. I often use ssh from a laptop after doing "wake-on-lan".
Tim:
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
George N. White III:
Not at all. Large organizations are trying to reduce power consumption by workstations sitting idle overnight, during meetings, lunch breaks, etc.
And what do you think they're going to do? Undo that setting, so that they don't have to deal with employees annoyed at having to wake up their PCs all day long because they don't actually use the PC constantly to keep it awake, but do need to refer to it a lot, and the wait for resumption while trying to keep a customer on the phone is being a pain, an inability for IT to remotely manage PCs when they want, and debugging PCs that don't wake from suspend/hibernation.
Greenwashing...
On Fri, May 5, 2023 at 4:04 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
George N. White III:
Not at all. Large organizations are trying to reduce power consumption by workstations sitting idle overnight, during meetings, lunch breaks, etc.
And what do you think they're going to do? Undo that setting, so that they don't have to deal with employees annoyed at having to wake up their PCs all day long because they don't actually use the PC constantly to keep it awake, but do need to refer to it a lot, and the wait for resumption while trying to keep a customer on the phone is being a pain, an inability for IT to remotely manage PCs when they want, and debugging PCs that don't wake from suspend/hibernation.
Greenwashing...
The most annoying thing (to me) was, Fedora maintainers did not make the setting default for new installs. Instead, they changed the setting for existing installs, like a F37 -> F38 system upgrade.
It really annoyed me when a couple of my machines went to sleep and I had to drive across town to wake them and reconfigure them.
Jeff
On 5 May 2023, at 21:48, Jeffrey Walton noloader@gmail.com wrote:
On Fri, May 5, 2023 at 4:04 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
George N. White III:
Not at all. Large organizations are trying to reduce power consumption by workstations sitting idle overnight, during meetings, lunch breaks, etc.
And what do you think they're going to do? Undo that setting, so that they don't have to deal with employees annoyed at having to wake up their PCs all day long because they don't actually use the PC constantly to keep it awake, but do need to refer to it a lot, and the wait for resumption while trying to keep a customer on the phone is being a pain, an inability for IT to remotely manage PCs when they want, and debugging PCs that don't wake from suspend/hibernation.
Greenwashing...
The most annoying thing (to me) was, Fedora maintainers did not make the setting default for new installs. Instead, they changed the setting for existing installs, like a F37 -> F38 system upgrade.
I read elsewhere that the setting change is to the default. If you had ever changed the power settings the default is not used apparently.
The default is used on new installs, and because it is the default also applies to upgrades, as i say, if you had not changed the default power settings.
I am not a gnome used so have no direct experience of this change.
Barry
It really annoyed me when a couple of my machines went to sleep and I had to drive across town to wake them and reconfigure them.
Jeff _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sat, May 6, 2023 at 4:04 AM Barry barry@barrys-emacs.org wrote:
On 5 May 2023, at 21:48, Jeffrey Walton noloader@gmail.com wrote:
On Fri, May 5, 2023 at 4:04 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
Are you falling foul of the recent Gnome change that puts a machine to sleep if it considers that it's been idle for about 15 minutes?
One of the all-time *DUMB* moves by Gnome.
George N. White III:
Not at all. Large organizations are trying to reduce power consumption by workstations sitting idle overnight, during meetings, lunch breaks, etc.
And what do you think they're going to do? Undo that setting, so that they don't have to deal with employees annoyed at having to wake up their PCs all day long because they don't actually use the PC constantly to keep it awake, but do need to refer to it a lot, and the wait for resumption while trying to keep a customer on the phone is being a pain, an inability for IT to remotely manage PCs when they want, and debugging PCs that don't wake from suspend/hibernation.
Greenwashing...
The most annoying thing (to me) was, Fedora maintainers did not make the setting default for new installs. Instead, they changed the setting for existing installs, like a F37 -> F38 system upgrade.
I read elsewhere that the setting change is to the default. If you had ever changed the power settings the default is not used apparently.
The default is used on new installs, and because it is the default also applies to upgrades, as i say, if you had not changed the default power settings.
I am not a gnome used so have no direct experience of this change.
Barry
It really annoyed me when a couple of my machines went to sleep and I had to drive across town to wake them and reconfigure them.
Jeff
Same here, I guess it didn't happen on my test machine that I updated first because that was switched to sddm, another way to avoid this.
On Thu, May 4, 2023 at 5:22 PM Neal Becker ndbecker2@gmail.com wrote:
On Thu, May 4, 2023 at 3:09 PM Tim Evans tkevans@tkevans.com wrote:
On 5/4/23 14:37, Neal Becker wrote:
Just updated my server F37->F38. The display doesn't start (black screen after boot).
journalctl shows many messages like:
May 04 14:32:00 nbecker8 kernel: nouveau 0000:01:00.0: bus: MMIO read
of
00000000 FAULT at 616330 [ PRIVRING ]
nouveau? This was running nvidia driver before the update (from
rpmfusion).
Any ideas?
Had this happen to me as well. Booted back to the last F37 kernel and problem went away. Current F38 kernel (6.2.14-300.fc38.x86_64) works ok.
Well I did boot from previous kernel, in this case 6.2.14-200.fc37.x86_64 (don't have an older fc38 kernel, I wasn't able to update to F38 until today), and display is working fine. I may have another problem but time will tell (running on the newer kernel connecting via ssh several times I've walked away and then the machine is nonresponsive to ping, have to force power cycle to recover.)
Fedora has changed default power management (because large organizations are watching power consumption of systems left idle for long periods. You should try wake-on-lan when a system stops responding to remote network access (ping, ssh, etc.).