今日はアップグレードすることにしました。Proxmox仮想環境（PVE） V6.2.4からV7.1へ。私がしたことは次のとおりです。
- まず、最新の6.xバージョンにアップグレードして
apt-get updateからapt-get upgrade-dist。 - 私は次のステップに従いました。Proxmox VEを6.xから7.0にアップグレード
アップグレード中に「ディスクが見つかりません」というエラーがいくつか発生し、心配になりましたが、アップグレードは続行されました。 （おそらく私が今経験している問題に関連しているようです。）アップグレードが完了したら、ホストを再起動してアップグレードを完了しました。 LXCコンテナが問題なく起動しました（起動時に起動しました）。一部の仮想マシン（起動時に起動）も直接機能します。
Boot failed: not a bootable disk一部の仮想マシンでは、コンソールでエラーが発生し、再起動が続行されます。インターネットを検索した後、時々コンソールを再起動するのに役立つ投稿を見つけて再試行しました。みんな仮想マシンで関連エラーが発生しました。私は何時間もインターネットを検索し、同様の質問をたくさん見つけました。ほとんどの仮想マシンで動作する唯一の方法は、バックアップを復元することです。残念ながら、これは最も重要なシステムであるメールサーバーでは機能しません。これには170GBのメールが含まれており、私が持っている唯一のバックアップは「proxmoxバックアップ」（images.7x）です。どちらも同じ問題を引き起こすため、どちらも機能しません。
質問：
- 仮想マシンを再起動するにはどうすればよいですか？回復できない場合は、データをインポートできるようにディスクに入る方法はありますか？
- どうやってこれが起こったのですか？私のせいですか？これはバグですか？これは既知の問題ですか？
- 他の仮想マシンも永久に破損するのではないかと心配しているので、Proxmoxを再起動するのは怖いです。このようなことが再び発生しないとどうすれば確信できますか？または、少なくともバックアップが有効であることを確認してください！
いくつかの重要な事実：
- Proxmoxのアップグレード前に動作していたすべてのVMが見つかったと100％確信しています。
- アップデート関連コマンドを実行する前に、各コンピュータのバックアップをネットワーク共有（バックアップサーバー）に作成してください。
- バックアップは Proxmox Web インターフェイスを介して行われます。
- メールサーバーを含むすべての仮想マシンは、Ubuntu 20.04 LTSで実行されます。
- BIOSをUEFIに設定してみました（成功しません）。
- 私はProxmox Proユーザーではないので、追加のデータが必要な場合は不要な投稿を避けるためにデータを取得する方法を説明してください。
間違い：
コンピュータUUID a238b981-27dd-4ebd-acee-1a9ee97d66a11 ハードドライブから起動... 起動失敗：起動可能なディスクではありません。[次から手動で転写この写真.]
pveversion -v 出力
root@hv1:/home/axxmin# pveversion -v
proxmox-ve: 7.1-1 (running kernel: 5.13.19-2-pve)
pve-manager: 7.1-8 (running version: 7.1-8/5b267f33)
pve-kernel-helper: 7.1-6
pve-kernel-5.13: 7.1-5
pve-kernel-5.4: 6.4-11
pve-kernel-5.3: 6.1-6
pve-kernel-5.13.19-2-pve: 5.13.19-4
pve-kernel-5.4.157-1-pve: 5.4.157-1
pve-kernel-5.4.41-1-pve: 5.4.41-1
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.18-2-pve: 5.3.18-2
ceph-fuse: 14.2.21-1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-5
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-14
libpve-guest-common-perl: 4.0-3
libpve-http-server-perl: 4.0-4
libpve-storage-perl: 7.0-15
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.1.2-1
proxmox-backup-file-restore: 2.1.2-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-4
pve-cluster: 7.1-2
pve-container: 4.1-3
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-3
pve-ha-manager: 3.3-1
pve-i18n: 2.6-2
pve-qemu-kvm: 6.1.0-3
pve-xtermjs: 4.12.0-1
qemu-server: 7.1-4
smartmontools: 7.2-pve2
spiceterm: 3.2-2
swtpm: 0.7.0~rc1+2
vncterm: 1.7-1
zfsutils-linux: 2.1.1-pve3
バックアップ用のバックアップ構成：
balloon: 6144
boot: cdn
bootdisk: sata0
cores: 2
ide2: none,
media=cdrom
memory: 12288
name: axx-mcow-srv01
net0: virtio=4E:86:95:6A:FC:46,bridge=vmbr20,
firewall=1
numa: 0
onboot: 1
ostype: l26
sata0: vm_instances:vm-140-disk-0,size=200G
scsihw: virtio-scsi-pci
smbios1: uuid=a238b981-27dd-4ebd-acee-1a9ee97d66a1
sockets: 1
vmgenid: 971eb84d-7502-4a68-97af-66c595c011b9 #qmdump#map:sata0:drive-sata0:vm_instances:raw:
仮想マシンの構成
root@hv1:~# qm config 140
balloon: 6144
boot: cdn
bootdisk: sata0
cores: 2
ide2: none,media=cdrom
memory: 12288
name: axx-mcow-srv01
net0: virtio=4E:86:95:6A:FC:46,bridge=vmbr20,firewall=1
numa: 0
onboot: 1
ostype: l26
sata0: vm_instances:vm-140-disk-0,size=200G
scsihw: virtio-scsi-pci
smbios1: uuid=a238b981-27dd-4ebd-acee-1a9ee97d66a1
sockets: 1
vmgenid: 66102f99-158b-451b-a8e2-187ebed7b183
アップデート1
ページが見つかりました。バックアップ後 - 起動失敗：起動可能なディスクではありません。 これはProxmoxサポートフォーラムで私に意味がありました。パーティションテーブルの別のバックアップがないため、1つ見つかりました。「ブート回復ディスク」。これにより、私のVMは変更されませんでしたが、役に立つかもしれないいくつかの追加情報が提供されました。
アップデート2
GParted liveで起動した後、パーティションテーブルが消えたことがわかります。次のコマンドで再構築してみました。testdisk破損または破損したLinuxパーティションテーブルの回復）しかし、これはうまくいきません。
まったく同じ構成（ディスクサイズを含む）で仮想マシンを作成し、ここにUbuntuをインストールし（常にデフォルトを使用するのと同じディスク設定で）、そのパーティションテーブルを「壊れた」サーバーにコピーできますか？
ベストアンサー1
サーバーが再始動されるように、パーティション表を「修復」することができます。その後、すべてが正しく実行されていることを確認するために、すべてを新しいサーバーに移行できました。以下の手順に従って行った。
- 次のコマンドを使用してサーバーを起動します。ブート回復ディスク。
- 自動的に実行されるツール「起動回復」をオフにします。
- ターミナルウィンドウを開き、コマンドを実行します
sudo testdisk /dev/sda。これにより、ディスク（sda）からパーティションを検索する（コマンドライン）ツールが起動します。 - 確認ディスクを使用してください
Proceed。 - 使用するパーティションテーブルの種類を選択します。 「BIOS」ディスクがあるのでそれが必要です
Intel。 「EUFI」ディスクがある場合はそれを選択してくださいEFI GPT。 - 行って
Analyseディスクを分析してみてください。 Quick searchクイックチェックを進めてください。ディスクによっては、この操作には数秒から1時間かかることがあります。- 場合によっては、aが役に立つと思いましたが、aがより正確でディスクの回復の可能性が高くなることが
quick scanわかりました。deeper search私が知る限り、それだけではquick scan十分ではありません。
deep search複数のパーティションが見つかる可能性があります。を使用してファイルを参照できますP。を選択または..押して戻ることができますが、押しすぎると最初からやり直す必要がありますのでQ注意してください。Q
ディレクトリを含むパーティションを見つけ、etc矢印キー（または）を使用してそのパーティションを（デフォルト）パーティションとして表示します。私の場合、2番目のパーティションはLinuxと同じファイル構造を持っていて、「デフォルトの起動可能」に設定しましたが、パーティションが常に見つからないことがわかりました。見つからない場合（私のテストでは）、ディレクトリがあるパーティションがデフォルトで表示されます。 （下記のテストマシンのスクリーンショットを参照してください。）（続行）を押して設定を確認し、新しいパーティションテーブルをディスクに書き込みます。P←→*etcPEnterWrite
パーティションテーブルを作成したら、ブートリカバリツール（最初はオフにしました）を開き、Linuxブートローダ（GRUB）をリカバリします。を使用して修理を実行できますRecommended repair。このオプションが利用できない場合は、パーティションテーブルの検索中にまだ有効になっている可能性があるため、ブート修復ツールを再起動してください。
メールサーバーをこのように修正できます。一部のテストマシンのジョブバックアップから（破損した）マシンのバックアップを復元しました。テストした機械5台をすべて修理できました。
この答えが他の人に役立つことを願っています。