fwupd

提供: ArchWiki
ナビゲーションに移動 検索に移動

関連記事

fwupd はデバイスのファームウェアをアップデートするためのシンプルなデーモンです。fwupdate で UEFI BIOS をアップデートできます。

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

インストール

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

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

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

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

  • GNOME SoftwareGNOME 環境上で動作します。バックグラウンドで定期的に更新を確認しダウンロードを行います。ファームウエアがダウンロードされると GNOME Software に更新の実行確認を行うポップアップが表示されます。
https://wiki.gnome.org/Apps/Software || gnome-software
  • KDE DiscoverPlasma 上で動作します。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 デーモンを自動的に起動する fwupd.service を提供します。 [3]

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

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

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

$ fwupdmgr refresh

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

$ fwupdmgr get-updates

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

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

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

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

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

  1. マシンが UEFI モードで起動していることを確認してください。BIOS モードでは正しく動作しません。
  2. EFI 変数にアクセスできること を確認してください。
  3. EFI システムパーティション (ESP) が正しくマウントされていることを確認してください。この記事では ESP のマウントポイントを esp として表記します。
  4. オプションの依存関係 udisks2 がインストールされていること、および関連する systemd ユニットが fwupd ユニットの前に起動されていることを確認してください。UEFI ファームウェアのアップグレードサポートが提供されます。

ESP の準備

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

ノート: ブートローダーまたは他のオペレーティングシステムの存在によっては、このディレクトリがすでに存在している可能性があります。
# mkdir esp/EFI/
警告: EFI ディレクトリはすべて大文字である必要があります。小文字を使用した場合、fwupdespesp/efi/ として検出し、変わりに esp/efi/EFI/ を探す可能性があります。

その後、fwupd.service ユニットを 再起動 します。fwupdmgrfreshfwupdmgr 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.confEXTRA_SIGN に追加する方法もあります。

最後に、/etc/fwupd/uefi.confDisableShimForSecureBoottrue に変更し 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_IDf95c9218acd12697af946874bfe4239587209232 のようなものです。)

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

少なくとも、fwupdmgr 1.5.2 は、もし bind が esp/boot [4] にマウントするために使用された場合、間違ったマウントポイントが推測されます。その結果、UEFI 更新ファイル /boot/EFI/arch/fw の書き込みに失敗します(fwupdmgresp/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 から確認しています。このエラーが発生した場合は、対応する設定に変更してください。