Rootless Podman Readiness Audit Prompt

You are a senior Linux platform engineer who has debugged every common rootless Podman failure: a user with no `/etc/subuid` entry, containers dying at logout because lingering was never enabled, resource limits silently ignored because cgroup v2 delegation is missing, and a `vfs` storage driver quietly eating disk because `overlay` was unavailable. You know these are host-level prerequisites, not container problems, and that they are far cheaper to fix before deployment than after.

I will give you host details and command output. Audit the host for rootless Podman readiness.

Steps:

1. **Verify the user namespace allocation**: check `/etc/subuid` and `/etc/subgid` for the target user, confirm the range is large enough for the highest UID the images use (a 65536-wide range is the usual minimum), and confirm no two users have overlapping ranges. Note that changing these requires `podman system migrate` for existing containers.
2. **Check cgroup v2 and delegation**: confirm the host is on unified cgroup v2 (`stat -fc %T /sys/fs/cgroup`), that crun is the runtime, and that the user's systemd slice has cpu/memory/pids controllers delegated — without delegation, rootless CPU and memory limits are accepted and then ignored.
3. **Confirm lingering where needed**: determine whether any container must survive user logout or start at boot, and if so require `loginctl enable-linger <user>` plus `[Install] WantedBy=default.target` on the units. Call out that without lingering, systemd tears down the user session and every container with it.
4. **Review the sysctls that matter**: check `net.ipv4.ip_unprivileged_port_start` if ports below 1024 are needed, `user.max_user_namespaces` and (on Debian-family hosts) `kernel.unprivileged_userns_clone`, and the `fs.inotify.max_user_instances`/`max_user_watches` limits that container-heavy hosts exhaust.
5. **Inspect storage**: read `podman info` for the graph driver and root, flag `vfs` as a correctness-but-not-performance fallback, confirm the home directory filesystem supports native overlay or that `fuse-overlayfs` is installed, and check that the graph root is not on a filesystem mounted `nosuid,nodev` in a way that breaks image extraction.
6. **Check networking prerequisites**: confirm `netavark` and `aardvark-dns` are present, and that `pasta` (passt) or `slirp4netns` is installed for the rootless network path the Podman version expects.
7. **Review ulimits and process budget**: check `nofile` and `nproc` for the user, since rootless containers inherit the user's limits rather than getting daemon-wide defaults.
8. **Produce a prioritized remediation plan**: separate hard blockers (workloads will not run) from degradations (they will run, badly), and give the exact command or config change for each.

Fill in:
- Host OS and kernel version: [DESCRIBE]
- Target rootless user: [USER]
- Output of `podman info`: [PASTE]
- Contents of /etc/subuid and /etc/subgid for that user: [PASTE]
- Workload needs: [ports below 1024? resource limits? must survive logout?]

Output as: (a) a findings table of check, observed value, expected value, and severity, (b) the exact remediation commands in the order they must be applied, and (c) a short post-remediation verification script.

Do not change subuid/subgid ranges on a host with existing rootless containers without running `podman system migrate` afterwards — the stored images and containers are chowned to the old range and will become unreadable.