20.04にアップグレードした後：luksは起動時にディスクを開きません。cryptroot / crypttabが空で、cryptsetupがcrypttabエントリを認識しません
20.04にアップグレードした後、暗号化されたディスクが起動時に復号化されません。パスワードの入力を求められないので、明らかにパーティションが見つからず、initrdプロンプトが起動します。
理由は何でしょうか：/cryptroot/crypttabinitrdイメージでは完全に空です。
lukを手動で開き、システムにchrootすることができます。これは、/etc/crypttab実際のルートディレクトリにある私のコンテンツです。
nvme0n1p3_crypt UUID=<some uuid> none luks
（UUIDはどこでもすべて正しいです）
を実行するupdate-initramfs -c -k allと、出力は次のようになります。
cryptsetup: WARNING: target 'nvme0n1p3_crypt' not found in /etc/crypttab
これは、そのファイル内の唯一のエントリのターゲット名であるため、少し奇妙です。それはまた正しいように思われる/dev/mapperリンクとしてリストされてい../dm-0ます。
デバイスの名前cryptを使用のみに変更しようとしましたdmsetup rename ...が、もちろん役に立ちませんでした。
これが私の問題の根本的な原因だと思います。
回答
Fyi、私はそれを修正しました。それはとても奇妙だったので、誰かが私に言っていないかどうかはわかりませんでした。
問題はファイルにあります/etc/crypttab：最後にEOFが必要です！
おっと！どうすればいいの？一部のLinuxがテキストファイルにEOFを反映する必要があるのは、過去25年で初めてです。おやおや！
とにかく、1週間以上のテストの後、修正されました。
生成ルーチンは次のとおりです。 https://salsa.debian.org/gpiccoli/cryptsetup/-/blob/master/debian/functions#L526
もう1つの落とし穴（他の人はそれが意図されていると言うかもしれません）は、/etc/crypttabTARGET（= name）が、initramfsを生成しようとしているルートに現在使用されているものでなければならないということです。
例：次の場合：
luks openfoo
mount /dev/mapper/foo
chroot
update-initramfs
次に、fooでfoo's etc/crypttab's TARGET なければなりません。そうでない場合は次のようになります。
cryptsetup: WARNING: target 'foo' not found in /etc/crypttab
でかろうじて見えますがupdate-initramfs -v。