Instagramが他のSNSの参照先になっていて，導かれて移動したら，誕生日を入力させる画面が出て，誕生日を入力しないと先に進めない状況になりました．
iOSアプリでもWeb UIでも同様です．
誕生日を入力したくないのでアカウントを削除する場合にもいったん誕生日を入力しないといけません．
怒り心頭です．もし，この先，誕生日の入力をしないでアクセスできるようになったらアカウントの削除をするつもりです．
Category: Computer
実マシンの仮想化 Lesson 2 ディスクのコピー
コピーに使用する実マシンは，第2 Workstation（WS）の第2 OSであるDebianです．
ディスクイメージは，今回update不能と判断したqcow2を使います．formatはしません．まるまるコピーするときはformatしたほうがあとのコピーが速いケースが多いですが，update不能なほど古いとはいえManjaro同士なので多少そのまま使えるファイルがあってコピーが早く済むかなと期待しました．
実Manjaro (第2 WSの第1 OS）を念の為read onlyで，Debianにマウントし，仮想ディスクは，nbdのモジュールを使って，write enableでマウントしました．
コピーはrsyncでします．
実マシンのディスクスペースは400GBなのに対して仮想マシンは80GBしかないので，Raspberry Piのバックアップや，ISOファイルづくりの過程や完成品などはコピーしないよう，rsyncのフィルター設定をしました．
途中でなんか余計なもののコピーを始めたら，とめて，フィルターを追加してまたコピーし直すというのができるのが，rsyncでするコピーの大きなメリットです．
20分ほどでコピーが終わったので，/etc/fdiskを修正して今夜は終わりにします．
実マシンの仮想化 Lesson 1 予習
振り返ると，一昨年末から昨年初めくらいにかけて，仮想マシンの実マシン化，実マシンの仮想マシン化をしていたようです．
手順としては，
- qcow2のディスクイメージを作るかどこからか持ってきて，パーティションを切って，formatする
- メインディスクの部分を実マシンにマウントして，rsyncで実マシンの内容をコピーする（/devに注意が必要）
- 起動の仕組みをなんとかする
です．しかし，考えてみると/devの中身はディスクが活きているとudevがマウントされていて，起動に必要不可欠なディバイスがない可能性があります．
そこで，別の実マシンを起動して，実マシンのディスクも読み込み専用にして，コピーすることにします．そのためというわけではないですが，サブマシンは，dual bootできるようになってますから，その利便性を活用しない手はないです．死んだディスクから死んだディスクへのコピーですから，/devなども何も考えないでコピーできます（完全なクローニング）．
となると，起動の仕組みをなんとかするのが唯一頭を使う作業です．クローニングした仮想ディスクイメージをマウントして，chrootしてちょちょいのちょいと行きたいところですが，実マシンはUEFIのgrubで起動していますが，仮想マシン環境でUEFIの環境を整えるのはかなり困難なようなので整えていませんからコピー先の仮想マシンの仮想ディスクのマウントポイントにchrootしてgrubのインストールコマンドを実行すると，UEFIでないgrubがちゃんとインストールはされないはずです．
じゃどうすればいいかというと，たぶん，ManjaroのインストールDVDイメージから起動してそこにクローニング完了した仮想ディスクをマウントしてchrootしてgrubのインストールコマンドを実行すれば良いのだと思います．
と思ったけど，当BLOGの記事を調べてもよく解りません．そんなに昔じゃないけどすっかり忘れた感じです．
壊れたManjaroは修復不能
「ローリングリリースを放って置くと修復不能になる」の最終判断として，updateできずトラブっているManjaroの仮想マシン（Manajaro VM）が，ダウンロードしたアップデートファイルのintegrityをチェックしないように，
- Ignore signature check when doing pacman command on Archlinux (archlinuxuser.com)
# pacman -Syyu
を実行したところ，これまでのように壊れたファイルを削除しますというメッセージは出ず，updateが始まりましたが，最初のファイルでエラーが出て終わりました😓
ということで，何の未練もなく消せます．
仮想のManjaro VMは特に必要性はないのですが，復習のため今動いている実マシンのManaroを仮想化することにします．
SigLevelをほとんどTrustAllに設定．
結果的にDovecotへの切り替えはエイヤ!
このときクライアントも設定も切り替えないと，メールデータの消失・破損などの事故になるので，慎重にやりたいと思います．
Dovecotへの移転は手作業
のつもりでした．メインWSのメインのメールソフトであるThunderbirdで作業を始めました．この時点で，同じサーバーの同じIDで違うポートにアクセスする2つのアカウントが機能して，それぞれ旧IMAPサーバー(port 933)とDovecot (port 10933)に問題なくつながっています（メールデータのコピーもできました）．
次にサーバーの旧IMAPサーバーを止め（/etc/inetd.confのport 933の行をコメントアウトしてinetdを再起動），Dovecotのポートを10933から933に変えてDovecotを再起動しました．
次にThunderbirdですが，起動したら前の設定のまま接続に行きますから，接続できないようにサーバーのパスワードを変更してから起動しました．そして，Dovecotに対応したアカウントのほうのパスワードだけ新しいものを入力してサーバーに接続しました．
ここで，予定どおりThnderbirdのアカウントの設定の，10993につなぐところを993に変更しました．しかし，想定外のことが起きました．このThunderbirdに設けているアカウントの2つが，どちらも同じUser IDで同じサーバーの同じポートにつながる設定になったわけですが，仕様なのかバグなのか，2つのアカウントのうち古い方（旧IMAPサーバーにつないでいた方）が消えてなくなってしまいました．
さいわい，メールデータを移転した先でなく，元のほうが消えたのでデータの消失は免れました．
ノートパソコンやLinux WSのThunderbirdでは，敢えてDovecot用のアカウントを作らず，旧IMAPサーバーにつなぐ設定でそのままDovecotにつなぎました．エイヤッ!です．さいわいメールデータの消失や重複は発生しないで済んでいるようです．
もちろんパスワードも同じ．
もちろんサーバーもクライアントもIMAPの仕様どおりに動いていれば，サーバーの内容にクライアントが同期（クローニング）するので，データ消失なんて起こらないはずですが，仕様から外れたことが起こるのが世の習いです😓
ただし，旧IMAPサーバーで必要としていたメールボックスのプリフィックス(.imapなど)は不要なので削除しました
Note 2と同じ．