fwupd
fwupd はデバイスのファームウェアをアップデートするためのシンプルなデーモンです。fwupdate で UEFI BIOS をアップデートできます。
サポートされているデバイスは [1] や [2] に記載されています。
目次
インストール
fwupdate を使用する場合は #UEFI BIOS のアップグレードを見てください。
グラフィカルフロントエンド
デスクトップ環境によっては fwupd が標準でサポートされています:
- GNOME Software — GNOME 環境上で動作します。バックグラウンドで定期的に更新を確認しダウンロードを行います。ファームウエアがダウンロードされると GNOME Software に更新の実行確認を行うポップアップが表示されます。
- KDE Discover — Plasma 上で動作します。KDE Plasma 5.14 以降では KDE Discover 上で fwupd バックエンドが実装されました。他のシステムのアップデートと同様にファームウエアの更新も表示されます。
- GNOME Firmware — fwupd がサポートするデバイスのファームウェアをアップグレード、ダウングレード、再インストールするためのアプリケーションです。ロックされた fwupd デバイスのロック解除、サポートされているデバイスのファームウェアの検証、fwupd デバイスの全リリースを表示することができます。
使用方法
fwupd に検出されたデバイスを確認するには:
$ fwupdmgr get-devices
利用可能なアップデートのメタデータを更新するには:
$ fwupdmgr refresh
システムのアップデート一覧を確認するには:
$ fwupdmgr get-updates
アップデートをインストールするには:
$ fwupdmgr update
UEFI のアップグレードのセットアップ
アップグレードする前に以下を確認してください:
- マシンが UEFI モードで起動していることを確認してください。BIOS モードでは正しく動作しません。
- EFI 変数にアクセスできることを確認してください。
- EFI システムパーティション (ESP) が正しくマウントされていることを確認してください。この記事では ESP のマウントポイントを
espとして表記します。
ESP の準備
fwupd は必要なファイルをすべて esp にコピーしますが、これが機能するには、基本的なフォルダーレイアウトが esp に存在する必要があります。;
これにより、esp 上に EFI ディレクトリが作成されます。
# mkdir esp/EFI/
その後、fwupd.service ユニットを 再起動 します。fwupdmgrfresh と fwupdmgr update ができるようになりました。再起動するように求められます (ファームウェアアップデーターを起動します)
セキュアブート
セキュアブートが有効な環境で 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
さらなる詳細は 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 から確認しています。このエラーが発生した場合は、対応する設定に変更してください。