docs: add moto g(50) 5G (saipan / XT2149-1, MT6833) to the non-GKI supported devices

[tingao]

Adds the moto g(50) 5G (saipan / XT2149-1, MT6833) to the non-GKI table.

Column	Value
Model	XT2149-1
Android / ROM	Android 12, stock Motorola
Baseband / Build	S1RSS32.38-20-7-16
Kernel	4.14.186
Root	KernelSU-Next v3.4.0
Kernel source	https://github.com/tingao/saipan-droidspaces-kernel
Download	https://github.com/tingao/saipan-droidspaces-kernel/releases/download/v1.1.0/boot-saipan-ksu-cgroupv2-mem.img
Droidspaces mode	Daemon
Status	Working

Verified on the device

vendor modules        17 of 17 load, Wi-Fi, Bluetooth, touch, fingerprint, GPS, FM, sensors
root                  KernelSU-Next, su -c id -> uid=0 context=u:r:ksu:s0
SELinux               Enforcing
Droidspaces           v6.5.5, Debian 13 trixie container, systemd as PID 1
cgroup                container on cgroup v2, force_cgroupv1=0
cgroup isolation      25 of 25 container processes under /sys/fs/cgroup/droidspaces/bagda
Docker in container   Engine 29.8.1, overlay2, systemd cgroup driver, hello-world rc=0
BPF_CGROUP_DEVICE     attached by runc: prog_cnt=1, attach_flags=0x2 (BPF_F_ALLOW_MULTI)
release string        4.14.186+, byte-identical to the stock vermagic

Notes worth putting in the table, and here

• Only the boot partition is replaced (fastboot flash boot). Nothing touches dtbo, vbmeta or super.
• Two non-default settings, both already in your troubleshooting docs: --privileged=noseccomp (the Adaptive Seccomp Shield returns EPERM to the syscalls containerd's shim needs), and a systemd drop-in replacing dockerd -H fd:// with -H unix:///var/run/docker.sock, because socket activation failed with no sockets found via socket activation. --force-cgroupv1 is no longer one of them, since the device-cgroup BPF backport removed the reason for it. On v2, cgroup-parent also has to come out of daemon.json, or dockerd refuses to start.
• If you want a memory cap, set memory_limit=. Note it writes memory.max only, so add swap or zram defeats it. That is in docs/CGROUP-V2.md.
• This device needs the symbol-CRC mismatch tolerated. Its 17 prebuilt modules in /vendor/lib/modules were built by Motorola from branch android-12-release-s1rs32.38-20-7-16, and the only branch published for that train is ...-20-9. Building -20-9 with the completely unmodified shipped config still produces different CRCs for symbols whose headers moved, so check_version() rejects every module and Wi-Fi, Bluetooth, touch, fingerprint and GPS all vanish while the kernel still boots. The published kernel keeps CONFIG_MODVERSIONS=y (so vermagic stays byte-identical) and warns instead of rejecting. Written up in docs/KERNEL-NOTES.md.
• SYSVIPC is deliberately off. IPC_NS only depends on (SYSVIPC || POSIX_MQUEUE), so POSIX_MQUEUE satisfies it, and SYSVIPC inserts fields into struct task_struct ahead of fs/files/nsproxy/signal/sighand, shifting offsets the prebuilt modules compiled against. That is silent corruption rather than a clean failure, so it is worth flagging for anyone else doing an MTK 4.14 port.
• GPU acceleration is untested on this device, so the column says so.
• Tested against stock Android 12 S1RSS32.38-20-7-16 on an opencl retail unit. Other builds untested.

I have entries for the Galaxy S8+ (dream2lte) and Galaxy S21 (o1q) in this table already; this is the third handset of mine running Droidspaces as a container server, and the first MediaTek one.

[ravindu644]

• on cgroup v2 runc must use BPF for device rules and 4.14 has no BPF_CGROUP_DEVICE prog-query

You can fix this by using something like this:

Kernels-by-ravindu644/samsung_kernel_exynos9820_extremerom@98d18e2

[tingao]

Ran it, updating with what happened on hardware.

• With that in, --force-cgroupv1 is unnecessary. The container runs on cgroup v2 now. Your docs were right that v1+force has no isolation — that is exactly why a cap never covered anything.
• Two things in Droidspaces you may want to look at. ds_oom_protect()'s -1000 is inherited by the whole container tree, and mm/oom_kill.c panics unconditionally when an OOM finds no victim (panic_on_oom is 0 here) — that is how my handset went down. And memory_limit= writes memory.max but not memory.swap.max, so zram defeats it.
• Your patch 02 is load-bearing on this device. Android mounts /dev/cpuset with noprefix, so cpuset.cpus and cpuset.mems did not exist at all. Applied verbatim, fixed. 01 doesn't apply (or I couldn't figure out how) no qtaguid source or config in this tree.
• Minor: ds_cgroup_v2_usable() has no callers

Details and measurements in the repo. Thanks again @ravindu644 — the pointer to 98d18e2a is what started this.