Jump to...
redirecting...

Log for Ubuntu 台灣社群

curl > /dev/sda:我是如何做出一套能用 wget | dd 直接寫入硬碟的 Linux 發行版 (★ 100 分)

作者示範了一種極端但可行的安裝方式:在 Unix 的「萬物皆檔案」觀念下,像 /dev/sda 這類區塊裝置也能像一般檔案一樣直接寫入,因此可以把透過 curl 或 wget 取得的磁碟映像檔,直接串流到硬碟,重開機後就換成另一套 OS (作業系統)。在多數採用 EFI (Extensible Firmware Interface,統一可延伸韌體介面) 的機器上,甚至不必額外調整開機選項,韌體就會自動找到新的 EFI 系統分割區。作者最初只是想省下在 Contabo 的 VPS (Virtual Private Server,虛擬私人伺服器) 上為預製映像檔另付物件儲存費用,沒想到一路追下去,變成一系列探討 Linux 開機早期機制的實驗。

文章先用 Raspberry Pi 的傳統燒錄流程當例子,說明這種做法其實只是把既有步驟一路簡化:先下載映像檔、再用 dd 寫入 SD 卡,接著可以改成用 curl 或 wget 直接把資料送進 dd,最後甚至連 dd 都省掉,直接把輸出重新導向到磁碟裝置即可。如果映像檔有壓縮,就串上 gunzip;若要跨機器傳送,也能透過 SSH (Secure Shell,安全殼層協定) 一邊傳、一邊解壓、一邊寫盤。至於可開機映像檔本身,可以先在 VM (Virtual Machine,虛擬機器) 裡安裝好任意系統,再取出 raw 磁碟映像檔,或用 QEMU (開源虛擬化模擬器) 建立;作者使用的 NixOS 也能直接自動產生這類映像檔。

真正的難題出在目標磁碟如果正是目前系統的根分割區,系統就無法先解除掛載它,因為作業系統本身還在上面執行。作者實際嘗試把壓縮後的 NixOS 映像檔直接灌到正在使用的 /dev/sda,結果機器寫到 77.8% 就當機,證明「在自己腳下改寫磁碟」雖然不是完全做不到,但風險極高,也很難期待穩定。較實際的辦法,是先開進不會掛載目標磁碟的救援環境,例如 Linux 安裝媒體或主機商提供的 rescue image;作者就是利用 Contabo 的 Debian 系救援系統,成功把 wget 下載到的映像檔直接寫回 /dev/sda。文章最後也把問題再往前推一步:如果把必要工具全部搬進 RAM (Random Access Memory,隨機存取記憶體),是否就能不靠第二套系統,在原地安全地改寫開機碟。

討論區補上了不少重要但容易被忽略的技術限制。有人指出,Linux 核心其實有 CONFIG_BLK_DEV_WRITE_MOUNTED 這個設定,可禁止對已掛載的區塊裝置直接寫入;也有人提醒,就算先把檔案系統改成唯讀,核心仍可能把快取中的資料回刷到磁碟,讓新舊映像互相污染,因此更穩妥的路線,是進入 initramfs / initrd (開機早期使用的暫存根檔案系統),或用 kexec (直接載入下一個 Linux 核心而不經完整韌體重新啟動) 切到極簡環境後再寫盤。其他留言則提到 rd.break、SysRq 緊急唯讀重掛、pivot_root、先把 LVM (Logical Volume Manager,邏輯磁碟區管理員) 搬進 RAM、或乾脆 netboot 等替代方式;也有人抱怨許多 VPS 供應商不願提供上傳 ISO (光碟映像檔) 或直接改寫開機碟的正式管道,才讓這種「邪門但有效」的技巧特別有吸引力。另有讀者提醒,若 QEMU 建出的映像檔與實體磁碟的磁區大小不同,GPT (GUID Partition Table,全域唯一識別碼分割表) 的對齊也可能出問題。整體來看,大家一方面很欣賞作者把系統安裝流程壓縮到近乎荒謬的工程美感,另一方面也一致認為,這種方法只有在充分理解開機流程、快取行為與磁碟結構時,才值得拿到真機上嘗試。

👥 42 則討論、評論 💬
https://news.ycombinator.com/item?id=47500522
在系統還活著的狀態下重灌系統?
Wine 11 改寫 Linux 在核心層執行 Windows 遊戲的方式,帶來大幅效能提升 (★ 105 分)

Wine 11 被文章定位為近年最重要的一次大改版。自從 Valve 的 Proton(以 Wine 為基礎的 Windows 遊戲相容層)在 2018 年把 Linux 遊戲體驗拉上主流後,Wine 多半是逐步修補;但這次的關鍵在於 NTSYNC(把 Windows NT 同步物件搬進 Linux 核心的機制)。現代遊戲大量仰賴多執行緒協調,過去 Wine 需要頻繁透過 wineserver(Wine 的協調行程)與 RPC(遠端程序呼叫)模擬 Windows 的 mutex、semaphore 與 event,容易造成卡頓與影格節奏不穩。先前的 esync 與 fsync 雖然能繞過部分瓶頸,但本質上仍是權宜作法;NTSYNC 則在 Linux 6.14 之後直接由核心處理同步,讓等待佇列、事件語意與原子操作更貼近 Windows。文章引用的基準測試顯示,某些原本受同步拖累的遊戲在 FPS(每秒影格數)上可出現數倍成長,但也強調不是所有遊戲都會有戲劇性差異;Valve 也已在 SteamOS 3.7.20 beta 預設載入相關模組,後續官方 Proton 跟進後,Steam Deck 使用者可望直接受惠。

另一個重大變化是 WoW64(Windows 32-bit on Windows 64-bit,讓 32 位元程式在 64 位元環境執行)架構終於完成。這代表 64 位元的 Linux 系統不再需要額外安裝 32 位元系統函式庫,也能直接執行 32 位元 Windows 軟體,甚至連 16 位元老程式都顧到,對舊遊戲與懷舊軟體尤其有感。除此之外,Wine 11 也補強 Wayland(Linux 新一代顯示協定)與 X11 的圖形體驗,包括雙向剪貼簿、拖放、舊遊戲低解析度切換;OpenGL 在 X11 上改以 EGL(連接 OpenGL 與顯示系統的介面)為預設後端,Vulkan 也升到 1.4,並加入以 Vulkan Video 驅動的 H.264 硬體解碼。再加上方向盤與飛行搖桿力回饋、藍牙與 BLE(Bluetooth Low Energy,低功耗藍牙)、MIDI(電子樂器數位介面)、ARM64(64 位元 Arm 架構)頁面大小模擬,以及多款遊戲的專屬修正,文章認為這是自 Proton 讓 Linux 遊戲真正可用以來,影響最大的一版 Wine。

在 Hacker News 討論裡,多數人把這次更新視為 Linux 桌面與遊戲生態的重要里程碑,特別期待 NTSYNC 與 WoW64 對老遊戲的幫助,也有人提到 macOS 已有使用者空間版本的 NTSYNC 後端可供嘗試。更有意思的是,不少留言把話題拉高到平台策略:有人認為 Wine 與 Proton 越成熟,越能讓 Linux 成為可行桌面作業系統;但也有人指出,這種成功反而可能降低廠商製作原生 Linux 版本的動機,因為 Win32(Windows 長期沿用的應用程式介面)與 ABI(應用二進位介面)對開發者而言更穩定,甚至連一些已有原生版本的遊戲,透過 Proton 跑 Windows 版都更穩。這讓 Wine 呈現出一種弔詭角色:它一面替 Linux 補上生態缺口,一面也可能把 Windows 介面繼續鞏固成事實標準。

討論串也補上了文章較容易被忽略的技術細節與修正。有人指出,文中把 fsync 描述成「不在 Linux 主線核心」過於簡化,因為相關的 futex_waitv 已在 Linux 5.16 納入;作者則回應,futex2 與 fsync 關係密切但並非完全等同,而且核心先納入機制,不代表一般使用者立刻能從 Wine 受益,真正的轉折還是在 Wine 11 正式採用 NTSYNC 之後。另一個高分觀點則提醒,文內最驚人的效能數字,是拿 NTSYNC 對上未啟用 fsync 的上游 Wine,因此多數已在 Linux 上玩遊戲的人,實際提升通常只會是個位數百分比,少數標題才會有飛躍式差異,甚至偶爾可能略退步。即便如此,整體氣氛仍相當正面,許多人把這視為一種耗時、低調卻極重要的底層工程:它不只讓遊戲更順,也讓從 Windows 轉往 Linux 的過渡更平順。

👥 13 則討論、評論 💬
https://news.ycombinator.com/item?id=47507150
看成Win 11
20 年前有類似的東西,可以直接 linux -> freebsd 的 https://www.daemonology.net/depenguinator/ 這個
https://gist.github.com/kworthington/dee2d9aef818db19c7c90f3a581341b9
之前也有人做過在 vps 上線上換系統的
還不支持 Linux Subsystem Windows 嗎 XDDDD