ラベル Arch Linux の投稿を表示しています。 すべての投稿を表示
ラベル Arch Linux の投稿を表示しています。 すべての投稿を表示

2021年8月17日火曜日

【GNOME】Conkyが自動起動しなくなった時の対処法

Conkyが自動起動しなくなった
以前のアップデートで、Conkyが自動起動しなくなっていた。ほっておけば治るかと思っていたが、そうもいかず。設定ファイルをいじってみたら、Conkyの起動までの待機(ポーズ)の時間が短かったことが原因だと分かった。

これまで、問題なくConkyは起動していたので、何かアップデートの際に問題が起きた可能性が高い。2021年6月に、デスクトップ環境がGNOME 40にアップデートしており、アップデートにより起動時のGNOME初期画面が変わったことが影響している気がする。

この記事では、Conkyが自動起動しなくなった原因と、その対処法について解説する。


2020年12月6日日曜日

CUPSのアップデートによりArch Linuxで印刷できなくなった時の対処法

CUPSのアップデートによりArch Linuxで印刷できなくなった
最近のCUPSのアップデートによりsystemdのサービス(デーモン)の名前が変更された。この名前の変更により、CUPSサービスの自動起動の再設定が必要となった。

もし、最近のArch Linuxのアップデート後に、プリンターが認識されなくなり印刷ができなくなった場合は、このアップデートが原因の可能性が高い。

この記事では、CUPSのアップデート後にすべき、CUPSのサービスの自動起動の再設定方法について解説する。印刷時にプロプライエタリなドライバを使用し、CUPSを使用していない環境では今回の対応は不要。


2020年4月29日水曜日

Arch Linuxでgconfとpygtkをアンインストールする方法

Arch Linuxでgconfとpygtkをアンインストール
AURのパッケージをaurmanからアップデートしようとしたところ、今までインストールされていなかったパッケージが追加でインストールされるメッセージが出てきた。

このような場合は、今まで使っていたパッケージが公式リポジトリからAURへ移動しており、そのリポジトリの移動に伴って追加のパッケージインストールが発生するケースが多い。

公式リポジトリからAURへ移動したパッケージは、他のパッケージから必要とされなくなっていることがほとんどなので、多くの場合アンインストールしてしまって問題ない。

今回のケースも、gconfとpygtkがAURに移動しておりaurmanのアップデート対象パッケージとなっていたが、必要ないパッケージとなっていたのでアンインストールすることとした。


2020年4月16日木曜日

pacmanのアップデートでp11-kit-trust.so exists in filesystemのエラーが発生した時の対処法

pacmanのアップデートでp11-kit-trust.so exists in filesystemのエラーが発生
pacmanでArch Linuxのパッケージをアップデートしようとしたら、conflicting filesのエラーが発生してアップデートができなくなっていた。

# pacman -Syu
:: Synchronizing package databases...
...
error: failed to commit transaction (conflicting files)
nss: /usr/lib/p11-kit-trust.so exists in filesystem
Errors occurred, no packages were upgraded.

Arch Linuxの公式ページを確認すると、nss>=3.51.1-1、lib32-nss>=3.51.1-1がアップデートファイルに含まれる場合、pacmanのオプション追加が必要とのこと。この記事では、このエラーの対処法についてまとめておく。


2019年12月31日火曜日

Arch Linuxでunable to lock databaseエラーが出てアップデートできない時の対処法

Arch Linuxでunable to lock databaseエラーが出てアップデートできない
Arch Linuxのアップデート中にパソコンがフリーズしたため、パソコンを強制終了してしまった。その後、パソコンを起動させると問題なく使えたが、pacmanのアップデートができなくなっていた。

「unable to lock database」というエラーが出て、アップデートがエラー終了してしまう状態になった。

この記事では、Arch Linuxで「unable to lock database」のエラーにより、アップデートできない時の対処法についてまとめておく。


Linuxでキーボードレイアウトが日本語配列にならない時の対処法

Linuxでキーボードレイアウトが日本語配列にならない
Linuxのインストールした直後や、ソフトウェアアップデートをした直後にキーボードレイアウトが英語キーボードの配列になってしまい、日本語のレイアウトにできないことがある。

Linuxのキーボードレイアウトの設定は、様々なソフトウェアが関与しているので設定がややこしい。さらに最近は、XorgからWaylandにウィンドウサーバーが変更されており、昔と設定方法が変わってきている。

かく言う私も、Linuxのアップデート後にキーボードレイアウトが日本語にならないトラブルに何度もあっており、最近もそのトラブルにあった。トラブル解決のために色々と調べてみて、分かったことを記事にしようと思う。

この記事では、Linux環境でキーボードレイアウトを日本語にする際にチェックするポイントをまとめておく。


2019年11月23日土曜日

Arch Linuxでaurmanが使えなくなった時の対処法

Arch Linuxでaurmanが使えなくなった時の対処法
パッケージアップデートをしてた後に、aurmanが使えなくなっていた。調べてみたら、aurmanを再インストールすれば解決することが分かった。

この記事では、パッケージアップデート後のaurmanのエラーの症状と、その解決方法についてまとめておく。


2019年10月21日月曜日

Arch LinuxでQt 4.xをアンインストールする

Arch LinuxでQt 4.xをアンインストール
少し前になるが、Qt 4.xのパッケージがAURに移動された。Qt 5.xが開発されたため、Qt 4.xを必要とするパッケージはほとんど無いためアンインストールすることにした。

Qt 4.xをアンインストールすることにした経緯について説明しておく。以前、AURパッケージをアップデートした時に、異様に時間がかかることに気が付き、この原因となっているのがQt 4.xのアップデートであることに気がついた。
(AURのパッケージをインストールしたりアップデートしたりすると、多くのパッケージがソースからビルドするようになっている。したがって、Qtパッケージのような巨大なパッケージだと、アップデートにとても時間がかかる。)

AURパッケージのアップデートで、毎回こんなに時間を取られてしまうと、面倒なのでいっそのことQt 4.xパッケージをアンインストールすることにした。この記事では、Qt 4.xのアンインストール方法についてまとめておく。


Arch Linuxをインストールする時の必須パッケージとして、新たにbaseパッケージが導入

Arch Linuxをインストールする時の必須パッケージとして、baseパッケージが導入された
最近、Arch LinuxのCoreリポジトリに「baseパッケージ」が導入された。Arch Linuxをインストールする際に、ほとんどの人が「base」をインストールしていると思う。

しかし、今回新たにリポジトリに登録された「baseパッケージ」と、2019年10月5日以前にインストールされた「base」は中身が異なっている。

今回の「base」の変更に伴い、色々と注意すべき点があるので、その注意点についてまとめておく。


2018年12月30日日曜日

LibreOfficeを使ってLinuxで年賀状作成

LibreOfficeを使ってLinuxで年賀状作成
LibreOfficeを使ってLinuxで年賀状を書いていて、今年で4年目。毎年、印刷ができなかったり、表示がずれたり何かしらトラブルは起きてしまう。

1年に1回の行事なので、毎年1年前の記憶を呼び起こしつつ、年末にトラブルの対処法を模索するのも恒例になってきた(笑)

毎回なんとか試行錯誤してトラブルも解決できて、対処法も分かってきた。ここで、トラブルの対処法も含めて、LibreOfficeを使ってLinuxで年賀状を書く方法を記事にまとめておこうと思う。


2018年8月18日土曜日

開発停止されたyaourt, packerをアンインストールして代替のAURヘルパーに移行する方法

AURヘルパーのyaourt, packerは開発停止されている
これまでArch LinuxのAURヘルパーとしてyaourtやpackerを使ってきたが、いずれのヘルパーも開発が停止されている。最近は、yaourtやpackerは時代遅れで、他の新しいAURヘルパーが使われるようになっているらしい。

気づいたきっかけは、pacmanのパッケージアップデートで以下のようなエラーが出たため。
# pacman -Syu

:: Synchronizing package databases...
 core                                 131.7 KiB   450K/s 00:00 [##################################] 100%
 extra                               1686.6 KiB   725K/s 00:02 [##################################] 100%
 community                              4.4 MiB  2.47M/s 00:02 [##################################] 100%
 archlinuxfr is up to date
:: Starting full system upgrade...
warning: packer: local (20150808-1) is newer than community (1.2.5-1)
resolving dependencies...
looking for conflicting packages...
...

これまで使ってきたpackerはAURからインストールしたパッケージ。「packer: local (20150808-1) is newer than community (1.2.5-1)」というエラーを最初に見た時は、packerがArch Linux公式のcommunityリポジトリに登録されたのかと勘違いした。

communityリポジトリに登録されたpackerに切り替えようと思い、下調べしてみるとどうやらcommunityに登録されたpackerはAURヘルパーではない、全く別のソフトウェアだった。

pacmanのパッケージアップデートで、同じように「packer: local (20150808-1) is newer than community (1.2.5-1)」のエラーが出ている人は勘違いしないでほしい。


AURヘルパーaurmanのインストール方法と使い方

AURヘルパーaurmanのインストール方法と使い方
これまでArch LinuxのAURヘルパーとしてyaourtやpackerを使ってきたが、どちらのヘルパーも開発停止されている(ちなみに、pacaurも開発中止)。そこで、現在も開発が継続されている新しいAURヘルパーのaurmanをインストールすることにした。

aurmanのインストール方法の紹介の前に、aurmanの特徴をまとめておく。
  • pacmanと同じオプション、似た文法で使える。
  • パッケージの依存関係やコンフリクトの確認を行える。また、パッケージの分割もできる。
  • AURパッケージの検索が行える。
  • AURパッケージのビルドの前に、PKGBUILDファイルの確認と編集ができる。

この記事に、aurmanのインストール方法と簡単な使い方をまとめておく。


2018年7月28日土曜日

pacmanのmirrorlistのftp.tsukuba.wide.ad.jpでエラーが発生

pacmanのmirrorlistのftp.tsukuba.wide.ad.jpでエラーが発生
最近pacmanでパッケージアップデートをする際、ftp.tsukuba.wide.ad.jpのサーバーでエラーが発生するようになっていた。

発生するエラーは以下の通り。The requested URL returned error: 503のエラーが発生。
# pacman -Syu

:: Synchronizing package databases...
error: failed retrieving file 'core.db' from ftp.tsukuba.wide.ad.jp : The requested URL returned error: 503
 core                                 131.9 KiB   139K/s 00:01 [##################################] 100%
error: failed retrieving file 'extra.db' from ftp.tsukuba.wide.ad.jp : The requested URL returned error: 503
 extra                               1652.3 KiB  1033K/s 00:02 [##################################] 100%
error: failed retrieving file 'community.db' from ftp.tsukuba.wide.ad.jp : The requested URL returned error: 503
 community                              4.5 MiB   806K/s 00:06 [##################################] 100%
 archlinuxfr                           12.8 KiB  45.1K/s 00:00 [##################################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (34) chromium-68.0.3440.75-1  curl-7.61.0-2  eog-3.28.3-1  fuse-common-3.2.4-2  grilo-0.3.6-1
...

ftp.tsukuba.wide.ad.jpのサーバーの状況を確認してみたら、やはり最近エラーが多く発生していることが分かった。なので、pacmanのmirrorlist上で、ftp.tsukuba.wide.ad.jp以外のサーバーを優先することにした。


2018年7月22日日曜日

pacmanでアップデート後にArch LinuxがEmergency modeで起動するようになった時の対処法(その2)

pacmanでアップデート後にEmergency modeで起動するようになった
先日、pacmanでアップデート後にArch LinuxがEmergency modeで起動するようになってしまったことを記事にした。

2018年7月16日
pacmanでアップデート後にEmergency modeで起動するようになった時の対処法 | 普段使いのArch Linux

上のページでは、pacmanでアップデートしたlvm2 (バージョン2.02.179-1) が悪さをしており、lvm2-2.02.179-1のバージョンからlvm2-2.02.177-5にダウングレードすれば、Arch LinuxがEmergency modeで起動する不具合を応急処置的には解決できることについて、記事にしていた。

先日、不具合があったlvm2-2.02.179-1の次のバージョンのlvm2-2.02.180-1がリリースされ、そのバージョンにlvm2をアップデートすることで、Arch LinuxがEmergency modeで起動してしまう不具合を完全に解決できるようになった。そのことについて、記事にしておく。


2018年7月16日月曜日

pacmanのアップデートでlibutf8proc: /usr/lib/libutf8proc.so.2 exists in filesystemのエラーが発生する時の対処法

pacmanのアップデートでlibutf8proc: /usr/lib/libutf8proc.so.2 exists in filesystemのエラーが発生
pacmanでArch Linuxのパッケージをアップデートしようとしたら、以下のエラーが発生してアップデートができなかった。
# pacman -Syu

:: Synchronizing package databases...
 core                                 130.7 KiB   934K/s 00:00 [##################################] 100%
 extra                               1642.0 KiB  3.27M/s 00:00 [##################################] 100%
 community                              4.5 MiB  6.44M/s 00:01 [##################################] 100%
...
error: failed to commit transaction (conflicting files)
libutf8proc: /usr/lib/libutf8proc.so.2 exists in filesystem
Errors occurred, no packages were upgraded.

libutf8procのパッケージが、/usr/lib/libutf8proc.so.2のファイルとコンフリクトしてアップデートできない状態になってしまっている。

この記事では、このエラーを解消する方法についてまとめておく。


pacmanでアップデート後にEmergency modeで起動するようになった時の対処法

2018年7月22日 更新
lvm2のバージョンアップで問題は完全に解決した。その内容を以下の記事にまとめてあるので、そちらを参考にしてほしい。

2018年7月22日
pacmanでアップデート後にArchl LinuxがEmergency modeで起動するようになった時の対処法(その2) | 普段使いのArch Linux

以下の記事は、古い内容。

pacmanでアップデート後にEmergency modeで起動するようになった
先日pacmanでパッケージのアップデートをした後、PCの電源を入れ直すとArch LinuxがEmergency modeで起動するようになってしまった。
You are in emergency mode. After logging in, type "journalctl -xb" to view 
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" 
to boot into default mode.

一旦、ルートパスワードを入力してEmergency modeに入った後、exitコマンドでEmergency modeを抜け出すと普通にGDMが起動してGNOMEのデスクトップ環境に入ることはできた。

問題なくデスクトップ環境が起動することを考えると大きな問題でもないはずだが、どうにか修理してEmergency modeが起動しないようにできないか調べてみた。

調べてみたところ、新しいバージョンのlvm2が悪さをしているらしく、lvm2をダウングレードするとで解決することが分かった。その詳細を記事にまとめておこうと思う。


2018年6月3日日曜日

pacmanのアップデートでffmpeg2.8: installing x265 (2.8-1) breaks dependency 'libx265.so=151-64'のエラーが発生する時の対処法

pacmanのアップデートでffmpeg2.8: installing x265 (2.8-1) breaks dependency 'libx265.so=151-64'のエラーが発生
pacmanでArch Linuxのアップデートをしたら、以下のエラーが発生してアップデートができなかった。

# pacman -Syu

:: Synchronizing package databases...
 core is up to date
 extra                               1620.4 KiB   636K/s 00:03 [##################################] 100%
 community                              4.4 MiB   954K/s 00:05 [##################################] 100%
 archlinuxfr is up to date
:: Starting full system upgrade...
:: Replace pkg-config with core/pkgconf? [Y/n] 
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: ffmpeg2.8: installing x265 (2.8-1) breaks dependency 'libx265.so=151-64'

ffmpeg2.8のパッケージがx265 (2.8-1) とコンフリクトして、x265のアップデートができなくなっている。

2018年5月9日水曜日

pacmanでアップデートをするとjs52: /usr/lib/libmozjs-52.so.0 exists in filesystemのエラーが発生する時の対処法

pacmanでアップデートをするとjs52: /usr/lib/libmozjs-52.so.0 exists in filesystemのエラーが発生
pacmanのアップデートをしたら、以下のエラーでアップデートに失敗した。
# pacman -Syu

:: Synchronizing package databases...
...
error: failed to commit transaction (conflicting files)
js52: /usr/lib/libmozjs-52.so.0 exists in filesystem
Errors occurred, no packages were upgraded.

/usr/lib/libmozjs-52.so.0のファイルが存在し、js52のアップデートとコンフリクトしている。


2018年2月18日日曜日

xorgprotoへのアップデートで、error: failed to prepare transaction (could not satisfy dependencies)のエラー

xorgprotoへのアップデートで依存関係のエラー
pacmanからパッケージのアップデートを行ったら、以下のようなエラーが発生した。

# pacman -Syu

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 archlinuxfr is up to date
:: Starting full system upgrade...
:: Replace compositeproto with extra/xorgproto? [Y/n] y
:: Replace damageproto with extra/xorgproto? [Y/n] y
warning: firefox: ignoring package upgrade (56.0.1-1 => 58.0.2-1)
warning: firefox-i18n-ja: ignoring package upgrade (56.0.1-1 => 58.0.2-1)
:: Replace fixesproto with extra/xorgproto? [Y/n] y
:: Replace fontsproto with extra/xorgproto? [Y/n] y
:: Replace inputproto with extra/xorgproto? [Y/n] y
:: Replace kbproto with extra/xorgproto? [Y/n] y
:: Replace randrproto with extra/xorgproto? [Y/n] y
:: Replace recordproto with extra/xorgproto? [Y/n] y
:: Replace renderproto with extra/xorgproto? [Y/n] y
:: Replace scrnsaverproto with extra/xorgproto? [Y/n] y
:: Replace videoproto with extra/xorgproto? [Y/n] y
:: Replace xextproto with extra/xorgproto? [Y/n] y
:: Replace xf86vidmodeproto with extra/xorgproto? [Y/n] y
:: Replace xineramaproto with extra/xorgproto? [Y/n] y
:: Replace xproto with extra/xorgproto? [Y/n] y
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'


2018年2月3日土曜日

CUPSのアップデートでヘルパーのユーザとグループが変更

CUPSヘルパーのユーザとグループが変更
CUPS 2.2.6-2以降で、CUPSヘルパーが使うユーザとグループが変更になった。これまで、ユーザはdaemon、グループはlpが使われてきたが、CUPS 2.2.6-2以降ではユーザ、グループともにcupsが使われるようになった。

CUPS 2.2.6-2のビルドファイルには、以下のように書かれている。
...
+ # use fixed cups user (id 209) since systemd adds "lp" group without a fixed id
...
-     --with-cups-user=daemon \
-     --with-cups-group=lp \
+     --with-cups-user=209 \
+     --with-cups-group=209 \
...