横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
コピーは終わりましたが， “BIOS boot” というパーティションを作っていないことを思い出して，パーティションを切り直すことにしました．
しかし，これまでupdate不能状態とは言え，その “BIOS boot” パーティションなしで動いていたのに必要なのか，と疑問がわきました．たぶん，今まではDOSパーティションだったので不要だったのでしょう．gptで “BIOS boot” パーティションを含むようにしてパーティションを切り直し，必然的にルートのパーティションをフォーマットし直しました．
もう一度，qcow2型式のルートパーティションをマウントして，念のためにリードオンリーでマウントしたコピー元になる実マシンのManjaroのパーティションからrsyncでコピーしました．
そういえば，以前はnbdで接続したディスクイメージをマウントする場合，mountコマンドにオフセット指定が必要でしたが，最近は改善されて，
mount /mnt/nbd /dev/nbd0p2
と，そのままマウントできるようになりました．人間がますますバカになります😥
コピーに使用する実マシンは，第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を修正して今夜は終わりにします．
振り返ると，一昨年末から昨年初めくらいにかけて，仮想マシンの実マシン化，実マシンの仮想マシン化をしていたようです．
手順としては，
です．しかし，考えてみると/devの中身はディスクが活きているとudevがマウントされていて，起動に必要不可欠なディバイスがない可能性があります．
そこで，別の実マシンを起動して，実マシンのディスクも読み込み専用にして，コピーすることにします．そのためというわけではないですが，サブマシンは，dual bootできるようになってますから，その利便性を活用しない手はないです．死んだディスクから死んだディスクへのコピーですから，/devなども何も考えないでコピーできます（完全なクローニング）．
となると，起動の仕組みをなんとかするのが唯一頭を使う作業です．クローニングした仮想ディスクイメージをマウントして，chrootしてちょちょいのちょいと行きたいところですが，実マシンはUEFIのgrubで起動していますが，仮想マシン環境でUEFIの環境を整えるのはかなり困難なようなので整えていませんからコピー先の仮想マシンの仮想ディスクのマウントポイントにchrootしてgrubのインストールコマンドを実行すると，UEFIでないgrubがちゃんとインストールはされないはずです．
じゃどうすればいいかというと，たぶん，ManjaroのインストールDVDイメージから起動してそこにクローニング完了した仮想ディスクをマウントしてchrootしてgrubのインストールコマンドを実行すれば良いのだと思います．
「ローリングリリースを放って置くと修復不能になる」の最終判断として，updateできずトラブっているManjaroの仮想マシン（Manajaro VM）が，ダウンロードしたアップデートファイルのintegrityをチェックしないように，
# pacman -Syyu
を実行したところ，これまでのように壊れたファイルを削除しますというメッセージは出ず，updateが始まりましたが，最初のファイルでエラーが出て終わりました😓
ということで，何の未練もなく消せます．
仮想のManjaro VMは特に必要性はないのですが，復習のため今動いている実マシンのManaroを仮想化することにします．
このときクライアントも設定も切り替えないと，メールデータの消失・破損などの事故になるので，慎重にやりたいと思います．
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につなぎました．エイヤッ!です．さいわいメールデータの消失や重複は発生しないで済んでいるようです．