1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@honda-dev-jp

古いLIFEBOOKをUbuntu開発機にする【8. 躓いたポイント集】

1
Posted at

目次

はじめに

メインPCのDELLでフリーズやWSL切断などの不調が発生し、修理・切り分け中もLaravel開発を止めないため、以前使用していた古いLIFEBOOKをUbuntu開発機として再利用しています。

これまでのシリーズでは、UbuntuのインストールからOpenSSH Server、VS Code Remote - SSH、Docker Engine、Samba、VS Code本体、LibreOfficeまで順番に環境を整えてきました。

今回使用しているLIFEBOOKは、

FUJITSU LIFEBOOK AH52/C
Intel Pentium P6200 2.13GHz
2コア / 2スレッド
メモリ8GB
256GB SSD

という古いハードウェアです。

一方、実際にUbuntu開発機として使い続けていると、ソフトウェアのインストール手順だけでは済まない問題もいくつか発生しました。

今回の第8回では、これまでの運用中に実際に遭遇した、

App Center
  └─ OpenGL関連エラー

Firefox
  └─ 描画が重い / GPU・WebRenderの確認

バッテリー
  └─ 交換後に充電が始まらない

蓋閉じ
  ├─ SSHが切断される
  └─ Wi-Fiが切断され機内モード相当になる

という躓きをまとめます。

この記事では、単に「古いPCだから仕方がない」と判断せず、

症状
  ↓
現在状態を実測
  ↓
ログ・設定を確認
  ↓
変更する条件を限定
  ↓
対処
  ↓
実機で再確認

という流れで切り分けた記録を残します。

この記事に記載する結果は、今回使用したLIFEBOOK実機で確認したものです。

「古いPCでは必ず同じ問題が発生する」「古いPCでは必ずGPU機能を無効化する必要がある」という意味ではありません。

また、最後に扱う蓋閉じ時の機内モード相当への切り替えについては、原因を特定できないまま追加検証を終了し、安定運用を優先して有線LANへ切り替えています。

今回の環境

今回の記事で扱うLIFEBOOKの主な環境は次のとおりです。

項目 内容
PC 富士通 LIFEBOOK AH52/C
型名 FMVA52CBJ
CPU Intel Pentium P6200 2.13GHz
CPUコア数 2コア / 2スレッド
メモリ 8GB
ストレージ 256GB SSD
OS Ubuntu 24.04.4 LTS Desktop（各トラブル発生時）
更新後OS Ubuntu 24.04.5 LTS
Kernel Linux 7.0.0-31-generic
Architecture x86_64
Ubuntuユーザー honta
Wi-Fiドライバ ath9k
Wi-Fiインターフェース wlp16s0

第7回のLibreOffice検証開始時点ではUbuntu 24.04.4 LTSを使用していました。

その後、主要ライブラリのセキュリティ更新を適用し、再起動後にはUbuntu 24.04.5 LTSになっていることを確認しています。

そのため、この記事では各トラブルが発生した時点の実測値を優先して記録します。

今回まとめる内容

今回まとめるのは次の5項目です。

1. App CenterがOpenGL関連エラーで起動しない

2. Firefoxが重いためGPU・描画状態を確認する

3. バッテリー交換後に充電が始まらない

4. 蓋を閉じるとSSHが切断される

5. 蓋閉じ時にWi-Fiが切断され
   機内モード相当になる
   └─ 原因未特定のまま検証終了
      有線LAN運用へ切り替え

VS CodeでもGPUアクセラレーションを使わない構成への変更を行いましたが、この内容は第6回「VS Code導入・GPU対策編」で扱っているため、今回は重複して掲載しません。

1. App CenterがOpenGL関連エラーで起動しない

1.1 発生した症状

UbuntuのApp Centerをターミナルから起動しました。

snap-store

すると、次のOpenGL関連エラーが表示され、App Centerが起動できませんでした。

Gdk-Message: Unable to load from the cursor theme
No provider of glBlitFramebuffer found.  Requires one of:
    Desktop OpenGL 3.0
    GL_ARB_framebuffer_object
    OpenGL ES 3.0
    GL_EXT_framebuffer_blit
    GL_NV_framebuffer_blit
中止 (コアダンプ)

ここでは、実際に、

No provider of glBlitFramebuffer found

というOpenGL関連のエラー文字列を確認できています。

そのため、まずOpenGLを使用しない条件で挙動が変わるかを確認しました。

1.2 App Centerの導入状態を確認する

App CenterはSnap版を使用していました。

snap list snap-store

実機では次の状態でした。

Name        Version         Rev   Tracking    Publisher   Notes
snap-store  0+git.8334e2e4  1390  2/stable/…  canonical✓  -

App Center自体が未導入だったわけではありません。

1.3 一時的にソフトウェア描画で起動する

まず、設定を恒久変更せず、一時的にソフトウェア描画を指定しました。

LIBGL_ALWAYS_SOFTWARE=1 snap-store

この条件では、

App Center起動成功

となりました。

起動中には、

ratings.ubuntu.com
Connection refused

という接続エラーも表示されました。

ただしApp Center本体は開いたため、この接続エラーをApp Center起動不能の直接原因とは判断していません。

確認できたのは、

通常起動
  ↓
OpenGL関連エラー
  ↓
起動失敗

LIBGL_ALWAYS_SOFTWARE=1
  ↓
起動成功

という差です。

1.4 OpenGL interfaceの接続状態を確認する

次に、SnapのOpenGL interfaceがどのように接続されているか確認しました。

snap connections snap-store | grep opengl

変更前は次の状態でした。

opengl  snap-store:opengl  :opengl  -

CanonicalのSnap公式ドキュメントでは、snap connections でSnapが使用しているinterfaceの接続状態を確認できると説明されています。

判断元URL：

公式記載：

The snap connections command lists which interfaces are connected and being used.

今回も、設定変更前に接続状態を確認してから作業を進めました。

1.5 App CenterのOpenGL interfaceを切断する

今回の実機では、次のコマンドでApp CenterのOpenGL interfaceを切断しました。

sudo snap disconnect snap-store:opengl

再確認します。

snap connections snap-store | grep opengl

変更後は次の状態になりました。

opengl  snap-store:opengl  -  -

Snap公式ドキュメントでも、interfaceを切断するコマンドとして snap disconnect が案内されています。

判断元URL：

公式記載：

To disconnect an interface, use snap disconnect.

snap disconnect はSnapのinterface接続状態を変更します。

今回の実機でApp Centerが起動したという結果だけを根拠に、他のUbuntu環境でも同じ設定変更を推奨するものではありません。

1.6 通常起動を再確認する

OpenGL interfaceを切断した状態で、特別な環境変数を付けずに起動しました。

snap-store

結果、

App Center起動成功

となりました。

さらにUbuntuのアプリ一覧からApp Centerを起動した場合も、正常に画面が開くことを確認しました。

今回確認できた最終状態は、

snap-store:opengl
  ↓
disconnect
  ↓
snap-storeを通常起動
  ↓
起動成功
  ↓
Ubuntuのアプリ一覧からも起動成功

です。

1.7 元に戻す方法

設定を元へ戻す場合は、OpenGL interfaceを再接続します。

sudo snap connect snap-store:opengl

設定変更を記事へ記録する場合は、変更方法だけでなくロールバック方法も残しておきます。

なお、Snap公式ドキュメントでは、手動で切断した自動接続interfaceの切断状態はSnap refresh後も保持されると説明されています。

判断元URL：

公式記載：

its disconnected state is retained after a snap refresh.

そのため、今回の設定を後から戻したい場合に備えて、再接続コマンドも記録しておきます。

1.8 切り分けの時系列

snap-storeを通常起動
  ↓
No provider of glBlitFramebuffer found
  ↓
起動失敗
  ↓
LIBGL_ALWAYS_SOFTWARE=1 snap-store
  ↓
起動成功
  ↓
snap connectionsでopengl接続状態を確認
  ↓
snap-store:opengl → :opengl
  ↓
sudo snap disconnect snap-store:opengl
  ↓
接続状態を再確認
  ↓
snap-storeを通常起動
  ↓
起動成功
  ↓
アプリ一覧からも起動成功

今回のApp Centerについては、明示的なOpenGL関連エラーを実際に確認し、OpenGLを使用しない条件へ変更したあとに起動できたところまで確認できました。

2. Firefoxが重いためGPU・描画状態を確認する

2.1 発生した症状

LIFEBOOKでFirefoxを使用していると、Webページの操作が重く感じることがありました。

VS CodeやApp CenterではGPU / OpenGLを使用しない構成へ変更したため、FirefoxについてもGPUアクセラレーションの状態を確認することにしました。

ただし、Firefoxでは設定画面だけで判断せず、まずFirefox自身がどの描画経路を使用しているかを確認しました。

2.2 Mozilla公式のパフォーマンス設定を確認する

Mozilla公式では、Firefoxの「パフォーマンス」設定からハードウェアアクセラレーションを変更する方法が案内されています。

判断元URL：

公式記載：

Hardware acceleration: Lets Firefox use your computer’s graphics processor (GPU).

また、設定項目が表示されない場合についても説明されています。

公式記載：

Firefox hides hardware acceleration if your graphics driver isn’t compatible.

今回のLIFEBOOKでは、設定画面だけでは状態を判断しにくかったため、about:support の「グラフィックス」を確認しました。

2.3 about:support で描画状態を確認する

Firefoxのアドレスバーへ次を入力します。

about:support

「グラフィックス」欄を確認しました。

今回の実機では、画像処理について次の表示を確認しました。

画像処理
WebRender (Software)

つまり、確認時点ではFirefoxの通常描画に Software WebRender が使用されていました。

2.4 WebRender / Hardware Compositingの診断結果を確認する

同じ about:support の「決定ログ」では、次の状態を確認しました。

HW_COMPOSITING

HW_COMPOSITING

default  available
env      blocked    Acceleration blocked by platform

OPENGL_COMPOSITING

OPENGL_COMPOSITING

default  unavailable  Hardware compositing is disabled

FEATURE_FAILURE_OPENGL_NEED_HWCOMP

WEBRENDER

WEBRENDER

default  available
env      blocklisted  Blocklisted by gfxInfo

FEATURE_FAILURE_OPENGL_LESS_THAN_3

WEBRENDER_COMPOSITOR

WEBRENDER_COMPOSITOR

default  available
env      blocklisted  Blocklisted by gfxInfo

この結果から、少なくとも確認時点では、

Hardware Compositing
  └─ blocked

Hardware WebRender
  └─ blocklisted

画像処理
  └─ WebRender (Software)

という状態でした。

2.4.1 英語の診断結果を日本語で整理する

about:support の「決定ログ」は内部的な英語表記が多いため、そのままでは意味が分かりにくいです。

今回表示された主な項目を、日本語で整理すると次のようになります。

Firefoxの表示 日本語での意味 今回のLIFEBOOKで確認した状態
WebRender (Software) WebRenderをGPUではなくソフトウェア側で処理している 通常描画はソフトウェア描画
HW_COMPOSITING GPUなどのハードウェアを使って画面を合成する機能 blocked で利用停止
OPENGL_COMPOSITING OpenGLを使って画面を合成する機能 unavailable で利用不可
WEBRENDER Firefoxの描画エンジンWebRender blocklisted でGPU側の利用対象外
WEBRENDER_COMPOSITOR WebRenderの画面合成部分 blocklisted で利用対象外
blocked Firefoxが利用可能と判断していても、環境・プラットフォーム側の条件で利用を止められている状態 今回はHardware Compositingで表示
blocklisted FirefoxのGPU互換性判定で、その機能を使用しない対象になっている状態 今回はWebRender関連で表示
FEATURE_FAILURE_OPENGL_NEED_HWCOMP OpenGLによる画面合成に必要なHardware Compositingが利用できないことを示す識別子 OpenGL Compositingを利用できない理由として表示
FEATURE_FAILURE_OPENGL_LESS_THAN_3 Firefoxの判定上、必要なOpenGL 3系の条件を満たしていないことを示す識別子 WebRenderのGPU利用がblocklist対象になった理由として表示

つまり今回の状態を日本語にすると、

Firefoxの通常描画
  ↓
GPUを使った画面合成は利用できない
  ↓
WebRenderのGPU利用も対象外
  ↓
WebRender (Software)
  ↓
ソフトウェア描画で動作

と整理できます。

blocked と blocklisted は似ていますが、記事では同じ意味として扱いません。

今回の実機表示では、

  • blocked：環境・プラットフォーム側の条件で利用停止
  • blocklisted：FirefoxのGPU互換性判定で利用対象外

として表示されていました。

この記事では、Firefoxが実際に表示した診断結果をそのまま記録し、その意味を日本語で補足しています。

2.5 GPU自体はFirefoxから認識されている

一方、about:support ではGPU自体も認識されていました。

GPU #1

使用中: はい
型番: Mesa Intel(R) HD Graphics (ILK)
ベンダーID: 0x8086
デバイスID: 0x0046
ドライバーのベンダー: mesa/crocus
ドライバーのバージョン: 25.2.8.0

ここで重要なのは、

GPU #1
使用中: はい

という表示だけを見て、「Firefoxの通常描画がGPUアクセラレーションされている」と判断しないことです。

同じ画面で、

画像処理: WebRender (Software)
HW_COMPOSITING: blocked
WEBRENDER: blocklisted

も確認できています。

2.6 WebGLの状態も確認する

ここで、WebRenderとWebGLは別の機能なので分けて考えます。

項目 役割
WebRender Firefox自身がWebページを画面へ描画するための描画エンジン
WebGL WebサイトやWebアプリがブラウザ上でGPUを利用した2D / 3D描画を行うための仕組み

今回のLIFEBOOKでは、

Firefox自身の通常描画
  └─ WebRender (Software)

Webサイト側から利用されるWebGL
  └─ WebGL 1ではIntel GPUを認識

という、別々の状態になっていました。

したがって、WebRender (Software) と表示されているからといって、Firefox内のGPU利用がすべて無効になっているとは判断しません。

WebGL 1については、次のレンダラーを確認しました。

WebGL 1 ドライバーのレンダラー
Intel -- Mesa Intel(R) HD Graphics (ILK)

WebGL 1のバージョンは、

OpenGL ES 2.0 Mesa 25.2.8-0ubuntu0.24.04.2

でした。

一方WebGL 2では、次のエラーを確認しました。

WebGL creation failed:
* tryNativeGL (FEATURE_FAILURE_EGL_NO_CONFIG)
* Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS)

この英語メッセージは、日本語では次のように整理できます。

表示 今回の記事での読み方
WebGL creation failed WebGL 2の描画環境を作成できなかった
FEATURE_FAILURE_EGL_NO_CONFIG Firefoxが利用できるEGL設定を確保できなかったことを示す識別子
FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS Firefoxが試したWebGL用ドライバー経路を使い切っても作成できなかったことを示す識別子

つまり今回の実機では、

WebGL 1
  └─ Intel GPUを認識して利用可能

WebGL 2
  └─ 描画環境の作成に失敗

という状態でした。

したがって今回の確認では、

項目 実機で確認した状態
画像処理 WebRender (Software)
Hardware Compositing blocked
Hardware WebRender blocklisted
WebGL 1 Mesa Intel HD Graphicsを認識
WebGL 2 作成失敗
GPU Firefoxから認識

となっていました。

2.7 about:config でWebGLを無効化する

about:support の確認では、Firefoxの通常描画はすでに、

WebRender (Software)

となっていました。

一方、WebGL 1では、

Intel -- Mesa Intel(R) HD Graphics (ILK)

がレンダラーとして認識されていました。

そこで今回は、通常のWebRender描画ではなく、WebGLを使用しない条件へ変更して挙動を比較することにしました。

Firefoxのアドレスバーへ、

about:config

と入力します。

警告画面が表示された場合は内容を確認したうえで詳細設定画面へ進み、次の設定を検索しました。

webgl.disabled

変更前は、

webgl.disabled = false

でした。

この設定名を日本語で読むと、

webgl.disabled
  ↓
「WebGLを無効にするか」

という意味です。

値は、

false
  └─ `webgl.disabled` による
     明示的なWebGL無効化をしていない状態

true
  └─ `webgl.disabled` により
     WebGLを明示的に無効化する状態

となります。

今回は、

webgl.disabled = false

から、

webgl.disabled = true

へ変更しました。

つまり、webgl.disabled で明示的に無効化していない状態から、WebGLを無効化する設定へ変更したことになります。

変更後、Firefoxをいったん完全に終了して再起動しました。

今回実際に変更した設定は、

about:config
  ↓
webgl.disabled
  ↓
false → true
  ↓
Firefox再起動

です。

about:config はFirefoxの詳細設定を直接変更する画面です。

今回のLIFEBOOKでは、WebGL 1がGPUを認識していることを確認したうえで、切り分けとして webgl.disabled=true に変更しました。

WebGLを使用するWebサイトやWebアプリの表示・機能へ影響する可能性があるため、すべての環境でWebGLを無効化することを推奨するものではありません。

元へ戻す場合は、webgl.disabled を false へ戻し、Firefoxを再起動します。

Mozilla Supportでは、グラフィック関連の問題を切り分ける方法としてWebGLを無効化する手順も案内されています。

判断元URL：

公式記載：

Enter webgl.disabled in the search box.

また、設定値を true へ変更する手順が案内されています。

今回もこの設定を使用して、WebGLを無効化した状態で挙動を確認しました。

2.8 体感では軽くなったが原因は断定しない

webgl.disabled=true へ変更してFirefoxを再起動したあと、実際に普段使用しているWebページを操作しました。

その結果、体感としては、

軽くなった気がする

という変化を感じました。

ただし、ここは記事上で特に注意します。

about:support を確認した時点ですでに、

WebRender (Software)

となっており、Hardware WebRenderもblocklist対象でした。

そのため、

NG:
Firefox全体のGPUアクセラレーションを無効化したから
Firefoxが軽くなった

とは書きません。

今回実際に行った変更は、

通常描画
  └─ もともとWebRender (Software)

WebGL 1
  └─ Intel -- Mesa Intel(R) HD Graphics (ILK) を認識
        ↓
about:config
        ↓
webgl.disabled
false → true
        ↓
Firefox再起動
        ↓
体感上は軽く感じた

です。

したがって、今回の記事で言えるのは、

Firefoxが重く感じた
  ↓
about:supportで描画状態を確認
  ↓
通常描画はSoftware WebRender
  ↓
Hardware Compositing / WebRenderはblocked・blocklisted
  ↓
WebGL 1ではGPUを認識
  ↓
webgl.disabledをfalseからtrueへ変更
  ↓
Firefox再起動
  ↓
その後の使用では体感上軽く感じた

までです。

「体感で軽くなった」という結果だけでは、性能改善の原因までは特定できません。

webgl.disabled=true への変更後に体感差はありましたが、CPU使用率、メモリ使用量、ページ内容、拡張機能、キャッシュなど別の要因もあります。

そのため、この記事ではWebGLの無効化をFirefox全体の重さの単独原因・解決策とは扱いません。

2.9 切り分けの時系列

Firefoxが重く感じる
  ↓
GPUアクセラレーションの状態を確認する
  ↓
設定画面に該当項目が見当たらない
  ↓
about:support
  ↓
画像処理
  └─ WebRender (Software)
  ↓
HW_COMPOSITING
  └─ blocked
     = ハードウェアによる画面合成は利用停止
  ↓
WEBRENDER
  └─ blocklisted
     = Firefoxの互換性判定でGPU利用対象外
  └─ FEATURE_FAILURE_OPENGL_LESS_THAN_3
     = OpenGL条件を満たしていない旨の識別子
  ↓
WebGL 1
  └─ Intel -- Mesa Intel(R) HD Graphics (ILK)
     = WebGL 1ではIntel GPUを認識
  ↓
WebGL 2
  └─ 作成失敗
  ↓
about:config
  ↓
webgl.disabled
  └─ false → true
  ↓
Firefoxを完全終了
  ↓
Firefox再起動
  ↓
その後の使用では体感上軽く感じた
  ↓
ただし原因は断定しない

Firefoxについては、「GPUを使っているかどうか」を設定画面だけで判断せず、about:support の実測結果を確認したうえで、実際に変更した webgl.disabled の設定まで記録することが重要でした。

3. バッテリー交換後に充電が始まらない

3.1 発生した症状

LIFEBOOKのバッテリーを新品の互換バッテリーへ交換しました。

交換前のバッテリーには次の表示がありました。

FMVNBP190
FPB0239
10.8V
2000mAh
22Wh
Li-ion

今回は互換バッテリーを使用した実機記録です。互換バッテリーの使用を推奨する記事ではありません。

富士通公式では、ACアダプタやバッテリパックについて 添付品・指定品を使用するよう案内しており、指定品以外を使用した場合の火災・破裂・発熱について注意喚起しています。

判断元URL：

https://www.fmworld.net/cs/azbyclub/qanavi/jsp/qacontents.jsp?PID=6604-7191

公式記載：

ACアダプタやバッテリパックは、必ず添付品・指定品を使用してください。

新品互換バッテリーを装着してUbuntuを起動しましたが、最初は、

充電中を示すオレンジ色の本体ランプが点灯しない
Ubuntu上でも充電が開始されない

という状態になりました。

3.2 BAT0 と決めつけて確認してしまった

最初はLinuxのバッテリーデバイス名を BAT0 等と想定し、次の確認を行いました。

upower -i $(upower -e | grep BAT)
cat /sys/class/power_supply/BAT*/status 2>/dev/null

しかし、このLIFEBOOKでは期待した情報を取得できませんでした。

実際にUPowerのデバイス一覧を確認すると、

/org/freedesktop/UPower/devices/battery_CMB1
/org/freedesktop/UPower/devices/line_power_AC
/org/freedesktop/UPower/devices/DisplayDevice

となっていました。

この実機のバッテリーデバイス名は、

CMB1

でした。

したがって確認には、

upower -i /org/freedesktop/UPower/devices/battery_CMB1
cat /sys/class/power_supply/CMB1/status

を使用します。

Linuxのバッテリーデバイス名を BAT0 と決めつけないことが今回の重要な躓きでした。

まず実機で列挙されているデバイス名を確認してから、その名前を使って状態を調べます。

3.3 バッテリー自体は認識されていた

UPowerでは次の状態を確認しました。

native-path:          CMB1
vendor:               Fujitsu
model:                CP345713
serial:               1
power supply:         yes
battery
  present:             yes
  rechargeable:        yes
  state:               pending-charge
  warning-level:       none
  energy:              28.512 Wh
  energy-empty:        0 Wh
  energy-full:         47.52 Wh
  energy-full-design:  47.52 Wh
  energy-rate:         0 W
  voltage:             11.305 V
  charge-cycles:       N/A
  percentage:          60%
  capacity:            100%
  technology:          lithium-ion
  icon-name:           'battery-full-charging-symbolic'

さらに、

cat /sys/class/power_supply/CMB1/status

では、

Not charging

となっていました。

つまり、

バッテリー未認識

ではなく、

バッテリーは認識されている
しかし充電は開始されていない

という状態です。

3.4 ACアダプターもOSから認識されていた

ACアダプター側を確認しました。

cat /sys/class/power_supply/AC/online

結果は、

1

でした。

UPowerでも、

native-path:          AC
power supply:         yes
line-power
  warning-level:       none
  online:              yes
  icon-name:           'ac-adapter-symbolic'

となっていました。

したがって当時の状態は、

ACアダプター
  └─ OSから認識

バッテリー
  └─ OSから認識

percentage
  └─ 60%

state
  └─ pending-charge

/sys/class/power_supply/CMB1/status
  └─ Not charging

energy-rate
  └─ 0 W

本体オレンジ充電ランプ
  └─ 点灯しない

です。

この時点では、互換バッテリーそのものが故障しているとは断定していません。

3.5 BIOSやUbuntu設定を変更せず放電リセットを試す

今回は、いきなりBIOSやUbuntuの設定を変更せず、ハードウェア側の状態を一度リセットすることにしました。

実施した手順は次のとおりです。

1. Ubuntuを通常シャットダウン

2. ACアダプターを外す

3. バッテリーを取り外す

4. 周辺機器を外す

5. 電源ボタンを約10秒長押し

6. 少し待つ

7. 新品バッテリーを再装着

8. ACアダプターを接続

9. PCを起動せず充電状態を確認

これは今回のLIFEBOOK実機で切り分けとして実施した手順です。

ここで記載した「電源ボタンを約10秒長押し」は、今回の実機で実際に行った切り分け手順です。

富士通公式が現在案内している一般的な放電手順とは完全に同一ではありません。

富士通公式の現在のQ&Aでは、ノートパソコンについて、電源を切ったうえでACアダプタ・ケーブル・周辺機器を外し、取り外し可能な場合はバッテリパックも外して、約2分置く手順が案内されています。

判断元URL：

https://www.fmworld.net/cs/azbyclub/qanavi/jsp/qacontents.jsp?PID=7607-9772

公式記載：

ノートパソコンの場合：約2分

なお、この富士通公式Q&Aの対象OS欄はWindows系です。この記事では、メーカーが案内しているハードウェア側の一般的な放電手順との比較資料として参照しています。

3.6 放電リセット後に充電ランプが点灯した

放電リセットとバッテリー再装着を行ったあと、それまで点灯しなかった、

充電中のオレンジ色ランプ

が点灯しました。

したがって、少なくとも実機の表示として、

対処前
  └─ 充電ランプ消灯

放電リセット
  ↓
バッテリー再装着
  ↓
AC接続

対処後
  └─ 充電ランプ点灯

まで改善したことを確認できました。

一方、記事作成時点で手元に残している調査記録では、Ubuntu上で、

state: charging
energy-rate > 0 W
percentageが60%から増加

までの最終確認結果は記録されていません。

そのため、この記事では「バッテリーが完全に正常になった」とまでは断定せず、

放電リセット＋再装着後に
本体の充電ランプが点灯するところまで確認

と記載します。

3.7 切り分けの時系列

新品互換バッテリーへ交換
  ↓
充電ランプが点灯しない
  ↓
BAT0前提で確認
  ↓
情報を取得できない
  ↓
UPowerの実デバイスを確認
  ↓
battery_CMB1 を発見
  ↓
バッテリー自体は認識済み
  ↓
state: pending-charge
status: Not charging
energy-rate: 0 W
  ↓
ACもonline=1で認識済み
  ↓
BIOS・Ubuntu設定は変更しない
  ↓
シャットダウン
  ↓
AC・バッテリー・周辺機器を外す
  ↓
電源ボタンを約10秒長押し
  ↓
バッテリー再装着
  ↓
AC接続
  ↓
オレンジ充電ランプ点灯

今回のポイントは、「バッテリーが認識されていない」と「認識されているが充電しない」を分けて確認したことでした。

4. 蓋を閉じるとSSHが切断される

4.1 発生した症状

このLIFEBOOKは、Ubuntu開発機としてだけでなく、

Windows
  ↓
SSH / VS Code Remote - SSH
  ↓
LIFEBOOK Ubuntu

というリモート利用も行っています。

通常の「自動サスペンド」はUbuntuの設定画面でOFFにしていました。

しかしLIFEBOOKの蓋を閉じると、

SSH接続が切断される

という問題が発生しました。

そのため、

通常の自動サスペンド

と、

蓋閉じイベント

を別の設定として切り分けることにしました。

4.2 systemd-logind の実効値を確認する

systemd-logind の蓋閉じ設定を確認しました。

busctl get-property \
  org.freedesktop.login1 \
  /org/freedesktop/login1 \
  org.freedesktop.login1.Manager \
  HandleLidSwitch

busctl get-property \
  org.freedesktop.login1 \
  /org/freedesktop/login1 \
  org.freedesktop.login1.Manager \
  HandleLidSwitchExternalPower

busctl get-property \
  org.freedesktop.login1 \
  /org/freedesktop/login1 \
  org.freedesktop.login1.Manager \
  HandleLidSwitchDocked

変更前は次の状態でした。

HandleLidSwitch              = "suspend"
HandleLidSwitchExternalPower = ""
HandleLidSwitchDocked        = "ignore"

実際の busctl 出力は、

s "suspend"
s ""
s "ignore"

でした。

つまり、Ubuntuの通常の自動サスペンド設定とは別に、systemd-logind 側では蓋閉じ時の動作として suspend が残っていました。

4.3 Ubuntu公式Manpageで HandleLidSwitch を確認する

Ubuntu 24.04（noble）の公式Manpageでは、HandleLidSwitch= などによって蓋スイッチ時の動作を設定できると説明されています。

判断元URL：

公式記載：

If "lock", all running sessions will be screen-locked.

また、HandleLidSwitch= の既定値は suspend と説明されています。

今回の要件は、

蓋を閉じる
  ↓
画面はロックする
  ↓
サスペンドしない
  ↓
SSHは継続する

です。

そのため、最終的に ignore ではなく lock を採用しました。

4.4 inhibitorを確認する

設定を変更する前に、蓋閉じイベントを別のプロセスが取得していないか確認しました。

systemd-inhibit --list

実機では8件あり、主なものは次のとおりでした。

ModemManager
NetworkManager
UPower
Unattended Upgrades Shutdown
GNOME Shell
gsd-media-keys
gsd-power

今回の確認では、handle-lid-switch を明示的に奪う低レベルinhibitorは確認できませんでした。

4.5 既存設定との競合を確認する

/etc 側に既存設定が残っていないか確認しました。

sudo grep -RnsE \
  '^[[:space:]]*HandleLidSwitch(|ExternalPower|Docked)[[:space:]]*=' \
  /etc/systemd/logind.conf \
  /etc/systemd/logind.conf.d 2>/dev/null || true

ls -la /etc/systemd/logind.conf.d 2>/dev/null || true

変更前の確認では、競合するローカル設定・drop-inは見つかりませんでした。

4.6 最初は ignore を試した

当初は、蓋閉じイベントでサスペンドしないことを優先し、次の設定を試しました。

[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

設定ファイルは、

/etc/systemd/logind.conf.d/90-lid-switch.conf

です。

作成時は次のようにしました。

sudo install -d -m 0755 /etc/systemd/logind.conf.d

sudo tee /etc/systemd/logind.conf.d/90-lid-switch.conf >/dev/null <<'EOF'
[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
EOF

4.7 いきなりrestartせずreload可能か確認する

SSH経由で設定変更していたため、systemd-logind をいきなりrestartして接続へ影響させたくありませんでした。

そこで、reload可能か確認しました。

systemctl show systemd-logind -p CanReload

結果は、

CanReload=yes

でした。

そのため、

sudo systemctl reload systemd-logind

で設定を反映しました。

今回の作業では、

systemctl restart systemd-logind

やOS再起動を設定反映のためには使用していません。

4.8 セキュリティを考えて最終的に lock へ変更する

ignore でもサスペンドを防ぐ目的は満たせます。

しかし今回の要件では、

蓋を閉じたとき
  ↓
何もしない

よりも、

蓋を閉じたとき
  ↓
画面をロック
  ↓
Ubuntuは稼働継続
  ↓
SSHも継続

の方が適切です。

そこで最終設定を次のように変更しました。

[Login]
HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock

実際の設定コマンドです。

sudo tee /etc/systemd/logind.conf.d/90-lid-switch.conf >/dev/null <<'EOF'
[Login]
HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock
EOF

sudo systemctl reload systemd-logind

4.9 最終設定と実効値を確認する

設定ファイルを確認します。

cat /etc/systemd/logind.conf.d/90-lid-switch.conf

結果：

[Login]
HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock

busctl の実効値も、

s "lock"
s "lock"
s "lock"

となりました。

さらに、

systemctl is-active systemd-logind

は、

active

でした。

4.10 蓋を閉じた状態でSSHを実機確認する

設定後、実際にLIFEBOOKの蓋を閉じた状態でSSHから確認しました。

date
uptime
free -h

結果：

2026年  8月 30日 日曜日 00:13:22 JST

00:13:28 up  3:18,  4 users,  load average: 0.12, 0.14, 0.40

メモリも取得できました。

Mem:
total       7.6Gi
used        1.7Gi
free        2.6Gi
available   5.8Gi

Swap:
total       4.0Gi
used        0B

蓋を閉じたままSSHコマンドを実行でき、OS稼働時間も継続していました。

この時点では、

蓋を閉じる
  ↓
画面ロック
  ↓
サスペンドしない
  ↓
Ubuntu稼働継続
  ↓
SSH継続

を実機で確認できました。

4.11 元に戻す方法

今回追加したdrop-inだけを削除する場合は、

sudo rm /etc/systemd/logind.conf.d/90-lid-switch.conf
sudo systemctl reload systemd-logind

とします。

削除後は実効値を確認します。

busctl get-property \
  org.freedesktop.login1 \
  /org/freedesktop/login1 \
  org.freedesktop.login1.Manager \
  HandleLidSwitch

設定を消しただけで完了とせず、現在の実効値まで確認します。

4.12 切り分けの時系列

Ubuntuの自動サスペンドはOFF
  ↓
それでも蓋を閉じるとSSH切断
  ↓
systemd-logindの実効値を確認
  ↓
HandleLidSwitch=suspend
  ↓
inhibitorを確認
  ↓
既存drop-inとの競合を確認
  ↓
まずignoreを設定
  ↓
CanReload=yesを確認
  ↓
systemd-logindをreload
  ↓
サスペンドしない状態を確認
  ↓
セキュリティを考えてlockへ変更
  ↓
HandleLidSwitch系3項目
  └─ lock
  ↓
蓋を閉じたままSSHから
date / uptime / free -h
  ↓
実行成功

この問題では、「Ubuntuの自動サスペンドをOFFにしたから蓋閉じでもサスペンドしない」と決めつけず、systemd-logind の蓋閉じイベントを別に確認したことがポイントでした。

5. 蓋閉じ時にWi-Fiが切断され機内モード相当になる

5.1 発生した症状

蓋閉じ時のサスペンド対策を行ったあとも、別の問題が発生しました。

LIFEBOOKの蓋を閉じてしばらくすると、

Wi-Fiが切断される
Ubuntu上で機内モード相当の状態になる
SSH接続ができなくなる
蓋を開けるとWi-Fiが復帰する

という現象です。

この問題は、単純なサスペンドとは別に調査しました。

5.2 journalctl で蓋閉じ前後を確認する

次のコマンドで、RFKill、Wi-Fi、サスペンド、蓋開閉に関するログを抽出しました。

journalctl -b --no-pager | \
grep -Ei 'rfkill|airplane|wlan|wifi|suspend|sleep|lid' | tail -n 100

問題発生時の重要なログは次のとおりです。

9月 08 14:58:43 lifebook-ubuntu wpa_supplicant[699]: rfkill: WLAN soft blocked
9月 08 14:58:43 lifebook-ubuntu NetworkManager[698]: manager: rfkill: Wi-Fi now disabled by radio killswitch
9月 08 14:58:44 lifebook-ubuntu systemd-logind[690]: Lid closed.
9月 08 14:58:46 lifebook-ubuntu kernel: ACPI: button: The lid device is not compliant to SW_LID.

蓋を開けたときには、

9月 08 15:37:06 lifebook-ubuntu systemd-logind[690]: Lid opened.
9月 08 15:37:14 lifebook-ubuntu NetworkManager[698]: manager: rfkill: Wi-Fi hardware radio set enabled
9月 08 15:37:14 lifebook-ubuntu NetworkManager[698]: manager: rfkill: Wi-Fi now enabled by radio killswitch

となっていました。

その後、

device (wlp16s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful.
Connected to wireless network "Buffalo-2G-27F8-WPA3"

とWi-Fiへ再接続していました。

ここで実測できた重要な事実は、

rfkill: WLAN soft blocked

です。

一方、同じ抽出ログには、

Suspending
sleep.target

などの明確なサスペンド実行ログは確認できませんでした。

5.3 systemd-logind 側はすでに lock

第4章で設定した systemd-logind 側を確認しました。

grep -RHiE \
'HandleLidSwitch|HandleLidSwitchExternalPower|HandleLidSwitchDocked' \
/etc/systemd/logind.conf /etc/systemd/logind.conf.d/ 2>/dev/null

結果：

/etc/systemd/logind.conf:#HandleLidSwitch=suspend
/etc/systemd/logind.conf:#HandleLidSwitchExternalPower=suspend
/etc/systemd/logind.conf:#HandleLidSwitchDocked=ignore
/etc/systemd/logind.conf.d/90-lid-switch.conf:HandleLidSwitch=lock
/etc/systemd/logind.conf.d/90-lid-switch.conf:HandleLidSwitchExternalPower=lock
/etc/systemd/logind.conf.d/90-lid-switch.conf:HandleLidSwitchDocked=lock

有効な独自設定は、

HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock

です。

したがって、この時点では systemd-logind 側を再度 suspend から変更する問題ではありませんでした。

5.4 GNOME側に別の蓋閉じ設定が残っていた

次にGNOME Settings Daemon側を確認しました。

gsettings get org.gnome.settings-daemon.plugins.power lid-close-ac-action
gsettings get org.gnome.settings-daemon.plugins.power lid-close-battery-action

変更前は、

'suspend'
'suspend'

でした。

つまり、

管理側 蓋閉じ設定
systemd-logind lock
GNOME Settings Daemon（AC） suspend
GNOME Settings Daemon（Battery） suspend

という不一致がありました。

5.5 GNOME側で利用可能な値を確認する

推測で nothing を設定せず、この環境で利用可能な値を確認しました。

gsettings range \
  org.gnome.settings-daemon.plugins.power \
  lid-close-ac-action

gsettings range \
  org.gnome.settings-daemon.plugins.power \
  lid-close-battery-action

実機結果：

enum
'blank'
'suspend'
'shutdown'
'hibernate'
'interactive'
'nothing'
'logout'

この実機では nothing が正式な選択肢として表示されました。

5.6 GNOME側を nothing へ変更する

GNOME側で蓋閉じ時にサスペンドを要求しないよう、次のように変更しました。

gsettings set org.gnome.settings-daemon.plugins.power \
  lid-close-ac-action 'nothing'

gsettings set org.gnome.settings-daemon.plugins.power \
  lid-close-battery-action 'nothing'

確認します。

gsettings get org.gnome.settings-daemon.plugins.power \
  lid-close-ac-action

gsettings get org.gnome.settings-daemon.plugins.power \
  lid-close-battery-action

結果：

'nothing'
'nothing'

意図した構成は、

蓋を閉じる
  │
  ├─ systemd-logind
  │    └─ lock
  │
  └─ GNOME
       └─ nothing

です。

5.7 一度は再発しなくなった

設定変更後、同じようにLIFEBOOKの蓋を閉じて再現試験を行いました。

その時点では、

機内モード / Wi-Fi切断は再発しない

ことを確認できました。

当初は、

GNOME側のsuspend
  ↓
nothingへ変更
  ↓
再発しなくなった

という結果になりました。

しかし、ここで原因を確定しません。

当時のログだけでは、

GNOMEのsuspend設定
  ↓
どの内部経路を通ったか
  ↓
RFKill Soft Block

という因果関係までは特定できていなかったためです。

5.8 後日、蓋閉じ時の切断が再発した

その後、再び蓋を閉じた状態でWi-Fi / SSHが切断される現象が発生しました。

つまり、

GNOME側をnothingへ変更
  ↓
一度は再発しなかった
  ↓
後日再発

となりました。

そのため、現在は、

GNOME側のsuspendが原因だった

とは書けません。

現在言えるのは、

問題発生時にRFKill Soft Blockを確認した

systemd-logindはlockだった

GNOME側にはsuspendが残っていた

GNOME側をnothingへ変更した

変更後はいったん再発しなかった

後日再発した

再発後に調査を始めると再現しなくなった

までです。

5.9 D-Bus監視をファイルへ残した

問題は毎回確実に再現するわけではありませんでした。

そのため、次回SSHが切断された場合でも記録を残せるよう、D-Busの監視を開始しました。

nohup dbus-monitor --session \
"type='method_call',interface='org.freedesktop.DBus.Properties',member='Set',path='/org/gnome/SettingsDaemon/Rfkill'" \
> ~/dbus-rfkill.log 2>&1 &

プロセスが残っているか確認します。

pgrep -af dbus-monitor

現象が再発した場合は、蓋を開けたあと、

cat ~/dbus-rfkill.log

で記録を確認する予定でした。

しかし、監視を開始したあとはこちらで狙って再現できず、原因特定につながるログを取得できませんでした。

そのため、D-Bus監視は実施した切り分け手段として記録を残すものの、この方法で原因を特定できたとは扱いません。

5.9.1 検証終了後の監視プロセスについて

nohup ... & で起動した dbus-monitor はバックグラウンドプロセスとして動作します。

検証終了後に残存を確認する場合は、

pgrep -af dbus-monitor

を使用し、対象PIDが残っている場合はPIDを確認したうえで、

kill <PID>

で終了できます。

今回の記録には、検証終了時点で dbus-monitor を停止したことを示す実測出力が残っていません。

そのため、この記事では「監視プロセスを停止済み」とは記載しません。

5.10 dbus-monitor で何を監視していたのか

D-Bus公式の dbus-monitor Manpageでは、dbus-monitor について次のように説明されています。

判断元URL：

公式記載：

The dbus-monitor command is used to monitor messages going through a D-Bus message bus.

また、--session はセッションバスを監視するオプションです。

今回使用した監視条件は、

session bus
かつ
method_call
かつ
org.freedesktop.DBus.Properties
かつ
member=Set
かつ
path=/org/gnome/SettingsDaemon/Rfkill

に絞っています。

したがって、

~/dbus-rfkill.log が空

だったとしても、

RFKill関連イベントが一切発生していない

とまでは判断できません。

今回指定した条件を通らない別経路でイベントが発生していた可能性は残ります。

5.11 原因未特定のまま検証を終了し、有線LAN運用へ切り替える

D-Bus監視を開始したあと、問題を狙って再現しようとしましたが、現象は毎回発生するわけではなく、原因特定につながるログを取得できませんでした。

この時点で確認できている事実は、

蓋閉じ時にWi-Fi / SSH切断が発生したことがある

問題発生時に
rfkill: WLAN soft blocked
を確認した

systemd-logindはlockへ変更済み

GNOME側はnothingへ変更済み

変更後はいったん再発しなかった

後日再発した

D-Bus監視を開始したが
その後はこちらで再現できなかった

までです。

一方、このLIFEBOOKはLaravel開発機、SSH接続先、Samba、Dockerなどを継続して利用することが目的です。

そのため、原因を特定するために追加設定や監視を増やし続けるよりも、開発機としての安定運用を優先し、有線LANへ切り替えることにしました。

Wi-Fi運用
  ↓
蓋閉じ時に機内モード相当への切り替えが再発
  ↓
原因は特定できない
  ↓
追加調査はここで終了
  ↓
有線LAN運用へ切り替え

これにより、本件は、

解決済み

ではなく、

原因未特定のまま検証終了
運用上の回避策として有線LANへ切り替え

と整理します。

この変更は、Wi-Fi側の原因が解決したという意味ではありません。

蓋閉じ時にWi-Fiが機内モード相当へ切り替わる原因は、今回の検証では特定できませんでした。

LIFEBOOKを開発機・SSH接続先として安定して使うことを優先し、有線LAN運用へ切り替えたため、追加検証を終了しています。

5.12 切り分けの時系列

蓋を閉じる
  ↓
Wi-Fi切断 / SSH切断
  ↓
蓋を開けるとWi-Fi復帰
  ↓
journalctlを確認
  ↓
rfkill: WLAN soft blocked
  ↓
NetworkManager
Wi-Fi now disabled by radio killswitch
  ↓
systemd-logindを確認
  ↓
HandleLidSwitch系はlock
  ↓
GNOME Settings Daemonを確認
  ↓
AC / Batteryともsuspend
  ↓
利用可能なenumを確認
  ↓
nothingが存在
  ↓
GNOME側をnothingへ変更
  ↓
同条件で再発試験
  ↓
一度は再発しなくなる
  ↓
後日再発
  ↓
原因確定を取り下げ
  ↓
D-Bus監視を開始
  ↓
その後はこちらで再現できず
  ↓
原因特定には至らない
  ↓
安定運用を優先
  ↓
有線LANへ切り替え
  ↓
本件の追加検証を終了

今回の蓋閉じ問題では、取れる対策は実施しましたが、最後の機内モード相当への切り替えについては原因を特定できませんでした。

LIFEBOOKを開発機として安定して使うことを優先し、有線LAN運用へ切り替えたため、本件の追加検証はここで終了します。

まとめ

今回は、古いLIFEBOOKをUbuntu開発機として実際に運用する中で遭遇した5つの躓きをまとめました。

App Centerでは、

No provider of glBlitFramebuffer found

というOpenGL関連エラーを実際に確認しました。

LIBGL_ALWAYS_SOFTWARE=1 では起動し、snap-store:opengl を切断したあとは通常起動とアプリ一覧からの起動も確認できました。

Firefoxでは、重く感じたためGPU・描画状態を調べました。

about:support では、

WebRender (Software)
HW_COMPOSITING: blocked
WEBRENDER: blocklisted
FEATURE_FAILURE_OPENGL_LESS_THAN_3

を確認しました。

日本語で整理すると、

通常描画
  └─ ソフトウェア描画

ハードウェアによる画面合成
  └─ 利用停止

WebRenderのGPU利用
  └─ Firefoxの互換性判定で対象外

という状態です。

通常描画はすでにSoftware WebRenderでしたが、WebGL 1では Intel -- Mesa Intel(R) HD Graphics (ILK) が認識されていました。

そこで about:config の、

webgl.disabled

を、

false → true

へ変更してWebGLを無効化し、Firefoxを再起動しました。

その後の操作では体感上軽く感じましたが、性能改善の原因をWebGLだけに断定できる測定結果はないため、今回の実機で確認した変化として記録しています。

バッテリー交換では、Linuxのバッテリーデバイス名を BAT0 と想定してしまい、最初の確認で躓きました。

実際のデバイスは、

CMB1

で、バッテリーとACの双方はUbuntuから認識されていました。

しかし、

pending-charge
Not charging
energy-rate: 0 W

という状態だったため、BIOSやUbuntu設定を変更せず放電リセットと再装着を行い、その後に本体のオレンジ充電ランプが点灯するところまで確認しました。

蓋閉じ時のSSH切断では、Ubuntuの通常の自動サスペンド設定とは別に、systemd-logind の、

HandleLidSwitch=suspend

が残っていました。

最終的に、

HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock

として、蓋を閉じた状態でもSSHから date、uptime、free -h を実行できることを確認しました。

最後のWi-Fi / 機内モード相当への切り替えについては、問題発生時に、

rfkill: WLAN soft blocked

を実際に確認しています。

GNOME側に残っていた蓋閉じ時の suspend を nothing へ変更したあと、一度は再発しなくなりましたが、後日再発しました。

そのため、この問題は「解決済み」とはせず、

dbus-monitor
  ↓
/org/gnome/SettingsDaemon/Rfkill
  ↓
ログをファイルへ保存
  ↓
その後はこちらで再現できず
  ↓
原因未特定
  ↓
有線LAN運用へ切り替え
  ↓
追加検証を終了

と整理しました。

Wi-Fi側の原因が直ったわけではありませんが、LIFEBOOKをLaravel開発機・SSH接続先として安定して使うことを優先し、運用上の回避策として有線LANを採用しています。

今回の記事で一番重要だったのは、

古いPCだから

と一括りにせず、

何が動いているか
何が動いていないか
どのログが出ているか
どの設定が実際に有効か
条件を変えたあと何が変化したか
どこまで原因を特定できたか

を一つずつ確認したことです。

原因を特定できなかった最後の問題についても、解決したことにはせず、「原因未特定のまま検証終了・有線LANへ切り替え」という実際の運用判断まで記録しました。

参考資料

Snap公式：Connect interfaces

判断元URL：

確認内容：

  • snap connections によるinterface接続状態の確認
  • snap connect
  • snap disconnect
  • 手動disconnect状態の扱い

公式記載：

To disconnect an interface, use snap disconnect.

また、手動で切断した自動接続interfaceについて、

its disconnected state is retained after a snap refresh.

と説明されています。

Mozilla Support：Firefox's performance settings

判断元URL：

確認内容：

  • Firefoxのパフォーマンス設定
  • ハードウェアアクセラレーション
  • グラフィックドライバ条件によって設定項目が非表示になる場合があること

公式記載：

Hardware acceleration: Lets Firefox use your computer’s graphics processor (GPU).

設定項目が表示されない場合については、

Firefox hides hardware acceleration if your graphics driver isn’t compatible.

と説明されています。

Mozilla Support：グラフィックドライバーを更新してハードウェアアクセラレーション機能とWebGLを使用する

判断元URL：

確認内容：

  • about:config から webgl.disabled を検索する手順
  • webgl.disabled を true へ変更してWebGLを無効化する手順
  • 設定変更後にFirefoxを終了・再起動する手順
  • about:config の変更が安定性・セキュリティ・性能へ影響する可能性があること

公式記載：

検索ボックスに、webgl.disabled と入力します。

今回のLIFEBOOKでも、実測でWebGLの状態を確認したあと、この設定を true へ変更しました。

富士通公式：パソコンを放電する方法

判断元URL：

確認内容：

  • ACアダプタを取り外すこと
  • 接続されているケーブル・周辺機器を取り外すこと
  • 取り外し可能な場合はノートPCのバッテリパックを取り外すこと
  • ノートPCではケーブルを外した状態で約2分置くこと

公式記載：

ノートパソコンの場合：約2分

今回実施した「電源ボタンを約10秒長押し」は、この現在の富士通公式手順と同一ではないため、本文では実機で行った切り分けとして分けて記録しています。

富士通公式：ACアダプタやバッテリの購入方法

判断元URL：

確認内容：

  • 富士通純正バッテリの購入案内
  • 添付品・指定品の使用に関する注意
  • 指定品以外を使用した場合の安全上の注意

公式記載：

ACアダプタやバッテリパックは、必ず添付品・指定品を使用してください。

この記事は互換バッテリーを使用した実機記録ですが、互換バッテリーの使用を推奨するものではありません。

Ubuntu Manpage：logind.conf / logind.conf.d

判断元URL：

確認内容：

  • HandleLidSwitch=
  • HandleLidSwitchExternalPower=
  • HandleLidSwitchDocked=
  • lock の動作

公式記載：

If "lock", all running sessions will be screen-locked.

今回のLIFEBOOKでは、この lock を蓋閉じ時の最終設定として使用しました。

D-Bus公式：dbus-monitor

判断元URL：

確認内容：

  • dbus-monitor の用途
  • --session
  • watch expressionによる絞り込み

公式記載：

The dbus-monitor command is used to monitor messages going through a D-Bus message bus.

今回のLIFEBOOKでは、GNOME Settings DaemonのRFKill関連通信を絞り込んでファイルへ記録する監視を実施しました。

関連記事

このシリーズ

あわせて読みたい

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?