跳至主要内容

树莓派 3b+ 使用 SSD 作为系统根目录记录

树莓派 4b 最近发售了, 想看看各方面准确参数, 查到 I/O 速度时看到这篇颇为详细的评测, 里面提到虽然树莓派 4b 也还未能直接完全从 SSD/U 盘启动, 但可以通过修改类似”引导文件”的方法指定系统根目录(即是 / 目录)到外置储存.
评测结果显示, 即使对于 3b+, 用 SSD 做系统盘也要比鹌鹑的 TF 卡快上约 2~4 倍. 正好有个神船 Z7M-KP5GZ 上拆下来的闲置群联 OEM 128G SSD, 虽然 3b+ USB 口实际最高传输速度只有约 25MB/s, 但水桶中最短的木板始终是 TF 卡, 而且现在转移了, 以后升级 4b 也能插上稍微改改就用, 所以感觉还是很值得一搞的, 于是开始动手.
题外话, 至于用 U 盘做系统盘, 评测结论是, 慢得要死, 别搞.
具体步骤直接一步步跟着他的教程走就好, 这里只提一些教程中遗漏的点, 和我踩到的坑.
再次提醒: 如上文提到, 这方法并不能让系统完全脱离 TF 卡启动.
不过反正空出来的 TF 卡空间挂载一下也能继续用嘛.

准备 SSD 阶段

无

转移文件阶段

这句的 rsync 参数可以加上 hP 来显示进度, 毕竟要复制好一会儿, 有个进度比较有底.
sudo rsync -avx / /media/newdrive
最后变成:
sudo rsync -avxhP / /media/newdrive

修改启动参数阶段

这句
  1. Paste the following text at the end of the first (and likely only) line of cmdline.txt.
root=/dev/sda1 rootfstype=ext4 rootwait
不要粘贴, 粘贴了会重复, 直接修改已经存在的 root= 值就好了.
稍微注意下 rootfstype 类型要跟 SSD 的实际文件系统类型对上, 不过如果跟着该文前面步骤的话, 就已经将整个 SSD 格式化成 ext4 了.
同时, root= 的值写成内核名称 /dev/sdXY 也是不太稳的做法, 随着外置设备的插拔, 这里 X 和 Y 的值很可能发生变化, 比较稳应该是用 LABEL 和 PARTUUID 来定位分区. (坑的是树莓派官方文档都没有介绍 root= 的额外写法.)

用 LABEL

先看看 SSD 上系统所在的分区内核名称.
sudo fdisk -l
这里假设分区内核名称是 /dev/sda1.
给分区加个 LABEL.
sudo e2label /dev/sda1 ssdsys
最后在 /boot/cmdline.txt 写上
root=LABEL=ssdsys

用 PARTUUID

用 lsblk 根据分区内核名称看 PARTUUID.
sudo lsblk -f
复制粘贴进 /boot/cmdline.txt.
root=PARTUUID=aaecbf2a-35e2-4b27-8b56-a8f5f3xxxxxx

修改 fstab

那篇教程让人改完 /boot/cmdline.txt 就算完了, 但这里明显还应该修改复制之后文件系统的 /etc/fstab, 因为此时这个 fstab 还会跑去挂载默认的 LABEL=writable 为系统根目录. 不改的话除了会造成非常让人混乱的挂载结构, 还会导致实际上迁移不成功.
首先在当前系统 /mnt 下新建个目录准备挂载复制后的文件系统. 这里假设分区内核名称和 UUID 与上文保持一致.
sudo mkdir /mnt/ssdfs
挂载分区.
sudo mount /dev/sda1 /mnt/ssdfs
改复制后系统的 fstab. (这里假设你已经装了 vim.)
sudo vim /mnt/ssdfs/etc/fstab
如果之前没改过什么的话, 打开后大概会是这样子.
LABEL=writable     /               ext4  defaults,noatime  0  0
LABEL=system-boot  /boot/firmware  vfat  defaults          0  1
改完后.
LABEL=ssdsys       /               ext4  defaults,noatime  0  0
LABEL=system-boot  /boot/firmware  vfat  defaults          0  1
演示起见, 加上 UUID 写法.
UUID=aaecbf2a-35e2-4b27-8b56-a8f5f3xxxxxx  /  ext4  defaults,noatime  0  0
LABEL=system-boot  /boot/firmware  vfat  defaults          0  1
想的话也可以把现在的 TF 卡分区挂载回来, 这个随意. 比如挂载去 /mnt/tffs(自行新建目录).
LABEL=ssdsys       /               ext4  defaults,noatime  0  0
LABEL=system-boot  /boot/firmware  vfat  defaults          0  1
LABEL=writable     /mnt/tffs       ext4  defaults,noatime  0  0
最后保存, 重启 sudo reboot, 完事.
觉得 TF 卡上旧系统碍事的可以参考 ArchWiki 的 Full system backup with tar 做个压缩备份扔一边后删掉.

参考链接

​

评论

发表评论

此博客中的热门博文

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 小时. 官方文档已经说得很详细了, 有不明白的, 请看多几遍文档. 之后再没发生类似问题. 由于文件同步的服务基本上都是用计算文件哈...
发表评论
阅读全文

使用 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 ...
发表评论
阅读全文

望一眼

收档了. 纵然有深度 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, 关闭的决定, 也几乎是必然. ‘旧日记’最好的状态, 就是让它保持现状, 可以让人需要时回来, 各个社群和圈子的人, 在事情发生的那段时间, 那些音容笑貌, 那些糗事笑料, 完整又立体地, 放在那里, 望一眼, 再望一眼. 是不是, 有点太恋旧了? ​
发表评论
阅读全文