まえがき
仕事で「Dell Latitude 3420」の「Build Your Own」という Ubuntu 20.04 をプリインストールして出荷してくれるタイプのPCを長期間に渡って利用していました。
このPCと一緒にDell純正の「WD19TB」というドッキングステーションもあわせて利用していました。
「Dell Latitude 3420」を長期に渡って利用していたこともあり、その中で Ubuntu のバージョンを 20.04 から 22.04 にアップデートするといったことも行っていましたが、「Dell Latitude 3420」と「WD19TB」の併用は特に問題なく動作していました。
しかしながら、4年半ほど利用しているとスペックやディスクサイズの面で厳しい部分が多々発生することもあり、会社用のPCを「Lenovo ThinkPad X13 Gen 7」に移行することとなりました。
Lenovo では Ubuntu OS をプリインストールする形での販売は行っていないため、手元に届いた後で Ubuntu 24.04 をインストールする形で利用しています。
※インストール時点では Ubuntu 26.04 LTS のポイントリリースとなる 26.04.1 が提供されていなかったため、 Ubuntu 26.04 のインストールは見送りました。
会社用のPCということもあり Linux の LUKS(Linux Unified Key Setup) と呼ばれるストレージの暗号化の仕組みを適用した状態で利用しているのですが、この場合は PC の起動時に LUKS のパスワードと Linux アカウントのパスワードを入力する必要があります。
ここで問題発生です。
「Dell Latitude 3420」の場合は起動直後に「WD19TB」をすぐに認識して、「WD19TB」に接続している外付けキーボードで LUKS と Linux アカウントのパスワード入力を行うことができたのですが、「Lenovo ThinkPad X13 Gen 7」の場合は LUKS のパスワード入力の際になぜか外付けキーボードでパスワード入力を行うことができす、本体のキーボードでしか入力を受け付けてくれません。
LUKS の認証が通ったあとにようやく「WD19TB」が認識されるようで、 Linux アカウントのパスワード入力の際は外付けキーボードでの入力が可能となります。
なので、 Lenovo の PC を起動する度に本体側の内蔵キーボードと外付けキーボードを行ったり来たりしている状態でして、これがなかなか地味に使い勝手の悪さを生んでいます。
ということで、今回はこの問題を解消してきたいと思います。
事前調査
AI に今回の事象について聞いてみたところ、どうやら割とポピュラーに発生する問題のようで、非常に近しい事例を発見することができました。
問題の原因（と思われるもの）
Ubuntu では Thunderbolt の機器を管理するための bolt という仕組みがあり、この bolt によって接続されたデバイスの認可や制限を行っています。
どうやら、 LUKS のパスワード入力画面の時点では bolt のデーモンである boltd がまだ起動していないので、 bolt による認可が行えないため、外付けキーボードが何も反応しない状態になっており、LUKS の認証を経た後の Linux アカウントのパスワードであれば boltd が起動しているためデバイスの認可が完了し、そこでようやく外付けキーボードが使用可能な状態になっているというのが、今回の原因のようです。
解決編
では、 AI に色々と聞きながら今回の問題を解決していこうと思います。
まず、 boltctl domains の実行結果の提示を求めらました。
「domain0」と「domain1」が表示されていますが、これはPC本体に2つの Thunderbolt のポートがあることを示しているようです。
実行結果を確認すると、両方とも「bootacl: 0/0」となっています。
BootACL(Pre-boot Access Control List) は登録済みの Thunderbolt 機器を OS が起動する前に認証するための仕組みで、その値が「0/0」ということは BootACL に非対応であることを意味しています。
つまり、 boltctl enroll で対象の機器を登録しても、 LUKS のパスワード入力画面では利用できないということです。
$ boltctl domains
● domain0 XXXXXXXX-90a6-XXXX-XXXX-XXXXXXXXXXXX
├─ bootacl: 0/0
└─ security: iommu+user
● domain1 XXXXXXXX-91a6-XXXX-XXXX-XXXXXXXXXXXX
├─ bootacl: 0/0
└─ security: iommu+user
次に boltctl list の実行を求められました。
このコマンドは現在接続中の Thunderbolt 機器と boltd に登録済みの機器を一覧表示します。
「domain」の値が先程の boltctl domains の「domain0」と一致しているので、「domain0」のポートに「WD19TB」が接続されているということがわかります。
また、「policy: iommu」となっています。 IOMMU(Input/Output Memory Management Unit) は周辺機器がメモリにアクセスする範囲を制御する仕組みで、この機器は IOMMU に対応しているということを意味し、 DMA(Direct Memory Access) 保護が効いているという状態になっています。
$ boltctl list
● Dell WD19TB Thunderbolt Dock
├─ type: peripheral
├─ name: WD19TB Thunderbolt Dock
├─ vendor: Dell
├─ uuid: c1010000-XXXX-XXXX-XXXX-XXXXXXXXXXXX
├─ generation: Thunderbolt 3
├─ status: authorized
│ ├─ domain: XXXXXXXX-90a6-XXXX-XXXX-XXXXXXXXXXXX
│ ├─ rx speed: 40 Gb/s = 2 lanes * 20 Gb/s
│ ├─ tx speed: 40 Gb/s = 2 lanes * 20 Gb/s
│ └─ authflags: none
├─ authorized: 2026年11月03日 01時00分55秒
├─ connected: 2026年11月03日 01時00分31秒
└─ stored: 2026年09月03日 12時28分13秒
├─ policy: iommu
└─ key: no
なお、「domain0」に対する IOMMU による DMA 保護については、以下のコマンドでも確認可能で、結果が「1」であれば DMA 保護が有効であることを表しています。
$ cat /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection
1
boltctl domains の結果でもう一点重要な情報として「security: iommu+user」と表示されていました。
これは以下のコマンドでも同様の内容が確認できるのですが、セキュリティレベルが「user」ということは、 boltd が認可を行うまでは機器が利用できないということになります。
$ cat /sys/bus/thunderbolt/devices/domain0/security
user
では、どうしたらいいの？という話になるのですが、こういった場合に対応するためのバイパスの仕組みが提供されています。
ただし、以下の内容をよく理解した上で設定を行う必要があります。
This will authorize all devices automatically when they appear. However, keep in mind that this bypasses the security levels and makes the system vulnerable to DMA attacks.
The Linux Kernel documentationの「USB4 and Thunderbolt」のページでは以下のように「/etc/udev/rules.d/99-local.rules」を作成する例が記載されており、これによって LUKS のパスワード入力時点でも Thunderbolt 機器が認可された状態になるようです。
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"
例示されている内容を元に以下のようなコマンドを実行しようかと思ったのですが、これではどの機器も認可してしまうことになり少々不安です。
$ sudo tee /etc/udev/rules.d/99-thunderbolt-authorize.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"
EOF
ということで「WD19TB」のみを認可する方法を AI に聞いてみたところ、以下の方法で実現できそうだとわかりました。
「ATTR{unique_id}」に boltctl list の結果の「uuid」を指定することで、認可する機器を「WD19TB」のみとしています。
$ sudo tee /etc/udev/rules.d/99-thunderbolt-authorize.rules <<'EOF'
# Dell WD19TB
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{unique_id}=="c1010000-XXXX-XXXX-XXXX-XXXXXXXXXXXX", ATTR{authorized}=="0", ATTR{authorized}="1"
EOF
[sudo] akase244 のパスワード:
# Dell WD19TB
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{unique_id}=="c1010000-XXXX-XXXX-XXXX-XXXXXXXXXXXX", ATTR{authorized}=="0", ATTR{authorized}="1"
準備が整いましたので、この状態で再起動してみると。。。うまくいきませんでした。
どうやら、「/etc/udev/rules.d」配下に設置したファイル群は OS 起動後に読み込まれる仕組みのようで、 LUKS のパスワード入力時には有効化されないようです。
「initramfs(initial RAM filesystem)」は、Linux カーネルが起動した直後、本来のルートファイルシステムをマウントするまでの間だけで使うメモリ上の小さなルートファイルシステムで、 LUKS などの起動初期に使われるものとなります。
lsinitramfs は、その initramfs に格納されているファイル群を参照するコマンドになっており、 lsinitramfs を実行してみると、先程の /etc/udev/rules.d/99-thunderbolt-authorize.rules が読み込まれていないことが確認できます。
$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'thunderbolt|rules\.d/99'
usr/lib/modules/7.0.0-38-generic/kernel/drivers/net/thunderbolt
usr/lib/modules/7.0.0-38-generic/kernel/drivers/net/thunderbolt/thunderbolt_net.ko.zst
usr/lib/modules/7.0.0-38-generic/kernel/drivers/thunderbolt
usr/lib/modules/7.0.0-38-generic/kernel/drivers/thunderbolt/thunderbolt.ko.zst
usr/lib/modules/7.0.0-38-generic/kernel/drivers/usb/typec/altmodes/typec_thunderbolt.ko.zst
ということで、 /etc/udev/rules.d/99-thunderbolt-authorize.rules は不要になったので削除しておきます。
$ sudo rm /etc/udev/rules.d/99-thunderbolt-authorize.rules
initramfs に読み込まれる形で /etc/udev/rules.d/99-thunderbolt-authorize.rules のような設定を準備する必要がありますが、 man initramfs-tools を参照すると、それっぽいサンプルが例示されています。
$ man initramfs-tools
・
・
CONFIGURATION HOOK SCRIPTS
Configuration hook scripts can be found in /usr/share/initramfs-tools/conf-hooks.d. They are sourced by mkinitramfs after the
configuration files in /etc and before running any hook scripts. They can override any of the variables documented in
initramfs.conf(5), but this should be done only if absolutely necessary. For example, if a package's boot script requires com‐
mands not provided by klibc-utils, it should also install a configuration hook that sets BUSYBOX=y.
HOOK SCRIPTS
Hooks can be found in two places: /usr/share/initramfs-tools/hooks and /etc/initramfs-tools/hooks. They are executed during gener‐
ation of the initramfs-image and are responsible for including all the necessary components in the image itself. No guarantees are
made as to the order in which the different scripts are executed unless the prereqs are setup in the script. Please notice that
PREREQ is only honored inside a single directory. So first the scripts in /usr/share/initramfs-tools are ordered according to
their PREREQ values and executed. Then all scripts in /etc/initramfs-tools are ordered according to their PREREQ values and exe‐
cuted. This mean that currently there is no possibility to have a local script (/etc/initramfs-tools) get executed before one from
the package (/usr/share/initramfs-tools).
If a hook script requires configuration beyond the exported variables listed below, it should read a private configuration file
that is separate from the /etc/initramfs-tools directory. It must not read initramfs-tools configuration files directly.
・
・
Exported variables
mkinitramfs sets several variables for the hook scripts environment.
MODULESDIR
corresponds to the linux modules dir.
version
is the $(uname -r) linux version against mkinitramfs is run.
CONFDIR
is the path of the used initramfs-tools configurations.
DESTDIR
is the root path of the newly build initramfs.
DPKG_ARCH
allows arch specific hook additions.
verbose
corresponds to the verbosity of the update-initramfs run.
BUSYBOX, MODULES
are as described in initramfs.conf(5).
BUSYBOXDIR
is the directory where busybox utilities should be installed from, or empty if busybox is not being used.
・
・
EXAMPLES
Hook script
An example hook script would look something like this (and would usually be placed in /etc/initramfs-
tools/hooks/frobnicate):
#!/bin/sh
# Example frobnication hook script
PREREQ="lvm"
prereqs()
{
echo "$PREREQ"
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line
if [ ! -x "/sbin/frobnicate" ]; then
exit 0
fi
force_load frobnicator interval=10
copy_exec /sbin/frobnicate /sbin
exit 0
・
・
上記の情報を元にして AI に提示してもらったのがこのコマンドです。
$ sudo tee /etc/initramfs-tools/hooks/thunderbolt-dock-auth <<'EOF'
#!/bin/sh
PREREQ="udev"
prereqs() { echo "$PREREQ"; }
case "$1" in
prereqs) prereqs; exit 0 ;;
esac
. /usr/share/initramfs-tools/hook-functions
mkdir -p "${DESTDIR}/usr/lib/udev/rules.d"
cat > "${DESTDIR}/usr/lib/udev/rules.d/99-thunderbolt-dock-auth.rules" <<'RULES'
# Dell WD19TB
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{unique_id}=="c1010000-XXXX-XXXX-XXXX-XXXXXXXXXXXX", ATTR{authorized}=="0", ATTR{authorized}="1"
RULES
force_load thunderbolt
manual_add_modules xhci_pci usbhid hid_generic
EOF
/etc/initramfs-tools/hooks/thunderbolt-dock-auth に実行権限を付与します。
$ sudo chmod +x /etc/initramfs-tools/hooks/thunderbolt-dock-auth
以下のコマンドで initramfs の内容を更新します。
$ sudo update-initramfs -u -k all
改めて lsinitramfs を実行してみると、先程の /etc/initramfs-tools/hooks/thunderbolt-dock-auth のスクリプトの中で作成している ${DESTDIR}/usr/lib/udev/rules.d/99-thunderbolt-dock-auth.rules が読み込まれていることが確認できます。
$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'thunderbolt|rules\.d/99'
usr/lib/modules/7.0.0-38-generic/kernel/drivers/net/thunderbolt
usr/lib/modules/7.0.0-38-generic/kernel/drivers/net/thunderbolt/thunderbolt_net.ko.zst
usr/lib/modules/7.0.0-38-generic/kernel/drivers/thunderbolt
usr/lib/modules/7.0.0-38-generic/kernel/drivers/thunderbolt/thunderbolt.ko.zst
usr/lib/modules/7.0.0-38-generic/kernel/drivers/usb/typec/altmodes/typec_thunderbolt.ko.zst
usr/lib/udev/rules.d/99-thunderbolt-dock-auth.rules
さて、今度はうまくいくでしょうか？
意を決して再起動してみると。。。 LUKS のパスワード入力画面で外付けキーボードが反応しました！
つまり、LUKS のパスワード入力画面の時点で「WD19TB」を認識させることに成功しました！！
あとがき
「Dell Latitude 3420」や「system76 Lemur Pro 14"」のように、自宅ではいくつかのノートPCで Ubuntu を利用していましたが、これらの PC では同様の問題は発生しておらず、今回初めて遭遇する現象だったため、解決への糸口が掴めず苦労しました。
以前であれば、こういったデバイス系のトラブルは海外の web サイトの情報を頼りになんとか解決するという方法しかありませんでしたが、今は AI があるおかげでこのようなトラブルに対してもかなり確度の高い情報を提示してくれるため、対応が随分楽になってきていますね。
AI の力を多分に借りることにはなりましたが、無事に解決できてよかったです。