14.04.03 LTSと16.04 LTSの2つのシステムがあり、どちらも最近のカーネルのアップグレード後に起動しません。助けていただければ幸いです-私は専門家ではありませんが、新しいカーネルはブート時に暗号化されたファイルシステムを認識していないようです。
どちらのシステムでも、インストーラーを使用してブートドライブを暗号化しました。その後、LUKSを使用して暗号化され、ブート時にキーファイルを使用して自動マウントされる2番目のディスクを追加しました。私は(おおよそ-システムのインストールと起動後に行われました)ここの指示に従いました:
システムの詳細は次のとおりです。
16.04 LTSシステムの場合:
ハードウェアは、/dev/sdb
上のmSATA SSDであり、Ubuntuは自動パーティションセットアップ(/
およびスワップ)を使用してインストールされました。 /dev/sda
の500GB Sataドライブは/data
に使用されます-システムが稼働すると、luksパーティションが作成され、キーファイルを使用してブート時に自動マウントするように設定されます。
$ uname -a
Linux <hostname> 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 X86_64 GNU/Linux
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdb2 during installation
UUID=5039XXXX-XXXX-XXXX-XXXX-d2b4XXXXXXXX /boot ext2 defaults 0 2
# /boot/efi was on /dev/sdb1 during installation
UUID=1DXX-XX4D /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt /data ext4 errors=remount-ro 0 1
$ cat /etc/crypttab
sdb3_crypt UUID=0bg9rz-XXXX-XXXX-XXXX-XXXX-XXXX-XXqvBH none luks
data_crypt UUID=453cXXXX-XXXX-XXXX-XXXX-6926XXXXXXXX /root/<keyfile> luks
4.4.0-21
をgrubから選択すると、sdb3_crypt
のロックを解除するためのパスワードプロンプトがすぐに表示されます。システムは、ubuntuの起動プロンプトでハングします。 [削除]を押すと、次のエラーメッセージが表示されます。数分後、システムは実際に起動し、data_crypt
が期待どおり/data
にマウントされます
[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
Reading all physical volumes. This may take a while...
Found volume group "ubuntu-vg" using metadata type lvm2
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
2 logical volume(s) in volume group "ubuntu-vg" now active
/dev/mapper/ubuntu--vg-root: clean 488960/6750209 files, 11825728/26996736 blocks
[ ***] A start job is running for dev-disk-by\x2duuid-0bg9rZ\X2deNSE\x2d1E8u\x2XXXXX\x2XXXXX\x2XXXX\x2dZpqvBH.device (xxS / 1min 30s)
Grubメニューから、4.4.0-22または4.4.0-24のいずれかを選択してから削除を押すと、次の情報が表示されます(文字起こし):
[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
Reading all physical volumes. This may take a while.
最後の3行はおそらく30回繰り返され、数分後にbusybox Shellにドロップします。手動でcryptsetup luksOpen /dev/sdb3 sdb3_crypt
を実行(およびパスフレーズを入力)しても問題ありませんが、これをマウントできません(おそらくinitramfsにあり、そこで何をしているかわからないため)。
data_crypt
および/etc/fstab
から/etc/crypttab
に関連する行を削除しても違いはありません。したがって、これは問題を引き起こすこのディスクの自動マウントとは関係ないと思います。
また、これらのカーネルのinitramfsを再作成しようとしましたが、違いはありませんでした。
また、14.04.03 LTSシステムで以下に説明するような同様の問題が発生していますが、正確な詳細を提供できません(これは私が投稿しているシステムです)。
14.04.03 LTSシステムの場合:
ハードウェアは、/
およびスワップ用のNVMe SSD、および/data
用の1TB SATAディスクです。繰り返しますが、UbuntuはSSDにインストールされ、その後SATAドライブが接続され、luksを使用して暗号化パーティションとしてセットアップされ、キーファイルでブート時に自動マウントに追加されました。
xenialカーネルのパッケージがインストールされています:
linux-generic-lts-xenial
linux-headers-generic-lts-xenial
linux-image-generic-lts-xenial
コマンド出力:
Linux hostname 4.2.0-36-generic #42~14.04.1-Ubuntu SMP Fri May 13 17:27:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/nvme0n1p2 during installation
UUID=0657XXXX-XXXX-XXXX-XXXX-1be3XXXXXXXX /boot ext2 defaults 0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=AEXX-XX66 /boot/efi vfat defaults 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt /data ext4 errors=remount-ro 0 1
$ cat /etc/crypttab
nvme0n1p3_crypt UUID=61235695-XXXX-XXXX-XXXX-962cXXXXXXXX none luks,discard
data_crypt UUID=2e92XXXX-XX57-XXXX-XXXX-af9fXXXXXXXX /root/<keyfile> luks
4.4シリーズカーネルのいずれかが起動に失敗します。ただし、4.2シリーズのカーネルは正常に起動します。
/etc/crypttab
が完全に欠落していることを除いて、同様の問題がありました。最近、機械式ハードドライブをSSDにアップグレードしました。両方で/boot
以外はすべて暗号化されており、ブートプロセスは正常に機能していました。また、私は数週間前からバックアップをチェックし、crypttabがそこにありました。
私はこの投稿に対する答えに従って問題を解決しました。
3つのマウントに関するコメントに注意してください。これらは間違っており、次のようになります。
# mount --bind /dev /mnt/ubuntu/dev
# mount --bind /sys /mnt/ubuntu/sys
# mount -t proc none /mnt/ubuntu/proc
また、crypttabのUUIDは、復号化後のLUKSボリュームではなく、LUKSボリューム(私の場合は/dev/sda5
)を含むコンテナ用でなければならないことに注意してください。 (これはこれを言っていますが、私は最初にそれを見逃したので、私はこれを指摘すると思いました。)
最後に、アップデーター側のこの貧弱な振る舞い-コンピューターを起動できなくすることは、Linuxが一般的なデスクトップユーザーの間でより多くの視聴者を得ることを妨げる一種の問題であると言わなければなりません。
わかった。
Sdb3_cryptのUUID(/とswapが存在する場所)は、どういうわけか/ etc/crypttabにありませんでした。/etc/crypttabにリストされているUUIDと/ dev/disk/by-uuid /にリストされているUUIDを比較して、これを確認しました。どうやってそれが間違ったのかはわかりませんが、途中で太っていたはずです。
/ dev/sdb3の正しいUUIDで/ etc/crypttabを修正し、initramfsを更新しました($ update-initramfs -c -k 4.4.0-24-generic)。再起動すると、正常に動作します。