Исправлено
-
install.shбольше не падает на свежем OpenWrt 25.12.5 при установке
entware-сборки Xray. Обнаружено вживую (GitHub issue #1) и
воспроизведено на реальном роутере (Netis N6, свежепрошитый на
OpenWrt 25.12.5): текущая версия установщика xkeen (Skrill0/XKeen)
сама регистрирует фиктивный пакетxray_sпрямо в статус-базе opkg —
чтобы отслеживать файлы, которые сама же записала (бинарник xray, его
конфиг-шаблоны, geoip/geosite.dat, логи). На OpenWrtxray_s
никогда не был настоящим, скачиваемым пакетом Entware, но opkg об
этом не знает: обычныйopkg install xray-coreкорректно отказывает
из-за конфликта на/opt/sbin/xray(«уже предоставлен пакетом
xray_s») — так же, как отказал бы для двух по-настоящему
конфликтующих пакетов.Пробовал сначала удалять
xray_s— тот же приём, что уже
используется веткой для KeeneticOS чуть выше по коду для похожего,
но другого конфликта — подтверждено вживую, что это неверный ход
именно здесь:opkg removeудаляет все пути из списка файлов этого
пакета, включая собственный каталог шаблонов xkeen
/opt/etc/xray/configs, который ничто дальше по скрипту не
восстанавливает.opkg install --force-overwrite xray-coreвместо
этого просто отдаёт настоящим файлам xray-core тот один путь, на
который претендуют оба, не трогая ни статус-записьxray_s, ни что-либо
ещё, что она заявляет — подтверждено вживую, что каталог шаблонов
остаётся нетронутым, а Xray после этого запускается и реально
маршрутизирует трафик.Попутно найден и исправлен второй, независимый баг устойчивости:
интерактивные запросы пароля (xkeen-UI, панель SmartRoute) могли
уронить всю установку подset -eu, еслиinstall.shзапущен не из
живого терминала (например,ssh роутер 'sh install.sh'— реальный
сценарий, не только особенность тестового стенда): проверка
[ -r /dev/tty ]может пройти, а сама попытка открыть/dev/ttyдля
read— упасть.Проверено вживую end-to-end: чистая установка на OpenWrt 25.12.5
проходит все 6 шагов,check.sh— везде [OK], реальная
подписка/профиль/маршрутизация работают.