No.1
メモ種別: 外来種の宇宙船
星系: エチュズク・フク
銀河: ユークリッド
遭遇場所: 宇宙ステーション
ゲームモード: 共同探検#1 REDUX
外見・ポータルアドレス・性能:
2021/11/25遭遇。
多少宇宙ステーションで待機する必要があった気がします。
No.1
メモ種別: 外来種の宇宙船
星系: エチュズク・フク
銀河: ユークリッド
遭遇場所: 宇宙ステーション
ゲームモード: 共同探検#1 REDUX
外見・ポータルアドレス・性能:
私しか知らない星系なので記録しておきます。
(おまけ情報追記-2021/11/24)
ゲームモードはパーマネント・デス、ユークリッド銀河です。
星系名はアーリネズブ、マルチツールの売り場は惑星「ツレフ」の小規模な開拓地です。
なお、この星系は、以前の記事で深赤の外来種の宇宙船が飛来する宇宙ステーションがある星系と同一です(記事を書いた自分が忘れていました)。
見つけたSクラスのマルチツール売り場のある星のポータルアドレスとマルチツールの外観は以下の通りです。
白を基調とした市松模様をあしらったシンプルデザインで素敵です。ま、単に私好みってだけなんですが。便利に使わせていただいております。
批判だなんてとんでもないこってす。そんな意図は毛頭ございませんので念のため。
私が悪いんです。
前置きです。
久しぶりにGitBucketを更新する衝動にかられました。
4.31.2から4.36.2です。
過去の例から絶対何か起きるな、という確信がありました。
だから、全然ちっとも悔しくなんかないんだもん。
今回は4.36.2にwarを置き換えたとたんにこんな感じです。
19:12:49.124 [main] ERROR com.zaxxer.hikari.pool.HikariPool - HikariPool-1 - Exception during pool initialization.
org.h2.jdbc.JdbcSQLException: テーブル "REPOSITORY" が見つかりません
で。4.31.2に戻しても
Caused by:
com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: テーブル "REPOSITORY" が見つかりません
だそうで。
4.36.2がテーブルをぶっ壊してくれるみたいですね。
そのため、4.31.2に戻しても後の祭りと。
すげえなあ。後方互換などには目もくれぬ未来しか見つめない設計思想。まさに聖帝サウザーばりですね。「ひかぬ。媚びぬ。顧みぬ。」でしたっけ。
多分4.31.2からリリース順にリプレース/起動/停止を繰り返してアップグレードすれば問題ないんでしょうね。思いついたときにドーンと更新した私が悪うございます。
この事例は以前もありましたので、もうこれ使うのやめたいなあと思っていながら惰性で使い続けたのも自業自得。
使うのをやめるつもりだったので、GitBucket専用の設定ファイル類のバックアップはとってませんでした。これも自業自得です。
ところで、タイトルにはH2データベースが壊れた、としましたが、この様子だと、GitBucketさんはH2データベースを信頼性がない云々で目の敵にしておいでですが、H2だから壊れたんじゃなくてGitBucketさん自身がぶっ壊しているようにしか見えません。
まあ、私が確認した範囲内ではH2データベースが壊れたのでタイトルはそのままにしておきます。
まあ、さっき新規プロジェクトをコミットしたばっかなので、その辺復旧できるなら復旧したいなあということで、試みてみました。
この際、懸案だったGitBucketから別のシステムに移行する手間か、単純にこの場は復旧だけしておいて済ませるか、多少考えないではありませんでしたが、結局やっつけで済ませられるほうを選びました。
まず、H2データベースのダンプを試みます。
H2公式から1.4.200をダウンロードしてみたところ、ファイルポインタがどうのこうのでさっぱり使えません。
何を言ってるのかわからないので早速検索をしたところ、199を使わないとダメなんだそうで。
なんなんだそろいもそろってjava業界って・・・未来しか見えてないのね。
ちゃっちゃとおわらそう。
java -cp h2-1.4.199.jar org.h2.tools.Shell -url jdbc:h2:file:data -user sa -password sa
で中身をのぞこうとしても
「org.h2.jdbc.JdbcSQLException: テーブル "REPOSITORY" が見つかりません」
この段階でDB全体の整合性が整っていることが必要なのね。
ウームと唸って、さらに探すとRecoverというツールがあるらしいので助かりました。
カレントディレクトリにdata.mv.dbがある前提で
java -cp h2-1.4.199.jar org.h2.tools.Recover
と実行すると、data.h2.sql とdata.h2.txtという2ファイルが生成されました。
そこで、data.h2.sql をさっそくのぞいてみると、O_??(数値)というあからさまにテンポラリな名前のテーブルがいくつか作られていました。
そして、そのテーブルに対してINSERTが発行されています。
さて、このO_で始まるテーブルは何なのかな?と思って、よくよく調べてみると、スクリプトの後半で本来のテーブルと思しきテーブルにinsert from selectしてました。
なるほど、制約条件の整合性対策なんだろうな、と納得した次第です。
で、確かに、テーブル "REPOSITORY"はありません。
その代わり、REPOSITORY_COPY_3_3っちゅーのが見つかりました。
なーんだかよくわかんないですけど、こーゆー名前のつけかたって、多分、ver3.3のころにアップグレード処理を入れた名残なんでしょうかね。
あれ?でも、これ、insert文にさっきgitにcommitしたばかりのはずのリポジトリ名も入ってる・・・
わけわかんないけど、これに対してinsertしているのをテーブル "REPOSITORY"に向けなおしときました。
ついでに、カラムが追加されてるテーブルがあり、insert文が通りませんでした。
そこで、4.36.2で新規作成した空のデータベースファイルをダンプして比較したところ、create table文にカラムが追加されており、default trueとか書いてあったのでinsert文の該当カラムにtrueを追記しておきました。
そして、それらテーブル名とカラムの追加を行ったinsert文をh2-1.4.199.jarではなくGitBucketの管理コンソールの「Database viewer」なる機能から流し込んでみたところ、見た目は復旧出来たっぽいのでもう終わりにします。
H2公式ツールを使わなかった理由は、二つあります。
いくら公式だからってh2-1.4.199で読めてh2-1.4.200で読めなくなるようないい加減なツールなんかおっかなくて使いたくないし、GitBucket自身が何を使ってんのか知らないのでこのプログラム自身が使ってるライブラリでDBをいじらないとまた七面倒なことが起きそうだと思った次第です。
ま。こんな感じです。
更に次回、やっぱり惰性で使い続けて似たようなことが起きた場合に備えて忘備録としたいと思い記録しました。なお、cronでバックアップする元をリポジトリ以外にGitBucketの設定定義体も念のため加えておきました。GitBucketを廃止したらこれを忘れずに除去しなくてはならないのが今からおっくうです。
こんな戯言にお付き合いいただき、誠にありがとうございました。
表題のゲーム、ノーマルモードである程度経験を積んだので、パーマネント・デスモードで遊んでみることにしました。
記事を長々と書く前に、まだチュートリアルすら終わっていない段階でとりあえず星系をいくつかはしごしただけで以下のような成果物を得られますという具体例をお示しします。
また、私しか知らない星系なので、という意味もあります。
銀河は(当然)ユークリッド銀河です。
まず宇宙船です。
アーリネズブ星系の宇宙ステーションで遭遇しました。
宇宙ステーションに3台目に到着しますので待つ必要がありません。
見た目とポータルアドレスは以下の通りです。
性能と名前は以下の通りです。
幸運なことに20スロットすべてが解放されていましたが、これは飛来順と異なってランダムな気がします。
お次はマルチツールです。
Aクラスならそこかしこで見つかりますので特記する必要はないと思いますが、今回はSクラスが見つかってしまったので、本来は具体例から外れてしまっているのですが、私しか知らない星系なのでここに記録したいと思います。
星系名オマルクフの宇宙ステーションで、見た目とポータルアドレスは以下です。
性能は以下の通りです。
なお、同一星系にあるオトフォルドという惑星ででセーブ/ロードをして宇宙ステーションに戻ってくると、実験的10/15となります。
さて、第一回目のセーブデータでは、宇宙船にたどり着けないまま、ソジウムも一休みするための洞窟も見つからないままにあえなく死亡しました。
第二回目のセーブデータでは、無事に宇宙船にたどり着け、それ以来まだ死んでいません。
まだ死んでいない、というより、宇宙船にたどり着いてしまえば、死のうと思って行動しない限り、もう死ぬことはまずありませんから、本当に最序盤は単なる運ゲーです。身もふたもないです。
無事に最初の基地を設置したら、次に行うのは金策かと思います。
とりあえずインベントリを実用程度に開放できて、扱いやすい船を購入できるだけの額を得るのが仮の目標となるでしょう。
ラディアント・ピラーをじっくりアップグレードするのも乙なものなので、その方向でプレイしてもいいと思いますが、結構な資金やナノマシンが必要となりますので、差し当たって当座の運用を行う宇宙船は別に確保してもいいでしょう。
最初期の金策の目標額としては、宇宙船は外来種でいいなら、後述する貿易用資金と合わせても具体的な額としてはとりあえず20,000,000ユニットもあれば十分でしょう。
このプレイ段階でこのゼロが並んだ数を見るととても高額に見えますが、ノーマルモードで一度経験を積んだおかげで、実際にはそれほど時間がかからずに稼げてしまえます。
いずれにせよ序盤で入手しておけばラディアント・ピラーに比べると雲泥の性能差なので、スペースレスキューやアルテミスミッションなどの遂行が大変楽になります。将来買い替えるつもりでもまずは一隻所有して置いて損はないと思います。
宇宙船全体に言えますが、宇宙ステーションに限れば一度発見してしまえば、その場ではユニットが不足していても、その宇宙ステーションに必ず来ることはわかっているわけですから、ゆっくり金策して買えば済みます。
さて、その金策ですが私の場合は、初手での金策は、自然の墓の墓荒らし発掘調査が好みです。
気候もセンチネルも穏やかな星に古代の残骸が見つかれば何の危険もなく多額の初期資金を手にすることができます。
お骨一つで高ければ1,000,000を超えるので、20か所も荒らせば供養すれば立派な小金持ちです。
墓巡りと並行して同じく地下から回収できる「回収データ」もある程度揃えておけば、次の段階の金策のためのテクノロジの解放に役立ちます。
どうしても理想的な古代の残骸がある星が見つけられない場合や、骨が大嫌い、生臭そう、という場合は、手間いらずな金策として、貿易があります。
貿易は、できれば初期費用として10,000,000ユニット程度あれば楽に資産を増やせるので、私自身はある程度の元手を得たら移行していますが、背に腹は代えられない場合でも、購入・運搬できる分だけでもこまめに売買を繰り返せば十分に小金持ちになれます。
しかも、宇宙ステーションをテレポートで行き来するだけです。
宇宙ステーションの反対側の島に渡る必要すらありません。
なお、売り払う場合は、貿易ターミナルではなく、地図製作者に売り払うと、より高額で引き取ってくれます。
地図製作者の属する相場情報はおそらく惑星上の相場とリンクしているんだろうと思います。
買い取る場合も実際には宇宙ステーションではなく惑星上の貿易ターミナルから購入したほうが廉価で仕入れることができるのですが、面倒だけど高額な金策手段ならほかにもいろいろありますから、貿易まで面倒にするには及ばないと思います。
なお、早めに船に経済スキャナを搭載しておいたほうがいいと思います。
ワープ前に経済レベルを知ることによるメリットは以下の通りです。
私の場合は、古代の残骸漁りに飽きたら貿易に移行しています。
貿易には宇宙ステーションの数がものをいうので、手を広げている間に使い勝手のいい船やマルチツールも同時に探しておくと効果的に序盤をこなせると思います。
金策と並行して、インベントリのアイテムスロットの解放も行うといいです。
最初のうちは小銭でアイテムスロットを拡張できますから、お骨を数個を売り払っただけで宇宙ステーションやスペースアノマリーで相当数のスロットを解放をするには十分な額となります。
無論、そのためには1星系あたり1スロット、チュートリアルを進めると2スロットしか開けられませんので、ワープで星系を渡り歩く必要がありますが、これは貿易での金策およびもっと扱いやすい宇宙船やマルチツール探しのために役立ちますので損はありません。
ユニットでスロットを解放しない場合は、投下ポッドに頼ることになります。
この場合、次の問題点があります。
もう一つ、これは自発的に行うというより必ず序盤に発生してしまうのですが、貨物船の入手です。
しかも1隻目なら無料、かつ未強化のラディアント・ピラーでも十分撃退できる程度の海賊しか襲ってきませんので、早めに手に入れておきますと、さらに次の金策や遊び方に何かと便利だと思います。
無論、別に無理に所有する必要はありませんが、貨物船さえ入手してしまえば、貿易だけでの金策でも貨物船のフリゲートもCクラスであれば一隻2,000,000ユニット以下で譲ってもらえるので1回の貿易で1~2隻は揃えられます。所詮フリゲートは最大でも30隻しか所有できませんから、結果としてすぐ定員いっぱいまでそろってしまいます。
フリゲートがそろえば寝ているだけでお金が増えます。
貨物船そのものはできれば大型が望ましいと思います。
というのは、大型貨物船は最初から解放されているアイテムスロット数が格段に多いためです。
アイテムスロットの拡張には遺棄された貨物船の探索で得られる資材が必要ですが、危険度がそこそこ高いイベントです。
パーマネント・デスモードでは君子危うきに近寄らず、ということで避けられるなら避けたいところです。
また、クラスは無論、初めての貨物船をSクラスを引くまで粘ってもいいですが、Aクラスで妥協しても実用上は何の問題もありません。Aクラスなら入手性が比較的高いという点も見逃せません。
むしろ、最初でイライラしながらSクラスを目指すより、序盤を脱出して、銀河を超えて、それでもなおそのセーブデータでやる気なら、改めてSクラスの貨物船を求めてもちっとも遲いことなんかありません。
このゲームはやれることは確かに多いかもしれませんが、深みも何にもない単純作業ばかりの寄せ集めゲーなので意識しない限りすぐマンネリ化するため、その頃にはむしろ「やることが増えてうれしい」と思うかもしれません。
特に必要はないけど「いつかはSクラス」と思いながら、たまたまワープアウトした先での遭遇戦だけで目指すプレイというのも結構乙なもんです。
私の場合はノーマルモードでは大型のAクラスを運用していますが何の不満もありません(隔壁の拡張すらしていません)が、どうしたことかパーマネント・デスモードでは大型のSクラスを引くことができたのでラッキーでした。
無論、燦然と輝くSのロゴは気分はいいですが、裏を返せば、言うまでもなく所詮それだけの事です。
マルチツールと違って、Sだからといって実用性が大きく変化するわけでもありません。
余談が過ぎましたが、貨物船の序盤での入手で何が便利かといえば、具体的には軌道エクソクラフト具現化装置だけでも十分に便利です。これは回収データだけで設置できますので序盤で十分に設置可能です。
惑星上ではセンチネルにねちっこくからまれやすく、劣悪な気候によるダメージ量も多いゲームモードなので、ノーマルモードよりも有用性が高いと思います。
また、物質転送ビームが必要なため、それが設置できる状況はもはや序盤とは言えませんが、持ち歩く必要があるほどではないが、必要なときには必要となる資源、例えばエメリルやコバルトといった物資、または逆に頻繁に必要となる炭素や酸素を備蓄できるのは便利です。また、埋蔵資源を貯蔵するための基地の作成にはむやみに金属プレートが必要ですが、これを貨物船で保管しておくと基地の設営が楽です。
これだけやれば、チュートリアルが終わらないうちにも、もはや序盤は卒業でしょう。
あとは銀河の中心に向かって進んで銀河を超えて実績を解放しておしまいです。そのまま(このゲームそのものを含めて)続けるかどうかは気分次第です。
このような戯言をここまでお読みいただいて、まことにありがとうございました。
別銀河へ向かう途中でSクラスの実験的の24スロットを持つマルチツールを見つけたので記事にしたいと思います。
プレイ環境は難易度ノーマルのPC(Steam)版です。
売り場がある星がある銀河はアイセンタムです。Eissentamです。
ユークリッド銀河ではありません。
ご注意ください。
なお、宇宙ステーションで一度ロードしてから宇宙機で次に示すポータルアドレスの星に向かってください。ワープなどで以下にお示ししている売り場に行ってしまうと別のタイプのMTが売られていることになりますのでご注意ください。
MT売り場がある星のポータルアドレスはこちらです。
(実はポータルアドレスとは何なのかよくわかってないのですが、これでSクラスMT売り場がある惑星に来れるようなので一応)共同探検#3を終えて、元のセーブデータに戻ってプレイ再開です。
共同探検#3では外来種という宇宙船を駆って宇宙を飛び回っていたはずなのですが、元のセーブデータのラディアント・ピラーBC1に戻っても、全然違いを感じないのは戦闘機という種別だからでしょうか。
操縦性能がいいし、機体がコンパクトで取り回しがいいのが何より重宝します。
いつかはいい船を手に入れるつもりなので宇宙機の倉庫やグレードなどのアップグレードは一切しない方針でプレイしましたが、ちっとも苦になりません。
戻ってきた後もチュートリアルを進めることはせず、多少分かったようなふりをして、一番最初に私が放り出された星系内の惑星の探索やらをちょこちょこと行っていると、あるとき、たまたま訪れた施設で出会ったばいきーんのおっさん?お姉さん?から、ライフル型の大きなマルチツールをプレゼントされました。
ランクはCでしたが、早いうちにたくさんのアップグレードをインストールできるマルチツールをもらえたことは大変幸運だと思いました。
いまとなっては、このゲーム、最初のうちは資源の獲得方法が分からないので、ひたすらマルチツールで必死に資源の収集をしていましたが、そのうち、店で買ったり、埋蔵資源を自動で抽出したりと、いろいろ横着できる方法が分かるにつれて、マルチツールなんかどうでもよくなりました。
そのため、序盤でスロット数が多いマルチツールを得られたことはなお幸運だったと思います。
そうやって遊んでいるうちに、週末にはイベントがあるということを知りました。
週末ミッションというそうです。
早速参加してみましたが、これは共同探検などとは違って、数時間程度もあれば終わるもののようでした。
と、いうよりも、なんと、一度開始をすると、ゲームを中断することができませんでした。
ゲームを中断すると、ミッションそのものが取り消しとなるのです。
思わず、「なんてこった、こんな雑なセッション管理をしているのかこのゲーム会社!」と感銘を受けてしまいました。
開催期間の管理やセーブデータの形式変更やら、いろいろとセーブデータにこのミッションの状況を保存するのが面倒だったんでしょうね。お察しします。
あと、ポータブル精製機以外でも精製機があることを知りました。
燃料いらずで稼働できるので、さっそくそれを基地に設置しました。惜しむらくは設置数に制限があるようです。また、ものや量によっては数十分単位の作業時間が必要となるみたいです。
それは構わないのですが、驚いたことに、機械に材料を入れて作業させたまま、星系を離れたりするような遠出をしてしまうと、中身が消失してしまうという雑っぷり。
すげえ、ほんとにすげえ。
おそらく、星系を離れるとfreeされるメモリかなんかに保存してある情報なんでしょうね。で、それはそのままで直さない。すげえ雑。その一方で、移動さえしなければ、機械を作動させたままセーブしてゲームを終了する分には消失しないという超半端な扱いがこのゲーム会社らしいと思いました。
セーブデータに保存するコードはかけても、星系をまたぐコードは書けないのが興味深いところです。
もしかして、と思って食品加工機械みたいなのも同じかと思ったら、こっちはもっとひどかったです。こっちは星系どころか、ある一定の距離を離れただけで中身が消失しました。
これには思わず笑ってしまいました。
いずれにせよ、機械が作業している場合は傍らから動いちゃいけないみたいです。この会社の面目躍如という感じがします。
こんな事象が起きたら、一般的に言えば理不尽だと非難されると思うのですが、それでも神ゲーだというのです。まだまだ探索の余地があります。
また、人工衛星みたいな呼び出せる星に行くと、なんだか知りませんが売値が50,000,000もするAIナントカというのを押し付けられてしまいました。
その時の私の所持金はおよそ12,000,000くらいだったので、すごい嫌な気分になりました。
しかも、抗議の仕方が分からないので、仕方がなく、黙って立ち去りました。
この辺は、オンラインゲームならではとも言えますが、受け取りの諾否を与える機能がないってのは、やっぱりこの会社らしい雑なつくりで、ブレがないことには感心します。
その後、やっぱり気分が悪いので捨ててしまった後、当初は中断できないのでやる気はなかったものの、気分転換になるかと思って、私にとって2回目の週末イベントを開始しました。
そのイベントで飛ばされた先の宇宙ステーションで、ふと見ると、外来種の宇宙船が停泊しているのを見つけました。
しかも、私の好み通り、小型で、装飾もシンプルで、色使いは白系であっさり。
あとから知りましたが、球形コクピット型といわれているそうです。
一目で気に入ったので急いで近づいて価格を尋ねてみると、11,000,000そこそこで売ってくれるとのことだったので、早速購入しました。
もしかして、週末イベントはこういう星系が選ばれたりするんでしょうか。
その週の人工衛星は同じような宇宙船が多数停泊していたのが印象的でした。
非常についてました。
もし、AIナントカを捨ててしまった後、所持金が足りずに購入できなかったとしたら。
厚顔にも、捨ててしまったことを後悔したかもしれません。
そんなことにならずに、むしろ、この船に出会える機会を与えてくれる結果となりました。本当に良かったと思います。返す返す「ついていた」と思いました。まるで塞翁が馬のようです。感謝しなければなりません。
余談ながら、うかつにも、この球形コクピット型の外来種を見て、「あ、ゴテゴテ装飾がついていたけど、共同探検#3の機体ってこれがベースだったのかな」と今更ながらに思い至った次第でした。
まあ、そんなこんなで、チュートリアルの続きもせず、エクソスーツのスロットの拡張だとか、ちょっとした工作をするときに不足しがちな資源の売り場探しが面倒なので資源の自力調達をすべく、いくつか地下資源や凝縮ガスを収集する基地やらを設置したり、あれこれつまみ食いをしながら遊んでいるうちに、共同探検#4が始まったので早速参加してみました。
今回は画面が揺れたりすごく鬱陶しかったのですぐ終わらせようと思ったせいもあるかもしれませんが、これまで学んできたことは無駄ではなかったと見えて、#3では通算24時間以上かかってクリアしたものが、今回はあっさり無事に終わらせることができました。
終わったあとで、冒険を振り返ろうかとWikiを参照してみると、まだこの共同探検の記事は作成中とのことでしたので、これまで学んだ成果がいかせたのかな、と思います。
今回の#4のプレイ中、人工衛星みたいなところでエクソスーツ拡張用のアイテムを大量に押し付けてくる人がいましたが、このセーブデータも完了次第に捨てるつもりなのでお礼も言わず抗議もせず、ただひたすら無視して捨てました。
なんか知らないけどやたらと私の周りを付きまとってきたので、推察するにお礼かなにか欲しかったのかもしれませんが、そんなことはしません。
渡しているほうは親切のつもりなのかもしれませんが、変に対応すると面倒なことになりそうですし。
やがてあきらめたのか、ほかの人にさらに大量に押しつけてました。
今回の#4は何がごみで何が必要なものなのかさっぱりわからないまま進めたので、アイテム欄が大変厳しかったのは事実ですが、フェイズを踏むごとに3つづつ増えていく構成でしたし、そもそもエクソスーツのアイテム欄の拡張なんぞ、大した手間でも何でもないことがこの時には学習できていましたので、恵んでもらっても面白くも何ともありません。
ところで、DUNEの日本語翻訳版って絶版になってた気がしますが、今回の映画に合わせて復刻したりするのかな。
はるか昔に読んだあの小説はなかなか面白かったですが、今はもうどこにあるやら・・・
それはどうでもいいとして、#4でも今までやったことがなかった貨物船の探検とかの経験ができてまた新たな要素の学習ができたので参加してよかったと思います。
そういえば、この記事を書く際に、どんな内容だったかな、と思って、Wikiの#4の記事ができていたのを幸いに読んでみたのですが、ちょっと不思議に思ったのが、「MPK」という言葉でした。
このゲームでは、ゲーム内で拾えと言われているアイテムを拾おうとするとモンスターが出てくるのが当然のところで当然の行動をとってる人を捕まえてMPK呼ばわりするもんなんですかねえ。とても奇妙に思えました。
MPKというのははっきりとした悪意を持った行為を指すものと思います。
知らない人向けに記述するとしたら「幼生コアを得るには囁く卵を攻撃する必要がありますが、その卵は攻撃を受けると周りにモンスターが生成されて周りにいる人を攻撃するので注意してください。よくわからない場合はネットワークオプションからマルチプレイを無効にしてから近づいてください」と書けば済む話です。
もしかしたら、自分の幼生コアにするつもりが先にとられて、単純にかなりカリカリしている人が執筆したのかもしれません。
マルチプレイヤーゲームである以上、当たり前すぎるほど当たり前だし、簡単にシングルプレイヤーモードに切り替えられるのにMPK呼ばわりというのは本当によくわかりませんでした。
もしかしたら私が主にプレイしていた時代とは言葉の定義が変わっているのかもしれませんね。勉強になります。
まあ、そんなこんなで共同探検#4も無事終えて、再度元のセーブデータに戻ってきたのですが、特にコレ、という目的もないので、今まで放置してきたチュートリアルの続きを始めてみました。
まあ、こういったミッションだかクエストだかがあると、とりあえずプレイの目標とはなるので、徐々に進めました。
進めるうちに知らないこともさらに学べましたし、ある程度は楽しめました。
テキストが表示域内に収まらないので読めないとか、クリアしたはずのミッションがログに残り続けるとか、基地を立てると配置によっては床から土が湧いてきたりとか、そういう雑さはしっかりしていてブレがないですね。
ただ、20回近くワープした挙句にわけのわからん絵文字にエネルギーを与えることに何の意味があるのかが分からないままで終わってしまったのと、潜水艦のミッションが壮絶に鬱陶しいことが印象に残る体験でした。
ただ、潜水艦のミッションで分かったことは、水面はどんな嵐でも常に水平を保ったまま(凪いだまま)荒れないということです。
これは基地を設置するのにとても便利だと思ったので、さっそく水上に植物園みたいなガラスドームみたいな基地を大量に並べて、使う当てなんかまったくないにもかかわらず、全種類の植物の栽培を開始してみました。
なかなかきれいな見栄えに仕上げることができました。
また、水中でも水上でも凝縮ガスや電力や埋蔵資源はお構いなしに収集する建造物が設置できることも学習できました。
それと、なんか居留地を作れみたいなミッションがあったのですが、これだけは見た瞬間、拒否しました。どうしてもFallout4のアレを思い出すからです。あんなもん、もうやりたくないです。もし違ったとしても、やっぱりやらないと思います。
「監督官」なんて言う言葉はどうせろくな意味じゃないに決まってますもの。
まあ、それやこれやでミッションをこなしていきましたが、相当もったいぶったストーリー展開の挙句、一通りミッションが終わると別の銀河におっぽり出されてしまいました。(ところでこの「記憶」って拡張、なんなんですかね・・・?)
ところが、これがまた壮絶に「今までの銀河」との違いがまったく分かりません。
ゲックとかバイキーンとかという種族はそのまんまですし、宇宙ステーションも地上構造物も何もかも、デザインも全く同一、機能も同一。
なにこれ、という感じで唖然としてしまいました。
しかも、ワープ?テレポート?であっさり元の銀河に帰ってこれるとか、ますます意味が分かりません。
最初からワープして別の銀河でもどこでも行けばいいじゃん。
あまりにも新銀河といえども「どうでもいい感」が強いのでどうしたものかと不思議になって、スポイラーだらけと警戒してあまり読んでいないWikiで思わず調べてしまいました。
すると、以前は一度別の銀河にたたき出されると、帰ってくる手段がなかったようでした。正確には帰ってこれるんだけど、銀河を256回超えて初めて帰ってこれるというような仕様だったようです。
なるほど、それならこの勿体ぶりもやむを得ないな、と妙に納得しました。
しかし、現在の私がプレイしている時間軸では、銀河を移動するということに何の意味もありません。つまり、今の私は、ほんとにヌルい世界の宇宙の住人だったのでした。
なんかほんとにザンネン感がひどいため、仕方がないので、それを補うべく、今は、別の銀河からさらに別の銀河に移動すべく、ちまちまとワープとブラックホールでもって銀河の中心を目指しています。
いまはやっと、銀河の中心まで450,000(単位は何だったかな)まで近づいてきました。
さすがに思った通り、馬鹿みたいに単純な作業が続くので、宇宙の広さを実感することができます。一番最初に銀河をこえた「ちょちょいのちょい」のワープ回数とは比較にならない作業量です。
ついでに、ただ中心を目指すだけでは面白くないので、ワープアウトするたびに宇宙ステーションに立ち寄って、マルチツールを眺めています。
CとかBクラスなら実験的とか異星人とかが結構見つかるもんなんですね。
いつかはSの大型ライフル型の実験的マルチツールが見つかるのかな。
なくても全然かまわないので、ほんとに気楽に旅ができます。
そういえば、unsigned long long intな18,446,744,073,709,551,616もの星があるのが売り文句だそうですが、こんなものただのこけおどしですね。
こけおどしには違いありませんが、この数値には大変夢があることは確かです。
まあ、実際問題として、宇宙ステーションのワープ?テレポート?先のリストはすぐあふれてしまうし、どうせこの分だと自分の基地だって一定数作ればもうアクセス不能になるに決まってることがありありと想像ができます。
まあ、なんか座標とかメモっておいて自力でエクセルとかで管理表を作って、宇宙船でワープしていったりすれば帰れるんでしょうけど、そんなことしますかねえ。
ま、私は絶対しません。
それにそもそも、セーブデータはちゃんと18,446,744,073,709,551,616もの星を、しかも256もある銀河の、データを、きちんと正しく保存できるのでしょうか。
せめて、「訪れたことがある星系」リストだけでも正しく表示できるのでしょうか。
この会社の雑具合から考えると、できないと思います。
そもそも、signed char (8bit) の範囲だってまったくできるとは思えません。
加えて、家庭用ゲーム機向けが主要顧客のようですから、「やる気になればマシンスペック次第でどうにでもできる」という状況でもなさそうですからね。
18,446,744,073,709,551,616という数値は夢がある。ただそれだけでいいじゃないか、という具合にとらえておくことにしておきたいと思います。
今日もワープを数回繰り返して終了しました。惰性でやるにはちょうどいい塩梅です。
ま、起動時間がかなり長いので、いつまで続くのかは謎ですが、どうせ元の銀河の基地には戻ってこれるので、何かほかに思いつくことがあればやってみたいと思います。
今のところ、まだ神ゲーといわれるような要素には出会えていません。
週末イベントは中断できないので最近はやってません。その辺も神ゲー要素に出会えない所以なのでしょうか。
もしも、私が似たようなキャッチをつけるとしたら。
そう、当然「雑ゲー」になると思います。
しかし、きっとどこかに神ゲー要素があるからこそ神ゲーといわれているはずです。
いつの日か出会える日が楽しみでなりません。
チュートリアルもそこそこに、さっそく実践編とばかりに共同探検#3を開始してみました。
終わってみて振り返ってみると、これが私にとってこのゲームの実際のチュートリアルとして大変役に立ちましたので、ゲームを開始した時期で言えば、大変ついていたと思います。
その理由は、宇宙船が壊れていて、その宇宙船を修理することが大きな目標になっていたため、様々な素材を調達したり、エクソスーツ内で加工したりといった作業を最初のチュートリアルよりも学習できたことと、「フェーズ(普通は段階を追うとか、順を追う場合に使うと思うんだけど)」と書いてあっても無視して前後して作業してもよいという、このゲームの雑さ具合は言葉の定義そのものを変えてくるということが学習できたことです。
また、マルチプレイモード?だと足がかかりとしての自分の基地を作ろうとしても作れない、ということも学びました。
この点で面白いと思ったのはマルチプレイとシングルプレイをゲーム内の設定で切り替えることができることでした。状況に応じて切り替えをするという発想そのものが珍しいように思います。
ところで、今にして思うと、この共同探検での自分の宇宙機は外来種だったような気がします。
当時は宇宙機の違いなんかさっぱり分からないので、ちっとも気づきませんでしたが、かなり貴重な機体なんだそうです。もし知っていたら、イベント終了後もそのセーブデータを消さないで遊んでいたかもしれません。知らぬが仏とはこのことだと思いました。
その他、工場の使い方とかも学びましたが、エクソクラフトなる乗り物についてもここで学習しました。
しかし、ミノタウロス・エクソクラフトという機械を作るように指示されて作ったのですが、とにかくEキー長押しで設置できる、すべてのアップグレードをつけなくてはならないものと思い込んで、何かを間違って、「酸」が必要な拡張を設置してしまったため、ミノタウロスを一歩も動かせなくなってしまいました。
なにかBクラスのアップグレードだったと思います。
これを動かすには「酸」とやらを手に入れて、拡張の設置を完了させなくてはならないようですが、その「酸」はどうやって作るのか、あるいは買うのか、共同探検を完了した後まで、さっぱりわかりませんでした。
後日、スペースアノマリーでレシピを買って、自作するもんだということが分かりましたが、後の祭りです。その当時は本当にわかりませんでした。
まあ、なんか見た目も超ウゼェロボだし、どうでもいいやと思って放置していましたが、フェイズ4の「クロスカントリー」という課題で、「エクソクラフトで15,000u移動」という内容があるので困ってしまいました。
このまま「やり直しをするか、全部の課題をこなすのは諦めるべきか?」という考えが頭をよぎりました。
ただ、よく読むと、「エクソクラフトで」としか書かれておらず、「ミノタウロスで」とは書いてありません。
ま、どうせ雑な会社だから自分で作らせておいたミノタウロスじゃなくても、エクソクラフトなら何でもいいんだろ、と推察して、実際にホバークラフト型のナントカというエクソクラフトを作って乗って移動するとちゃんと移動距離が計上されたので一安心です。
いや。この場合は文言に忠実だ、というべきでしょうね。訂正します。
さて、そんなこんなで、数日かかったものの(通算24時間以上)、無事すべての課題をこなすことができました。
これで心置きなく元のセーブデータに戻ることができます。
大変学ぶことが多いイベントでした。
ところで、まだどの辺が神ゲーなのか、この段階でも、まだよく見えていません。
元のデータに戻って、さらにプレイを続けたいと思います。
さて、起動してみてまず驚いたのは、音声までも日本語化されていることでした。
大変立派だと思います。
無論、プレイをしているうちに日本語化もかなり雑なことは表示域に収まらない文章や意味不明な「xx動作。停止。」とかいう掛け声ですぐわかりましたが、インストール時で雑なことはよくわかったのでちっとも気になりません。
日本語の入力もできませんがまるで平気です。
とにかく母国語でゲームができることは大変に有り難いです。これだけでも大したもんです。
私がゲームを開始したころ、ちょうど「共同探検#3」という期間限定イベントをやっているようでした。残り1週間とありました。
そこで、共同探検#3に参加してみようと思い、チュートリアルをどの程度進めればいいのか、先達に教わるべくGoogle検索さんに聞いてみました。
すると、このゲームは立派なWikiがあることが分かりました。
どうも家庭用ゲーム機が主体のゲームのようですが、やることは特に変わらないだろうと、さっそくWikiに記述されている先輩諸氏の意見を拝聴すると、大変親切なことに、「目覚め」というシナリオを一通りやっておくと良いようでした。
ただ、かなり充実したWikiの様子でしたので、これは一から十まで全部スポイルされているな、という気がしたので、それ以降はあまり目を通さないようにして早速開始しました。
故障しているものの、なかなかカッコいい宇宙船が私の船のようです。
とにかく環境が悪いのでとっとと修理してこの惑星から逃げ出さなければならないようです。
チュートリアルで指示された通りにあれやこれやで修理の方法や、修理のための素材集めの方法を一通り学びながら進めていくと、所有している宇宙機とは別に、ぼこぼこに壊れた墜落した宇宙機が手に入りました。
これは最初に所有していた宇宙機よりもランクは高いようですが、見てくれがかっこ悪い上に、どう直せばいいんだか手のつけようがないほどの壊れようなので、とりあえずその墜落現場に基地を据えて、放っておくことにしました。
とりあえず、この辺で共同探検#3を開始してみようかと思い、いったんこのセーブデータから離れました。
余談ですが後日、宇宙機を売り払うことができることが分かったので、売り払って懐を温めてくれました。
ところで、基地を設置したことが役に立ちました。
なんでか知りませんが、基地の撤去のために再度訪問したところ、売り払ったはずの同じ宇宙機が再び墜落していたのです。
おお、なんて雑なんだ・・・!
ほんとに雑な会社だ、徹底的に雑なんだ、と念を押してくるこのゲーム会社は本当にすごいと思いました。
早速、再度入手して売り払いました。
このことがあったので、調子に乗って墜落現場を発見したら基地を設置しておくようになりました。4か所くらいでしたでしょうか。
やっぱりそういた現場も二度も三度も同型機が墜落し続けています。
ほんとにインストール時に雑な会社が作ったゲームだとわかっていなかったら、あまりのばかばかしさに幻滅して辞めちゃってたと思います。
あの洗礼は本当に役に立ちました。
でもしばらくして、やっぱりなんだか不正を働いている気分が重くなっちゃって来たので、今ではもうそういった基地は設置していません。
"NVIDIA DLSS cannot be loaded due to outdated driver."ですって。ただし、そのダイアログにはOKボタンしかついておらず、そのOKボタンを押下するとゲーム自体は開始することができました。
グラフィック: nVidia GTX 480, AMD Radeon 7870
チラシの裏です。読む価値はありません。
積みゲーが3ケタを超えて久しく、まだ増える一方の現状に鑑み、いくらか消化しようと試みてみました。
しかし、試みてはみたというものの、数か月かかっても大して手を付けられず、しかも途中で放り出すものばかりという体たらくでげっそりです。
その中から、ある程度やったゲームの所感を記録として残しておこうと思います。
まずTropico5はそれなりに楽しめました。まだDLC版のシナリオに加えて、さらにTropico6が残っていますが当分はおなかがいっぱいで当面は見向きもしないと思います。
思えばTropico4のころはSteamもドル建てだったことを思い出しました。もっと前は日本語版だからか大変お高かったけど、初代Tropicoの日本語版の声優さんの演技がとても素晴らしかったことが思い出されます。そして、その初代のゲーム性のままパーツだけ豪華になっているという稀有な作品(「あの」Kalypso mediaに権利が移り、加えて「あの」スクウェア・エニックスと手を組んで聳え立つ**のような組み合わせが実現してしまったものの、時を経てスクウェア・エニックスがどっか行ってくれて本当にヨカッタ)なのも、長くお付き合いできている理由かもしれません。
The Long Darkは最初は面白かったものの、生活が安定すると、あとはすでに用意されているマップの観光をするくらいしかやることがなくなって終了。自分で縛りを入れたりといった遊び方がいいんでしょうが、3ケタもあるゲームが待っているのにそこまでする価値は見出せませんでした。
ただ、たとえシステム的に絶対に逃れられなくても、どんどん南下していつかはアメリカにたどり着くべく努力をしている「つもり」にさせてくれたり、何かこう、ただその場を死なずに生き残るというだけでなく、観光以外の何か希望が持てる感覚を味わえていたら、ちょっとづつ続けられるゲームになったと思います。
当然、シナリオ?ストーリー?は手つかずのままです。
Fallout4はそれなりに楽しめました。レベル40半ばくらいまでは惰性プレイとなりつつもプレイできました。まだメインシナリオも終えていませんが、いつの日かまた起動するかは未知数です。
また、いくら古いゲームとはいえ、GeForceGTX660で快適なプレイが可能だったのには感心しました。
思えばFallout3のころもSteamもドル建て(年寄はクドい)
Oxygen Not Includeedは最初はものすごく楽しめました。
ただ、だんだん仕組みが分かってくると、やることが単調すぎて、せっかくの複製人間のかわいらしいしぐさをもってしても飽きてしまいました。ロケットはひとつも作りませんでした。とは言え、600時間を超えていたのでもう十分やり切った気もします。
これも自分で縛りを入れればまた楽しみ方も変わってくることと思いますが、やはり3ケタもある積みゲーの前には力及ばず、DLCも買っていません。
Civ6は・・・良くも悪くも、ただの「Civilizationの最新版」でした。
このシリーズはCiv3かCiv4で完成しきっちゃった感をひしひしと感じ、あの頃のワクワク感がまるで感じられなかったので、国王で開始して初回プレイで勝ってしまったので、すぐ削除してしまいました(ついでにHDDの肥やしとなっていたCiv5も削除できてすっきりです)。Tropicoも初代から変わり映えしていないのに割合プレイできたのに対して、なんでCivシリーズはつまらないのか、我ながら謎です。
また、積みゲーではないのですが、無料ゲームのIndustry Idleというゲームにも手を出してみました。放置ゲームの一種らしいのですが、抽象化の度合いが面白く、これはかなりいけます。
1回のプレイが短時間で済むので、今でも数日に数分起動して売り上げの回収だけはしています。
そのほかにもいくつかやっていると思うのですが、パッと思い出せないので、とりあえずこんな程度でメモとします。
こんなチラシの裏を公開して申し訳ございません。
新規購入したHDDの初期不良のチェックやRAIDアレイの再構成が一段落ついたので、 先日故障が発覚したHDD(Seagate Barracuda 3.5, ST3000DM008-2DM166)で遊んでみたいと思います。
とにかくドライブのサイズがそれなりに大きいので、一つのコマンドの結果が返ってくるまでに5時間など当たり前なので、一日一コマンドづつしか入力できないのがもどかしいのですが、まあ折角ですので、これまで何度もやっているとはいえ、訓練を重ねることは悪いことではありません。
今回はまず、不良セクタを何とかしたいと思います。
今回の状況としては、/dev/sddとして接続し、ext4の単体ドライブとしてmkfs.ext4をしなおしたうえでrsyncコマンドで元のRAIDの内容をコピーしてある状況を作りました。
まずは異常セクタの特定から行いたいのですが、前回書いた通り、smartctl -t longテストでは異常なしとか平気で言い放つ始末で手に負えません。
実際には以下のパラメータが48まで上昇しているにもかかわらず、です。
・197 Current_Pending_Sector
・198 Offline_Uncorrectable
そこで、badblocksコマンドを用いて異常セクタを検出したいと思います。
まあ、念のため、再度ブロックサイズを確認します。
1 2 | # tune2fs -l /dev/sdd1|grep -i "block size" Block size: 4096 |
1 2 3 4 | # nohup badblocks -b 4096 -vs -o badblocks.txt /dev/sdd1& tail -f nohup.out Checking blocks 0 to 732566271 100.00% done, 5:23:20 elapsed. (139/0/0 errors) |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 097 093 006 Pre-fail Always - 40328485 3 Spin_Up_Time 0x0003 096 096 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 49566908 9 Power_On_Hours 0x0032 063 063 000 Old_age Always - 32571 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 6 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 262 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0 189 High_Fly_Writes 0x003a 099 099 000 Old_age Always - 1 190 Airflow_Temperature_Cel 0x0022 076 060 045 Old_age Always - 24 (Min/Max 20/26) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 4 193 Load_Cycle_Count 0x0032 073 073 000 Old_age Always - 55928 194 Temperature_Celsius 0x0022 024 040 000 Old_age Always - 24 (0 13 0 0 0) 197 Current_Pending_Sector 0x0012 094 094 000 Old_age Always - 1112 198 Offline_Uncorrectable 0x0010 094 094 000 Old_age Offline - 1112 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 32556h+15m+05.395s 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 25786278431 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 1151768457351 |
1 2 | # 1 Short offline Completed: read failure 90% 32571 - # 2 Extended offline Completed without error 00% 32452 - |
全然教えてくれる気はないようです。
しかし、前回、異常が発生しているにもかかわらずエラーなし(#2です)で正常終了していたのが、read failureで異常終了(#1です)しているのはせめてもの事でした。
異常なしっていう時点でおかしいですもの。
まあ、HDDが異常セクタを教えてくれないとのことですので、それならばbadblocksで検出した139の異常セクタをどうにかすればsmart値はどうなるのかを見ていきたいと思います。
その前に、異常セクタにあるファイルを削除するため、先ほどのbadblocksコマンドで生成された badblocks.txt に記録されているセクタ番号をもとに、debugfsコマンドでセクタ番号から使用されているinode番号を取得して、そのinode番号をもとにファイル名を特定します。
無論、すぐに廃棄する予定のHDDでここまでする必要はないのですが、せっかくの演習ですから壊れても惜しくない大容量HDD(いや、もう壊れているのですが)、有効活用してみたいと思います。
まずは指定したセクタに何らかのデータが記録されているかを調べるには以下です。
セクタ番号が524726232として、icheck <セクタ番号>で調査します。
1 2 3 4 | # debugfs -R "icheck 524726232" /dev/sdd1 debugfs 1.42.9 (28-Dec-2013) Block Inode number 524726232 117966080 |
1 2 3 4 | # debugfs -R "icheck 620236906" /dev/sdd1 debugfs 1.42.9 (28-Dec-2013) Block Inode number 620236906 <block not found> |
1 | # debugfs -R "ncheck 117966080" /dev/sdd1 |
1 2 3 4 5 6 7 8 9 10 11 12 13 | # dd if=/dev/zero of=/dev/sdd1 bs=4096 count=1 seek=524726232 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.00141101 秒、 2.9 MB/秒 # sync # smartctl -a /dev/sdd1 ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE (略) 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8 (略) 197 Current_Pending_Sector 0x0012 094 094 000 Old_age Always - 1104 198 Offline_Uncorrectable 0x0010 094 094 000 Old_age Offline - 1104 (略) |
1 2 3 | 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8 197 Current_Pending_Sector 0x0012 100 094 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 094 000 Old_age Offline - 0 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | # fsck.ext4 -l badblocks.txt /dev/sdd1 e2fsck 1.42.9 (28-Dec-2013) /dev/sdd1: Updating bad block inode. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #18928 (23698, counted=23699). Fix<y>? yes Free blocks count wrong for group #19312 (24543, counted=24544). Fix<y>? yes Free blocks count wrong for group #20416 (24543, counted=24544). Fix<y>? yes Free blocks count wrong for group #22000 (24543, counted=24544). Fix<y>? yes Free blocks count wrong for group #22032 (24542, counted=24544). Fix<y>? yes Free blocks count wrong (63487139, counted=63487145). Fix<y>? yes /dev/sdd1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdd1: 97313/183148544 files (1.5% non-contiguous), 669079127/732566272 blocks |
1 | # smartctl -t long /dev/sdd |
1 2 3 4 5 6 7 8 9 10 11 12 13 | Mar 7 05:57:53 ***** kernel: ata3.00: exception Emask 0x0 SAct 0x100000 SErr 0x0 action 0x0 Mar 7 05:57:53 ***** kernel: ata3.00: irq_stat 0x40000008 Mar 7 05:57:53 ***** kernel: ata3.00: failed command: READ FPDMA QUEUED Mar 7 05:57:53 ***** kernel: ata3.00: cmd 60/00:a0:00:17:46/01:00:45:01:00/40 tag 20 ncq 131072 in#012 res 41/40:00:38:17:46/00:01:45:01:00/00 Emask 0x409 (media error) <f> Mar 7 05:57:53 ***** kernel: ata3.00: status: { DRDY ERR } Mar 7 05:57:53 ***** kernel: ata3.00: error: { UNC } Mar 7 05:57:53 ***** kernel: ata3.00: configured for UDMA/133 Mar 7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=3s Mar 7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 Sense Key : Medium Error [current] [descriptor] Mar 7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 Add. Sense: Unrecovered read error - auto reallocate failed Mar 7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 CDB: Read(16) 88 00 00 00 00 01 45 46 17 00 00 00 01 00 00 00 Mar 7 05:57:53 ***** kernel: blk_update_request: I/O error, dev sdc, sector 5457188664 Mar 7 05:57:53 ***** kernel: ata3: EH complete |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | SMART Error Log Version: 1 ATA Error Count: 109 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 109 occurred at disk power-on lifetime: 32432 hours (1351 days + 8 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 ff ff ff 4f 00 19d+18:25:46.787 READ FPDMA QUEUED 60 00 00 ff ff ff 4f 00 19d+18:25:46.754 READ FPDMA QUEUED 60 00 00 ff ff ff 4f 00 19d+18:25:46.143 READ FPDMA QUEUED 60 00 00 ff ff ff 4f 00 19d+18:25:46.015 READ FPDMA QUEUED 60 00 00 ff ff ff 4f 00 19d+18:25:46.014 READ FPDMA QUEUED |
1 | SMART overall-health self-assessment test result: PASSED |
1 | 1 Extended offline Completed without error 00% 32452 - |
1 2 | mdadm --manage /dev/md0 --fail /dev/sdc1 mdadm --manage /dev/md0 --remove /dev/sdc1 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | # parted /dev/sdc (parted) mklabel gpt (parted) mkpart パーティションの名前? []? SDC1-WD4T ファイルシステムの種類? [ext2]? xfs 開始? 2048s 終了? 5860532223s (parted) set 1 raid on (parted) p モデル: ATA WDC WD40EZRZ-22G (scsi) ディスク /dev/sdc: 4001GB セクタサイズ (論理/物理): 512B/4096B パーティションテーブル: gpt ディスクフラグ: 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 1049kB 3001GB 3001GB SDC1-WD4T raid |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | (parted) mkpart パーティションの名前? []? SDC2-WD4T ファイルシステムの種類? [ext2]? xfs 開始? 3001GB 終了? 100% (parted) p モデル: ATA WDC WD40EZRZ-22G (scsi) ディスク /dev/sdc: 4001GB セクタサイズ (論理/物理): 512B/4096B パーティションテーブル: gpt ディスクフラグ: 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 1049kB 3001GB 3001GB SDC1-WD4T raid 2 3001GB 4001GB 1000GB SDC2-WD4T |
1 | # mdadm --add /dev/md0 /dev/sdc1 |
1 2 | sent 2.80T bytes received 1.69M bytes 139.56M bytes/sec total size is 2.81T speedup is 1.00 |