毎日モザイク

White Room Layout Works

2024-01-11T05:18:07+09:00 [Thu]
--> [debian]

Appimageと普通にインストール

MX-Linuxのneovimのバージョンが微妙に古いのでAppimageで使ってましたが、なんとなく微妙に遅い気がして、普通にソースから入れてみました。

同じ設定で起動すると、

Appimage
173.476 000.005: — NVIM STARTED —

ソースから入れたやつ
132.160 000.005: — NVIM STARTED —

約40ms差。体感と同じく、なんとなく微妙に速くなりました。

2023-12-05T00:07:55+09:00 [Tue]
--> [Ubuntu]

WD RED

WD REDに絶大な信頼を置いていたため、WD REDを買ったのが約10ヶ月前。

mdadmでraid1で運用。なんかいつの間にかlink downを繰替えし、最終的に1.5Gbpsまで落ちて落ち着く感じだったのが、最後は書き込みエラーが出るようになり、ひとまず超link downするほうを殺してdegradeさせた状態で1.5Gbpsまで落ちて安定運用できていたのが1ヶ月くらい。

smart情報ではエラー記録はありません。

ケーブル交換、sataポート変更とかもしましたけど、同じ。

何が悪いのかわかりませんが、なんかの相性的な何かではないかと。

ぶっ続けで、と言っても数100GB程度書き込み続けるとどんどん速度が落ちて、最終的になんかのエラーを吐く感じ。
それでもsmartのエラー記録はありません。

可用性の向上目的じゃなくて、バックアップの安心料のためのraid1なので、もうWD Blue(それでもWD派)でいいや。

2023-12-03T12:39:54+09:00 [Sun]
--> [debian, 日常]

こんばんはMX

ここはMX Linuxでしょ。やっぱり。
ええ。失敗しましたとも。debianの普通のアップデートにね。

完全に素のdebianなら、こんなことにはならなかったと思うんですが、入れちゃったんですね。管理仕切れる気がしたんですが、素人には無理でした。sid。

無謀なチャレンジャーのために何が無理だったかというと、昔の雑な上にアホほど進化が速かった時期のLinuxみたいに、アレをアップデートしたらコレが動かなくなり、コレのアップデートをするには、アレの最新版が入ってないとダメみたいなグルグルに入って、もうダメ。

カーネルを前のやつにした程度では起動できず……。

rdiff-backupのフルバックアップから前日に戻す手もありましたが、もうMX。評判のいいMXで。

特に特筆するところもなく、MX-TOOLSも以前それだけ使ったboot-repairが便利なくらいで、ほかは普通。普通最高!

慣れてしまったので、systemdに変更したくらいで、素の状態に素のリポジトリから素のソフトウェアを入れる。

snapとかflatpacが増えた昨今。素のやつはマジ便利。色とか気にしなくても勝手に変ってくれる。

あと、余談ですが、glowは便利。nvimに入れるとポップアップでmarkdownの雑なプレビュー(数式とかややこしいのは当然表示されない)が爆速で確認できます。

割と勢いで変更できてるのは、rdiff-backupのお陰。

バックアップ、マジ大事。

2023-05-01T23:00:35+09:00 [Mon]
--> [debian]

こんにちはdebian

だいたい一年遅れでやる、ノートPCのOSのアップデート。
ubuntu23042204LTSにそろそろアップデートの時期が参りました。

で、何回かぶりに失敗。

具体的にはなんかpython3.10がらみの依存関係が修復不能なほどに決裂して、起動はするけどupdateとかできない。apt -f installだの修復系はかたっぱしからためしてみたところでdebian。

ここはdebianですよ。

データの類は設定も含めてっていうか、4時間ごとにまるごと過剰にバックアップを取っているので、基本的に何もこわくないわけです。

元々、なぜubuntuにしたのかといえば、debianはデスクトップで使うには標準で配布されているバイナリが全体的に古いっていうのに尽きますが、昨今のubuntu界隈でも、新型はでぶじゃなくて色々厳しいsnapになってたりするので、もうたいした違いはないと言っては言い過ぎですけど…。実際たいした違いはなくせます。

で、ここでは割愛して、大活躍したのがMX Linuxのインストールディスク。これは一家に一枚常備なりUSBメモリに入れるなりしたほうがいいでしょうという親切設計。

toshibaの旧式にUEFIでインストールしたのすが、アップデートをするたびに起動しなくなる。

なんか、/boot/EFI/boot/ じゃないとダメみたいで、debianのインストーラが作る/boot/EFI/debian/だとgrubが出なくてnetbootに落とされるのです。

いろいろ調べた結果。/boot/EFI/boot/bootx64.efi になってないとダメで、debianが入れる/boot/EFI/debian/grubx64.efi だと起動するやつが見つけられなくてnetbootに落されたり、再起動を繰替えしたりするもよう。

これを簡単に回避できるboot repairがMX Linuxのインストールディスクに入ってるわけです。

なんならMXでもと思ってたんですがVirtualboxで試して、インストーラ以外、そんなに違わない感だったので、debian。素のdebian。全裸で。

cronとかにメールを出させるなら、msmtpdとbsd-mailx。

単純便利な、clip-board-autoedit-indicatorは配布元から拾って、
AppIndicator3 っていうので引っ掛りますが、後継があるので、libayatana-appindicator3を入れて、AppIndicator3をぜんぶ、AyatanaAppIndicator3に置換してあげればだいじょうぶ。

あとは、appimageなりflatpakなりsnapじゃないやつで補強すれば日常生活には困りません。

ではubuntuさん。デスクトップのvirtualboxで2004であと1年くらいよろしくお願いします。

2023-03-12T11:17:54+09:00 [Sun]
--> [Ubuntu]

All Your Base Are Belong to Us

みたいなメッセージ出た。

金曜日からのさくらインターネットさんの事故で、復旧発表後も動きません。

微妙に不便なvnc的なやつで電源オフ→オンをしてみたら、出たのがAll Your Base Are Belong to Usみたいな冒頭の画像。

一部障害が残っているという段階だったので、起動、終了ができないのはリモート操作をしている機材なのか、サーバ本体の異常なのかはわからないので、リブート依頼を出しました。

さくらさん凄い。立派。マジ親切。

30分くらいで、サーバ機材の故障で部品の交換が必要。修理部品はあるので、依頼を出してもらえば90分以内に交換できますという連絡をいただいたので、交換のお願いを。

結果的に、画像に出ているメッセージは普通にエラーメッセージで、エラーメッセージを出すところのエラーで何のエラーかわからんけど何かエラーになってる的なものではなく、見たまんま、設定が全部飛んでますってことのようでした。

raid設定の操作マニュアルは公開されているのですが、この手で直接触れない機材に、やった事がない事は試さない主義を貫いて、現地の人にお願いは正解でした。故障ということでしたから、下手にいじってたらトドメを刺したかもしれません。

格闘開始から概ね3時間でvnc的なやつで接続できるようになりました。

で、raidファームウェアの正常画面を経て、vncなのでOSのグラフィカルな感じの起動画面が出て……。

ネットワークの設定のところで待ちが入ったので……。

起動はしたものの、ネットワークに繋がりません。

ssとかipとかしてみたら、eth0がない。upもdownもno suchなんたら。dmesgしたらeth0がeth2に変ってました。

で、決め打ちの所を書き換えてnetworkを再起動したら復活。

諸々確認して、正常終了させて、普通にリモートのやつから起動して外から見て元どおりになってるのを確認してできあがり。

使い出してから始めてのトラブルでした。10年使って初めて。北海道地震のブラックアウトさえ乗り切ったさくらタンまじがんばった。