Versa Pro VA-G(VK18EA-G)のCeleron 1000MをCore i7 2640Mに交換

知人のVersa Pro VA-G(VK18EA-G)

型名 : VK18E/A 
http://121ware.com/navigate/support/productsearch/old_number/VK18EAG/spec.html

のCPUがCeleron 1000M

インテル® Celeron® プロセッサー 1000M
2M キャッシュ、1.80 GHz
https://ark.intel.com/content/www/jp/ja/ark/products/72060/intel-celeron-processor-1000m-2m-cache-1-80-ghz.html

でかなり遅く、手元にたまたまあったCore i7 2640M

インテル® Core™ i7-2640M プロセッサー
4M キャッシュ、最大 3.50 GHz
https://ark.intel.com/content/www/jp/ja/ark/products/53464/intel-core-i7-2640m-processor-4m-cache-up-to-3-50-ghz.html

に交換してみると、動いてしまいました。チップセットがHM75M Express

インテル、Intel 7シリーズチップセットを正式に発表
2012年04月08日 00時00分 公開
Ivy BridgeもSandy Bridgeも使えますから安心してください
https://www.itmedia.co.jp/pcuser/articles/1204/08/news008.html

でSandy Bridge(2640M)とIvy Bride(1000M)を両方サポートしているようです。BIOSのサポートがあるかはわからなかったのですが、試してみると、今のところ、うまく動いているようです。

VK18E/Aの分解については、以下のblogを参考にしました。

【パソコン】NEC Versa Pro VK18E/AのCPUを交換してみました。
https://mokkousan.blog.fc2.com/blog-entry-153.html

今回、CPUを交換したPCとは型番が違いますが同じ構造に見えるので、こちらにある手順を試したところ、うまくいきました。手順は以下のようです。

1. バッテリーを外します。
2. メモリと同様に背面の大きなカバー（ネジ×4）を外します。
3. CPUを止めているヒートシンクのネジ×4とファンのネジ×2を外し、ヒートシンクを外します。
4. CPUロックを反時計回りに回して外します。
5. ファン廻りのほこりの掃除、ヒートシンクの古いグリスの除去。
6. 新しいCPUを取付（取付位置に注意！）、グリスの塗布。
7. ロックをしてヒートシンクを取付、カバー取付で終了。
8. BIOSでCPUの認識を確認。

こういった作業に慣れている人であれば、15分から30分程度でできると思います。

Ubuntu Server 18.4をFreeBSD 10.xのNISクライアントとする

Ubuntu Server 18.4をFreeBSD 11.xのNISクライアントとする場合、いくつかの設定が必要でした。

FreeBSD 11をNISサーバーに、Ubuntu 16.04をNISクライアントするための設定
http://www.sakashita-net.jp/2018/01/freebsd-11nisubuntu-1604nis-1.html
http://www.sakashita-net.jp/2018/01/freebsd-11nisubuntu-1604nis-2.html

今回、これ以外にも設定が必要であることがわかりました。

1. NISのパッケージをインストールして設定ファイルを記述
   

   $ sudo apt install nis
   …
   $ cat /etc/yp.conf
   domain NISドメイン名 server NISサーバーホスト名
   $ cat /etc/nsswitch.conf
   passwd:         compat systemd nis
   group:          compat systemd nis
   shadow:         compat nis
   $

2. NISでの認証の場合、ログインに時間がかかるので、以下のWWWページを参照して設定を行った。
   
   Ubuntu 18.04 マシンへのログインに時間がかかることに対する対処
   https://ocg.aori.u-tokyo.ac.jp/member/daigo/comp/memo/?val=valid&typ=all&nbr=2018051801
   …
   問題
   Ubuntu 16.04 のころから ssh でログインするのに異様に時間がかかるようになった. ログインするたびに /var/log/auth.log には
   pam_systemd(sshd:session): Failed to create session: Connection timed out
   とのエラーが出ており PAM に問題があるようだったため,sshd が PAM を使わないよう設定していた. なお, このタイムアウトは 25秒 に設定されている. しかし, パスワード認証に PAM を使うシステムは sshd だけでなく,デスクトップの lightdm なども該当するため根本的解決が必要になった.
   原因
   ログインに時間がかかるマシンは NIS のクライアントでもあった.sshd の起動時, /var/log/syslog には
   systemd-logind do_ypcall: clnt_call:
   RPC: Unable to send; errno = Operation not permitted
   とのエラーが出ていた. PAM が呼ぶ system-logind が NIS サーバにアクセスできていないようである. ypcat などで passwd データなどは引けているので, この原因は不明である.
   対処
   /lib/systemd/system/systemd-logind.service
   にて
   IPAddressDeny=any
   を
   #IPAddressDeny=any
   とコメントアウトし
   $ sudo systemctl daemon-reload
   で systemd をリロード. これで ssh, lightdm 等のログイン問題は解決した.
   
   Linux NISクライアントがログイン時にハングアップする
   https://qiita.com/kakinaguru_zo/items/18258d4dd296a755badd
   
   Ubuntu 18や最近のDebian testingやArch LinuxでNISを用いた認証を行うようにすると25秒間固まる。これはsystemdバージョン235からsystemd-logindが一切のネットワーク通信を出来ないように設定されているからである。これを解決するための方法はいくつかあり以下のどれかを実行すればよい。
   
   1. /lib/systemd/system/systemd-logind.service の IPAddressDeny=any の行をコメントアウトする
   2. unscd をインストールする(nscdは問題が多いのでやめたほうがよい)
   この問題はsystemdの開発者に認識されているがsystemdのほうで修正される予定はない
   
   私は、後者のunscdをインストールすることで対処しました。というのは、ファイル/lib/systemd/system/systemd-logind.service はsystemdのアップデートで更新されてしまうことがあり、変更が失われてしまう場合があったためです。

Ubuntu Desktop 16.04で起動時にDHCPからのIPアドレス取得が遅く、NFSのマウントに失敗する

Ubuntu Desktop 16.04で起動時にDHCPからのIPアドレス取得が遅く、NFSのマウントに失敗するということがありました。これは

/lib/systemd/system/NetworkManager-wait-online.service

の

[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=30
RemainAfterExit=yes

の太字の部分を

[Service]
Type=oneshot
# ExecStart=/usr/bin/nm-online -s -q --timeout=30
ExecStart=/usr/bin/nm-online -s -q --timeout=90
RemainAfterExit=yes

とすることで回避できました。

これは、/var/log/syslogの内容を手がかかりにして見つけました。

1. /var/log/syslogには以下のようなエラーが記録されていました。
   

   DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 3 (xid=0xe6993237)
   DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interval 8 (xid=0xe6993237)
   NetworkManager-wait-online.service: Main process exited, code=exited, status=1/FAILURE
   Failed to start Network Manager Wait Online.
   NetworkManager-wait-online.service: Unit entered failed state.
   NetworkManager-wait-online.service: Failed with result 'exit-code'.
   Reached target Network is Online.
   Mounting /home...
   mount.nfs: Failed to resolve server NFS0: Temporary failure in name resolution

2. この「NetworkManager-wait-online.service」が怪しそうなので、検索をしてみると以下のWWWページがありました。
   

   デバイスの認識が遅くてnetwork.serviceがfailedになる問題
   https://qiita.com/kawaz/items/715d7ea761f13230607b
   …
   systemctl list-unit-files を見てたら NetworkManager-wait-online.service なんて名前のサービスがあるじゃない！？デフォルトではdisabledらしいが、いかにも僕の問題を解決してくれそうなサービス名である。おもむろに有効化。
   
   systemctl enable NetworkManager-wait-online.service
   
   再起動してみる。…やったー、無事SSH入れたよ！network.service のステータス見ても failed しなくなってる!

3. そこでこのサービスを確認し見たところ、enabledにはなっているがエラーがある(太字)。
   

   $ systemctl status NetworkManager-wait-online.service
   ● NetworkManager-wait-online.service - Network Manager Wait Online
   Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since …; 3min 40s ago
   Docs: man:nm-online(1)
   Process: 874 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited, status=1/FAILURE)
   Main PID: 874 (code=exited, status=1/FAILURE)
   …

4. このサービスの記述ファイルをlocateコマンドで探して中を確認してみると以下のようになりました。
   

   $ locate NetworkManager-wait-online.service
   /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
   /lib/systemd/system/NetworkManager-wait-online.service
   /var/lib/systemd/deb-systemd-helper-enabled/NetworkManager-wait-online.service.dsh-also
   /var/lib/systemd/deb-systemd-helper-enabled/network-online.target.wants/NetworkManager-wait-online.service
   $

   もう少し見てみると、
   

   $ cd /etc/systemd/system/network-online.target.wants/
   $ ls -l
   …
   lrwxrwxrwx 1 root root  38  2月 19 19:50 networking.service -> /lib/systemd/system/networking.service
   lrwxrwxrwx 1 root root  54  2月 19 19:50 NetworkManager-wait-online.service -> /lib/systemd/system/NetworkManager-wait-online.service

   ようにシンボリックリンクとなっていて、/lib/systemd/system/NetworkManager-wait-online.service が本体のようです
   
5. そこで/lib/systemd/system/NetworkManager-wait-online.serviceを最初に書いたように変更しました。

さらに、このUbuntu Desktop 16.04はサーバーとして運用しているのでGUIが不要です。そこで、以下のようにしてGUIを停止しました。

$ systemctl status lightdm
● lightdm.service - Light Display Manager
Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/display-manager.service.d
         └─xdiagnose.conf
Active: active (running) since … 15:24:23 JST; 3min 28s 
…
$ sudo systemctl disable lightdm 
$

補足: この「IPアドレスが必要なサービスがIPアドレスの付与を待たない」という問題は、Ubuntu Server 18.04では解消されていました。

Apple製品の廃棄

不要になったMac miniの廃棄をアップルに依頼してみました。リサイクルマークが添付されている製品だけだったためか、13時にWWWページから依頼して、その日の17時に引き取り日時が決まりました。引き取りは1週間後でした。

以下に時系列をまとめます

•  13:00
  以下のWWWページの「事業系パソコンのリサイクルのお見積もり依頼」から引取を依頼
  Appleのリサイクルプログラム
  MacとiPadのリサイクル
  https://www.apple.com/jp/recycling/computer/
• 13:01
  廃棄業者からメールで自動返信
• 13:02
  廃棄業者から電話があり、廃棄するもの、引取の場所などの確認
• 13:20
  見積書兼回収申込書がメールで送られてくる
• 13:50
  申込書をメールで送付
• 15:05
  申込書受領の確認されたという連絡をメールで受け取る
• 17:00
  引取業者から引き取り日時の連絡
• 一週間後
  引取

非常に迅速でした。