Ruyi 默认不执行需要超级用户权限的操作，故只有在命令失败时才尝试 sudo 提权。而对于 fastboot 来说，刷写过程中对于没有检测到设备的情形，会持续等待。对于没有配置 udev 规则，也不熟悉 udev 的用户，这会导致问题。
事实上在 Ruyi 的命令输出中，已经进行了提示：
Some flashing steps require the use of fastboot, in which case you should
ensure the target device is showing up in fastboot devices output.
Please confirm it yourself before the flashing begins.
Is the device identified by fastboot now? (y/N)
什么意思呢，就是说当设备出现在 fastboot devices 的输出中时，再进行刷写。注意是 fastboot devices 的输出，而不是 sudo fastboot devices 的输出。以及，这个检查并不能用 lsusb 看到 usb 设备来代替。显然，用户很可能输入了 y 但是并不知道自己同意了什么。
基于上述原因，我们需要在文档中添加关于 fastboot 相关的内容，至少应当涵盖基于 th1502 的设备以及基于 k1 或者 m1 的设备，告诉用户如何配置自己的系统，以及刷写前关注 fastboot devices 的输出。
关于 udev 规则，已有的文档中提到的规则：
|
SUBSYSTEM=="usb", ATTR{idVendor}="2345", ATTR{idProduct}=="7654", MODE="0666", GROUP="plugdev" |
将权限提供给了 plugdev 用户组，这对于 Debian/Ubuntu 以及其衍生发行版是有效的，因为这些发行版规则依赖 plugdev 用户组。而对于 Archlinux，其规则依赖 TAG+="uaccess"，systemd-logind 会基于当前登录用户动态下发 ACL，在实践中用户无需任何额外配置就能直接刷写 licheepi 4a。而对于 Fedora 等发行版，同样也不存在 plugdev 用户组，具体情况待考。也就是说文档并不能使用同一种解决方法覆盖所有发行版，支持范围中的各个发行版需要有针对性地编写提示。
基于上述原因，udev 提示不能也不应该由 Ruyi 包管理器给出，更适合由文档给出。
Ruyi 默认不执行需要超级用户权限的操作，故只有在命令失败时才尝试
sudo提权。而对于fastboot来说，刷写过程中对于没有检测到设备的情形，会持续等待。对于没有配置 udev 规则，也不熟悉 udev 的用户，这会导致问题。事实上在 Ruyi 的命令输出中，已经进行了提示：
什么意思呢，就是说当设备出现在
fastboot devices的输出中时，再进行刷写。注意是fastboot devices的输出，而不是sudo fastboot devices的输出。以及，这个检查并不能用lsusb看到 usb 设备来代替。显然，用户很可能输入了y但是并不知道自己同意了什么。基于上述原因，我们需要在文档中添加关于
fastboot相关的内容，至少应当涵盖基于 th1502 的设备以及基于 k1 或者 m1 的设备，告诉用户如何配置自己的系统，以及刷写前关注fastboot devices的输出。关于 udev 规则，已有的文档中提到的规则：
docs/Package-Manager/cases/case4.md
Line 29 in 8d74e93
将权限提供给了 plugdev 用户组，这对于 Debian/Ubuntu 以及其衍生发行版是有效的，因为这些发行版规则依赖 plugdev 用户组。而对于 Archlinux，其规则依赖
TAG+="uaccess"，systemd-logind 会基于当前登录用户动态下发 ACL，在实践中用户无需任何额外配置就能直接刷写 licheepi 4a。而对于 Fedora 等发行版，同样也不存在 plugdev 用户组，具体情况待考。也就是说文档并不能使用同一种解决方法覆盖所有发行版，支持范围中的各个发行版需要有针对性地编写提示。基于上述原因，udev 提示不能也不应该由 Ruyi 包管理器给出，更适合由文档给出。