Debian実マシンをぶっ壊す (3) いちおう復旧

もとの実マシンでなく仮想マシンから持ってきたので,厳密な意味での “復旧” ではありません.しかし,Debianの実マシンが復活したので,広い意味での復旧ということにします

結局最終的に成功したのは,Manjaroの実マシンにDebianのパーティションを適当な場所(たとえば/mnt/hd)にマウントして,

root #mount --types proc /proc /mnt/hd/proc
root #mount --rbind /sys /mnt/hd/sys
root #mount --make-rslave /mnt/hd/sys
root #mount --rbind /dev /mnt/hd/dev
root #mount --make-rslave /mnt/hd/dev
root #mount --bind /run /mnt/hd/run
root #mount --make-slave /mnt/hd/run 

という具合にお膳立てしてから,

root #chroot /mnt/hd /bin/bash
root #source /etc/profile
root #export PS1="(chroot) ${PS1}"

として,さらにDebian実マシン用のEFIにしている/dev/sda1を/boot/efiにマウントしてから,UEFI+Grub2の手順にしたがって,EFIとGrubをインストールしました.

一年前の実マシンのバックアップからの復旧も試してみます.

このページの内容は固定ページに収録します.

利用した仮想マシンはもともと実マシンのクローンとして作成したので “復元” に近いといえます.

Debian実マシンをぶっ壊す (2) 進展なし

昨夜も2時間ほどあがきましたが進展なしです.

まずはぶっ壊したパーティションに,生きているDebian AMD64 bookworm (12.1)の仮想マシンの仮想ディスクの内容をコピーしました.これは内容量があまり多くなかったこともあり思ったより短時間ですみました.

引き続き自分で書いたメモに従い,DebianのインストールDVDイメージをUSBメモリーに焼いてレスキューモードからターゲットパーティションをchrootでマウントするという手軽な方法をとりましたが,それから先が進みません.EFIの設定もGrubの設定もエラーが出てできません.

お手軽なchrootがいけないのかもしれないので,手で設定してからchrootするManjaroの方法を今夜試してみます.

厳密には,空いている手頃なUSBメモリーがなかったので,16GBのSDカードに焼いて,USB-SDカードアダプターに差しました.

Debian実マシンをぶっ壊す

昨夜,なんにもしてないのにDebianの実マシンを壊してしまいました

Debianの新しい安定リリースbookwormが6月にリリースされていたのに今頃気が付き,まずは仮想マシンからupgradeしてみました.Debianの仮想マシンはAMD64版とx86 32bit版の2つを飼っていて,特になんにも考えず,/etc/apt/sources.list内のbullseyebookwormに書き換えて,apt update; apt upgrade; apt full-upgradeや,apt autoclean; apt autoremoveをしたらbookwormになりました.

楽勝だったので実マシンもupgradeすることにしましたが,かけがえのない実マシンなのでより慎重にとsources.listを書き換える前にapt update; apt upgrade; apt autoclean; apt autoremoveをしてから,sources.listを書き換え,仮想マシンと同じ手順を施しましたが,ぶっ壊れて再起動しなくなりました.updateの過程でファイル関係のエラーメッセージが出ていたようですが,気にせずやったのが良くなかったようで,Manjaroを起動して,Debianのrootパーティションをfsckすると,修復不能と出ました😓

これはいったんパーティションをフォーマットし直すしかないので,バックアップを確認すると,ちょうど一年前の7月のものが最新でした😓 それでも動かないのではしょうがないので,パーティションをフォーマットしてからrsyncで1年前のバックアップをコピーバックしました.

しかし,grubの設定の仕方をすっかり忘れてしまい,昨夜のうちには起動できませんでした.

自分の記録を見ると,インストール用DVDイメージからレスキューモードでgrubの設定をするようです.一年前のDVDイメージを探すのも面倒なので,bookwormにupgradeできた仮想マシンのディスクイメージをDebianのパーティションにコピーして, 最新のDVDイメージからrescueすることにします.この仮想マシンはもともと実マシンから移転したものです.

まあバックアップの意味もあって仮想マシンを飼っているわけです.ただし,仮想マシンの仮想ディスクからコピーバックするのはかなり時間がかかります.今回実マシンの復元に成功したら,今後はまめにバックアップを取ることにします.

なんにもしてないのに壊れるわけはなく,厳密に言えば,「何も悪いことはしてないのに…」です.世の中に蔓延する「何もしてないのに壊れた」も,責任逃れのいいわけです.
一年前のバックアップがその時点でup-to-dateな保証もないし😓

突如としてMTAへの攻撃が止む

何年か続いていたMail Transfer Agent (MTA)への攻撃が7月2日をもって止みました.

2年前からの不正なアクセスのIPアドレスを全部iptablesで “DROP” しています.その数は7000余りです.

たぶんまた何か月か経ったら新しいIPアドレス(=ボット)を使って攻撃してくるとは思いますが.

ATOKの使用終了を検討中 (2)

今もGoogle日本語入力の評価を続けています.まだ十分に自分ナイズされていないから,自分では絶対に使わない言葉が第1候補に出てきたりして途惑うことが多いです.これは使い込んでいけば解消されるとは思いますが,今のところ確かなことは解りません.

それから,あいかわらず連文節変換がだめです.こんな日本語ないだろうということをしばしばやらかしてくれます.

それと細かいことですが,個人的には文書中やタイトルに付ける日付は, “2023年6月14日(水)” の型式にしていまして,ATOKでは「きょう」,「きのう」,「おととい」,「あす」,「あさって」等と入力して “変換” すると,その形式が第1の候補に出ます

一方のGoogle日本語入力では例えば「きょう(変換)」とすると, “2023年6月14日” は出ますが,かならず第6候補で,何回入力しても第1候補に上がってきません.また,曜日を思い出して「すい(変換)」として追加しなければなりません.それも後ろから2番目の候補です.

曜日を思い出すのにひとタイミング遅れますが,認知症予防になって良いのかも知れません.

また,かつて何度か経験したのですが,評判のよい変換ソフトを試してみたものの,かな入力では非常に使いにくい,ということがありました.たぶん,かな入力はいちおう付けてみたものの,開発した会社にかな入力を実用的に使っている人がいなくて評価できなかったのでしょう.今日そんなことがあるのかどうか解りませんが,新しい日本語入力システムを使う際の最大の懸念材料です.

その辺ATOKはかな入力に対して全く問題ありませんし,Google日本語入力も今のところかな入力に関連した問題はないです.

もうしばらくGoogle日本語入力を使ってみます.

スペースキー押し下げ.
候補順については自分ナイズできているからと思います.
全く使い物にならないレベルのものもありました.
だから長年使っているわけです.