web-dev-qa-db-ja.com

Archcryptsetupが「ゼロ待ち」でハングする

Cryptsetupは何ヶ月も問題なく動作していましたが、今日システムで行ったことがハングアップしました。

# cryptsetup --debug --verbose luksOpen /dev/sdb home --key-file=/home.key --verbose
...
Key slot 1 unlocked.
...
# Udev cookie 0xd4d949a (semid 32768) decremented to 1
# Udev cookie 0xd4d949a (semid 32768) waiting for zero

また、lsblk -fを実行すると、以前はすべてのデバイス(sdbを含む)のUUIDを取得していましたが、現在はrootfsのUUIDとFSTYPEのみを取得しています(他のすべてのデバイスがリストされていますが、FSTYPE 、LABEL、およびUUIDは空です)。ただし、blkidはすべてのデバイスのUUIDを表示します。

また、ネットワークデバイスも表示されません。eth0wlp4s0ip linkifconfigにありません。

元のライブUSBから起動すると、すべてが完全に機能します。すべてのパーティションをマウントし、WiFiに接続して、壊れたシステムにArch-chrootすることができます。その後、pacman -Syuuを実行し、今日インストールしたすべてのパッケージ(f2fs-toolsexfat-utilsFuse-exfat)をアンインストールし、initramfsをmkinitcpio -p linuxで更新しました。

3
cronburg

私の愚かさ.bash_history

#1448399392
chroot rootfs /bin/bash -x <<'EOF'
ln -s /dev/null /etc/systemd/system/systemd-udevd.service
ln -s /dev/null /etc/systemd/system/systemd-udevd-control.socket
ln -s /dev/null /etc/systemd/system/systemd-udevd-kernel.socket
ln -s /dev/null /etc/systemd/system/proc-sys-fs-binfmt_misc.automount
exit
EOF

恐ろしい恐ろしいシンボリックリンクを削除し、すべてが正常になりました。 LXCコンテナ内ではなく、メインシステムで上記のリンクを誤って実行しました。 ( https://wiki.archlinux.org/index.php/Linux_Containers#Systemd_conflicts_in_the_.2Fdev_tree

1
cronburg

このUdev cookie ... waiting for zeroは、次の条件のいずれかが当てはまる場合にも発生します。

  1. ディストリビューションに/lib/udev/rules.d/${NUMBER}-dm.rulesファイルがありません。少なくとも、Ubuntu 15.10Wilyでは${NUMBER}55です。 ( 詳細
  2. udevSudo service udev startで開始する必要があります
  3. udevは実行中ですが、Sudo service udev restartで再起動する必要があります(システムのマウントされたボリュームの状態を何らかの方法で変更し、Udevがその状態をリセットする必要があるため)
1
Neil