日報 2026.05.31
エリート飯。
続きをやります。
|
1 2 |
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img fastboot --disable-verity --disable-verification flash vbmeta_system vbmeta_system.img |
このコマンドを実行すると、fastboot: error: Failed to find AVB_MAGIC at offset: 0 と言われるが
GPT-5.4の言い分だとこう。
stock の vbmeta.img は先頭がちゃんと AVB0 でした。
同じ stock イメージに対して fastboot flash vbmeta … は通りました。
しかし fastboot –disable-verity –disable-verification flash vbmeta … だけが Failed to find AVB_MAGIC at offset: 0 で落ちました。
つまり、エラーの意味は「その vbmeta.img が偽物」ではなく、「今の fastboot が disable-flags を付けたときのローカル前処理でコケている」です。
さらに、この機種の公式 Fastboot ROM 同梱スクリプト flash_all.bat:28-32 を見ると、Xiaomi は bare な vbmeta ではなく vbmeta_ab、vbmeta_system_ab、vbmeta_vendor_ab に書いています。
ここが重要で、AOSP の fastboot は disable-flags 付き書き換え対象を実質 vbmeta / vbmeta_a / vbmeta_b だけに見ています。なので:flash vbmeta … にすると rewrite が走って、そこで今回のエラーになる
flash vbmeta_ab … にすると rewrite 自体が走らず、そのまま stock が書かれる
flash vbmeta_system_ab … も同様で、flags を付けても実質ただの stock flash です
要するに、以前の手順のこの部分はこの端末ではそのままでは正しくありません。fastboot –disable-verity –disable-verification flash vbmeta vbmeta.img
fastboot –disable-verity –disable-verification flash vbmeta_system vbmeta_system.img
特に 2 行目の partition 名は、この機種では vbmeta_system ではなく vbmeta_system_ab 側です。
Failed to find AVB_MAGIC at offset: 0 に関してはfastboot 37(最新)ではなく古いやつ使えとの助言だったのでやってみたけど同じだったので更に問い詰め。
——————————
それなら結論ははっきりしています。37系 が悪いというより、あなたの環境では 36系 でも 37系 でも --disable-verity --disable-verification を使った「fastboot による vbmeta のその場書き換え」が失敗します。つまり、もう fastboot の版を追う問題ではありません。
やるべきことは 1 つです。fastboot に patch をやらせず、手元で vbmeta.img を 1 回だけ patch して、その patch 済みファイルを普通に flash します。
これは AOSP fastboot が本来やる処理を、手動で先にやるだけです。
重要
- ここからは
fastboot --disable-verity ...は使わない vbmeta_system_abとvbmeta_vendor_abは最初は触らない- 初回は EROFS より EXT4 の GSI を推奨
手順
まず bootloader fastboot に戻します。今 fastbootd にいる可能性があります。
|
1 2 |
fastboot reboot bootloader fastboot getvar is-userspace |
is-userspace: no になっているのを確認します。
次に、作業フォルダで vbmeta.img から patch 済みファイルを作ります。
|
1 2 3 4 5 6 |
Copy-Item .\vbmeta.img .\vbmeta_disabled.img $path = (Resolve-Path .\vbmeta_disabled.img).Path $bytes = [System.IO.File]::ReadAllBytes($path) $bytes[123] = $bytes[123] -bor 0x03 [System.IO.File]::WriteAllBytes($path, $bytes) |
確認します。
|
1 2 |
$check = [System.IO.File]::ReadAllBytes($path) ($check[120..123] | ForEach-Object { '{0:X2}' -f $_ }) -join ' ' |
ここで 00 00 00 03 と出れば OK です。
これで disable-verity と disable-verification が立っています。
その patch 済み vbmeta を plain flash します。
もう flags は付けません。
|
1 2 |
fastboot flash vbmeta_a .\vbmeta_disabled.img fastboot flash vbmeta_b .\vbmeta_disabled.img |
次に fastbootd に入ります。
|
1 2 3 |
fastboot reboot fastboot fastboot getvar is-userspace fastboot getvar current-slot |
is-userspace: yes を確認します。
ここで current-slot が a なら、GSI は system_b に入れます。current-slot が b なら、GSI は system_a に入れます。
例として、current-slot: a の場合:
|
1 2 3 4 |
fastboot flash system_b .\LineageOS-23.2-20260524-GAPPS-EXT4-GSI.img fastboot -w fastboot set_active b fastboot reboot |
current-slot: b の場合:
|
1 2 3 4 |
fastboot36 flash system_a .\LineageOS-23.2-20260524-GAPPS-EXT4-GSI.img fastboot36 -w fastboot36 set_active a fastboot36 reboot |
失敗したら
元の slot に戻します。
元が a だったなら:
|
1 2 3 |
fastboot reboot bootloader fastboot set_active a fastboot reboot |
元が b だったなら:
|
1 2 3 |
fastboot reboot bootloader fastboot set_active b fastboot reboot |
今回のポイントはこれです。36 でも 37 でも inline patch が失敗する以上、版の違いは本質ではありません。
でも、手動 patch した vbmeta_disabled.img を plain flash する方法なら、36 でも 37 でも進められます。
次に必要なら、あなたの current-slot に合わせて、a/b を埋めたコピペ用コマンドを 1 本だけで出します。
つまり…？
–disable-verity –disable-verification オプションは使わず、vbmeta.imgを細工して
本来 –disable-verity –disable-verification オプションが行うべき操作をしたっぽい。
あとvbmeta_system.imgのflashは必要ないっぽい。
あとは手順通り vbmeta.img をflashしてFastboot”D”モードに入ってLineageOS GSIのイメージをBスロット？FlashしてカレントスロットをBに切り替えてブート。
これで起動するはずが…一向に起動せず。
PCとUSB接続が切れたりついたりする音が聞こえるだけで起動ループに陥ってしまってる模様。変な汗が出る。
が、暫く待ってるとHyperOSが起動。
どうもブートローダーの仕様上、スロットBの起動に一定回数リトライして失敗しつづけるとカレントスロットをAに戻して起動し直すっぽい。スロットAには公式ROMがまだ入ってるのでそっちで起動したと。
この辺のコマンドでそういう詳細が見れる。
|
1 2 3 4 5 6 |
fastboot getvar slot-successful:a fastboot getvar slot-successful:b fastboot getvar slot-unbootable:a fastboot getvar slot-unbootable:b fastboot getvar slot-retry-count:a fastboot getvar slot-retry-count:b |
GSIのイメージをGAPPS-EROFS, GAPPS-EXT4, VANILLA-EXT4とかいろいろ変えてみたけどダメ。
他にも試しまくったがダメなのでAIが提案するには「preloader_b」というパーティーションをいじるのが最終手段というが、これ失敗すると根本のブートローダーが起動しなくなるので文鎮化するとのこと。やりたくねえ…。
そこで閃いたのが、HyperOSイメージが入ってるスロットAが正常起動するならそれをGSIに差し替えて、もし失敗したとしてもブートローダーにダメージは無くFastbootには入れるはずなのでそれでやれば良いのでは？とAIに提案したら「かなり有効です」とのことなのでやってみる。
ネタバレですが成功したので最終的な手順まとめ。
Redmi Pad 2 4G(koto)の公式Fastboot ROMをダウンロード。
koto_global_images_OS3.0.4.0.WOWMIXM_20260320.0000.00_16.0_global_2f123a43c1.tgz
展開したらimagesにファイルにある vbmeta.img をコピー
先ほど記述したAIの内容にある vbmeta.img を改変するスクリプトを実行して vbmeta_disabled.img を作る。（どこのバイナリ改変したかはスクリプト読んでくれ）
Redmi PadをFastbootブートモードで実行。
以下コマンドでvbmeta_aに改変したイメージを焼く。
fastboot flash vbmeta_a vbmeta_disabled.img
よくわからんけどmetadata削除？をする。いるのかどうかはわからん。
fastboot erase metadata
fastboot”d”モードへ移行
fastboot reboot fastboot
端末に青文字で”FASTBOOTD”とでてたらモードが切り替わってる。
fastboo getvar is-userspace を実行して yes になってたらOK
LineageOS GSIのイメージをダウンロードする。
googleサービス付きのEROFSにした。
LineageOS-23.2-20260524-GAPPS-EROFS-GSI.img
スロットA側 system を GSI に差し替えるfastboot flash system_a LineageOS-23.2-20260524-GAPPS-EROFS-GSI.img
デバイス内のユーザーデータとキャッシュを初期化するためのコマンド。必須らしい。,
fastboot -w
運命の再起動fastboot reboot
イッ….イッた…！！
ということで行きまして、無事にGSI ROMで動いており完全にXiaomiの魔の手から逃れる事に成功しました。かなりサクサクになって、気が狂うほど気持ちええんじゃ。スロットBからのブートができないのはちょっと謎ですが、まあ公式イメージ焼き直せばいつでも戻せるんで何も問題無し。
LineageOS、今のところ目立った問題も全く無くて良い感じ。というかXiaomi要素が消えただけって感じでデバフ状態から平常に戻った印象ですね。現状維持は成長。まあRedmi Pad 2 4G、これでやっとこ使い物になったのでぼちぼち触っていきます。
Minibook Xの愛撫もやっておきます、ディスプレイの90Hz出力、というか最終的に95Hzになったんでその時のメモ。
サーベイすると一応情報が出てきたけど何がなんだかよくわからんのでAIの情報食わせて、Arch上でAgentモードでやってもらったら95Hz出力に成功したので手順だけまとめてもらった。
- Chuwi Minibook X: Linuxで90Hzとタブレットモードを有効に！ : r/Chuwi
- 90 Hz EDID File Test · Issue #7 · sonnyp/linux-minibook-x
—————–
● 動作した手順はこれです。
この環境では 90Hz ではなく、VBT の pixel_clock=262144 kHz にした 95.76Hz 相当で正しく表示できました。
- chuwi-minibook を取得して vbt_patch をビルド
sudo pacman -S –needed git gcc make
mkdir -p ~/src
cd ~/src
git clone –depth=1 https://github.com/fstanis/chuwi-minibook.git
cd chuwi-minibook/vbt_patch
make CC=gcc - 現在の VBT を吸い出す
cp /sys/kernel/debug/dri/0000:00:02.0/i915_vbt /tmp/vbt-stock.bin - 95Hz相当の VBT を作る
–hz 90 ではなく、issue の回避策どおり clock を直接 262144 にする ~/src/chuwi-minibook/vbt_patch/vbt_patch /tmp/vbt-stock.bin –clock 262144 /tmp/vbt-95.bin
~/src/chuwi-minibook/vbt_patch/vbt_patch /tmp/vbt-95.bin 確認出力がだいたいこうなればOKです。 pixel_clock: 262144 kHz
refresh: 95.76 Hz - パッチ済み VBT を firmware として配置 sudo install -m 0644 /tmp/vbt-95.bin /lib/firmware/vbt
- mkinitcpio に VBT を含める
/etc/mkinitcpio.conf の FILES をこうする FILES=(/lib/firmware/vbt) - systemd-boot の arch.conf に kernel parameter を追加
/boot/loader/entries/arch.conf に以下を入れる options i915.vbt_firmware=vbt
options i915.enable_psr=0 このマシンでは最終的にこんな形です。 title Arch Linux
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options quiet splash
options resume=UUID=…
options root=UUID=… rw
options video=DSI-1:panel_orientation=right_side_up
options i915.enable_psr=0
options i915.vbt_firmware=vbt - initramfs を再生成 sudo mkinitcpio -P
- 再起動 systemctl reboot
- 起動後に確認 hyprctl monitors all
cat /sys/kernel/debug/dri/0000:00:02.0/i915_display_info | grep DSI -A2 補足:
途中で試した 90Hz パッチは 画面上半分が見えない 症状になったため不採用で、最終的に –clock 262144 = 約 95.76Hz が正解でした。
戻す場合は arch.conf から i915.vbt_firmware=vbt を外せば元に戻ります。
明るいイケメン化計画して飯して作業メモかいてたら土日終わったね。
そういやGithub Copilotが来月から従量課金になるので昨日と今日でおもちゃ愛撫のために質問攻めにしてやったぜ。もしAIが無くなったらどうやって問題解決したらええかわからへん。今のうちにカレー屋修行しておいたほうが良い。
エリート飯。
エリートおやつ。
■今日の #明るいイケメン化計画 #揺るぎなき信念のRPG
VRダンレボ 326.9kcal
■今日の1日1捨て
■ 今日の楽器
おもちゃ愛撫のためサボりです。
おわい