またもや、Windows10 の「お節介な機能」に悩まされています。

-現象-

WIndows10 (1607) で、ディスクアクセスが100%になる。全く処理を受け付けなくなる。アプリケーションを全部強制終了させてもダメ。

1) どうもこの現象は、Windows Update をやった後に起こりやすい(やる前にも時々あるので、だからってわけでもないな)
2) FTP や Bit torrent で Linux のディストリビューションのような、数Gbのデータをダウンロードしている最中に発生しやすい(ような気がする)
特に FTP や Windows Store からダウンロードしながら、ヒマこいて YouTube なんか見ていると、あぼん。(痛いなぁ...やり直しか)
3) 大きなファイルを別なメディアにコピー、移動、削除などの処理をした後に陥る(ような気がする)
4) こういう時間がかかる処理でヒマこいている時に、暇つぶしに何かぼーっとしている時に大抵こういう状態に陥る。
5) ディスクの空き容量が少ないPCに出やすい現象(のようだ)
6) リブートすらできない。そもそも、リブートボタンまでたどり着けない。仕方がないので DOS 窓から > shutdown /r /t 0 してものろのろお帰りのお仕度を初めて、エラク反応が遅い。
7) そういう時にかぎって、急な用事を思い出して、こなさなければならない。で、トラブルシューティングを始めたら、「急いでやるべきこと」を忘れてしまうというオマケ付き。
8) ディスクの空きが余裕のヨッちゃんなPCでは現象出ず。
9) Windows Update Service を無効にしてみる。ただし手動アップデートもエラーになるし、やっぱりHDD 100% 病は治らない。 (確かになぁあり得るんだよな)
a0056607_17024038.jpg
「田(田圃アイコン)」の右クリック > コンピュータの管理 > サービスとアプリケーション > サービスから、
"Windows Update Service" を無効にしてみた。



でもねぇ......

a0056607_15325339.jpg

こんなのが何時間も続くと、イライラが募って、もう昼間っから酒飲んじゃうぞって気分になるのですよ。

- 色々な対策 -

でも日曜日の昼間っから酒飲んでも問題は片付かないわけですね。という事で色々調べてみたのですが、皆様つぎのようなご苦労を色々しているようです。

1) 極悪の OneDrive を殺す (既に無効にしてるんだが)

極悪 Windows10 の OneDrive を無効にする

2) タスクマネージャでディスクに必死こいて、アクセスしまくるサービスを止めてみる(と言っても一番しつこいサービス停止は拒否されることが多いし...)

3) IPv6 を無効にしてみる(インストールしたら、即時そうしていますよ....)

Windows7 からWindows10 にアップデートしたらまずするべき事。

4) リソースモニタ > 「ディスクタブ」を開くと、ページファイルに必死に書き込んでいるので、ページファイルのサイズをいじってみた(効果なし)
当然、ファイルがジャンスカ書かれるので、アンチウィルス系のソフトウェアもビンビンで大忙しの様だ。

5) 仕方なく、物理的な電源ボタンから「強制終了」して、あるいはコンセントを引っこ抜いて、お祈りしながら起動できるかナぁ...

6) サービスの中の Superfetch を無効にする(とっくにしている)

Windows10 の停止しておきたいサービスとタスク

という事で前後の状況から、どうも「システムディスクに余裕がないときに大きなファイル操作をしている時に、ヒマこいて 「YouTube なんか」をぼーっと見ていると現象が出るわけなで、そういう時にこそ、急な調べものなんかをしたくなるのですね。

そこでアイドリングプロセス中にやっていそうな、一番アヤシいプロセス。「自爆(あ自動だ)メンテナンス」を止めてみました。

コントロールパネル > セキュリティとメンテナンス > 「メンテナンス」を開くと「自爆メンテナンス」「進行中」です。思わず007のロジャームーアになった気分。

a0056607_15361924.jpg
で、「自動メンテナンス」を「停止」したら、あれれ。

a0056607_15395644.jpg
2,30秒後に見事に嵐が止みはじめました。

もっとも、アイドリング状態から、いきなり使い始めても、すぐには戻りません。
これも「停止」させようにも、激重中に「停止」すら押せない事もあるので、もう致命的です。まるでオシッコが止まらないアル中患者のようにしつこく動き続けることがあります。

そういう時は、電源スイッチを長押しして「南無阿弥陀仏」を唱えながら、もう一度電源を投入するしか方法がありません。
無事お祈りが利いて起動できたら、「自爆....」あ、いや「自動メンテナンス」を「停止」させます。

もう一度「自動メンテナンス」を「開始」すると

a0056607_15425939.jpg
あらら、やっぱりこうだったか、とまた HDD 100% 状態です。逃げろロジャームーア。

a0056607_15450673.jpg

ただ、この「メンテナンス」ってヤツは「自動」で、アイドリング状態になると、ノラ猫のようにゴミ箱あさりを始めるので、また「停止」させなければなりません。しかも、この設定を弄れるのは、管理者アイコンが示す通り、「管理者のみ」です。
ユーザに「一般ユーザ」でログオンさせて使わせています、という様な、一般企業の環境では大変な大騒ぎとなるわけですね。

デフォルトでは、夜中の3時に、スリープ中のPCをたたき起こして「働かせる」という、プアなPCだったら「過酷な仕様」ですし、ほおーっておくと、また「勝手に開始」されてしまうようです。タスクスケジューラから「無効」にしても効き目はないようです。

ノートPCの Bios パスワードをかけて、「帰宅や外出で離席する時は、コンセントとネットワークケーブルを外してPCを机の中にしまっておく事」なんて、企業の運用ルールなんか無視しまくりです。

朝いちばんにノートPCを引き出しから出したら、奇妙に本体があったかいンだからぁ~、おまけにバッテリーは消耗しまくっているし。

となると、また朝いちばんからヘルプデスクの電話は鳴りっぱなしになるわけです。

試しにタスクスケジューラを止めてみてもだめでした。
a0056607_15475570.jpg
全くお節介で厄介な仕様なんですね。しかもコントロールできない、無敵の Microsoft 仕様なのです。

レジストリをツツけば「自動メンテナンス」を無効にできるようですが

How to disable Automatic Maintenance in Windows 10 and 7

によると

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance]

に " MaintenanceDisabled" という DWORD のキーを作って、値に 1 を設定してリブートすると、この「自動運転の嵐」は止むようなのです。ただし一応「システムメンテナンス」は、あの悪名高い NFTS のフラグメンテーションの補正だとか、あまり役に立つとはおもえないけれど Windows Defender のスキャン、いらなくなったシステムファイルやパッチなどのクリーンアップをするようなので、止めておくことは決して勧められるものではないようです。

だからシステムの変更があった時や大きなファイルを操作した時に、大幅な「席替え」をせっせとやるわけですね。もっとも、こんな事できるのは「管理者」だけなので、一般ユーザにこんなフクザツな作業をやらせたくない。

そもそもそんなのUIに常備しろよと言いたくなるのですが、あまり公にはしたくない、かなり怪しい機能なんですね。

だから、もし上のレジストリを弄ったら、もう一度 Value を 0 にして、メンテナンスをして放置プレーするしかないようです。お勧めはしませんよ。

つまり、「Windows10 に於る HDD 100% アクセス激重シンドローム」には「萬金丹」のような万能の薬はないと言ってもいいのです。
a0056607_17123739.jpg
伊勢の萬金丹
鼻くそ丸めて萬金丹」



- まず一番効果的と思われるのは-

とにかく、エンドユーザさんには「ローカルディスクの空きを沢山空けておけ」空きに余裕があれば、そう滅多に自動メンテナンスはしない(ような気がする)。何しろフラグメントの起こりやすい事で有名で、25年以上昔に開発されて厚化粧を繰り返してきた Windows の NTFS だ。重くなって仕方がない。またデカいファイルなんか、特に Hyper-V とか動かすと、4Gの ISO だとか 40Gb の VHD 仮想ディスクイメージなんかが、ごっちょりあるので少しは整理して、放置プレーということでしょうかね。

まぁ、除虫剤のように「お出かけ前に」メンテナンスモードにして「帰ったら窓開け換気」じゃないな、メンテナンスモードを解除するのが、この暴れ馬を乗りこなす一つの方法かも知れません。

それにしても、こんな現象ってやっぱり Windows サーバーでも起こるのでしょうか。だから Windows (Storage 版の NAS も含む)のファイルサーバーって信用できないンですけどね。Hyper-V なんぞで、ディスクの容量ギリギリでスナップショットなんか取ったら、悲惨そう....

それから Windows のログも見てチョウダイネ、という事です。

- 結局そういうことだったのか -

やっぱり Windows Log はみるべきだった。ディスクエラー出てるんじゃん!

a0056607_14593478.jpg
という事で、ディスクエラーがでているので、バックグラウンドタスクが何度もリトライするわけですね。という事で、このPCもうダメじゃんということが判りました。

PS:その後見事に昇天し、最後を遂げましたトサ。南無南無............





--
Windows10 HDD 100% 重い、遅い、Hyper-V Windows 制御不能 メンテナンスモード

[PR]
by islandcenter | 2017-06-19 15:29 | Windows | Trackback | Comments(0)

-現象-

ローカルネットワークから、Squid プロクシ経由でインターネット接続している場合、 Windows Update Service 3.0 (WSUS) サーバからアップデートできない。この現象は Windows7 環境では発生せず Windows10 以降(具体的には 1607以降)のバージョンで発生する。

Windows 10 / Windows Server 2016 を含め、プロキシ サーバーを介して Windows Update サイトへアクセスした際に、更新プログラムの検出が通信エラー (0x80240030 / 0x80072efe / 0x80244022 / 0x80072EFD / 0x80072EE2 等) でうまくいかない、あるいは更新プログラムのダウンロードが通信エラー (0x80072ee7 / 0x8024402c 等) で進まないといったお問い合わせをいただくことがございます。

プロキシ サーバー経由での Windows Update へのアクセスについて

また、WinHTTP に対してプロキシ サーバーが適切に設定されているかをご確認ください。

-------

「ナヌ! WinHTTP って聞いたことないぞな?」

と、どうやらインターネットマーケットで一般的な Squid などのプロクシ経由では、「WinHTTP という、我等大変困惑独善非標準的詳細非公開的謎通信網」はエラーになってしまうようですね。つまり、WSUS は HTTP(s) 80,443 ポートを使うにも関わらず、一般的な HTTP(s) ではなく WinHTTP というレッドチャイナ並の特殊で非公開な極秘な通信するという事なのですね。(はじめて知った......)

「うちは、ほぼ世界標準の Squid プロクシなんだけどなぁ.....」

という場合、例外リストに明示的にプロクシの設定から WSUS サーバーを除外する必要があるようです。

- 対策 -

ローカルLAN内に Squid などの Proxy がある場合、コントロールパネル > インターネットオプション > 「接続」タブ > プロシサーバー > 「詳細設定」ボタンから「例外」リストに

"*.mylocalzone.mycompany.com;" のローカルゾーンか WSUS の、生IP アドレス(192.168.1.xx;)などをセミコロン区切りで明示的に追加します。
a0056607_15232155.jpg

どうも Windows10 Version 1607 あたりから、WSUS の挙動がおかしくなったナとは思っていました。この場合、単純なLAN内部のプロキシキャッシュなので、月のモノのWindows Update をする場合、一時的にプロクシを外せばいいのですが、Windows10 1607 以降、Windows Update ってやたらと時間がかかるじゃないですか。その間、色々モンダイがあるわけですよ。まぁ、このケースではこれで「一応」解決できていますが。

例えば、 Windows Update の「更新プログラムのチェック」をしても、全部アップデートできない。その様なときは "オンラインで Microsoft Update から更新プログラムを確認します"をクリックすると "ご本尊" からのアップデートを更新して、 WSUS にアップデートがキャッシュされるようです。最初の1台目でキャッシュすると、以降はイントラネットの WSUS からアップデートを "ダウンロード"だけはしてくれるので、2台目以降は、 WSUS から、文字通り "Windows Update Service" のキャッシュが参照されて、ピピッと、"ダウンロードだけは" 行われます。もっともその後の「更新のインストール」だけは、ユーザさんには、朝のコーヒー飲んで、ついでにトイレにでも行ってPCの性能次第で「まったり待つ」必要があります。
a0056607_23382112.jpg
もっとも、Windows Update の”状態の更新”は、深夜に行われるようスケジュールされるので、実際の現場では "朝イチバン"に、パッチの適用と、 WSUS への通知が行くようです。月モノによっては二度のリブートが必要なケースもあるので、翌日もう一度"リブートしろ"と出るケースもあります。ユーザさんは待ち時間でゆっくりトイレで××コ「していても、インフラ担当者は、漏れそうでも「そんなヒマねぇよ」という我慢の時間帯です。

まぁこれも給料の一部だとおもって、諦めてください。あらかじめ総務にお願いして Windows Update を 「承認」した、翌数日間は、役員用トイレも解放しておくようお願いするのもイイかも。

a0056607_23400558.jpg
でも、同時にWSUS 上にも正しく更新された情報が伝わるようで、WSUS の登録されたPCの全てが数日後に 100% パッチ完了となります。やれやれ......

山市良のうぃんどうず日記(97):進まないWindows Update、やっぱり止まっていなかった

--

でセキュリティアプライアンスや、チャイニーズ製グレートファイアウォールなどが導入されている環境の場合、

Windows Update / Microsoft Update の接続先 URL について

によると、2017/2 現在....

http://download.windowsupdate.com
http://*.download.windowsupdate.com
http://download.microsoft.com
https://*.update.microsoft.com
http://*.update.microsoft.com
https://update.microsoft.com
http://update.microsoft.com
http://*.windowsupdate.com
http://*.windowsupdate.microsoft.com
http://windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://ntservicepack.microsoft.com
http://wustat.windows.com
—————————-
※Windows 10 の配信の最適化を使用するためには以下の URL も併せて通信を許可するように設定ください。
—————————-
*.download.windowsupdate.com
*.au.windowsupdate.com
*.tlu.dl.delivery.mp.microsoft.com

の全てを、プロクシキャッシュなどの、セキュリティアプライアンスを使う経路から除外しろ、という事になりますね。これらを除外リストにズラズラと Windows10 の場合(;) セミコロンで区切って羅列します。(それも全部)

コピペ用に書いてみましたが、プロクシがある環境では、例外リストを「こうしろ」という事ですかね。間違っていたらご指摘下さい。
------ここから
*.download.windowsupdate.com;*.download.windowsupdate.com;*.download.microsoft.com;*.update.microsoft.com;*.windowsupdate.com;*.windowsupdate.microsoft.com;*.ntservicepack.microsoft.com;*.wustat.windows.com;*.download.windowsupdate.com;*.au.windowsupdate.com;*.tlu.dl.delivery.mp.microsoft.com;
ここまで-----

ちなみに

Windows Update / Microsoft Update サイトへの接続先 URL は不定期に変更されることがございますので変更が生じた際は本ブログも更新いたします。

とあるので要チェックです。(つまり予期なく変更ということで.... はぁ?)

セキュリティアプライアンスなどの設定も要注意ということになります。あるいは "WinHTTP という謎” を克服するか。

どうも

netsh winhttp set proxy proxy-server=

というインディジョーンズも解読できない呪文を管理者モードで実行せよというのもありです。

これで謎の WinHTTP も強制的に、システムプロクシの設定に合わせてしまうようです。世間一般および新華社通信によると、どうもこのコマンドはプロクシを使う環境では香港土産の謎の萬金丹のように良く効くようです。

プロキシ サーバーを使用する環境にて Windows Update を実行すると通信エラーが発生する

じゃ、トランスペアレントプロクシだとかセキュリティアプライアンスがインターネット接続のトポロジのグレートファイアウォールにある場合はどーなるンでしょうね。ウチの環境の場合 WSUS サーバーも LAN内にあるので、WSUS 自体も Squid Proxy を使う事(なぜか問題ない)になるので、とりあえずは問題解決ですが、トランスペアレントプロクシがグレートファイアウォールを作って、そこから経由して WSUS がローカルで構築していない環境では、ちょっと困ったモンダイになりそうな悪寒です。

また必ずしも、全て WSUS 3.0 経由では当たらない「累積パッチ」もあるようです。この問題は Windows2012r2 標準の WSUS 4.0 で解決しているかどうかはわかりませんが....やっぱりこれも謎の呪文を唱える必要があるようです。

Windows Update で通信系のエラーが出た場合、近所のセブンイレブンとかの無料、暗号化なし Wifi フリースポットへ走って(あるいはPCをかついで)アップデートし、ついでにウィルスクサいメールをかたっぱしから開きまくって、アンチウィルスが正しく動作しているかどうかテストしたり、銀行振込してパスワードダダ漏れさせてみる、のもヒマつぶしには面白いかもしれません。

Squid 本家の次の文書も見つけましたが、情報が古くて全然アテにならないようです。どうやら "Windows そのものの問題” と捉えているようなので、あの謎の萬金丹のコマンドを使え、という見解のようです。

How do I make Windows Updates cache?

全く、Windows10 anniversary Update 以降の Windows Update はどうも問題が謎な部分が多くあります。中国製かと思われるぐらい不可思議.....
Windows7 時代に構築して問題なかった WSUS の運用方法も Windows10 時代では適応できないようです。


-その他の記事-

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server

WSUS のディスク容量がピンチ!空き容量を一挙に増やすには

Windows Update Service(WSUS) の日常の運用

Windows10の Windows Update はデフォルトで使ってはいけない。



※言い訳:すみません、いつも「串」って言ってるんで「風呂串=プロクシ」と読ンじゃう私はやっぱり古いタイプなのです。世間では「風呂岸」なんですね。




Windows10 WSUS 3.0 Windows Update Error Squid Proxy キャッシュ、キャッシュアプライアンス、プロクシ、プロキシ、



[PR]
by islandcenter | 2017-06-16 15:20 | プライベートクラウド | Trackback | Comments(0)


どうも世の中、Linux のサービスの、リストアップ、起動、停止を行うために chkconfig、service というコマンドがあるそうなのですが、 SUSE Linux を使う場合、まずお世話になることがありません。勿論、これらのコマンドは実装されているのですが、ほとんどのサービスの管理は # yast (or yast2) > System > System Service(SLES12 では Servie Manager) の中で行います。

SLES11 の System Servie
a0056607_13281346.jpg

この使い勝手よ良さは systemd を採用した SLES12 でも引き継がれ、Servie manager となりよりシンプルになりました・

SLES12 の Service Manager
a0056607_13284102.jpg

SLES12 の Service Manager , CUI 版
a0056607_13290645.jpg


勿論テキスト端末から、慣れた Service の再起動には # rcXXXX" コマンドや "#/etc/init.d/xxxx restart" を使いお世話になることもあります。その程度なら、何しろお手軽ですからね。

でも YaST で、インストールし、During boot をアクティブ設定をして、その他、必要な設定をすませば、ほとんどサービスマネージャを使う事もありません。もしサービスが安定していなくて「よく分からんぞ」という時は、YaST のサービスマネージャで、サービスのステータスチェックから、起動、再起動、chckconfig, inittab, fstab の書き換えまで行えます。
画面をスクロールしたり、難しそうに「うーむ」と唸りだしそうに眉間にシワを寄せて、非番の殺し屋が、突然ゴルゴ13の様なムズカシイ顔に変身して、綴りを間違ってキーボードを乱打しないので、非常に楽なのです。

何しろ、本棚の中から「誰でもカンタン Linux コマンドリファレンス」なんてアンチョコ本を取り出してページをピロリピロリと探すヒマがあれば、さっさと YaST を立ち上げればいい。まぁ私の場合、それほど難しい事をやっていないということもあるのですけどね。

※ ちなみに SLES12 では service/usr/sbin/rcXXXXX は service コマンドのシンボリックリンクになりました。

「難しいを簡単にできる」事が SUSE Linux の YaST なんですね。

でも、「自宅のXXサーバー」なんて記事を見ると、いかにもコマンドがズラズラで、これで「やっぱ Linux サーバーは使い易いや」なんて思っている人ってどれくらいいるのでしょうか。Linux の入り口で本当にその通りにやって途中で綴りミスなんかでエラーが出てしまって「挫折する」ヒトもいるわけだから、chkconfig だとか、yum や apt-get のマニュアルページをひたすらじーっと眺めて、YaST なら数クリックでできる作業も、Apache のインストールごときに、ごっちょりページを割いて「俺は Linuxの 使い手なのだ。タッチタイプのプロだぞ。スゴイだろ」という感じのコムズカシイドキュメントを作っているヒトってやっぱり、私よりは賢いけれど平均的なヒトから見ると、ちょっと特殊に思えてしまい、「やっぱり Linux では HTTPサーバーのインストールすら難しそう」となってしまいます。

YaSTは、昔、映画で見た、良く設計されたドイツの潜水艦の司令室みたいなもので、一つ人のコマンドを別個に使うのではなく、各種パラメータを一つのコントロールパネルで設定して最後にレバーを下すと、YaST に設定されたパラメータを次々と処理して「魚雷発射!ズシン!」となるわけですね。例えは悪いかも知れませんがいかにも SUSE Linux に標準の YaST はドイツ製、質実剛健、合理的な設計なのです。






- Keyword -

Linux サービス管理、chkconfig rcコマンド SUSE SLES openSUSE


[PR]
by islandcenter | 2017-06-06 13:20 | SUSE | Trackback | Comments(0)

SUSE Linux の YaST Partitioner によるパーティション管理を説明します。

SuSE Linux (SLES, SLED, openSUSE) のパーティション管理は、通常 YaST の "Partitioner" によって行います。勿論、「fdisk や fstab の直接編集の方が慣れている」のであれば、その通りで、SUSE Linux でも基本的なコマンドラインを使ったパーティション操作は、他のディストリビューションと同じです。ただ、アンチョコ本に書かれている様なパーティション操作に、不慣れな管理者にとっては YaST の "Partitioner" は心強い味方となるでしょう。

また私の様に「コマンド叩きには疲れたよ、老眼鏡ほしい」と言うような年寄管理者にとっても、一度 YaSTの"Partitiner" に慣れてしまえば、もう「コマンド叩きはいいや」と思うかもしれません。資料の少ない GParted の様なGUIを後で自己責任で導入するより、YaST Partitioner はSUSE によってサポートされる標準装備なので、安心して使う事ができます。

不用意な操作で、データがそっくり喪失されるパーティション管理は、事前にバックアップを取っておきたいくらい、わかり易い手順と確認が重要です。

- 起動 -

YaST の Partitioner は CUI 版 yast コマンドと、GUI 版 yast2 の両方に実装されています。

どちらかと言うと、[TAB][SPACE]{+][-] などを多用する CUI 版より、1クリックでダイアログが遷移する GUI 版の方が、誤操作は少ないかもしれません。やむを得ない場合を除いて、GUI 版 yast2 の Partitioner を使う方をお勧めします。何しろパーティション操作は、データロスを伴うエキスパートでもやりたくない非常に危険なタスクです。
という事でここでは SUSE Linux のGUI 版 yast2 の Partitioner からのパーティション操作を見てみましょう。

# yast2 & (またはyast) > System > Partitioner を選ぶと、一応「非常にキケンを伴う作業でデータを失うかも知んないけん熟練者だけやってケロね(意訳)」という警告のダイアログが出ます。 "Continue" します。

※なお、ここでは基本言語は English に設定しています。YaST は ALT+キーのショートカットは英語版の方が便利なんですね。勿論、言語を "Japanese" にすれば一応おおよそ理解できるニホンゴ表記になります

GUI版
a0056607_09390380.jpg
CUI版
a0056607_09404875.jpg
- 参考文献 -
Using the YaST Partitioner

- パーティションの作成 -

※今回は機材の都合により SLES11sp4 を使っています。

たまたまわずかばかりの空き領域が /dev/sdc にあったので、"Hard Disks" > "sdc" を選んで "Add" ボタンを押してみました。
a0056607_09431411.jpg

まずは、空きディスクを、プライマリパーティションにするか、拡張パーティションにするかどうかです。一般的なPC/AT アキテクチャでは、OSに関わらず一つの物理ディスクにはプライマリパーティションは4つまで作成できます。なぜそうなのかはここでは聞かないでください。もし間違っていれば、コメントください。

ここでは "Primary Partition"を作り、次に拡張パーティションを作ってみます。

サイズを最大サイズにするか、指定サイズに控えておくか、ここでは "Custom Size" を選んでみました。最大サイズ以下の数値を与えます。
a0056607_09445862.jpg

※ これば「アナタの趣味だ」とご批判あるかも知れませんが。ディスク容量を物理ディスクの "Maximum Size” にせず、数10Gb 程度、空けておくのがいいと思います。 dd で同じサイズ、モデルの別ディスクにフルバックアップコピーを確実に取れるし、いざとなれば、別な Linux のシステムをインストールして、 Rescue 用にも使えるかな、という、あくまでも「趣味」かも知れませんが。

"Extend" パーティションが用意されます。 > Next

a0056607_09464506.jpg

今度は拡張パーティションの中に Logical Partition を作ります。> Next

a0056607_09483507.jpg

さて、ここがキモなのですが、パーティションをフォーマットするかしないか、フォーマットするならどのファイルシステムなのか、同時に、マウントしてしまうのか、あるいは、手動でマウントするのかの指定を行います。

a0056607_09502831.jpg

SLES9 では RaiserFS が標準でしたが、SLES10/11 では Ext3、SLES12 以降は、ロールバックできるように "/(ルート)" に BtrFS、別に分けたデータ用のパーティションに XFS がデフォルトとなっています。ただし SLES12 でも、スナップショット、ロールバックがが必要であれば記憶には BtrFS も使います。/database だとかのデータベース領域だとか、仮想化システムのスナップショットを取りたい場合などですね。
SLES では Ext4 の読み取りだけをサポートしています。ひと昔前の openSuSEでは Ext4 が採用されていました。

"Do not Format partition" を選ぶと、パーティションは初期化されないので、例えば、他のシステムから取り外したディスクのデータをそのまま使いたい場合はこちらを選びます。

"Mount partition" をチェックすると、Mount Point も同時に指定します。例えば /var を別パーティションにするとか、独自のディレクトリ、/database を別な専用パーティションにするなどの場合です。"Do not mount partiton" をチェックすると /etc/fstab に書き込まれないため、mount コマンドでマウントする必要があります。iSCSI デバイスなどでは、まれにマウントできない場合があったり、外付けディスクの電源が入っていない場合や二台目のディスクが「ご不幸」になられた場合、"fstab のご指定のディスクが見つからないよ"となります。正常起動できないので、起動時に mount するかしないかはそれぞれの目的次第です。

まず、システムをインストールする時の1台目のディスク(Raidの仮想物理ドライブも)は、特に意識しない限り "Mount partition" です。
a0056607_09542069.jpg
さて、拡張パーティションの用意がスケジュールされました。

"F" のマークが付いているパーティションは"フォーマットするぞするぞ!" の予定フラグです。 "Mount Point" のところが "*" となっているのは「起動時にマウントする予定なし」あるいは、「まだマウントしない予定」というシルシです。"?" が付いているのは、fstab に書き込まれていない、手動マウントが必要なパーティションです。
a0056607_09563232.jpg

次の画面のサマリで内容を確認します。"赤字" で書かれているのは、「フォーマットしちゃうぞ、消えちゃうぞ、ホントにいいのか?」という警告です。 "Do not format" を選べば別な記述がなされるでしょう。
a0056607_10021526.jpg

"Finish" ボタンを押すと「執行」されます。ここまでの操作はあくまで予定で、コマンドライン操作のように、生きたまま皮を剥ぎ、指先を折るような、後戻りできない拷問ではありません。

指定された内容でパーティションはフォーマットされ、fstab が書き換えられます。

"Finish" すると計画されたジョブ通りにフォーマットや fstab の書き換えが執行され、 Partitioner は終了します。

ではもう一度 Partitioner で確認してみましょう。
a0056607_11302425.jpg

実際にテストしてみます。

sles11:/mnt # mount /dev/sdc5 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/sdc5,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try <--- おっと、失敗したみたい。
dmesg | tail or so
sles11:/mnt # cd test
sles11:/mnt/test # ls <---- 今の所何もない
sles11:/mnt/test # touch myfile
sles11:/mnt # umount /dev/sdc5
sles11:/mnt/test # ls -al
total 8
drwxr-xr-x 2 root root 4096 Jun 1 15:40 .
drwxr-xr-x 4 root root 4096 Jun 1 15:39 ..
-rw-r--r-- 1 root root 0 Jun 1 15:40 myfile <--- umount してもファイルが残っている
sles11:/mnt/test #

どうもうまく行かなかったようです。これは SLES11 で公式なサポートがない XFS を使ったことが原因です。

- パーティション削除 -

そこで、間違えてつくってしまったパーティションの削除をやってみます。物理デバイスからパーティションを選び右ボタン、あるいは Delete ボタンから "Delete"します。

確認して Next
a0056607_11374107.jpg
リストから消えました > Next

ここまでは、「作業の予定」が定義されただけです。 "Finish" ボタンで「執行」され後戻りできなくなります。不安があれば "Abort"してください。

実際には "Finish" によりパーティションのフォーマットが開始され、データが削除されます。
ここで不安があって、中止したい場合、最後のチャンスです。
"Abort" できます。

サマリ画面で、削除される予定であることが「赤字」で表示されることを確認して > Finish

a0056607_11403871.jpg
- 再度チャレンジ -

XFS パーティションのマウントに失敗したので SLES11 デフォルトの Ext3 フォーマットしてみます。後は同じ操作です。
a0056607_11434644.jpg

実際にマウントしてファイルが書き込めるか確認してみましょう。

sles11:/mnt # mount /dev/sdc5 /mnt/test <---- 問題ないみたい。
sles11:/mnt # touch /mnt/test/My-Test-File <---- ファイルを作ってみる
sles11:/mnt # ls -al /mnt/test/
total 24
drwxr-xr-x 3 root root 4096 Jun 1 16:39 .
drwxr-xr-x 4 root root 4096 Jun 1 15:39 ..
-rw-r--r-- 1 root root 0 Jun 1 16:39 My-Test-File <--- 作られたファイル
drwx------ 2 root root 16384 Jun 1 16:38 lost+found <--- パーティションのルートに必ず作られるディレクトリがある
sles11:/mnt # umount /dev/sdc5 <--- umount してみた。
sles11:/mnt # ls -al /mnt/test/
total 8
drwxr-xr-x 2 root root 4096 Jun 1 16:23 .
drwxr-xr-x 4 root root 4096 Jun 1 15:39 ..
sles11:/mnt # <--- 別パーティションのファイルは見えなくなった。

どうやらうまく行った様です。

マウントしてもう一度 Partitioner で確認してみます。
a0056607_11481185.jpg
"Mount By" に "?" が付いているパーティションは、fstab にかきこまれていない、手動でマウントされたものです。パーティション作成の時に "Mounting Opttion" > "Mount Partition" をチェックしてマウントポイントを指定しておけば、fstab に書き込まれ、起動時に自動的にマウントされます。

※ これはテスト環境なので、起動ディスク以外のパーティション以外は手動マウントしています。物理ディスクをデータ用に追加した場合、もしディスクに障害があると、fstab にマウント指定されていると起動できなくなります。仕方がないので Rescue 状態から、皆さんの大好きな vi エディタで fstab の該当の行を削除(コメントアウト)する必要があります。


- いかがでしたか -

SUSE Linux でのパーティション管理は、熟練エンジニアにとっても手軽だし、「まだ未熟」な Linux オペレータさんにとっても、割と理解しやすいインターフェースが YaST の中に用意されています。Linux の"キホン"さえ知っていれば、「パーティション操作」という、データロスにつながり易いクリティカルな作業も、fdisk の難解なコマンドオプションと表示内容を理解して、闘う必要もなく、何とかなるものです。

他のディストリビューションでは、これほど使いやすいパーティション管理ツールが「標準装備」されているわけでもなさそうですし、たとえ 「GParted の様なGUIツールがあるじゃん」と言っても、GParted パッケージそのものが一般的なディストリビューションにデフォルトで付属されてインストールされていないようですし、インストールで挫折するくらいなら、ハジメから「Linuxを知りたいし安定して使いたい」事を目的としては SUSE Linux の敷居の低さが理解できるでしょう。



- Key Word -

Linux パーティション管理、パーティション作成と削除の方法、SUSE Linux、SLES、SLED、openSuSE、yast、


[PR]
by islandcenter | 2017-06-02 11:52 | SUSE | Trackback | Comments(0)