■Windows7 / WindowsUpdateでネットワークアダプタが消える

Windows7 機を整備するために Windows Update を実行したら、ネットワークアダプタが消えてしまったという話です。

 

この Windows7 機を最後に更新したのは 3年近く前です。整備するためにまず Windows Update を実行します。

が、その前に、なにかトラブルがあった時のために HDD を丸ごとバックアップしておきます。何でもないことだけどこれは必須です。何度助けられたことか (^_^;)

蛇足ですが。バックアップを取られる人は多いと思いますが、リストアってやったことあります? たとえば別の HDD にリストアしてみるといった予行演習的なことは、常々やっておいたほうが良いです。いざというときに「リストアできない!」「方法がわからない!」という悲惨な目にあわないためにね。

 

閑話休題。

 

Windows Update の設定は「更新プログラムを確認しない」になっていましたので、それはそのまま「更新プログラムの確認」を行いました。いくつかの更新プログラムが表示されましたが、最新のものは 2019/05/14 のマンスリー品質ロールアップなどです。インストールを実行し、再起動の指示に従い再起動。とりあえず問題なく Windows7 は起動しました。

 

が、ネットワークにつながりません。タスクトレイのネットワークアイコンには ×印がついています。

そういえば Windows Update でネットワーク設定が変更されるって記事があったよなぁ、と思い出して、ネットワークアダプタの設定を確認しようとすると…… 無い…… ローカルエリア接続のアイコンが無い (^_^;)

デバイスマネージャを確認すると、ネットワークアダプタは「ドライバがインストールされていません」となっていました。ドライバの更新を実行するとなにやらエラーを起こしてインストールできません。

 

さて、どうするか?

なにかとお世話になっている「ぼくんちのTV別館」で Windows Update の情報を確認すると

今後、Windows7の更新は注意が必要 (再掲)

 

※この項目は、2019年4月度情報の再掲です。
今後、Windows 7 を2018年3月以前のイメージからリカバリを行おうと思った場合や、ゲスト仮想マシンでの運用では注意が必要。Windows Update 適用後に、ネットワーク設定が意図しないものに変更される場合がある。

とありました。

 

これかぁ、これに違いない。なんてったって最終更新は 3年前だもの (^_^;)

 

こうなってしまったら更新プログラムの削除とかシステムの復元とかを考えるわけですが、そんなことして深みにはまるより、さっさとバックアップからリストアして元に戻したほうが早いです。もうね、神様、仏様、バックアップ様ですよ。

というわけでリストア完了。もう一度 Windows Update をやり直します。

 

更新プログラムの確認をして、まず 2019年4月10日より前の日付の更新プログラムだけをインストールします。

次に、更新プログラムの確認をして表示された 5月分の更新プログラムをすべて非表示にし、もう一度更新プログラムの確認を行います。すると 4月分の更新プログラムが表示されますので、これも非表示にします。

さらに更新プログラムの確認を行うと、今度は 3月分のマンスリー品質ロールアップ (KB4489878) を含む 3月分の更新プログラムが表示されます。これをインストールします。

この「2019-03 マンスリー品質ロールアップ (KB4489878) 」こそが必須の更新プログラムなのだそうです。

 

引き続き更新プログラムの確認を進めます。

もう一つ必須の「サービススタック更新プログラム (KB4490628) 」が表示されますので、インストール。さらに更新プログラムの確認を行うと「利用できる重要な更新プログラムはありません」となりました。

ここで非表示の更新プログラムの再表示を行うと 5月分の更新プログラムが表示されます。たぶんもうこれをインストールしても問題ないのだろうと思いますが、念のためこれをもう一度非表示にして、4月分の更新プログラムを表示させインストールします。

そして最後に、5月分の更新プログラムをインストール。

 

無事、ネットワークアダプタには被害なく、Windows Update を完了しました。

 


■直す価値のないハードディスクを修復してみる の結果

ハードディスクの S.M.A.R.T. 属性について、英語版の Wikipedia S.M.A.R.T. にこんな記述を見つけました。これは「197 0xC5 Current Pending Sector Count」属性の解説の抜粋です。

 

However, some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the "Reallocation Event Count" (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.

 

代替保留中の不良セクタは、もう一度読み出しに失敗すると代替処理待ちとなり、次の書き込みで代替処理が行われます。しかし、「一部のドライブでは書き込みを行なってもただちに代替処理が行われない」というのです。不良セクタに対して、まず書き込みを行なってみて、書き込みが成功すれば良いセクタだとマークされます。この場合は Reallocation Event Count (0xC4) を増やしません。

 

まさにこれではないのでしょうか。

くだんの HDD は、dd コマンドでゼロフィルしたのちに Current Pending Sector が 0 になった。でも、Reallocated Event Count も Reallocated Sector Ct も増えていない。つまり、書き込みを行なったにもかかわらず代替処理が行われなかった。それは、代替処理の前に書き込みを行ない、それが成功したためだと。

これは、場合によっては不良セクタの代替処理が行われないことになるので「重大な欠点だ」と書かれています。

 

微妙な位置に立たされた HDD ということでしょうねぇ (^_^;)

 

ちなみに「198 0xC6 (Offline) Uncorrectable Sctor Count」について。

 

The total count of uncorrectable errors when reading/writing a sector. A rise in the value of this attribute indicates defects of the disk surface and/or problems in the mechanical subsystem.

 

この数値が増えるということは、「ディスク表面の欠陥」「メカニカルサブシステムの問題」があるということ。これはどうやら今後急速に劣化していく可能性を持っているようです。

 

ということで、最終結果。

この HDD は近いうちに故障する恐れがあります。でも、貧乏な俺はこの HDD を、あまり重要でない用途に、常に状態をチェックしながら使い続けてみることにします。\(^o^)/

 


■直す価値のないハードディスクを修復してみる のまとめ

もともと Windows7 のノートパソコンで使われていた 2.5 インチ 500GB のハードディスク。Windows が起動できなくなっていました。具合が悪くなると強制終了、なんて使い方を続けていたようです。そのハードディスクのままで OS を再インストールしたら正常に使えちゃったというのが、事の始まり。

で、完全に動かなくなるまでハードディスクを使い倒したい貧乏な俺は、いろいろ試しながら、グーグル先生に教えてもらいながら、あわよくばこいつを再利用できないものかと目論んでいたわけです (^_^;)

 

多くのサイトで勉強させていただきましたが、そんななかで出会ったサイトがこちら「PCと解 パソコントラブルにまつわるサイト」です。さまざまなパソコントラブルについてこれまでのご経験をもとに書かれているサイトですが、ハードディスクトラブルに関してもわかりやすく書かれています。とても参考になりました、ありがとうございます。

 

 

さて、おれが正確に理解できているかかどうかは怪しげです (^_^;) が、つまりこういうことかと。

 

S.M.A.R.T. テストは HDD の物理的な状態を調べるもの。

Windows で使ってみたらエラーもなく利用できたのは、ファイルシステムが物理的な異常を論理的に処理、回避してくれているから。Windows で動くチェックディスク chkdsk で不良セクタが表示されないのはそのためだということ。

S.M.A.R.T. によるセルフテストは読み書きのチェックを行ないますが、最初に不良セクタを見つけたところで停止します。badblocks コマンドも同じように読み書きを行ないますが、エラーがあっても停止せず HDD 全体をチェックしてくれます。

不良セクタをファイルシステムに論理的に認識させるには、Windows ならば chkdsk 、Linux ならば fsck のようなファイルシステムをチェックするコマンドを利用します。でも、すでに代替処理されたセクターにファイルシステムは関知しませんから、OS からは見えません。

 

読み出しエラーがあったセクターは Current Pending Sector となり登録されます。次に読み出しがあったときに、読み出しに成功すれば正常なセクタとなり Current Pending Sector の数は減ります。読み出しに失敗すると代替処理すべきセクタとなり、次の書き込み時に代替処理されます。

代替処理が行われると Reallocated Event Count が増やされます。処理済みとなれば Reallocated Sector Ct が増える。でも、処理に失敗した場合はどうなるのでしょうか? その場合は Offline Uncorrectable となる?

 

Current Pending Sector に書き込みを行なう ( dd や badblocks ) と代替処理が行われるので、Current Pending Sector は消失します。chkdsk や fsck はファイルシステムのエラーをチェックするものなので、いわゆる修復 (代替処理) にはならない。フォーマットもファイルシステム上の処理なのでダメ。

 

 

これらを踏まえてくだんの HDD のことを考えてみると。

 

dd コマンドでゼロフィルしたのちに、S.M.A.R.T. のセルフテスト (long) を実行し Current Pending Sector は 0 になった。でも、Reallocated Event Count も Reallocated Sector Ct も増えていない。Offline Uncorrectable は 108 が 209 に増えた。

とゆーことは、書き込みを行なったにもかかわらず代替処理が行われなかった。代替保留中だけれども、次の読み出しがまだ行われておらず、代替処理すべきセクターになっていなかった、ってことか? そこへ書き込み、読み出しを行なったら正常にできたので、代替保留中にはならなかった?

…… じゃあ、Offline Uncorrectable はなんなの?

 

まとめようかと思ったけれど、疑問はさらに続く…… (^_^;)

 


■直す価値のないハードディスクを修復してみる の参

全ブロックに 0 を書き込んでみた HDD (500GB) の S.M.A.R.T. テストの結果は、Current Pending Sector (現在保留中のセクタ) がなくなりましたが、Offline Uncorrectable (オフライン修正不可能) が 209 に増えています。これはいわゆる不良セクターって奴なのでしょうか?

badblocks コマンドを使って調べてみることにしましょう。

 

badblocks は、今回は破壊的 (書き込みモード) 検査をやってみます。man badblocks してみると、

 

-w     Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55,  0xff,  0x00)  on  every block (すべてのブロックにいくつかのパターンを書き込むことによって) of the device, reading every block and comparing the contents.  (後略)

 

ということです。ん〜、4つのパターンをすべてやってみるのかな。1パターンに 5時間かかるとすると 20時間 …    -t オプションでパターンを random に指定すれば良いのかもしれない。

 

-t test_pattern

Specify a test pattern to be read (and written) to disk blocks.   The test_pattern may either be a  numeric  value between  0 and ULONG_MAX-1 inclusive, or the word "random", which specifies that the block should be filled with a random bit pattern ("random" は、ブロックがランダムなビットパターンで埋められることを指定します) .  (中略) If multiple patterns are specified then all blocks will be tested with one pattern before proceeding to the next pattern (複数のパターンが指定されている場合は、すべてのブロックが1つのパターンでテストされた後に、次のパターンに進みます。) .

 

ということなので、以下のように実行してみることにします。

$ sudo badblocks -svw -b 4096 -c 256 -t random -o badblocks.txt /dev/sdb

ランダムなパターンを書き読みして、一回りで終了。1 ブロック 4096 バイトを 256個ずつテストしますので、一度に 1MB をテストすることになります。と思います (^_^;)

 

ちなみに、エラーを書き出したファイルを e2fsck に渡すといった方法を説明しているサイトがいくつも見られましたけど、いま俺がやっているような、全体を潰したファイルシステムが無い状況ではそれはできません。e2fsck はファイルシステム (ext2 / ext3) がないと実行できませんので。俺がファイルに書き出しているのは、単に記録として見るためです。

man には、e2fsck に渡す場合には badblocks を使わないように、と書かれています。

 

Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs (badblockの出力がe2fsckまたはmke2fsプログラムに送られる予定の場合) , (中略) it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs (ユーザーが badblocks を直接実行しないことを強くお勧めします。むしろ、e2fsckおよびmke2fsプログラムの-cオプションを使用してください) .

 

さて、実際の動きですが、開始からまずランダムなパターンの書き込みが行われたようです。4時間 40分で 100% に達し、

Testing with random pattern: done

となりました。現在のところエラーは検出されていません。

そして今度は Reading and comparing: が進行しています。たしかに、dd で全体に 0 を書き込むにも同じ時間がかかっていますから、納得できる作業時間です。

ということはですよ、デフォルトが 4つのパターンを指定しているとすると、書き込みだけで 18時間 40分を要することになります。読み出しと比較に同じ時間かかるならば、全体の作業時間は 37時間 20分と見積もられます。

 

そしてついに badblocks コマンドが終了しました。正確な時間をチェックしてないのですが、ほぼ書き込みと同じほどかかっています。

$ sudo badblocks -svw -b 4096 -c 256 -t random -o badblocks.txt /dev/sdb
Checking for bad blocks in read-write mode
From block 0 to 122096645
Testing with random pattern: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

結果、不良セクタは検出されませんでした。エラーがなかったので badblocks.txt も作成されていません。そして予定したとおり、ランダムパターンの書き込み読み出しを一回り実行して終了ということでした。

 

どうなんでしょう? この HDD ってまだしばらく利用できそうじゃないですか (^_^;)

 


■直す価値のないハードディスクを修復してみる の弐

さて、S.M.A.R.T. テストで多くの不良セクタが見られるにもかかわらず評価が PASSED の HDD (500GB) を、物は試しに修復してみようとしていますが、あまりに不良セクタ予備軍などが多いので、あっさり全部潰してしまおうかと (^_^;)

 

全ブロックに 0 を書き込んでみたいのですが、方法として、いつも HDD の廃棄のときに利用している shred コマンドで可能です。でも今回は、あまり使ったことがない dd コマンドでやってみようと思います。

なお、時間が長くなるので、以下、別のパソコン (linuxBean) で作業を行いました。

$ sudo dd if=/dev/zero of=/dev/sdb bs=4096

多分 4時間ぐらいはかかるのでしょうけど、進行状況がわかりません。そこで、別のターミナルを開いて

$ sudo killall -USR1 dd

とすると進行状況が表示されます。定期的に表示させるには watch コマンドを使うとよいです。

$ sudo watch -n 600 killall -USR1 dd

-n の値が繰り返しの秒数です。頻繁に表示しても仕方がないので、10分おきにしています。

 

ちなみに、ubuntu 18.04 の man dd で調べると、

 

status=LEVEL

The  LEVEL of information to print to stderr; (中略) 'progress' shows periodic transfer statistics ( 'progress' は定期的な転送統計を表示します)

 

と書いてあるので、status=progress をつければ良さそうですね。試してませんが (^_^;)

ubuntu の dd のバージョンは 8.28 ですが、linuxBean は 8.13 でこのオプションはありませんでした。

 

で、結果 dd は 4時間 40分で終了しました。続けて S.M.A.R.T. テストを行います。

$ sudo smartctl --test=long /dev/sdb

予定時間は 3時間 50分ほどですので、パソコンにおまかせして就寝します (^_^;)

 

一夜明けて、テストの結果を確認しました。

$ sudo smartctl -a /dev/sdb

テスト評価は PASSED です。

SMART overall-health self-assessment test result: PASSED

ログのステータスも正常に終了しています。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     25478         -

属性データの抜粋です。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       1 (1999, 1)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1 (5, 13648)
197 Current_Pending_Sector  0x0012   100   001   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       209

属性データについてざっとググってみたけど、なるほどって思えること書いてあるサイトにまだ出会っていません。今の俺には難しすぎる解説ばかりってことです (^_^;)

197 Current_Pending_Sector (現在保留中のセクタ) はなくなりました。予備軍は一掃されたってことですかね。

5 Reallocated_Sector_Ct (再割当てされたセクターの数) は 1 のままです。代替領域に再割当てされた不良セクターですので、OS からは見えない奴です。(1999, 1) というのは代替領域が 2000 あるってことでしょうか?

196 Reallocated_Event_Count (再割当てイベントの回数) は再割当てを試行した回数です。

198 Offline_Uncorrectable (オフライン修正不可能) が当初の 108 から 209 に増えました。再割当てできなかったセクターらしく、こいつがいわゆる不良セクターって奴かな?

 

それでは次は、badblocks コマンドで不良セクターの検査をしてみましょう。

 


■直す価値のないハードディスクを修復してみる の壱

以前修理したノートパソコン FMV-BIBLO NF/E70 から取り出した HDD ですが、表向きは特に異常が出ないけど、S.M.A.R.T. テストをすると read failure で中断してしまうという状態です。直す価値はないのではないかと思っています。が、物は試し修復してみようと思います。技術的な興味と後学のためとゆーことで (^_^;)

以下、壊れてもかまわない、データも消失してかまわないというレベルでの話ですので、真似してみようという物好きな人も自己責任でお願いします。

 

セルフテストの評価は PASSED になっています。

SMART overall-health self-assessment test result: PASSED

 

セルフテストのログです。read failure で中断しています。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%     25453         172907425

 

属性データの抜粋です。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       1 (1999 1)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1 (5 13648)
197 Current_Pending_Sector  0x0012   058   058   000    Old_age   Always       -       43
198 Offline_Uncorrectable   0x0010   046   046   000    Old_age   Offline      -       108

不良セクタに関連する数値の抜粋ですが、けっこう悪くなっている感じです。

 

テストでエラーになる LBA は 172907425 です。これがあるパーティションは /dev/sdf2 だということが以下でわかります。

$ sudo fdisk -l /dev/sdf
ディスク /dev/sdf: 465.8 GiB, 500107862016 バイト, 976773168 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x3f3c3b21

デバイス   起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/sdf1  *        2048   1126399   1124352   549M  7 HPFS/NTFS/exFAT
/dev/sdf2        1126400 976771071 975644672 465.2G  7 HPFS/NTFS/exFAT

ファイルシステムは NTFS でブロックサイズは 4096 バイト、1 セクターは 512 バイトですから、問題の LBA が含まれるブロックは、

 

(172907425 − 1126400 ) × 512 ÷ 4096 = 21472628

 

となります。

ちなみに、ブロックサイズは NTFS では Windows のコマンドプロンプトで

> fsutil fsinfo ntfsinfo X:

でわかります。ext3 などは Linux で

$ sudo tune2fs -l /dev/sdf2

で調べることができます。

 

このブロックを潰します。

$ sudo dd if=/dev/zero of=/dev/sdf2 bs=4096 count=1 seek=21472628

1+0 レコード入力
1+0 レコード出力
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000202855 s, 20.2 MB/s

$ sudo sync

sync はメモリーとディスクを同期させるっていうコマンドです。

 

S.M.A.R.T. ショートテストしてみましょう。

$ sudo smartctl --test=short /dev/sdf

結果のログです。Completed without error となりました。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error

# 1  Short offline       Completed without error       00%     25457         -
# 2  Short offline       Completed: read failure       90%     25453         172907425

属性データもみてみましょう。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       1 (1999 1)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1 (5 13648)
197 Current_Pending_Sector  0x0012   059   058   000    Old_age   Always       -       42
198 Offline_Uncorrectable   0x0010   046   046   000    Old_age   Offline      -       108

ん〜、Current_Pending_Sector が一つ減っただけです。一つ潰しただけだから当然ですよねぇ。潰したけど Reallocated_Sector_Ct が増えないのはなぜ? HDD の詳しい知識がないので俺にはわかりません m(__)m

 

で、次にロングテスト ( 4時間近くかかりました) を行うと別の LBA でエラーが出ます。それを潰して、またロングテストして… あ〜それを 40回以上やります? つまり、Current_Pending_Sector が一つぐらいならこうして潰してもいけるのかな、って感じ。こんなに傷んでる HDD ではやる価値ないってことです。

じゃぁ次は、あっさり全部を 0 で潰してしまいましょうか。

 


■ubuntu 18.04 / NASのPC連動電源機能を使う

我が家で利用しているバッファローの NAS TS-WXL には「PC連動電源機能」があります。これは、NAS Navigator2 をインストールした PC の電源の on/off に連動して NAS を自動的に on/off する機能です。HDD を起動/停止させるのが良いかどうかわかりませんが、夜間など誰もパソコンを使っていないときは節電しようよってことで利用しています。

しかぁし、NAS Navigator2 というアプリケーションは Windows 用で ubuntu では使えない。ubuntu をメインに使っているのに、NAS を起動させるために Windows を起動しなければならないとゆー本末転倒なことになっております (^_^;)

 

そこで、この PC連動電源機能を ubuntu でも利用できないか、という話。

 

Windows では何をしているのか。

WireShark でパケットのやり取りを見てみると、ときどき WOL (Wake on LAN) の Magic Packet が NAS へ送られていることがわかります。150 秒おきですが、なぜか 140 秒だったり 15 秒だったり…

「NAS Power Management Service」というサービスがこれを実行しているようで、Magic Packet は 3 回連続でポート 9 へ送られます。これを停止すると NAS は 300 秒後にシャットダウンします。NAS Power Management Service を再度起動すると Magic Packet がポート 9 へ送られ、NAS は起動します。

ちなみに NAS の WOL について説明書には、ポート 2304 を待ち受けていると書かれています。実際にはポート 9 でも起動できますけどね。

 

つまり、ubuntu でも 150 秒間隔で Magic Paket を送り続ければいいんじゃないのん?

 

スクリプト naspoweron.sh を書いてみました。

#! /bin/bash

while true

do

  for i in `seq 3`

  do

    wakeonlan -i 192.168.1.xx -p 9 AA:BB:CC:DD:EE:FF

  done

  sleep 150s

done

これを ubuntu 機で実行すると NAS が起動、150 秒おきに Magic Paket が送信されて NAS は稼働し続けてくれました。

 

ではこのスクリプトを ubuntu server に仕込んじゃいましょう。そうすればサーバーが起動すれば NAS も起動するようにできます。スクリプトを自動起動させる方法はいくつかあるようですが、サーバーの自動シャットダウン用に crontab を使っているので、これを利用することにします。

 

$ sudo crontab -e

 

次の一行を追加します。

 

@reboot /home/hoge/naspoweron.sh


パケットの送出を確認するには tcpdump を使います。

 

$ sudo tcpdump host 192.168.1.xx

 

クライアントの ubuntu desktop 18.04 では「自動起動するアプリケーションの設定」に追加すれば良いですね。

ではしばらく使ってみて、どうなるかみてみよう (トランプ氏風に (^_^;) )

 


■インターネットに繋がらない

営業さんから連絡受けて訪問したユーザーさん、「インターネットに繋がらない」とのことでした。

 

  1. タスクトレイのネットワークアイコンは「インターネットアクセスなし」表示です。
  2. まずはコマンドプロンプトから「 ipconfig /all 」してみます。パソコンのIPアドレスは DHCP からの自動取得で 192.168.1.18 / 24 、デフォルトゲートウェイと DNS は 192.168.1.1 でした。
  3. コマンドプロンプトから「 ping 192.168.1.1 」と入力すると応答がありました。
  4. ルーターは NTT の OG400X で、PPP ランプは点灯しています。ブラウザから「 http://192.168.1.1 」へアクセスしてルーターの状態を確認すると、プロバイダへは正常に接続できているようです。
  5. コマンドプロンプトから「 ping 8.8.8.8 」と入力すると Google Public DNS からの応答があります。が、「ping www.google.co.jp 」とするとホストが見つからないとのこと。どうやら名前解決ができていないようです。
  6. ルーターの接続状況からプロバイダの DNS サーバーのアドレスを確認し ping してみると応答があります。
  7. ネットワークアダプタの設定は DNS も自動取得になっていましたので、プロバイダの DNS サーバーアドレスを設定してみると見事に繋がりました。プロバイダの DNS サーバーは正常に稼働しているようです。
  8. ということで、どうやらルーターの DNS がうまく働いていないようです。処置はルーターの再起動。正常に接続できるようになり、めでたしめでたし (^_^;)

 

まぁ簡単なトラブルシューティングですが、ご参考までに。

なんちゅーかねぇ、窓際でのんびり過ごしたいのに、こんなんで呼び出されるわけですよ。ルーター再起動するぐらい営業さんでもできるでしょ、ってね。

 


■ubuntu 18.04 / 共有ディレクトリを自動マウント

ファイルサーバー (NAS) の共有ディレクトリを自動マウントしておくようにします。

 

基本的には過去記事 Ubuntu / ネットワークプレースを自動マウント でいけますが、このままでは NAS をマウントできませんでしたので一部修正しました。
 

ファイルサーバー (NAS) : 192.168.1.10
共有ディレクトリ : userdir
マウントポイント : /mnt/nas
ユーザー名 : nasuser
パスワード : naspasswd


まず cifs-utils をインストールします。
 

$ sudo apt install cifs-utils


つぎにマウントポイントを作成します。マウントポイントは、マウントする共有ディレクトリを格納する場所です。
 

$ sudo mkdir /mnt/nas

 

資格情報ファイル passwd.user を作成します。ファイル名は任意です。
 

$ sudo vi /etc/passwd.user


資格情報ファイルにユーザー名とパスワードを記述します。
 

username=nasuser
password=naspasswd


ファイルができたらオーナーとパーミッションを変更し、root 以外が読み書きできないようにします。
 

$ sudo chown root:root /etc/passwd.user
$ sudo chmod 600 /etc/passwd.user


/etc/fstab を編集します。
 

$ sudo vi /etc/fstab


次の一行を追加します。
 

//192.168.1.10/userdir /mnt/nas cifs vers=1.0,credentials=/etc/passwd.user,uid=1000,gid=1000,rw,defaults 0 0

 

我が家の NAS をマウントするためには vers=1.0 が必要でした。NAS の cifs バージョンが古いためだそうです。

rw は読み書きモード、defaults はマウントオプション、次の 0 は dump フラグ、最後の 0 は fsck チェックをしない、ということです。

サーバー起動時にマウントしますが、NAS が起動していないなどでマウントできなかった場合は

 

$ sudo mount -a

 

でマウントできます。

アンマウントしたいときは

 

$ sudo umount /mnt/nas

 

です。

 


■Windows10 / ubuntu18.04 / UEFIモードでデュアルブート

CPU: Core i5-4590 3.3GHz / Memory: 8GB / HDD: 500GB のパソコンに Windows10 と ubuntu18.04 をインストールし、デュアルブートさせることにします。俺が普段使っている ubuntu 機の後継とする予定です。

 

まずは Windows10 64bit をインストールします。毎度のようにインストール DVD から実行していけば、問題なくインストールできますね。難しいことはありません。

インストールが完了したら「ディスクの管理」を起動し、C ドライブにあたるパーティションを縮小します。約 260GB に縮小できたので、ubuntu 用に約 100GB 、共有パーティションとして約 130GB が確保できました。共有パーティションは Windows10 と ubuntu とで共有して使う場所で、作っておくとなにかと便利です。

 

次は ubuntu18.04 LTS をインストールします。こちらは 64bit のみですね。

Windows とのデュアルブートも何度もやっていることなので、いつものようにインストール DVD から起動して進めていきます。が、あれ?インストールボタンをクリックするとブート領域がなんとかかんとか文句言ってきます。何か間違えているのかと悩むこと一晩 (^_^;)

原因は、わかってしまえば簡単なことなのですが、ubuntu のインストール DVD をレガシードライブから起動していた、とゆーことです。

Windows10 64bit をインストールすると UEFI になります。俺の古い頭は、この UEFI というものをよく理解していない。UEFI のパソコンで DVD から起動するためには BIOS でレガシーモードにしなければならない、という程度の知識。今回起動モードをしっかり見てみたら UEFI の DVD ドライブというものが存在していました。このドライブを選択して起動すると UEFI でインストールされ、ブートは EFI が管理する、と。まぁ今回はその程度で (^_^;) 機会をみつけて勉強しましょ。

ちなみに UEFI で起動するとブートローダが起動、レガシーだと「Ubuntuを試す」の選択画面が表示されます。

 

さて、ブートローダが起動したら Install Ubuntu を選択しインストールを進めます。基本的にはこれまでと変わりありませんね。難しいことはないです。

インストールは「日本語」、キーボードレイアウトも「日本語 - 日本語」を選択します。

アップデートと他のソフトウェアでは「最小インストール」、その他のオプションのチェックはすべて外します。必要なものは後からインストールするほうが勉強になりますよ (^_^;)

インストールの種類は「その他」です。ubuntu 用のパーティションは /dev/sda5 、すべて「 / 」とします。swap 用のパーティションは作りません。共有パーティションは /dev/sda6 で、「 /Share 」などとしておくとディレクトリが作られます。

 

/dev/sda5 ext4 初期化 マウントポイント /

/dev/sda6 fat32 初期化 マウントポイント /Share

 

ウインドウが画面外へはみ出しているので「インストール」ボタンが見えません。super キー ( Windows キー) を押しながらドラッグするとウィンドウが移動できますので、上のほうへ移動して「インストール」を押します。

あとはタイムゾーン、ユーザー名、パスワードなどを設定。インストールが完了したら「今すぐ再起動」。

 

ubuntu のブートローダが起動したら、ubuntu、Windows10 がそれぞれ起動できることを確認して、完成です。

 


| 1/14PAGES | >>

■calendar

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     
<< September 2019 >>

■search this site.

■recommend

毎日貯まるポイントサイト ECナビ

■recommend

* 楽天ROOM *

■Twitter

■recommend

■recommend

■selected entries

■categories

■archives

■recent comment

■recent trackback

■links

■profile

■others

■mobile

qrcode

■powered

無料ブログ作成サービス JUGEM