舊 Kindle 越獄後可變 Linux 端點，但先計清安全與維護成本

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-04

一名 XDA Developers 作者把已停止支援的 2015 年 Kindle Paperwhite 3 越獄，取得裝置內建 Linux 的 root 權限後，讓它運行 KOReader、Alpine Linux chroot，亦曾改作 Home Assistant 觸控面板。這為閒置電子書閱讀器提供了再利用方向：E Ink 螢幕適合長時間顯示文字與簡單狀態，舊機亦有 Wi‑Fi、前置燈和觸控功能。不過，這不是把舊 Kindle 變成安全、通用的平板；原裝安全更新已終止，而改裝的可行性高度取決於型號與韌體版本。

最重要的取捨在於，停止更新令越獄漏洞較難被廠商封堵，卻也意味裝置無法再取得後續安全修補。若 Kindle 仍連接家居 Wi‑Fi、登入帳戶或接觸 Home Assistant 等內部服務，使用者應把它視為舊式網絡端點處理，而非一件「冇嘢輸」的玩具。對想重用舊機的讀者而言，較有價值的問題不是能否成功開機，而是能否在限制網絡權限、保留復原方法和持續檢查日誌後，仍令它承擔一項足夠簡單的工作。

凍結韌體令越獄較穩定，亦固定了風險

作者所用的 Paperwhite 3 已停留在 5.16.2.1.1 韌體；他指 Amazon 在 2023 年 8 月推出 5.16.3 後，較舊 Kindle 不再獲更新。作者又引述 Amazon 自 2021 年起的政策：Kindle 在官方商店最後出售後至少四年可獲安全更新。對一般閱讀用途，支援期結束代表裝置長期暴露在未修補的風險下；對改裝者而言，韌體不再變動則令現有越獄方法不會因 OTA 更新被即時堵上。

這種穩定不應被誤解為相容性保證。作者提到，較新的瀏覽器式越獄 Véra 只適用於指定型號及韌體上限；即使同屬 Kindle，能否使用某一工具亦不能由機齡推斷。因此，任何重現工作都應以「設定內顯示的 Device Info 韌體版本」作第一個核對點，再對照工具項目的受支援清單。未確認版本前，不宜下載來歷不明的越獄檔、隨意降級，或把涉及登入資料的裝置直接接上家居主網絡。

作者特別澄清，Kindle 越獄通常不是把另一套 Linux 刷入裝置。Kindle 本來已使用 Linux；越獄的核心是打開原有系統的 root 存取權。以其個案為例，他透過 KUAL 啟動自製軟件，再以 USBNetwork 把 USB 線變成網絡連線，設定 SSH 公鑰後才取得 root shell。這條路徑有一個實務優點：先透過有線 SSH 清點系統、備份設定和驗證權限，毋須一開始便把管理介面暴露於 Wi‑Fi。

硬件仍可用，但只適合單一、低負載角色

作者讀取到的裝置資料顯示，這部 Paperwhite 3 採用單核心、約 1GHz 的 ARM Cortex-A9，RAM 約 502MB，原裝介面閒置時約有 213MB 可用；可用使用者儲存空間為 3.0GB，系統分區已使用九成以上。其 Linux 3.0.35-lab126 kernel 雖在 2023 年重新編譯，版本源頭仍很舊。這組條件足以處理文字、簡單畫面及低頻率控制，卻不適合要求即時回應、瀏覽大量現代網頁或同時跑多個 server 的工作。

在 root shell 下，作者以 Kindle 內部的 LIPC 訊息機制讀取電量和調整前置燈，並使用 eips 直接在 E Ink 畫面繪製文字。這些例子說明改裝後可直接控制哪些基本硬件，卻不等於可安全地把任何 Linux 軟件搬進去。較可重現的次序，是先在 USB 網絡下確認 SSH、公鑰登入和基本硬件指令，再逐一測試顯示、休眠和耗電；每一步保留原來設定和可回復的檔案，出問題時才不會連閱讀器原有用途也一併失去。

對閱讀需求而言，KOReader 是較務實的起點。作者稱它對 EPUB、PDF 及漫畫的處理較 Amazon 原生閱讀器靈活，並可經 Wi‑Fi 更新；其裝置曾由 2025 年 12 月 nightly 更新至 2026.07.2 穩定版。不過，該次更新留下 84.2MB 安裝包，在只有數 GB 空間的舊機上並不輕。實際部署時，應先量度剩餘空間、確認更新檔能否清理，並將大型書庫、下載檔與系統用途分開規劃，否則「獲得較新軟件」很快會換來儲存空間不足。

Alpine 與智能家居面板：可運行不代表可長用

作者亦測試 alpine_kindle 的 Alpine Linux chroot；該項目列出 Paperwhite 3 為唯一已測試裝置。2GB 映像檔令其可用空間由 2.4GB 降至約 425MB，雖可進入 shell，並見到 Python 3.7.4 和 Chromium，但映像檔是 2019 年 8 月的開發快照。由於 Alpine 已輪換套件簽署金鑰，套件庫出現 UNTRUSTED 簽章錯誤，無法正常安裝新軟件；其更新器甚至曾刪掉可用映像檔、重建相同舊版本，最後僅餘 39.6MB 空間。

這個結果為 DIY 選型劃出界線：chroot 成功啟動只是驗證概念，未必構成可維護的平台。作者指出，16GB 或以上儲存的較新 Kindle 較能容納 2GB 映像檔與書庫，但儲存空間不會改善舊處理器的效能，也不會自動解決過期套件與安全問題。若目標是長期運行服務，應避免把它放在這類未獲修補的閱讀器上；若只是探索 Linux 環境，應把實驗與日常家居控制分開，並預先準備移除映像檔及還原空間的方案。

作者較看好的用途是 Home Assistant 牆上面板：他使用 1RandomDev 的 kindle-smarthome-dashboard 分支，讓 Kindle 保持連線，按下畫面按鈕可切換燈具，Home Assistant 的狀態改變亦可反映到 E Ink 螢幕。這與定時載入 dashboard 截圖的方案不同，但代價是架構更複雜。上游項目原本只支援 Paperwhite 2 的 1024×758 螢幕；作者須為 Paperwhite 3 的 1072×1448 解像度重設橫向版面、放大字距，並改用 LIPC 前置燈控制，因為不同型號的底層控制路徑不同。

面板同樣暴露了「服務正在運行」和「服務可用」之間的差距。作者需要一個小型 Node.js proxy，把 Kindle 的舊 WebSocket 支援轉換成 Home Assistant 可用的連線，並把它放在與 Home Assistant 虛擬機同主機的 Proxmox LXC。雖然 systemd 曾顯示服務已運行四日，實際上卻受 Node 20 要求啟用內建 WebSocket client、Home Assistant IP 變更、存取 token 失效，以及 Kindle 與 proxy token 不一致等問題影響。對照日誌、驗證每一段連線和憑證，會比只看服務狀態更可靠。

此外，持續連線令 Kindle 無法休眠，電池消耗加快。上游方案建議以硬件改裝直接向電池端子供電，作者亦提到長期插上充電器可行；兩者均不應草率處理。若要用作固定面板，較審慎的做法是先以原裝充電方式短期測試發熱、斷線後復連與畫面殘影，再決定是否常設。涉及打開機身、改接電源或電池端子的工作有安全風險，且來源未提供適用於各型號的完整步驟，沒有相應經驗者不宜照做。

對舊 Kindle 用戶和 Home Assistant DIY 玩家來說，這個個案的價值在於展示一條可分階段驗證的再利用路線：先核對型號與韌體，再在有線環境取得 root、評估空間與耗電，最後才選 KOReader 或只讀／低權限的家居顯示用途。日後較值得觀察的，是社群會否為更多型號維護兼容工具、較新的可用環境及清晰的復原文件；在此以前，把停止安全更新的 Kindle 放到受限制網絡、避免承載敏感憑證，會是比追求更多功能更應優先處理的一環。