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 全盘扫描那一步——漏掉其中任何一个，问题都会延迟暴露，等你发现时已经混在一堆日志里难定位。