Linux

| Linux

[Linux] Udevを使ってKeyuboardのマッピング

[Linux]udevを使ってUSB Keyboard のキーマップを変更する.

なんの拍子か、KeyboardのBluetoothの接続が消えてしまったので再ペアリングしたらKeymap設定もおかしくなってしまったので（理由は不明だ・・）Keyboardのモードによる違いなのか・・・

/etc/udev/hwdb.d/90-bluetoothkey.hwdb

evdev:input:b0005v05ACp0110e0100*
  KEYBOARD_KEY_700e6=hiragana
  KEYBOARD_KEY_700e7=print
  KEYBOARD_KEY_700e3=leftmeta
  KEYBOARD_KEY_700e2=katakana
  KEYBOARD_KEY_700e0=capslock
  KEYBOARD_KEY_70039=leftctrl

最近は、ノートパソコンのキーを上記のようにしているので今回は合わせるよに設定をおこなう。

| POP_OS

LinuxのPipeWireを利用していてBluetoothのヘッドホンが音飛びする場合の対処（かもしれない）

Bluetooth Audio とLinux。なんとなく相性悪そうなやつですね。ただのイメージですが。

症状

音楽の再生時に音飛び（一時的に音が消える）減少が発生する。Bluetooth AudioのCodecが何であっても関係がない状態。SBCとかでも発生している。再生できる時もあるが基本的にはブツブツな感じ

  • PipeWire audio ( POP_OS 22.04 )
  • Bluetooth Audio head set

解決方法

Flatpakで入っている（ここが一番怪しいけど）ため以下の　cd $HOME/.local/share/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08/3e9184ebb14aa1a827518493704b7d45fb80136bcb31b6fac096f55be53048f3/files/share/pipewire/media-session.d/ ディレクトリに入っているファイルを修正する。ローカルに普通に入っている場合には /etc/pipewire などにあるはず

alsa-monitor.conf　→　session.suspend-timeout-seconds = 0 # 0 disables suspend
bluez-monitor.conf　→　session.suspend-timeout-seconds = 0 # 0 disables suspend

サスペンドしてしまうことによる原因がありそうなのでこの値を０に変更

pipewire.conf 　→　default.clock.rate = 44100 # default.clock.rate = 48000

これも何処かに書いてあったので修正（※こちらはなくても良いかもしれない）して、PCを再起動

結果

音飛びは減りました（というかほぼなくなりました）正確にどの対処であるとかほんとにFlatpakの場所を見ているのかとか確認していませんが状況的には改善していますのであっていたのかな。しばらく使っていてダメそうならまた原因を探したいと思います。

| Linux

LinuxでFlatpakのアプリ上でのカーソルが小さすぎる場合の対処

HiDPIや最近の大型の画面で利用している場合にカーソルのサイズを変えたりした際にFlatpak上のアプリではカーソルの大きさに影響がないことがあります。

以下のコマンドでFlatpak側からもローカルのファイルシステムの変更が見えるようにすることで解消することがある（解消した）ので紹介しておきます（※なんでiconsを見ると「サイズ」の問題が解消するのかはわかってないですが）

flatpak --user override --filesystem=/home/$USER/.icons/:ro
flatpak --user override --filesystem=/usr/share/icons/:ro
| Linux, POP_OS

xremapを利用して特殊なショートカットをマッピングしてみる（Alt+c → Shift+Ctrl+c など )

スペースキーの左側の「ALT」キーを普段は「Katakana」キーにマッピングしています。これでIME側の設定で日本語を解除するのに利用しています（USキーボードを使用しておりmacosでの挙動を模倣しています）
やりたいことは次のようになります。

ショートカット変更後のキー
Katakana + cShift + Ctrl + c
Katakana + cShift + Ctrl + v

macOSでは、⌘キーと Ctrl キーの使い分けがきちんと出来ておりTerminalとかでコピーとCtrl+cをうまく分離しています。Linuxではこれらを避けるために多くのアプリは Shift + Ctrl + c にショートカットが割り当てられていることが多いです。

WaylandもXでもどちらでも利用できる xremap というツールでこれを実現できました。

普段 macの場合には　Karabiner Elements を利用してコマンドキーを一回押した場合に Hiragana / Katakana にしています。Linuxでも同様に ALT_R を Katakana にしています。そのため、うまくこのキーを利用したいので、

キー１回長押し
KatakanaKatakanaAlt_R

に設定するようにします。そしてこのAlt_Rのショートカットを設定するようにします。

ショートカット変更後のキー
Alt_R + cShift + Ctrl + c
Alt_R + cShift + Ctrl + v

今回は、Alt_Rという装飾キーmodifiersを利用しました。Katakanaキーを直接virtual_modifiersにしていすると単体でKatakanaキーが有効化できなくなったので一旦Alt_Rを経由して実現しています。

modmap:
  - remap:
      Katakana:
        held: Alt_R
        alone: Katakana
        alone_timeout_millis: 100

keymap:
  - remap:
      Alt_R-c : SHIFT-CTRL-c
      Alt_R-v : SHIFT-CTRL-v

xremap自体はバイナリで提供されておりダウンロードしてすぐに使えますのでまずは試してみるのが良いですね。他にも色々なことができそうなのでもう少し色々見てみたいと思います。

参考

| GCP, Linux

GCEがKernel Panic で起動しないときの対処

症状

  • GCEに対して再起動を実施したら起動してない
  • シリアルポートログを確認すると「Kernel Panic」で停止している
  • Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

環境

  • Ubuntu 22.04 ( upgradeで来ている）
  • e2-micro (一番小さいやつ）
  • ストレージサイズ 10G (一番小さいやつ）

原因

結果的には以下が原因となっていた

  • Kernel Update の際にディスクの容量不足？でUpdate が正常に行えず、かつロールバックも出来ない状態になっていた
  • その際に、ディスク装置に問題が発生しておりSuperBlockか何処かがおかしい状態になっている（通常の mount が出来ない状態）

対処

GCEなので対処の方法は色々取れるのは助かりました。結果として実施した内容を以下に整理しておきます。原因は別でも似たような症状になった場合には対処できることもあるかもしれません。

  1. ストレージのスナップショットから「ディスクを作成」する
    • 今回は日々スナップショットをスケジュールで実行していたので昨日のスナップショットを利用した（大切、1世代でも取得しておくことをおすすめ）
    • 復元するリージョン・ゾーンと同じ場所に作る
    • サイズをこの段階で20Gに変更しておく（サイズはGCEの場合にはオンラインでも変更可能）
    • 名前は適当に
  2. 新規に同じリージョン・ゾーンでインスタンス①を作成する
    • 復旧の一時的なものなのでマシンスペックは大きめにしておくほうが良い（特にメモリは4Gとかはある方が無難、一時的なのでそれほど費用はかからない想定）
      先程作成した「ディスク」をセカンドディスクとして接続しておく
    • ネットワークなどの通信設定は不要（ディフォルトで作成して問題ない）
    • OSは故障したものと同じOSのバージョンのイメージ（今回はUbuntu22.04 min LTS）を利用して作成する
  3. インスタンス①を起動したらディスクを修復
    • fdisk -l でストレージを確認（/dev/sdb）
    • parted -l で GPTエラーが出ていたら修復する
    • ディスクサイズを大きくしているので以下で拡張をする
      • growpart /dev/sdb 1 を実施してパーティションを拡張（※sdb1がデータが入っている本体のパーティションの場合）
      • resize2fs /dev/sdb1 を実施（ファイルシステムを拡張）
    • ディスクを修復 e2fsck -f /dev/sdb1
  4. ディスクをマウントしてChrootを実施
    • mkdir /data_disk
    • mount -o nouuid /dev/sdb1 /data_disk
    • mount –bind /dev /data_disk/dev/
    • mount –bind /dev/pts /data_disk/dev/pts
    • mount –bind /proc /data_disk/proc
    • mount –bind /sys /data_disk/sys
    • chroot /data_disk
    • これでルートが追加したディスクになっていることを確認しておく
    • 何故か初期で mount -o nouuid でマウントできずオプションなしでマウントすることになった（同じマシンで起動する場合には競合する可能性があるので注意）
  5. Kernelの再導入
    • 色々この段階で調査をしているのだが今回はKernelが半端に入っているので再度導入を行う（実際には apt –reinstall install linxu-xxx をしたのだが実行が出来ず結果的には apt autoremmove で修復が実施された
    • Kernelを導入するとその段階でGrub系のコマンドも実行される
    • 今回のケースではない場合には grub install や update-grub などを利用してブート (/boot) を修復する必要があるかもしれない。
    • インスタンス②を停止
    • 編集からディスクを取り外す
  6. 新規にインスタンス②を起動
    • 最終的にはこのインスタンス②を利用するか、壊れたインスタンスのディスクを取り外しても良い（怖いのでここは②を利用して確認をおこなう）
    • 作成時に、先程のディスクを boot diskとして選択する
    • ネットワークの設定などは壊れたインスタンスの内容と同じにしておく
    • 起動を実施してシリアルログから起動メッセージを確認する
    • 起動しない場合にはBoot領域がおかしいなどの場合がある。今回のケースで言えば修復だけして起動したら指定されたKernelがないために起動することが出来なかった。多分 grubで一つ前のものをうまくしてするように修正すれば起動したと思われる

感想

まぁクラウドで良かった。色々試せたので。たまにはスナップショット意外にもマシンイメージとしてバックアップも必要だなと感じた次第。スナップショットの定期実行は便利。Config Managerの自動アップデートの構成（のせい？）は怖い。KernelはUpdateしないほうが無難かもしれない。あとそもそもの原因はストレージ不足とメモリ不足もある気がするのでストレージ拡張した上でZramとかSwapをきちんと定義しておくことで予防にはなる

上部へスクロール