Category: Manjaro

実マシンの仮想化 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をチェックしないように，

この記事を参考に設定して，

# pacman -Syyu

を実行したところ，これまでのように壊れたファイルを削除しますというメッセージは出ず，updateが始まりましたが，最初のファイルでエラーが出て終わりました😓

ということで，何の未練もなく消せます．

仮想のManjaro VMは特に必要性はないのですが，復習のため今動いている実マシンのManaroを仮想化することにします．

SigLevelをほとんどTrustAllに設定．

Firefoxが勝手に最後までスクロールする（解決）

OSを変えたら治ったなどという絶望的な記事を見つけて，諦めてしまっていましたが，ブラウザによらないということで，これはなんかブラウザではないところに原因がありそうと，もう少し検索を進めたところ解決しました．

なんと，システム設定のアクセシビリティーにあるスクリーンリーダーONがいけないとのことです．

そんなものONにした覚えは全く無いです．

Firefoxが勝手に最後までスクロールする

注: 解決しました → Firefoxが勝手に最後までスクロールする（解決）

かなり前からなのですが，サブworkstation（サブWS）のサブOSであるDebianでFirefoxを使ってweb pageを開くと，開くたびにそのページの最後まで勝手にスクロールしていって，ページの読み込みとそのスクロールが完了するまで手も足も出ない状態となります．

とはいえ，いったん最後までスクロールすればあとはフツーに使えるし，サブWSのサブOSではそんなに生産性が問題になる作業はしないので，不問に付してきました（時々はネット検索で解決策を探りましたが）．

今回，Debianの実マシン環境で動くKVMが必要となり，そこでFirefoxを開いて，調べたり，wikiに書き込んだりして作業を進めようとしましたが，そういう生産的😥な仕事をするには，この勝手なスクロールは著しく作業効率を落とします．というか，やる気が失せます．

そこで，真剣に検索をしてみました．日本語で検索してもだめなので，英語で検索することにして，まず「勝手に」を英語でなんていうかから調べました．それで，

Debian Firefox scrolls arbitrarily to the bottom

てな感じで検索したら，ズバリのものが見つかりました．

で，この質問者は，違うOSをインストールして解決したとあります．つまり，本当の意味での解決策はないのです😥

サブWSのメインOSであるManjaroではこのようなトラブルはもともと発生してませんから，Manjaroでやれよなってことです．

追記: ESRも本家もだめ

ふと，これはDebianにバンドルされているFiref0x-ESRの問題で，本家からダウンロードしたものは大丈夫なのではと思い，試してみましたが，同じでした😥

追記2: Chromiumもだめ

また，ふと思いついて，Chromiumをイントールして，試してみました．同じです😥 どうしたものか，最後までスクロールしていき，落ち着くまで操作できません．

この2つのテストにより，ブラウザーが悪いのではなく，GUI・デスクトップに何らかの問題があるといえそうです．

DebianのサブOSと同じKDE Plasma Desktopを使っているメインOSのManjaroではなんの問題も起きないんだけどなあ😥

非公開の自分専用メモ．
サブWSのメインOS．

Postfixを試す (7) Avahiのbuildで難航

Postfixを試すのにAvahiが要るのか，という疑問もあるかと思いますが，筆者のLAN内ではAvahiを有効利用しているので，テストの準備などのいろんな手続きをスムーズにするためインストールすることにしました．

Slackware (64, ARM) 15.0用としてSlackBuildsにzeroconfのサーバーであるAvahi，クライアントであるnss-mdns，そしてAvahiに必要なライブラリーlibdaemonが用意されています．したがって，libdaemonからの順番で，sbopkg -iすれば，インストール完了します．実際，SlackwareARM 15.0のとあるマシンでは，そのようにして他のマシンを参照するのも，他から参照されるのもうまく機能しています．

ところがどっこい，Postfixのテスト用に仕立てたSlackware 15.0 (32bit)の仮想マシンでは，Avahiのbuildができません．gtk+2のバージョンが必要条件(>=2.14.0)を満たしていないとconfigureスクリプトが文句を言いますが，pkgtoolで確認するとちゃんと条件を満たしています(2.24.33)．エラーメッセージは的が外れているけど，なにか確かにエラーがあるに違いないです（よくあることです😥）．

うまくいったSlackwareARMと失敗したSlackware (32bit)の違いは，もちろんアーキテクチャーや，実マシン・仮想マシンの違いがありますがそれらは別にして，X, XAP, KDEをインストールしていないことです．リモートで運用・管理するのが前提なので，そもそもGUIは要りませんので，省略することによってシステムの容量を減らすことができると考えました．

しかし，これがどうもいけないようです．そもそもAvahiにGUIは関係ないと思うのですが，なんか必要なライブラリーがGUIのライブラリーと依存関係にあるとかないとかいうことでしょうか．知らんけど😥

必要最低限のライブラリーを見つけ出してインストールするというのがGUIをインストールしなかった初期の方針に沿う方法でしょうけど，時間が無駄にかかりますので，ここは諦めて，XとXAPはインストールすることにします（いくらなんでもKDEは要らんでしょう😥）．

ここも，ここまでいじってきたシステムにXとXAPを追加してインストールすればいいんですが，完成したときにクリーンインストールからの最小手順だったという形にしたいので，また箱庭を消してゼロからやります．