Windows10 セキュアブートできるようにする

メインPCはWindows 10とUbuntu 18.04(Mate)のデュアルブート環境で、Legacyモードで起動している。
Windows Updateの画面でWindows 11のお誘いを受けたが、古くて誘いには乗れなかった。

しかし、いずれハードウェアを組み替えて、Windows 11に移行する日は来るだろうから、そのための準備は必要。
ということで、LegacyモードからUEFIモードに変更し、セキュアブートを有効にする方法を整理して実行してみた。

---

結果として、メインPCはセキュアブートに移行できたが、Ubuntuを失って再インストールしている。
Ubuntuを失った理由はセキュアブートではなく、プロプライエタリドライバを上手く動作させられなかったことによる。

今回行ったディスクの操作は、やってみれば難しいものではなかった。
でも、理屈を分かった上で実施しないと、パーティションをまるごとぶっ飛ばしてしまうかもしれない。
操作をはじめる前にパーティションのバックアップを取り、OSを起動(復旧)するための手順をよく調べておこう。

• 環境
• 表記の整理
• 作戦と現状確認
  • 目指すところ
  • MBRの復習
  • BIOSの状態
  • ディスクの状態
• 実験環境を作る
  • 本番環境のバックアップ
  • 実験環境の構築
    • パーティション作成
    • Windows 7のリカバリ
    • パーティション再作成
    • Windows 10へのアップグレード
    • デュアルブート環境
• 実験環境をセキュアブートさせる
  • 仮想PCをUEFI起動にする
  • MBRからGPTへの変換
  • 必要パーティションの作成
  • Windowsを復旧
  • デュアルブートを復旧
• 本番環境のセキュアブート
• やったこと
  • MBRのOSブートを学習
  • 回復環境
  • Windows 10インストール直後(Legacy)
  • Windows 10インストール直後(UEFI)
  • Legacy+UEFIとは
• 起きたこと
  • Windows 10 Homeのローカルアカウント
  • カーネルへの署名
  • 仮想PCのネットワークが使えない
  • winload.exeが見つからない

ちょっと手間は掛かったが、得られた結果はまぁまぁ良かったのではないかと思っている。

環境

だいぶ古いPCを、拡張した状態で使っている。

項目	値
CPU	i5-4590
Memory	32GB
Motherborad	H97M-S01 (Boot mode: Legacy)
GPU	GeForce GT 1030 & Intel HD Graphics 4600
OS	Windows 10 Pro / Ubuntu 18.04 LTS
Storage	SSD, HDD, DVD Multi

表記の整理

この記事では以下の通り表記する。

• BIOSは、マザーボードのファームウェアととらえて、BIOS画面とかBIOSの設定などと書いたりする。
• Legacyは、BIOSのブート項目の設定値とする。Legacyモードは、MBRからMaster bootstrap loaderを読み出して、OSを起動していく。
• UEFIは、BIOSのブート項目の設定値とする。UEFIモードは、GPTのESP(EFI System Partition)からOSを起動していく。

いろいろ読んだり書いたりしているうちに、こんな感じなのかな？と思ったのでこれで。

作戦と現状確認

今使っているPCはLegacyで立ち上がっている。これをUEFIに変えていくのだけれど、単純にLegacyをUEFIに変更しただけではOSが立ち上がってこないことを体験していた。

目指すところ

改めて調べてみると、LegacyはMBR、UEFIはGPTからOSを起動することがわかった。先日書いた記事を見直してみるとGPTに全く触れていないが、稼働中のサーバー達を確認してみると、すべてがGPTに変換されていた。全く意識せずにこうなっているということは、Boot-Repairが上手く処理してくれていたのだろう。

ということで、UEFI起動するために、GPTへの変換をしていく。

現状：Legacy起動

          MBR
         ┌─────┬─────┬────────────────┬─────┬───┐
Label    │ Recovery │  SYSTEM  │             Gateway            │  -none-  │Linux │
Use      │          │ RESERVED │           (Windows10)          │ (Ubuntu) │ swap │
Size     │   14GB   │   100MB  │              840GB             │   80GB   │ 18GB │
         └─────┴─────┴────────────────┴─────┴───┘
Primary  │    1     │    2     │                3               │        4         │
Extended │          │          │                                │    5     │  6   │
         └─────┴─────┴────────────────┴─────┴───┘

目指すところ：UEFI起動＋セキュアブート

          GPT
         ┌───┬──┬────┬────────────────┬─────┬───┐
Label    │ BOOT │----│        │             Gateway            │  -none-  │Linux │
Use      │  ESP │ MSR│  空き  │           (Windows10)          │ (Ubuntu) │ swap │
Size     │ 100MB│16MB│        │              840GB             │   80GB   │ 18GB │
         └───┴──┴────┴────────────────┴─────┴───┘

※サイズと表示幅の比率が合っていないのはご容赦。

現状のPartition 1はPCを買ったときのものがそのまま残っているのだが、今回よく調べてみると残しておいても仕方がないものだった。
Partition 2はOSをブートするため領域で、これを流用してESPにすれば良さそうだ。

MSRはWindowsがパーティション管理に役立てるために作成するパーティションだそうだが、中身はどんなものだか分からない。
MSRはESPの後ろ、かつ、Windowsパーティションの前に配置する必要がある。

空き領域は、そのうちGPartedで詰めれば良いと思う。

MBRの復習

MBRはディスクの先頭512バイト。
Hazymoon / MBR(Master Boot Recode)の構造

内容	先頭	終了	サイズ
Master Bootstrap Loader	0	445	446
Partition Table 1	446	461	16
Partition Table 2	462	477	16
Partition Table 3	478	493	16
Partition Table 4	494	509	16
Signature	510	511	2

Master Bootstrap Loaderには決まったプログラムが入っているようなので「あっちから持ってくる」的なことができそう。
その昔、fixmbrというのを何度か実行したことがあったけれども、ここに決まったプログラムを書き込んでいたということなのだろう。

446～511までの領域は、Ubuntuを起動してfdiskで編集できる。
基本的にはこの情報を編集するだけ…と思うと、このコマンドを使うことに対して少しだけ気が楽になった。

BIOSの状態

マザーボード(H97M-S01)の設定を見たところ、Boot mode selectという項目があり、選択肢は

• LEGACY [現状はこれが選択されている]
• UEFI
• LEGACY+UEFI

となっている。

最後の選択肢がよく分からなかったが、

• VMware Playerで試してみると、UEFI+Legacyサポートでは、GPTとMBRの両方からブートできる。
• メインPCで試してみると、LEGACY+UEFIでMBRのディスクからOSが起動できる。
  ただし、バックアップ用のUSBハードディスクをつなげたら、認識できない。

というハイブリッドな設定であるようだ。できることが増えるけれども、できないことも出てくるような感じ。

なお、調べた感じ、このOEMマザーボードはMSI H97M-G43のファームウェアがそのまま動く模様。
アップデートすることによるメリットがあるか分からないけど。

ディスクの状態

Windows 10のディスクの管理で見てみるが、情報が不足しているように思ったので、PC再起動…はい、Ubuntu 18.04(Mate)からこんにちは！
GPartedをインストールして見てみる。

$ sudo apt install gparted

基本パーティション	拡張パーティション	ファイルシステム	サイズ	マウントポイント	ラベル	フラグ	内容
1	–	NTFS	14GB		PQSERVICE	diag	Acer eRecovery Management
2	–	NTFS	100MB		SYSTEM RESERVED	boot	起動用パーティション
3	–	NTFS	840MB		Gateway		Windows 10本体
4	5	ext3	80GB	/			Ubuntu 18.04(Mate)本体
4	6	linux-swap	16GB				Linux swap

前々から気になっていながらほったらかしの PQSERVICE と SYSTEM RESERVED には何が入っているのか…

PQSERVICEは14GBを消費する、購入当時としてはリッチな構成で、中身はおそらくリカバリディスクを作成するためにあるのかと。
このリカバリツールは、先頭のパーティションにシステムを復旧してくれる仕様なので、この位置にあったのでは使えないのだった。

SYSTEM RESERVEDは、まっさらなディスクにWindowsをインストールすると作られるようになったらしい(Windows 7から)。
Windows 7から導入された仕組みで、BitlockerでC:ドライブを暗号化した場合もここは暗号化されず、ここからC:ドライブを起動していくのだそう。
How-To Geek / What Is the System Reserved Partition and Can You Delete It?

SYSTEM RESERVEDにはbootフラグが立っているけれども、うちの環境でGrubが強制的に実行されるように見えている。
GrubメニューでWindows 10が選択されると、はじめてこのパーティションのブートローダーが読み込まれて、Windowsが読み込まれる。

実験環境を作る

実験環境を作るにあたっては、仮想PCで一通り試して概要を理解し、2周目にしてようやく全体像が見えてきたというのが実態。

PCをどうしてきたのかを思い出しながら、実験環境を作っていく。後からみれば、この手順には無駄が多い(Windows 7のリカバリーは必要なかった)けれども、パーティション操作やブート設定を理解するためには悪くない素材だった。

• 現在のシステムからバックアップを取る。
  • Partition 1(回復パーティション)と、Partition 2(ブートパーティション)をバックアップする。
  • Partition 3,5,6はリカバリーやインストールで代用する計画。
• リカバリディスクからWindows 7を復旧。
  • 購入当時にリカバリーディスクを作成していた。
  • GatewayのPCだったけれども、リカバリディスクに収録されていたのはAcer eRecovery Managementだった。
• Windows 10にアップグレード(本当はアップグレードしたかったけれどライセンスがないため、インストールで再現)。
• Ubuntu 18.04をインストールしてデュアルブート環境にする。

ちゃんと実験環境を再現した上で手順を確立してもなお、本番では何か変なことが起きるもの。
それを意識して、ハードウェアに依存しない部分の手順を確立するために、ちゃんとした実験環境を作っておく。

本番環境のバックアップ

Ubuntuでシステムを起動し、MBRとPartition1, 2をファイルにバックアップする。
Partition3～5はでかすぎて仮想マシンに入れられないので、リカバリーで再現する。

バックアップ先のディレクトリに移動して、MBRとPartition1,2をファイルに書き出す。
書き出し先は共有フォルダにして、仮想PCからマウントできるようにしておく。

$ sudo dd if=/dev/sdb1 of=./p1.dmp bs=1M
$ sudo dd if=/dev/sdb2 of=./p2.dmp bs=1M

※本番環境はディスクの接続ポートを間違えていて、OS用のディスクが2番目になっている…

ついでに、パーティションの状態を書き留めておく。
@IT / パーティションの状況を調べるには

$ sudo fdisk /dev/sdb

fdisk (util-linux 2.31.1) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。


コマンド (m でヘルプ): p
ディスク /dev/sdb: 953.9 GiB, 1024209543168 バイト, 2000409264 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x2afcec37

デバイス   起動   開始位置   最後から     セクタ サイズ Id タイプ
/dev/sdb1             2048   29362175   29360128    14G 27 隠し NTFS WinRE
/dev/sdb2  *      29362176   29566975     204800   100M  7 HPFS/NTFS/exFAT
/dev/sdb3         29566976 1793409023 1763842048 841.1G  7 HPFS/NTFS/exFAT
/dev/sdb4       1793411072 2000408575  206997504  98.7G  5 拡張領域
/dev/sdb5       1793413120 1961347071  167933952  80.1G 83 Linux
/dev/sdb6       1961351168 2000406527   39055360  18.6G 82 Linux スワップ / Solaris

コマンド (m でヘルプ): q

実験環境の構築

パーティション作成

仮想PCに新しく作った仮想ハードディスク120GBを取り付け、Ubuntu Live DVDで立ち上げる。
Partition 1,2は本番環境ときっちり同じサイズ、同じ場所。
Partition 3にはWindowsをリカバリする予定で、残り全部を割り当てた。

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x5440588b.

Command (m for help): n … Partition 1作成(Recovery)
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-251658239, default 2048): 2048
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-251658239, default 251658239): 29362175

Created a new partition 1 of type 'Linux' and of size 14 GiB.

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): 7
Changed type of partition 'Linux' to 'Compaq diagnostics'.

Command (m for help): n … Partition 2作成(SYSTEM RESERVED)
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (29362176-251658239, default 29362176): 29362176
Last sector, +/-sectors or +/-size{K,M,G,T,P} (29362176-251658239, default 251658239): 29566975

Created a new partition 2 of type 'Linux' and of size 100 MiB.

Command (m for help): t
Partition number (1,2, default 2): 2
Hex code (type L to list all codes): 7

Changed type of partition 'Linux' to 'HPFS/NTFS/exFAT'.

Command (m for help): a
Partition number (1-3, default 3): 2

The bootable flag on partition 2 is enabled now.

Command (m for help): n … Partition 3作成(からっぽで、Windows 7をリカバリする)
Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): 

Using default response p.
Partition number (3,4, default 3): 
First sector (29566976-251658239, default 29566976): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (29566976-251658239, default 251658239): 

Created a new partition 3 of type 'Linux' and of size 105.9 GiB.

Command (m for help): t
Partition number (1-3, default 3): 3
Hex code (type L to list all codes): 7

Changed type of partition 'Linux' to 'HPFS/NTFS/exFAT'.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

ここで、先程バックアップしたデータにアクセスするため、保存している共有フォルダをマウントする。

$ mkdir share
#ゲストアクセスできるなら
$ sudo mount.cifs -o guest,gid=999,uid=999 //share.example.jp/share ./share
#ユーザーを指定するなら
$ sudo mount.cifs -o username=hoge,gid=999,uid=999 //share.example.jp/share ./share

Partition 1,2を復元する。

$ sudo dd if=./share/p1.dmp of=/dev/sda1 bs=1M
$ sudo dd if=./share/p2.dmp of=/dev/sda2 bs=1M

共有フォルダのマウントを解除。

$ sudo umount ./share

Partition 3をNTFSでフォーマットする。

$ sudo mkfs.ntfs -Q -L Gateway /dev/sda3
Cluster size has been automatically set to 4096 bytes.
Creating NTFS volume structures.
mkntfs completed successfully. Have a nice day.

作成結果をGPartedで見てみる。

Windows 7のリカバリ

パーティションの状態

          MBR
         ┌─────┬─────┬──────────────────────────┐
Label    │ Recovery │  SYSTEM  │             Gateway                                │
Use      │          │ RESERVED │           (からっぽ)                               │
Size     │   14GB   │   100MB  │              106GB                                 │
         └─────┴─────┴──────────────────────────┘

最初、1にbootフラグを立てて起動してみたところ、懐かしいWindows 7の開始画面を経て、Acer eRecovery Managementが立ち上がった。
多分、初めて見る画面だ。

ただ、Completely Restore System to Factory Defaultsがグレーアウトされていて、選択できない。
Acer community / eRecovery Management

やってみて分かったのだが、このツールはMaster Bootstrap Loaderが存在することが前提で、かつ、最初のパーティションにOSを復元する仕様のようだった。
そのため、せっかくきっちりと作ったパーティションテーブルだけれども、一旦Partition 1,2を削除して、Partition 3に復元ができるようにする。

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): d
Partition number (1-3, default 3): 1

Partition 1 has been deleted.

Command (m for help): d
Partition number (2,3, default 3): 2

Partition 2 has been deleted.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

パーティションの状態

          MBR
         ┌───────────┬──────────────────────────┐
Label    │     unallodated      │             Gateway                                │
Use      │(中身はあるが仕切りは │           (からっぽ)                               │
Size     │       取り払った状態)│              106GB                                 │
         └───────────┴──────────────────────────┘

リカバリディスクをISOイメージにし、仮想PCにセットして起動してみる。

最初、Partition 1,2,3をそろえた状態で復元したのだが、「このオペレーションの実行に必要なテンポラリファイルを作成するために十分な容量があります。」と表示された…日本語的にはOKっぽいメッセージだけれども、いちいちこんな表示するか？怪しい…
ということで、再起動してみると、

BOOTMGR is missing
Press Ctrl+Alt+Del to restart

と表示され、OSは起動しなかった。
Partition 1に復旧用の分割されたファイルが書き込まれており、容量がいっぱいになっているようだった。十分な容量が「ありません」が伝えたかったことの模様。

Partition 1,2を消した後で復元すると、復元状況が表示されるようになり、20分ほど掛けてシステムが復旧していく。

復旧完了後、PCを再起動したところ、OSが立ち上がってこなかった。
この手順では、MBRにMaster bootstrap loaderがインストールされないのだった。

Master bootstrap loaderを書き込むのには、bootsectやbootrecコマンドが使えると思うのだけれども、このときはWindowsが動いているPCからコピーしてくれば使える！などと考えて、やってみた。コマンドの理解ができておらず、思っていないところに何かを書き込まれてしまうのでは？と不安になったのも理由の1つ。

仮想PCにWindowsだけが動いている仮想ハードディスクを取り付けて起動し、Master bootstrap loaderを取り出して、それを実験環境のディスクに書き込んだ。

$ sudo dd if=/dev/sdb of=./mbr-mbl.dmp bs=446 count=1
$ sudo dd if=./mbr-mbl.dmp of=/dev/sda bs=446 count=1

仮想PCの電源を落とし、Windosが入ったディスクを外してから起動。
Partition 3(このタイミングではPartition 1,2を削除しているので、Partition 1扱い)にあるブートローダーが起動した。

待たされる…待つ、結構待つ。

リカバリーしたWindows 7が起動した。

パーティション再作成

パーティションの状態

          MBR
         ┌───────────┬──────────────────────────┐
Label    │                      │             Gateway                                │
Use      │     unallocated      │           (Windows 7)                              │
Size     │                      │              106GB                                 │
         └───────────┴──────────────────────────┘

Ubuntu 20.04のLive DVDで起動し、削除したPartition 1,2を復活させる。パーティションの中身は一度作ってあるので、パーティションテーブルをセットし直せば元通り。

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): n … Partiton 1(回復)復活
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2 … この段階では2扱い
First sector (2048-29566975, default 2048): 2048
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-29566975, default 29566975): 29362175

Created a new partition 2 of type 'Linux' and of size 14 GiB.
Partition #2 contains a ntfs signature.

Do you want to remove the signature? [Y]es/[N]o: N

Command (m for help): n … Partition 2(ブート)復活
Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 3 … この段階では3扱い
First sector (29362176-29566975, default 29362176): 29362176
Last sector, +/-sectors or +/-size{K,M,G,T,P} (29362176-29566975, default 29566975): 29566975

Created a new partition 3 of type 'Linux' and of size 100 MiB.
Partition #3 contains a ntfs signature.

Do you want to remove the signature? [Y]es/[N]o: N

Command (m for help): a … Partition 2にbootフラグを立てる
Partition number (1-3, default 3): 3

The bootable flag on partition 3 is enabled now.

Command (m for help): a … Partition 3のbootフラグを落とす
Partition number (1-3, default 3): 1 … この段階では1扱い

The bootable flag on partition 1 is disabled now.

Command (m for help): t … Partition 1にdiagフラグを立てる
Partition number (1-3, default 3): 2
Hex code (type L to list all codes): 12

Changed type of partition 'Linux' to 'Compaq diagnostics'.

Command (m for help): t … Partition 2をNTFSにする
Partition number (1-3, default 3): 3
Hex code (type L to list all codes): 7

Changed type of partition 'Linux' to 'HPFS/NTFS/exFAT'.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

ただし、Partition 3相当が1として存在するとき、その手前にパーティションを作成すると、パーティション番号が2とか3になる。上のfdiskの操作も、パーティション番号を意識して行っていた。
色々やりづらいし、良い状態ではないので、パーティションの並び順を修正する。
reader / ハードディスクのパーティションを fdisk でいろいろする

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sda: 120 GiB, 128849018880 bytes, 251658240 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd00bbfb4

Device     Boot    Start       End   Sectors   Size Id Type
/dev/sda1       29566976 251658239 222091264 105.9G  7 HPFS/NTFS/exFAT
/dev/sda2           2048  29362175  29360128    14G 12 Compaq diagnostics
/dev/sda3  *    29362176  29566975    204800   100M  7 HPFS/NTFS/exFAT

Partition table entries are not in disk order.

Command (m for help): x

Expert command (m for help): f
Partitions order fixed.

Expert command (m for help): r

Command (m for help): w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

これでパーティションの順序が修正できた。

パーティションの状態

          MBR
         ┌─────┬─────┬──────────────────────────┐
Label    │ Recovery │  SYSTEM  │             Gateway                                │
Use      │          │ RESERVED │           (Windows 7)                              │
Size     │   14GB   │   100MB  │              106GB                                 │
         └─────┴─────┴──────────────────────────┘

復旧直後はPartition 3にbootフラグが立っていたのだが、元々の構成を目指し、先程の操作でPartition 2にbootフラグを立てていた。
結果として、Windows 7は起動しなくなった。

これはSYSTEM RESERVEDに入っているBCD(Boot Configuration Data)が本番環境用のためで、BCDに登録されている環境が見つからないためだった。
復旧のため、Windows 7運用当時に作ったWindows PEを起動した。

コンピュータからマウントされているディスクを確認したところ、Partition 2がC:に、Partition 3がd:にマウントされた状態になっていることがわかった。
そこで、コマンドプロンプトから以下を入力し、d:にあるWindows 7をBCDに追加登録する。

X:\windows\system32>bcdboot d:\windows /l ja-jp

BCDBootのマニュアルはこちら。
Microsoft / BCDBoot のコマンド ライン オプション

仮想PCを再起動すると、Windows 7を選択・起動できるようになった。

Windows 7が起動したあとで、本番環境のWindows 10を起動するエントリを削除する。
bcdeditコマンドのマニュアルはこちら。
Microsoft / BCDEdit のコマンド ライン オプション

C:\windows\system32>bcdedit /enum
…
Windows ブート ローダー
--------------------------------
identifier              {3nnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnd}
device                  unknown
path                    \WINDOWS\system32\winload.exe
description             Windows 10
locale                  ja-JP
inherit                 {bootloadersettings}
recoverysequence        {8nnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnna}
custom:15000066         3
recoveryenabled         Yes
custom:17000077         352321653
osdevice                unknown
systemroot              \WINDOWS
resumeobject            {3nnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnd}
nx                      OptIn
custom:250000c2         1
hypervisorlaunchtype    Off

C:\windows\system32>bcdedit /delete {3nnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnd}
この操作を正しく終了しました。

仮想PCを再起動して確認したところ、7と10の選択画面は表示されなくなり、すぐにWindows 7が起動するようになっていた。

Windows 10へのアップグレード

本番環境は、この後でWindows 10へのアップグレードをしている。
今回、ライセンスキーがないのでアップグレードはできなかったため、Windows 10をPartition 3にインストールしてみた。

パーティションの状態

          MBR
         ┌─────┬─────┬──────────────────────────┐
Label    │ Recovery │  SYSTEM  │             Gateway                                │
Use      │          │ RESERVED │           (Windows10)                              │
Size     │   14GB   │   100MB  │              106GB                                 │
         └─────┴─────┴──────────────────────────┘

bcdeditで確認したところ、Partition 2に起動情報が書き込まれていた。
念押しでUbuntuからGPartedで確認したが、Partition 2にbootフラグが立っていた。
また、Partition 3にはBootディレクトリがなく、Partition 3にbootフラグを立てても起動できないことも確認した。

多くの方はこのような環境を作れば、実験環境として十分と思われる。
ウチのメインPCはWindows 10とUbuntu 18.04のデュアルブート環境なので、もう1手間加える必要がある。

デュアルブート環境

本番環境は、Windows 10へのアップグレード後に、Ubuntu 16.04をインストールし、18.04にアップグレードしている。
今回はUbuntu 16.04を飛ばし、Ubuntu 18.04を直接インストールしてデュアルブート環境にする。

まずはUbuntu 20.04のLive DVDで起動して、GPartedを使い、パーティション3を縮めて、拡張パーティションを作り、そこにUbuntuをインストールする領域(Partition 5)と、SWAP領域(Partition 6)を作る。
似たパーティション構成にしたいだけなので、サイズは適当。

Partition 5にUbuntu 18.04をインストールしていく。
インストールの種類をお任せにするとPartition 5を細かく分割されてしまうので、インストールの種類でそれ以外を選択し、/ をPartition 5に決める。

パーティションを編集する画面が途中で超縦長になった。
ALTを押しながらウィンドウの適当な場所をドラッグするとウィンドウが移動するので、それでどうにか操作を継続し、インストールが完了。

PCを再起動したところ、GrubでOS選択ができるようになっていて、Ubuntuが問題なく起動してきた。
また、Windowsも問題なく起動した。

パーティションの状態

          MBR
         ┌─────┬─────┬────────────────┬─────┬───┐
Label    │ Recovery │  SYSTEM  │             Gateway            │  -none-  │Linux │
Use      │          │ RESERVED │           (Windows10)          │ (Ubuntu) │ swap │
Size     │   14GB   │   100MB  │               81GB             │   20GB   │ 5GB  │
         └─────┴─────┴────────────────┴─────┴───┘

不思議なのは、Partition 2にbootフラグが立っているのに、Grubが起動すること。
インストール時にブートローダーを/dev/sdaにインストールしているので、MBRにそれが入り、bootフラグに関係なくGrubを起動しているのだろうと思われる。
※これを改めて認識し、UEFI起動もできるけれども、Legacy起動もできそうなMBRのUSBフラッシュメモリーを作るときに「えいっ」とやることができた。

さて、Grubメニューを見ると、/dev/sda3にWindows 7がエントリーされていることになっている。
Windows 10をインストールしたパーティションの中だけれども、実際にWindows 7の回復パーティションを起動できた。

このエントリーを削除するため、Windows 10を起動し、どんなエントリーだったのかを確認だけしておく。
(普通にエクスプローラーから削除…とかできないので、メモだけ)

C:\Windows\system32>bcdedit /store c:\Boot\BCD /enum all

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  ja-JP
inherit                 {globalsettings}
default                 {default}
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {1b79e153-2e67-11ec-9634-000c292d182a}
device                  ramdisk=[C:]\Recovery\1b79e153-2e67-11ec-9634-000c292d182a\Winre.wim,{1b79e154-2e67-11ec-9634-000c292d182a}
path                    \windows\system32\winload.exe
description             Windows Recovery Environment
inherit                 {bootloadersettings}
osdevice                ramdisk=[C:]\Recovery\1b79e153-2e67-11ec-9634-000c292d182a\Winre.wim,{1b79e154-2e67-11ec-9634-000c292d182a}
systemroot              \windows
nx                      OptIn
winpe                   Yes

Windows ブート ローダー
--------------------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  ja-JP
inherit                 {bootloadersettings}
recoverysequence        {1b79e153-2e67-11ec-9634-000c292d182a}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
nx                      OptIn

…

再起動してUbuntuを起動し、C:\Boot と C:\Recovery/1b79e153-2e67-11ec-9634-000c292d182a を削除して、Grubを更新する。

$ mkdir mp
$ sudo mount /dev/sda3 mp
$ sudo rm -r mp/Boot/
$ sudo rm -r mp/Recovery/1b79e153-2e67-11ec-9634-000c292d182a/
$ sudo umount mp
$ rmdir mp

$ sudo update-grub

出来上がった実験環境のGrubメニューと、本番環境比較してみた。
本番環境はこちら。

• Windows 10 (on /dev/sdb2)
• Ubuntu
• Advanced options for Ubuntu
• Windows Recovery Environment (on /dev/sdb1)
• Memory test (memtest86+)
• Memory test (memtest86+, serial console 115200)

実験環境はWindows 10が3番目になっていること、ディスクが/dev/sdaになっていることが違うけれども、構成が一致していることが確認できた。

念のため、Windows 10を起動してBCDを確認する。

C:\Windows\system32>bcdedit /store c:\boot\bcd /enum ← ディレクトリがないので当然
ブート構成のデータ ストアを開けませんでした。
指定されたファイルが見つかりません。

C:\Windows\system32>bcdedit /store z:\boot\bcd /enum ← SYSTEM RESERVEDパーティションに z: を割り当てて実行

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=Z:
description             Windows Boot Manager
locale                  ja-JP
inherit                 {globalsettings}
default                 {default}
resumeobject            {bab4181a-2e30-11ec-a21b-e85848b2a480}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 10
locale                  ja-JP
inherit                 {bootloadersettings}
recoverysequence        {bab4181c-2e30-11ec-a21b-e85848b2a480}
displaymessageoverride  Recovery
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {bab4181a-2e30-11ec-a21b-e85848b2a480}
nx                      OptIn
bootmenupolicy          Standard

Windows 10とリカバリーだけが登録されていることが確認できた。

これで、実験環境が完成した。

実験環境をセキュアブートさせる

ここから、

• ディスクをMBR→GPTに変換。
• ESP領域とMSR領域の作成。
• Boot-RepairでUEFI＋セキュアブートできるようにする。

までを一気に行う。

この作業中は、使用中のOSが起動できなくなるから、

• Windowsのインストールディスク
• Ubuntu Live DVD
• Boot-Repair Live DVD

をそれぞれダウンロードして用意しておく。

仮想PCをUEFI起動にする

仮想PCの定義ファイル、今回はWin7.vmxだけれども、それをテキストエディタで開いて以下を追記・変更すれば動作を変えられる。

項目	設定値
firmware	efi : UEFIで起動する。 未指定 or efi以外の適当な文字 : Legacyで起動する。
efi.legacyBoot.enabled	TRUE : UEFIで起動していつつも、GPTだけでなくMBRからのブートもできる。 FALSE : UEFIで起動し、GPTでブートができる。
uefi.secureBoot.enabled	TRUE : セキュアブートが有効になる。 FALSE : セキュアブートが無効になる。

今回は、セキュアブートまでさせるつもりなので、以下を設定した。
Win7.vmx

firmware = "efi"
efi.legacyBoot.enabled = "FALSE"
uefi.secureBoot.enabled = "TRUE"

この設定で、MBRからの起動ができなくなる。

MBRからGPTへの変換

これは、コマンドで行える模様。
ask ubuntu / Change MBR to GPT on external hard drive with data

パーティションの状態

          MBR
         ┌─────┬─────┬────────────────┬─────┬───┐
Label    │ Recovery │  SYSTEM  │             Gateway            │  -none-  │Linux │
Use      │          │ RESERVED │           (Windows10)          │ (Ubuntu) │ swap │
Size     │   14GB   │   100MB  │               81GB             │   20GB   │ 5GB  │
         └─────┴─────┴────────────────┴─────┴───┘

Ubuntu Live DVDで起動して、ディスクをMBRからGPTに変換する。
StackExchange / Change MBR to GPT on external hard drive with data
POLAR CLOUDS / MBR to GPT Conversion WITHOUT Data Loss

$ sudo gdisk /dev/sda
…
Warning! Secondary partition table overlaps the last partition by 33 blocks!
You will need to delete this partition or resize it in another utility.
<DeepL先生の翻訳>
警告! セカンダリーパーティションテーブルは、最後のパーティションと33ブロック重なっています。
このパーティションを削除するか、別のユーティリティでサイズを変更する必要があります。

Command (? for help): q

そうだ、ディスクの最後1MBにパーティションテーブルのバックアップが取られるんだっけ。
なので、3番目のWindowsが入ったパーティションを、GPartedで1MB程縮める。
(linux-swapはswap onの状態なので、これをoffの状態にしないと、パーティションを縮めることができないので注意)

再挑戦。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
<DeepL先生の翻訳>
無効なGPTと有効なMBRが見つかり、メモリ上でMBRをGPT形式に変換しました。
この操作は破壊的な可能性があります! MBR パーティションを
GPT フォーマットに変換したくない場合は、'q' を入力して終了してください。
***************************************************************

Exact type match not found for type code 1200; assigning type code for
'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

結果をGPartedで見てみる。

隙間がチクチク空いてしまったが、まぁ、動くだろう。
隙間を埋めるとしたら…チクチク移動させるより、広げた方が安全かなぁ。

必要パーティションの作成

もう使わないパーティションを削除し、GPTのUEFI起動で必要なパーティションを作成する。

パーティションの状態

          GPT
         ┌─────┬─────┬────────────────┬─────┬───┐
Label    │ Recovery │  SYSTEM  │             Gateway            │  -none-  │Linux │
Use      │          │ RESERVED │           (Windows10)          │ (Ubuntu) │ swap │
Size     │   14GB   │   100MB  │               81GB             │   20GB   │ 5GB  │
         └─────┴─────┴────────────────┴─────┴───┘

Partition 1は回復パーティションだけれど、Acer eRecovery Managementはこの位置にあってもシステムを復旧できないし、もうリカバリディスクは作ってあってバックアップもあるよね…ということで、使わない。

Partition 2は起動用で、bootディレクトリなどが含まれている。
BitLockerの起動の流れを想像すると必要だけれど、このパーティションはNTFSなので、FAT32への変換して使う。

ということで、

• Partition 1を削除。
• 空いた場所に、新しくESP(起動用のパーティション)を作成し、Partition 2の内容をコピー。
• Partition 2を削除。
• MSRのパーティションを作成。

を実施する。

パーティションの作成は、UEFIでまっさらなディスクにWindows 10をインストールしたときにできあがったディスクの構成に従う。
ESPは200MBが推奨サイズだったと記憶しているが、必要になったら後から広げる。

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI system partition
   2          206848          239615   16.0 MiB    0C01  Microsoft reserved ...

まずは、Partition 1を削除。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): d
Partition number (1-6): 1

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

パーティションの状態

          GPT
         ┌─────┬─────┬────────────────┬─────┬───┐
Label    │unallocated   SYSTEM  │             Gateway            │  -none-  │Linux │
Use      │          │ RESERVED │           (Windows10)          │ (Ubuntu) │ swap │
Size     │   14GB   │   100MB  │               81GB             │   20GB   │ 5GB  │
         └─────┴─────┴────────────────┴─────┴───┘

起動用のパーティション(ESP)を作成する。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-251658206, default = 2048) or {+-}size{KMGTP}: 2048
Last sector (2048-29362175, default = 29362175) or {+-}size{KMGTP}: 206847
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI system partition'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

パーティションの変更をシステムに伝える。
これをやっておかないと、システムは古いパーティションテーブルのまま動作するので注意。

$ sudo partprobe /dev/sda

Partition 2の中身をコピーする。NTFSからFAT32へのコピーなので、パーティションの丸ごとコピーではなく、マウントしてファイルをコピーする。

$ sudo mkfs.fat -F 32 /dev/sda1
mkfs.fat 4.1 (2017-01-24)

$ mkdir sda1
$ sudo mount /dev/sda1 sda1
$ mkdir sda2
$ sudo mount /dev/sda2 sda2

$ sudo cp -ar sda2/* sda1/

$ sudo umount sda1
$ sudo umount sda2

コピーできたので、Partition 2を削除する。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): d
Partition number (1-6): 2

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

パーティションの変更をシステムに伝える。
これをやっておかないと、システムは古いパーティションテーブルのまま動作するので注意。

$ sudo partprobe /dev/sda

続いて、MSRパーティションを作成する。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): n
Partition number (2-128, default 2): 2
First sector (34-251658206, default = 206848) or {+-}size{KMGTP}: 206848
Last sector (206848-29566975, default = 29566975) or {+-}size{KMGTP}: 239615
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): 0C01
Changed type of partition to 'Microsoft reserved'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

パーティションの変更をシステムに伝える。
これをやっておかないと、システムは古いパーティションテーブルのまま動作するので注意。

$ sudo partprobe /dev/sda

MSRは中身がよく分からないので、0でクリアしておいてみる。
※後に、MSRを作成するためのコマンドが存在することを知る…こちら。

$ sudo dd if=/dev/zero of=/dev/sda2
dd: writing to '/dev/sda2': No space left on device
32769+0 records in
32768+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.805949 s, 20.8 MB/s

操作の結果はこのようになった。MSRだけはどうにもならないが、これはインストール直後に見てみてもこの表示なので、もうWindowsに任せるしかない。

Windowsを復旧

パーティションの状態

          GPT
         ┌───┬──┬────┬────────────────┬─────┬───┐
Label    │ BOOT │----│        │             Gateway            │  -none-  │Linux │
Use      │  ESP │ MSR│  空き  │           (Windows10)          │ (Ubuntu) │ swap │
Size     │ 100MB│16MB│        │               81GB             │   20GB   │ 5GB  │
         └───┴──┴────┴────────────────┴─────┴───┘

※ESPはSYSTEM RESERVEDをコピーした状態。

この状態で仮想PCを起動したところ、WindowsもUbuntuも起動してこなかった。
UEFIのブートローダーが入っているはずもなく、当然といえば当然。

Windows 10インストールディスクから起動し、「コンピューターを修復する」から「スタートアップ修復」を選択したが失敗。
詳細オプションからコマンドプロンプトを開き、

X:\Sources>bootrec /fixboot
アクセスが拒否されました。

と失敗。

これはいかん…ということで探してみたところ、やり方はこちらで教えてくれていた。
IT HOOK / bootrec /fixbootで「アクセスが拒否されました」が出た時の対処 – Windows10

教えてくれている中から、UEFIにブートローダーを導入するあたりを切り出して実施。

ESP領域にドライブ文字を割り当てる。
list volumeでみると、ディスク上の順番とは違っていたりするのだけれど、Windows的にはドライブが割り当てられたかどうかが重要なのだろう。

X:\Sources>diskpart

DISKPART> list volume

 Volume ###  Ltr Label        Fs    Type        Size     Status     Info
 ----------  --- -----------  ----  ----------  -------  ---------  --------
 Volume 0     D   ESD-ISO      UDF    DVD-ROM     3973 MB  正常
 Volume 1     C   OS           NTFS   Partition     81 GB  正常
 Volume 2                      FAT32  Partition    100 MB  正常         非表示

DISKPART> select volume 2

ボリューム 2 が選択されました。

DISKPART> assign letter=z

DiskPart はドライブ文字またはマウント ポイント を正常に割り当てました。

DISKPART> exit

DiskPart を終了しています...

ESP領域にUEFIの起動情報を作り、そこにブートマネージャーを入れて、ブートローダーを入れていく。

X:\Sources>bcdboot C:\windows /s Z: /f UEFI /l ja-jp
ブート ファイルは正常に作成されました。

X:\Sources>bootsect /nt60 z:
対象のボリュームは BOOTMGR 互換のブートコードで更新されます。

Z: (\\?\\Volume{367d7493-7f44-4fdf-a369-1e7a14c4a0a4})

    FAT32 ファイルシステムのブートコードを正常に更新しました。

すべての対象ボリュームでブートコードが正常に更新されました。

X:\Sources>bootrec /fixboot
操作は正常に終了しました。

コマンドによる修正ができたら、続行(終了してWindows 10に進みます)する。
この選択で、実際にはPCの再起動が行われる。

操作の結果、Windowsが立ち上がってきて、セキュアブートが有効な状態になった。
msinfo32を起動すると、セキュアブートの状態を確認できる。

もしも、操作の過程で、何らかの理由でBCDが破損・消失した場合には、以下で再構成することで復旧できる。
まずはOSが見つけられることを確認。

X:\Sources>bootrec /scanos
Windows インストールを、すべてのディスクをスキャンして検出しています。

これには、しばらく時間が掛かります。お待ちください...

Windows のインストールのスキャンは成功しました。
Windows のインストールとして認識された合計数: 1
[1] C:\Windows

見つけられることが明確になったので、BCDを再構成。

X:\Sources>bootrec /rebuildbcd
Windows インストールを、すべてのディスクをスキャンして検出しています。

これには、しばらく時間が掛かります。お待ちください...

Windows のインストールのスキャンは成功しました。
Windows のインストールとして認識された合計数: 1
[1] C:\Windows
インストールをブート一覧に追加しますか? Yes(Y)/No(N)/All(A): Y
操作は正常に終了しました。

以上で、Windows 10を復旧できた(Windows 10だけの環境であれば、ココで作業終了)。

デュアルブートを復旧

Boot-RepairはOSが起動できない問題を修復してくれるツールで、ESXiのバージョンアップ時に困った問題を解決してくれた。
Boot-Repair-Disk
Ubuntu Community Help Wiki / Boot-Repair

色々と試した結果、Boot-Repairをセキュアブートの状態で起動しても上手く動かないので、一旦解除する。
Win7.vmx

firmware = "efi"
efi.legacyBoot.enabled = "FALSE"
uefi.secureBoot.enabled = "FALSE"

改めてBoot-Repairをセットして起動。
Windows 10を修復したので起動順位が最高になっており、ディスクをセットしただけではWindows 10が起動してしまうので、仮想PCの起動直後に[DEL]キーを押してセットしたISOイメージを起動する。

Boot-Repair起動直後に

It is strongly recommended to always use the latest version of this software.
Do you want the software be automatically update now?

本ソフトウェアは常に最新版を使用することを強くお勧めします。
今すぐソフトウェアを自動更新しますか？

と表示された。そんなに頻繁にアップデートされるものではないけれど、一応Yesと回答してみた。

その後は、各種設定を確認して

途中でプロンプトを開いて次のようなコマンドを実行する。

boot-repair:~$ sudo chroot "/mnt/boot-sav/sda5" dpkg-configure -a
boot-repair:~$ sudo chroot "/mnt/boot-sav/sda5" apt-get install -fy
boot-repair:~$ sudo chroot "/mnt/boot-sav/sda5" apt-get purge -y grub*-common shim-signed

通常は、実行したら先に進めるのだが、数回のテストの中で前に進めない事象も発生(何をどう操作したときだったかは失念)。
この時には、コマンドプロンプトにこんなメッセージが出ていた。

E: Essential packages were removed and -y was used without --allow-remove-essential

なので、そのパラメーターを追加してコマンドを実行した。

boot-repair:~$ sudo chroot "/mnt/boot-sav/sda5" apt-get purge -y grub*-common shim-signed --allow-remove-essential

次に実行したのはこれ。

boot-repair:~$ sudo chroot "/mnt/boot-sav/sda5" apt-get install -y grub-efi-amd64-signed shim-signed linux-headers-generic linux-signed-generic

こうしてコマンドを書き出してみれば、Grubもセキュアブートに対応した署名済みのものに書き換えているように見える。
どこかで、セキュアブート対応するためには再インストールしないと、あるいは、自分で署名して鍵を放り込んでおかないと…といった記事を見かけた気がするんだけれども、こうしてコマンドで入れ替えられるんだなぁと。

なお、この時にコンソールに表示されるカーネルの更新は4.15.0が対象になっていて、5.0.0は操作対象になっていなかった。

この後、以下のメッセージが表示された。大事なことが書かれている。

Boot successfully repaired.

Please write on a paper the following URL:
http://paste.ubuntu.com/p/xwKbqZcHDf/

In case you still experience boot problem, indicate this URL to:
***********@*****.com or to your favorite support forum.

You can now reboot your computer.

Please do not forget to make your UEFI firmware boot on the Ubuntu 18.04.3 LTS entry (sda1/EFI/ubuntu/shimx64.efi file) !
If your computer reboots directly into Windows, try to change the boot order in your UEFI firmware.
忘れずにUEFIファームウェアをUbuntu 18.04.3 LTSのエントリ(sda1/EFI/ubuntu/shimx64.efi のファイル)で起動させてください。
コンピューターが直接Windowsで再起動する場合は、UEFIファームウェアの起動順序を変更してみてください。

If your UEFI firmware does not allow to change the boot order, change the default boot entory of the Windows bootloader.
For example you can boot into Windows, then type the fllowing command in an admin command prompt:
bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi
UEFI ファームウェアでブートオーダーの変更ができない場合は、Windows ブートローダのデフォルトのブートエントリーを変更してください。
例えば、Windowsを起動し、管理者用コマンドプロンプトで以下のコマンドを入力します。

表示されたメッセージをDeepL先生に翻訳してもらったもの

メモして仮想PCをシャットダウンし、セキュアブートを有効にしてから仮想PCを起動する。
Win7.vmx

firmware = "efi"
efi.legacyBoot.enabled = "FALSE"
uefi.secureBoot.enabled = "TRUE"

起動直後に[DEL]キーを押して、起動のエントリーを修正する。
とりあえず、ISOイメージを入れたときにはそこから起動したいので、こんな感じで並べている。

EFI VMware Virtual SATA CDROM Drive (1.0)
Virtual CDROM 0
EFI VMware Virutal SATA Hard Drive (0.0)
ubuntu
Windows Boot Manager
Virutal Hard Drive 0
Network Boot from PCI 02:01.0
EFI Network

※3つめまでは真面目に考えたけれども、そこから先はGrubがどうにかしてくれるものと思うことにして、気にしなかった。

Ubuntuを起動しようとしたところ、こんなエラーが出て止まってしまった。

error: /boot/vmlinuz-5.0.0-23-generic has invalid signature.
error: you need to load the kernel first.

Press any key to contiune...

  Failed to boot both default and fallback entries.

Press any key to continue...

仕方がないので、Advanced Options for Ubuntu → Ubuntu, with Linux 4.15.0-153-generic を選択して見たところ、起動した。
5.0.0-23が入っていて、これはこれで署名されていそうな気がするんだけれど…確かにBoot-Repairでは更新対象にはなっていなかった。

$ dpkg -l linux-image*
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留
|/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常)
||/ 名前                          バージョン          アーキテクチャ      説明
+++-=============================-===================-===================-===============================================================
un  linux-image                   <なし>              <なし>              (説明 (description) がありません)
ii  linux-image-4.15.0-159-generi 4.15.0-159.167      amd64               Signed kernel image generic
ii  linux-image-5.0.0-23-generic  5.0.0-23.24~18.04.1 amd64               Signed kernel image generic
ii  linux-image-generic           4.15.0.159.148      amd64               Generic Linux kernel image
ii  linux-image-generic-hwe-18.04 5.0.0.23.80         amd64               Generic Linux kernel image
un  linux-image-unsigned-4.15.0-1 <なし>              <なし>              (説明 (description) がありません)
un  linux-image-unsigned-5.0.0-23 <なし>              <なし>              (説明 (description) がありません)

とりあえず、Ubuntuをアップデートしてみる。

$ sudo apt update
$ sudo apt dist-upgrade
$ dpkg -l linux-image*
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留
|/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常)
||/ 名前                          バージョン          アーキテクチャ      説明
+++-=============================-===================-===================-===============================================================
un  linux-image                   <なし>              <なし>              (説明 (description) がありません)
ii  linux-image-4.15.0-159-generi 4.15.0-159.167      amd64               Signed kernel image generic
ii  linux-image-5.0.0-23-generic  5.0.0-23.24~18.04.1 amd64               Signed kernel image generic
ii  linux-image-5.4.0-89-generic  5.4.0-89.100~18.04. amd64               Signed kernel image generic
ii  linux-image-generic           4.15.0.159.148      amd64               Generic Linux kernel image
ii  linux-image-generic-hwe-18.04 5.4.0.89.100~18.04. amd64               Generic Linux kernel image
un  linux-image-unsigned-4.15.0-1 <なし>              <なし>              (説明 (description) がありません)
un  linux-image-unsigned-5.0.0-23 <なし>              <なし>              (説明 (description) がありません)
un  linux-image-unsigned-5.4.0-89 <なし>              <なし>              (説明 (description) がありません)

これで再起動したところ、5.4.0-89-genericで起動してきた。

$ uname -r
5.4.0-89-generic

なお、起動し直してみたけれども、5.0.0-23はやはりエラーになった。
インストールし直せば上手くいきそうな気もするが、そもそも大量にあるカーネルのうち、何故これが選択・インストールされるのか、どういうときにカーネルを変えるのか、といったところを理解できていない。これは今後の課題とする。

とりあえずUbuntuは起動したので、再起動してWindows 10が起動できることを確認。

これで、MBRの環境を、セキュアブート対応のデュアルブート環境にする手順が確立できた。

本番環境のセキュアブート

セキュアブート対応させるために色々なOS・ツールを使うので、マルチブートができるUSBフラッシュメモリーを作成した。
そして、確立した手順に従って、メインPC(デュアルブート)と、もう1台のPC(Windowsのみ)をセキュアブート対応にすることができた。

とはいえ、メインPCでは問題発生したり、現在も発生していたりするのでメモしておく(一般的には考えなくて良い問題だろうけれども)。

発生した問題	原因	対策
OSが起動しない。	メインメモリが32GBの時に、オンボードのグラフィックを使おうとした。 ファームウェアのIGP Multi Monitorのサイズが32Mになっていた。	ファームウェアのIGP Multi Monitorのサイズを256Mにする。 色々と試したけれども、この選択をした場合だけ上手く動く。
UbuntuのGUIが表示できない。	プロプライエタリのドライバーが動作していない。	nvidia-*のパッケージをすべて削除。
Grubが起動できない。	署名されていないブートローダーが選択されている。 署名されたブートローダーのエントリーが消えている。	Boot-Repairで復旧。 もしくは、efibootmgrコマンドでエントリーを作り直す。 これは繰り返し発生しているが、発生契機は調査中。
UbuntuのGUIが表示できない。 その2	プロプライエタリのドライバーをインストールしたところで発生。	Ubuntu 18.04を諦めて削除。 Ubuntu 20.04をインストールし直した。 なお、LightDMではGUI表示できず、gdm3であれば動作。

このように問題はUbuntuに集中しており、Windowsは問題が起きなかった。

まず、GUI表示できないところから問題は始まる。[Ctrl]+[Alt]+[1～7]をこんなに何度も押したのは久しぶり…。
最初は古いバージョンのプロプライエタリなドライバーが上手く動かない問題が発生していた。
dpkg -l nvidia-* で検索してみたところ、随分古いドライバーがインストールされていた。

要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留
|/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常)
||/ 名前                              バージョン            アーキテクチャ        説明
+++-=================================-=====================-=====================-===============================================
un  nvidia-304                        <なし>                <なし>                (説明 (description) がありません)
ii  nvidia-340                        340.108-0ubuntu0.18.0 amd64                 NVIDIA binary driver - version 340.108
un  nvidia-384                        <なし>                <なし>                (説明 (description) がありません)
un  nvidia-common                     <なし>                <なし>                (説明 (description) がありません)
un  nvidia-dkms-kernel                <なし>                <なし>                (説明 (description) がありません)
un  nvidia-driver-binary              <なし>                <なし>                (説明 (description) がありません)
un  nvidia-legacy-340xx-vdpau-driver  <なし>                <なし>                (説明 (description) がありません)
un  nvidia-libopencl1-340             <なし>                <なし>                (説明 (description) がありません)
un  nvidia-libopencl1-dev             <なし>                <なし>                (説明 (description) がありません)
un  nvidia-opencl-icd                 <なし>                <なし>                (説明 (description) がありません)
ii  nvidia-opencl-icd-340             340.108-0ubuntu0.18.0 amd64                 NVIDIA OpenCL ICD
un  nvidia-persistenced               <なし>                <なし>                (説明 (description) がありません)
ii  nvidia-prime                      0.8.16~0.18.04.1      all                   Tools to enable NVIDIA's Prime
ii  nvidia-settings                   470.57.01-0ubuntu0.18 amd64                 Tool for configuring the NVIDIA graphics driver
un  nvidia-settings-binary            <なし>                <なし>                (説明 (description) がありません)
un  nvidia-vdpau-driver               <なし>                <なし>                (説明 (description) がありません)

これらをアンインストールして再起動してみたら、GUIが表示されるようになった。

でも、画面表示が遅い。glmark2の結果が237。モニターが2枚になったこともあるかもしれないが、とにかく表示がもたもたする。
我慢できないレベルだと思ったので、あらためてプロプライエタリのドライバーをインストールしてみた。
水面下のブログ / Secure BootのままNvidiaドライバをaptからインストールする【Ubuntu 16.04】
ask ubuntu / How can I install Nvidia drivers on Ubuntu 18.04 with secure boot?
adk ubuntu / Why do I get “Required key not available” when install 3rd party kernel modules or after a kernel upgrade?

$ sudo add-apt-repository ppa:graphics-drivers/ppa

$ ubuntu-drivers devices
WARNING:root:_pkg_get_support nvidia-driver-390: package has invalid Support Legacyheader, cannot determine support level
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd00001D01sv00001043sd000085F4bc03sc00i00
vendor : NVIDIA Corporation
model : GP108 [GeForce GT 1030]
manual_install: True
driver : nvidia-driver-390 - distro non-free
driver : nvidia-driver-470 - distro non-free recommended
driver : nvidia-driver-418-server - distro non-free
driver : nvidia-driver-460-server - distro non-free
driver : nvidia-driver-450-server - distro non-free
driver : nvidia-driver-460 - distro non-free
driver : nvidia-driver-470-server - distro non-free
driver : xserver-xorg-video-nouveau - distro free builtin

$ sudo apt install nvidia-driver-470

プロプライエタリのドライバには署名をして、システムに「これは信用できるよ」と伝える必要がある。

Your system has UEFI Secure Boot enabled. UEFI Secure Boot requires additional configuration to work with third-party drivers.
The system will assist you in configuring UEFI Secure Boot. To permit the use of third-party drivers, a new Machine-Owner Key (MOK) has been generated. This key now needs to be enrolled in your system’s firmware.
To ensure that this change is being made by you as an authorized user, and not by an attacker, you must choose a password now and then confirm the change after reboot using the same password, in both the “Enroll MOK” and “Change Secure Boot state” menus that will be presented to you when this system reboots.
If you proceed but do not confirm the password upon reboot, Ubuntu will still be able to boot on your system but any hardware that requires third-party drivers to work correctly may not be usable.

お使いのシステムでは、UEFIセキュアブートが有効になっています。
UEFI セキュアブートでは、サードパーティ製ドライバーを使用するための追加設定が必要です。
UEFI セキュアブートの設定については、システムがサポートします。サードパーティードライバーの使用を許可するために、新しいMOK（Machine-Owner Key）が生成されます。このキーをシステムのファームウェアに登録する必要があります。
この変更が攻撃者ではなく、正規のユーザーであるあなたによって行われていることを確認するために、システムの再起動時に表示される「Enroll MOK」と「Change Secure Boot state」の両方のメニューで、今すぐパスワードを選択し、再起動後に同じパスワードを使って変更を確認する必要があります。
再起動時にパスワードを確認しなかった場合、Ubuntuはシステム上で起動できますが、サードパーティ製のドライバーを必要とするハードウェアは使用できなくなる可能性があります。 www.DeepL.com/Translator（無料版）で翻訳しました。

DeepL先生の翻訳

パスワードを入力してインストールを完了させ、再起動後に…なんだろう、署名を有効にするのかドライバを有効にするのか、そんな操作のためにこのパスワードを利用する。

Ubuntuは起動できるし、ドライバーも有効になったようだったのだが、結局GUIを表示させることはできなかった。
ということで、泣く泣くUbuntu 18.04を削除し、Ubuntu 20.04をインストールし直した。

その他に発生した問題について、調べてみるともう色々ありすぎるので、もうちょっと調査して別記事として投稿することにした。

やったこと

MBRのOSブートを学習

Windowsが起動するまでの絵を発見。
Microsoft / ブート シーケンスのフローチャート

フローチャートは後から見つけたもので、色々なページで教えてもらいながらこんな表を作ってみていた。
ざっくりとしたところだけ押さえたいなら、この程度で良いかもしれない。

名称	内容
Master bootstrap loader	bootフラグが立ったパーティションを探し、パーティションブートセクターを起動する。
Partition boot sector	パーティションブートセクターに配置され、ブートマネージャーを起動する。 NTFSの場合は0x54番地からがブートストラップコードで、bootmgrを起動する。
Windows boot manager	Windows 7で見てみると、bootmgrという名前のファイルだった。 C:\Boot\BCD (Boot Configuration Data)に従ってWinboot.exeを起動する。
Windows boot loader	カーネルを読み込んでログインに進む。

ブートの仕組みはここで詳しく教えてくれる。
Nobusan’s Square / ブートの仕組み

また、Master bootstrap loaderについて、かなり詳しく分析されていた。
Nobusan’s Square / ブートストラップローダの詳細

ブートセクターについてわかりやすい言葉で教えてくれる。
パソコントラブル解決 PCと解 / ブートセクタとは何か 広義のブートセクタ

ブートセクターを詳しく教えてくれる。
NTFS.com / NTFS Partition Boot Sector
eのらぼらとり / ハードディスクの構造とパーティション

回復環境

BCDを見ていて、Windows Recovery Environmentってなんだろう？と気になった。
Microsoft / Windows 回復環境 (Windows RE)

日頃使うものではないのだけれど、ディスクを取り扱う作業をするときには、背景知識として持っておきたいところ。

Windows 10インストール直後(Legacy)

VMware PlayerをLegacyで起動して、Windows 10をインストールした直後のパーティション構成を調べてみた。

$ sudo fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 120 GiB, 128849018880 bytes, 251658240 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklavel type: dos
Disk identifier: 0x5b13a0e9

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048    104447    102400    50M  7 HPFS/NTFS/exFAT
/dev/sda2          104448 250531809 250427362 119.4G  7 HPFS/NTFS/exFAT
/dev/sda3       250531840 251654143   1122304   548M 27 Hidden NTFS WinRE

Command (m for help): q

SYSTEM RESERVEDの中身はこうなっていた。

$ ll /media/ubuntu/システムで予約済み/
total 429
drwxrwxrwx  1 ubuntu ubuntu   4096 Oct 11 13:26  ./
drwxr-x---+ 3 root   root       60 Oct 11 22:51  ../
drwxrwxrwx  1 ubuntu ubuntu   8192 Oct 11 13:26  Boot/
-rwxrwxrwx  1 ubuntu ubuntu 413706 May 11  2020  bootmgr*
-rwxrwxrwx  1 ubuntu ubuntu      1 Dec  7  2019  BOOTNXT*
-rwxrwxrwx  1 ubuntu ubuntu   8192 Oct 11 13:25  BOOTSECT.BAK*
drwxrwxrwx  1 ubuntu ubuntu      0 Oct 11 13:26 'System Volume Information'/

Windows 10では回復パーティションと表示されていたWinREの中身はこのような中身だった。

$ ll /media/ubuntu/20E6C99CE6C97318/Recovery/WindowsRE/
drwxrwxrwx 1 ubuntu ubuntu         0 Oct 11 22:28 ./
drwxrwxrwx 1 ubuntu ubuntu         0 Oct 11 13:27 ../
-rwxrwxrwx 1 ubuntu ubuntu   3170304 Dec  7  2019 boot.sdi
-rwxrwxrwx 1 ubuntu ubuntu      1118 Oct 11 22:28 ReAgent.xml
-rwxrwxrwx 1 ubuntu ubuntu 467680438 May 11  2020 winre.wim

※Recovery以外のディレクトリはSystem Volume Informationのみ。

Windows 10インストール直後(UEFI)

VMware PlayerをUEFIで起動して、Windows 10をインストールした直後のパーティション構成も調べてみた。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 251658240 sectors, 120.0 GiB
Model: VMware virutal S
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 14EC292B-5B05-4208-9D40-10A1A49E40B4
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 251658206
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI system partition
   2          206848          239615   16.0 MiB    0C01  Microsoft reserved ...
   3          239616       250531809   119.3 GiB   0700  Basic data partition
   4       250531840       251634143   548.0 MiB   2700

Command (? for help): q

ESPのパーティションは、起動システム感でいっぱい。

$ ll /media/ubuntu/003B-69B3
total 4
drwxr-xr-x 4 ubuntu ubuntu 1024 Oct 11 23:14 ./
drwxr-xr-x 3 ubuntu ubuntu 1024 Jan  1  1970 ../
drwxr-xr-x 2 ubuntu ubuntu 1024 Oct 11 23:17 Boot/
drwxr-xr-x 4 ubuntu ubuntu 1024 Oct 11 23:14 Microsoft/

$ ll /media/ubuntu/003B-69B3/Microsoft/Boot
drwxr-xr-x 40 ubuntu ubuntu    4096 Oct 11 23:14 ./
drwxr-xr-x  4 ubuntu ubuntu    1024 Oct 11 23:14 ../
-rw-r--r--  1 ubuntu ubuntu   36864 Oct 12 08:43 BCD
-rw-r--r--  1 ubuntu ubuntu   65536 Oct 11 23:14 BCD.LOG
…
-rw-r--r--  1 ubuntu ubuntu 1557816 Dec  7  2019 bootmgfw.efi
-rw-r--r--  1 ubuntu ubuntu 1541432 Dec  7  2019 bootmgr.efi
-rw-r--r--  1 ubuntu ubuntu   65536 Oct 11 23:17 BOOTSTAT.DAT…

回復パーティションはこんな内容。

$ ll /media/ubuntu/DE0A03020A02D803/Recovery/WindowsRE/
total 459820
drwxrwxrwx 1 ubuntu ubuntu         0 Oct 11 23:20 ./
drwxrxxrxx 1 ubuntu ubuntu         0 Oct 11 14:19 ../
-rwxrwxrwx 1 ubuntu ubuntu   3170304 Dec  7  2019 boot.sdi*
-rwxrwxrwx 1 ubuntu ubuntu      1109 Oct 11 23:20 ReAgent.xml*
-rwxrwxrwx 1 ubuntu ubuntu 467680438 May 11  2020 Winre.wim*

Legacy+UEFIとは

過去にVMware Playerの仮想マシンをUEFIで起動できるように色々とやっていた記録があり、その当時はよく分からないまま以下の設定をしていた。

Win7.vmx

firmware = "efi"
efi.legacyBoot.enabled = "TRUE"

これでLegacy+UEFI相当の設定になり、MBRのディスクイメージ(Legacy Hard Drive)からWindows 7を起動させることができた。
Windows 7のログイン画面表示までの時間が75s。LegacyもUEFIも一緒。そうだ、この頃は起動までに時間が掛かってたなぁ、懐かしい。

これで、Legacyを無効にしたらどうなるのか…
Win7.vmx

firmware = "efi"
efi.legacyBoot.enabled = "FALSE"

Windows 7は起動しない。なるほど、Legacy+UEFI設定とは、UEFI起動だけれどもMBRからOSが起動できる設定だったのね。

起きたこと

Windows 10 Homeのローカルアカウント

ということで、UEFIでWindows 10をインストールしてみたら、ディスクはどんな状態になるのか確認しようと考えた。
使用したのは2004のインストールディスク。

テスト環境なので容量を軽くしようと考え、Windows 10 Homeを選択したところ、インストール後のセットアップでMicrosoftアカウントを利用したログインしかできなくなっており、すべての選択肢を試したけれどもローカルアカウントを作ることができなかった。

安全なUEFIへの移行手順を確立するテストのためだけに、Microsoftアカウントを作ったりする迷惑は掛けられないので、ディスクを作り直してProをインストールすることにした。

カーネルへの署名

Boot-Repairを使ってデュアルブート環境を復元した後、Ubuntuを起動しようとしたら、以下のメッセージが表示されて先に進まなかった。

error: /boot/vmlinuz-5.0.0-23-generic has invalid signature.
error: you need to load the kernel first.

今回は4.0.15で起動してアップデートすることで、5.4.0がインストールされ、そのカーネルで起動ができたのでOKとしたが、カーネルに自己署名をするという解決方法もあるらしい。いつかやる日が来るかもしれないのでメモ。
ask ubuntu / vmlinuz-4.18.12-041812-generic has invalid signature

仮想PCのネットワークが使えない

VMware PlayerをNAT設定で起動したところ、ネットワークが使えない。
どうやら、ホスト側のDHCP Serviceが起動できずにいるようだ。
Snowland.net / VMware PlayerでVMnetのDHCP設定を変更する
Qiita / VMnet1、VMnet8のネットワークアドレス変更メモ

教えてくれた方法で問題解消できたのだが、1つポイントが。

設定ファイルは「管理者」で開いて編集して書き込む。

このファイルは保護されているようで、編集・保存してもファイル本体ではなくユーザー用のファイルが書き換えられるだけで、サービス起動時に使われない。
管理者でメモ帳を開いて編集・保存することで変更を反映することができた。

winload.exeが見つからない

システム復旧の手順を確立する過程で色々なことが起きていたが、

• 新たな仮想ディスクを用意。
• Windows用のパーティションを作成。
• ただし、MBRのMaster bootstrap loaderがない。

という状態でリカバリディスク(Acer eRecovery Management)からリカバリーして、仮想PCを再起動したところ、真っ黒画面に。

Master bootstrap loaderがないのだから当然、と気付いて、動いている他の仮想ディスクからコピーして起動してみたところ、こんな画面が表示された。

んー、この画面、過去に何度か見た気がする。ヤバっと思う画面。

今回はある程度学習をした後なので、落ち着いて考えてみると…
Windows boot managerまでは呼び出されていて、Windows boot loader(Winload.exe)が見つからないといっているように思われた。

BCDに何がエントリされているんだろう？と気になって、C:\Boot\BCD というファイル(Boot Configuration Data)をホストPCに取り出してきた。
管理者でコマンドプロンプトを開き、bcdeditコマンドを叩くと中身が見える。

C:\WINDOWS\system32>bcdedit /store d:\work\bcd /enum

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  unknown
description             Windows Boot Manager
locale                  ja-JP
inherit                 {globalsettings}
default                 {default}
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {default}
device                  unknown
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  ja-JP
inherit                 {bootloadersettings}
osdevice                unknown
systemroot              \Windows
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
nx                      OptIn

deviceとosdeviceがunknownになっている。

C:\WINDOWS\system32>bcdedit /store d:\vmware\dump\bcd /set {bootmgr} device partition=c:
この操作を正しく終了しました。

C:\WINDOWS\system32>bcdedit /store d:\vmware\dump\bcd /set {default} device partition=c:
この操作を正しく終了しました。

C:\WINDOWS\system32>bcdedit /store d:\vmware\dump\bcd /set {default} osdevice partition=c:
この操作を正しく終了しました。

それぞれを設定したので、ファイルを仮想ディスクに書き戻し、再度仮想PCを起動してみたが、結果は変わらなかった。

答えはなんなんだろう？ということで、MBRにMaster bootstrap loaderをインストールした状態で、復旧し直してみたところ、Windowsが起動してきた。
その環境で同じ情報を表示させたところ、こんな風になった。

C:\Windows\system32>bcdedit /enum

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  ja-JP
inherit                 {globalsettings}
default                 {current}
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  ja-JP
inherit                 {bootloadersettings}
recoverysequence        {822e0132-2dd7-11ec-931d-000c292d182a}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
nx                      OptIn

defaultがcurrentになっているのは、起動に関してはあまり関係がなさそうなので放っておくと、違いはrecoverysequenceとrecoveryenabledだった。
Windowsから普通にはアクセスできなかったので、Ubuntu 20.04のLive DVDで起動して中身を見てみた。
MSDN / Recoverysequence string in BCD store deleted

項目	中身	ありか	備考
resumeobject	{2a6324be-41e7-11df-9a87-fb418c4010f1}		休止状態からの再開で使用されるプログラムや、 hiberfil.sysなんかが定義されている。
recoverysequence	{822e0132-2dd7-11ec-931d-000c292d182a}	C:\Recovery	Recoveryの中に、この名前のディレクトリがあり、 中にはboot.sdiとWinre.wimが入っていた。

BCDには「どこにWindowsやRecoveryがあるのか」と「そのIDはなんなのか」というのが入っていて、それを使ってWindowsや回復コンソールが起動してくるのだなぁ。

その後に、これらの情報は以下ですべて見られることが分かった。

C:\Windows\system32>bcdedit /enum ALL

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=C:
description             Windows Boot Manager
locale                  ja-JP
inherit                 {globalsettings}
default                 {current}
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  ja-JP
inherit                 {bootloadersettings}
recoverysequence        {822e0132-2dd7-11ec-931d-000c292d182a}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {2a6324be-41e7-11df-9a87-fb418c4010f1}
nx                      OptIn

Windows ブート ローダー
--------------------------------
identifier              {822e0132-2dd7-11ec-931d-000c292d182a}
device                  ramdisk=[C:]\Recovery\822e0132-2dd7-11ec-931d-000c292d18
2a\Winre.wim,{822e0133-2dd7-11ec-931d-000c292d182a}
path                    \windows\system32\winload.exe
description             Windows Recovery Environment
inherit                 {bootloadersettings}
osdevice                ramdisk=[C:]\Recovery\822e0132-2dd7-11ec-931d-000c292d18
2a\Winre.wim,{822e0133-2dd7-11ec-931d-000c292d182a}
systemroot              \windows
nx                      OptIn
winpe                   Yes

休止状態からの再開
--------------------------------
identifier              {2a6324be-41e7-11df-9a87-fb418c4010f1}
device                  partition=C:
path                    \Windows\system32\winresume.exe
description             Windows Resume Application
locale                  ja-JP
inherit                 {resumeloadersettings}
filedevice              partition=C:
filepath                \hiberfil.sys
debugoptionenabled      No

Windows メモリ テスター
--------------------------------
identifier              {memdiag}
device                  partition=C:
path                    \boot\memtest.exe
description             Windows メモリ診断ツール
locale                  ja-JP
inherit                 {globalsettings}
badmemoryaccess         Yes

EMS 設定
--------------------------------
identifier              {emssettings}
bootems                 Yes

デバッガー設定
--------------------------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

RAM 不良
--------------------------------
identifier              {badmemory}

グローバル設定
--------------------------------
identifier              {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
                        {badmemory}

ブート ローダー設定
--------------------------------
identifier              {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}

ハイパーバイザー設定
-------------------
identifier              {hypervisorsettings}
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200

再開ローダー設定
--------------------------------
identifier              {resumeloadersettings}
inherit                 {globalsettings}

デバイス オプション
--------------------------------
identifier              {822e0133-2dd7-11ec-931d-000c292d182a}
description             Ramdisk Options
ramdisksdidevice        partition=C:
ramdisksdipath          \Recovery\822e0132-2dd7-11ec-931d-000c292d182a\boot.sdi

これらを再現するのは大変過ぎるので、修復コマンド(bootrec /rebuildbcd)を使って修正するのが早い、という結論に至った。

さいごに

本番環境をどうしても壊したくなくて、手順を確立してからトライした結果、Windowsは問題なく移行ができて、変化に気付かないくらいスムーズだった。
一方でUbuntuでは問題が発生し、今の段階でも完全に収束したとは言えない状況。知識が足りない部分をガンガン攻め込まれていて、今まさに学習中。

そういう意味でWindowsはとてもうまくできていると思う。

これで、ハードウェアがTPM2.0に対応すればいつでもWindows 11に移行できる。PCを組み替えるのはいつの日になるか…