$ chromium
/usr/lib/chromium/chromium: error while loading shared libraries: libre2.so.0: cannot open shared object file: No such file or directory
いくつかi686版archlinux32の更新をしましたが、
横並びで皆こうなりました。同等ファイルの
なりすましリンクファイルをつくれば、
ウィンドウは開き使えましたが、youtubeはだめでした。
firefoxは、動作するので、黙って待っていれば、
そのうち更新されて直るものと想われます。
2020年08月10日
ubuntu-gnome16.04ltsを、ubuntu18.04ltsにアップグレードすると。
当たり前といえば、あたり前ですが、gnomeが
デフォルトデスクトップになったubuntu18.04ltsそのまんま
になりました。ちなみに、上げるまえのubuntu-gnome16.04ltsは、
ubuntu-gnome14.04ltsからのアップグレードものです。
アップグレード終了後、再起動しましたら、
grub rescue> のプロンプトがでました。
以前、マルチブートのご法度、パーティション削除を
してしまい、パーティション番号がずれ、
隣りのパーティションのpbrにインストールしてしまった模様。
もう一度、強制的に再起動しましたら、いきなり
ubuntu18.04ltsが立ち上がり出しました。
つまりmbrのmbmも上書きされちゃいました。
mbmのos選択画面、写真に撮るのを忘れたーー。
ところが、mbmインストール後５番を選んでリブートすると、
あら不思議、消えずに付けた各ディストロの
名前が残っていました。
壁紙とアイコンだけが16.04ltsの残像。
アイコンは、ダウンロードして入れたものです。
いま見ると、あんまりよくないですね。
デスクトップの構成は、ubuntu18.04ltsのデフォルト。
縦のパネルと横向きのパネルが左上角でくっつくのは、、、。
デフォルトデスクトップになったubuntu18.04ltsそのまんま
になりました。ちなみに、上げるまえのubuntu-gnome16.04ltsは、
ubuntu-gnome14.04ltsからのアップグレードものです。
アップグレード終了後、再起動しましたら、
grub rescue> のプロンプトがでました。
以前、マルチブートのご法度、パーティション削除を
してしまい、パーティション番号がずれ、
隣りのパーティションのpbrにインストールしてしまった模様。
もう一度、強制的に再起動しましたら、いきなり
ubuntu18.04ltsが立ち上がり出しました。
つまりmbrのmbmも上書きされちゃいました。
mbmのos選択画面、写真に撮るのを忘れたーー。
ところが、mbmインストール後５番を選んでリブートすると、
あら不思議、消えずに付けた各ディストロの
名前が残っていました。
壁紙とアイコンだけが16.04ltsの残像。
アイコンは、ダウンロードして入れたものです。
いま見ると、あんまりよくないですね。
デスクトップの構成は、ubuntu18.04ltsのデフォルト。
縦のパネルと横向きのパネルが左上角でくっつくのは、、、。
grub2によるマルチブート の定番設定、引き続き効力がありました。grub2 + BLS
/etc/default/grub
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT="true"
上記の2行は、前回起動したカーネルないし、osが
選択状態で次回起動する設定ですが、BLSが加わっても、
そこは変わらずでした。
BLSの役割は、親ディストロの起動部分のみですが、
カーネルが複数あっても、前回起動したカーネルが
選ばれた状態で、次回起動します。
これ、数が多いマルチブートの場合、
けっこう大事です。巡回してシステム更新している場合、
毎回一番目に戻ってしまうと、あれ、どこまで
行ったんだっけ、となりやすいですから。
GRUB_DEFAULT=saved
の一行で効く場合もあるらしいですが、
GRUB_SAVEDEFAULT="true"の行も
あったほうが確実です。
設定を効かせるには、追記後、
update-grubないし、
grub-mkconfig -o /boot/grub/grub.cfg
を実行する必要があります。
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT="true"
上記の2行は、前回起動したカーネルないし、osが
選択状態で次回起動する設定ですが、BLSが加わっても、
そこは変わらずでした。
BLSの役割は、親ディストロの起動部分のみですが、
カーネルが複数あっても、前回起動したカーネルが
選ばれた状態で、次回起動します。
これ、数が多いマルチブートの場合、
けっこう大事です。巡回してシステム更新している場合、
毎回一番目に戻ってしまうと、あれ、どこまで
行ったんだっけ、となりやすいですから。
GRUB_DEFAULT=saved
の一行で効く場合もあるらしいですが、
GRUB_SAVEDEFAULT="true"の行も
あったほうが確実です。
設定を効かせるには、追記後、
update-grubないし、
grub-mkconfig -o /boot/grub/grub.cfg
を実行する必要があります。
CONFIG_USER_NS=y 大当たり！ fedora32workstationのカスタムカーネルビルド（コンパイル）
けさ、5.8.0のカーネルソースを、これまで後生大事に
守ってきた手持ちの軽量.configファイルに
表題にある修正を加え、再ビルドしました。
できたてホヤホヤカーネルで、
googole-chrome-stableは、--no-sandboxの
オプションなしで無事起動するようになりました。
万歳！
カーネルは、軽いほうがいいです。ビルドにかかった時間、
わずか10分ぐらいですよ。fedora32のconfigファイルでは、
一時間以上、ターミナルがぐずぐず動いていて、うんざり。
きのうの借り物.configファイルでビルドしたカーネルの一群を
削除しました。使用容量がさらに5gb減りまして、
使用部分が11gb（カーネル2）。空きが18gbに。
気分は日本晴れです。コロナで出かけられないでも、
こうやって気分を盛り立てる？と。
ディストリビューションが提供するカーネルは、皆に使って
ほしいから、できるかぎり多くのハードウェアが動作するように
ビルドされていますよね。でも、ユーザーにしてみれば、
じぶんpcにインストールした途端、そのosは、
原則どこにも行けなくるわけで、
じぶんのハード装備が過不足なく動けばよいだけ。
それ以外の要素はゴミでしかありません。
いろいろな都合上、オフィシャルのカーネルひとつは、
必要でしょうけど、いくつも抱えこむのは、
かなりの無駄な行為だと思います。 とか言って、
けっこうほったらかしの私ですが。
カーネル改革が起こってもいいと思います。
インストールしたら、動作していないモジュールが
削除される仕組みとか。 使ってなくても、
いずれ使う可能性のあるものの判断が難しい？
なんとか、いい線を考えてほしい。ビルドにかかる時間から
類推すれば、どれほど無駄を抱えているかが判るので。
google-chromeの当初の不具合は、ウィンドウ自体は
開くのですが、ネットにつながっていない状態で、
chrome://settings/すら出せないといった状態でした。
守ってきた手持ちの軽量.configファイルに
表題にある修正を加え、再ビルドしました。
できたてホヤホヤカーネルで、
googole-chrome-stableは、--no-sandboxの
オプションなしで無事起動するようになりました。
万歳！
カーネルは、軽いほうがいいです。ビルドにかかった時間、
わずか10分ぐらいですよ。fedora32のconfigファイルでは、
一時間以上、ターミナルがぐずぐず動いていて、うんざり。
きのうの借り物.configファイルでビルドしたカーネルの一群を
削除しました。使用容量がさらに5gb減りまして、
使用部分が11gb（カーネル2）。空きが18gbに。
気分は日本晴れです。コロナで出かけられないでも、
こうやって気分を盛り立てる？と。
ディストリビューションが提供するカーネルは、皆に使って
ほしいから、できるかぎり多くのハードウェアが動作するように
ビルドされていますよね。でも、ユーザーにしてみれば、
じぶんpcにインストールした途端、そのosは、
原則どこにも行けなくるわけで、
じぶんのハード装備が過不足なく動けばよいだけ。
それ以外の要素はゴミでしかありません。
いろいろな都合上、オフィシャルのカーネルひとつは、
必要でしょうけど、いくつも抱えこむのは、
かなりの無駄な行為だと思います。 とか言って、
けっこうほったらかしの私ですが。
カーネル改革が起こってもいいと思います。
インストールしたら、動作していないモジュールが
削除される仕組みとか。 使ってなくても、
いずれ使う可能性のあるものの判断が難しい？
なんとか、いい線を考えてほしい。ビルドにかかる時間から
類推すれば、どれほど無駄を抱えているかが判るので。
google-chromeの当初の不具合は、ウィンドウ自体は
開くのですが、ネットにつながっていない状態で、
chrome://settings/すら出せないといった状態でした。
これかも。sandbox対応のカーネルオプション / fedora32workstation
上は、google-chromeが--no-sandboxオプションを
付けないと起動しなかった.configファイルです。
青くなっているところが怪しい、と
gentooのディスカッションフォーラムの記事に
ありました。CONFIG_PID_NS=y CONFIG_NET_NS=y も
必要ですが、CONFIG_USER_NS=yも必要らしい？
明日にでも、再々ビルドに挑戦し、
確かめるしかないです。
作った5.8.0のカスタムカーネルに穴。fedora32workstation
stableの最新linux kernelのソースを使ってビルドし、
動作したまではよかったのですが、、、。使った
config ファイルは、以前からカーネルを超軽量化するために
最小限のモジュールだけにとどめた特製のものです。
pt3が動き、あとは過不足なく機能を果たせばいい
というconfigファイルなのですが、
google-chromeが、--no-sandboxのオプションを
付けないと適正起動しません。stable版でしたが、
unstable版にしても、beta版にしても結果は同じで、
chromiumにしても改善しませんでした。
fedora32のインストールから、ひとつバージョンが上がっての
5.7.12のデフォルトカーネルでの起動に切り替えたら、
--no-sandboxなしでgoogle-chromeは起動しちゃいました。
つまり、カーネルが原因ってことですよね。
検索しても、google-chromeのsandboxを成立させる
カーネルオプションがなんであるかなんて、判りません。
しょうがないので、デフォルトカーネルの
configファイルを拝借し、pt3のオプションだけ加えて、
5.8.0のソースで再ビルドしました。
おそらくは、10倍以上のそのほとんどが要らないモジュールが
生成されちゃったんだと思います。時間もずいぶんかかりました。
全体で30gbのディスク容量ギリギリになっちゃって、危なかったです。
ひとつ下のデフォルトのカーネルを削除したり、
いまビルドに使ったばかりのソースを速攻捨てたりして、
13gbの空きをつくり、ようやく正常起動するように
なりました。カーネルのビルドって、
想像以上に場所を食いますね。
デフォルトカーネルのアップデートを知らせてきたら、
デフォルト筋のカーネルは捨てるしかないかもしれません。
パーティション容量は、マルチブートなので、
増やすのは現実的じゃないです。後ろのパーティションの前を
動かせば、そのパーティションのpbrは破壊されます。
カスタムカーネルだけにするしかなのかも。
デフォルトカーネルが立ち上がっている環境で、
ビルドしないといけないものは、もうないですし、
5.8.0が古くなるまでには、時間もそれなりにあり、
ま、いいか、ってところです。
それにしても、sandboxを成立させているのは、
カーネル付帯の機能の何なのかを知りたいですっ！！
どういう調べ方をすると判るんですかね。
firefoxは、問題なく使えていたから、
google-chromeにこだわらなければ、
よかったのですが、起動しないとなると、
解決したくなるサガがうづきました。
動作したまではよかったのですが、、、。使った
config ファイルは、以前からカーネルを超軽量化するために
最小限のモジュールだけにとどめた特製のものです。
pt3が動き、あとは過不足なく機能を果たせばいい
というconfigファイルなのですが、
google-chromeが、--no-sandboxのオプションを
付けないと適正起動しません。stable版でしたが、
unstable版にしても、beta版にしても結果は同じで、
chromiumにしても改善しませんでした。
fedora32のインストールから、ひとつバージョンが上がっての
5.7.12のデフォルトカーネルでの起動に切り替えたら、
--no-sandboxなしでgoogle-chromeは起動しちゃいました。
つまり、カーネルが原因ってことですよね。
検索しても、google-chromeのsandboxを成立させる
カーネルオプションがなんであるかなんて、判りません。
しょうがないので、デフォルトカーネルの
configファイルを拝借し、pt3のオプションだけ加えて、
5.8.0のソースで再ビルドしました。
おそらくは、10倍以上のそのほとんどが要らないモジュールが
生成されちゃったんだと思います。時間もずいぶんかかりました。
全体で30gbのディスク容量ギリギリになっちゃって、危なかったです。
ひとつ下のデフォルトのカーネルを削除したり、
いまビルドに使ったばかりのソースを速攻捨てたりして、
13gbの空きをつくり、ようやく正常起動するように
なりました。カーネルのビルドって、
想像以上に場所を食いますね。
デフォルトカーネルのアップデートを知らせてきたら、
デフォルト筋のカーネルは捨てるしかないかもしれません。
パーティション容量は、マルチブートなので、
増やすのは現実的じゃないです。後ろのパーティションの前を
動かせば、そのパーティションのpbrは破壊されます。
カスタムカーネルだけにするしかなのかも。
デフォルトカーネルが立ち上がっている環境で、
ビルドしないといけないものは、もうないですし、
5.8.0が古くなるまでには、時間もそれなりにあり、
ま、いいか、ってところです。
それにしても、sandboxを成立させているのは、
カーネル付帯の機能の何なのかを知りたいですっ！！
どういう調べ方をすると判るんですかね。
firefoxは、問題なく使えていたから、
google-chromeにこだわらなければ、
よかったのですが、起動しないとなると、
解決したくなるサガがうづきました。
