サーバーを再起動すると、次のエラーメッセージが表示されます。
Begin: Running /scripts/init-premount … done.
Begin: Mounting root file system …
Begin: Running /scripts/local-top …
Volume group “ubuntu-vg” not found
Cannot process volume group ubuntu-vg
Begin: Running /scripts/local-premount …
...
Begin: Waiting for root file system …
Begin: Running /scripts/local-block …
mdadm: No arrays found in config file or automatically
Volume group “ubuntu-vg” not found
Cannot process volume group ubuntu vg
mdadm: No arrays found in config file or automatically # <-- approximately 30 times
mdadm: error opening /dev/md?*: No such file or directory
done.
Gave up waiting for root file system device.
Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules: ls /dev)
ALERT! /dev/mapper/ubuntu--vg-ubuntu--lv does not exist. Dropping to a shell!
システムは、lvm vgscanボリュームグループが見つからず、ls /dev/mapper1つの項目のみが表示されるinitramfsシェル（busybox）に移動しますcontrol。
ライブSystemRescueCDを起動すると、ボリュームグループが見つかり、LVが通常どおりに使用され、マウントされ、/dev/mapper/ubuntu--vg-ubuntu--lvVGがアクティブに設定されます。だからVGとLVは大丈夫に見えますが、起動中に何かが壊れているようです。
Ubuntu 20.04サーバー、4つのSSDを持つハードウェアraid1 + 0のLVM設定。ハードウェアRAIDコントローラは、ファームウェアバージョン3.00を搭載したHPE SmartアレイP408i-p SR Gen10コントローラです。 RAID 1+0構成のHPE SSDモデルMK001920GWXFK 4個。サーバーモデルはHPE Proliant DL380 Gen10です。
ソフトウェア攻撃もなく、暗号化もありません。
エラーを見つけて問題を解決する方法についてのヒントはありますか？
私を編集してください：
/proc/partitionsよさそうだ
blkid
どこ
- /dev/sdc1 は /boot/efi です。
- /dev/sdc2 は /boot です。
- /dev/sdc3はPVです。
以前のカーネルバージョンから起動すると、実行されるまでうまく機能しましたapt update && apt upgrade。以前のカーネルは、アップグレード後も同じ問題が発生しました。
編集2：
モジュール内に/proc/modules次の項目があります。
smartpqi 81920 0 - Live 0xffffffffc0626000
lvm pvsinitramfs シェルには出力がありません。
出力は次のとおりですlvm pvchange -ay -v
No volume groups found.
出力は次のとおりですlvm pvchange -ay --partial vg-ubuntu -v
PARTIAL MODE. Incomplete logical volumes will be processed.
VG name on command line not found in list of VGs: vg-ubuntu
Volume group "vg-ubuntu" not found
Cannot process volume group vg-ubuntu
同じモデルP408i-p SR Gen10にHDDが接続された2番目のRAIDコントローラがあります。 「cinder-volumes」というボリュームグループがこのRAIDの上に構成されています。しかし、このVGはinitramfsにはありません。
3つを編集してください。
ここに一つあります。協会ルートFSから要求されたファイルまで：
- /mnt/var/log/apt/term.log
- /mnt/etc/initramfs-tools/initramfs.conf
- /mnt/etc/initramfs-tools/update-initramfs.conf
編集4：
SystemRescueCDからLV /（root）をインストールし/boot、/boot/efiLV /としてrootを指定しました。マウントされたすべてのボリュームには十分なディスク容量が残ります（使用済みディスク容量< 32％）。
出力はupdate-initramfs -u -k 5.4.0.88-generic次のとおりです
update-initramfs: Generating /boot/initrd.img-5.4.0.88-generic
W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays.
W: mdadm: failed to auto-generate temporary mdadm.conf file
この画像の/boot/initrd.img-5.4.0-88-generic最終修正日が更新されました。
再起動後も問題が発生し続けます。initrdGrubメニュー設定の起動パラメータは、XXが各メニュー項目ごとに異なる場所（88、86、77など）を/boot/grub/grub.cfg指します。/initrd.img-5.4.0-XX-generic
/bootディレクトリにはさまざまな画像（？）があります。
vmlinuz-5.4.0-88-generic
vmlinuz-5.4.0-86-generic
vmlinuz-5.4.0-77-generic
このリンクは/boot/initrd.img最新バージョンを指します/boot/initrd.img-5.4.0-88-generic。
5つの編集:
どんな措置も望む効果が得られず、システムを回復する努力が大きすぎたので、サーバーを完全に再構築する必要がありました。
答え1
私は非常に似た問題があります。新しいカーネルのインストールが失敗した後（主に/bootパーティションスペースが不足しているため）、initramfsを手動で更新し、再起動時にinitramfsは暗号化されたパーティションの復号化プロセスを要求しませんでした。Volume group “vg0” not found端末に似ていますが、機能が制限されているinitramfsについても同様のエラーとプロンプトが表示されます。
私の問題は解決しました。
- ブートパーティションのスペースを解放します。
- インストールする
cryptsetup-initramfs。
ステップ1では、この投稿のレシピを使用して古いカーネルを削除しました。https://askubuntu.com/a/1391904/1541500。手順1の注意：以前のカーネルから起動できない場合（私の場合のように）、夜にコマンドを実行した後、手順2（Live CDセッション）の一部としてこの手順を実行する必要がありますchroot。
ステップ2では、Live CDから起動してターミナルを開きました。その後、システムをインストールして不足しているパッケージをインストールし、最後のカーネルを再インストールするように求められました（initramfsとgrub cfgが自動的に更新されます）。
以下に、システムを回復するために手順2でLive CDセッション端末で使用されたコマンドを示します。
私の場合は、次のパーティションがあります。
/dev/sda1/boot/efi~とfat32/dev/sda2/boot~とext4/dev/sda3- >これは私の暗号化されたパーティションで、My Kubuntuのインストールですvg0。lvm2
私の暗号化されたパーティションCryptDiskは/etc/crypttab。復号化されたパーティションを使用するにはこの名前が必要ですcryptsetup luksOpen。復号化後には、およびvg03つのパーティションがあります。roothomeswap
これで、LIVE CD 端末で実行されるコマンドに戻ります。
sudo cryptsetup luksOpen /dev/sda3 CryptDisk # open encrypted partition
sudo vgchange -ay
sudo mount /dev/mapper/vg0-root /mnt # mount root partition
sudo mount /dev/sda2 /mnt/boot # mount boot partition
sudo mount -t proc proc /mnt/proc
sudo mount -t sysfs sys /sys
sudo mount -o bind /run /mnt/run # to get resolv.conf for internet access
sudo mount -o bind /dev /mnt/dev
sudo chroot /mnt
apt-get update
apt-get dist-upgrade
apt-get install lvm2 cryptsetup-initramfs cryptsetup
apt-get install --reinstall linux-image-5.4.0-99-generic linux-headers-5.4.0-9 9-generic linux-modules-5.4.0-99-generic linux-tools-5.4.0-99-generic
再起動に成功した後update-initramfs -c -k all。
答え2
以前のカーネルバージョンから起動した後、問題は消えましたが、アップグレード後に再び表示されたため、誤ってカーネルバージョンを切り替えた可能性があります。https://wiki.ubuntu.com/Kernel/LTSEnablementStack詳細については。
デフォルトでは、Ubuntu 20.04はLinuxカーネルの3つのバージョンのうちの1つを使用できます。
- Ubuntu 20.04バージョンの公式リリース（GA）：メタパッケージ
linux-generic - OEM特別版：メタパッケージ
linux-oem-20.04 - 長期サポートアクティベーション/ハードウェアアクティベーション（HWE）カーネルバージョン：メタパッケージ
linux-generic-hwe-20.04
あなたのハードウェアがあまりにも新しいので、OEMまたはHWEコアが必要な場合があります。ただし、システムに最初に「間違った」カーネルがインストールされていて、そのメタパッケージをインストールせずに正しいカーネルを手動でインストールした場合、アップデートメカニズムはハードウェア固有のドライバを備えたsmartpqiGAシリーズの最新のカーネルをデフォルトでインストールできるようになりました。あります。あまりにも古いかもしれません。
paladinがコメントで示唆したように、SystemRescueCDから起動して/var/log/apt/term.logシステムを調べて、アップデートで置き換えられた正確なカーネルパッケージのバージョンを見つける必要があるかもしれません。
正しいカーネルバージョンがわかったら、起動メニューを再試行するか（まだ機能している以前のカーネルバージョンが含まれている場合）、SystemRescueCDから起動し、ルートLVとchrootをここにマウントしてから、必要な他のファイルシステムをマウントできます。をクリックし、最新のカーネルパッケージをインストールします。ぴったりの味を押してから再起動します。
システムがうまく実行されたら、「間違った」カーネルスタイルに関連するメタパッケージを削除する必要があります（インストールされている場合）。aptこれらのメタパッケージは、新しいカーネルの更新が可能になるたびにカーネルスタイルを直接選択します。
カーネルスタイルが正しいことが判明した場合、ディスク容量が不足してupdate-initramfs新しいカーネル用の新しいinitramfsファイルを作成するなど、状況がより簡単になる可能性があります。
簡単な修正方法があります。まず、いくつかのディスク容量を解放し（aptキャッシュを消去するのに役立ちapt cleanます）、実行してupdate-initramfs -u -k version-of-newest-kernel-packageinitramfsファイルを再生成します。 initramfsが現在失敗しているすべてのカーネルバージョンに対してこのコマンドを繰り返して、後でより多くの問題が発生した場合に備えて、より実行可能な起動オプションを提供できます。
答え3
しばらく前に同様の問題が発生しました。設定に別のLVMボリュームを追加し、誤ってubuntu-vgの名前を新しいボリュームに変更しました（コマンド実行中に混乱）。
解決策は、USB起動可能ディスクから起動し、障害のあるvgの名前を変更することです。私が従ったステップは次のとおりです。
Live Linux USB Open端末を使用して実行し、次のように入力します。 2.1 sudo vgdisplay -->設定ですべてのvgsのリストを表示する
2.2 メインFSを妨害または含むvgの識別
2.3 sudo vgrename <エラー名> ubuntu-vg
上記の作業を完了してから正常に終了してから再起動してください。 grubはボリュームをチェックし、正常にマウントします。