2020年08月30日

のノータッチ&熟睡バージョンアップグレード法、試していません。

以下は、ほぼgoogleの翻訳のままです。

----

次のコマンドは、プロンプトなしで
新しい安定版リリースにアップグレードします。

$ sudo do-release-upgrade -f DistUpgradeViewNonInteractive


次のコマンドは、プロンプトなしで
現在の開発リリースにアップグレードします。

$ sudo do-release-upgrade -d -f DistUpgradeViewNonInteractive

私はそれをテストしていませんが、質問が発生したときに
デフォルトのアクションを実行するだけのようです。
また、スクリプトが長時間ハングすると、
スクリプトがタイムアウトになります。

dpkg-reconfigure特定のパッケージの設定に不満がある場合は、
後で使用する必要があるかもしれませんが、
ほとんどの場合は問題ありません。

----

上は、ltsで、下は、10月リリースとか、奇数年の4月リリースを
意味しているんですかね。

ubuntuのバージョンアップグレードで、
時間の事で悩んでいながら、
検索することにアタマが行かない状態でしたが、、、。
こんど試してみたいと思います。

タイムアウトがあるんですね。この間も、そうだったのか?

情報元:
https://askubuntu.com/questions/250733/can-i-do-a-silent-or-unattended-release-upgrade



posted by ブログ開設者 at 23:17| Comment(0) | linux | このブログの読者になる | 更新情報をチェックする

ほったらかしarchlinux32のシステム更新について復習。

非公式の32ビット版archlinuxでは、
chromiumがふつうにやっていたのでは、使えなくなります。
/etc/pacman.confのarchitecture = のところを
pentium4にして、
再pacman -Syyuすると、chromium-84.0.4147.135-1.0
などがインストールされることになり、バージョンが
74台から一気に進んで、
chromiumが起動するようになります。

あとは、また pentium4にしたところを
i686にしておくのが、
平生状態と受け止めるべきでしょう。

archlinux32オフィシャル以外から、インストールする
ときは、autoではなく、i686かpentium4になっていないと、
依存パッケージインストールのときに蹴られます。

ですから、yayをインストールするため、aurから
yayのsnapshot(yay.tar.gz)を落としてきて、
解凍後に、makepkg -is をするときも、
/etc/pacman.confのarchitecture = の値は、
i686になっていないと、途中でfailedになり、
インストールを完結できないです。

粘って、archlinux32を使い続けるには、
だんだんと手間がかかるようになっていきます、ネッ!

きょうで、巡回更新の第4コーナーに近づいてきましたが、
archlinux32の更新後、再起動しましたら、lxdmで
ログインできない状態になりました。

上で復習したような、裏テクじみたことを
したことと関係があるのか、わかりませんが、
ctrl + alt + F2で、コンソール画面に出て
ログインしなおしましても、やっぱり入れずで、
どんな表示が出たかと申しますと、

英語でだったですが「8分後に、アンロックされます」だって。
システムに怪しまれたわけですね。archlinux32の
どこに、そんな機能があったのか。それとも、
lxdmの付帯機能が働いて?

しょうがないので、次の
archbang(x86_64)をシステム更新することにして、
時間を経過させました。戻ってきましたら、
言われていたとおり、ログインできました。
ふむーん、そういうものか、って勉強になりました。


posted by ブログ開設者 at 22:39| Comment(0) | linux | このブログの読者になる | 更新情報をチェックする

かつて16.04ltsに上げていたdescentos3.0.2をさらに18.04.5ltsにupgradeした結果。

♪ひとつとせ〜
cat /etc/os-proberと、cat /etc/lsb-proberの
実行結果が違うという、へんな状況が起こりました。

descetos18.04?.jpg

$ sudo -H mousepad /etc/lsb-release

というコマンドを実行し、どこかの有名社長の、
グリーン脇の土手が上手い具合に陰になっていて、
誰からも見えておらぬ、と察知できたときの
手投げ上げバンカーショットのように、、、
以下のように修正しました。
私自身は、万年下働きの立場でしたっ!

話は、例え、たとえ、です。

DISTRIB_ID=DescentOS-3.0.2
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="ubuntu 18.04.5 LTS"


catコマンドでも、同様に出ます。

♪ふたつとせ〜 
下記のような表示がログイン直後に出るように
なってしまいました。ok押せば、ログイン可能ですが、、、。

error_ioctl.jpg

意味がよく理解できませんでした。

$ sudo nano /root/.profile
#mesg n || true
test -t 0 && mesg n

$ nano ~/.profile
#mesg n
test -t 0 && mesg n

の2箇所を上記のように修正しましたら、
表示が出なくなりました。
根源的に直ったのか、どうか、判りません。

♪みっつとせ〜
上下のパネルの色がパネルのデフォルトらしき
薄いグレーに変わってしまいました。

そのぐらいですかねえ。
細かいこと言い出すと、キリがないです。

descentos3.0.2は、2013年のインストールです。
中身が18.04.5ltsになって、動作しないソフトとかは、
いまのところありません。google-chromeは、
更新時にオフィシャル以外のrepoが閉じられるのがお約束事で、
起動自体はしますが、ブログの一部が適正表示されない
などの不具合があります。古いから当然ですね。
使いたくなれば、repoの再設定をして、
最新版をインストールするまでです。

むかしむかしの、ん大生諸君。
数え歌を覚えておりますか。


posted by ブログ開設者 at 19:29| Comment(0) | linux | このブログの読者になる | 更新情報をチェックする

fedora skinsのfedora30-lxqtをfedora32にひとつ飛ばしupgradeした結果。

バージョンアップ後、起動したカーネルは、

バージョンアップ前の5.6.13-100.fc30.x86_64からだった。

/bootには、fc32のkernel-5.7.17-200.fc32.x86_64が

存在するにも拘らず、

BLSが効いていないみたいだ。


/etc/default/grubは、消失したのか、ない。


下記のコマンドを実行すると、


$ sudo os-prober

rmdir: '/var/lib/os-prober/mount' を削除できません: デバイスもしくはリソースがビジー状態です

という出力がある。


インストール後、システムのupdateすると、

kernel-5.8.4-200.fc32.x86_64が入った。


自設した/etc/default/grub:

GRUB_DEFAULT=saved

GRUB_TIMEOUT=10

GRUB_TIMEOUT_STYLE=menu

GRUB_ENABLE_BLSCFG=false

#GRUB_DISABLE_OS_PROBER=true


の内容で、

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

を実行すると、


Generating grub configuration file ...

Found linux image: /boot/vmlinuz-5.8.4-200.fc32.x86_64

Found initrd image: /boot/initramfs-5.8.4-200.fc32.x86_64.img

Found linux image: /boot/vmlinuz-5.7.17-200.fc32.x86_64

Found initrd image: /boot/initramfs-5.7.17-200.fc32.x86_64.img

Found linux image: /boot/vmlinuz-5.6.13-100.fc30.x86_64

Found initrd image: /boot/initramfs-5.6.13-100.fc30.x86_64.img

Found linux image: /boot/vmlinuz-5.1.0-rc7

Found initrd image: /boot/initramfs-5.1.0-rc7.img

Found linux image: /boot/vmlinuz-0-rescue-4700c6f3e1e742be8f93d7030ff11d89

Found initrd image: /boot/initramfs-0-rescue-4700c6f3e1e742be8f93d7030ff11d89.img

rmdir: '/var/lib/os-prober/mount' を削除できません: デバイスもしくはリソースがビジー状態です

rmdir: '/var/lib/os-prober/mount' を削除できません: デバイスもしくはリソースがビジー状態です

rmdir: '/var/lib/os-prober/mount' を削除できません: デバイスもしくはリソースがビジー状態です

rmdir: '/var/lib/os-prober/mount' を削除できません: デバイスもしくはリソースがビジー状態です

rmdir: '/var/lib/os-prober/mount' を削除できません: デバイスもしくはリソースがビジー状態です

done


grub-pcやos-proberの再インストールをして、

やり直しても、変化はないです。


os-proberの様子は、情報収集は行なっているけど、

なぜかgrub.cfgに書き込まない、という感じです。


ディスクパーティションがdosで、mbmが使えているから、

まったく影響はないですが、fedoraのgrub2でマルチブート

している場合は、ほかのosを立ち上げられないですね、

40_customなどに手書きしないかぎり。


/etc/default/grubで

GRUB_ENABLE_BLSCFG=をtrueにして

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

を実行すると、

fedora本体のカーネル情報取得表示も出ないです。

BLSのほうでカーネルが管理されるってことですね。

この辺りで、 BLSも正気を取り戻したような。


os-rober自体か、grubか、どちらかが、

それとも両方とも悪いのか、何かしらの

問題があるみたいです。それともひとつ飛ばしの

乱暴バージョンアップで、不具合が生じたのでしょうか。


試みに、、、


$ sudo rm -r /var/lib/os-prober/mount

rm: '/var/lib/os-prober/mount/lost+found' を削除できません: 関数は実装されていません


↑意味がよく判らないです。


fedora30-.32lxqt.jpg

 ※壁紙は、デフォルトではありません。


使う、ということに関しては、別段、問題ないように

感じられます。ただ、lxqtが、、、

最初軽くていいな、と思ったものでしたが、

操作性が敏感すぎるというか、コピー& ペイストなど

のマウス操作で、ミスが多く出ますね。



posted by ブログ開設者 at 11:46| Comment(0) | linux | このブログの読者になる | 更新情報をチェックする