先对齐内核与用户态再谈桌面——LinPad OS 装在 iPad 上的前置条件

照着文档装完却停在黑屏，或者桌面进程起来就退出，先别去改桌面配置。LinPad OS 这类把 Linux 用户态搬到 iPad 上的做法，桌面能不能起，取决于四个前提是否同时成立：内核与用户态组件版本匹配、存储空间与文件系统可写、输入输出设备能被系统看见、存在一个可用的最小运行环境。这四项里任何一项没对齐，桌面都会以看似无关的方式失败。可行的顺序是安装前逐条核对，装完先用「能不能进一个可交互 shell」验收，再谈桌面。

判断顺序固定为四步：按仓库声明列前提清单，验内核与 C 库版本及架构一致，验存储挂载可写且空间与 inode 够用，验输入输出设备可枚举且可打开，最后以能进可交互 shell 作为最小通过标准。任一项不通过就先修该项，不要继续装桌面；四项都过而桌面仍失败，问题才可能落在桌面组件自身的依赖与配置上，此时应查桌面日志，而不是回头怀疑设备前提。

把项目文档声明的运行前提逐条抄成清单

先确定项目到底声明了什么，避免按猜测准备环境。提取来源通常是三类文件：仓库根目录与 docs 下的 README、INSTALL、说明页；构建入口，如 Makefile、CMakeLists.txt、build.sh、meson.build；包与镜像描述，如 manifest、control、rootfs 打包脚本。

归档建议只留三类，避免清单失控：硬件、系统版本、权限。每项都要写出处，写到文件名加章节或行号，例如 README 的 Requirements 一节、build.sh 中判断架构的那几行。文档没写到的项，标成「未声明」，不要凭经验补一条当作官方要求。

硬件：机型、芯片、内存下限、是否需要外接键鼠。
系统版本：固件版本、内核版本、所需运行环境（如越狱环境或某个宿主 App 的版本）。
权限：是否需要 root、文件系统是否可写、是否需要额外授权或关闭某项校验。

清单第四列写「验证方式」，必须是能执行的动作，例如「uname -r 的主版本与文档声明一致」「该路径下能 touch 出新文件」，而不是「确认内核正确」这类无法判定的描述。

核对内核版本与用户态组件是否匹配

内核与用户态错配，最典型的表现是二进制根本跑不起来，或者跑到一半缺符号。先在目标环境的 shell 里确认三件事：内核版本、架构、C 库版本。

uname -a
uname -r
uname -m
cat /etc/os-release
ldd `--version`            # glibc 环境
ls /lib/ld-* /lib64/ld-* 2>/dev/null

对照点有三个：uname -m 是否为 aarch64 或 arm64（iPad 上通常如此）、ldd `--version` 报的是 glibc 还是 musl 及其主次版本号、动态链接器的实际路径是否存在。项目提供的 rootfs 或预编译二进制，必须与这三项同时对上。

版本对不上时，常见报错形态可直接对照排查：

文件明明存在却报 No such file or directory，或 bad ELF interpreter：动态链接器路径不存在，多半是 rootfs 与设备架构或发行版族系不一致。
version `GLIBC_2.xx' not found：用户态库版本低于二进制要求，方向是换成匹配的 rootfs，不要在现场硬替换 libc。
Exec format error：架构不对，例如把 x86_64 的包放到 arm64 设备上。
Illegal instruction：编译目标或指令集不匹配，需要回到构建产物确认编译参数。

这些都能用 file 加 ldd 交叉验证：file 看二进制架构，ldd 看依赖能否全部解析，输出里出现 not found 的那一行就是缺的组件。

确认存储空间与文件系统可用

df -h
df -i
findmnt -T /
mount | grep -Ei 'ro,|read-only'

只看三件事：目标分区剩余空间、inode 是否耗尽、挂载是否可写。解包类操作常在最后几步失败，报错多为 No space left on device、Read-only file system、Cannot create symlink、Cannot open: File exists。

空间不足时的处理顺序是：先删上一次中断留下的解包目录和压缩包临时文件，再清包管理缓存（apt-get clean、清空 /var/cache/apt/archives，按发行版替换命令），确认 df -h 与 df -i 两项都回落之后再重试。只清空间不看 inode，遇到大量小文件时仍会在原地失败。

只读要区分原因：是文件系统本身以只读方式挂上，还是上层策略限制。前者可尝试对目标挂载点执行 mount -o remount,rw；后者不要靠 remount 硬顶，先按项目说明确认该路径是否本来就设计为只读。文件系统类型也要记下来（apfs、ext4、f2fs 等），大小写敏感和符号链接支持在不同组合上表现不同，解包脚本带符号链接时最容易在这里出问题。清理临时文件只是让安装走完的止血手段，不要当成优化手段。

确认输入输出设备能被系统看见

设备存在与设备可用要分成两步看：ls 能看到节点，只说明枚举到了；能不能 open 才是可用性。

ls -l /dev/input/
cat /proc/bus/input/devices
dmesg | grep -iE 'input|hid|drm|fb'
ls -l /dev/fb* /dev/dri/ 2>/dev/null
id
ls -l /dev/input/event0

枚举到但打不开，按顺序看三样：节点权限位与所属组（event 节点常见 root:input）、当前用户是否在该组、是否已有进程占用该设备。对应报错分别是 Permission denied、Device or resource busy；节点在但报 No such device，通常是设备重载后节点残留，重新触发枚举再试。

输出侧同理：存在 /dev/fb0 或有 DRM 节点，只说明显示通路被识别；要跑桌面合成器时还要看运行目录（如 XDG_RUNTIME_DIR）是否存在、权限是否正确。iPad 上的外设与显示通路通常由项目自身的一层桥接提供，这些节点是否存在要以项目说明为准；没有对应节点时先别改桌面配置，回到第一份清单确认该机型是否在支持范围内。

用最小可运行目标验收

最小目标只验证一件事：能进一个可交互 shell，并且能读、能写、有回显。装桌面之前必须先通过这一关。

重启进入目标环境，执行 id 与 uname -a，确认身份与内核版本和第 2 节记录一致。
执行 touch /tmp/probe && echo ok > /tmp/probe && cat /tmp/probe，验证写权限与回显；路径换成项目声明的可写目录。
在终端里手动输入几个字符，看是否有即时回显，这一步验证的是输入通路而不是 shell 本身。
执行一次带输出的小命令，例如 ls /，确认输出完整、无截断，命令退出码为 0，终端能正常退出。

通过标准是上述四步全部成功。未通过时回退路径要固定：命令都起不来，回第 2 节查内核与用户态；能执行但写文件失败，回第 3 节查挂载与空间；键盘无回显或设备打不开，回第 4 节查枚举与权限；四项都过而桌面仍起不来，这时才去查桌面组件自身的依赖与日志，不要再回头怀疑设备前提。