LUKSを使用してカーネルを更新した後、Ubuntu 21.04は「初期RAMディスクのロード中」で停止します。

LUKSを使用してカーネルを更新した後、Ubuntu 21.04は「初期RAMディスクのロード中」で停止します。

新しくインストールして2回コピーしました。最初は設定が正常に機能しましたが、カーネルアップデートを適用すると再起動時にシステムがクラッシュしました。 GRUBが提供する古いカーネルを選択するとうまくいきます。

システムの詳細:

  • XPS 13 9380
  • i5-8265U
  • BIOS バージョン 1.15.0
  • マイクロコードバージョンは「0xea」と報告されます。 apt list --installed | grep microcode 出力: intel-microcode/hirsute-updates, hirsute-security, 3.20210608.0ubuntu0.21.04.1 amd64 [インストール済み、自動]
  • セキュアブートが監査モードに設定されているようです。
  • Ubuntuマオマオ(上記のように)
  • LiveUSBのLUKSパーティションにインストール
  • 現在5.11.0-37-genericを使用していますが、以前の5.11カーネルを使用してコピーすることもありました。確かにそうだな変化バージョン自体ではなくカーネルバージョンから。 5.11.0-36-genericは珍しいGRUBオプションなしで始まります。

私が試したGRUB設定絶対にしない:

  • dis_ucode_ldrとMitigations = off(一緒にまたは別々に)。
  • スキーマが設定されていません。
  • 静かな水ぶきを取り除く
  • また覆う
  • デバッグ(出力変更なし)
  • "initrd /initrd.img-5.11.0-37-generic" 行の後のすべての形式のエコー

そしてそのすべての順列。

initrd.imgおよびinitrd.img.old(起動可能)ファイルのlsinitramfsは、明確な候補を表示しません。

マイクロコードやcryptsetupに関連しているようですが、デバッグが情報を提供せずに36で起動すると、dmesgが正常な起動を報告するため、やや恥ずかしいです。

どんなアイデアがありますか?関連のバグがあるようですが、完全に再現されませんでした。

答え1

解決策:使用

MODULES=dep

内部に/etc/initramfs-tools/initramfs.conf

再構築し(5.11.0-37-generic使用しているカーネルバージョンと置き換えます):

update-initramfs -c -k  5.11.0-37-generic

OPと同じ問題が発生しました。数日前に更新して再起動した後、システムは「初期RAMディスクをロードしています...」というメッセージで停止し、他の出力はありません。

ハードウェアはほぼ同じですが、CPUはi7-8565Uです。 OPにリストされているのと同じソフトウェア構成。

その他の投稿以下の提案:

この問題は、サイズ制限のためにロードできないinitrd.img大容量ファイル(〜100 MB)が原因で発生します。この問題は、約55MBのファイル生成MODULES=mostに切り替えることで解決できます。MODULES=depinitrd.img

答え2

今日もこの問題が発生し、解決するのに数時間かかりました。解決策は約160 MBで、大きすぎるブートイメージを再構築することです(Sorinの説明に従って)。しかし、そうするにはいくつかの説明が必要です。

機械

  • デルXPS 9550
  • Ubuntu 20.04
  • UEFIブートパーティション:nvme0n1p2
  • LUKS暗号化デフォルトパーティション:nvme0n1p3

兆候

起動すると、LUKSパスワードプロンプトの代わりにgrubメニューが表示されます。Ubuntu空の画面で結果を選択します。リカバリモードで起動しようとすると、停止する前に「初期RAMディスクをロード中」の状態になります。 Bereded(OP)と同様に、複数のGRUB設定フラグとBIOSを設定しようとしましたが、役に立ちませんでした。

解決策

USBから起動し、initramfs-tools設定を変更して、再構築する必要がありますinitrd.img

  1. ライブUSBから起動
  2. デフォルトのパーティションの復号化/ロック解除(nvme0n1p3暗号化されたパーティション名で置き換え)
    sudo cryptsetup luksOpen /dev/nvme0n1p3 nvme0n1p3_crypt
    
  3. 暗号化されたパーティションをにマウントし/mnt、ブートパーティションをにマウントして/mnt/bootからchrootを実行します。/mnt
    vgscan --mknodes
    vgchange -ay
    sudo mount /dev/mapper/vgubuntu-root /mnt # may be named ubuntu--vg-root depending on your system
    sudo mount /dev/nvme0n1p2 /mnt/boot  # replace nvme0n1p2 with your boot partition
    for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
    sudo chroot /mnt
    
  4. chroot シェルで開いて編集し、以下を/etc/initramfs-tools/initramfs.conf設定します。
    MODULES=dep
    
  5. たとえば、現在/最新initrd.img
    mv /boot/initrd.img-5.13.0-44-generic /boot/initrd.img-5.13.0-44-generic.bak
    
  6. イメージを再構築します(現在のカーネルバージョンに置き換えます)。
    update-initramfs -c -k 5.13.0-44-generic
    
  7. グラップアップデート
    update-grub
    
  8. シャットダウンして再起動すると、再構成されたイメージから起動できるようになります。

トラブルシューティング

呼び出し時にマッピングされたデバイスに指定する名前がcryptsetup luksOpen重要です。この名前はcrypttabで構成されているボリューム名と一致する必要があります(まだパーティションのロックを解除/マウントしていないため、まだ表示されません)。慣例的には<device_name>_crypt。これが正しくない場合は、実行時に次の警告が表示されますupdate-initramfs

cryptsetup: WARNING: target '<Device UUID>' not found in /etc/crypttab

リソース

答え3

(正しい)LUKSパスワードを入力してEnterキーを押すと、dm-cryptプロンプトがあるかのように正常に起動します。

(現在、Debian(netinstall)とAlpine Linuxでこの状況を経験しました。)

関連情報