rtspがVLC playerで開けない 〜UbuntuもNG〜

随分遠回りをしてしまいましたが,UbuntuのVLCも,rtspは開けないことが確認できました.

ということで,Raspberry Pi 3 Model B (+)に,Ubuntu aarch64版をインストールするのはやめときます.

Raspberry Pi 3 Model B (+) にて,rtspを見る方法がまだ見つかりません.

Raspberry Pi 3 Model B(+)に,Ubuntu aarch64版をインストールする前に仮想マシンのUbuntu x86_32, x86_64でVLCを試して,Debian同様にrtspが再生できないことを試そうとしましたが,仮想マシンの仮想ディスクを保存しているSSDが不具合になり,本当に不具合なのかを検証したり,いずれにしても予備のSSDがないからということで,SanDiskのSSD 2TBを購入して仮想ディスクを移し替えたりしていました.そもそもSSDの不具合は,仮想マシンのUbuntuのdo-release-upgradeの最中に電源断してしまったことが原因なのかもしれません.

3.5インチ2TB HDD 4機を捨てる (2) 暗号化

廃棄するHDDをソフト的に消去する第2案としては暗号化です.メリットとしては,1台ずつ作業ができる(したがって,残しておくHDD, SSDを登板させる必要がない)ことが挙げられますが,1つのそう簡単にクラックされないパスワードをこのために考えて使わなければならないというのがデメリットでしょう.

スピードについては,方式やツールによるでしょうからなんとも解りませんが,複数台同時進行も可能です.

自分のどれかのアカウントと同じでは,あとあと夢見が悪いでしょうから,使い捨てするしかないです.

3.5インチ2TB HDD 4機を捨てる

3.5インチドライブは原則使わないことにしていますが,どう捨てるかが問題です.

今の時代どこの職場にもHDD破壊機はあると思いますが,まだどこのご家庭にもというほど手軽ではないてすね.わが家にも残念ながらありません.

某与党議員のO渕U子さん(仮名)に習ってドリルで破壊するのは,この異常な暑さの中では危険です.

まずは中身をソフト的に復元不可能にします.RAID Level 5のRAID arrayを組んで,rebuildが完了したら1機脱落させて,次のを加えてrebuildし直すを繰り返して,最後の2機は残しておく2.5″ HDDないしSSDにしてやれば,1byteも取り出せない形で廃棄できます.

脱落させたHDDは,インターフェース基板をハンマーで一撃しときます😓

2TBのHDDのRAID Level 5のarrayのrebuildは,下手をすると何日もかかりますので,気長にやりたいと思います.

Postfixを試す (8・完) Postfixを試さない

Postfixを試すシリーズですが, “Postfixを試す (7) Avahiのbuildで難航” で更新が止まっているのに今気がつきました.

結局,Postfixをインストールしようと考えていたサーバーではMail Transfer Agent (MTA)は動かさないことに方針変更しました.Dovecotでサーバー内でやりとりされたメールだけ見てます.ほとんどは,というか全てLogWatchの様なシステムからAdminに宛てたメールですが.

とくに目標があるわけでなく,個人の興味のままやっているので,つまみ食い,食い散らかしプロジェクトだらけです😓

今回の,もともと監視カメラのrtspの映像を転がっているRaspberry Pi 3 Model Bで見ようプロジェクトも,VLC playerがDebianでは機能制限されていることを知り,他のdistroのVLC playerをいろいろ試したいがそれなら仮想マシンが楽ではないかと思い試し始めたら, 仮想マシンの調子がおかしい,そもそもSSDが故障しているのではないか,となって,コピーできる仮想マシンを別ドライブに移した上で,現在SSDの動作を検証中です.

このPostfixを動かそうか検討していたサーバーに関しては,例外的に「使命」がありました😓

大多数の仮想マシンを壊す

Real Time Streaming Protocol (rtsp)をRaspberry Pi 3 Model B (RPi3)でどう見るかの続きです.

残念ながらManjaroは,RPi3では動かないようです.そこで今度は,Ubuntuを試すことにしました.まずはx86_64 (AMD64)で試してからの方が早いだろうと思い,第2 workstation (WS2)の仮想マシンのUbuntuを久しぶりに動かしてみました.いつupgradeしたか全く記憶にありませんでしたが,LTS 20.04になっていました.せっかくだからこの際,最新の22.04にしようと,ネット検索してやり方を探しながら試みました.で,最後のまじない,

do-release-upgrade

を実行していたところ,突然電源が切れました.すぐに何が起こったか解りました.もともと電源コードが緩いのです.ACスイッチをON/OFFすると電源コードにどうしても触れて,しばらく繰り返すと,プラグが外れてしまいます.

それが解っているので,電源ON/OFFの際プラグを押し込む様にしていますが,しばらく忘れていたところ,一番抜けてはいけないタイミングで抜けてしまいました😓

まあ,最近はjournaling file systemなので,途中でズバッと電源を切ったところで,ファイルシステム(FS)が壊れることは滅多にありません.しかし,do-release-upgradeの途中なのでdpkgデータベースがかなり深刻にダメージを受けているに違いありません.

実際,ネットの情報を調べてaptなんとかかんとかしても,全然前進しません.こういうときのために,バックアップを取ってあります.

しかし,そのバックアップのディスクイメージをコピーすると, “input/output error” とかなんとか言ってコピーできません.rsyncでもcpでもだめです

心配になってそのディスクにあるファイルを調べてみると,ここ1年以内に作ったqcow2以外のqcow2が皆同じエラーを出します.

最初はSSDの問題か,マザーボードのインターフェースの問題か,あるいはSSDとマザーボードの相性の問題か,などと考え,問題のSSDをUSBエンクロージャーに入れて,Raspberry Pi 4 Model B (RPi4)につないでcpやrsyncを試しましたが,同じエラーが出ます.

ということで,ここ1年より前に作った,まあ,知的資産のqcow2は全滅のようです.ほとんどここ数年触っていないファイルで,今回の電源断の時もリードオンリーでさえ開いていないので,電源断が問題とは思えません.

まあ,古い仮想マシンの仮想ディスクなんか,滅多に役に立つことはないので,実害はないのですが,長年熟成してきたのに寂しい気はします.

md5sumでも同様のエラーが出ます.