そこでいきなり落ち着きを取り戻し、今回のアップデートの内容をみてみると、なーんとなく「KB4601382」が怪しい気がする。「ハイダイナミックレンジ(HDR)ディスプレイで使用できるリフレッシュレートが正しくないという問題の修正、特定の低遅延対応モニターでレンダリングするとビデオ再生がちらつくことがある問題の修正など」とあり、やはりなーんとなく勘ぐってしまう。

専門の方に原因を究明していただきたいと思っていますが、現状回復したので自分的には（今日のところは？）結果オーライではあります。ただ、文字が若干細ったように見えるのがちと気にはなっています。

2021-01-12

fakeなmicroSDカードにwishbone ash、アルゴス

いやー、はまりにハマった一週間であったが、よもやfakeなmicroSDカードが原因だったと今朝になるまで気付けなかった。

f:id:hoshiyama-jun:20210112162201j:plain — fakeな仲間たち

exfatでフォーマットできるが、ext4やntsfなどでフォーマットできない

fdiskで、pするとそれなりにマトモな感じに見えるがdもnもwできないんだワ。これが。

大量データを保存してみるとなぜかデータの取りこぼしや不整合がそれなりに出る。メゲずに壊れたファイルをようやくリストアしたかと思い翌日ファイルにアクセスするとロードできない、昨日のフル作業が灰燼と帰す。

マシーン環境やデバイス、転送プログラムなど見直しもしやと思いググるとこの話題。ザクザクあります。そしてまず、H2testwにたどり着く。早速試してみるが8時間程度経っても延々と続くH2testwはあきらめ、もう一つたどり着いたf3probeで覚醒。

sudo ./f3probe --destructive --time-ops /dev/mmcblk0sudo ./f3probe --destructive --time-ops /dev/mmcblk0

とすると。

F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA. This is free software; see the source for copying conditions.
WARNING: Probing normally takes from a few seconds to 15 minutes, but
it can take longer. Please be patient.
Bad news: The device `/dev/mmcblk0' is damaged
Device geometry: *Usable* size: 0.00 Byte (0 blocks)
Announced size: 999.02 GB (2095104000 blocks)
Module: 1.00 TB (2^40 Bytes)
Approximate cache size: 31.00 MB (63488 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 7'36" Operation: total time / count = avg time
Read: 13.44s / 131289 = 102us Write: 7'22" / 190721 = 2.3ms
Reset: 2us / 2 = 1us

7分半で結果が得られる。が、

「Bad news: The device `/dev/mmcblk0' is damaged Device geometry: Usable size: 0.00 Byte (0 blocks)」ってところから、アダプタとかマシーン側ハードウェアの不調かもと思いUSB刺しでも試してみたが変わらず。まぎれもないfakeでした。しかし、使える領域があるんじゃないかと、あきらめ悪く続けてみる。

fdiskの状況はこんな感じ。

sudo fdisk /dev/mmcblk0

fdisk (util-linux 2.34) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。


コマンド (m でヘルプ): p
ディスク /dev/mmcblk0: 999.2 GiB, 1072693248000 バイト, 2095104000 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x00000000

デバイス       起動 開始位置   最後から     セクタ サイズ Id タイプ
/dev/mmcblk0p1            32 2095103999 2095103968   999G  7 HPFS/NTFS/exFATsudo fdisk /dev/mmcblk0

fdisk (util-linux 2.34) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。


コマンド (m でヘルプ): p
ディスク /dev/mmcblk0: 999.2 GiB, 1072693248000 バイト, 2095104000 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x00000000

デバイス       起動 開始位置   最後から     セクタ サイズ Id タイプ
/dev/mmcblk0p1            32 2095103999 2095103968   999G  7 HPFS/NTFS/exFAT

そんじゃパーテーションをいじってみるか。って事で、アダプタもfakeかもと頭をよぎりmicroSDをUSB刺ししてlsblk。

sdb
└─sdb1 exfat 688C-5C75

で、再びfdisk。

ディスク /dev/sdb1: 999.2 GiB, 1072693231616 バイト, 2095103968 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x00000000

デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ
/dev/sdb1p1 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdb1p2 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdb1p3 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdb1p4 4294967295 5035196669 740229375 353G ff BBT

笑ってしまう4つのパーテーション。まっさらにすっか。って事で手始めに一個削除。

sudo fdisk /dev/sdb
fdisk (util-linux 2.34) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。 書き込みコマンドを使用する際は、注意して実行してください。

コマンド (m でヘルプ): d パーティション 1 を選択
パーティション 1 を削除しました。
コマンド (m でヘルプ): w
パーティション情報が変更されました。
ioctl() を呼び出してパーティション情報を再読み込みします。
/dev/sdb: デバイスのクローズに失敗しました: 入力/出力エラーです

というありさま。しかし、500Gあたり500円程度のコストなんだが販売業者的にペイできているのか？を考えた時、何故かふとArgusを思い出してしまった。

以下、正常なモノでは。

mmcblk0
└─mmcblk0p1 exfat          0123-4567

sudo fdisk /dev/mmcblk0

fdisk (util-linux 2.34) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。


コマンド (m でヘルプ): p
ディスク /dev/mmcblk0: 116.37 GiB, 124939927552 バイト, 244023296 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x00000000

デバイス       起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/mmcblk0p1         32768 244023295 243990528 116.4G  7 HPFS/NTFS/exFAT

コマンド (m でヘルプ): i
パーティション 1 を選択
         Device: /dev/mmcblk0p1
          Start: 32768
            End: 244023295
        Sectors: 243990528
      Cylinders: 15188
           Size: 116.4G
             Id: 7
           Type: HPFS/NTFS/exFAT
    Start-C/H/S: 2/10/9
      End-C/H/S: 1023/254/63


sudo ./f3probe --destructive --time-ops /dev/mmcblk0
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Good news: The device `/dev/mmcblk0' is the real thing

Device geometry:
                 *Usable* size: 116.36 GB (244023296 blocks)
                Announced size: 116.36 GB (244023296 blocks)
                        Module: 128.00 GB (2^37 Bytes)
        Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
           Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2'38"
 Operation: total time / count = avg time
      Read: 707.7ms / 4817 = 146us
     Write: 2'29" / 4192321 = 35us
     Reset: 2us / 1 = 2us

さて。失った時間を取り戻さねば。Blowin' Free。

2016-10-22

mondoでlive filesystemバックアップとリストア

cloud

conoha旧サービス最小構成のVPSにplexmediaserverを入れ、acd_cliでぶる下げたamazon driveをplex cloudで連携させてみたところ、動画や音楽を非常に楽しめる環境ができあがった。特に音楽系では、巨大flacなファイルまでスルスルとストリーミングするので、うれしくなって500Gほどamazonへ放り込んだところ、VPSを見ると1.5G程度ディスク容量が減っているのに気づいた。

いろいろ調べてみると、
/var/lib/plexmediaserver/Library/Application Support/Plex Media Server
配下にジャケ写画像などのファイルがcacheされるのだそうだ。

動画ファイルもガンガン放り込んだりしており、そのサムネイル画像などもcacheされていくので、今後どんどん肥大化していくこいつを何とかしなければならなくなった。
現況、基本構成（20G／80G）で使っていたので、全容量20Gのうち残りが5Gほどしか無く困った。どこか空きがという事で同じくamazonへと思ったが、plex supportを見るとサーバが（どう考えても）不安定になりそうなので、これは断念。

そこで、mondorescueを使って現環境をそのまま新しいVPSへ移行と考え、実行してみるとうまくいかない。あれこれ試行錯誤を繰り返しつつも一向にラチがあかない時にフッと残りの80Gをマウントしたほうが手っ取り早いのでは・・・と、ここに行き着く。

＜結論＞

基本構成（20G／80G）について、mondorescueをいじくり回していたおかげで、fdisk -lを実行して、全くの勘違いであった事にようやく気づく。残りの80Gは、/dev/vdbにext4で存在しており、これを、新たに作った/dataディレクトリにマウントして80Gを確保。ここに問題のcacheを含むApplication Supportをコピーし、/var/libのほうへシンボリックリンクをおき完了。あーあ。ってな感じで終了。。。

だが、いずれはお世話になりそうなmondorescue。ちゃんとリストアできるのか否かの検証のため、以下をメモ。

＜バックアップ＞

肝は、テンポラリーファイルやスクラッチファイルなどバックアップに関係する場所から除外する事だった。コマンドはCUIで、

mondoarchive -Oi -s 10000m -d /data/backup -T /data/backup -S /data/backup -E "/data/backup|/home/plex/acd3|/home/fedora/acd" -p conoha-`date +%Y%m%d`

とした。
サービスなど何も停止せずにバックアップしたが、いろいろ試した中でリストアが最もうまくいった。

＜リストア＞

とりあえず、/dev/vdbで80Gをマウントできた事で、cache肥大の件は解決したので、試しにconohaの旧サービスでVPSを追加し、そこへ試してみた。

オートでリストアすると、正常に終了。ディスクを排出して、exitすると難なく起動。とりあえず、rootでログインしてシェルからfdisk -lでチェックすると、/dev/vda1と/dev/vda2の両方にブートフラグがたっていた。なので、vda2のほうはこれを外す。
ざっと見た目良好だったが、/dataにデータがリストアされておらずスッカラカン。という事で、/etc/fstabを見ると、/dataにマウントする/dev/vdbはちゃんとアサインされている。。。

うーん、、、という事で、試しにinteractiveモードで再試行。

まず、Editing mountlistに何故か、/dev/vda2がlvmで表示されている。これを、/dev/vdbで、Mountpointを/data、Formatをext4、Sizeを0に修正。

次に「Do you want to erase and partition your hard drives?」と聞いてくるので、「Yes」。とするが、Configurering LVMで失敗し、「Re-edit the mountlist」と聞いてくる。なら、って事で、Re-edit the mountlistのところで、<cancel>を選びシェルにし、chrootする。ここで、fdisk -lしてみると、/dev/vda2が無いようだ。なので、
fdisk /dev/vdaで、nで、あとは、returnし続け新しくパーティション/dev/vda2を作り、tで8eのLinux LVMにする。さらに、aで、/dev/vda1をブータブルにし、wで保存。

exitでchrootを抜けると再びmondorescueが起動。boot:でinteractiveとし、mountlistsで/dev/vda2の所を同じ修正をして<OK>。先ほどパーティション操作はしたので、erase and partitionのところは<cancel>。すると今度はConfigureing LVMが成功し、各パーティションのフォーマットするかどうか聞いてくるので、<Yes>。

ようやく「Restoring from archives」で<Yes＞でデータのリストアを開始。

で。「Initialize the boot loader?」で<Yes>。initrdをre-generateせよ、とのAlertにすべて<Yes>。chrootされているシェルで、とりあえずブートローダーの再インストール。

grub2-mkconfig -o /boot/grub2/grub.cfg
し、
grub2-install /dev/vda
で、Installation finished. No error reported.

次に、dracutコマンドを使って、initramfsの再構成をおこなう。
cd /boot
ls -l vmlinuz*
で、ブートしたいカーネルを確認し（うちの場合）、
mv initfamfs-3.17.8-200.fc20.x86_64.img initfamfs-3.17.8-200.fc20.x86_64.img.oldと退避させ、
dracut initfamfs-3.17.8-200.fc20.x86_64.img 3.17.8-200.fc20.x86_64

exitでchrootされたシェルを抜け、再びGUI。あとは、ひたすら、Yesで、control-x。

すると、「GRUB is now installed correctly」で、<OK>。ラベルとか聞いてくるが、これも<Yes＞で、<OK>。

Excution run ended; result=0という事で、isoを排出して、exitでリブート。

で。ブートするが、何故か、no such deviceでデバイスが無いよ。とのエラーを吐く。とりあえず、rootでログイン。

df -lすると、今度は、/dev/vdbがちゃんと/dataにマウントされており、かつ中身も正常にリストアされている。

fdisk -lすると、/dev/vda1にのみブータブルフラグがたっており、/dev/vda2も指定どおり。

grub2でのno such deviceが不気味だが、何となくほぼリストアできた実感。

2016-10-01

unlimited cloud storageにノセられて

cloud

長らくpogoplug cloudを使い続けてきた。何度かごっそり消失したなどという事などがあったが、ランニングコストが異常に安く感じていたためパフォーマンスや消失したファイル群などへの思いをオーバーライトしつつ使ってきたが、サービスが終了してしまうので、前から気になっていたamazon cloud drive unlimitedに手を出してしまった。

amazonのこのサービスには、無制限お試しが始まった頃にちょっと試してみたが、クライアント側のアプリのアップローダーやプレイヤーに納得できず、とても使いものにならないと判断し、たいして使わずに退会してしまった。20分越えの動画が再生できなんじゃどーしようもねーな。画像系だけならプライムで充分じゃんってな感じ。

ところが、そんな事情もあり、cloud storage周辺をいろいろ調べてみると、amazonが最強との声も多く、acd_cliとかplexmediaserverとか、以前納得できなかったモノを使わなくても運用できそうな事から、コスト的には数十倍になってしまうが、再度こちらを使ってみた。

結果。想像以上に運用できそうな感触を得たので、その手順と経過をメモする事にした。

① 移行

VMでfedora20を走らせているVPSに、既にpogoplugfsを使ってpogoplug cloudをマウントさせた事があるので、ここにamazonをマウントさせrsyncでコピーする事にした。

acd_cliは作者によるドキュメントがあるので、これを読みながらやったら難なくインストールできた。oauth_dataを得るためターミナルに慣れないw3mが起動され、操作に若干手間取ったが、capture入力要求が無かったのでうまくダウンロードできた。

で。amazonをマウントしてread/writeを確かめてみると（pogoplugfsとは異なり）まるでローカルドライブのようにディレクトリ共に読み書きでき感動。優れものです。

早速、pogoplugもマウントし、rsync。案の定、pogoplug側の読み込みが異常に遅く、また不安定でもあり、500G弱を約4日間かけ終了。（pogoplug cloudをWebブラウズすると4.2Tあったが、その時点で0byteだったり消失してしまっていたものが多数あり、結局残存していたものは500G弱だったと判明・・・さよならpogoplug！）

手元のPCでamazon cloud driveをブラウズしてみると、ちゃんと入っており、思わず小躍り。（っていうか、入っていて当たり前なんだが。）ただ、動画を再生してみるとやはり20分未満のみ。という事で、次のステップへ。

②コンテンツをブラウジング

yanoshiさんの「さわっても熱くない花火」の関連記事を激しく参考にさせていただきつつplexmediaserverをVPSへ導入。

インストールから起動まではサクサクっと進んだが、マウントしたamazonを読み込んでくれなく、熱く（暑く？）なってしまう。

yanoshiさんが紹介してくれている元ネタを読むと、plexmediaserverのplexというidでacd_cliを操作させているのが冗長に感じられ、何とか自分のログインidでの運用を目指したが、パーミションをいじってもダメ、シンボリックリンクもダメ、その他いろいろすべてダメで、断念。素直に、元ネタさんの記事をfedora目線で読みつつやったら成功。自分の知識不足になげきつつも、動画やオーディオがザクザク読み込まれていくのに感動。さらに、2時間越えのflvまでサクッと再生できるじゃありませんか。素晴らしい。

で。ふと。ログインidでマウントしたamazonはどーなってるの？と、ちと気になり、adc_cli lsで、ちゃんと見えている。新しいコンテンツを投げ込むとちゃんと受け取ってくれている。なるほど、fuseと今更ながら納得。しかし、これではVPSにディスクを増設するよりもamazonをぶる下げてしまえばOKなどという事もありかなぁ。などと、思ってしまった。

③手元からの上り経路

あまりにも感動したので、plex passをお試しのつもりで1ヶ月分購入してしまった。で、セキュリティ（というか、外部漏洩防止）を確保しつつ、モバイルアプリでもサクサク動作が確認でき、メディア系ファイルの下りは、plexmediaserverで文句無しとなった。（が・・・コスト捻出を何とかしなければ・・・）

じゃ、上りは。って事で、win10なubuntuのbashでVPN同様acd_cliを導入しようとしたが、modprobe fuseはできないのでamazonをマウントできなかった。（というか、マウントだけできなかった・・・これが肝心だと思うのだが。）Macは試していないが、ググってみるとやはりこちらもダメなようだ。

うーん。専用アプリでアップロード・・・やりたくないなぁ。と、思っていたところ、手元のマシーンからVPSのログインidへマウントしたamazonへ向けrsyncすればイイんじゃないか。って事でやってみたら、ズコズコ飛んでいく。win10 Anniversary updateありがとう！（笑）2G程度のフォルダに収められたファイルやフォルダがログインidのamazonマウントポイント配下へrecursiveに転送。うちの環境で、ペヤングに熱湯注いで食べ終わる程度で終了。pogoplugへウンウン唸りながらアップロードしていたのは一体なんだったんだろうか。また、macとwin両方で同様に使えるrsyncのほうが、妙なアプリなどを使うより、僕にとっては透過的でわかりやすい。plexmediaserverへの反映はid plexでacd_cli syncする必要があるが、これはスクリプトを書けば何とかなるでしょう。

という事で、これにて。

尚、10月1日15時32分現在。未だpogoplug cloudへはアクセスできるようです。（膨大な数の0 byteコンテンツは移管ともしようがありませんが・・・）

2015-11-23

win10アップデートでコルタナ

1週間前くらいにコルタナにアップデートしてみました。

win10にした直後は、あれやこれや問題が出ていましたがそれらはほぼ解決（もともと、それほど複雑な事をしていなかった事もあってか）、ここまで実に快調で、コルタナにアップデート後も問題無しです。

ただ。コルタナアップデートに１時間ちょい時間がかかったのでメモ。

アップデートはwin7からwin10にアップグレードした時と同じ画面・工程で進行。今回はアップデートなんだからせめて進行状況画面を少しは変えてくれたら複数回勝手にリブートさせられるんだから、復帰までのあの張り詰めた緊張感は薄らいだのでは・・・。
３工程とも100パーセントで最後のリブート後、ログイン画面に復帰し、そこでログインした後、デスクトップが現れるのではなく、「？！」と思うようなメッセージと共に、残りのアップデート作業が開始され、え！まだあるの・・・みたいな怠さ。ログイン画面を出すんだから、その時にまだ終わってませんよ〜みたいなメッセージでも出してくれれば、もう少し気を確かに保てたような気が・・・。
一番最後にブラックスクリーンになったままでなかなか復帰しないのが不気味。時間的には３分程度だったがここをじっと我慢しているのが一番つらかった。

ってな感じで、トータル１時間ちょいディスプレイに貼り付きでようやく無事終了。その後は、全く問題無し。と思ったら、AMD Quick Stream Technologyが権限無しなアラートが出ましたが、これはwin7からのアップグレード後と同様、AMDサイトからダウンロードしてインストールしたら出なくなりました。

2015-09-01

z575へのwin10導入その後

やっとのおもいでwin7に復帰したばかりだが、再度挑戦。今度はうまくいきました。

ただ、サクッとはできなかったのでメモ。

普通に「Windows 10を入手する」、「Windows Update」からでは、やはりモダン・セットアップ・プログラムがエラーして継続できなかった。
従って、前回書いた [FIX] “Modern Setup Host Has Stopped Working” While Upgrading To Windows 10 の記事にある手順を素直に実行してみた。
で、FIX1の方法ではダメで、また、FIX2の方法でもC:￥Windows￥SoftwareDistribution￥Downloadのファイルを残したままだとダメで、FIX1をすべて実行し再起動後すぐにMedia Creation Toolを使ってうまくいった。また、その際、モダン・セットアップ・プログラムはエラーしなかった。

という事で、ようやく導入できたのだが、ご多分にもれず、挙動が非常におかしい。。。たとえば、

「設定」や「Microsft Edge」などが開かない。なので、はっきり言って何もできずこれ以上前に進めない状態。。。
では。という事で、system32にある、control.exeをダブルクリックしてみるが反応無し。右マウスクリックで管理者権限を与えてやると実行する模様。つまり、管理者権限が与えられてるユーザーなのに、機能していない。また、explorer.exeでは「要素が見つかりません」と・・・。
フォーカスが10秒程度ごとに前面に来たりバックグランドに逃げたりを繰り返す。そのため、文字入力などをしているとバックグランドに逃げたフォーカスが戻ってくると文字列が全て選択され、その後に入力した文字で上書きをしてしまうので、使いものにならない。

が、これらはラッキーな事に解決方法が既に記事としてあり、「PCトラブルカルテ Vol.7」で説明されている解消手順を実行し、Microsoftのコミュニティにあった「Edgeなどを起動させると〜」にあったレノボの「Onekey Theater」をアンインストールで、一気に解決しました。助かりました！

他、以下の点の解決策を模索中。

起動時に「AMD Quick Stream」が、本ソフトの権限情報は見つからない。と、言ってくる。
＜解決＞「Download AMD Quick Stream Technology」サイトから最新のドライバをダウンロード＆インストールで解決。
Firefoxのみ、Flashビデオがグリーンバックになるか、ステレオグラムのような画面になりまともな再生をできない。
＜一部解決＞サイトによってはHTML5なMP4 Videoも見れなかったが、これはFirefoxの「オプション」の「プログラム」でMP4 Videoの「取り扱い方法」が毎回確認する（複数プログラムが登録されていたので）となっていたのを明示的に一つに指定してOKとなる。
＜あきらめる＞dailymotionやFC2などのFlash動画が未だ見れないが他のブラウザで見る事にしてこれ以上の追求はあきらめる。すべてのFlash動画が見れないわけではなく、一部のサイトでのみ見る事ができない不思議さ・・・。
＜解決＞グリーンバックでノイズ混じりでビデオがうまく再生されていないPlayer上でマウス右クリックし「設定」で、ハードウェアアクセラレーションの有効化のチェックを外したら、うまく再生できるようになりました。
なんらかのタイミングでbing.vcが混入したため除去の必要あり。
＜解決＞ AdwCleanerにて除去。
Win10が動作するQuickTimeの旧バージョンをインストールしたいが、既にインストールされているものが、Vista/7が必要とアラートが出てアンインストールできない。
＜妥協＞win7の時に入れていたQuickTime7.7.8が正しく動作しているようなので、このまま黙って利用。