記一次把舊手機刷成原生 Linux 服務器的完整折騰過程

手頭有一臺閒置很久的樂視第 2 代手機，具體型號是 Le X620。平時放在抽屜裏一直喫灰，剛好最近想搭一臺低功耗的本地服務器跑點服務，就尋思着能不能把這臺舊手機利用起來。

先看下這臺手機的硬件：搭載的是聯發科 MT6797也就是 Helio X20處理器，ARM64 架構，內存大概 3GB，內置存儲的數據分區有 24GB，而且手機自帶屏幕、Wi-Fi、USB 接口和電池。原機系統我之前刷了 MIUI，內核版本是 3.18.22+，之前也已經刷好了 Magisk root 和 TWRP recovery。

網上很多舊手機改服務器的教程，基本都是在 Android 系統裏裝個 Termux，或者在 Termux 裏套一層 chroot 跑 Linux。但說實話，那種方式底層還是拖着一整套龐大的 Android 系統，資源佔用高不說，跑後臺服務也經常被殺。我這次的目標是徹底幹掉 Android，不跑 Android framework 和 Zygote，直接讓 Linux 的 init 作爲 PID 1 啓動，把這臺手機真正變成一臺用 SSH 管理的無界面 Alpine Linux 服務器。

這篇文章就把我從前期查資料、備份分區、踩坑 fastboot 回鎖，到點亮全套手機硬件的全部過程完整記錄一下。全文都是在這臺 Le X620 上實測出來的結論，不同手機硬件差異很大，大家千萬不要直接照搬鏡像硬刷。

一、前期調研：網上有沒有現成的包可以刷？

在動手刷機之前，第一步肯定是先去網上查資料，看看有沒有前人做好的現成鏡像。

我去翻了一圈公開資料，找到了樂視 2在 postmarketOS 和 LineageOS 上的頁面，但仔細一看，那些全是基於高通驍龍 652 平臺的機型比如 X520、X522、X526、X527，跟聯發科 MT6797 的 X620 完全不是一碼事，底層的東西根本不能混刷。

圖1：postmarketOS 項目 logo（圖源：Wikimedia Commons，postmarketOS developer team，CC BY-SA 3.0）

接着我又順着 MT6797 這顆 SoC 去查，發現同系列的幾款設備確實有人做過原生 Linux 移植：

Gemini PDA：用的是下游 3.18.41 內核，USB 網絡可以用，Wi-Fi 部分支持，不過這個移植項目已經歸檔了。
Lenovo K8 Note：基於 MT6797D 和 3.18.60 內核，能啓動原生系統，USB 網絡也正常，但 Wi-Fi 是壞的。
紅米 Note 4：同樣是 MT6797，但在官方頁面上直接標了 Not booting。

圖2：同爲 MT6797 平臺的 Gemini PDA（圖源：Wikimedia Commons，Gareth Halfacree，CC BY-SA 2.0）

圖3：同爲 MT6797 平臺的紅米 Note 4，關於手機頁顯示十核處理器（圖源：Wikimedia Commons，Dqwyy，CC0）

看到這裏心裏就有數了：首先，MT6797 這顆芯片跑原生 Linux 在技術上是絕對可行的；其次，網上找不到成品 Linux 鏡像。而且玩手機移植最忌諱的就是看到同品牌或者同款 CPU就直接拿別人的 boot.img 過來刷，因爲每臺手機的分區佈局、設備樹、供電管理、屏幕和無線配置都不一樣，亂刷必變磚。

既然沒有現成的，那就自己動手豐衣足食。我最終定下來的方案是：保留這臺手機原本就已經驗證穩定的 3.18.22+ 原廠內核、設備樹和底層固件，只把上面的 Android 用戶空間抽掉，自己構建一套 Alpine Linux 3.24.2 ARM64 的根文件系統和啓動配置。

圖4：Alpine Linux logo（圖源：Wikimedia Commons，Alpine Linux Development Team，MIT 許可）

二、刷機前準備：備份比刷機更重要！

在往手機分區裏寫任何東西之前，我先把退路給鋪好了，這一步無論怎麼強調都不爲過：

在手機上打開 USB 調試，連上電腦確認 ADB 授權正常。
把 boot、recovery、system、LK、NVRAM、nvdata、nvcfg、protect、persist、seccfg 這些關鍵分區全部導出來備份到電腦。
實測用 adb reboot recovery 和物理按鍵（電源鍵 + 音量上）都能順利進入 TWRP，確認 TWRP 能正常掛載分區，在後面的所有折騰裏，recovery 分區絕對不動，確保隨時有救磚通道。
去 Alpine 官方鏡像站下載了 Alpine 3.24.2 的官方 ARM64 minirootfs，。

圖5：手機上的 TWRP Recovery 主界面（實拍）

這裏放一下我整理出來的原機關鍵分區對應表：

三、踩了個巨坑：這臺手機的 fastboot 會自動回鎖

按我們平時刷機的習慣，肯定是用 fastboot boot 命令先在內存裏臨時引導一下，看看 Linux 能不能跑起來對吧？

結果就在這裏踩了第一個大坑：我先用 fastboot getvar 確認了手機狀態是 unlocked=yes、secure=no。接着執行 fastboot boot，電腦終端上明明返回了 OKAY 提示成功，但手機那邊既沒有出來 USB 網卡，也連不上 SSH。更嚇人的是，手機重啓後屏幕直接提示非官方系統無法啓動，然後就開始無限循環重啓了！

圖6：fastboot 自動回鎖後，開機提示“非官方系統無法啓動”（實拍）

我趕緊重新進 fastboot 模式一查，發現 bootloader 的狀態居然自己變成了 unlocked=no、secure=yes，回去翻剛抓下來的控制檯輸出才發現，當我執行 fastboot boot 的時候，樂視的 bootloader 竟然輸出了 Fastboot oem devices is unlock -> Start lock flow -> Lock Pass...continue to fastboot——它返回 OKAY 的同時，居然在後臺自己跑了一遍上鎖流程，把手機給重新鎖上了！

我重新執行 oem unlock 恢復解鎖狀態後，試了一下普通的 fastboot reboot，結果它又觸發了一模一樣的自動上鎖！

再次解鎖後，我老老實實用物理按鍵進到 TWRP，把手機裏的診斷日誌（logs/native-diagnostics-20261015-230635/）拉出來看，這才搞明白剛纔發生了什麼：其實第一次測試的時候，原生 Linux 的 BusyBox 已經成功作爲 PID 1 跑起來了，只是當時網絡初始化失敗，240 秒看門狗正常觸發了重啓；結果因爲 fastboot 剛纔偷偷把 bootloader 給鎖了，重啓的時候校驗不過，這才卡死在開機報錯上。

喫一塹長一智，針對這臺 X620，爲了防止燒心，我給 deepseek 立下四條規矩：

絕對不用 fastboot boot。
絕對不用 fastboot reboot。
絕對不用 fastboot continue。
絕對不信 fastboot 返回碼裏的成功提示。

後面所有的刷寫操作，我都改成進 TWRP，在 TWRP 裏用命令寫分區，寫完立刻從分區把數據完整讀回來算一遍 SHA256，覈對無誤後直接用 TWRP 重啓或者在 Linux 裏用 reboot 重啓，再也沒有觸發過自動上鎖的毛病。

四、臨時啓動排障：打通 USB 網卡、聯發科 Wi-Fi 和 SSH

在正式清空 Android 之前，我靠着臨時啓動測試，先把最核心的網絡和遠程連接問題給挨個解決了。期間主要碰到了四個問題：

1. USB 複合設備互相卡死

一開始我想省事，打算在 USB 上同時開啓 RNDIS（USB 網絡）和 FunctionFS（ADB 調試）。結果實測發現，只要 FunctionFS 那邊的服務還沒準備好，整個 USB 複合設備就會被卡死，電腦上什麼都認不出來。解決方法很簡單：我把原生系統下的 ADB 給砍了，改成只開 RNDIS（18d1:4ee3，設置 WCEIS=1）。這樣一插上電腦，Windows 就會自動綁定系統自帶的 Remote NDIS 驅動，手機端固定 IP 爲 192.168.92.1/24，電腦直接通過 USB 就能連上手機。萬一需要用 ADB，進 TWRP 也能用。

2. 聯發科 Wi-Fi 驅動等不到 Android 屬性報錯

在手機上搞 Linux，Wi-Fi 絕對不是簡單裝個 wpa_supplicant 就能連的。這臺 MT6797 的無線網卡需要先跑原廠的 wmt_loader，然後再用 6620_launcher 去加載固件。但我在純 Alpine 下跑的時候，內核一直報 no hif info 錯誤。排查後發現，原廠的 6620_launcher 啓動時會去讀 Android 的 property，而在純 Linux 下根本沒有 Android 的 init 和屬性服務，它就一直在那傻等！爲了不把 Android 那套東西塞回來，我直接用 C 寫了一個很小的動態庫 scripts/mtk-native-properties.c，編譯成沒有任何外部 libc 依賴的 libnativeprops.so，只針對 6620_launcher 設置 LD_PRELOAD，在它讀取屬性時直接返回本機的 chipid 0x6797 和驅動就緒狀態。接着把 /etc/firmware 和 /lib/firmware 軟鏈接指向原廠固件所在的 /system/etc/firmware，只讀掛載 /nvdata，再把 wpa_supplicant 不支持的 -f 參數去掉，Wi-Fi（wlan0）終於順利連上路由器並拿到了 IP！

圖7：終端裏 ip a 顯示 wlan0 已獲取 192.168.0.118（實拍）

3. 連 SSH 卡死，按音量鍵才恢復

網絡通了之後，我第一次連 SSH 時發現終端一直卡着不動，手機看起來就像死機了一樣。結果我隨手按了幾下手機側面的音量鍵，SSH 突然就連上了！原因很蛋疼：老舊的 3.18.22+ 內核在剛開機時，系統隨機數熵池裏的數據不夠，SSH 握手在傻等隨機數生成；我按音量鍵剛好給內核產生了中斷隨機事件。找到原因就好辦了，直接在系統裏裝上官方的 haveged 服務並設爲開機自啓，自動初始化隨機池，以後重啓再也不用去人工按音量鍵了。

4. 插着 USB 關機會進充電模式，一拔線就關機

在測試電源的時候我還發現一個問題：如果手機插着 USB 線執行 Linux 的 poweroff，它會重啓進入 boot_mode=8（也就是內核參數帶 androidboot.mode=charger 的關機充電模式）。在這個模式下，USB 會變成不工作的 MTP 狀態，而且按原廠內核 mt_kpoc_power_off_check() 的邏輯，只要你一拔掉 USB 線，手機就會立刻自動關機；我想往 sysfs 的 boot_mode 裏寫 0 退出去，發現內核裏那個寫函數根本是空的！於是我寫了個 /usr/local/sbin/native-boot-mode 腳本放在開機早期執行：只要檢測到當前是 boot_mode=8，就先在磁盤上記一個標記（防止萬一失敗陷入無限重啓循環），然後自動執行一次正常的 Linux reboot。實測插着電關機後，它進到 mode 8 會自動重啓一次跳回正常的 mode 0，USB 網絡和所有服務全部自動恢復。

五、正式刷入 Alpine Linux 與持久化驗收

臨時啓動把所有核心鏈路都跑通之後，就可以正式幹掉 Android 了。整個安裝過程是在 TWRP 裏完成的，步驟如下：

再次覈對電腦上備份好的原廠 boot、recovery、system 鏡像哈希值和分區大小。
使用兼容舊版 3.18 內核的 ext4 參數，把 system 分區（mmcblk0p36）和 userdata 分區（mmcblk0p38）格式化掉。
把 Alpine 3.24.2 ARM64 的 rootfs 解壓到 system 分區，作爲 Linux 的根目錄 /（解壓出來大概也就 23 MB）。
把 userdata 分區掛載到 /srv，專門用來存服務數據和用戶文件（可用空間約 23.8 GiB）。
把打包好的 16 MiB Linux boot 鏡像寫入 boot 分區（mmcblk0p31）。
寫完之後，把分區內容完整讀回來重新算一遍 SHA256，確認寫入完全正確。
保持 TWRP recovery 分區原樣不動，直接重啓進入 Linux。

開機之後等了一兩分鐘，我按服務器標準做了一輪完整驗收：檢查 PID 1 確實已經是 /sbin/init；USB 網卡（固定 192.168.92.1）和 Wi-Fi 雙路 SSH 都能用固定密鑰連上；8080 端口的靜態網頁返回 200；SFTP 傳文件正常；往 /srv 寫了一個 1 MiB 的測試文件，重啓後再算 SHA256 分毫不差。到這裏，這臺手機就已經是一臺合格的 Linux 小服務器了。