木っ端拾いの材木流し

Cannot see the wood for the trees.

wimbootを用いたisoファイルからのWindowsブート

大元の問題は、Windows回復環境(WinRE)がUSB HDD等のリムーバブルでないハードディスクから起動したとみなされた場合に、システムイメージから空のハードディスクへの復元に失敗するという点である。


・WinRE(Windows)は、デバイスがリムーバブルかどうかを判別している。
Set colDrives = objWMIService.ExecQuery _
("Select * From Win32_LogicalDisk Where DriveType = 2")
で2を返すものがリムーバブルディスクとなる。
diskpartのlist volumeで確認できる。partitionが固定ディスク、removableがリムーバブル。
余談だが、回復ドライブやWindowsインストールメディアを作る時にもリムーバブルなドライブしか選べないが、これはホットプラグSATAやUSB接続されていればUSBメモリでもHDDでもリムーバブルと判別される。


・システムイメージからの回復は、接続されているボリューム上にWinREがあるかどうかによって、成功するかどうかが変わる。
WinREをリムーバブルでないハードディスクから起動した場合、接続されているボリューム（WinREの起動デバイス、復元元デバイス、復元先デバイスを含む）にWinREが1つしかないと、復元に失敗する。WinREの起動デバイスに加えて
復元先に既にWinREがある場合は成功する。
ただし、WinREを光学ドライブから起動すると、復元先デバイスにWinREがあってもなくても成功するため、WinREの数だけで判別しているのではないと思われる。


以上から、WinREを使ってシステムイメージから空のドライブに復元する場合、以下のいずれでWinREを起動することが必要になる。
・光学ドライブから起動する
・リムーバブルなデバイスから起動する
・その他、ハードディスクと判別されない方法で起動する


物理PCの場合、USBメモリは通常はリムーバブルデバイスとして認識されるので、Windowsで作成した回復ドライブで復元できる。


VirtualBoxの場合、仮想ディスクは基本的にリムーバブルでないハードディスクと認識されるため、回復ドライブでシステムイメージから空のディスクに復元ができない。

対処としては以下の方法がある。
・Windowsインストーラーもしくはシステム修復ディスクのisoファイルを作成し、仮想光学ドライブにマウントして起動する
・Windowsインストーラーもしくはシステム修復ディスクのisoファイルのrawデータを書き込んだ仮想ディスクを作成し、仮想ディスクから起動する。VirtualBoxのUEFIファームウェアはisoのrawデータが書き込まれた仮想ディスクを仮想光学ドライブとして起動ファイルを探す。（OS起動後は仮想ディスクとして認識される）


問題となるのは、物理PCでかつ回復ドライブがリムーバブルディスクとして認識されない場合。

これは過去に遭遇した人がいた。

デジタルドルフィンズ　サポセンブログ:他の復元方法を選択してください - livedoor Blog（ブログ）
https://digitaldolphins.livedoor.blog/archives/1946708.html


MBR環境では、上記のサイトに倣ってmemdiskを使うことで回避できた。


memdiskはsyslinuxプロジェクトのコンポーネントのひとつで、syslinux,GRUB2などのブートローダから呼び出せるプログラムである。
https://wiki.syslinux.org/wiki/index.php?title=MEMDISK
ファイルで保存したイメージファイル（フロッピー、ハードディスク、ISOファイル等のrawデータが保存されたファイル）をメモリに展開し、BIOSからこれらのデバイスへのアクセスしているようにエミュレートする。

参考にしたサイトではmkisofsで復元用WIM（WinRE）を含むisoファイルを作成し、syslinux+memdiskでisoファイルからブートすることで、光学ドライブから起動したと見せかけている。


自分はこれを参考に、仮想ハードディスクにBIOS起動するGRUB2をインストールし、memdiskとシステム修復ディスクのisoファイルをコピーしたうえで、GRUB2のシェルから以下のコマンドでisoファイルを起動した。

set root=(memdiskとisoファイルを配置したパーティション)
linux16 memdiskのフルパス raw iso
initrd16 isoファイルのフルパス
boot


UEFI環境の場合、memdiskはBIOSのディスク呼び出しをエミュレートするものなので使えない。

ここでようやくwimbootが登場する。
wimbootは以下のようにハードディスクに展開されたWindows起動ファイル(BIOS環境ならbootmgr)を指定して起動させられるローダーである。
https://superuser.com/questions/1519927/windows-linux-bootdisk-iso
Windows起動ファイルをロードする方法はsyslinuxやgrub2にも存在するが、wimbootはsyslinuxやgrub2から読み込む際にwimbootの引数としてWindows起動ファイル関連の情報を記載できるため、わかりやすい。


最初は展開したWindows起動ファイルからの起動しかできないと思っていたが、以下によるとISOファイルから直接、かつUEFI環境でもWindows起動できるらしい。


INSTALL WINDOWS DIRECTLY FROM AN ISO FILE USING WIMBOOT (MBR\UEFI + GRUB2\GRUB4DOS)
https://rmprepusb.com/tutorials/145-install-windows-directly-from-an-iso-file-using-ipxe-wimboot-mbruefi-grub2grub4dos/


今後、こちらを調べてみる。

xorriso/mkisofsによる起動・dd書き込み可能なisoの作成 (3)

前回、以下のコマンドでisoファイルを作成した。
※-boot-load-sizeが誤っていたので修正

xorriso -as mkisofs \
    -b boot/etfsboot.com -no-emul-boot -boot-load-size 8  \
    -eltorito-alt-boot -e efi/microsoft/boot/efisys.bin -no-emul-boot -isohybrid-gpt-basdat  -o output.iso .

作成したファイルを見ると、
・fdisk -l：パーティション情報が表示されない
$ fdisk -l w10-22h2-inst-xorrisofs.iso
ディスク w10-22h2-inst-xorrisofs.iso: 4.56 GiB, 4891910144 バイト, 9554512 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

・hexdump -C：LBA0、LBA1が空
$ hexdump -C w10-22h2-inst-xorrisofs.iso | head
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00008000 01 43 44 30 30 31 01 00 20 20 20 20 20 20 20 20 |.CD001.. |
00008010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
00008020 20 20 20 20 20 20 20 20 49 53 4f 49 4d 41 47 45 | ISOIMAGE|
00008030 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
00008040 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 | ........|
00008050 94 72 24 00 00 24 72 94 00 00 00 00 00 00 00 00 |.r$..$r.........|
00008060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008070 00 00 00 00 00 00 00 00 01 00 00 01 01 00 00 01 |................|
・Ubuntuディスクユーティリティ：パーティション情報が表示されない
・VirtualBoxからHDDとしてUEFI起動：失敗（CDROMと認識される）

xorrisofsのisohybrid関連オプション

xorriso -as mkisofs ではなく xorrisofs を使う。
実体は同じだと思うが、オプションの情報はこちらのほうが調べやすかった。


xorrisofs - マニュアルページ セクション 1: ユーザーコマンド
https://docs.oracle.com/cd/F16635_01/html/E71065/xorrisofs-1.html
Oracle Solarisのだけど、xorrisofsのman。

isohybrid関係のオプション：

・ -isohybrid-gpt-basdat
EFIのブートイメージをESPとして疑似MBR・GPTに登録する。-isohybrid-mbrと一緒に使うことが前提。

・-part_like_isohybrid

  • isohybrid-gpt-basdatを指定した際、-isohybrid-mbr が指定されていなくてもEFIのブートイメージをESPとしてGPTに登録する。MBRには登録されない。

・-efi-boot-part disk_path
disk_path のファイルをGPTでESPとしてマークする。disk_pathはFAT-12のディスクイメージを指定する。disk_pathの代わりに --efi-boot-image を指定すると、 -eもしくは -efi-boot で指定したブートイメージが指定される。


aports/scripts/mkimg.base.sh at master · alpinelinux/aports · GitHub
https://github.com/alpinelinux/aports/blob/master/scripts/mkimg.base.sh
Alpine Linuxのisoイメージを作成するスクリプト。

スクリプトの中で、以下のような記述があった。

		if [ -z "$_isolinux" ]; then
			# efi boot only
			_efiboot="
				-efi-boot-part
				--efi-boot-image
				-e boot/grub/efi.img
				-no-emul-boot
				"
		else
			# hybrid isolinux+efi boot
			_efiboot="
				-eltorito-alt-boot
				-e boot/grub/efi.img
				-no-emul-boot
				-isohybrid-gpt-basdat
				"

isolinuxはBIOS環境でCDROM起動する仕組みなので、efi boot only とコメントが付いているオプションを指定すると、UEFI環境でのみHDD起動すると思われる。


RepackBootableISO - Debian Wiki
https://wiki.debian.org/RepackBootableISO
DebianでブータブルISOを再作成する際のガイド。
xorrisofsの各オプションの説明の中で --isohybrid-mbr と --isohybrid-gpt-basdat についても説明されている。

    • isohybrid-mbr isohdpfx.bin について、isoファイルの先頭432バイトに書き込む、とある。

ロードされるファイルは isolinux.bin が想定されているのだが、ISO9660のファイルシステム上、ブートローダーのセクタ位置は同じなのではないか。

対処

UEFI環境でCDROMとHDD両方に対応するハイブリッドisoファイルを作る方法は以下が考えられる。
(1) -isohybrid-mbr を指定せず -isohybrid-gpt-basedat -part_like_isohybrid を指定することで、疑似MBRなしで疑似ESPだけを付与する
(2) -isohybrid-mbr を指定せず -efi-boot-part --efi-boot-image を指定することで、疑似MBRなしで疑似ESPだけを付与する
(3) -isohybrid-mbr isohdpfx.bin と -isohybrid-gpt-basedat を指定することで、疑似MBRと疑似ESP両方を付与する

(1) -isohybrid-mbr を指定せず -isohybrid-gpt-basedat -part_like_isohybrid を指定することで、疑似MBRなしで疑似ESPだけを付与する

$ sudo xorrisofs -iso-level 4 -R -D -U -b boot/etfsboot.com -no-emul-boot -boot-load-size 8 -boot-info-table -eltorito-alt-boot -e efi/microsoft/boot/efisys.bin -no-emul-boot -isohybrid-gpt-basdat -part_like_isohybrid -o ../w10-22h2-inst-xorrisofs.iso isoroot .


結果：だめ。LBA1にGPTヘッダーは書き込まれるのだが、GPTパーティションとして認識されない。

・fdisk -l：パーティション情報が表示されない

$ fdisk -l ../w10-22h2-inst-xorrisofs.iso 
ディスク ../w10-22h2-inst-xorrisofs.iso: 4.56 GiB, 4891942912 バイト, 9554576 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

・hexdump -C：LBA0が空、LBA1にGPTヘッダーあり

$ hexdump -C ../w10-22h2-inst-xorrisofs.iso | head
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  05 86 bf 93 00 00 00 00  01 00 00 00 00 00 00 00  |................|
00000220  8f ca 91 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000230  50 ca 91 00 00 00 00 00  d9 26 4f b9 01 64 5b 45  |P........&O..d[E|
00000240  94 d2 c1 89 29 e4 cf 82  02 00 00 00 00 00 00 00  |....)...........|
00000250  f8 00 00 00 80 00 00 00  92 53 36 1f 00 00 00 00  |.........S6.....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

・Ubuntuディスクユーティリティ：パーティション情報が表示されない

・VirtualBoxからHDDとしてUEFI起動：失敗（CDROMと認識される）

(2) -isohybrid-mbr を指定せず -efi-boot-part --efi-boot-image を指定することで、疑似MBRなしで疑似ESPだけを付与する

$ sudo xorrisofs -iso-level 4 -R -D -U -b boot/etfsboot.com -no-emul-boot -boot-load-size 8 -boot-info-table -eltorito-alt-boot -e efi/microsoft/boot/efisys.bin -no-emul-boot -isohybrid-gpt-basdat -part_like_isohybrid -o ../w10-22h2-inst-xorrisofs.iso isoroot .


結果：だめ。3つの中で唯一UbuntuのディスクユーティリティーがHDDをGPTとして認識し、VirtualBoxでもHDDとして認識されるが、起動すると Press any key の後インストーラーを読み込めずに終了する。
(1)で boot/etfsboot.com と efi/microsoft/boot/efisys.bin と efi/boot/bootx64.efi だけを入れたISOファイルを作って起動すると Press any key は表示されるので、bootx64.efi か efisys.bin までは読み込んでいるが、それ以降のファイルへはアクセスできていないと思われる。


(3) -isohybrid-mbr isohdpfx.bin と -isohybrid-gpt-basedat を指定することで、疑似MBRと疑似ESP両方を付与する

$ sudo xorrisofs -iso-level 4 -R -D -U -b boot/etfsboot.com -no-emul-boot -boot-load-size 8 -boot-info-table -isohybrid-mbr ./isohdpfx.bin -eltorito-alt-boot -e efi/microsoft/boot/efisys.bin -no-emul-boot -isohybrid-gpt-basdat -o ../w10-22h2-inst-xorrisofs.iso isoroot .


結果：
結果：だめ。LBA0にMBRが、LBA1にGPTヘッダーが書き込まれるが、パーティションはMBRと認識され、疑似GPTパーティションが認識されない。

・fdisk -l：MBRとして空のディスクとEFIパーティションが表示される。

$ sudo fdisk -l /dev/sdc
ディスク /dev/sdc: 4.56 GiB, 4893106176 バイト, 9556848 セクタ
Disk model: VBOX HARDDISK   
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x244c3ab9

デバイス   起動 開始位置 最後から  セクタ サイズ Id タイプ
/dev/sdc1  *           0  9556847 9556848   4.6G  0 空
/dev/sdc2           1160     4039    2880   1.4M ef EFI (FAT-12/16/32)

・hexdump -C：LBA0にMBR、LBA1にGPTヘッダーあり

$ sudo hexdump -C /dev/sdc | less
00000000  33 ed 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |3...............|
00000010  90 90 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |................|
00000020  33 ed fa 8e d5 bc 00 7c  fb fc 66 31 db 66 31 c9  |3......|..f1.f1.|
00000030  66 53 66 51 06 57 8e dd  8e c5 52 be 00 7c bf 00  |fSfQ.W....R..|..|
00000040  06 b9 00 01 f3 a5 ea 4b  06 00 00 52 b4 41 bb aa  |.......K...R.A..|
00000050  55 31 c9 30 f6 f9 cd 13  72 16 81 fb 55 aa 75 10  |U1.0....r...U.u.|
00000060  83 e1 01 74 0b 66 c7 06  f1 06 b4 42 eb 15 eb 00  |...t.f.....B....|
00000070  5a 51 b4 08 cd 13 83 e1  3f 5b 51 0f b6 c6 40 50  |ZQ......?[Q...@P|
00000080  f7 e1 53 52 50 bb 00 7c  b9 04 00 66 a1 b0 07 e8  |..SRP..|...f....|
00000090  44 00 0f 82 80 00 66 40  80 c7 02 e2 f2 66 81 3e  |D.....f@.....f.>|
000000a0  40 7c fb c0 78 70 75 09  fa bc ec 7b ea 44 7c 00  |@|..xpu....{.D|.|
000000b0  00 e8 83 00 69 73 6f 6c  69 6e 75 78 2e 62 69 6e  |....isolinux.bin|
000000c0  20 6d 69 73 73 69 6e 67  20 6f 72 20 63 6f 72 72  | missing or corr|
000000d0  75 70 74 2e 0d 0a 66 60  66 31 d2 66 03 06 f8 7b  |upt...f`f1.f...{|
000000e0  66 13 16 fc 7b 66 52 66  50 06 53 6a 01 6a 10 89  |f...{fRfP.Sj.j..|
000000f0  e6 66 f7 36 e8 7b c0 e4  06 88 e1 88 c5 92 f6 36  |.f.6.{.........6|
00000100  ee 7b 88 c6 08 e1 41 b8  01 02 8a 16 f2 7b cd 13  |.{....A......{..|
00000110  8d 64 10 66 61 c3 e8 1e  00 4f 70 65 72 61 74 69  |.d.fa....Operati|
00000120  6e 67 20 73 79 73 74 65  6d 20 6c 6f 61 64 20 65  |ng system load e|
00000130  72 72 6f 72 2e 0d 0a 5e  ac b4 0e 8a 3e 62 04 b3  |rror...^....>b..|
00000140  07 cd 10 3c 0a 75 f1 cd  18 f4 eb fd 00 00 00 00  |...<.u..........|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
:[K
[K000001b0  80 04 00 00 00 00 00 00  b9 3a 4c 24 00 00 80 00  |.........:L$....|
000001c0  01 00 00 97 ff e5 00 00  00 00 70 d3 91 00 00 fe  |..........p.....|
000001d0  ff ff ef fe ff ff 88 04  00 00 40 0b 00 00 00 00  |..........@.....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  ff 4b d8 24 00 00 00 00  01 00 00 00 00 00 00 00  |.K.$............|
00000220  6f d3 91 00 00 00 00 00  40 00 00 00 00 00 00 00  |o.......@.......|
00000230  30 d3 91 00 00 00 00 00  44 ec 49 75 ab c7 57 42  |0.......D.Iu..WB|
00000240  be 4a 18 0b 11 6c 40 b9  02 00 00 00 00 00 00 00  |.J...l@.........|
00000250  f8 00 00 00 80 00 00 00  85 6b 70 f3 00 00 00 00  |.........kp.....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|

・Ubuntuディスクユーティリティ：
MBR 2パーティションとして認識される。
GPTでないのでEFIパーティションはESPとしては認識されない。

・VirtualBoxからHDDとしてUEFI起動：失敗（CDROMと認識される）


Windowsのisoファイルにisohybrid相当の疑似MBR/GPTを付与するのは難しそう。

xorriso/mkisofsによる起動・dd書き込み可能なisoの作成 (2)

前回、UEFI環境で作成したWindowsシステム修復ディスクやWindowsインストールディスクのisoファイルをddでHDDにべた書きし、このHDDをVirtualBoxで起動したところ、システム修復ディスクのWindows回復環境が起動した。
これを見て、Windowsシステム修復ディスクやWindowsインストールディスクはUEFI環境でハイブリッド起動できるように作られていると思っていたが、実際は違うらしいことが見えてきた。

ハイブリッド起動について

ハイブリッド起動できるisoファイルについては、以下が詳しい。

第93回　xorrisoとUEFIブート再び［その3］ | gihyo.jp
https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi/0093


上記ページの説明だと、UEFI環境でisoファイルをddで書き込んだHDDを起動すると、USBメモリのパーティションテーブルを探し、仮想ESP(実体は/EFI/BOOT/BOOTx64.efiを持つディスクイメージファイルの先頭アドレス)を読み込んで/EFI/BOOT/BOOTx64.efiを起動する。

Windows isoファイルの中身

しかし、UEFI環境でWindowsシステム修復ディスクのisoファイルの先頭2ブロック(512バイトx2)をhexdumpしてみると、何もない。

$ dd if=Emergency\ Repair\ Disk\ UEFI.iso bs=512 count=2 | hexdump -C
2+0 レコード入力
2+0 レコード出力
1024 バイト (1.0 kB, 1.0 KiB) コピーされました、 0.000107 s, 9.6 MB/s
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

ではどうやってこのisoファイルを書き込んだHDDから起動しているのか。
これはVirtualBoxのUEFIファームウェアによるようだ。

VirtualBoxのUEFIファームウェアの挙動

Windowsシステム修復ディスクを書き込んだ仮想HDDをVirtualBoxにアタッチして起動し、Escキー→Boot Maintenance Manager→Boot From File で起動ファイルを探索すると、最初のディスク選択のメニューでディスクが以下のように表示された。

ESP,[PciRoot(0x0)/Pci(0xC,0x0)/USB(0x8,0x0)/CDROM(0x1,0xXXXXXX,0xXXXX)]

ディスクを示す部分が「CDROM」となっている。これはisoファイルを光学デバイスとしてアタッチした場合と同じだった。

つまり、VirtualBoxのUEFIファームウェアは、isoファイルを直接書き込んだ仮想HDDを、光学ディスクとして認識する。
HDDとして認識しないので先頭のMBRやGPTの情報を読まず、ISO9660ファイルシステムを読み込んでファイルシステム内の/efi/boot/bootx64.efiをロードしている。


UbuntuやAlmaLinuxのインストールディスクのisoファイルはハイブリッド起動に対応して作られているため、先頭セクタ(LBA1,2)にローダーの情報が書き込まれている。
他のOS上でこの仮想HDDをfdisk -lで見ると、GPTの情報が認識されて仮想ESPが表示される。
また、VirtualBoxのUEFIファームウェアで見ると、

ESP,[PciRoot(0x0)/Pci(0xC,0x0)/USB(0x8,0x0)/HD(2,GPT,XXXXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX,0xXXXXXX,0xXXXX]

という形でGPT形式のHDDとして認識される。

VirtualBox以外での挙動

VirtualBox以外のUEFIファームウェアでWindowsのisoファイルを書き込んだHDDが起動可能かは適当なUSBメモリに書き込んで実機から起動すれば分かると思うが、未検証。

動作しない場合は、Windowsのisoファイルの中身をコピーしてxorriso,genisoimage等で疑似ESPを持つisoファイルを作成しないと、実機で動作するハイブリッドisoは作れないことになる。

(追記)Windowsインストールメディアのefisys.bin

Windowsインストールメディアのisoファイルをマウントし、 \efi\microsoft\boot\efisys.bin を取り出して OSFMount でマウントしてみた。

Windowsインストールメディアのefisys.bin

サイズが1.44MBであることから察しがついたが、これはgihyoの記事で書かれている「UEFI用のブートローダを収めたEFIディレクトリ(中略)をFAT16なファイルシステムに収めたefiboot.img」に相当するファイルで、中には \EFI\BOOT\BOOTX64.EFI が入っている。

これを前回記載したように

xorriso -as mkisofs \
    -b boot/etfsboot.com -no-emul-boot -boot-load-size 4  \
    -eltorito-alt-boot -e efi/microsoft/boot/efisys.bin -no-emul-boot -isohybrid-gpt-basdat  -o test02.iso .

の形で -isohybrid-gpt-basedat つきでisoファイルにすることで、UEFI環境でハイブリッド起動するisoファイルが作成できる。


(2024/12/27追記)
・・・と思ったのだが、実際にやってみると疑似MBR、GPTが作成されなかった。次回へ続く。

xorriso/mkisofsによる起動・dd書き込み可能なisoの作成

Windowsインストーラーのisoファイルから、BIOS/UEFI環境で光学ディスク起動可能、かつddでHDDにべた書きすることでHDD起動可能なisoファイルを作成しようとした。

・何も考えずにべた書きしてみる

Media Creation Toolで作成したWindowsインストーラーのisoファイルをddで仮想HDDにべた書きする。
w10-22h2-inst-iso-dd.vdi
作成した仮想HDDを接続して起動してみた。
BIOS環境では起動失敗する。UEFI環境では起動してコマンドプロンプト、インストーラーともに動作した。

・xorrisoでインストーラーからisoファイルおよびdd直書きファイルを作成してみる

データ作成用の仮想HDD MAKEISOTEMP作成 12GB
仮想HDD MAKEISOTEMPにファイルシステム作成：isoファイルが4GB超えになる。exFATはアクセスに追加パッケージためNTFSで作成。
インストーラーisoファイル内のファイルをMAKEISOTEMPにコピーし、xorrisoでisoファイルを作成。
w10-22h2-inst-xorriso.iso
xorrisoで作成したisoファイルをddで仮想HDDにべた書き。
w10-22h2-inst-xorriso-dd.vdi

参考にしたのは以下の2サイト。
mkisofsでブート可能なWindowsインストールISOを再作成する #command - Qiita
https://qiita.com/Marukaziler/items/abfb67c767778ff2f657
mkisofsで光学ディスク起動可能なWindowsのisoファイルを作成している。
第93回　xorrisoとUEFIブート再び［その3］ | gihyo.jp
https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi/0093
xorrisoでBIOS環境・UEFI環境どちらでも光学ディスク起動可能かつddべた書きでHDD起動可能なisoファイルを作成している。

上記を参考に、xorrisoはBIOS環境・UEFI環境どちらでも光学ディスク起動可能かつddべた書きでHDD起動可能となることを期待して以下のコマンドで実行した。

xorriso -as mkisofs \
    -b boot/etfsboot.com -no-emul-boot -boot-load-size 4  \
    -eltorito-alt-boot -e efi/microsoft/boot/efisys.bin -no-emul-boot -isohybrid-gpt-basdat  -o test02.iso .

Linuxのxorrisoの例をWindowsのmkisofsの例で書かれたブートイメージに変更するとともに、オプションを可能な限り追加した。追加したのは -iso-level 4 -udf -R -D -U
-R Rock Ridgeフォーマットを使用する
-D 深いディレクトリの再配置を行わない
-U ISO9660標準に違反するファイル名も許可する
-iso-level レベル番号
ISO9660 準拠レベル番号を指定する。 1 から 4 までのいずれかを指定する。
レベル 1 では、ファイルは単一セクションで構成され、ファイル名は 8.3 形式のみとなる。
レベル 2 では、ファイルは単一セクションのみで構成される。
レベル 3 では、(ISO-9660:1988 を除き) 上記の制約はない。
レベル 4 は正式には存在しないが、mkisofs はこれを ISO-9690:1999、つまり ISO-9690 バージョン 2 に割り当てている。
-isohybrid-mbr は対応するWindowsのファイルがないので削除した。

・動作確認

isoファイルはVMにアタッチして光学ドライブ起動、vdiファイルはVMにアタッチしてHDD起動で、ブートするかを試す。

ファイル名 BIOS環境 UEFI環境 備考
w10-22h2-inst.iso ○ ○ Media Creation Toolで作ったiso。当然成功。
w10-22h2-inst.vdi ○ ○ Media Creation Toolで作ったvdi。当然成功。
w10-22h2-inst-iso-dd.vdi × ○ Media Creation Toolで作ったisoをddべた書きしたvdi。
w10-22h2-inst-xorriso.iso × ○ Media Creation Toolで作ったisoからファイルコピーしxorrisoで作ったiso。
w10-22h2-inst-xorriso-dd.vdi × ○ Media Creation Toolで作ったisoからファイルコピーしxorrisoで作ったisoをddべた書きしたvdi。
w10-22h2-inst-mkisofs.iso ○ ○ Media Creation Toolで作ったisoからファイルコピーしmkisofsで作ったiso。

結果として、UEFI環境ではすべての光学ドライブ起動、HDD起動が成功した。
xorrisoの -isohybrid-gptdat オプションが機能しているのが確かめられた。
同時にWindowsのインストーラーやシステム修復ディスクのisoファイルにもddべた書きしたものがUEFI環境で動作するための情報が入っているようだ。
Linuxの例のサイトだとfdisk -lコマンドでisoファイル内に存在するパーティションテーブルが表示できるようだが、Ubuntuのfdiskコマンドでは確認できなかった。

w10-22h2-inst-iso-dd.vdi、w10-22h2-inst-xorriso.iso、w10-22h2-inst-xorriso-dd.vdiはともにMBR環境からの起動に失敗した。
w10-22h2-inst-xorriso.isoは"CDBOOT: Couldn't find BOOTMGR" というメッセージが出る。
w10-22h2-inst-iso-dd.vdi、w10-22h2-inst-xorriso-dd.vdiはMBRが無いため起動できない。
w10-22h2-inst-iso-dd.vdiはWindowsインストーラのisoファイルがMBRディスクへのddを想定していないということなのだろう。

w10-22h2-inst-xorriso.isoはLinuxでの例と違って -isohybrid-mbr オプションを使えない（疑似MBR作成に使えるファイルがない）ので、ddべた書きしたw10-22h2-inst-xorriso-dd.vdiがMBR環境で起動できないのは想定内。
しかし、 -b でMBR環境用のブートイメージ etfsboot.com は指定しているので、w10-22h2-inst-xorriso.isoはMBR環境でも起動してほしい。
ぐぐったら"CDBOOT: Couldn't find BOOTMGR" はブートローダーのないディスクで起動しようとしたときに出るメッセージのようなので、ブートイメージの書き込みに失敗しているようだ。
Windowsの例に倣ってつけたxorrisoのオプションを消してみたが、結果は同じだった。

mkisofsコマンドで -boot-load-seg つきでw10-22h2-inst-mkisofs.isoを作成すると、MBRでもUEFIでも光学ドライブから起動するisoファイルになった。が、これだと -isohybrid-gptdat が指定できないので、このファイルをddべた書きしてもHDD起動はできないと思われる。

xorrisoでwindowsを起動できるisoを作成している例を調べるが、なさそうだった。
mkisofsでは -boot-load-seg でブートローダーのセグメントを指定できたがxorrisoでは指定できなくなっている。Windowsを想定していないのかもしれない。

もともとはBIOS環境、UEFI環境でHDDと認識させずにWinREを起動させるのが目的で、それはBIOS:grub2+memdisk、UEFI:xorrisoで-isohybrid-gptdatでiso作成してからddで書き込みしたHDDで起動、で果たされている。
（もっというとUEFI環境だとERDやインストーラーのisoファイルをddでHDDに書き込むだけでよい）
BIOS環境で光学ディスク起動したければERDのisoファイルをそのまま使うか焼くかgrub2+memdisk起動すればよいし、HDD起動でよければ中身をコピーしてbootsectでMBRを付ければ済むので、これ以上の追及は不要だろう。

AndroidでmicroSDカードにアプリを移動する

ZenFone Max Pro (M1) (メモリ3GB内部ストレージ32GB)で内部ストレージが2GBを切った。
ほとんどがアプリでキャッシュの削除で凌いできたがそろそろ限界に近くなってきたので、microSDカードにアプリを移す方法を試してみた。

参考にしたのはここ。

sp7pc.com

事前準備としてサイトの手順に従ってAndroid Studioをインストールし、adbとGoogleのAndroid USBドライバーをインストール。
PCのストレージが少ないので、adbとUSBドライバーが入ったらAndroid Studioはアンインストールした。

microSDカードは128GBのものを使い、SDカードの一部領域のみ内部ストレージ化する方法で50%を内部ストレージにした。

内部ストレージ化後の設定→ストレージの表示

アプリを移動した後なので内部共有ストレージが空いているが、移動前は内部共有ストレージが30GB/32GB、内部ストレージのSDカードが76GB/128GB、外部ストレージのSDカードが6MB/62GB程度だった。

この状態でアプリを移動したが、最初に7GB程度のアプリを移動すると、移動中に画面がブラックアウトして端末の反応が無くなった。
電源ボタンで端末を強制終了してmicroSDカードを抜いてから電源を入れたら復旧し、内部ストレージ化したmicroSDも使える状態のままだったが、再度実行しても再現した。
原因が分からなかったが、内部ストレージ側の空き容量不足ではないかと考え、アプリのデータ部分を外部ストレージに移して3GB程度にし、他のアプリのキャッシュを削除して内部ストレージの空き領域を6GBまで増やして再実行したら成功した。

設定→ストレージでゲームに分類されるアプリをすべて移動した後の内部共有ストレージと内部SDカードの使用量

内部共有ストレージのゲームの使用量が3.9GBとなっているが、ゲームをタップするとアプリは空になっている。

内部共有ストレージのSDカードでシステムに67GB使用されている。これは外部ストレージ側に割り当てた領域と思われる。

内部ストレージ化したmicroSDカードをPCで見るとパーティションが3つできている。

外部ストレージのSDカードにファイルを作ってPCで見るとDドライブにファイルができていた。1番目のDドライブになっているexFATの領域が外部ストレージ相当、2番目が管理領域、3番目が内部ストレージ相当と思われる。

SRWare IronでGoogleアカウントが同期できない

ある時期からSRware Ironで同期しているGoogleアカウントの同期を解除したら、再ログインができなくなった。
ログインしようとするとGoogleアカウントのログイン画面でログインまでは普通に成功するが、その後同期するかの確認画面が出ない。
Ironのバージョンを上げてみたが解消しなかった。

以前に同じことがあって対処したのだがメモするのを忘れていた。

発端はこれ。
SRWare Iron Part20

同期で思い出したけどgoogleが今月にやる同期拒否の対策はみんなどーすんの？
アドオンとブックマークが同期できなくなるのはつらいんだけど

GoogleがChrome以外のChromiumブラウザへの対策として2021/3/15以降に同期を拒否したということらしい。

対処はこちらで紹介されていた。
lemu.blue

当時はSRwareのフォーラムも読んだけど今回は面倒で読まなかった。

https://groups.google.com/a/chromium.org/g/google-browser-signin-testaccounts
に同期したいGoogleアカウントでログインして、このグループに参加してからIronでログインすると同期できるようになる。