Same here. None of the keyboard shortcuts work. Just reboot.
Well, I still have the 200. How do I get the 300?
You just need to update the system.
Type
dnf update --refresh
in the Terminal and it’s done 
Please report here if this fix the problem for you
Thanks for reply. mine is:
5.6.6-300.fc32 so u think it was kernel bug?
what is best to have system all updated and secured?
sudo dnf upgrade
sudo dnf --refresh
or
sudo dnf update?
are that commands same?
Ok. I did the dnf update --refresh, a command I didn’t know well and I find out it’s another way to update the system.
I don’t know if I already mentioned it in my original post, but I’ll remind you: every day, after I turn on my PC, the first thing I do is open the terminal and run dnf upgrade, which is the way I update my system. So the kernel and my system in general is updated with the latest that Fedora offers me.
My current kernel, the most recent one, is still 5.6.8-200.fc31.x86_64.
That concludes, that in my case, dnf update --refresh does not solve the problem.
I will continue to report. 
Update command is a deprecated alias for the upgrade command.
Reference:
https://dnf.readthedocs.io/en/latest/command_ref.html#update-command
1 Like
@zarathustra19 I don’t know if it’s a kernel bug. I’ve only updated the system (and the kernel) and the problem seems fixed for me. For this reason I suggested you to update.
As reported by @alciregi (thanks!) you can use “dnf upgrade --refresh”.
The --refresh option just sets the metadata as expired before running the command.
https://dnf.readthedocs.io/en/latest/command_ref.html
@sonnycardona The *-200 is probably the last update available for F31.
1 Like
Another freeze :-/ below the logs and it’s alwyas the same error.
Journalctl -p2
-- Logs begin at Wed 2020-05-06 17:25:56 CEST, end at Wed 2020-05-06 18:04:34 CEST. --
mag 06 17:26:31 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: object GsmAutostartApp 0x55596d5aba20 finalized while still in-construction
mag 06 17:26:31 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: Custom constructor for class GsmAutostartApp returned NULL (which is invalid). Please use GInitable instead.
mag 06 17:26:32 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: object GsmAutostartApp 0x7f9d2c0123d0 finalized while still in-construction
mag 06 17:26:32 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: Custom constructor for class GsmAutostartApp returned NULL (which is invalid). Please use GInitable instead.
Journalctl -p3:
-- Logs begin at Wed 2020-05-06 17:25:56 CEST, end at Wed 2020-05-06 18:05:03 CEST. --
mag 06 17:25:56 enrico-fedora systemd-modules-load[231]: Failed to find module 'vboxdrv'
mag 06 17:25:56 enrico-fedora systemd-modules-load[231]: Failed to find module 'vboxnetflt'
mag 06 17:25:56 enrico-fedora systemd-modules-load[231]: Failed to find module 'vboxnetadp'
mag 06 17:26:07 enrico-fedora systemd[1]: systemd-rfkill.socket: Socket service systemd-rfkill.service not loaded, refusing.
mag 06 17:26:07 enrico-fedora systemd[1]: Failed to listen on Load/Save RF Kill Switch Status /dev/rfkill Watch.
mag 06 17:26:24 enrico-fedora setroubleshoot[1180]: SELinux impedisce a pcscd di utilizzare la capacità sys_nice. Per i messaggi SELinux completi, eseguire: sealert -l 7d97db0a-b200-460f-8f73-8ad0e765bf26
mag 06 17:26:28 enrico-fedora setroubleshoot[1180]: SELinux impedisce a accounts-daemon di utilizzare la capacità sys_nice. Per i messaggi SELinux completi, eseguire: sealert -l d88cf178-1784-4d3d-b602-5047b29cb5ad
mag 06 17:26:31 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: object GsmAutostartApp 0x55596d5aba20 finalized while still in-construction
mag 06 17:26:31 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: Custom constructor for class GsmAutostartApp returned NULL (which is invalid). Please use GInitable instead.
mag 06 17:26:32 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: object GsmAutostartApp 0x7f9d2c0123d0 finalized while still in-construction
mag 06 17:26:32 enrico-fedora mate-session[1521]: GLib-GObject-CRITICAL: Custom constructor for class GsmAutostartApp returned NULL (which is invalid). Please use GInitable instead.
mag 06 17:26:33 enrico-fedora setroubleshoot[1180]: SELinux impedisce a tlp un accesso search su cartella /var/lib/snapd. Per i messaggi SELinux completi, eseguire: sealert -l 0e5c859f-5423-4d2f-8e6e-8ab602553b08
If you needed to reboot because of the freeze before doing journalctl, then you had to use -b -1 as a parameter, to ask journalctl to produce results for your previous session… the first line tell you when that session began and ended, so hopefully you will be able to know if that span of time is when the computer frozen. You might need to go even earlier with -b -2 if you rebooted once more since last freeze.
-r would give the result in reverse order (last even first)… and it make sense here since we would like to know what happens at the end of the session… just before reboot.
-p2 is giving only at least critical messages
-p3 is giving only at least error messages
so -p2 is subset of -p3
and -p3 would be a subset of -p4
So If you give the output of -pn … you probably dont’t need to give the output with a lower value than n… unless to make it easier to spot errors… but I don’t think it is really useful.
You could use -k to limit message to the one generated by the kernel to limit the quantity.
So “journalctl -b -1 -k -p5 -r” or “journalctl -b -2 -k -p5 -r” is likely to give more relevent info… you should check the first line to try to know if the span of time covered contain the moment of the last freeze.
3 Likes
Thank you. I can’t understand ho to use this command
[root@enrico-fedora enrico]# journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal was found
so I’ve done a little online search and found the --list-boots command to list the available logs:
[root@enrico-fedora enrico]# journalctl --list-boots
0 abfe6b71141c48f0a05be7aecc0316f5 Wed 2020-05-06 17:25:56 CEST—Thu 2020-05-07>
it seems that I have only one log. Maybe this is the reason why the -b -1 command doesn’t work.
You could edit the file: /etc/systemd/journald.conf
and put:
Storage=persistent
under #Storage=auto
The # indicate a comment.
you could do it with “sudo gedit /etc/systemd/journald.conf”
Not sure how you ended up with a “volatile” journal… but have read this have happened to other on devel mailing list.
1 Like
Thanks, I’ve done the change in the file. I don’t know if this could be related to the upgrades (I’m upgrading and not reinstalling since Fedora 28). Anyway, I’ll let you know as soon as I get another freeze. Thanks!
Ok, this is the report before the freeze. There are some strange things
mag 10 15:01:01 enrico-fedora CROND[129088]: (root) CMD (run-parts /etc/cron.hourly)
mag 10 15:01:01 enrico-fedora run-parts[129092]: (/etc/cron.hourly) starting 0anacron
mag 10 15:01:01 enrico-fedora run-parts[129098]: (/etc/cron.hourly) finished 0anacron
mag 10 15:16:41 enrico-fedora systemd[1]: Starting dnf makecache...
mag 10 15:16:42 enrico-fedora dnf[134636]: Cache dei metadati aggiornata recentemente.
mag 10 15:16:42 enrico-fedora systemd[1]: dnf-makecache.service: Succeeded.
mag 10 15:16:42 enrico-fedora systemd[1]: Finished dnf makecache.
mag 10 15:16:42 enrico-fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
mag 10 15:16:42 enrico-fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
mag 10 15:39:49 enrico-fedora systemd-udevd[576]: hidpp_battery_0: Worker [138975] processing SEQNUM=3407 is taking a long time
mag 10 15:39:49 enrico-fedora systemd-udevd[138975]: hidpp_battery_0: Spawned process '/usr/sbin/tlp auto' [138976] is taking longer than 59s to complete
mag 10 15:41:49 enrico-fedora systemd-udevd[576]: hidpp_battery_0: Worker [138975] processing SEQNUM=3407 killed
mag 10 15:41:49 enrico-fedora systemd-udevd[576]: Worker [138975] terminated by signal 9 (KILL)
mag 10 15:41:49 enrico-fedora systemd-udevd[576]: hidpp_battery_0: Worker [138975] failed
HIDPP could be related to Logitech as I see here Linux-Kernel Archive: [PATCH v2 08/15] HID: logitech-hidpp: add support for battery status for the K750 and I have a Logitech trackball. @sonnycardona @zarathustra19 do you have any logitech device attached to your system?
I really don’t know. I don’t even know how to find out if I have it installed or not. To be honest with you, I’m giving up the search for the problem; I’ll live with it while it lasts.
I wish you all the best and I hope you can find the cause of the problem soon.
Thanks for everything, man.
Did anyone try changing to scheduler to see if it helped? In that case, because it’s a CPU hang, no logs are written which made it difficult to debug in the first place.
Hello, I also experience this problem with Fedora MATE 32. I also had it with Fedora MATE 31 before I upgraded. It an happen when opening a video, when playing a game on Wine, or sometimes when opening an application. I think it does not leave logs because the syslog process is not running on close to 100% after I boot again, something which does happen when I have to reboot because of other problems.
Regarding the schedulers, I followed the links but I am not sure what do to to make changes.
$ grep "" /sys/block/*/queue/scheduler
/sys/block/dm-0/queue/scheduler:none
/sys/block/dm-1/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sdb/queue/scheduler:mq-deadline kyber [bfq] none
If I get it right I 'd have to echo to those files to change scheduler but I m not sure how or with what options.
1 Like
These are the relevant bits. You are using the bfq scheduler for these two disks: sda and sdb. To modify them, try:
# does not work if we use sudo echo ...
sudo -i
echo "mq-deadline" > /sys/block/sdb/queue/scheduler
# then verify with:
cat /sys/block/sdb/queue/scheduler
If this helps with the issue, it is possible to make this persist over reboots.
Thanks for the reply. I will try this and see if I get an improvement. Because the bug is intermittent, hence requiring a lot of retries, and time constraints it will take some time.
edit: Actually on early testing I was “able” to freeze my system again. So the scheduler fix doesn’t seem to apply in my case.
I’ve reinstalled the whole system (not because of this bug). The freeze happened again on a brand-new Fedora 32 installation. I’ve not copied my /home or anything else.