うつ病けんけんのFedora/Linux日記

2020年05月11日21:00

【解決済み】GNOMEのサウンドがspeech-dispatcherが表示されて音割れノイズする！！

カテゴリ: Gnome-Shell; マルチメディア

新コロナが少し落ち着いて来ましたね。ホッとしてる方も多いのでは。

　さて、GNOMEのサウンドが音割れというかノイズがすることがまれにあります。Last.fmさんを巡回していると起きますね。私のサウンド周りはマザボのオンボでマザボはASRock B450M Steel Legendなのです。恐らくMなしも同様の方法で直ると思います。Fedora32で起きていますすが、Fedora31でも起きていてF32よりも音割れの仕方がひどかったです。記事に出来なくてすいません。

　GNOMEの【設定】から【サウンド】を見てみると、下図のように

speech-dispatcher-mummy
speech-dispatcher-espeak-ng
speech-dispatcher-generic

と表示されています。dispatcherってe-Wordsさんによると、「処理待ちのデータやプロセスに対して必要な資源の振り分けや割り当て、適切な受け入れ先への引き渡しを行うプログラムなどを指すことが多い。」とありますねー。公式サイトは、Speech Dispatcher　Free(B)Soft。googlingしてたら、Arch Wikiにたどり着いて、Pulseaudio/トラブルシューティングにたどり着きました。Linuxのサウンド処理を担当しているPulseaudioが原因みたいですね。

　解決策は、以下の通り。

cp /etc/pulse/default.pa ~/.config/pulse

そして、~/.config/pulse/default.paを以下のように編集してください。(編集前ファイルのバックアップを取っておくこと)

load-module module-udev-detect

　　　　　　　　　↓

load-module module-udev-detect tsched=0

と tsched=0を足して下さい。自分だけじゃなく複数人でLinuxを使っているなら/etc/pulse/default.paに書けばシステム全体で有効になります。Arch Wikiには色んな解決方法が載っているのこの方法で直らない場合はPulseAudio/トラブルシューティングを参照のこと。反対に鳴らなくなる可能性もあるので要注意

タグ：: pulseaudio

2020年05月01日10:40

GNOME keyringキーリングのパスワードを忘れた！解除する方法は？

カテゴリ: Gnome-Shell

GNOMEを使ってて不意にキーリングのパスワードを求められても解除出来ない事が起きました。その解決方法を紹介。FedoraでなくてもUbuntuなどのGNOMEデスクトップ環境であればこの方法で解決出来ると思います。ただし、失われる情報もあるかもしれないので慎重に。

解決方法は簡単でkeyringのファイルを削除orリネームすればOKです。

cd .local/share
cp -R keyring keyring.bak
rm keyring/login.keyring

してログアウトかLinuxシステムを再起動でOKです。

再起動後キーリングにログインした時に求められたらLinuxのログイン時のパスワードだと思います。また、必要なアプリを起動するとパスワードの登録を求められるので入力して下さい。恐らくGoogle Chromeが要求してくると思います。また毎回パスワードを入力するのが面倒であれば、”パスワード”項目の"ログイン"や"Default keyring"の項目を右クリックして"パスワードを変更"を選び、現在のパスワード入力後変更後のパスワードで何も入力せずにEnterすれば空のパスワード設定になりキーリングのパスワードの入力を求められなくなると思います。(何故か空にし直さないといけないことがよくある。)

2020年04月29日16:46

GNOMEリモートデスクトップが真っ暗

カテゴリ: Fedora Core; Gnome-Shell

Fedora32のGNOMEのリモートデスクトップ(画面共有)がうまく機能していません。初回時はちゃんとGNOMEの画面表示操作が出来ますが、クライアント側から一度切ってしまうと下図のように真っ暗になります。

iPhoneからベッドで寝転がってLinux操作できて便利だったんですが、残念ですね。

解決策がないか色々探してみましたがなさそうなので、アップデート待ちです

パッケージはgnome-remote-desktopなのでこいつがアップデートされる事を祈ります！

2020年04月17日09:52

【解決済み】KVMでのUbuntu 20.04 Beta GNOME 3.36がクラッシュログインループする

カテゴリ: Ubuntu

珍しくUbuntuのネタです。

KVMでのUbuntu 20.04 Beta(~~Betaじゃなく正式版20.04でも起こるかも~~正式版の20.04では直ってます)のGNOME 3.36がクラッシュしたり、ログイン画面でパスワード入れてもログイン画面に戻されるログインループしますのでその解決方法。設定ツールを開くとクラッシュします。

KVMのGUIツールにvirt-manager仮想マシンマネージャーを使うことを前提とします。

Virtualboxでも起きるかどうかは調べていませんが、拡張機能を使うなら起きないかも？

発生条件として、Ubuntuインストール時にプロプライエタリのドライバーをインストールするかUbuntuインストール後にubuntu-restricted-extraをインストールしているとクラッシュが起きます。

解決策としては、virt-managerのキーの送信から【Ctrl+Alt+F3】を選んでコンソールに切り替えログインして、

sudo apt remove  gstreamer1.0-vaap

して再起動すれば解決します。

タグ：: Ubuntu

2020年04月01日21:45

GNOMEとKDEがついにタッグを組んだ！KNOME登場！？

カテゴリ: Gnome-Shell

Linuxの2大統合デスクトップ環境のGNOMEとKDEがタッグを組んだKNOMEがリリースされるという情報がTwitterのGNOME公式アカウントで発表されました。https://twitter.com/gnome/status/1245259605388607489?s=21 GNOMEはGIMPのgtkをベースに、KDEはqtをベースに作られたデスクトップ環境です。KNOMEではQTK3とMutterならぬkutterを使うのだそう。

デスクトップLinuxerならとてもワクワクするプロジェクトです。このKNOME、スマホでも動くらしいです。

詳しくは、https://knome.org へ！

まあ、今日が何の日か…

2020年03月20日15:49

【解決済み】デュアルディスプレイでのGNOME-Shell画面ロック後真っ暗(ブランク)を維持しない

カテゴリ: Gnome-Shell

症状の概要

GNOME-Shell on Xorgの画面ロック及び自動画面ロック機能が変な動きをします。画面ロックは、右上端をクリックして鍵マークを押すとでき、自動画面ロックは【設定】→【プライバシー】→【自動画面ロック】をOFFにしていなければ、設定時間次第ですが、マウスキーボードを動かさず放っておくと真っ暗（ブランク)されます。

詳細

この画面ロックの際に真っ暗になってマウスやキーボードに触らければ真っ暗なままなはずなんですが、真っ暗になったあとモニタがスリープになりましたと表示された後何故か復帰してロック画面が表示され、そしてまた真っ黒画面になりロック画面に戻ると数十秒ごとに繰り返すのです。明るくなったり暗くなったりですごくうざい…　しかし、これが色々試しても直らないんですよねー。

ハードウェア環境

モニター1がHDMI、モニター2がDP→DVI-D接続です。GPUはCPU内臓のAPUでAMD Ryzen 5 2400GのものであるRadeon Vega 11 Graphicsです。

試したこと

この問題について試行錯誤したことを以下に記載します。

WindowsではOK。
シングルモニタではモニタ1、モニタ2両方共ダメ。
GNOMEの通知が来ている？→設定でアプリ全部通知を切ってもダメ。
mariadb、httpdなどサービスを止めてみては？→止めてもダメ。
カーネルバージョンは？→古いものを試してもダメ。
マザボのCMOSクリアは？→効果なし

解決方法

解決方法は2通り。ただし、私のCPUではダメなものも。

amdgpu.dc=0

Rx460 monitors won't stay asleepで書いてあるとおり、カーネルパラメーターに "amdgpu.dc=0"を追加です。起動時にgrub2で試してみてうまくいくなら、/etc/default/grubに

GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.dc=0"

を追加してください。そして、grub2の設定を書き出すように

sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

します。これで再起動しても有効になります。ただし、amdgpu.dc=0はグラボの性能さげちゃうかと。そしてなによりRyzen 2400Gではamdgpu.dcと表示された後起動しないです。

xset s off -dpms

もうひとつは、XorgのDPMS機能をオフにします。GNOMEと喧嘩でもしてるんですかね…よくわかりませんが、端末アプリから

xset s off -dpms

すると何故か画面ロックの後真っ黒画面を維持してくれます。DPMSって自動でモニタの画面を切ってくれる機能のはずなんですが…　再起動するとまた戻るので、xset.desktopファイルを~/.config/autostartへ以下の内容で配置します。

[Desktop Entry]
Name=Xset-off
GenericName=Xset OFF DPMS
Comment=Xset OFF DPMS for Screen Lock
Exec=xset s off -dpms
Terminal=false
Type=Application

これでGNOME起動時にxsetが有効になります。

感想

この現象の一番の原因は上記でも書いたリンクとの共通点であるredditDP→DVI-D接続のせいかなと思ってますが、どうなんでしょうねえ。モニタを買い換えないとわかりませんが、2400GのVega11のせいだったら悲しいなあ。ググってもそれらしいのは見つからないのですが、手っ取り早いのはグラボ買い替えですかね？GTX 1050TiとかならDVI-D端子のものもありますし…　実際の作業時の問題ではないので放置でいいかなとも思ってますが。ずっとこだわっててうまく対処方法が見つかってうれしいですが、問題を気にせず頭を切り替えていったほうが良かったようなきもします…

2020年02月03日20:24

WordPress Maximum Upload File Size 2MB

カテゴリ: サーバー管理

WordPress鯖をLAN内で構築しているのですが、画像ファイルなどのメディアファイルのサイズが2MB以上のものがアップロード出来ませんでした。

ぐぐってみると、.htaccessとか functions.phpだったりしますが変更しても何も変化なく…

/etc/php.iniの編集

　Fedora鯖のphpの/etc/php.iniを弄れば良いようです。もちろんsudo vim /etc/php.initしてくださいね。　　

upload_max_filesize = 2M

　　　　　　　↓ 　　

upload_max_filesize = 10M

　と数字を変更してください。数値は必要になってから増やす方が良いかと思います。
　　

php-fpmサービスの再起動

　 phpのサービスを再起動します。　　

　sudo systemctl restart php-fpm

PHP設定確認

　設定サービス再起動したら安心と思わず、反映されているか確認しておきましょう。WordPressでアップロードしてみれば良いですが、WordPress側の設定のせいか鯖の設定か切り分けられないので、Linux鯖のPHPでの確認方法を紹介しておきます。　　

phpinfo.phpの確認

　 phpの設定確認にphpinfo.phpを用意します。公開先は標準だと/var/www/html/以下ですかね。　　

とします。画像ですいません。HTML preタグの中で書くと<？がコメント化されてしまいます。
編集出来たら、ブラウザで
http://IPアドレスorドメイン名/phpinfo.php を開きます。IPアドレスorドメイン名はご自分の環境で。すると下図のようにphpの情報が表示されると思います。　　

　表示されたら、ブラウザの検索で

upload_max_filesize

で検索します。下図のように設定した数値になっていたら成功です。
php情報を公開するのは危険なので速やかにphpinfo.phpを消しておいてください。　　

　これでもWordPressでメディアアップロードが出来なければブラウザからWordPressの設定をあたってください。プラグインで設定するのが楽かな？　　

タグ：: WordPress; PHP

2020年01月03日10:28

[再発]AMD Ryzen 2400G でGNOMEロック画面が真っ黒オフにならない

カテゴリ: Gnome-Shell

※GNOME 3.34.3アップデートにより解決したっぽい？(2020年1月11日(土)）

※アップデートあったがまた再発(2020年3月13日(金))

唯一の情報の出処のPhoronixの記事には明示的には書いてないですが…

久々の投稿になります。

PCの環境をリプレースして

CPU: Ryzen 2400G

マザボ: ASRock B450M Steel Legend

グラボ: Ryzen 2400G Radeon Vega 11(APU)

でご機嫌にLinuxライフしています。概ね調子よく動いてるのですが一つ困ったことが。

それは、GNOMEのロック画面が真っ黒になるけど16秒ほどですぐにロック画面の壁紙に。つまり真っ黒画面から明るくなっちゃうのです。Abrtに大量にカーネルバックトレース通知が来ていて？しかもjournalctlのログ見たら16秒ごとに同じ内容のエラーが出てるし、この通知が来ることによって明るくなっていると思う…

※スリープはする

PCと同じ部屋で寝てないですが、画面が明るくなったりしてかなりうっとおしい。

どうもマルチメディアというかデュアルディスプレイにしていると起こるようで、電源切ってからシングルディスプレイにしてる場合はロック画面での明るくなることはないっぽい。3分ほどしかみてないのですが、16秒ごとに起きてはないので問題ないのではないかと。

まあ、使わないときはディスプレイの電源は切っておけばいいものだし放っておけばいいのでしょうが。あとは、Abrtパッケージを削除とか？多分、ごっそりGNOME環境を道連れにされるのでしないほうが良いでしょう。というわけで対策求む…

【追記】

いつの間にか再発。まず、普段使いとは別の新規アカウントを作ってもこの問題は出ます。たまに画面ロック画面オフになってくれることもあるが、ごちゃごちゃ確かめてるとやはり真っ黒画面をキープせずロック画面壁紙が見える状態に。唯一ちゃんと再現よく画面真っ黒になるのは、無線マウスの電源を切ってひと呼吸おいてから【田(Windowsキー）】+【L 】を押すと画面オフになってくれます。USBの有線マウスだと引っこ抜くといける。PS/2マウスは持ってないのでわかりません。

Fedora30のUSBライブイメージで起動してそのまま画面ロックしてもこの問題はおきます。Ubuntuでもなるのか試したいけど、USBメモリにインストールは時間掛かりすぎた…

Rx460 monitors won't stay asleep [reddit] でDVI-DとDisplay Port接続がーってのが私の条件とあっているんだけど、amdgpu.dc=0すると起動しない…　あっちはグラボでこっちはCPU内蔵であるAPUだからかな？

画面ロックから画面真っ暗オフしない一番簡単な解決方法はモニタの電源切れば良い話なんだけど、原因がつかめないのでスッキリしないです。FedoraだとAMDプロプライエタリのドライバは対応していないので、OSSなドライバのせいなんですかね。さあ、早く諦める決意をしよう。

以下、journalctlメッセージ

 ------------[ cut here ]------------
 1月 03 19:00:06  kernel: WARNING: CPU: 2 PID: 441 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1464 dcn_bw_update>
 1月 03 19:00:06  kernel: Modules linked in: fjes(-) amdgpu(+) amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper uas nvme drm >
 1月 03 19:00:06  kernel: CPU: 2 PID: 441 Comm: systemd-udevd Not tainted 5.4.7-Ryzen5-rpm #1
 1月 03 19:00:06  kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Steel Legend, BIOS P2.90 11/27/2019
 1月 03 19:00:06  kernel: RIP: 0010:dcn_bw_update_from_pplib+0xaa/0x2f0 [amdgpu]
 1月 03 19:00:06  kernel: Code: 0c 24 85 c9 74 24 8d 71 ff 48 8d 44 24 04 48 8d 54 f4 0c eb 0d 48 83 c0 08 48 39 d0 0f 84 2e 01 00 >
 1月 03 19:00:06  kernel: RSP: 0018:ffffb92e4040b690 EFLAGS: 00010246
 1月 03 19:00:06  kernel: RAX: ffffb92e4040b694 RBX: ffff90382d3d0000 RCX: 0000000000000004
 1月 03 19:00:06  kernel: RDX: ffffb92e4040b6b4 RSI: 0000000000000003 RDI: ffff903850497900
 1月 03 19:00:06  kernel: RBP: ffffb92e4040b7d0 R08: 0000000000000000 R09: 0720072007200720
 1月 03 19:00:06  kernel: R10: 0720072007200720 R11: 0720072007200720 R12: ffffb92e4040b720
 1月 03 19:00:06  kernel: R13: ffff90384d97a380 R14: 0000000000000001 R15: ffffb92e4040b870
 1月 03 19:00:06  kernel: FS:  00007fcdfab5a940(0000) GS:ffff903850480000(0000) knlGS:0000000000000000
 1月 03 19:00:06  kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 1月 03 19:00:06  kernel: CR2: 00007fcd35be3000 CR3: 000000036fdf2000 CR4: 00000000003406e0
 1月 03 19:00:06  kernel: Call Trace:
 1月 03 19:00:06  kernel:  dcn10_create_resource_pool+0x82c/0xb60 [amdgpu]
 1月 03 19:00:06  kernel:  ? _cond_resched+0x15/0x30
 1月 03 19:00:06  kernel:  ? dal_gpio_service_create+0x92/0x110 [amdgpu]
 1月 03 19:00:06  kernel:  dc_create_resource_pool+0xcf/0x150 [amdgpu]
 1月 03 19:00:06  kernel:  dc_create+0x23d/0x700 [amdgpu]
 1月 03 19:00:06  kernel:  ? amdgpu_cgs_create_device+0x23/0x50 [amdgpu]
 1月 03 19:00:06  kernel:  amdgpu_dm_init+0x13d/0x1c0 [amdgpu]
 1月 03 19:00:06  kernel:  ? phm_wait_for_register_unequal.part.0+0x50/0x80 [amdgpu]
 1月 03 19:00:06  kernel:  dm_hw_init+0xe/0x20 [amdgpu]
 1月 03 19:00:06  kernel:  amdgpu_device_init.cold+0x1477/0x1790 [amdgpu]
 1月 03 19:00:06  kernel:  amdgpu_driver_load_kms+0x53/0x1a0 [amdgpu]
 1月 03 19:00:06  kernel:  drm_dev_register+0x111/0x150 [drm]
 1月 03 19:00:06  kernel:  amdgpu_pci_probe+0xee/0x150 [amdgpu]
 1月 03 19:00:06  kernel:  ? __pm_runtime_resume+0x58/0x80
 1月 03 19:00:06  kernel:  local_pci_probe+0x42/0x80
 1月 03 19:00:06  kernel: RDX: ffffb92e4040b6b4 RSI: 0000000000000003 RDI: ffff903850497900
 1月 03 19:00:06  kernel: RBP: ffffb92e4040b7d0 R08: 0000000000000000 R09: 0720072007200720
 1月 03 19:00:06  kernel: R10: 0720072007200720 R11: 0720072007200720 R12: ffffb92e4040b720
 1月 03 19:00:06  kernel: R13: ffff90384d97a380 R14: 0000000000000001 R15: ffffb92e4040b870
 1月 03 19:00:06  kernel: FS:  00007fcdfab5a940(0000) GS:ffff903850480000(0000) knlGS:0000000000000000
 1月 03 19:00:06  kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 1月 03 19:00:06  kernel: CR2: 00007fcd35be3000 CR3: 000000036fdf2000 CR4: 00000000003406e0
 1月 03 19:00:06  kernel: Call Trace:
 1月 03 19:00:06  kernel:  dcn10_create_resource_pool+0x82c/0xb60 [amdgpu]
 1月 03 19:00:06  kernel:  ? _cond_resched+0x15/0x30
 1月 03 19:00:06  kernel:  ? dal_gpio_service_create+0x92/0x110 [amdgpu]
 1月 03 19:00:06  kernel:  dc_create_resource_pool+0xcf/0x150 [amdgpu]
 1月 03 19:00:06  kernel:  dc_create+0x23d/0x700 [amdgpu]
 1月 03 19:00:06  kernel:  ? amdgpu_cgs_create_device+0x23/0x50 [amdgpu]
 1月 03 19:00:06  kernel:  amdgpu_dm_init+0x13d/0x1c0 [amdgpu]
 1月 03 19:00:06  kernel:  ? phm_wait_for_register_unequal.part.0+0x50/0x80 [amdgpu]
 1月 03 19:00:06  kernel:  dm_hw_init+0xe/0x20 [amdgpu]
 1月 03 19:00:06  kernel:  amdgpu_device_init.cold+0x1477/0x1790 [amdgpu]
 1月 03 19:00:06  kernel:  amdgpu_driver_load_kms+0x53/0x1a0 [amdgpu]
 1月 03 19:00:06  kernel:  drm_dev_register+0x111/0x150 [drm]
 1月 03 19:00:06  kernel:  amdgpu_pci_probe+0xee/0x150 [amdgpu]
 1月 03 19:00:06  kernel:  ? __pm_runtime_resume+0x58/0x80
 1月 03 19:00:06  kernel:  local_pci_probe+0x42/0x80
 1月 03 19:00:06  kernel:  pci_device_probe+0x107/0x1a0
 1月 03 19:00:06  kernel:  really_probe+0x147/0x3c0
 1月 03 19:00:06  kernel:  driver_probe_device+0xb6/0x100
 1月 03 19:00:06  kernel:  device_driver_attach+0x53/0x60
 1月 03 19:00:06  kernel:  __driver_attach+0x8a/0x150
 1月 03 19:00:06  kernel:  ? device_driver_attach+0x60/0x60
 1月 03 19:00:06  kernel:  bus_for_each_dev+0x78/0xc0
 1月 03 19:00:06  kernel:  bus_add_driver+0x14d/0x1f0
 1月 03 19:00:06  kernel:  driver_register+0x6c/0xc0
 1月 03 19:00:06  kernel:  ? 0xffffffffc0a6b000
 1月 03 19:00:06  kernel:  do_one_initcall+0x46/0x1f4
 1月 03 19:00:06  kernel:  ? _cond_resched+0x15/0x30
 1月 03 19:00:06  kernel:  ? kmem_cache_alloc_trace+0x162/0x220
 1月 03 19:00:06  kernel:  ? do_init_module+0x23/0x230
 1月 03 19:00:06  kernel:  do_init_module+0x5c/0x230
 1月 03 19:00:06  kernel:  load_module+0x28c9/0x2b20
 1月 03 19:00:06  kernel:  ? ima_post_read_file+0xf0/0x100
 1月 03 19:00:06  kernel:  ? __do_sys_finit_module+0xaa/0x110
 1月 03 19:00:06  kernel:  __do_sys_finit_module+0xaa/0x110
 1月 03 19:00:06  kernel:  do_syscall_64+0x5b/0x1a0
 1月 03 19:00:06  kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 1月 03 19:00:06  kernel: RIP: 0033:0x7fcdfbb001ad
 1月 03 19:00:06  kernel: Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d >
 1月 03 19:00:06  kernel: RSP: 002b:00007ffd4bcfdcb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
 1月 03 19:00:06  kernel: RAX: ffffffffffffffda RBX: 00005563e28ea7b0 RCX: 00007fcdfbb001ad
 1月 03 19:00:06  kernel: RDX: 0000000000000000 RSI: 00007fcdfb72784d RDI: 0000000000000013
 1月 03 19:00:06  kernel: RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007
 1月 03 19:00:06  kernel: R10: 0000000000000013 R11: 0000000000000246 R12: 00007fcdfb72784d
 1月 03 19:00:06  kernel: R13: 0000000000000000 R14: 00005563e28ea410 R15: 00005563e28ea7b0
 1月 03 19:00:06  kernel: ---[ end trace b4501ffe4dce7d81 ]---

Abrtを見ると警告件数が8800超えてます（左上に表示）