On 11/15/20 5:23 AM, Roger Heflin wrote:
Does the kernel post any messages?
nope
you might try removing quiet and see if anything shows up at all,
those^ results are withOUT 'quiet' ... specifically, WITH 'try-some-massively-overkill-debugging-first', rd.systemd.show_status=1 rd.shell=1 rd.auto=1 rd.udev.log_priority=debug rd.debug=1 rd.break systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on systemd.log_level=debug debug showopts noquiet print_fatal_signals=1 loglevel=8 initcall_debug and serial-console enabled/monitored.
if nothing at all does
nope. complete 'radio silence'. not a peep after selecting the grub menu entry after a soft-reboot.
then something must be broken really early which would likely make it a firmware issue.
likely. tho, i'm not entirely clear on what could be getting borked in a soft-reboot case that's NOT an issue in the hard-reboot case. and doesn't seem to appear as a problem in the running environment.
There are options you can specify on the kernel line that will force a hard/cold boot when you do a reboot, and setting that option is probably the easiest solution. I think it is boot=cold but at the moment the machine I have to set that on to get it to work on reboots is off so I cannot double check.
here, https://www.kernel.org/doc/html/v5.8/admin-guide/kernel-parameters.html i see only reboot= not boot= I've already tried any/all combinations of 'reboot=' options. I've also tried the usual assortment of acpi= options ; to no avail. I can't get it to FAIL to RE-boot; in all soft cases, e.g. 'shutdown -r now', I _do_ get a reboot, back to the grub menu ... and it's there, and only there, that it freezes / goes silent on soft-reboot.
A bios update might fix it, but if the boot=cold does it, then I would just set that. The option is I believe designed for this sort of issue.
BIOS is latest available; which _is_ a bit old. I've cleared/reflashed ... no effect. (Re)booting the machine with different OSs (Win10, Ubu20, OpensuseTW) all work without problem; both in the soft- and hard-reboot cases. So, here, it's Fedora-specific; It's 'local' to my F32 install on this machine; elusive, atm :-/ If I can just manage to get _some_ sort of useful logging at that stage ... _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx