F40 won't shut down

Ask Fedora
,
1

F40 has been running fine on my system for a couple of months now. When I shut my desktop down last night everything was fine.

We had a brief power outage this morning. When the power came back on, the system started up. Now I can’t get it to shut off AND stay off. When I tell it to power off, it goes through the motions. I can hear the fan shut off. Then it starts up again - there is only a second or two of quiet.

I’ve tried shutting down from the menu icon. I’ve tried systemctl poweroff. The system starts up again. I’ve gone through all the power setting I can find (Under Gnome and Plasma). I’ve gone through the system BIOS. I can’t find anything telling the system to restart. Right now, the only way to power off the system is to unplug it.

The journal shows this at one of the reboots:

Oct 24 10:11:42 localhost.localdomain systemd-journald[702]: Received SIGTERM from PID 1 (systemd-shutdow).
Oct 24 10:11:42 localhost.localdomain systemd-journald[702]: Journal stopped
-- Boot f0ab415101d140d698a7f673a57fa28f --
Oct 24 10:12:35 localhost.localdomain kernel: Linux version 6.11.4-201.fc40.x86_64 (mockbuild@49ea9c9b44de4986ad76c1a7822f2cd3) (gcc (GCC) >
Oct 24 10:12:35 localhost.localdomain kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.11.4-201.fc40.x86_64 root=/dev/mapper/fedora_>

I’m out of ideas. Does anyone have any ideas?

2

The power outage may have been coincidental. Does the problem occur if you boot the system with an older kernel?

Edit: Some PCs have an “always on” setting in their BIOS. Another possibility is that the power outage/surge corrupted the firmware somehow. You might try re-flashing your BIOS firmware.

3

The reboot= kernel parameter (GRUB/boot option) sounds like it could affect ACPI poweroffs, but I’m not sure how it might do that or if it might really only apply to rebooting.

If you’re using UEFI, I’d try reboot=efi. If that doesn’t work or you’re using Legacy, reboot=pci (I use UEFI but pci works better). You’ll have to boot, set the boot option (GRUB update/grubby), reboot (so the new option gets applied to next/future boots), then power-off normally from the DE to see if it works.

If manually typing it into GRUB from cold-boot, it applies that session and you can power-off normally from the DE to see if it works.

1 Like
4

interesting… I rebooted with the 6.11.3-200 kernel and the system shut down properly. The 6.11.4-201 has been installed, and working fine, for a few days.

I’ll have to see if I have a copy of the BIOS - the surge protector should have protected the system, but stranger things have happened.

1 Like
5

I am using EFI. I don’t find a reboot= option in any of the files.

6

I entered reboot=efi at the command prompt. Now the newer kernel seems to be shutting down properly.

Many thanks

1 Like
7

If adding reboot=efi solves the problem on your hardware, you can make that change persistent so you don’t have to manually type it each time you boot. Here is the documentation: Working with the GRUB 2 Boot Loader :: Fedora Docs

8

Many thanks

9

In the older days of laptops, some types of problems like this could be fixed by powering down, removing the battery, waiting a while and putting the battery back in and booting up again. Physically removing the battery truly powers down the firmwire and clears up some types of firmware problems.
These days it’s hard to find a laptop with a removable battery outside of unscrewing the back and unplugging the cable.

10

Though I have done so, I’m reluctant to disassemble my desktop unit. I was hoping that leaving it unplugged overnight would have a similar effect.

11

interestingly - the change seems to be “permanent”. I’m wondering if - when I booted to the older kernel - the system updated the file.

1 Like
13

I installed

efivar-39-2.fc40.x86_64 Tools to manage UEFI variables

but when I run “efivar -l” I get:

efivar: error listing variables: Function not implemented

15

UEFI can work on MBR (DOS) partitions. GPT is only required for larger drives (>2TB).

I thought it was stated in an earlier post that the problem was resolved by using (temporarily) an older Linux kernel?

17

Perhaps some firmware implementations have that limitation, but it is not a general requirement.

Excerpted from wikipedia.org – UEFI#Disk_device_compatibility:

In addition to the standard PC disk partition scheme that uses a master boot record (MBR), UEFI also works with the GUID Partition Table (GPT) partitioning scheme, which is free from many of the limitations of MBR. In particular, the MBR limits on the number and size of disk partitions (up to four primary partitions per disk, and up to 2 TB (2 × 240 bytes) per disk) are relaxed.[40] More specifically, GPT allows for a maximum disk and partition size of 8 ZiB (8 × 270 bytes).[41][42]