Ubuntu 15.10 をインストールするために、このチュートリアルに従いました。
コンピュータを再起動した後、GRUB メニューにアクセスし、Ubuntu を選択しました。その後すぐに、次のエラーが発生しました。
/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
これらのメッセージは、黒い画面に毎秒表示され続けます。しばらくすると、initramfs
ash コンソールにアクセスできるようになります。
何が間違っているのでしょうか?
答え1
今日、Ubuntu 15.10 を実行しているラップトップで同じエラーが発生していました。このラップトップは常に最新の状態に保たれていましたが、現在のカーネルをテストするまで 1 か月間再起動していませんでした (つまり、最近変更があった可能性があります)。
とにかく、私の場合、根本的な原因は、上記のチュートリアルに従う際のセットアップの不具合により、スワップ パーティションが「欠落」していることであることがわかりました。これが当てはまる場合、または実際に を使用している場合はlvm
、以下の手順 2 をスキップできる可能性があります。もちろん、システム (またはセカンダリ データ) パーティションが破損しているか見つからない場合にも、上記のエラー メッセージが表示されることがあります (手順 3 を参照)。
ステップ1: システムをマウントし、前述のチュートリアルに従ってパーティションを起動します
たとえば、(ext2) ブート パーティションが /dev/sdX1、(暗号化された) スワップ パーティションが /dev/sdX2、(暗号化された) データ パーティションが /dev/sdX3 で、 を使用して後者を正常に復号化しcryptsetup luksOpen /dev/sdX3 data
、マウントしたとしますmkdir /tmp/data; mount /dev/mapper/data /tmp/data
。
チュートリアルのバインド マウントに注意し、システム パーティションの /boot ディレクトリからアクセスできるように /dev/sdX1 をマウントしてください ( を実行する必要があるため、これは重要ですupdate-initramfs
)。
以下では、chroot /tmp/data/@ubuntu1510
(またはマウントされたシステムパーティションの名前)が正常に実行されたと仮定します。
ステップ2: 上記のエラーメッセージを取り除く
私は btrfs を使用しています (前述のサブボリューム名から推測できると思います)。そのため、機能性を損なうことなく、lvmetad を次のように簡単に無効にすることができます。
- /etc/lvm/lvm.confを編集して、
use_lvmetad=1
次のように変更します。use_lvmetad=0
- 実行する
update-initramfs -k $(uname -r) -u ; sync
今あなたできた再起動するとエラーメッセージは消えます。しかし、私の場合、次のエラーメッセージ[1]が上記の根本的な問題を指摘していたので、ついでに...
ステップ3: /etc/crypttabが正しい、破損していないパーティションを指していることを確認する
まず、sfdisk --list /dev/sdX
暗号化されたスワップパーティション(私の場合は/dev/sdX2)が実際にない(通常の) スワップ パーティションとして表示されます。 (私の場合のように) 表示される場合、これは、たとえばレスキュー ディスクを使用して起動すると、その利用可能なスワップ パーティションが使用される可能性が高くなり、cryptsetup 関連のメタデータ (キーフレーズと UUID) が上書きされることを意味します。
次に、/dev/disk/by-uuid を見て、暗号化されたパーティションのそれぞれの UUID を /etc/crypttab に含まれる UUID と比較します。この時点での私の推測では、あなたのケースでは不一致があります。
専用の暗号化されたスワップ パーティションが /dev/disk/by-uuid の下に見つからない場合は、現在レスキュー システムによって使用されているためです。その場合は、次の操作を行います。
- パーティションの使用を必ず停止してください。
swapoff -a
- フォーマットし直す:(
mkfs.ext2 /dev/sdX2
これは重要な特にGPTパーティション[2]を使用する場合は、前述の不具合が解消されます。sfdiskリストでパーティションが「swap」タイプとして表示される原因としては、mkswap /dev/sdX2
最初にパーティションを設定するときに誤って使用したことが考えられます。 - チュートリアルに従ってパーティションを暗号化し、パスフレーズを設定します。その後、cryptsetupを使用してパーティションを開き、適切に再フォーマットします。解読完了パーティション( のようなものを使用
mkswap /dev/mapper/swap
) sfdisk --list /dev/sdX
スワップパーティションをそのように識別しないようにします(その場合は、最後の手順を繰り返します)
ここで、/etc/crypttab にリストされている UUID が、それぞれの暗号化されたパーティションの /dev/disk/by-uuid の下に表示されるものと一致していることを再確認します。
繰り返しになりますが、変更を永続的にするには、update-initramfs
上記のように実行する必要があります。
満足したら、すべてがディスクに書き込まれたことを確認し、システムを再起動します (すべてを手動でアンマウントする必要はありません)。その後、問題は解決されるはずです。
[1] おそらく私は最初のエラーメッセージに注意を払っていなかったか、最初のエラーメッセージが2番目のエラーメッセージを「隠していた」use_lvmetad=0
のでしょう。つまり、再起動( )した後で初めて、「すべての物理ボリュームを読み取っています。しばらく時間がかかる場合があります...「(複数回繰り返し)」に続いて「警告! /dev/disk/by-uuid/... が存在しません。update-initramfs
「(パーティションが見つからないという苦情も寄せられたことに注意してください。)
[2] なぜなら、そのタイプは内容を分析することで推測され、最終的にはフラグ/バイトによって指定されるわけではないからです(そのため、たとえばを使用してGPTファイルシステムのタイプを変更する簡単な方法はありません[g]parted
)。
答え2
エラーFailed to connect to lvmetad
できるディスクが 100% いっぱいになっているために発生します。これを修正するには、USB サムドライブから起動し、いっぱいになったディスクをマウントし、不要なファイルを削除して再起動します。また、ブート システムも再インストールしましたが、それが必要かどうかはわかりません。
これらは、USB ドライブから起動した後にターミナルから実行して、私の場合問題を解決したコマンドです。フルドライブ暗号化を備えた標準の Ubuntu 18.04 を使用しています。結果は人によって異なります。
ドライブをマウントします。
sudo cryptsetup luksOpen /dev/sda5 sda5_crypt sudo vgscan --mknodes sudo vgchange -ay sudo mount /dev/mapper/ubuntu--vg-root /mnt
不要なファイルを削除する(
cd /mnt/home/your_username
...rm ...
)(必要ない場合もあります) ブート システムを再インストールします。
cd /mnt/ sudo mount /dev/sda1 boot for d in dev sys proc run; do sudo mount --bind /$d $d; done sudo vi etc/crypttab # make sure first line uses "sda5_crypt" sudo chroot . update-grub grub-install /dev/sda update-initramfs -u -k all exit sudo umount dev sys proc run boot
アンマウント:
cd / sudo umount /mnt sudo vgchange -an sudo cryptsetup close sda5_crypt
リブート:
sudo reboot
答え3
Ubuntu 18.04.1 LTS です。数か月間、無人で実行していましたが、戻ってきたときにキーボードが認識されないことに気付きました。再起動すると、「lvmetad に接続できません」というメッセージが表示され、「UEFI db リスト」を取得できないという詳細が表示されました。
ディスク暗号化なしでインストールしました。
UEFI メッセージは心配でした。UEFI コンピューターへのインストールは初めてだったので、経験がなく、正直に言ってまだその有用性についてよくわかっていません。問題は、'/' (ルート ボリューム) になる予定のボリュームに 'lvm' を使用していたことでさらに複雑になりました。(実際、最初にどうやってそれを実現したのか、もう忘れてしまいました。ああ、私は年寄りです。)
しかし、マシンが再起動しなかったので、解決策を探しましたが、決定的なものは何も見つかりませんでした。ただし、a) EFI パーティションが、あるサイトで推奨されている 500 MB より小さいこと、b) 別途用意した /boot/ パーティションがおそらく無関係で未使用であることに気付きました。おそらく、無人アップグレードによって、割り当てられたスペースが何かによって埋め尽くされた可能性があると考えました。
私は再インストールすることに決めました。これはうまくいき、/home/ ディレクトリ構造はそのまま残りました。/etc/ は確認していませんが、後で確認できるように、事前に両方のコピーを作成しました[1]。/etc/ は本当に小さいです。
また、EFI と /boot/ のパーティションを削除し、単一の大きな EFI パーティション (>750MB) に結合しました。
再起動はしましたが、1 つのエラー メッセージがあまりにも速く点滅して読めず、起動する Linux イメージの起動「メニュー」も表示されず、代わりに Ubuntu が直接起動します。この問題に対処するには、おそらく grub を使ってさらに作業する必要があります。しかし、少なくともファイルは戻りました。
[1] USBスティックからUbuntuのインストールを起動し、Ubuntuを「試す」ことを選択しました。これにより、デスクトップから「インストール」を選択する前に、etcとhomeのコピーを作成できました。
答え4
システムを USB または他のものから起動する必要はありません。私も同じ問題を抱えていましたが、その理由はディスクが 100% いっぱいだったからです。次の解決策が役に立ちました。
システムを再起動します。BIOS では、Shift キーをすばやく押したままにすると、GNU GRUB メニューが表示されます。
Ubuntuの設定を編集するには「e」を押します。この問題画面を見つけることができます。次のように、「linux *」で始まる文字列を見つけます。
linux /boot/vmlinuz-4-4.0-22-generic root=UUID=43ad24d3-e\ c5b-44ee-a099-a88eb9520989 ro quiet splash $vt_handoff
消去:
ro quiet splash $vt_handoff
そして次のように付け加えます:
init=/bin/bash
準備ができたら、Ctrl+xまたはF10を押して起動します。
ルートパーティションは読み取り専用でマウントされています。読み取り/書き込みでマウントするには、次のコマンドを入力します。
mount -o remount,rw /
何が問題だったのか調べる:
df -hT