天気予報がコロコロ変わり、少なくとも数日は周辺の天気が悪いらしい。
浜益の黄金山も登山口まで行ったものの小雨なので諦めました。そして、暑寒別岳の曲がり口で思案したのですが、利尻岳に注力しようと思い稚内に急ぎました。
その時に発表されていた予報は、数日間は晴れ間が見えるかも知れないと期待させるものでした。
朝起きて小雨が降り、雲の切れ間に青空の少し見える状況ですが、今日がピークで悪化に向かい雨の予想もされているようです。
雨具も用意してることだし、ここまで来たのだから渡って歩いてみようかと、意を決したところです。
相変わらず強い風が吹く事もあり、風の音が大きいです。
どうなることか話の種に、利尻島に渡ります。
6月15日 12:00発の新日本海フェリーで、新潟から小樽に移動しますが、自宅の群馬県藤岡市から新潟のフェリー埠頭までの経路をどの様にするのかも思案です。
基本的に高速道路は嫌いなので、一般道を走行することになるでしょう。雨天で夜間だと疲労も重なり時間も掛かりますが、高い料金を払える収入がありませんので仕方ないです。
当初の説明では、無料になると言われていた高速道路ですが、既得権益を手放す筈も無く、未来永劫有料が続くらしいので、応援するのをやめました。
高速道路は、無料なら好きですが、有料なので嫌いです。従って一部の無料区間は利用しています。
新日本海フェリーも船室が更新され、大昔は2等船室と呼ばれていたフラットのカーペット式のエリアがほとんど無くなり、ベッド式のエリアに衣替えされました。
昔から愛用していた大部屋が無くなったのは寂しい限りですが、たまにいる大柄な客の迷惑を考えると時代の変革かなと思います。
それに伴い、安い船室は早くから予約で埋まるらしく、派遣の仕事がいつ迄あるかが流動的だったこともあって、日程の予定が立てられなくて、今回も少し割高なツーリストAになりました。
ツーリストAは、上下のベッド式で、大きく二部屋に別れていて、予約画面でデフォルトになっていた部屋は、そこそこ埋まっていましたが別の部屋はガラ空きでした。当然ですが、空いている部屋の方に予約を入れました。
小樽には朝早くに着きますが、そこから日本海側を北に向かいます。稚内の天気を数日間確認しましたが、こちらが梅雨空でも離れている稚内の天候が特に良いわけではないようで、曇や雨の日が結構目に付きます。
それなら、行きながら目に付き気になっていた暑寒別岳とか黄金山に立寄りながら目指すのもありかな？と思い始めたところです。暑寒ルートと呼ばれる海側からの登りです。
過去には反対側の雨竜湿原から登れればと考えたこともありましたが、名前通りの雨にやられてしまい諦めました。入口では協力金と言うことで通行料が徴収されます。
近くに尾瀬を抱える県民としては一度訪れれば十分かなと思ってしまいました。晴れていたら景色の印象も違っていたのかも知れません。それと季節が枯草の秋だったのも、残念な印象を受けた要因かもしれないですね。
いきあたりばったりで、夜中に移動を始めます。
私は深田久弥の日本百名山とかの趣味は無く、行ってみたいと思う山を思いつきで歩くだけですが、その百名山の北海道内で選定された山では、利尻岳のみ未踏です。
過去にバイクツーリングを楽しんでいた若い頃に、利尻島には渡っていますが、その当時は山に登れそうなら登ろうか程度で執着心もなく、強い風下にたなびく帯状の雲と雨を経験しただけで終わりました。
その後にも一度、子供が小さかった頃に、会社の夏休みに家族と計画したことがありました。会社の夏休みは他社より少し早くお盆の前でしたが、本州東北の梅雨が開けた頃で、北海道は道北に前線が停滞したままで、雨が毎日降り最悪でした。
それ以来、利尻礼文は考えないようにしてきましたが、周囲にいる利尻岳を経験した皆さんが、一度は行ってみるのも良いよとおっしゃるので、少しその気になりました。
残り少ない人生ですから、初夏の気になる山を訪ねてみるのも、変な心残りを作らないためにも必要かと思い立ちました。
第一目標は、利尻岳で、第二目標は礼文島歩きとします。
他にこの時期に登ってみたい山は、トムラウシ山、アポイ岳、雄阿寒岳、雌阿寒岳、羊蹄山、大雪山赤岳、大雪山沼ノ平、富良野岳とか切がないほど並びますが、思い付きで少しだけ歩こうかと思っています。
今週土曜日 6月15日昼の便で、新潟から道北を目指します。今回が最後になるのか、また訪れる機会があるのかは分かりませんが、何れにしても人生の残りは長くないので楽しみたいと思います。
できるだけ写真を公開しようと考えています。最終的には帰宅後の整理になりますが、暫定として公開できればと思ってます。
プライベートの写真 とか ブログ を公開しているこのサーバーですが、家に置かれた小さな機器で公開しています。
当初の設置から考えると、何度か機器は更新されていて、今現在は日本国内向けとして直接販売されなかったピンク色の PogoPlug で稼働しています。
OS の設定も当時最新だった Debian の１つ前の安定版をチョイスしたのですが、システムを入れるルートパーティションに余裕を持たせるような配慮を頭に置かずにセットアップしてしまいました。
あまり稼動状態に目を向けていなくて、Logwatchで毎日メールを受取っていたにもかかわらず、ちゃんと見ていませんでした。
なんとルートパーティションの使用率が 99% を越えていました。いつからこの状態だったのか…
サイズ的には、2GBしか確保していませんでした。今時の割り振りとは思えない小ささです。しかし、サーバーを稼働したままパーティションの再配分なんてできませんので、ピンチです。
コマンド du でどの部分が占めているのかを確認すると、/usr の下に使われているようです。実際には大した量ではないのですが、割合的に大きいです。
メンテナンス操作は、byobu と screen を組合せた端末から、リモート操作している環境です。
場所を移動させたい /usr 以下をガラガラに空いている場所にコピーして、/usr 以下を消去しました。さすがにその時点でbyobuが表示する各種ステータスに異常な表示が見られました。
心配しましたがメンテナンス操作はできているようです。確信はないのですが、byobu が情報の格納に/usr 以下の領域を利用しているようです。
すかさずコピー先を /usr にソフトリンク ln で結びつけると、少しずつ異常なステータス表示は解消して、正常な状態に復帰しました。
さすがにネットに公開して稼働中のサーバーを荒療治でメンテナンスする経験は無いので、ドキドキな経験でしたが無事に対処できて良かったと思います。
/usr をルートディレクトリから排除したことで、使用率が 58% に下がりました。時間がないと思っていても、時々は管理してやらないといけませんね。かなり反省しています。
色々と時間の成約があって、手を掛けてやれなかったデスクトップが有ったんですが、何とか起動しようと試みて、大変な状況になっていたことを知りました。
何で使わなかったかといえば、電源スイッチを押しても反応がなくて電源が入れられなかったことに問題があったのですが、何度もさらには何十回も挑戦すれば入ることもありました。
何としても立ち上げたいと考えた時には、別のPCから俗に言うマジックパケットを発行してネット越しに起動していました。
別に起動した機器からの立上げになり、本当に必要とした時だけの利用でした。
そんな状況では利用しようとの考えもしぼみがちで、当然のこと利用機会が遠ざかっていくことになりました。
起動しないのは電源スイッチの問題だとの認識があったので、時間が自由になっている現在、復旧させて利用しようと考えました。
放置するのがもったいないのは、実はメモリを12GBと贅沢に搭載していて遅いプロセッサながら、内蔵ディスクもRAID構成でそこそこ動く代物でした。
そして最初の対策が筐体を開けて、電源スイッチの繋がるピンをショートしたのですが、CPUの冷却ファンが回り始めて３秒程度で止まってしまいます。この時にはキーボードとマウスは接続しているもののモニタの接続をしていませんでした。
すぐに止まるのはこれが原因かと考えて、VGAコネクタやHDMIコネクタでモニタを接続してみたのですが、ここには関係ないようで変化は見られませんでした。
その後、電源スイッチのピンに単体でオンオフできるスイッチを取付けて操作できるように改善して試すも、同様に３秒程度で止まります。理由がわからないのでBIOSのメモリクリアも試しました。後々これが別の問題を起こしていたかもしれません。
あまり気にしたことがなかったのですが、電源スイッチってオンしっぱなしではなく、短期間にオンで、その後はオフを継続するものなのでしょうか、そんなシーケンスでスイッチを操作すると電源が入って立ち上がるようになりました。
と言ってもBIOS メモリクリアしたのが悪かったようで、日付は2002年頃の状態で色々な設定が飛んでしまったようで、内蔵メモリの不具合を示すランプも点灯したり、色々な問題対処も必要になりました。
考えれば、電源の強制停止には、電源スイッチを５秒間押しっぱなしにするのが定説ですので、電源スイッチは少しのオンで電源が入り少しのオンで電源が停止するのは当たり前ですよね、よくよく考えてみれば当然です。
そうこうしていると起動を示すバナーがモニター上に流れて、GRUBの起動するシステムを選択するメニューが表示されるところまでは進みました。しかし、どれを選択してもカーネルのパニックを表示してすぐに止まります。
起動の始めに [del] キーを連打して BIOS の設定画面を表示して、ディスクの認識する順番を入替えても、 grub rescue > と入力待ちになったり、多少の変化はあるもののどれも正常な起動までは行われませんでした。
仕方無く、レスキュー用のメディアも検討したのですが、新しく OS をインストールしてみることにしました。候補に上げたのが、普段使い慣れている Ubuntu です。 USBブート用の USBメモリを持っていたのですが、そこから読み込んで立ち上げができなかったので、 Ubuntu 18.04 LTD 日本語 Remix をダウンロードして DVD メディアに焼きました。
以前稼働していた頃には、ソフトウェアRAIDの設定で集めたデータも格納されていて、Ububtu の OS も RAID1 で問題なく動作していました。気持ち的には復旧させたいとの願いも心の底にあって、まずは DVDメディアで起動して、モジュールのアップデート、そしてソフトRAIDのmdadmのインストールを行いました。
mdadmが入っただけではRAID設定のディスクを認識できないようで、各モジュールの最新への更新が完了した頃には、元からあった RAIDの構成が勝手に認識されていました。
インストール前に、システムが入るエリアのマウント位置の ‘/’ と ‘/boot’ を RAID1 に設定したのですが、最終的なブートで使用される GRUB のインストールで障害になりました。
興味深いのは、ディスクへのインストーラが RAID定義したファイルをあたかも LVM のような１つのディスクのように認識していて、その中にパーティションを分割するように振る舞うことです。昔ソフトRAIDを使用していた頃の感覚からすると別世界のような感覚です。
たまたま GRUB のインストールには失敗したのですが、そこまでのシステムのインストール状況も気になって、 /dev/md0 として作成し、その中に /dev/md0p1 と /dev/md0p2 がそれぞれ ‘/boot’ と ‘/’ に対応していました。
誤って mount に /dev/md0 を指定したらマウント対象ではないようなエラーが吐き出され失敗しました。
そして、/dev/md0p1 と /dev/md0p2 の mount では、問題なくマウントできたようです。内容も思っていた内容で、確かにパーティション分割されているようです。
ブートの GRUB を修復できるソフトがあるらしく、それは grub-rescue と呼ばれ公開されているようで、インストールをネット公開情報から試みましたが、日本語Remixの環境ではインストール自体ができませんでした。
そこで、単体でメディアから起動して動作する grub-rescue をネットから入手して試しましたが、結果的に自動での修復は無理でした。これは Ubuntu 17.10 だったかな? の中にインストールされている単体動作の専用ツールです。
自動修復は無理でしたが、でもこのツールは解析の履歴が事細かく記録されているようで、http://paste.ubuntu.com/p/…. に残されて後からゆっくりと確認できることです。
他にも、’/boot’ を外出しにして、’/’ を RAID エリアにしても、GRUB のインストールはできるのですが、やはり起動はできないようです。
何日にも及ぶほど時間を掛けたのですが、インストール先に RAIDエリアは利用できないとの結論になりました。
そう言えば、昔々公開サーバーに バッファローのネット共有ディスクを改造して、Debian をインストールして RAID にするのに、最初は普通に入れてから片側を半端な RAID に定義して、そっちに全てをコピーしてから、元のディスクを RAID に追加してリビルドさせて、最終的に RAID になったシステムが完成したような気がします。
最近のインストーラも RAID は想定外なので、正規のシステムが立ち上がる前に利用される一時的なシステムに、RAIDを認識できる部分が組み込まれていないのだろうと思います。
したがって最初は単純にインストールして、徐々にカスタマイズしないと RAID の組込みはできないということのようです。
仕切り直して、単純に Ubuntu 18.04 LTS 日本語Remix を入れるところから始めました。時間がかかったけど想定した位置に入れ込むことができました。
/dev/sda1 — ‘/boot’
/dev/sda3 — ‘/’
これも簡単ではなく、苦労したのは既に作成されているパーティション分割に合わせてマウントポイントを指定するのですが、モニタに利用したテレビ画面から作業を選択するボタンが表示枠の範囲外になってしまい、スクロールもできず選択不能です。
タブキーとエンターキーを画面の想像で操作するのですが、何度も取り消されてしまい、振り出しに戻されての繰り返しで、先に進む方法に辿り着けません。
やっとインストールされた初期の状態で立ち上がりました。その後のパッチ類を全て適用して、やっとスタート台に立った状態です。
その後、ソフトRAID の mdadm、ソフト検索のため aptitude 、エディタとして vim、リモートログインに openssh-server をインストールしました。
元々のデータが収まっていた 500GB 程度の RAID1 の内容を確認すると ‘/home’ の内容のようなのを確認できたので、 /etc/fstab ファイルを修正して ‘/home’ にマウントされるように定義して、reboot で正しくマウントされて立ち上がるのを確認しました。
しばらく放置したPCを復旧させるって難題ですね。以前はルートのシステム部分もRAID1で構成されていたので、その状態に戻したくて四苦八苦して悪あがきをしたのですが、結果は惨敗でした。記憶では、RAID1を片肺にしてコピーしてから /etc/fstab や /boot/grub/grub.cfg を書き換えて片肺の RAID1 をシステムに無理やり組込んでいたように覚えてます。
最近の作法としては、grub.cfg は update-grub のようなツールで生成されるもののようで、強制的に書き換えて機能するものなのかも理解していません。生成されている grub.cfg を見ると該当するディスクは基本的に UUID で指定されているようで、これをどのように引っ張ってきたのかも理解できていません。
何かの定義を変更すると立ち上げ対象のディスクが置き換えられるのかと思い、あちこち調べたのですが思い当たるものには到達できませんでした。強制的に grub.cfg を書き換えて仮に立ち上げてから RAID1 を正常に整備してから update-grub を実行して RAID1 にシステムを入れた状態で、正常に立上がるのかは検証できていません。
強制的に grub.cfg を書き換えて立上がるものなのかもわかっていません。時間を作って試してみたいと思います。
復旧しようと考えた PC のマザーボードですが、新しいものではなく、かと言ってディスクに IDE インターフェースでマスターとスレーブの４台が組み込まれるほどの古さでもない微妙な物です。 プロセッサは、’AMD Athlon(tm) II X4 605e Processor’ で、 DD3 メモリが、12GB 搭載されているので再利用できれば程度の考えです。
ただ、IDE のコネクタも１つあり、当時はSATAインターフェースの CD-ROM がなくて、そのためのコネクタだったような気がします。
SATS1 / SATA2 / SATA3 / IDE / SATA5 / SATA6 と続きます。昔の IDE 接続だった頃のディスクの場合、セカンダリーのスレーブに CD-ROM を繋いでいた名残にも見えます。
昔のシステムは単純で、ディスクの装着位置で順番が決まっていたので、UUID でディスクを特定する必要がなかったのでしょうね、今復旧している PC も立上がるタイミングや BIOS の定義で順番がコロコロと置き換わるようです。
さすがに動作しながら順番が異なることはなさそうな気もしますが、でも USB-HDD を挿入したタイミングで処理中だった物が、対象機器を見失ったような混乱で、障害で停止したのかと思う動きもあって気になりました。
筐体もパワースイッチが入らなくなるような状況で、整形されたプラスチック類も加水分解状態の物も目に付くような状況から検討することにしました。マザーボードは、サイズが少し大きめで ATX 、電源は昔ではちょっと大きめな高速なプロセッサに対応した容量の物でした。そのまま再利用できそうなので筐体だけ入れ替えようと探しました。
筐体の価格も高価なものから低価格な庶民的なものまでピンキリのようで、フルの ATX なので小型のものは望めませんでしたが、Amazon で手頃な中国製を購入しました。ちょっと派手で、片側が透明なプラスチックのミドルタワー型です。製品名は、 ‘Thermaltake Versa H26 Black/w casefan’ とかで、送料サービスで 4,163円でした。
久し振りに自作用の筐体を入手しましたが、価格の割に良くできていてファンも ２個装着済で、コネクタをマザーボードに挿すだけでした。その前に使っていた古い筐体にもファンは取付けられていましたが、ディスク等に供給する電源コネクターに接続するようになっていて、結局使わないままでした。
購入した筐体は派手な作りのようで、筐体正面のファンにはブルーのLEDが付けられていて、筐体自体も風通しが良くなるメッシュが随所に組み込まれていて、埃除去のフィルターも簡単に取り外しできる構造です。
筐体の片面が透明なプラスチックで中がスケスケなため、夜になるとギンギラギンでまばゆい状態です。派手過ぎてちょっと自分の好みではないけど、価格が安いですのでこれもオーケーでしょう。
配線も裏にまとめやすく作られていて、見える透明なプラスチック側は綺麗に見せられるように、裏からの配線が近くから表側に導き出せるよう随所に穴が作られています。
筐体前面の電源スイッチの並びには、マイクやスピーカー等のオーディオ系コネクタやUSB2.0✕2 や USB3.0✕2 のコネクタもあり、USB2.0✕2 とオーディオ系は、そのままマザーボード上のコネクタに挿入できましたが、USB3.0✕2 には挿入できる機能がありません。
使えないコネクタが前面にあるのもちょっと気になるため、乗りかかった船なので、増設用ボードの手配もしました。ただ、Amazon経由で台湾のメーカーらしく、船便でゆっくり届くと思われます。
しばらく後になっての取付けですが、安いのでこれもありかと思います。
廃棄した古い筐体の方には、2.5インチで 1TBのディスクが ２台あり、これが RAID1 の構成に利用されていましたが、何故か 3.5インチベイの片側に寄せた形でネジ止めされていました。組んだ時が昔なのですっかり記憶から抜けています。
他に 2.5インチのディスクを ２台づつ装着でき、外から簡単に挿入したり、抜き出したりできるケースがあるにも関わらず、使わずに単体で 3.5インチベイにネジ止めしていたので不思議に思っていたのですが、取り付けようとして理由がわかりました。
ディスクの厚さが 13mmあって、9.5mm厚に対応しているケースには入れられなかったようです。当時は 1TBクラスの 2.5インチディスクは厚くないと製造できなかったようです。
とりあえず新しく購入した筐体にも、電源の置かれた最下部の前側には、ペラペラのプラスチックのトレイに入れて SSD やディスクの設置が可能です。
最近は価格も下がり普及してきた SSD を入れるために考えられたと思われる場所です。
そこに厚さが 13mm の 2.5インチのシステムディスクを ２台とりあえず入れることにしました。
穴位置のサイズが公表されて無く、写真から 13mm 厚の2.5インチのディスク２台を収納できるようにも見える 3.5インチ用のマウンターも購入しました。
本当に厚い２台装着できるのかは心配です。賭けですね、無駄な買い物になってしまうかもしれません。
デスクトップとしてインストールしていますが、リモートからの電源オンオフも含めて、リモート操作を想定したサーバーとしての利用なので、これからのカスタマイズも含めてまだまだ楽しめそうです。
Volumio2 を私がいる２階の部屋でのバックグラウンド・ミュージックのサーバーとして稼働させています。特に問題もなく安定しているので、１階の居間でも同様に稼働させようと思い立ちました。
もともと１年以上の間、追加で置こうとしている１階には、安定稼働の様子見のため古いバージョンでしたが、電源を入れたままで動作させていました。そのため里帰り的な事なので何の問題もないと思っていて、時間を無駄にする痛い目にも合いました。
２台を識別するために、システム名を標準の Volumio の名称をそのまま残しておき、後に ‘-1F’ と ‘-2F’ を付加した名称にしました。１台の稼働のときは想像できなかったことですが、ブラウザからコントロールする時に、１つの接続からどちらをコントロールするのか選択して操作できることです。
一般的な操作や設定だけなら、ブラウザで接続した状態からIPアドレスの設定や無線LANの設定、ボリュームアップダウンの刻み幅、DACの設定、電源オフ、再起動等ほとんどの操作ができます。
ブラウザでの操作だけなら、マウスやキーボード、モニタとなるテレビも不要です。とは言っても、自動で振られたIPアドレスが何になっているのかとか、確認したい場合もありますし、既に設定してあるデータを新しく立ち上げた側にコピーしたいこともあるでしょう。
リモートでログインしてコマンドで操作する ssh ですが、有効にすると利用できるようになります。方法は、ブラウザで操作する接続先のアドレスの後に /DEV/ を指定すると設定する項目が表示されます。ここで ssh を有効にするための項目の [ENABLE] ボタンをクリックします。
コマンドで操作したいこともあると思います。最悪はローカルで直接ログインする方法ですが、機材を持込むか逆に機材のある場所に本体を持ってこないといけないので、ぜひとも ssh を有効にしておくことを勧めます。
本体にモニタ、マウスとキーボードを取付けて、ユーザー名: volumio と パスワード: volumio が初期値ですが、それでログインすれば操作できます。重要な注意点としては、パスワードを変更する時に記号を含めると、キーボードの配置が想定と異なっていてログインできなくなる事があることです。これにはマジでハマります。
Volumio の操作画面ですが、スマートフォンで操作する縦型で小さな画面と、パソコンで一般的な横に広い大きな画面で、配置される項目に大きな違いがあるようです。
パソコンでもブラウザの横を縮めて小さくするとスマートフォンの表示と同じような配置になります。帯状のボタンが横一列に並び、左が一覧表示、真ん中がプレイバック、右がキューとなっているようです。そのボタンは、スマートフォンのように小さな画面では最上部に、大きな画面では最下段に表示されています。
３つの選択ボタンの真ん中のプレイバックが、イニシャルのデフォルト画面のようです。この状態の時にアーティストや曲名を表示していて、ウェブラジオならその下に放送局名が表示されているようです。また、mp3のような楽曲のデジタルデータでも登録されていれば同様に情報が表示されます。
プレイバックが選択されている時に、複数台の Volumio が稼働している場合に、どの Volumio を操作するのかの選択ができるようです。
スクロールすると下にMultiroom Devices の項目内にリストされています。
小さな画面は縦に、大きな画面は横に並んでいるようです。
左の一覧表示には、先端をホームとして色々な選択できる項目を表示し、そこから選ぶことができるようです。項目としては、|お好み|プレイリスト|音楽ライブラリ|アーティスト|アルバム|ジャンル|Media Servers|last 100|ウェブラジオ| とありますが、使い方がよく分かりません。
ウェブラジオでは、Volumio の推奨の局やジャンル別、国別等とラジオ局を選べる項目がリストになっています。希望する局をクリックすると、右のキューの項目に転送されて受信が始まり、演奏が流れ出します。クリックする度にキューに蓄積して受信を開始します。ただし、局リストにあっても受信できない局もあるようで、その場合はエラーになります。
プレイリストでは、自分で付けたグループ名で登録した項目が、一覧表示されています。いつも利用したい放送局をジャンル別や、利用頻度の多い局を集めたグループ等でまとめて登録しておくと、毎回ウェブラジオから選び出す必要が無くなります。
なお、プレイリストへの登録方法は、選択された結果の右のキューにリストされた項目をグループ名を付与して一括で登録することができます。
音楽ライブラリは、Volumio に登録した外部の共有ネットサーバー等のエリアを参照して楽曲を選択できるようにする項目のようです。
last 100 は、演奏した楽曲や選択した局がリストされているような気がしますが、どのタイミンクで取り込まれているのかよく分かりません。
その他の項目は、今ひとつ利用方法が分かりませんが、音楽ライブラリから楽曲を選択すると、その後にその楽曲内にあった情報として、アーティスト、アルバム、ジャンルが対応するリストになっているようです。どのタイミングで取り込まれているのか不明です。
右のキューには、左の一覧表示から選曲した楽曲や、選択したウェブラジオ局が、その都度リストの最後に追加される仕組みのようです。複数回の繰り返しを行うと繰り返した分だけリストに追加されるようです。
ここにリストされた楽曲の場合は、該当の演奏が終わると次の楽曲に移りますが、ウェブラジオの選局では、別の局に変更されるまで受信が続きます。ここにリストされているウェブラジオ局は、クリックして別の局への受信切替が可能です。
ここにリストされている楽曲やウェブラジオ局は、各項目の右にある(x)で個々に消去することも、ゴミバケツマークのクリックでまとめて全て消去することも可能です。操作性が難しく上手く整理できないかもしれませんが、上下の入替えのような単純な編集が可能です。
キュー上にリストされた楽曲やウェブラジオ局は、フロッピーマークのクリックで、グループ名を付与して一括でプレイリストを新規作成することができます。ただし、注意点は新規名を付与しないで既存の名前を選択すると、以前に何が登録されていたのかに関係なく、現在のキューにリストされていたものと置き換えられます。言い換えれば強制的な更新となります。
作成されたプレイリストのデータについては、労力が費やされているので障害での消去も考えてバックアップするなり、別の Volumio にコピーして再利用するなりしたいと思います。
その方法としては、 ssh 等によるリモートログインでコマンド操作を行い、/data/playlist/ の下に置かれたデータを扱います。コマンドとしては、rcp 等でコピーすれば良いと思います。
次に、普段使いのLinux PC で、自分のホームに取り込んだ１つの例を示します。
:~$ mkdir ~/volumio-playlist :~$ rcp volumio@192.168.11.18:/data/playlist/* ~/volumio-playlist/ volumio@192.168.11.18's password: -普段のバック曲 100% 3242 420.1KB/s 00:00 Guitar & piano 100% 1257 594.4KB/s 00:00 Jazz 100% 2166 695.2KB/s 00:00 Relax & Easy listening 100% 1124 555.5KB/s 00:00 Retro 50s-80s & Beatles 100% 3978 929.0KB/s 00:00 Solo 100% 713 387.4KB/s 00:00 シンフォニー&クラッシック 100% 3196 585.1KB/s 00:00 ダンス系・スイング&タンゴ 100% 3490 843.0KB/s 00:00 ボサノバ & シャンソン 100% 1887 376.8KB/s 00:00 日本歌謡・アイドル他 100% 2451 431.7KB/s 00:00 映画 100% 2234 766.9KB/s 00:00 :~$ ls ~/volumio-playlist/ -普段のバック曲 'Retro 50s-80s & Beatles' 'ボサノバ & シャンソン' 'Guitar & piano' Solo 映画 Jazz 'シンフォニー&クラッシック' 日本歌謡・アイドル他 'Relax & Easy listening' 'ダンス系・スイング&タンゴ'
プレイリストのデータは、キューから作成されたグループ毎に １ファイルとして作られています。それと、キューにリストされた項目が１行ずつではなくて、グループ全体が １行になっているようです。
１ファイルで １行ですが、一応テキストエディタで編集は可能だろうと思います。ただ、実用的とは思えません。例として Jazz の内容を次に示します。
:~$ cat ~/volumio-playlist/Jazz
[{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1723864","title":"Smooth Jazz Florida","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1625448","title":"SmoothJazz.com Global","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1292701","title":"Jazz Lounge","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=959067","title":"The UK 1940s Radio Station 1920s 1930s 1940s","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1469526","title":"The Great American Songbook","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1151057","title":"Smooth Jazz - Tampa Bay","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1423641","title":"Deep Pockets Jazz","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1441882","title":"Swing Street Radio","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1638696","title":"1000 HITS Jazz","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=559409","title":"Jazz International","albumart":"/albumart"},{"service":"webradio","uri":"http://yp.shoutcast.com/sbin/tunein-station.m3u?id=1733465","title":"Smooth Sounds Radio","albumart":"/albumart"},{"service":"webradio","uri":"http://89.16.185.174:8000/stream","title":"Linn Jazz","albumart":"https://radio-directory.firebaseapp.com/volumio/src/images/radio-thumbnails/Linn Jazz.jpg"},{"service":"webradio","uri":"http://icy1.abacast.com:80/kplu-jazz24aac-64","title":"Jazz24","albumart":"https://radio-directory.firebaseapp.com/volumio/src/images/radio-thumbnails/Jazz24.jpg"},{"service":"webradio","uri":"http://8.38.78.173:8210","title":"Audiophile Jazz","albumart":"https://radio-directory.firebaseapp.com/volumio/src/images/radio-thumbnails/Audiophile Jazz.jpg"}]
Volumio の複製なんて簡単に設置できると思っていたら、意外に時間を取られて無駄な時間を使っていました。原因は、昨年の暮れになって家の中をリフォームしていたのと、光回線のキャリアの変更とか色々重なり、以前設置していた場所が家のネットワークやインターネットから切り離されていたのでした。
でもなかなかわからなかったのは、運悪く切り離された場所にもルータが置かれていて、イーサネットの接続ランプはリンクアップしているように時々点滅していたことです。思い込みは直さないと失敗の元です。
情けない!! アホなことをしてしまいました。
昨年は厚真の大地震が発生した頃から長期滞在していたキャンプ場である旭川市21世紀の森 運営協議会からの便りが届きました。
過去にも新しく作られたパンフレットとか受取った事はありました。外側の封筒は過去に受取った物と似たイメージでしたが、中に入っていた物が少し異なりました。
雪の中にあるキャンプ場のカラー写真を配置した冬景色の1ページの1枚と、ふるさと納税を説明している両面印刷の1枚が入っていました。
あさひかわ応援寄附金（ふるさと納税）とタイトルが付けられています。
実は昨年アンケートを渡されていて、キャンプ場も有料に切替える検討が行われている事を知っていました。そのため、その事を伝える内容かと思って封を切りました。
今回はどこにもその事には触れていないので、まだ保留になっているのでしょうか。キャンプ場の有料/無料にかかわらずふるさとのフレーズには弱いです。
何しろ夏から秋にかけては、毎年のように何度も長期滞在して、居住地のような生活を送っていた身としては、多少の寄付では恩恵を賄いきれないです。
とは言っても年金生活者で、働きも少なく、寄付による減税の効果も期待できないので、気持ちだけの金額でご勘弁願いましょうか。
太っ腹な旭川市には本当にお世話になりっぱなしです。キャンプ場、森の湯、旭山動物園、科学館サイパルと、いつも有難う御座います。
設置時からずっと気になるのは、セキュリティーホールを探るアタックが多いことです。
ポート22を攻めるSSHは、ごく一般的な基本の攻撃なので驚きはしませんが、ここで公開しているこのブログは標準でDBを使用するので、更新したり セットアップしたりする操作が想定できるセキュリティホール全ての事を、端から試すアタックを受け続けています。
暫く長期で旅行の予定は無いので、家の外からの操作もなく、あまりにウザいアタックなので、ポート22を無効にしています。更に、写真の公開については、特に外部からの情報を受け付けない仕様なので問題外です。
問題はこのブログへのアタックです。毎日のLogwatchのレポートに多数のエラー404が記録されていて、同じIPアドレスから呆れるくらいの数の悪意な接続がリストされています。
どのような内容かと言うと、セットアップしたり初期化する時に、予め使用が考えられそうな操作やコマンドが全て試されているような状況です。
毎日作成されるレポートには、ログから概要がリストされていますが、IPアドレス単位で回数のカウントまでをまとめたレポートまではありません。そこでアクセスログから集計してみました。
毎日ではウザいので、1週間単位に集計して、テキスト形式で共有サーバーのフォルダに自動蓄積するようにしました。そこから転記して覚書として、ここにまとめてみようかと思います。
回数 : アドレス
108 : 18.220.66.54 ec2-18-220-66-54.us-east-2.compute.amazonaws.com. アメリカ
410 : 59.36.169.180 180.169.36.59.broad.dg.gd.dynamic.163data.com.cn. 中国 450 : 61.160.215.38 逆引き 登録なし 中国
108 : 66.24.164.33 cpe-66-24-164-33.stny.res.rr.com. アメリカ
436 : 79.8.64.93 host93-64-static.8-79-b.business.telecomitalia.it. イタリア
108 : 79.120.133.202 逆引き 登録なし ハンガリー
108 : 83.28.183.131 bkp131.neoplus.adsl.tpnet.pl. ポーランド
437 : 94.191.10.62 逆引き 登録なし 中国
436 : 94.191.71.240 逆引き 登録なし 中国
227 : 103.27.61.244 逆引き 登録なし ベトナム
450 : 103.123.161.50 逆引き 登録なし 中国 108 : 104.34.26.102 cpe-104-34-161-50.socal.res.rr.com. アメリカ
420 : 114.116.94.28 ecs-114-116-94-28.compute.hwclouds-dns.com. 中国
410 : 116.193.155.7 逆引き タイムアウト 中国 436 : 118.89.57.149 逆引き 登録なし 中国
431 : 122.114.186.8 逆引き 登録なし 中国
396 : 122.114.240.241 逆引き 登録なし 中国 410 : 123.207.237.141 逆引き 登録なし 中国
467 : 124.156.167.231 逆引き 登録なし シンガポール
478 : 125.27.179.27 node-zdn.pool-125-27.dynamic.totbroadband.com. タイ 436 : 132.232.44.27 逆引き 登録なし 中国
465 : 132.232.200.165 逆引き 登録なし 中国
416 : 132.232.211.14 逆引き 登録なし 中国 408 : 134.175.30.72 逆引き 登録なし 中国 409 : 139.199.23.198 逆引き 登録なし 中国 405 : 139.199.125.47 逆引き 登録なし 中国
397 : 146.71.56.226 逆引き 登録なし アメリカ
436 : 148.70.130.190 逆引き 登録なし 中国
449 : 159.192.220.60 逆引き 登録なし タイ
418 : 160.19.49.95 逆引き 登録なし 香港 108 : 182.164.172.192 182-164-172-192f1.shg1.eonet.ne.jp. 日本
416 : 188.131.128.163 逆引き 登録なし 中国 396 : 188.131.181.62 逆引き 登録なし 中国
450 : 188.131.204.15 逆引き 登録なし 中国
108 : 188.192.161.111 ipbcc0a16f.dynamic.kabel-deutschland.de. ドイツ
228 : 192.185.82.119 xenon.websitewelcome.com.
108 : 196.201.197.69 逆引き 登録なし ジブチ
450 : 201.117.251.50 customer-201-117-251-50.uninet-ide.com.mx. メキシコ
420 : 210.89.52.233 Sublime-52-233.pacenet-india.com. インド
437 : 218.161.75.200 218-161-75-200.HINET-IP.hinet.net. 台湾
381 : 220.135.141.52 220-135-141-52.HINET-IP.hinet.net. 台湾
114 : 220.146.236.244 nttkyo699244.tkyo.nt.ngn.ppp.infoweb.ne.jp. 日本
397 : 222.179.152.117 逆引き 登録なし 中国
478 : 222.186.136.116 逆引き 登録なし 中国
450 : 222.192.60.40 逆引き 登録なし 中国
200 : 222.255.46.171 static.vnpt.vn. ベトナム
205 : 2a02:4780:bad:3:fced:1ff:fe03:166 逆引き 登録なし LT:Lithuania
アタックするIPアドレスは、まんべんなく分散しているようです。間隔の狭いアクセスは、１秒に10回程度の機械的な接続を試みています。普通に人が操作しても数秒も掛かる操作を連打されている感じでしょうか。
元々が普通に遅いサーバーなので、処理能力の50倍や100倍の強制操作となっていて、レスポンスに時間がかかるのは当然のようです。
アメリカの amazon aws とかありますけど、クラウドの貸出サーバーでしょうか、アタックするために借りているのかなぁ…、汚染された結果なのか、脆弱な放置システムの検索のために公務で利用しているとか????
日本国内からもアタックがありました。正規に逆引き登録もされているシステムから、回数は 100回程度で少ないのですが記録されています。
リスト更新日 : 2019-04-19
一般的な検査と修復に利用する fsck コマンドがありますが、その利用で badblocks の機能を伴って、不良セクタをリカバリする機能があることを知りました。
その機能の学習を兼ねて、不良ディスクとして保留していたハードディスクを使って実行してみました。
$ sudo fsck -vcck /dev/sdb2
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done
system: Updating bad block inode.
Pass 1: Checking iノードs, blocks, and sizes
Pass 2: Checking ディレクトリ structure
Pass 3: Checking ディレクトリ connectivity
Pass 4: Checking reference counts
Pass 5: Checking グループ summary information
system: ***** ファイルシステムは変更されました *****
11 inodes used (0.00%, out of 2621440)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 3
242382 blocks used (2.31%, out of 10485760)
0 bad blocks
1 large file
0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
2 files
前述が実行結果です。
時間は長く掛かりましたが、以前頻繁にエラーを吐き出していたパーティション位置に対して非破壊型の読み書きテストだとのことです。
このパーティションは、mkfs.ext4 で１度ファイルを生成したのですが、気になるメッセージが最終行にあって、再び mkfs.ext4 で書き直した直後に、前述の fsck を実行しています。
途中に『system: ファイルシステムは変更されました 』の文脈がありますが、不良箇所があって一部が変更されたということでしょうか。初めての実行なので詳細が分かりません。
次にパーティションをファイルに生成した時の１度目と、気になって再実行した２度目のメッセージについて次に示します。
$ sudo mkfs.ext4 -L system /dev/sdb2
mke2fs 1.44.1 (24-Mar-2018)
Creating filesystem with 10485760 4k blocks and 2621440 inodes
Filesystem UUID: 3cf7fb03-0d7d-491b-8d6b-8265e2798161
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624
Allocating group tables: done
Writing inode tables: done
Creating journal (65536 blocks): done
Writing superblocks and filesystem accounting information:
Warning, had trouble writing out superblocks.
$ sudo mkfs.ext4 -L system /dev/sdb2
mke2fs 1.44.1 (24-Mar-2018)
Creating filesystem with 10485760 4k blocks and 2621440 inodes
Filesystem UUID: 789bf9e8-5e1d-4dbc-ae81-a8d25a02529b
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624
Allocating group tables: done
Writing inode tables: done
Creating journal (65536 blocks): done
Writing superblocks and filesystem accounting information: done
元々不良ディスクとして、使わずに置かれていたディスクなので、多少なりとも利用できれば学習も兼ねて儲けものかもしれません。
数年前にラズパイに搭載していたハードディスクがありました。ラズパイ発売当初の頃、今となってはかなり昔の話になります。ラズパイの使い方は今も変わらないと思いますが、SD あるいは micro SD にシステムを入れて立ち上げ利用します。
その当時、たまたま手持ちの SD 類が低品質だったのか、ラズパイとの相性の問題なのかは今でも納得できないでいますが、使い始めてこれからと思う所まで作業を進めた頃に必ずシステムが飛んでしまい、操作や定義した内容が成果として残らないことが多々ありました。
そのようなこともあり、ラズパイの初期利用の頃からOSの raspbian を最初のboot パーティションを除きハードディスクのパーティションに移して運用していました。それ以降はずっと安定してラズパイを利用していたのですが、ある時１台のラズパイが不安定になり、原因がラズパイのハード本体か、ハードディスクか、SD のブートなのかと疑い、多分ハードディスクだろうとの結論になりました。
当時ハードディスクの確認方法に、どのようなものがあるのか、調べたものの時間もなく『不良』と張り紙して捨てずに残しておきました。
そのハードディスクを見付けて、そう言えば保留で放置していたなと思い出して、調べてみることにしました。
$ sudo fdisk /dev/sdb fdisk (util-linux 2.31.1) へようこそ。 ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。 書き込みコマンドを使用する際は、注意して実行してください。 コマンド (m でヘルプ): p ディスク /dev/sdb: 931.5 GiB, 1000204886016 バイト, 1953525168 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト I/O サイズ (最小 / 推奨): 4096 バイト / 33553920 バイト ディスクラベルのタイプ: dos ディスク識別子: 0xab9fb81c デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ /dev/sdb1 2048 2099199 2097152 1G b W95 FAT32 /dev/sdb2 2099200 44042239 41943040 20G 83 Linux /dev/sdb3 44042240 48236543 4194304 2G 82 Linux スワップ / Solaris /dev/sdb4 48236544 1953525167 1905288624 908.5G 5 拡張領域 /dev/sdb5 48238592 635441151 587202560 280G 83 Linux /dev/sdb6 635443200 1222645759 587202560 280G 83 Linux /dev/sdb7 1222647808 1953525167 730877360 348.5G 83 Linux コマンド (m でヘルプ): q
$ sudo blkid
--
途中省略
--
/dev/sdb1: UUID="7C91-A3DA" TYPE="vfat" PARTUUID="ab9fb81c-01"
/dev/sdb2: UUID="83670319-849c-459b-84aa-fe7f3f776145" TYPE="ext4" PARTUUID="ab9fb81c-02"
/dev/sdb3: UUID="c3a4d72a-7866-4ffe-a864-5a3f24fb889f" TYPE="swap" PARTUUID="ab9fb81c-03"
/dev/sdb5: LABEL="home" UUID="35786e95-ea9a-4975-aa39-c10ba1d47e3f" TYPE="ext4" PARTUUID="ab9fb81c-05"
/dev/sdb6: LABEL="data" UUID="217555fc-a5d3-4cd8-9702-06f1b5c77f6d" TYPE="ext4" PARTUUID="ab9fb81c-06"
/dev/sdb7: LABEL="bkup" UUID="8aec4e2f-e576-4b73-9aa1-38b905c68dc1" TYPE="ext4" PARTUUID="ab9fb81c-07"
$ sudo fsck /dev/sdb1
fsck from util-linux 2.31.1
fsck.fat 4.1 (2017-01-24)
/dev/sdb1: 0 files, 1/261629 clusters
$ sudo fsck /dev/sdb2
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/sdb2: clean, 15/1310720 files, 285254/5242880 blocks
$ sudo fsck /dev/sdb5
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
home: clean, 953/18350080 files, 1202987/73400320 blocks
$ sudo fsck /dev/sdb6
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
data: clean, 703/18350080 files, 1345817/73400320 blocks
$ sudo fsck /dev/sdb7
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
bkup: clean, 11/22847488 files, 1483745/91359670 blocks
前述のように、一般的なパラメータ無しで fsck コマンドを実行しても何のエラーも表示されません。しかし、システムを稼働させるとシステムダウンを起こすほどの不安定な動きをします。
昔は、色々な物が手作りのようで、低レベルフォーマットの話も聞いたことがありますが、時代は変わり、現在は一般利用者が利用できるレベルでもないようです。調べるとディスクドライブ全域にスペースを書き込む方法については見つかりました。
昔の記事の中には、使えるものがメーカーで異なっていたとか、ガードが掛からずスーパーブロックまで消去されてしまい大問題になったらしいた記事等もありました。
なお、Linux システムで、 /dev/sdb ドライブに ‘０’ を充填するコマンドは次のコマンドです。
# dd if=/dev/zero of=/dev/sdb bs=1M
ディスクの修復等をキーワードで検索すると、『Linuxでディスクのエラーや不良セクタのチェックと修正をする方法』を見付けました。
その記事では、 fdisk えふでぃすく | hdparm えいちでぃーぱーむ | badblocks ばっどぶろっくす | e2fsck いーつーえふえすしーけー | fsck えふえすしーけー について記述されていました。
私が使ったことのない初めて知るようなコマンドも説明してくれています。 hdparm は昔何かの講習会で聞いたような気もしますが、すでに記憶からは飛んでいました。
その中で、ハードディスクのモデルを表示するコマンドを見付けましたが、試してみると残念ながら再現しませんでした。コマンドが変わったのか、ディスクの情報の持たせ方が変わったのか、詳細は分かりませんが時代の変化なのかもしれません。
$ sudo hdparm -i /dev/sdb1 |fgrep Model Model=Hitachi HDS5C3020ALA632, FwRev=ML6OA5C0, SerialNo=ZZZZZZZZZZZZZZ
前述が説明のサンプルですが、実際の結果が次になります。
$ sudo hdparm -i /dev/sdb |fgrep Model HDIO_GET_IDENTITY failed: Invalid argument
hdparm のオプションを -I に変えて実行すると、色々な情報が表示されるので、何かが変わったのでしょうね。
$ sudo hdparm -I /dev/sdb
/dev/sdb:
ATA device, with non-removable media
Model Number: ST1000LM024 HN-M101MBB
Serial Number: S30EJ9GF304434
Firmware Revision: 2BA30001
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0028)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 16384 KBytes
Form Factor: 2.5 inch
Nominal Media Rotation Rate: 5400
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: disabled
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
Advanced Power Management feature set
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
Automatic Acoustic Management feature set
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
* Idle-Unload when NCQ is active
* NCQ priority information
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Read/Write Long (AC1), obsolete
* SCT Write Same (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
194min for SECURITY ERASE UNIT. 194min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50004cf20ca73d80
NAA : 5
IEEE OUI : 0004cf
Unique ID : 20ca73d80
Checksum: correct
説明されていた hdparm のパラメータを変更した結果が次です。
$ sudo hdparm -I /dev/sdb |fgrep Model
Model Number: ST1000LM024 HN-M101MBB
不良セクタを調べる方法も説明されていて、せっかくなのでそれを試してみました。不良箇所が多くて時間がかかったのか、1TB 2.5インチディスクの実行に丸１日以上かかりました。212箇所の不良ブロックでした。
$ sudo badblocks -v -s /dev/sdb | tee /tmp/badblocks.txt
Checking blocks 0 to 976762583
Checking for bad blocks (read-only test): 6154392 done, 6:03 elapsed. (0/0/0 errors)
6154393 done, 6:37 elapsed. (1/0/0 errors)
6154394 done, 7:12 elapsed. (2/0/0 errors)
6154395 done, 7:45 elapsed. (3/0/0 errors)
6250116 done, 8:59 elapsed. (4/0/0 errors)
6250117 done, 9:34 elapsed. (5/0/0 errors)
6250118 done, 10:08 elapsed. (6/0/0 errors)
--
途中省略
--
329269885one, 6:23:07 elapsed. (205/0/0 errors)
329269886one, 6:23:42 elapsed. (206/0/0 errors)
329269887one, 6:24:17 elapsed. (207/0/0 errors)
329370036one, 6:25:04 elapsed. (208/0/0 errors)
329370037one, 6:25:38 elapsed. (209/0/0 errors)
329370038one, 6:26:12 elapsed. (210/0/0 errors)
329370039one, 6:26:46 elapsed. (211/0/0 errors)
done
Pass completed, 212 bad blocks found. (212/0/0 errors)
前述の方法で収集した情報を利用して、不良セクタをマークするとのこと試してみます。ただ良く理解できていないのは、説明されている例では、パーティションを対象に操作しています。
でもディスクドライブに対して不良セクタを除く必要があるようにも思うのですが…、それとスーパーブロックと呼ばれる領域は、各ファイルの中に作られるものでしょうか。
だとするとディスクドライブ全体に操作すること自体が間違いなのかとも思います。知識不足から釈然としませんが、その出力から次の結果となりました。
$ sudo e2fsck -l /tmp/badblocks.txt /dev/sdb
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a valid ext2/ext3/ext4
ファイルシステム. If the device is valid and it really contains an ext2/ext3/ext4
ファイルシステム (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
or
e2fsck -b 32768
Found a dos partition table in /dev/sdb
ディスクドライブに対しての操作ですが、そもそも e2fsck 自体が、ext2 ext3 等のファイルに対するチェックや修復のコマンドなので、私の操作そのものが誤りなのでしょうね。
$ sudo e2fsck -b 32768 /dev/sdb
e2fsck 1.44.1 (24-Mar-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a valid ext2/ext3/ext4
ファイルシステム. If the device is valid and it really contains an ext2/ext3/ext4
ファイルシステム (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
or
e2fsck -b 32768
Found a dos partition table in /dev/sdb
同様のメッセージが繰り返されるだけでした。パラメータを少し変えたりしながら試しましたが、同じメッセージが出されるだけでした。
そこで、ディスクドライブの全域に ‘０’ を書き込んでみることにしました。時間が掛かるのは当然としても想像していたよりは早く完了しました。
$ sudo dd if=/dev/zero of=/dev/sdb bs=1M dd: '/dev/sdb' の書き込みエラー: デバイスに空き領域がありません 953870+0 レコード入力 953869+0 レコード出力 1000204886016 bytes (1.0 TB, 932 GiB) copied, 32963.1 s, 30.3 MB/s
当然ですが、定義してあったパーティションの情報は消去されています。
$ sudo fdisk /dev/sdb fdisk (util-linux 2.31.1) へようこそ。 ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。 書き込みコマンドを使用する際は、注意して実行してください。 デバイスには認識可能なパーティション情報が含まれていません。 新しい DOS ディスクラベルを作成しました。識別子は 0x53cc047d です。 コマンド (m でヘルプ): p ディスク /dev/sdb: 931.5 GiB, 1000204886016 バイト, 1953525168 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト I/O サイズ (最小 / 推奨): 4096 バイト / 33553920 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x53cc047d コマンド (m でヘルプ): q
次に、不良セクタを再び調べると、完了するまでの時間も短く、エラーしたメッセージは１つもありませんでした。実行時間が短いのは、リトライでの繰り返しが無くなっての短縮かと思われます。
$ sudo badblocks -v -s /dev/sdb | tee /tmp/badblocks.txt Checking blocks 0 to 976762583 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors)
これで、色々なパーティションを作成してまともに利用できるのかは不明ですが、もう少し検証してみたいと考えています。
別な情報を検索していると、badblocks の修復について説明しているサイトを見付けました。
ここの説明を見ると mkfs でファイルを作成する時や、 fsck でファイルをチェックする時に、badblocks で収集した不良セクタの情報を適用できるように説明されています。