「Fwupd」の版間の差分

2023年10月5日 (木) 10:28時点における版

サポートされているデバイスは [1] や [2] に記載されています。

インストール

fwupd パッケージをインストールしてください。

fwupdate を使用する場合は #UEFI BIOS のアップグレードを見てください。

グラフィカルフロントエンド

デスクトップ環境によっては fwupd が標準でサポートされています:

GNOME Software — GNOME 環境上で動作します。バックグラウンドで定期的に更新を確認しダウンロードを行います。ファームウエアがダウンロードされると GNOME Software に更新の実行確認を行うポップアップが表示されます。

https://wiki.gnome.org/Apps/Software || gnome-software

KDE Discover — Plasma 上で動作します。KDE Plasma 5.14 以降では KDE Discover 上で fwupd バックエンドが実装されました。他のシステムのアップデートと同様にファームウエアの更新も表示されます。

https://userbase.kde.org/Discover || discover

GNOME Firmware — fwupd がサポートするデバイスのファームウェアをアップグレード、ダウングレード、再インストールするためのアプリケーションです。ロックされた fwupd デバイスのロック解除、サポートされているデバイスのファームウェアの検証、fwupd デバイスの全リリースを表示することができます。

https://gitlab.gnome.org/hughsie/gnome-firmware-updater || gnome-firmware

使用方法

fwupd に検出されたデバイスを確認するには:

$ fwupdmgr get-devices

ノート: 上記のコマンドで出力されるデバイスの一部は fwupd でアップデートできない場合があります。例えば Intel の内蔵グラフィックはアップデートできません。

利用可能なアップデートのメタデータを更新するには:

$ fwupdmgr refresh

システムのアップデート一覧を確認するには:

$ fwupdmgr get-updates

アップデートをインストールするには:

$ fwupdmgr update

ノート:

再起動が必要ない更新はただちに適用されます。
起動時に実行される更新は次回再起動時に行なわれます。
アップデートによっては root 権限が必要になることがあります。

UEFI のアップグレードのセットアップ

警告: UEFI ファームウエアの更新によりブートローダーが破棄される可能性があります。更新完了後に NVRAM エントリを efibootmgr などで再生成する必要が生じる場合があります。

アップグレードする前に以下を確認してください:

マシンが UEFI モードで起動していることを確認してください。BIOS モードでは正しく動作しません。
EFI 変数にアクセスできることを確認してください。
EFI システムパーティション (ESP) が正しくマウントされていることを確認してください。この記事では ESP のマウントポイントを esp として表記します。

ESP の準備

fwupd は必要なファイルをすべて esp にコピーしますが、これが機能するには、基本的なフォルダーレイアウトが esp に存在する必要があります。; これにより、esp 上に EFI ディレクトリが作成されます。

ノート: ブートローダーまたは他のオペレーティングシステムの存在によっては、このディレクトリがすでに存在している可能性があります。

# mkdir esp/EFI/

警告: EFI ディレクトリはすべて大文字である必要があります。小文字を使用した場合、fwupd は esp を esp/efi/ として検出し、変わりに esp/efi/EFI/ を探す可能性があります。

その後、fwupd.service ユニットを再起動します。fwupdmgrfresh と fwupdmgr update ができるようになりました。再起動するように求められます (ファームウェアアップデーターを起動します)

ノート: Lenovo ThinkPad P50 ラップトップなどの一部のデバイスでは、ファームウェアアップデーターによって 何もメッセージが表示されない黒い画面 が表示されます。パニックにならないでください。また、中断しないでください。 アップデートに応じて数秒または数分後デバイスは、強制的にリセットされます。マシンは再起動されてオペレーティングシステムに戻ります。

セキュアブート

セキュアブートが有効な環境で fwupd EFI バイナリをチェーンロードするには shim が正しくインストールされていることが必要です。

自己署名証明書を使う

ファームウエア更新に使われる UEFI バイナリ /usr/lib/fwupd/efi/fwupdx64.efi を手動で署名する方法もあります。

sbsigntools を使うと署名されたバイナリ /usr/lib/fwupd/efi/fwupdx64.efi.signed が生成されます。

# sbsign --key <keyfile> --cert <certfile> /usr/lib/fwupd/efi/fwupdx64.efi

Pacman フックを使うと fwupdx64.efi の更新時に自動で署名できます:

/etc/pacman.d/hooks/sign-fwupd-secureboot.hook

[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/fwupd/efi/fwupdx64.efi

[Action]
When = PostTransaction
Exec = /usr/bin/sbsign --key <keyfile> --cert <certfile> /usr/lib/fwupd/efi/fwupdx64.efi
Depends = sbsigntools

<keyfile> や <certfile> は対応する鍵と証明書へのパスに置き換えます。

pacman hook を使わず、/usr/lib/fwupd/efi/fwupdx64.efi から /usr/lib/fwupd/efi/fwupdx64.efi.signed へシンボリックリンクを作成し /etc/sbupdate.conf の EXTRA_SIGN に追加する方法もあります。

最後に、/etc/fwupd/uefi.conf の DisableShimForSecureBoot を true に変更し fwupd.service サービスを再起動してください。 fwupd.service:

/etc/fwupd/fwupd.conf

...

[uefi_capsule]
DisableShimForSecureBoot=true

ノート: fwupd 1.9 より前にこれを設定した場合、このオプションは /etc/fwupd/uefi_capsule.conf にあります。

ノート: fwupd 1.4 以前を使う場合は設定オプションの名前が微妙に異なることに注意してください。

さらなる詳細は GitHub Issue を参照してください。

トラブルシューティング

再起動時にスタック

fwupdmgr update はエラーを報告しませんが、再起動を促すと電源ボタンを押したまま動かなくなり、何の反応もありません。電源を切るか、リセットボタン (ノートパソコンの場合、背面の穴) を押して、強制的に再起動してみてください。

エラーは出ないが再起動後も更新されない

現象: fwupdmgr update は正常に終了し (UEFI の更新などで) 再起動を求められた。しかし再起動してもファームウエア更新は行なわれなかった。

考えられる原因: 起動順序がBIOS で正しく設定されていない。

保留中の更新が複数ある場合に考えられる他の解決策: パッケージを 1つずつ更新してみてください。以下を使用してパッケージを選択します。:

$ fwupdmgr update update_ID

(update_ID は f95c9218acd12697af946874bfe4239587209232 のようなものです。)

読み取り専用ファイルシステムエラー

少なくとも、fwupdmgr 1.5.2 は、もし bind が esp を /boot [3] にマウントするために使用された場合、間違ったマウントポイントが推測されます。その結果、UEFI 更新ファイル /boot/EFI/arch/fw の書き込みに失敗します(fwupdmgr は esp/EFI/arch/fw に書き込みます)。これにより、(誤解を招く) "file system is read-only" というエラーメッセージが表示されます。Discover (またはその他の fwupd 対応アップデート GUI ) によって更新が実行された場合は、エラーや誤解を招くようなエラーは表示されない場合があります。

回避策としては、以前に esp/EFI/arch にバインドマウントされていた場合は最初に umount /boot を実行し、その後 fwupdmgr update を実行して UEFI 更新ファイルを esp/EFI/arch/fw に書き込み、mount /boot してシステムを再起動して UEFI 更新を実行します。

UEFI ESP パーティションが検出または設定されていない

fwupd#UEFI のアップグレードのセットアップのすべての要件を満たした後でも ESP パーティションが検出されない場合、マウントポイントを手動で指定することができます。

/etc/fwupd/uefi_capsule.conf

[uefi_capsule]
OverrideESPMountPoint=/efi   # 設定に合わせて変更

MSR プラグインを読み込めない

MSR プラグインは DCI の状態を問い合わせることができます。DCI は Intel CPU で利用可能なデバッグインターフェイスで、fwupd's documentation に従って本番マシンでは無効化されているはずです。

このプラグインは msr カーネルモジュールがロードされている必要があります。msr は全ての公式 Arch Linux カーネルパッケージのビルトインカーネルモジュールですが、非公式のカーネルパッケージではロード可能なカーネルモジュールとして存在しているかもしれません。後者の場合、起動時に明示的にモジュールを自動ロードする必要があります。

Failed to load daemon: failed to load engine: No ESP with path

fwupd は起動時に EspLocation という esp の場所を /etc/fwupd/daemon.conf から確認しています。このエラーが発生した場合は、対応する設定に変更してください。

@@ 58行目: / 58行目: @@
 === ESP の準備 ===
-fwupd は必要なファイルを ''esp'' 以下にコピーします。'EFI' デイレクトリが存在しない場合は作成してください:
+''fwupd'' は必要なファイルをすべて {{ic|''esp''}} にコピーしますが、これが機能するには、基本的なフォルダーレイアウトが {{ic|''esp'' に存在する必要があります。}};
+これにより、{{ic|''esp''}} 上に {{ic|EFI}} ディレクトリが作成されます。
+{{Note|ブートローダーまたは他のオペレーティングシステムの存在によっては、このディレクトリがすでに存在している可能性があります。}}
  # mkdir ''esp''/EFI/
-{{Warning|'EFI' ディレクトリは全て大文字でなければなりません。fwupd が ''esp'' を ''esp''/efi/ と誤認識し ''esp''/efi/EFI/ 以下を検索する可能性があります。}}
+{{Warning|{{ic|EFI}} ディレクトリはすべて大文字である必要があります。小文字を使用した場合、''fwupd'' は {{ic|''esp''}} を {{ic|''esp''/efi/}} として検出し、変わりに {{ic|''esp''/efi/EFI/}} を探す可能性があります。}}
+その後、{{ic|fwupd.service}} ユニットを [[再起動]] します。{{ic|fwupdmgrfresh}} と {{ic|fwupdmgr update}} ができるようになりました。再起動するように求められます (ファームウェアアップデーターを起動します)
-作成後、fwupd サービスを[[再起動]]してください。
- # systemctl restart fwupd.service
+{{Note|[[Lenovo ThinkPad P50]] ラップトップなどの一部のデバイスでは、ファームウェアアップデーターによって '''何もメッセージが表示されない黒い画面''' が表示されます。パニックにならないでください。また、'''中断しないでください。''' アップデートに応じて数秒または数分後デバイスは、強制的にリセットされます。マシンは再起動されてオペレーティングシステムに戻ります。}}
-そののち、{{ic|$ fwupdmgr refresh}} と {{ic|$ fwupdmgr update}} を実行すると、再起動が促されファームウエアが更新されます。
 === セキュアブート ===