The Lost Pieces

簡略的紀錄安裝的步驟： 用 UEFI 模式安裝 ESXi 6.7 從ESXi的控制面板刪除安裝時建立的 datastore 用 Ubuntu Live 環境中的 gparted 先取消 esp 分割區的 flag，建立一個新的 fat32 分割區(至少10MB，做為新的 EFI系統分割區；VMWare原先給不到4MB，無法裝下grub)並關閉 gparted 複製原本 esp 分割區的內容到新建的分割區，然後再用 gparted 將新的分割區設定成 esp 分割區。(原本的esp分割區筆者沒有刪除，作為備份；刪掉應不影響。) 安裝/還原 Ubuntu，並預留 datastore 要用的空間 用 Gparted 建立未格式化的空分割區給 datastore 使用，並記下建立完成後的分割區編號 用 gdisk 將未格式化的空分割區 type guid 改成 fb00 也就是 VMWare VMFS type 開機進 ESXi (透過 UEFI boot menu而非GRUB，此時還不能偵測) 開啟 ESXi ssh連線 ssh 連到 ESXi ls /vmfs/devices/disks  可以找到(可能為)vml.開頭的硬碟硬碟名稱 vmkfstools -C vmfs6 -S datastore名稱 /vmfs/devices/disks/ vml.硬碟名稱 : 分割區編號 從 ESXi 的網頁控制面板可以看到 datastore 已經生出來了 開機進 ubuntu sudo lsblk | grep efi  找到掛載 /boot/efi 的裝置代號 sudo blkid | grep 裝置代號 找到 EFI系統分割區的 uuid (長的會像 XXXX-XXXX) 編輯 /etc/grub.d/40_custom，加入 menuentry 'VMWare ESXi' {   insmod part_gpt   insmod fat   insmod chain   search --no-floppy --fs-uuid --set=root  EFI 系統分割區的 uuid   chainloader /EFI/VMware/safebt64.efi } sudo update-gr

前言 廢話 近期比較常玩 Bang Dream等音樂遊戲，常常會因為 Xperia Z5 的熱情導致打不到十分鐘就 FPS 狂降，甚至偶爾還會熱到畫面凍結然後譜面加速(汗 的程度，嚴重影響 肝 遊戲體驗。 看到有實況主拿著 Zenfone 3 的S625 連打一小時以上+實況都沒有任何障礙，因此試著手動將系統的 thermal-engine.conf 溫控條的更加激進，調整後半個多小時都沒遇到不順暢的情況。雖然邊錄影邊打還是會過熱，不過只拿來打打活動非常滿意。 軟硬體 拍賣撿的 Sony Xperia Z5 Qcom Snapdragon 810(4x1.5 GHz Cortex-A53 & 4x2.0 GHz Cortex-A57) LineageOS 14.1 20180617-NIGHTLY-sumire 修改前有安裝 FSC™+ 2.2 MOD Bang Dream!GBP 台+日板、 MLTD 修改方向 在 悲慘的 遊戲過程中，晶片的溫度約在 60 度左右，約超過 59 度手機會開始將 A57 的所有核心關閉且將 A53 小幅度降頻，調度的瞬間畫面會有明顯的延遲；溫度降低後系統會再度把 A57 核心打開，溫度高速上升後再度關閉核心，不斷反覆。拿小電風扇直吹手機背面也只是提高 A57 核心啟動的時間，治標不治本，耗電又勞神。 既然 Zenfone 3 用 Octa-core 2.0 GHz Cortex-A53 玩起來也很順暢，那一開始就把耗電又噴火的 A57 核心關掉應該就能解決問題；因此從原本安裝的 MOD 中將 thermal-engine.conf 拿出來，修改關於 cluster 開關和頻率的設定，再將修改後的檔案放回該 MOD 的壓縮黨中安裝近手機。 由於本來 MOD 作者定義的溫度-限制非常詳細，會不斷導致系統拉高頻率，這邊改成簡單粗暴但有效的限制方式： 42 度以下不限制 42 度以上打開兩個 A57，A53 以 1.5Ghz、A57 以 1.3Ghz 運作，38度解除限制 沒在玩遊戲時安裝軟體和外出使用時仍然可以利用到 A57 的效能 48 度以上 A57 全關，A53 小降到 1.4Ghz，42度解除 遊戲啟動後一陣子很容易就達到這個溫度，因為遊戲用 A53 足以流暢執行，此時直接關閉所

因為家裡需要一台文書機，於是將目前作為檔案伺服器的老 i3 取出硬碟裝上 SSD 跑 Windows；需求只有瀏覽網頁和閱讀少量的文件、且考量到出保固的方便程度，就用約 1.2k 購入了這顆硬碟。 不同於以前購入的 Arc 100，跟記憶卡一樣簡單的包裝： 意外的不太像塑膠殼，摸起來有粗糙的金屬感覺： 效能測試： Ubuntu 16.04 LTS 安裝 Windows 10 1709 後忘記關閉防毒軟體(Kaspersky Free)的測試： 效能比想像中(官網標示寫入約320MB/s)的高，目前沒有遇到任何嚴重的問題。

在購入SSD給舊電腦用的同時購入了這款外接盒存取原本的硬碟，順手簡單開箱。 盒子外觀： 打開盒套和白色盒子，可以看到外接盒本體和保固卡、保固延長三個月說明： 盒內其他內容物：立架、很粗勇（直徑約 6mm）的 USB 3.1(?) Type-B 轉 Type-A 連接線、12V2A電源供應器、螺絲包（裝完後還剩下一個黑色螺絲）、螺絲起子(如果機身設計個可以把這個起子塞進去的地方就可以隨地拆換了，不然好像沒太大用處...囧) 髮絲紋本體，內附乾燥劑包一枚。安裝最後鎖上外接盒外側兩顆時孔位公差稍大且蓋子未完全密合，並非很好裝；但仍可順利安裝使用。 以準備使用、即將四歲的 Hitachi DT01ACA100 (1TB、SATA6G)，已經裝了許多資料的情況下做極端不嚴謹的效能測試（作業系統為 Windows 10 1709、USAP、USB3.0，電腦為DELL Inspiron 15R 7520），由於不方便使用電腦連接做對照故僅供參考： 目前使用上還算順利，裝置從作業系統退出後外接盒也會自動關閉硬碟，變壓器溫度僅微溫；原本裝在 JONSBO C2 中噪音很大且容易有共鳴聲的 DT01ACA100 噪音仍然不小、但沒有裝在機殼中嚴重的高頻共鳴聲。但不確定是否晶片或電腦自身的問題，電腦上有一個 USB 3.0 插槽在連接此外接時毫無反應，其他裝置卻能在該插槽上正常運作。

想必找到這篇的人應該心裡很急，先用半調子解決方案作為開頭(假設想解壓的空白目錄是output，輸入為backup.ab)： cd  output dd if='backup.ab' bs=512 skip=1 | tar fxiv - 先在此掃興，輸出不太好用，這結果只適合用來拯救帳號等重要資訊。所有資料都還是完整的，但輸出時所有分割區會混成一片；如果讀取檔案的 header 或者利用輸出檔案的時間做切割，應該就可以完整的還原分割區的樣貌。 接下來敘述一下這兩行指令背後的故事。 在期末考前這幾天，手機體感越來越慢，突然腦袋一抽就去 xda 上找了 Android 8.0 AOSP 的 ROM 刷進我年事已高的 2S 中，作者表示 GPU 的嚴重問題已經解決了，於是就放心的刷入。 當然在刷機之前要做 nandroid 備份，基於 2S 沒有記憶卡，且 TWRP 新增了 adb backup 的功能，備份勢必無後顧之憂。於是： adb backup backup.ab  --twrp system cache data boot 災難由此開始。 備份過程一切順利，產生檔案大小符合預期，TWRP表示備份成功，/sdcard需要手動備份在預料之中，完美。刷入新 ROM，感覺手機像新的一樣，用起來只有爽能形容，遊戲也不會 lag 了，只可惜考試離100分越來越遠。 雖然帳號等等大多做了獨立的備份，繼承碼和綁定也確認完成，但不曉得為什麼腦子抽了---有個不常玩的遊戲（但有著難得的卡，CC日板惠惠突滿！EXPLOSION!!）沒有設定到繼承碼。好險，有備份！先還原舊版系統拿到繼承碼就好。 然而，俗話有云，備份直到還原之前都不知道是不是有效的備份。這個 nandroid 備份就是近乎無效的備份。 執行adb restore，TWRP 只會還原 /system ，就很開心的停下表示 succeed。跟文件說的 all or nothing 完全不同，屢試不爽。新系統的備份沒用，原本系統的備份也不能用，資料大爆裂。 情急之下搜尋到了這篇： https://android.stackexchange.com/questions/171638/extract-twrp-backups-made-with-adb 指令都不能用，加上