ubuntu覚書

私のubuntu覚書

ubuntuのアップデートに失敗していたが理由が分かった

GUIでのアップデートではわからなかったが、端末でsudo apt updateを実行した際にubuntuのサーバーへの接続がタイムアウトして失敗していた。
ubuntuの「ソフトウェアの更新」（よく似た名前のツールが多いのでわかりにくいが、アップデート環境の設定を行うツールのようだ）でダウンロードのミラーサイトを選択するところで、最適なダウンロードサイトを検索して設定すると更新が進むようになった。
要するに、ダウンロードをしようとしたミラーサイトが重かっただけのことみたい。ちなみに、新しいダウンロードのミラーサイトはrikenのサーバーだった。

.debファイルのインストール

通常はdpkg -iでインストールするようだが、これでは依存関係を調整してくれないらしい。
代りに gdebi を使うと依存関係を調整しつつインストールしてくれるらしい。

apache2の自動起動（稼働）のON・OFFについて

（※ちなみに、次の２つのコマンドは何の効果もない。後続の説明を見よ）
自動起動させたくないときは、次のコマンドで起動項目から取り除ける。
$ sudo update-rc.d -f apache2 remove
起動項目に追加したい時は、次のコマンドで
$ sudo update-rc.d apache2 defaults

と、説明されていたのでubuntu18.04の環境で自動起動を停止したつもりなのに再起動したらアパッチがしっかり稼働していた。稼働中かどうかは次のコマンドで確認した。

このコマンドは起動している全サービスを出力するが、１つずつ確認して出力するので時間がかかる。アルファベット順に出力されるので、適当にCtrl+Cで止めるのが吉。
service --status-all

そこで、再度ぐぐると次のコマンドが見つかる。

再起動　sudo systemctl restart apache2
起動　　sudo systemctl start apache2
停止　　sudo systemctl stop apache2
自動起動　sudo systemctl enable apache2
自動起動の無効化　sudo systemctl disable apache2

自動起動の無効化を実行して再起動してサービスの状況を調べてみると
[ + ] apache-htcacheclean
[ - ] apache2
apache-htcacheclean の意味は分からないが、本体のapache2は停止[-]状態だった。
停止状態で起動しているもよう。
当然、この状態から上の起動コマンドを実行すれば稼働中になる。

DVDやCDのマウント場所を確認する

コマンド　df

DVDドライブ(/de/sr0)にディスクを挿入している状態で出力すると
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sr0 3808976 3808976 0 100% /media/xxx/NAP-006

ファイルシステムのエラーで起動時に'(initramfs)_'プロンプトに落ちる

例えば、次のような感じで（/dev/xxxは対象となるファイルシステムのデバイス名）

fsck exited with status code 4
The root filesystem on /dev/xxx requires a manual fsck.

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)_

この場合、fsckがマニュアルモードを要求している状態なので次のコマンドを実行
fsck /dev/xxx

後は何度か、y('yes')でFixを選んで修正して、最後に再チェック
fsck /dev/xxxx
して
> ubu: clean, 302818/6176768 files. 3913618/24696832 blocks
というようなメッセージでればOK.

exitでinitramfsモードを抜けて再起動すれば元の状態に戻れるはず。

ubuntu 18.04の起動時不具合

grubメニューの通常起動でubuntu18.04が起動できなくなった。advanced option から起動するとリカバリーモード用であろうとなかろうと起動する。昨日までちゃんと起動できていたのに‥

【症状】
通常起動の場合、画面が暗転したまま何も表示されない。ハードディスクのアクセスランプは点滅しているので見えないだけで起動しているような気がする。Ctrl+Alt+Deleteキーを押すとちゃんと再起動もかかるのでOSが暴走しているわけでもない。

【調査】
advanced option には次の２つのカーネルのメニューがあった。
Linux 5.3.0-26-generic
Linux 5.0.0-37-generic

古いカーネルの5.0.0-37で起動するとリカバリーモードで修復作業などせずとも普通に起動できる。

現行のカーネルである5.3.0-26で起動すると古いカーネルと同様修復作業をせずとも起動できるのだが、画面の解像度が1024ｘ768だった。従来の解像度である1280ｘ1024に変更しようとしたが、変更候補は800x600しかなかった。また、nVidia x server settingを起動しても何も設定できない状態だった。

【修復作業】
ネットを調べるとディスプレイサーバーがWaylandの場合ログイン画面が表示されない場合があるのでディスプレイサーバーをxorgにするべしとの書き込みがあったが、結局Waylandは関係なかった。

もしかするとnVidiaドライバが壊れたのではないか、それで解像度も一般的な解像度しか選択できないのではないかと思い立った。

推奨されているnVidiaドライバーを確認するために次のコマンドを実行した。
ubuntu-drivers devices
（※このコマンドをubuntuノートPCで実行したが何も出力されなかった。デスクトップ機には別途グラフィックカードを挿しているが、ノートにはチップセット内蔵のグラフィック機能のみだからか？）

特に躊躇することなく、推奨されているドライバーをインストール
sudo apt install nvidia-driver-435

再起動すると通常のubuntuで起動することができた。

Ubuntu18.04の起動が遅いのでググると次のサイトを見つけた。早速やってみた。

参考サイト
http://lime-piko.blog.jp/archives/15553094.html

１．先ずは起動処理時間を調査
起動処理に８分ほどかかっているようだが、ログインしてデスクトップが表示されるまでならもっと短い。３分くらいだったような気がする。

~$ systemd-analyze

Startup finished in 5.009s (kernel) + 8min 5.341s (userspace) = 8min 10.350s
graphical.target reached after 1min 7.900s in userspace

２．オプションを付けて起動処理時間の内訳表示
参考サイトの情報と同じくアップデートの調査に多大な時間を費やしている。

~$ systemd-analyze blame | head
7min 162ms apt-daily-upgrade.service
33.043s sav-protect.service
28.269s dev-sda1.device
27.602s systemd-journal-flush.service
16.813s NetworkManager-wait-online.service
13.461s systemd-sysctl.service
9.837s snap-canonical\x2dlivepatch-94.mount
9.630s fwupd.service
8.321s snapd.service
6.526s plymouth-read-write.service

３．参考サイトの情報を元に起動時間の短縮を図る。

sudo gedit /etc/systemd/system.conf

修正前
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
修正後
DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s

４．結果
次の出力のとおり、劇的に改善

体感的にはログインしてデスクトップが表示されるまでの時間は半分くらいになった気がする。
電源を入れてログイン画面が表示されるまでの時間も体感的に短縮されているが、一番気になっていたのはログインしてデスクトップが表示されるまでの時間だった。
修正前はログインパスワードを叩いてデスクトップが表示されるまで２分近くかかっていたが
修正後は４０秒ほどに短縮された。

~$ systemd-analyze

Startup finished in 4.809s (kernel) + 1min 16.139s (userspace) = 1min 20.949s
graphical.target reached after 1min 16.020s in userspace

~$ systemd-analyze blame | head
41.033s sav-protect.service
28.846s systemd-journal-flush.service
28.214s dev-sda1.device
14.566s systemd-tmpfiles-setup-dev.service
12.450s systemd-sysctl.service
11.371s NetworkManager-wait-online.service
4.820s NetworkManager.service
4.779s snapd.seeded.service
4.637s snapd.service
4.415s dev-loop1.device

.shファイルのランチャー登録について

ubuntu18.04環境にて

スクリプトを作成して（例えば、sample.sh）実行権限の有無に関らず端末上で
sh sample.sh
で実行できるが、sample.shに実行権限をつけてダブルクリックしても、何とかが見つからないというエラーが発生して実行できない。
いちいち、端末を起動してshナンたらカンたらって打つのはとっても面倒。

ubuntuのgnomeランチャーに登録したら動作するような記事があったのでやってみた。
先ずは適当なアイコン(sample.png サイズは48x48)を作成しておいて、次のような中身の
sample.desktopファイルを作成

[Desktop Entry]
Name=サンプル
Exec=/bin/bash /path/to/sample.sh
Icon=/path/to/sample.png
Type=Application

※端末出力が必須のスクリプトの場合
Terminal=true
の１行を追加すること。

保存してファイラーでそのsample.desktopを見ると、ファイル名は「Name=サンプル」で指定したサンプルで表示される。なんだか実行サイルのようなアイコンで表示されているのでダブルクリックしてみるとちゃんと動作する。

その.desktopファイルを次のディレクトリに保存するとubuntuのランチャーに表示される。
表示名は「Name=　」で指定した名前となる。
~/.local/share/applications/

端末でタッチパッドのON/OFF

端末でタッチパッドのON/OFF

synclient TouchpadOff=0 ON
synclient TouchpadOff=1 OFF

ubuntuでGUI⇔CUIの切り替え

UbuntuのGUI画面からCUIに切り替えるのは
Ctrl+Alt+F1(～F6)

CUIから再びGUIに戻るには
Ctrl+Alt+F7

ちなみに、CUI起動後にGUIを起動する場合は
startx
※だと思う。確認してないけど

ソフトウェアセンターのリフレッシュ

ソフトウェアセンターがアップデートがあると通知してくるのでそのままアップデートしようとすると次のエラーが表示される。
snap has no updates avairable

でも、アップデートがある旨の表示が消えない。
そこで、snap-storeをリフレッシュ。

一旦、snap-storeを停止
sudo killall snap-store
そして、リフレッシュ
sudo snap refresh snap-store

再度、ソフトウェアセンターを起動するとアップデートのマークは消えていた。

ubuntuのドライバ(Nvidiaなど)を自動で適用するコマンド

sudo ubuntu-dirvers autoinstall

ヘルプを見る限り、最初に ubuntu-drivers devicesでドライバーの必要なデバイスがあるかを調べて、あれば ubuntu-drivers install xxx あたりでドライバーを適用するようだ。
上のようなautoinstallオプションは推奨されていない。
ubuntu-drivers devicesで示されたデバイスに同時に示されたパッケージを指定してinstallオプションで適用するのが正しいやり方のようだ。

ubuntu-driversコマンドのヘルプは次のとおり

Usage: ubuntu-drivers [OPTIONS] COMMAND [ARGS]...

Options:
--gpgpu gpgpu drivers
--free-only Only consider free packages
--package-list PATH Create file with list of installed packages (in install
mode)
--no-oem Do not include OEM enablement packages (these enable an
external archive) [default: False]
-h, --help Show this message and exit.

Commands:
autoinstall Deprecated, please use "install" instead
debug Print all available information and debug data about drivers.
devices Show all devices which need drivers, and which packages...
install Install a driver [driver[:version][,driver[:version]]]
list Show all driver packages which apply to the current system.
list-oem Show all OEM enablement packages which apply to this system

rsyncでファイル・ディレクトリに関する権限の問題でエラーが発生したことについて

突然、rsync(Grsyncで実行)でエラーが発生。いつものようにhomeからUSBメモリにGrsyncで同期しようとしてUSBメモリを接続した際に理由はわからないがシステムの不具合か発生してパソコンが固まった。やむなく電源ボタンの長押しで電源を落として起動し直した。

その後、USBメモリを接続してGrsyncで同期しようとすると権限問題でエラーが発生するようになった。エラーメッセージはrsyncそのものが発していた。

USBをバックアップして初期化してみたりしたが何の効果もない。
ネットで調べると権限の問題だからrsyncに管理権限での実行許可を与えればいいというような無責任な意見もあったが、今まで普通にできていたのだから他に理由があろうと思った。
そもそも、ファイルマネージャで普通にファイル操作ができるのに実行権限がないわけがないが、わからなかった。

しかし、ファイルマネージャでUSBの中を表示させて何気なくその上のディレクトリを覗いたところ何とUSBメモリのディレクトリが２つあるではないか。１つは従来のUSBメモリのボリューム名でもう１つは初期化時に新たに付けたボリューム名であった。

どうやらUSBメモリを接続したまま強制的にジャットダウンさせたためにUSBへのアクセスポイントとなるディレクトリが削除されずにそのまま残っていたようだ。その幽霊ディレクトリを管理者の権限で削除すると従来どおりrsyncが動作するようになった。

ubuntu japanese teamの日本語関連パッケージのインストールについて

１．日本語関連パッケージのインストール
ubuntu24.04以降はubuntu japanese teamの日本語Remixは提供されなくなった。24.04のインストール後、日本語の使用に特別問題があったわけではないが、念の為、ubuntu japanese teamサイトに日本語関連のパッケージをインストールするためのコマンドがあるので実行してインストールした。

２．困ったこと
そのコマンドの実行について、ホームページでは以下のように記載されている。
「
Ubuntu 24.04 LTSにUbuntu Japanese Teamのパッケージリポジトリを追加するには、以下のコマンドを実行してください。

$ sudo wget https://www.ubuntulinux.jp/sources.list.d/noble.sources -O /etc/apt/sources.list.d/ubuntu-ja.sources
$ sudo apt -U upgrade
$ sudo apt install ubuntu-defaults-ja

リポジトリ追加後、パッケージ情報の更新時に以下の警告が表示されますが、これはUbuntu 24.04 LTSから1024ビットRSAによるAPTリポジトリ署名鍵が非推奨になったことによるものです。Launchpad PPAでの再署名と鍵の更新が完了後、この警告は表示されなくなる予定です。
（警告文は省略）
」

ホームページの記載では「警告」という表現になっていますが、実際は、sudo apt -U upgradeのところでエラー終了してしまう。ubuntu japanese team もまさか更新がエラーで止まるとは思っていなかったんでしょうね。

２．解決
ググると以下のサイトで公開鍵をシステムに登録すればよいとあった。

「
https://lil.la/archives/4185
apt-get update実行時に「公開鍵を利用できないため、以下の署名は検証できませんでした」と表示されてしまったときの対処方法
」

それに従って、sudo apt -U upgrade時に出力されていた＜公開鍵コード＞をつけて以下のコマンドを実行。
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ＜公開鍵コード＞

その後、sudo apt -U upgradeを実行するとめでたく完了して、その後 ubuntu-default-jaをインストールできた。

ubuntuの定番のディレクトリ名を日本語から英語に戻す

日本語環境のubuntuでは定番のディレクトリ（ドキュメント、ダンロードなど）が日本語表示になっている。
端末で操作するときいちいち日本語を打つのがうっとおしいので、もとの英語表示に戻すコマンド。

LANG=C xdg-user-dirs-gtk-update

これを実行すると日本語表示から英語に切り替えるダイアログが表示されるので、更新（update）して終了する。

その後、再起動すると、今度は英語表示を日本語にしないかと確認するダイアログが表示されるので、
「次回から表示しない」にチェックを入れて、「古い名前のままにする」をクリック。

私のubuntu覚書
python覚書 ubuntu覚書 php覚書コマンド覚書その他の覚書
1	ubuntuのアップデートに失敗していたが理由が分かった GUIでのアップデートではわからなかったが、端末でsudo apt updateを実行した際にubuntuのサーバーへの接続がタイムアウトして失敗していた。 ubuntuの「ソフトウェアの更新」（よく似た名前のツールが多いのでわかりにくいが、アップデート環境の設定を行うツールのようだ）でダウンロードのミラーサイトを選択するところで、最適なダウンロードサイトを検索して設定すると更新が進むようになった。要するに、ダウンロードをしようとしたミラーサイトが重かっただけのことみたい。ちなみに、新しいダウンロードのミラーサイトはrikenのサーバーだった。
2	.debファイルのインストール通常はdpkg -iでインストールするようだが、これでは依存関係を調整してくれないらしい。代りに gdebi を使うと依存関係を調整しつつインストールしてくれるらしい。
3	apache2の自動起動（稼働）のON・OFFについて（※ちなみに、次の２つのコマンドは何の効果もない。後続の説明を見よ）自動起動させたくないときは、次のコマンドで起動項目から取り除ける。 $ sudo update-rc.d -f apache2 remove 起動項目に追加したい時は、次のコマンドで $ sudo update-rc.d apache2 defaults と、説明されていたのでubuntu18.04の環境で自動起動を停止したつもりなのに再起動したらアパッチがしっかり稼働していた。稼働中かどうかは次のコマンドで確認した。このコマンドは起動している全サービスを出力するが、１つずつ確認して出力するので時間がかかる。アルファベット順に出力されるので、適当にCtrl+Cで止めるのが吉。 service --status-all そこで、再度ぐぐると次のコマンドが見つかる。再起動　sudo systemctl restart apache2 起動　　sudo systemctl start apache2 停止　　sudo systemctl stop apache2 自動起動　sudo systemctl enable apache2 自動起動の無効化　sudo systemctl disable apache2 自動起動の無効化を実行して再起動してサービスの状況を調べてみると [ + ] apache-htcacheclean [ - ] apache2 apache-htcacheclean の意味は分からないが、本体のapache2は停止[-]状態だった。停止状態で起動しているもよう。当然、この状態から上の起動コマンドを実行すれば稼働中になる。
4	DVDやCDのマウント場所を確認するコマンド　df DVDドライブ(/de/sr0)にディスクを挿入している状態で出力すると Filesystem 1K-blocks Used Available Use% Mounted on /dev/sr0 3808976 3808976 0 100% /media/xxx/NAP-006
5	ファイルシステムのエラーで起動時に'(initramfs)_'プロンプトに落ちる例えば、次のような感じで（/dev/xxxは対象となるファイルシステムのデバイス名） fsck exited with status code 4 The root filesystem on /dev/xxx requires a manual fsck. BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs)_ この場合、fsckがマニュアルモードを要求している状態なので次のコマンドを実行 fsck /dev/xxx 後は何度か、y('yes')でFixを選んで修正して、最後に再チェック fsck /dev/xxxx して > ubu: clean, 302818/6176768 files. 3913618/24696832 blocks というようなメッセージでればOK. exitでinitramfsモードを抜けて再起動すれば元の状態に戻れるはず。
6	ubuntu 18.04の起動時不具合 grubメニューの通常起動でubuntu18.04が起動できなくなった。advanced option から起動するとリカバリーモード用であろうとなかろうと起動する。昨日までちゃんと起動できていたのに‥ 【症状】通常起動の場合、画面が暗転したまま何も表示されない。ハードディスクのアクセスランプは点滅しているので見えないだけで起動しているような気がする。Ctrl+Alt+Deleteキーを押すとちゃんと再起動もかかるのでOSが暴走しているわけでもない。【調査】 advanced option には次の２つのカーネルのメニューがあった。 Linux 5.3.0-26-generic Linux 5.0.0-37-generic 古いカーネルの5.0.0-37で起動するとリカバリーモードで修復作業などせずとも普通に起動できる。現行のカーネルである5.3.0-26で起動すると古いカーネルと同様修復作業をせずとも起動できるのだが、画面の解像度が1024ｘ768だった。従来の解像度である1280ｘ1024に変更しようとしたが、変更候補は800x600しかなかった。また、nVidia x server settingを起動しても何も設定できない状態だった。【修復作業】ネットを調べるとディスプレイサーバーがWaylandの場合ログイン画面が表示されない場合があるのでディスプレイサーバーをxorgにするべしとの書き込みがあったが、結局Waylandは関係なかった。もしかするとnVidiaドライバが壊れたのではないか、それで解像度も一般的な解像度しか選択できないのではないかと思い立った。推奨されているnVidiaドライバーを確認するために次のコマンドを実行した。 ubuntu-drivers devices （※このコマンドをubuntuノートPCで実行したが何も出力されなかった。デスクトップ機には別途グラフィックカードを挿しているが、ノートにはチップセット内蔵のグラフィック機能のみだからか？）特に躊躇することなく、推奨されているドライバーをインストール sudo apt install nvidia-driver-435 再起動すると通常のubuntuで起動することができた。
7	Ubuntu18.04の起動が遅いのでググると次のサイトを見つけた。早速やってみた。参考サイト http://lime-piko.blog.jp/archives/15553094.html １．先ずは起動処理時間を調査起動処理に８分ほどかかっているようだが、ログインしてデスクトップが表示されるまでならもっと短い。３分くらいだったような気がする。 ~$ systemd-analyze Startup finished in 5.009s (kernel) + 8min 5.341s (userspace) = 8min 10.350s graphical.target reached after 1min 7.900s in userspace ２．オプションを付けて起動処理時間の内訳表示参考サイトの情報と同じくアップデートの調査に多大な時間を費やしている。 ~$ systemd-analyze blame \| head 7min 162ms apt-daily-upgrade.service 33.043s sav-protect.service 28.269s dev-sda1.device 27.602s systemd-journal-flush.service 16.813s NetworkManager-wait-online.service 13.461s systemd-sysctl.service 9.837s snap-canonical\x2dlivepatch-94.mount 9.630s fwupd.service 8.321s snapd.service 6.526s plymouth-read-write.service ３．参考サイトの情報を元に起動時間の短縮を図る。 sudo gedit /etc/systemd/system.conf 修正前 #DefaultTimeoutStartSec=90s #DefaultTimeoutStopSec=90s 修正後 DefaultTimeoutStartSec=5s DefaultTimeoutStopSec=5s ４．結果次の出力のとおり、劇的に改善体感的にはログインしてデスクトップが表示されるまでの時間は半分くらいになった気がする。電源を入れてログイン画面が表示されるまでの時間も体感的に短縮されているが、一番気になっていたのはログインしてデスクトップが表示されるまでの時間だった。修正前はログインパスワードを叩いてデスクトップが表示されるまで２分近くかかっていたが修正後は４０秒ほどに短縮された。 ~$ systemd-analyze Startup finished in 4.809s (kernel) + 1min 16.139s (userspace) = 1min 20.949s graphical.target reached after 1min 16.020s in userspace ~$ systemd-analyze blame \| head 41.033s sav-protect.service 28.846s systemd-journal-flush.service 28.214s dev-sda1.device 14.566s systemd-tmpfiles-setup-dev.service 12.450s systemd-sysctl.service 11.371s NetworkManager-wait-online.service 4.820s NetworkManager.service 4.779s snapd.seeded.service 4.637s snapd.service 4.415s dev-loop1.device
8	.shファイルのランチャー登録について ubuntu18.04環境にてスクリプトを作成して（例えば、sample.sh）実行権限の有無に関らず端末上で sh sample.sh で実行できるが、sample.shに実行権限をつけてダブルクリックしても、何とかが見つからないというエラーが発生して実行できない。いちいち、端末を起動してshナンたらカンたらって打つのはとっても面倒。 ubuntuのgnomeランチャーに登録したら動作するような記事があったのでやってみた。先ずは適当なアイコン(sample.png サイズは48x48)を作成しておいて、次のような中身の sample.desktopファイルを作成 [Desktop Entry] Name=サンプル Exec=/bin/bash /path/to/sample.sh Icon=/path/to/sample.png Type=Application ※端末出力が必須のスクリプトの場合 Terminal=true の１行を追加すること。保存してファイラーでそのsample.desktopを見ると、ファイル名は「Name=サンプル」で指定したサンプルで表示される。なんだか実行サイルのようなアイコンで表示されているのでダブルクリックしてみるとちゃんと動作する。その.desktopファイルを次のディレクトリに保存するとubuntuのランチャーに表示される。表示名は「Name=　」で指定した名前となる。 ~/.local/share/applications/
9	端末でタッチパッドのON/OFF 端末でタッチパッドのON/OFF synclient TouchpadOff=0 ON synclient TouchpadOff=1 OFF
10	ubuntuでGUI⇔CUIの切り替え UbuntuのGUI画面からCUIに切り替えるのは Ctrl+Alt+F1(～F6) CUIから再びGUIに戻るには Ctrl+Alt+F7 ちなみに、CUI起動後にGUIを起動する場合は startx ※だと思う。確認してないけど
11	ソフトウェアセンターのリフレッシュソフトウェアセンターがアップデートがあると通知してくるのでそのままアップデートしようとすると次のエラーが表示される。 snap has no updates avairable でも、アップデートがある旨の表示が消えない。そこで、snap-storeをリフレッシュ。一旦、snap-storeを停止 sudo killall snap-store そして、リフレッシュ sudo snap refresh snap-store 再度、ソフトウェアセンターを起動するとアップデートのマークは消えていた。
12	ubuntuのドライバ(Nvidiaなど)を自動で適用するコマンド sudo ubuntu-dirvers autoinstall ヘルプを見る限り、最初に ubuntu-drivers devicesでドライバーの必要なデバイスがあるかを調べて、あれば ubuntu-drivers install xxx あたりでドライバーを適用するようだ。上のようなautoinstallオプションは推奨されていない。 ubuntu-drivers devicesで示されたデバイスに同時に示されたパッケージを指定してinstallオプションで適用するのが正しいやり方のようだ。 ubuntu-driversコマンドのヘルプは次のとおり Usage: ubuntu-drivers [OPTIONS] COMMAND [ARGS]... Options: --gpgpu gpgpu drivers --free-only Only consider free packages --package-list PATH Create file with list of installed packages (in install mode) --no-oem Do not include OEM enablement packages (these enable an external archive) [default: False] -h, --help Show this message and exit. Commands: autoinstall Deprecated, please use "install" instead debug Print all available information and debug data about drivers. devices Show all devices which need drivers, and which packages... install Install a driver [driver[:version][,driver[:version]]] list Show all driver packages which apply to the current system. list-oem Show all OEM enablement packages which apply to this system
13	rsyncでファイル・ディレクトリに関する権限の問題でエラーが発生したことについて突然、rsync(Grsyncで実行)でエラーが発生。いつものようにhomeからUSBメモリにGrsyncで同期しようとしてUSBメモリを接続した際に理由はわからないがシステムの不具合か発生してパソコンが固まった。やむなく電源ボタンの長押しで電源を落として起動し直した。その後、USBメモリを接続してGrsyncで同期しようとすると権限問題でエラーが発生するようになった。エラーメッセージはrsyncそのものが発していた。 USBをバックアップして初期化してみたりしたが何の効果もない。ネットで調べると権限の問題だからrsyncに管理権限での実行許可を与えればいいというような無責任な意見もあったが、今まで普通にできていたのだから他に理由があろうと思った。そもそも、ファイルマネージャで普通にファイル操作ができるのに実行権限がないわけがないが、わからなかった。しかし、ファイルマネージャでUSBの中を表示させて何気なくその上のディレクトリを覗いたところ何とUSBメモリのディレクトリが２つあるではないか。１つは従来のUSBメモリのボリューム名でもう１つは初期化時に新たに付けたボリューム名であった。どうやらUSBメモリを接続したまま強制的にジャットダウンさせたためにUSBへのアクセスポイントとなるディレクトリが削除されずにそのまま残っていたようだ。その幽霊ディレクトリを管理者の権限で削除すると従来どおりrsyncが動作するようになった。
14	ubuntu japanese teamの日本語関連パッケージのインストールについて１．日本語関連パッケージのインストール ubuntu24.04以降はubuntu japanese teamの日本語Remixは提供されなくなった。24.04のインストール後、日本語の使用に特別問題があったわけではないが、念の為、ubuntu japanese teamサイトに日本語関連のパッケージをインストールするためのコマンドがあるので実行してインストールした。２．困ったことそのコマンドの実行について、ホームページでは以下のように記載されている。「 Ubuntu 24.04 LTSにUbuntu Japanese Teamのパッケージリポジトリを追加するには、以下のコマンドを実行してください。 $ sudo wget https://www.ubuntulinux.jp/sources.list.d/noble.sources -O /etc/apt/sources.list.d/ubuntu-ja.sources $ sudo apt -U upgrade $ sudo apt install ubuntu-defaults-ja リポジトリ追加後、パッケージ情報の更新時に以下の警告が表示されますが、これはUbuntu 24.04 LTSから1024ビットRSAによるAPTリポジトリ署名鍵が非推奨になったことによるものです。Launchpad PPAでの再署名と鍵の更新が完了後、この警告は表示されなくなる予定です。（警告文は省略）」ホームページの記載では「警告」という表現になっていますが、実際は、sudo apt -U upgradeのところでエラー終了してしまう。ubuntu japanese team もまさか更新がエラーで止まるとは思っていなかったんでしょうね。２．解決ググると以下のサイトで公開鍵をシステムに登録すればよいとあった。「 https://lil.la/archives/4185 apt-get update実行時に「公開鍵を利用できないため、以下の署名は検証できませんでした」と表示されてしまったときの対処方法」それに従って、sudo apt -U upgrade時に出力されていた＜公開鍵コード＞をつけて以下のコマンドを実行。 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ＜公開鍵コード＞その後、sudo apt -U upgradeを実行するとめでたく完了して、その後 ubuntu-default-jaをインストールできた。
15	ubuntuの定番のディレクトリ名を日本語から英語に戻す日本語環境のubuntuでは定番のディレクトリ（ドキュメント、ダンロードなど）が日本語表示になっている。端末で操作するときいちいち日本語を打つのがうっとおしいので、もとの英語表示に戻すコマンド。 LANG=C xdg-user-dirs-gtk-update これを実行すると日本語表示から英語に切り替えるダイアログが表示されるので、更新（update）して終了する。その後、再起動すると、今度は英語表示を日本語にしないかと確認するダイアログが表示されるので、「次回から表示しない」にチェックを入れて、「古い名前のままにする」をクリック。