読者です 読者をやめる 読者になる 読者になる

解き放たれしソフトウェア

GNU/LinuxなどFLOSSについて書いてみるつもり

lm_sensors でファンの回転数を制御する

ハードウェア Linux

近年の PC 用 M/B の多くは、温度やファン回転数、電圧のセンサーチップが搭載されています*1。CPU 温度と冷却ファン回転数を監視することで、ファンが壊れて即死という事態を予防しています。 そして、M/B のファームウェアによりますが、ファン回転数を制御可能な M/B が一般的になっています。

lm_sensors

さて、GNU/Linux では、 lm_sensors を用いると、こうした温度や回転数などの数値を取得可能です。 さらに、 lm_sensors を用いれば、検出した温度に合わせてファンの回転数を変えるということも可能です。

参照: ArchWiki

まず、 lm_sensors をインストールします。

sensors_detect

そして、sensors-detect を root 権限で実行して、センサーを検出します。

Gentoo の場合は

Gentoo の場合は Linux カーネルを自力でビルドするのが原則でしょうから、sensors-detect の出力内容に応じてカーネルコンフィグレーションをやり直し、カーネルの再インストールが必要になるかもしれません。 lm_sensors - Gentoo Wiki にも書いてありますが、

  • CONFIG_I2C
  • CONFIG_I2C_CHARDEV
  • CONFIG_HWMON
  • CONFIG_THERMAL_HWMON
  • (おそらくは) CONFIG_X86_CPUID
  • M/B に載っているセンサーチップ用のデバイスドライバ

以上を、ローダブルモジュール<M>でもいいですが、有効にする必要があります。

とはいえ、M/B に載っているセンサーチップが何かが判らないでしょう。 とりあえず後回しにして sensors-detect を先に実行すると判ります。

設定が完了したら、service lm_sensors start で開始し、rc-update add lm_sensors default で再起動後も始動するようにします。

sensors

設定完了後は、 sensors コマンドで、センサーの数値が表示されます。

fancontrol

lm_sensors に入っている fancontrol が、ファン回転数制御のためのプログラムです。

参考: ArchWiki

pwmcontrol

fancontrol を使えるようにするには設定が必要です( /etc/fancontrol )。 pwmconfig は、この設定のためのツールです。

Gentoo の場合は

Gentoo ではやはり、 service fancontrol start で始動し、 rc-update add fancontrol default で自動始動にします。

DCファンの構造と回転数制御

さて、PC は電源ユニットから先は直流電力(DC)ですから、冷却ファンもDCです。

DCですから、端子の一本はプラスで、一本はマイナスです。

CPU 冷却ファンなどでは、回転数を M/B に検知させるのが一般的になって久しいです。そこで、回転数を知らせるためのピンが1本あります。

よって、端子は、3ピンあるわけです。

回転数制御の手法

回転数を固定ではなく可変にすることもいまや一般的です。 そして、回転数を変えるための手法には

  1. M/B が一方的に電圧を上下させる手法(電圧制御方式)
  2. M/B がファンに信号を送って、その信号を受けたファンが回転数を変える手法(パルス幅変調制御方式 ; PWM

の2種類があります。

電圧による制御では、ファン側に特別な機能は必要ないのが利点で、挙動は M/B と ファンとの相性次第で何ら確証がないのが欠点です。電圧が足りないときのファンは、停止します。

他方の PWM 制御では、信号を送るためのピンがさらに1本必要になり、合計4本の端子になってしまいます。 PWM 制御では、挙動はファンの設計次第で決まるので確実です。

M/B の対応状況

電圧制御でも回転数の上下は可能ですから、 PWM 非対応の M/B は多いです。

lm_sensors の pwmconfig では、"PWM" という語を用いてはいますが、PWM 用の数値を M/B に送ったところで実際にどう処理されるかは M/B 次第です。

実際には PWM 非対応の M/B では、電圧を変えることでファンの回転数を制御します。

3ピン端子と4ピン(PWM対応)端子の互換性

3ピン端子と、4ピン(PWM対応)端子とは、互換性があります。 PWM 対応 M/B に 3ピン端子は挿せます。 PWM 用ファンを PWM 非対応 M/B に挿せます。ただし、他の部品による物理的干渉が無いことが前提ですが。

PWM 信号が来ないときの PWM ファンは、100% の指令が来ているものとして動作します。 ですから、電圧制御方式の M/B に挿しているときは、 PWM ではフル回転ですが、電圧不足で回転数が下げられます。

実際の回転数の設定どうしよう

ケース内には、M/B のシステムチップ、RAM モジュール、拡張ボード、HDD など、発熱する部品があるでしょう。 ですから、いくら CPU がパッシブヒートシンクだけでまかなえる状況であったとしても、ケースへの air flow はあった方がよいと思います。

ただし、電源ユニットがファンレスではない場合は、電源ユニットのファンを利用して冷却し、CPU ファンやケース(シャーシ;chasis)ファンは止めるという案もあるかもしれません。そうなると、 CPU ファンもケースファンも止める余地はあります。

*1:他方で、携帯端末などのいわゆる「組込み」などではそもそも CPU が過熱しない、ファンがないといったことから、事情は異なります

スワップは RAM の 20%、とレッドハットの人

RHEL Linux

Red Hat の人が、RAM の多い現在におけるスワップの必要性について書いています。

Do we really need swap on modern systems? - RED HAT BLOG

例えば RAM が 2GB でスワップが 2GB のシステム上で、間違えて 5GB を利用する設定でデータベースサーバを運用してしまったら、RAM を使い切ったらスワップアウトして遅くなり、スワップを使い切ってようやく不要なプロセスが終了させられるスワップが 2GB もあるせいで、システムが重くなる時間が長く続いてしまう。その間はログインすら不可能な状況が起こるかもしれない。

しかしもしもスワップ無しにしてしまうと、スワップアウトの起こらないまま直ちにプロセスが終了させられてしまう。そのため、トラブルを未然に防ぐことが不可能になるとともに、解析も困難になってしまう。

よって、RAM よりも少量でスワップを用意した方がよく、スワップに使用するディスクは速い方がよい、という結論。

Our size recommendation for most modern systems is ‘a part of the physical RAM’, for example, 20%. With this, the painfully slow phase of operation in our example will not last as long, and the OOM kicks in earlier.

物理 RAM の 2割

If you design your applications to regularly use swap, make sure to use faster devices, like SSD - starting with Red Hat Enterprise Linux 7.1, ‘swapon –discard’ can be used to send TRIM to SSD devices, to discard the device contents on swapon.

スワップに使用するディスクは、可能ならば SSD で。 いま(RHEL 7.1 以降)は、swapon のオプションには discard があるので、 SSDスワップを設定しても TRIM を発行させることが可能。

util-linuxswapon ですが、たしかにありますね。 https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c230138

ただし、この記事は RHEL のブログで、あくまでもサーバ運用を想定して書かれています。

以前なら、書換寿命のある SSDスワップに用いたくはなかったものですが、今の SSD は耐性が向上しています。 しかもサーバ運用だとプロ用の高寿命 SSD が用いられることがよくあります。 そのため、高速である SSDスワップにも使った方がよいという思い切った結論の取れる時代になったようです。

Windows を MBR・非GPT から UEFI・GPT に、データ削除なしに移行する方法

プロプライエタリ Windows ブートローダ

WindowsMBR から UEFI に、再インストールや復元作業なしに移行することに成功したので、メモ書きをします。 理解したうえで自己責任でやるべきなので、具体的なコマンドの詳細説明は書きません。

BitLocker を用いている場合はどうやったらいいか知りません。ブートが多段構造になっているからです。以下は、BitLocker 暗号化していないという前提です。

UEFI / GPT インストールWindowsパーティション構成

マイクロソフト予約済みパーティションって何?

BitLocker で 暗号化済のシステムをブートする際の踏み台です。暗号化されたパーティションからいきなり起動は不可能なので。 BitLocker の導入予定があるならば、置いておきましょう。

方針

  1. もしも GNU/Linux 環境がなければ、GParted Live などのライブディスクを作成します。 おそらく、SystemRescueCdClonezilla などでもかまわないでしょう。
  2. フルバックアップを行う
  3. システム修復ディスクまたはインストールメディア(書込可能DVDまたはUSBフラッシュメモリ)を作成する
  4. ディスクを GPT に変換する
  5. (無ければ)ディスク上に空き領域をつくる(既存パーティションの縮小)
  6. EFI システムパーティション(ESP)を作成する
  7. マイクロソフト予約済パーティションMicrosoft Reserved Partition ; MRP)を作成する
  8. ESP に Windowsブートローダを書き込む

上記1と2は、 WIndows 上で行います。コントロールパネルの、バックアップ(Windows7)のところでやります。

3~6は、システム修復ディスクまたはインストールメディアで起動しても可能ですが、GNU/Linux上でも可能で、その方がやりやすいと思います。なぜなら、 GUI もある&インターネット接続して調べながらでもやれるから。 GParted Live などの、パーティション編集用のディストリビューション(ライブイメージ)で起動するとよいかもしれません。

3の GPT への変換は GPT fdisk (gdisk)で行います。

4~6は、 GParted でも可能です(ただし、2は NTFS 編集用のソフトウェアも入っている必要がありますが、 GParted Live などではまずデフォルトで導入済でしょう)。

7は、システム修復ディスクまたはインストールメディアから起動してコマンドラインでやります。

フルバックアップ

フルバックアップしましょうWindows 標準の機能であります。ただし、 Windows 7 時代からの旧来の方式でやります。

同じディスクにある他のパーティションも、バックアップしておいたほうがよいです。 私は責任もちません。 GParted Live などで起動してパーティションごと他のディスクにコピーするなどしてもよいと思います。

システム修復ディスクまたはインストールメディアの作成

フルバックアップと同じところで、修復ディスクもつくれます

インストールメディアを作成する方法もあります。 その場合は、書込可能な空の DVD か、4GB以上の空の USB フラッシュメモリが要ります。 方法はマイクロソフトのウェブサイトに行ってください。

既にインストールメディアを買って持っているというならば、それを使う手もあります。

高速スタートアップを切り、完全シャットダウンする

とはいえ、「シャットダウン」でなく「再起動」なら済みますが。

あと、繰り返しますが、 BitLocker 使っていないのが前提です。

GPT への変換

GPT への変換をすると、 MBR が消えます。一旦はこのディスクからはブート不能な状態になります。 だから、バックアップしましたよね?

GParted Liveなどの GNU/Linux のライブディスクで起動します。

sudo gdisk -l で、 Windows の入っているディスクのブロックデバイス名を特定してください。たとえば /dev/sdb1 ならば、sudo gdisk /dev/sdb で入り、 w (書込むコマンドだけ)で GPT に変換されます。

空き領域をつくる

後記の、 ESP や MRP を作成するための領域が必要だからです。 容量は、 ESP が 100MB 以上、 MRP が 128MB 以上が目安ですから、その合計分を用意します。私としては、 256MB がおすすめです。

空き領域がなければ、システムパーティションを縮小するなりしてつくります。 GParted だと平易です。時間はそこそこかかります。

状況によっては Windows RE (修復作業用のパーティション)がつくられていることがありますから、不要ならば消して領域を空けるということも考えられます。 修復用ディスクなりインストールメディアなりがあれば代わりになりますので、Windows RE を削除してもどうにかなります。

EFI システムパーティションをつくる

100MB 以上の大きさパーティションをつくります。(きりがいいので、128MB がおすすめです。)

フォーマットは FAT32 です(ESP は FAT32 と決まっています)。

パーティションに適当なラベルをつけます。(Windows のデフォルトでは、 “System” のようです。)

パーティションのフラグを “esp” に設定します。

マイクロソフト予約済パーティション(MRP)をつくる

BitLocker を利用するときに使うパーティションです。BitLocker を金輪際つかわないのならば不要です。

つくるならば、128MB つくっておけば、前記 ESP と足して 256MB できりがいいです。

MRP にフォーマット形式はありません。

パーティションのフラグを “msftres” に設定します。

Windowsブートローダをインストール

システム修復ディスクまたはインストールメディアで再起動し、コマンドプロンプトに入ります。

  1. 言語、時刻、通貨、キーボード、入力方式を選択
  2. コンピューターの修復
  3. 修復したいオペレーティング システムを選択
  4. システム回復オプションを選択
  5. コマンド プロンプトを選択

以下、DOS/Windowscase insensitive なので、コマンドは大文字でも小文字でも構いません。

  1. DISKPART を実行します。
  2. LIST DISK で、該当する Windows のインストールされているディスクの番号を見つけます。
  3. SELECT DISK n で当該ディスクを選択します(例えば1番なら、SELECT DISK 1
  4. LIST PARTITIONパーティション一覧。ESP のパーティション番号と 、Windows 本体の入っているパーティション番号を把握します。
  5. SELECT PARTITION n で、ESPのパーティションを選択します(例えば0番なら SELECT PARTITION 0
  6. ASSIGN LETTER=S などとして、とりあえず空いている適当なドライブ記号を割り当てます(左記の例では S: ドライブになる)
  7. SELECT PARTITION n で、 Windows 本体のパーティションを選択します
  8. 例えば Windows のドライブが C: だったら ASSIGN LETTER=C
  9. EXIT で DISKPART を終了します、これで通常のコマンドプロンプトに戻ります。
  10. BCDBOOT で、 ESP にブートローダを書き込みます。たとえば、Windows 本体が C:\WINDOWS にあり、 ESP が S: ドライブならば、 BCDBOOT C:\WINDOWS /S S: /F UEFI で ESP に書き込みます
  11. EXIT で終了。マシンを再起動

参考