[DevomB]

The battery's ACPI driver wakes an s2idle machine when the charge falls to the firmware's alarm level or goes critical. In v6.18's drivers/acpi/battery.c, acpi_battery_update() calls acpi_pm_wakeup_event(), and the device is a wakeup source from the moment it is added. A laptop asleep in a bag then wakes to the state passphrase prompt with its lid still shut.

At that prompt the power service can't keep its 3% rule:

• It may wait on the suspended state partition, as any program started then can.
• If it doesn't wait, its shutdown asks kryptikd to stop each zone, then runs the system's shutdown, which syncs, stops kryptikd and unmounts. None of that can finish with the partition suspended.

kryptikd already answers the screen lock while the partition is suspended, reading sysfs alone. With this change it also looks at the battery:

• When: every 30 s, from the end of each sleep (woken or refused) until the passphrase is given. A daemon started again at the prompt looks from its start.
• The rule: power.sh's. The fullest of the machine's own batteries (not a mouse's, scope Device; one not present is ignored) at or under 3%, and running down: one says it discharges, or none says anything and no adapter is online.
• The action: seen twice running, it powers off with reboot(2). The zones are not stopped first:
  • they are frozen, and the partition and their volumes have no key;
  • everything was written out before the seal;
  • a sync would wait on the partition for good.
• The count carries across a sleep, so a machine put back to sleep soon after each wake still powers off. It resets once the partition is back.
• A refused power-off is logged once and not retried.

The power service gains sealed(), read with shell builtins alone. While it holds, the service leaves the power-off to kryptikd.

Tests:

• critical_in is held to every case in tools/tests/power.sh that decides power.sh's critical=, so the two readers agree.
• The twice-running count has its own test.
• tools/tests/power.sh runs sealed() against stand-in device-mapper trees, and checks that the loop's power-off waits on it.
• No guest check yet. The suspend suite would need test_power loaded, the battery set to 2% with builtins while sealed, and "Power down" expected after the wake.

docs/design/laptop.md gets a paragraph, "The battery while the state partition waits".

New attack surface: none. The daemon reads /sys/class/power_supply and calls reboot(2), as root, which it already is. No new input from zones or the session reaches it.