跳至主要内容

使用 WSL 从源码编译小米路由器青春版 R1CL 带 v2ray 的 LEDE

在使用 Portainer 部署容器时在 glances 看到几乎没流量, 知道又需要走代理了, 然而既然选择了使用 Portainer 这种集成度高的 wrapper 类工具, 就无法避免看不到实际指令只能靠它自动完成, 也就无法自己配置代理, 而且 Portainer 本身也没给出代理配置, 同时也为了以后各种服务不用再重复配置代理, 于是开始考虑路由器级代理.
刚好小米路由器青春版刚被斐讯 K2P 取代而退役, 就顺便编译个 LEDE 加上 v2ray 来做旁路由进行路由器代理吧.

尝试使用 WSL 下 Manjaro 配置依赖

sudo apt-get -y install build-essential asciidoc binutils bzip2 gawk gettext git libncurses5-dev libz-dev patch unzip zlib1g-dev lib32gcc1 libc6-dev-i386 subversion flex uglifyjs git-core gcc-multilib p7zip p7zip-full msmtp libssl-dev texinfo libglib2.0-dev xmlto qemu-utils upx libelf-dev autoconf automake libtool autopoint device-tree-compiler
这堆包, LEDE 官方 README 推荐用的是 Ubuntu, 刚开始看到时就感到不妙, 但本着没必要就不装多一个 WSL 发行版的心态, 先看看 Arch 源里有没有替代包.
前面没有问题, 替代包都有, 遗憾的是进行到 make menuconfig 时开始报错, 缺少包. 懒得再折腾, 老老实实去装 WSL Ubuntu.
期间看到 LxRunOffline 可以灵活管理 WSL, 之后试试看.

编译前配置

根据这里配置好 WSL 下的全局代理, 关键语句摘抄如下.
echo "export ALL_PROXY=\"socks5://127.0.0.1:1080\"" >> ~/.bashrc
echo "export all_proxy=\"socks5://127.0.0.1:1080\"" >> ~/.bashrc
sudo tee -a /etc/apt/apt.conf <<< 'Acquire::http::Proxy "http://127.0.0.1:1080";' > /dev/null
sudo tee -a /etc/apt/apt.conf <<< 'Acquire::https::Proxy "http://127.0.0.1:1080";' > /dev/null
继续根据官方 README, 这次 make menuconfig 后成功进入图形配置界面, 不过面对各选项有点不知所措, 从此处得知关键的配置选项, 摘抄如下.
  • Target System: MediaTed Ralink MIPS
  • Subtarget: MT78x8 based boards
  • Target Profile: Xiaomi MiWiFi Nano
  • Target Images: 勾选 squashfs
再参考这里进入 LuCI 配置, 选自己需要的插件. 启用 v2ray 的选项如图.

生成的 config 存了个 gist.

下载, 编译

然后都是标准流程.
make download -j8 V=s
make -j8 V=s
各命令解释可再次看这里.
第一次用 8 线程编译出错, 第二次用单线程, 成功. 怀疑是 LuCI 插件选太多导致包太大而出错, 调整了一下插件数量直接 10 线程编译, 没问题.

开刷

之后就是进小米路由器青春版的 breed 刷固件了, 这里直接选编译输出里的 squashfs-sysupgrade.bin 后缀文件就可以, 不需要用 initramfs-kernel.bin 后缀的打底.
又因为本人之前在小米官方开发版固件下直接用坊间重置 SSH 密码办法直刷 PandoraBox, 导致 u-boot 分区锁死, 又经历一番探索才成功刷入 breed, 留待下回分解了.

后续

有了自己的 config 文件之后, 后续还可以
薅 Github 羊毛利用 Github Action 自动 CI, 解放本地运算/硬盘资源. 这里就不展开了.

参考链接

​

评论

发表评论

此博客中的热门博文

Syncthing 使用踩坑记录

硬盘缓存解决方案导致 Syncthing 数据库错乱 在某台式上用 Windows Syncthing (SyncTrayzor) 后一段时间后出现类似 这里提到 的 log. 可以看出关键的一句是: panic: leveldb/table: corruption on data-block (pos=0): checksum mismatch, want=0x222c5c3a got=0x6676beb6 [file=004278.ldb] 就是 Syncthing 用来存放同步内容哈希的数据库里某条记录跟实际文件的哈希对不上了。以这条 log 前半段 “panic: leveldb/table: corruption on data-block” 搜索一下可以看到前人的一些讨论. https://github.com/syncthing/syncthing/issues/2734 https://forum.syncthing.net/t/panic-leveldb-table-corruption-on-data-block/2526 https://forum.syncthing.net/t/panic-leveldb-table-possibly-due-to-ssd-caching/2673 我首先看到有人建议先清掉 Syncthing 的数据库文件夹再重启一下让它自动重新建数据库。于是 参考一下文档 找到 Windows 下的数据库文件夹位置。看到唯一那个 index 开头的文件夹，删掉。删掉这个不会丢失用户自定义的设置和同步文件夹设置. 重建 index 根据同步文件夹大小和电脑 CPU 耗时不定，200G & R5 2600 好像用了一个多小时. 重建之后随便加了一些文件测试同步，似乎没有问题. 两三天之后，问题重现. 根据上面查到的讨论开始怀疑是 AMD CPU 带的 StoreMI (用 SSD 给 HDD 加速的软硬件解决方案) 引起问题. 跟着 StoreMI 官方文档 开始把原本融合的两个盘拆开. 此处省略具体操作和电脑迁移数据时间 3 小时. 官方文档已经说得很详细了, 有不明白的, 请看多几遍文档. 之后再没发生类似问题. 由于文件同步的服务基本上都是用计算文件哈...
发表评论
阅读全文

望一眼

收档了. 纵然有深度 Google+ 用户不舍, 趁这最后几天在里面作别, 这时登上去, 还是可以通过各种无法加载出图标的按钮, 只剩下孤零零一条 post 的社群, 来侧面感受 Google+ 服务器那侧 Google 工程师的操作. 面对这种场景, 我仿佛能听到以前深夜路过商业街时, 店主们哧啦哧啦关上卷闸, 把展示柜拖回店里时跟地面的摩擦声. 又像是, 初中的每一次留校值日, 课桌椅摩擦地板发出刺耳响声, 空气中散发着稀释消毒剂蒸发起的气味, 无力的夕阳穿过窗玻璃折射在白墙壁. 世上也难有什么永恒之事, 只是 Google 热衷砍产品线, 才让用户感受到这种频频要跟喜欢用的产品道别的烦恼. 举一个可能已经为人熟知的例子, 典型且黑色幽默. Google 在聊天工具上的节奏, 从 Google Talk, 到 Hangout, 到 Allo, 到 Duo, 需求不断地提, 轮子不断地造, 运营一段时间, 哦, 貌似不太行, 关掉. 你甚至可以预期 Google 下次的 I/O 大会, 也会发布新的聊天工具, “我们又满足了一个 XX 的需求”, blabla. 只能说, 人生苦短, 我用 Telegram. 倒不是说’收档’给我带来如何大的影响, 实际上 Google+ 早在被宣布死亡日期前, 事实上也没有太多用到它的需求. 它在那时候的角色更像是一本用过的旧日记, 承载着很多或精彩或尴尬的回忆, 承载着各种事存在过的印记. 可以这么理解: 从 2013 年 Ingress 游戏开始存在, 到 2019 年 Google+ 宣布倒闭, 6 年间与 Ingress 相关的人事物, 那些值得发帖的, 发活动的, 都在 Google+ 上. 只是近两三年我, 或其他很多人们, 也都已经转向新平台. 显然商业公司不能容许这种白占资源不带来一丝盈利机会的情况发生, 可以说即使决策方换成不是 Google, 关闭的决定, 也几乎是必然. ‘旧日记’最好的状态, 就是让它保持现状, 可以让人需要时回来, 各个社群和圈子的人, 在事情发生的那段时间, 那些音容笑貌, 那些糗事笑料, 完整又立体地, 放在那里, 望一眼, 再望一眼. 是不是, 有点太恋旧了? ​
发表评论
阅读全文