Skip to content

kuma v0.15.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 21 Aug 20:07
v0.15.0
4aeafd2

Swap was always zram, which is memory, so a kuma machine could sleep but never hibernate. It can now put a swapfile on the disk, point the kernel at it, and say plainly when the machine will refuse.

Added

  • Kuma machines can hibernate. Every machine's swap was zram, which is memory, so there was never anywhere to write a hibernate image. Kuma can now make a swapfile on the root disk and set the resume= and resume_offset= kernel arguments that resume from it.

  • kuma install asks, after the encryption question, and creates the file before it pulls the image. Off unless you say yes. --swap 16G answers early and --swap none declines without being asked. On a disk you chose not to encrypt, the install plan says that hibernating writes the contents of memory to it in the clear.

  • kuma hibernate does the same on a machine that is already running, so this needs no reinstall. It defaults to the size of memory, prints what it would do, and changes nothing without --yes. --off --yes removes the swapfile, its fstab lines and the kernel arguments. The kernel arguments take effect on the next boot.

The file is never resized in place: growing it would move it on the disk, and the kernel would then resume from the wrong place. Change the size by turning it off and on again.

  • kuma doctor grades it, and grades the part that fails silently. If the swapfile and the kernel arguments disagree, a hibernated machine boots fresh and the session is gone with nothing logged. Doctor compares the two and says so. Running kuma hibernate --yes on a machine that already has a usable swapfile repairs exactly that, leaving the file where it is. Machines with no swapfile are not graded, because they promise nothing.

  • Secure Boot machines are told the truth. A kernel that booted with Secure Boot on runs locked down, and a locked-down kernel refuses to hibernate. Kuma can still make the swapfile and set the kernel arguments correctly, and the machine still will not do it. kuma install and kuma hibernate say so before you spend the disk on it, and kuma doctor warns rather than reporting a machine ready that never was. If you want hibernate on such a machine, turn Secure Boot off in firmware; otherwise kuma hibernate --off --yes takes the space back.

  • The swapfile is labelled for SELinux. systemd-sleep can only read a file typed swapfile_t, and the policy's own default for a file under /var is var_t, which it cannot read. A machine with the wrong label has a correct swapfile, correct kernel arguments and active swap, and fails at the moment you ask it to hibernate. There are two labels to get right, not one: the file, and the directory systemd-sleep has to search to reach it. Kuma images declare that path a swapfile and relabel both at boot, and kuma doctor grades both.

Known limits

  • Hibernate does not work under Secure Boot, and that is the kernel's decision rather than kuma's. See above: everything kuma sets up is correct and the kernel still refuses. Turning Secure Boot off in firmware is the only way to have both.
  • Proven in a virtual machine, not on your hardware. A gate installs a machine, hibernates it, boots it again and asks three questions the answer to "did it come up" cannot answer: the kernel's own boot_id, a marker in tmpfs, and whether uptime continued. All three say the same session came back. What that cannot cover is your machine. Lid-close behaviour, firmware that mishandles S4, and drivers that do not survive a suspend vary by hardware, and none of them are things kuma can test for you.
  • Hibernating over ssh is refused, and not by kuma. systemctl hibernate asks logind, which gates it on polkit, whose policy wants an active session; an ssh login is not one and there is no agent to answer the prompt. Hibernate from the desktop, where your session is active.

Static x86_64 binary, no runtime dependencies.

$ curl -LO https://github.com/Letdown2491/kuma-linux/releases/download/v0.15.0/kuma-x86_64-unknown-linux-musl
$ chmod +x kuma-x86_64-unknown-linux-musl && sudo mv kuma-x86_64-unknown-linux-musl /usr/local/bin/kuma

Verify it came from this workflow:

$ cosign verify-blob \
    --bundle kuma-x86_64-unknown-linux-musl.bundle \
    --certificate-identity-regexp '^https://github.com/Letdown2491/kuma-linux/' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    kuma-x86_64-unknown-linux-musl

Built from 4aeafd2d0bf871ab401df2a7893de5794cbe66f9.

Assets 8
Loading