web-dev-qa-db-ja.com

起動時に別のパーティションを自動マウントすると、systemd / udevの依存関係が失敗します

編集:これは、/varだけでなく、任意のマウントポイントで別のパーティションを使用しようとしたときに発生します。

Buildrootを使用して組み込みLinuxシステムを構築しています。/varに別のパーティションを使用しようとしていますが、これはすべてのマウントポイントで発生します。私のinitシステムはsystemd、デバイス管理用のudevです。 fstabを次のように編集しました。

# <file system> <mount pt>     <type>   <options>                <dump> <pass>
/dev/root       /              ext2     rw,noauto                0      1
/dev/mmcblk0p4  /var           ext2     defaults                 0      2
proc            /proc          proc     defaults                 0      0
devpts          /dev/pts       devpts   defaults,gid=5,mode=620  0      0
tmpfs           /dev/shm       tmpfs    mode=0777                0      0
tmpfs           /tmp           tmpfs    defaults                 0      0
sysfs           /sys           sysfs    defaults                 0      0
tmpfs           /run           tmpfs    defaults                 0      0

システムが起動すると、「デバイスdev-mmcblk0p4.device ... "が必要です。

"デバイスdev-mmcblk0p4.deviceの待機中にタイムアウトしました。"

"/ varの依存関係に失敗しました。"

"ローカルファイルシステムの依存関係に失敗しました。"


/var2の代わりにマウントポイントとして/varなどを使用した場合も、同じことが起こります。ブートが失敗すると、緊急モードに入り、マウントが正常に実行されます。その後、システムメンテナンスを終了でき、すべてが期待どおりに機能します。この遅延マウントの原因は何ですか?私は一歩を逃しましたか?

出力のスクリーンショット:

systemd startup

8
schumacher574

Exherbo(Gentooと同様)でカーネル3.13.1および3.14.4を使用してsystemd-208を使用すると、同様の問題が発生しました。個別のパーティション(/ var、/ home、/ boot、さらには/ swap)が目的のルートにマウントされました。ロケーション。すべてがうまくいきました。次に、systemd 213にアップグレードすると、パーティションがマウントされているはずのポイントでブートプロセスが停止し、「dev-sdxx.deviceの開始ジョブが1分30秒のタイムアウトまで実行されています」というメッセージが表示されます。その後、私は緊急モードになりました。の抜粋

$ journalctl -xb

Jun 09 13:50:29 exathlon systemd[1]: Job dev-disk-by\x2dlabel-BAK_A4.device/start timed out.
Jun 09 13:50:29 exathlon systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-BAK_A4.device.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /mnt/BAK_A4.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for Local File Systems.
Jun 09 13:50:29 exathlon systemd[1]: Triggering OnFailure= dependencies of local-fs.target.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /export/LinuxMint13_KDE_64.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /export/SystemRescueCD-x86.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for File System Check on /dev/disk/by-label/BAK_A4.
Jun 09 13:50:29 exathlon systemd[1]: Job dev-sdb11.device/start timed out.
Jun 09 13:50:29 exathlon systemd[1]: Timed out waiting for device dev-sdb11.device.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /var.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for Update UTMP about System Boot/Shutdown.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for Load/Save Random Seed.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for File System Check on /dev/sdb11.
Jun 09 13:50:29 exathlon systemd[1]: Job dev-sdb8.device/start timed out.
Jun 09 13:50:29 exathlon systemd-journal[1044]: Forwarding to syslog missed 15 messages.
Jun 09 13:50:29 exathlon systemd[1]: Timed out waiting for device dev-sdb8.device.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /home.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for File System Check on /dev/sdb8.
Jun 09 13:50:29 exathlon systemd[1]: Job dev-sda6.device/start timed out.
Jun 09 13:50:29 exathlon systemd[1]: Timed out waiting for device dev-sda6.device.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /boot.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for File System Check on /dev/sda6.
Jun 09 13:50:29 exathlon systemd[1]: Job dev-sdb5.device/start timed out.
Jun 09 13:50:29 exathlon systemd[1]: Timed out waiting for device dev-sdb5.device.
Jun 09 13:50:29 exathlon systemd[1]: Dependency failed for /dev/sdb5.

systemdによるマウントの失敗した試行を示しています。

インターネットを調べた後、カーネルを構成する際の解決策を見つけることができました。

CONFIG_FHANDLE=y (before: n)

下の「systemdSystemandServiceManager」を参照してください。

REQUIREMENTS:
 CONFIG_FHANDLE (libudev, mount and bind mount handling)

ソース: http://cgit.freedesktop.org/systemd/systemd/tree/README

その後、問題は解決され、すべてのパーティションが再度マウントされました。

なぜこれが起こらなかったのか、またはsystemd208では必要なかったのかわかりません。

11
marsh

一種のハックですが、これを回避することができました。そもそもなぜこれが発生しているのか知りたいのですが、systemdのinitが完了するまでudevがmmcblkパーティションをマウントしていないように見えます。これにより、/etc/fstabがmmcblkパーティションを呼び出すと、依存関係エラーが発生します。 udevはfstabをチェックし、mmcblkデバイスがマウントされるのを待ってタイムアウトします、[〜#〜] then [〜#〜]デバイスのマウントを試みます。

私の解決策:

1)パーティションのマウントを処理するsystemdサービスを作成します。

#/etc/systemd/system/mount-data-partition.service
[Unit]
Description=Mount Data Partition
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount /dev/mmcblk0p4


2)systemd-udev-trigger.service内のこのサービスにWants依存関係を追加します。

#/usr/lib/systemd/system/systemd-udev-trigger.service
[Unit]
Description=udev Coldplug all Devices
Documentation=man:udev(7) man:systemd-udevd.service(8)
DefaultDependencies=no
Wants=systemd-udevd.service mount-data-partition.service
After=systemd-udevd-kernel.socket systemd-udevd-control.socket
Before=sysinit.target
ConditionCapability=CAP_MKNOD

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger


これにより、mount-data-partition.serviceが呼び出され、systemd-udev-trigger.serviceの前に実行されます。次に、mountコマンドは/dev/mmcblk0p4/etc/fstabを検索し、指定されたとおりにマウントします(私の状況では/var)。 /dev/mmcblk0p4がマウントされたので、udevはデバイスが存在することを認識し、それを待っている間にタイムアウトしなくなりました。システムは通常どおり起動し続けます。

私は自分の質問に答えるのは嫌いですが、この情報が誰かを助けてくれることを願っています。そもそもなぜこれが起こっているのか、誰かが私に教えてくれるなら、そうしてください。

4
schumacher574