ときには古いlxleのように。lxle-18043-64beta

スマホに充電ケーブルをつけたような
小ぶりのconkyがトレードマークだったのは、もうだいぶ以前。
積んであるどれかのhddに、
古いlxleがあるはずですが、掘り当てて
設定ファイルを持ってくる元気はありませんでした。
代わりにこのごろ使っている設定ファイルで
かつて入っていた同じ位置に入れました。

壁紙の自動変更ができると思っていた（勘違いしていた？）
nitrogenで上手くできなかったので、varietyという表示ソフトを
入れました。

壁紙のダウンロード付きのソフトで、
デフォルトのままだと、自動で画像をがんがんダウンロードする
みたいです。危ないといえば、ま、危ないかな。
それを止めて、lxleの壁紙100枚を表示するように、
設定しました。パスは、~/Pictures/Wallpapers

壁紙の写真は、相変わらずアメリカンなものが多いです。
「ナショナルジオグラフィック」的モード。
カリフォルニアの乾いた風で
印刷後のインクを即乾させたような色味。


「自動起動」にチェックが入っていないのは、
先にlxdeの推奨方法で自動起動設定していたためです。





ご心配のごとく、右上が白っぽい壁紙になった場合は、
conkyの表示が見えなくなります。
arcolinuxなんかでも、同じことが起こりますが、
壁紙の色を感知して、conkyの表示色を
自動的に変えるプログラムは
まだ開発されていないみたいです。
どなたか、やってやろうじゃないか、の方、居られませんか？
独立してできず、conky側の仕事なんでしょうかね。

virtualboxの現状。archlinux＆debian&ubuntu

前提条件
ryzen 3 2200g + tb350-btc + memory8gb✕2枚

archlinux（具体的にはarchbang-0608）は、
ホストパッケージにvirtualbox-6.0以降しか
使えません。よって、それだけでの検証になります。
ゲストのフルスクリーン時に、
mini-toolbarが出ない、という以外は、
すべて正常です。

ただし、ゲストosにguest addisionsの導入以前は、
設定、ディスプレーの項目の、
グラフィッsっクスコントローラーの値がデフォルトの「VMSVGA」に
なったまま、起動するとエラーになり。システム起動できません。
「VBoxVGA」か、「VBoxSVGA」に選択し直し、
起動すると、ゲストosが起動します。

guest additionsを導入後、「VMSVGA」に戻して、
起動すると、guest osは、適正に起動、動作します。
何が適正でなかったか、は、
ソフトウェアのウィンドウをドラッグすると
残像は残らないがスムーズではない、
というようなことです。
現時点で、virtualbox hostのバージョンは、6.0.10。

次に、debianをホストにしたときの動作ですが、、、
具体的には、debian(buster）のlxqtになります。
virtualbox-6.0.10では、うまく動作しません。
グラフィックの動作、具体的には、さっきと同じ
ウィンドウのドラッグがスムーズではありません。

ホスト側を5.2.32にして、extension packを入れ、
ゲストosのguest additonsも5.2.32にすれば、
すべて上手く動作するようになります。
lxqtのデスクトップのパネル出遅れ問題も、
システム更新しているうちに治りました。

次にubuntuをホストにした場合ですが、、、
具体的には、xubuntu18.04.3ltsですが、
virtualbox-6.0.10では、debian（buster)と同様の状態で、
使えないです。オフィシャルrepoで入れられる
ようになった5.2.32では、使用上の問題はないですが、
突然、ホスト＆ゲストもろともフリーズが起こります。
ホストとゲストのメモリ配分をあれこれ変えても、
起こることを防げませんでした。

あと、大所としては、rpmパッケージを使う
ディスりビューションになりますけど、
amd環境ではまったく試していませんので、
お答えできません。

fedoraでは、サポート期間が短すぎますし、
やるならcentosでぐらいでしょうかね。
パーティション利用の都合上、すぐに試すのは、
ちょっとむずかしいです。試す機会がありましたら、
またご報告します。

いまのところ、じぶんが試した中で
virutualbox(host)-6.0.ｘがまともに動くのは、
archlinuxでだけです。

ネット検索では、あまり問題が出ていないみたいですし、
intelのハード環境では、上記のような問題は
起こっていないのかもしれません。

きょうの学び：パーティションの前を動かしてもOK。uefi +gpt

dos（mbr）方式では、絶対に駄目だった、
ルートパーティションの前を動かすと、
システムが起動しなくなる件、uefi +gptでなら、
問題なしでした。

じつは、xubuntuをホストにした場合の、
ホスト＆ゲストもろともフリーズがどうしても
直せずにいました。debian10(lxqt)が、
デスクトップのパネルが出るのが遅いという問題は残るものの、
それ以外は改善されてきたので、virtualboxの
ホスト側がxubuntuと同じバージョン(5.2.32)でもあることだし、
ってことで、xubuntu上、ゲストでインストールした
archbangの1808、MX-18.3、netrunner-desktop-1908のファイルを
debian10(lxqt)の/home/user/VirtualBox VMsに移しました。

ゲストosの動作はまったく問題なかったです。ただ、そのため
debain10(lxqt)のパーティションに余裕がなくなりました。
efiシステムパーティションを覗いて、
３つ目のパーティションに入っている
xububuntuを捨てるのも惜しくなり、そのパーティションの
後ろを伸長し、前を修正前と同じサイズになるよう後に寄せたあと、
debian10(lxqt)の入っている２つ目の
パーティションを空いたスペース分拡張しました。

uefi+gptでは、pbr（パーティションツールには出ない、
パーティションのあたまの部分）を使わないことは、
わかっていましたので、やってみましたら、
思惑通り上手くいきました。パーティションの前を
後ろに動かした3つ目のパーティションに入っている
xubuntuは、起動不能に陥ることなく元気に起動してくれました。

これは、dosパーティションでは、禁じ手と
思ったほうが無難な操作です。後ろは動かしても、大丈夫ですが。
前は動かしては、通常はだめです。
chrootから、pbrへのブートローダーの再インストールをすれば、
システム起動するのかもしれませんが、
ま、やめておくべきでしょう。
つまり、あれこれシステムが入っている、
マルチブートのdosパーティションのhddでは、
困ったからといって、パーティションに挟まれた
途中のパーティションを拡張することはできない
と心得るべきだと思います。

ちなみに、すべての操作は、uefi起動のliveメディアに入っている
gpartedを使って行いました。
パーティションの前を動かすと、データの移動が伴うので、
時間がかかります。ただ今回は、gpartedも性能が上がっているのか、
意外と早かったですね。10gmぐらいを動かすのに、30分ほどでした。

以下は、変更操作後の状態です。debianのパーティションを
200gbほどにすることに成功しました。

このスクリーンショットは、作業後テストで
起動したxubuntuから取ったものです。

xubuntu18.04.3ltsを捨てるのが惜しくなった理由は、
オフィシャルrepoでvirtualbox-6.0以降になれば、
問題が改善されるかも、という
淡い期待が湧いてきたからでした。またいちからインストール
するのも面倒ですからね。