usermod -u仅修改/etc/passwd中的UID，不更新文件所有权、cron、systemd用户session等，必须执行扫描（find按旧UID定位）、修改（usermod+chown精准修复关键路径）、验证（ssh/cron/systemd）三步闭环。
usermod -u 命令本身只改 /etc/passwd 里的数字，不碰任何文件、不更新 cron、不重建 systemd 用户 session——直接执行完就以为改好了，90% 的人会立刻遇到 ssh 拒绝密钥、crontab 静默失效、systemctl --user 启动失败。
查旧 UID 和新 UID 是否冲突
别信 id username 就完事，它只显示当前值，不检查目标 UID 是否已被占用。
- 查当前 UID：
id -u username - 查新 UID 是否空闲：
getent passwd | awk -F: '$3 == 2001 {print}'（把2001换成你想设的值） - 手动扫
/etc/passwd第三列更可靠：cut -d: -f3 /etc/passwd | sort -n | grep 2001 - 避开
0–999：这些是系统保留范围，硬塞进去可能让dbus或systemd-logind拒绝加载用户 session
改 UID 前必须停干净进程并换 shell
在目标用户自己的终端里跑 usermod -u，命令一返回，shell 就断连——不是卡死，是内核直接回收了那个 UID 的所有资源。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先确认无残留进程：
ps -u username，有输出就得sudo pkill -u username或sudo systemctl stop xxx - 确保用户已登出：检查
loginctl list-users，没出现该用户才算安全 - 操作必须从 root shell 或另一个管理员账户发起，绝对不要
su - username后再执行
chown 必须按旧 UID 扫描，不能只修 /home
sudo chown -R username:username /home/username 是最常见但最危险的 shortcut——它漏掉三个关键位置，改完照样登录失败。
- crontab 文件路径因发行版而异：
Debian/Ubuntu：/var/spool/cron/crontabs/username
RHEL/CentOS：/var/spool/cron/username
归属必须手动chown username:cron（注意组名） - ssh 密钥：
/home/username/.ssh/authorized_keys所有权和600权限缺一不可 - systemd 用户 socket：
/run/user/1000（旧 UID）目录若还存在，说明 user instance 没重建，得loginctl terminate-user username强制清理 - 精准扫描推荐：
find / -xdev -user 1000 -type f -exec chown 2001 {} \; 2>/dev/null（1000是旧 UID，2001是新 UID）
验证时重点看隐性依赖，不是看 id 输出
id username 显示 uid=2001 ≠ 改成功。真正要命的是那些不报错、只静默失效的服务。
- 测试 ssh 登录：
ssh -o LogLevel=DEBUG3 username@localhost，看是否卡在debug3: key_read: invalid format或Authentication refused - 检查 cron 是否真运行：
sudo grep username /var/log/syslog | tail -5，没日志 = crontab 文件归属没修对 - 查 systemd 用户服务：
sudo -u username systemctl --user list-units --state=failed，失败项大概率指向/run/user/1000这类硬编码路径 - 别忽略
/etc/sudoers里用 UID 写死的规则（虽然少见，但某些定制环境存在）
改 UID 不是改一个数字的事，是重映射整个用户上下文。最容易被跳过的，是 loginctl terminate-user 和按旧 UID 全盘扫描那一步——漏掉其中任何一个，问题都会延迟暴露，等你发现时已经混在一堆日志里难定位。
