It might be useful to check if Fedora was really active or not in the time in which the machine was seemingly shut down while losing power → create a case: document the exact times when you do what, have your system up, check out the power percentage, shutdown, wait again e.g. 24 hours, then power up, check the percentage → if the percentage again has lost a lot of power, it might be useful to check the current and the last boot with sudo journalctl -k --boot=0 (current one) and sudo journalctl -k --boot=-1 (last one). It might be also useful to get sudo journalctl --list-boots to have things more comprehensible (theoretically the latter should also contain the relevant information).
If the last boot really ends at the time you shut down, and if the current one started at the time you really started it again after 24 hours, then there is either a very severe bug in the kernel (and I think this is reeeeeeeally unlikely) or no Fedora was active in the time the drain took place: in short, it is then more likely that the battery is damaged or that there is a firmware issue (or some external impact applies), and that the fact that it worked seemingly with Windows was more a coincident, in terms of the issue occurs not always but only sometimes (I have seen that with broken batteries already). If so, you might check out several times with Fedora and Windows: I would in that situation expect that the drain will be at both occasionally.
If the logs of course indicate Fedora was active, then we have to get deeper, but in that case the logs might be also the best way to start to see what is going on at the very time. So they are useful anyway
I see
[code] Nov 03 09:14:55 fedora kernel: thinkpad_acpi: Unknown/reserved multi mode value 0x0000 for type 4, please report this to ``ibm-acpi-devel@lists.sourceforge.net nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ PRIVRING ] Nov 03 09:15:06 fedora kernel: rfkill: input handler disabled Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 122124 [ PRIVRING ] Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: TRAP ch 3 [007fa14000 gst-plugin-scan[2188]] Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 8, format = 37, storage type = 0 Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 0, y = 8, format = 37, storage type = 0 Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: TRAP ch 3 [007fa14000 gst-plugin-scan[2188]] Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 8, format = 37, storage type = 0 Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 0, y = 8, format = 37, storage type = 0 Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: TRAP ch 3 [007fa14000 gst-plugin-scan[2188]] Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 8, format = 37, storage type = 0 Nov 03 09:15:06 fedora kernel: nouveau 0000:05:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 0, y = 8, format = 37, storage type = 0 Nov 03 09:15:07 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 122124 [ PRIVRING ] Nov 03 09:26:37 fedora kernel: rfkill: input handler enabled Nov 03 09:26:38 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ PRIVRING ] Nov 03 09:26:39 fedora kernel: rfkill: input handler disabled Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: TRAP ch 4 [007f9a4000 gst-plugin-scan[3813]] Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 8, format = 37, storage type = 0 Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 0, y = 8, format = 37, storage type = 0 Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: TRAP ch 4 [007f9a4000 gst-plugin-scan[3813]] Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 8, format = 37, storage type = 0 Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 0, y = 8, format = 37, storage type = 0 Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: TRAP ch 4 [007f9a4000 gst-plugin-scan[3813]] Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 8, format = 37, storage type = 0 Nov 03 09:26:39 fedora kernel: nouveau 0000:05:00.0: gr: GPC1/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 0, y = 8, format = 37, storage type = 0 Nov 03 09:27:02 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ PRIVRING ] Nov 03 09:27:02 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 122124 [ PRIVRING ] Nov 03 09:34:04 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ PRIVRING ] Nov 03 09:34:18 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ PRIVRING ] Nov 03 09:34:18 fedora kernel: nouveau 0000:05:00.0: bus: MMIO read of 00000000 FAULT at 122124 [ PRIVRING ] [/code]
Last week I use
halt -p
and only have 1% of battery drain
If I use halt -p in terminal for turn off my laptop I have 1% battery drain.
Please guide me why this is happen.
Is halt -p is OK for turn off ?
NOTES
Note that on many SysV systems halt used to be synonymous to poweroff, i.e. both commands
would equally result in powering the machine off. systemd is more accurate here, and halt
results in halting the machine only (leaving power on), and poweroff is required to
actually power it off.
Therefore, your halt -p command is functionally equivalent to poweroff
