2020/4/19 (日)

diary/Kojima

・Plamo Linux 小技集

MLの方でも書いたけど、手元で作っているカーネルパッケージ（例えばkernel-5.4.30-x86_64-1.txz)には grub.cfg を作る処理は仕込んでいないので、手動で grub-mkconfig を実行する必要がある。

なぜ grub-mkconfig を仕込んでいないのかと言うと、新しいカーネルで何かトラブルがあった場合は古いカーネルにfall backできるようにしたいのだけど、そのためには新しいカーネルパッケージと既存のカーネルパッケージを共存させる必要があるためだ。

Plamo Linuxの場合、パッケージの有無は /var/log/packages/<パッケージ名> というファイルの有無で管理しているので、例えば複数のカーネルパッケージを共存させたい場合、既存の/var/log/packages/kernel というファイルを別の名前にしておけば、新しいカーネルパッケージを installpkg で(= 古いパッケージを削除することなく）インストールできる。

例えばこんな感じ。

 # mv /var/log/packages/kernel{,_5.2.11}
 # installpkg kernel-5.4.30-x86_64-B1.txz

こうすれば /lib/modules/ 以下に 5.2.11_plamo64/ と 5.4.30_plamo64/ のモジュールディレクトリ、/boot 以下に {vmlinuz,initrd}-5.2.11-plamo64 と {vmlinuz,initrd}-5.3.40-plamote というカーネルイメージが共存できるので、

 # grub-mkconfig -o test.cfg

してやれば2世代のカーネルとinitrdイメージを見付けて、適切な設定ファイルを作ってくれる。test.cfg を確認して、

 # mv test.cfg /boot/grub/grub.cfg

してやれば、古い 5.2.11 カーネルと新しい 5.4.30 カーネルがデュアルブート可能になるので、何か問題が起きた場合は古いカーネルに fallback 可能になる。

ちなみにこのテクニックはカーネルパッケージ以外にも使用可能なものの、Plamo Linuxでは既存のファイルへの上書きを保護するような仕組みは用意してないため、ファイル名やディレクトリ名にバージョン番号を含むような形で区別していない場合は、既存のファイルを上書きしてしまうので要注意。


2020/4/18 (土)

diary/Kojima

・Plamo Linux 7.x 小技集

原稿の記事にするほどでもない小ネタを思いつくままに。。。

昨今のデスクトップ環境は、ユーザのホームディレクトリに「デスクトップ」とか「ドキュメント」とか言った日本語のディレクトリを作るけど、このディレクトリ名を英語にしたい場合は、新規ユーザを作ってそのユーザでログイン後、*xinit を起動する前*に、

 $ LANG=C xdg-user-dirs-update

を実行すればいい。

先にxinitを実行してしまって、日本語ディレクトリを作られた状態でも、このコマンドを実行すると以後は英語ディレクトリが優先されるので、必要なファイル等を移せば日本語ディレクトリは削除可能。

この設定は ~/.config/user-dirs.dirs と ~/.config/user-dirs.localeに保存され、 XDG_DESKTOP_DIR等の環境変数が$HOME/Desktop等と結び付けられて、デフォルトのダウンロード先等の設定に利用される。


2019/12/26 (木)

diary/Kojima

broadcom 用のドライバを添付してみるテスト。

このページの一番下にある ucode30_mimo.fw をダウンロードして、 /lib/firmware/bc43 というディレクトリを作ってそこに置いてみたら ロードされるのではあるまいか。


2019/10/25 (金)

diary/Kojima

・get_depends.py/query_depends.py

MLの方でライブラリの互換性とかの話が出ているので、遅まきながら、メンテナ回りで使っているライブラリの依存性を調べるためのツールを紹介。

get_depends.py は /usr/bin や /usr/lib 等にあるバイナリファイルを ldd して、そのバイナリファイルが必要とするライブラリを SQLite3 なデータベースに格納するコマンド、query_depends.py は指定したバイナリファイルに必要なライブラリをDBから検索するコマンドです。

使い方としては、まず get_depends.py を root 権限で走らせて depends.sql3 というデータベースファイルを作っておき、依存関係を調べたいバイナリファイルを query_depends.py で検索する、という形。とりあえずの使い方は query_depends.py -h で表示される。

$ ./query_depends.py -h
Usage:
 ./query_depends.py [-b name] [-p path ] [-s soname ] [-r realname]
   ./depends.sql3 データベースを用いて，ライブラリの依存関係を調べる．
   -b name: name が含まれるELF形式のバイナリファイルが使う共有ライブラリを表示する
      -b cat とすれば /bin/cat だけでなく，bdftruncate や fc-cat もマッチする
      -b の場合，パス名は見ずに，ファイル名のみで検索する
   -p name: 検索の際にパス名も含めてマッチさせる．-p /bin/cat とすれば /bin/cat のみにマッチする
   -s soname: 共有ライブラリ soname を利用するバイナリファイルを表示する
      -s libgtk libgtk-3.so.0 や libgtk-x11-2.0.so もマッチする
      -s の場合，パス名は見ずに，共有ライブラリ名のみで検索する
   -r realname: 検索の際にライブラリのパス名も含める

例えば、 /usr/sbin/httpd が使うライブラリを調べたい場合は query_depends.py -p /usr/sbin/httpd を実行する。

$ ./query_depends.py -p /usr/sbin/httpd
/usr/sbin/httpd needs these libraries
  b'linux-vdso.so.1 (0x00007ffe927ae000)'()
  b'libpcre.so.1(/usr/lib/libpcre.so.1)
  b'libaprutil-1.so.0(/usr/lib/libaprutil-1.so.0)
  b'libapr-1.so.0(/usr/lib/libapr-1.so.0)
  b'libpthread.so.0(/lib/libpthread.so.0)
  b'libc.so.6(/lib/libc.so.6)
  b'libexpat.so.1(/usr/lib/libexpat.so.1)
  b'libuuid.so.1(/usr/lib/libuuid.so.1)
  b'librt.so.1(/lib/librt.so.1)
  b'libcrypt.so.1(/lib/libcrypt.so.1)
  b'libdl.so.2(/lib/libdl.so.2)
  b'/lib/ld-linux-x86-64.so.2(b'/lib/ld-linux-x86-64.so.2)

あるライブラリ（例えば /usr/lib/libgtk-x11-2.0.so.0) を使っているバイナリファイルを調べたい場合は query_depends.py -s libgtk-x11-2.0

$ ./query_depends.py -s libgtk-x11-2.0
b'libgtk-x11-2.0.so.0 used by these binaries
  uim-input-pad-ja(/usr/bin/uim-input-pad-ja)
  uim-im-switcher-gtk(/usr/bin/uim-im-switcher-gtk)
  uim-pref-gtk(/usr/bin/uim-pref-gtk)
  uim-toolbar-gtk(/usr/bin/uim-toolbar-gtk)
  uim-toolbar-gtk-systray(/usr/bin/uim-toolbar-gtk-systray)
  gtk-query-immodules-2.0(/usr/bin/gtk-query-immodules-2.0)
  gtk-demo(/usr/bin/gtk-demo)
  wnckprop-1(/usr/bin/wnckprop-1)
  wnck-urgency-monitor-1(/usr/bin/wnck-urgency-monitor-1)
  ....

依存関係のチェックには ldd コマンドを使っているので、厳密にそのバイナリファイルが依存しているライブラリだけではなく、関連するライブラリが芋蔓式にひっかかるので、依存関係はかなり多めに出がち。

コマンドファイル(Python スクリプト)は、このページへの添付としてアップロードしておくので、本文の下にある「添付ファイル」のリンクからダウンロードしてください。


2019/9/9 (月)

diary/Kojima

・radiru_noa.py

7月ごろから、NHKの「らじる☆らじる」の番組情報を提供するNOA(Now on Air) APIの URLやJSONフォーマットが変っていて、radiry_rec スクリプトで録音したデータファイルに正しく番組情報が記載できていなかった模様。

ざっと見、radiru_noa.py の修正だけで対応できそうなので、添付のファイルを/usr/local/bin/radiru_noa.py にインストールしてもらえば、NOA経由で番組情報も正しく取れるようになるはず。

Python2で書いたコードなんで、Python3に書き直したいと思ってはいるものの、いつになるかはよく分からないので、とりあえずその場しのぎということで（苦笑


2019/6/3 (月)

diary/Kojima

○CPU用firmwareの読み込み

最近は Meltdown や Spectre といった CPU レベルでのセキュリティホールが見つかり、 それを修正するために CPU 用の firmware が頻繁に更新されています。

Plamo Linuxでは、Intel用のfirmwareは microcode_intel パッケージとして、 AMD 用の firmware は linux_firmware パッケージとして提供し、 それぞれ /lib/firmware/{intel,amd}-ucode/ ディレクトリに収めています。

firmware は、モジュールドライバと同様、 必要に応じてカーネルが(ファイルシステムから)自動的に読み込むものの、 CPU用のfirmwareはCPUが動き始めた直後に適用する必要があるため、 initrdの仕組みを利用して、 すなわちcpioアーカイブをramfs上に展開して読み込むようになっています。

そのためには、CPU用firmwareをcpioアーカイブ化しなければなりません。 カーネルがramfsのどこからCPU用firmwareを読み込むかはあらかじめ決まっており、 Intel用のfirmwareは kernel/x86/microcode/GenuineIntel.bin、 AMD用は kernel/x86/microcode/AuthenticAMD.bin です。

# ソースコード的には /usr/src/linux/arch/x86/kernel/cpu/microcode のあたり

そこで、/lib/firmware/{intel,amd}-ucode/ 以下の firmware を、 これらのファイルに集めます。

$ mkdir -p kernel/x86/microcode
$ cat /lib/firmware/intel-ucode/* > kernel/x86/microcode/GenuineIntel.bin
$ cat /lib/firmware/amd-ucode/* > kernel/x86/microcode/AuthenticAMD.bin

次にこれらのファイルをcpioアーカイブにまとめ、/boot ディレクトリにコピーします。

$ find . | cpio -ov -Hnewc > ../cpu_firmware.cpio
$ sudo cp ../cpu_firmware.cpio /boot

このファイルを grub.cfg の initrd= ... 行に設定します。

  115          echo    'Linux 5.1.5-plamo64 をロード中...'
  116          linux   /boot/vmlinuz-5.1.5-plamo64 root=UUID=47749fa2-16d6-4b5a-bb44-9538e8605ac3 ro  net.ifnames=0 quiet
  117          echo    '初期 RAM ディスクをロード中...'
  118          initrd  /boot/cpu_firmware.cpio /boot/initrd.img-5.1.5-plamo64

この設定でカーネルを起動すれば、カーネルは ramfs 上の kernel/x86/microcode/ に firmware を収めたファイルがあるかを調べ、動作しているCPU用のfirmwareが見つかれば まずそれを適用した上で起動処理を行います。 そのため、firmware の適用は dmesg の先頭で報告されます。

[    0.000000] microcode: microcode updated early to revision 0x27, date = 2019-02-26
[    0.000000] Linux version 5.1.5-plamo64 (kojima@pl71_0513) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Thu May 30 20:36:40 JST 2019
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.1.5-plamo64 root=UUID=47749fa2-16d6-4b5a-bb44-9538e8605ac3 ro net.ifnames=0 quiet
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
...

cpu_firmware.cpio は initrd と合体させることも可能です。 その場合、gzip で圧縮した initrd の先頭に、 無圧縮の cpu_firmware.cpio を追加します。

# cd /boot
# cat cpu_firmware.cpio initrd.img-5.1.5-plamo64 > temp.img
# mv temp.img initrd.img-5.1.5-plamo64

こうしておけば、firmwareのcpioアーカイブを別途読み込ませる必要なく、 initrd と共に読み込まれるようになります。

なお、この処理は、mkinitramfs-0.4 以降の mkinitramfs にはあらかじめ組み込まれているので、 このバージョン以降の mkinitramfs を使う場合、特に気にする必要はありません。

○initrd ファイルの展開方法

cpu_firmware.cpio を先頭に結合したinitrd ファイルは、無圧縮のcpioアーカイブ(CPU用firmware)と gzipで圧縮したcpioアーカイブ(本来のinitrd)が連結された状態になっているので、 そのままではCPU用firmwareの部分しか見えません。

$ cpio -t < /boot/initrd.img-5.1.5-plamo64 
.
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/GenuineIntel.bin
kernel/x86/microcode/AuthenticAMD.bin
5018 ブロック

ここから、元のinitrdを取り出すには、CPU用firmwareの部分を取り除く必要があります。 そのためには dd コマンドで読み飛ばすのが簡単です。 その際、CPU用firmwareのサイズ(上記例では5018ブロック)が必要になります。

$ dd if=/boot/initrd.img-5.1.5-plamo64 skip=5018 | zcat | cpio -t
.
init
lib64
etc
etc/lvm
etc/lvm/cache
etc/lvm/cache/.cache
etc/lvm/lvm.conf
...
bin/cp
bin/cat
bin/sh
34624+1 レコード入力
34624+1 レコード出力
17727818 bytes (18 MB, 17 MiB) copied, 0.190163 s, 93.2 MB/s
52169 ブロック

上記で指定した -t オプションはアーカイブに含まれるファイルの確認です。 実際にファイルを取り出したい場合は -ivd オプションを指定してください。


2019/6/2 (日)

diary/Kojima

○initrd の仕組み

Plamo-7.1で採用したinitrdは、正式には initramfs と呼ばれる仕組みで、 カーネルと共にブートローダ(grub)によってメモリに読み込んだファイルから、 root filesystem をマウントするために必要なモジュール類を カーネルに組み込むために使われます。

 最初に生まれた initrd は、INITialize RamDisk の名前通り、
 あらかじめ loopback 機能等を用いてファイルの形で作成した
 ファイルシステムをRAMディスク上に展開するスタイルでした。
 その後、あらかじめファイルシステムを用意しなくても利用できる
 ramfs が開発され、そこに任意サイズのcpioアーカイブを展開すれば
 ファイルシステムとして利用できるようになりました。
 この第２世代の仕組みは initramfs という名称なものの、
 grubのパラメータ等では initrd= ... という書式が定着しているので、
 initramfs 用のファイルでも、名称は initrd.img-XXXX を使うという
 慣習になっています。そのため、本稿でも initrd/initramfs の総称として
 initrd を使っています。

initrdは、LiveCD等でも使われるものの、 主な用途はroot filesystem(fs)をマウントするために必要な モジュール類のロードです。

Linuxも従っているUnixの伝統的な流儀では、 起動されたカーネルはCPUや周辺機器の初期化等、必要な処理を終えれば、 root fsをマウントし、 そこにある init コマンドに以後の処理を委ねるようになっています。

この処理の流れを大きく変えずに済むように、 initrd にはカーネルから処理を引き継ぐinitコマンドが用意され、 そのinitコマンドが必要とするツールやライブラリ一式を組み込んだ、 シンプルなroot filesystemになるように設計されています。

Plamo-7.1で採用しているinitrdは以下のような構造になっています。

$ ls
bin/  dev/  etc/  init*  lib/  lib64@  proc/  run/  sbin/  sys/  usr/

ここにある init はシェルスクリプトで、 udevd を起動して接続されている周辺機器を確認し、 必要なモジュール類をカーネルに読み込ませてから、 カーネルパラメータの root=... で指定された真のroot fsをマウントし、 最終的に、switch_rootコマンドでroot fsを切り替える、という処理を行います。

 後述する mkinitramfs が利用できるように、initrd用のinitスクリプトは
 /usr/share/mkinitramfs/init.in に収められているので、
 動作を確認したい方はこのファイルをご参照下さい。

この init はシェルスクリプトなので、動かすためにはshell(bash)が必要です。 また、周辺機器の認識用の udevd、 必要なモジュールをロードする modprobe、 root fsをマウントするためのmount等が必要で、 さらにそれらが利用する各種ライブラリ等も必要となり、 それら一式が/binや/lib以下のディレクトリに収められています。

$ ls bin
basename*  cp*  insmod@   kmod*  ls*     mkdir*  mount*     rm*   sh*      umount*
cat*       dd*  killall*  ln*    lsmod@  mknod*  readlink*  sed*  sleep*  uname*

$ ls lib
firmware/              libcap.so.2*                 libm.so.6*         libudev.so.1*
ld-linux-x86-64.so.2*  libdevmapper-event.so.1.02*  libmount.so.1*     libuuid.so.1*
libacl.so.1*           libdevmapper.so.1.02*        libncursesw.so.6*  libz.so.1*
libattr.so.1           libdl.so.2*                  libpthread.so.0*   modules/
libblkid.so.1*         libkmod.so.2*                libreadline.so.7*  udev/
libc.so.6*             liblzma.so.5*                librt.so.1*

$ ls sbin
blkid*     lvdisplay@  lvscan@    pvchange@   pvscan@       vgchange@  vgscan@
dmsetup*   lvextend@   mdadm*     pvck@       switch_root*  vgck@
lvchange@  lvm*        mdmon*     pvcreate@   udevadm*      vgcreate@
lvcreate@  lvrename@   modprobe*  pvdisplay@  udevd*        vgrename@

これらのファイルを含むため、Plamo-7.1の initrd は、圧縮状態で20MB程、 展開すると30MB程度のサイズになります。

 initrd は小さい方が読み込み時間が短くてすみ、起動速度も速くなるため、
 かっては busybox 等を使ってサイズを削減する取り組みが行なわれていました。
 しかしながら、昨今のハードウェア環境ではそれほどサイズを気にする必要も無くなってきたので、
 最近では標準のglibc一式を使って、実環境と互換性を持たせた設計に変ってきています。

このinitrdにはカーネルのドライバ・モジュールが含まれているので、 カーネルを更新する際にはinitrdも合わせて更新する必要があります。 そこで、Plamo-7.1では initrd を作成するための /sbin/mkinitramfs というコマンドを用意しました。

/sbin/mkinitramfs は、 LFS方面で開発されたシェルスクリプトをPlamo用に調整したもので、 必要なディレクトリ構造やデバイスファイルを作り、 システム環境から各種コマンドやライブラリをコピーした上で、 root fsをマウントする際に必要となりそうなモジュール類をコピーし、 cpioアーカイブにまとめた上で圧縮する、という処理を行います。

 具体的にどのようなファイル/モジュールをコピーするのかを知りたい方は、
 /sbin/mkinitramfs をご覧ください。

mkinitramfs は initrd 上にデバイスファイルを作成するため、 実行にはroot権限が必要となります。

$ ls /lib/modules/
4.19.35/  4.19.35-plamo64/  5.1.5-plamo64/

$ sudo /sbin/mkinitramfs 5.1.5-plamo64
[sudo] kojima のパスワード:
Creating initrd.img-5.1.5-plamo64... .
...
 
$ ls -lh initrd.img-5.1.5-plamo64 
-rw-r--r-- 1 root root 20M  6月  1日  12:48 initrd.img-5.1.5-plamo64

こうして作成したinitrdをカーネルと同じディレクトリ(/boot)に配置し、 /sbin/grub-mkconfig を実行すれば、 このinitrdを利用するgrub.cfgが作成されます。 以下の例では、test.cfg として試作しています。

$ sudo /sbin/grub-mkconfig -o test.cfg
Generating grub configuration file ...
Linux イメージを見つけました: /boot/vmlinuz-5.1.5-plamo64
Found initrd image: /boot/initrd.img-5.1.5-plamo64
Linux イメージを見つけました: /boot/vmlinuz-4.19.35_plamo64
Found initrd image: /boot/initrd.img-4.19.35_plamo64
Found Windows Boot Manager on /dev/sda2@/efi/Microsoft/Boot/bootmgfw.efi
Found Plamo Linux release 7.0 on /dev/sda6
Found Plamo Linux release 7.0 on /dev/sda7
Found Plamo Linux release 7.0 on /dev/sdb3 
完了

作成した設定ファイルを、MBR起動の場合は /boot/grub/grub.cfg、 UEFI起動の場合はESP(EFI System Partition)を/boot/efi にマウントした上で /boot/efi/grub/grub.cfg にコピーすれば、 新しく登録したカーネルやinitrdを起動することができます。

なお、grub-mkconfigはカーネルとinitrdを バージョン番号(上記例では 5.1.5-plamo64)で対応づけるので、 両者が一致している必要があります。 特にPlamo環境では、"-"(ハイフン)と"_"(アンダースコア)を混同しがちなのでご注意ください。


2019/6/1 (土)

diary/Kojima

○Plamo-7.1のinitrd対応について

従来、Plamo Linuxでは、起動回りの処理を簡単にするため、initrd は使わないようにしていました。

しかしながら、昨今のカーネルの多機能化や周辺機器の多様化に伴ない、 カーネルにどのドライバを組み込んでいいのかがよく分からなくなってきたため(苦笑)、 Plamo-7.1からはHDD等のブロックデバイスやファイルシステム回りのドライバはinitrd経由で組み込むようにしました。

使用するinitrdは、initrd.img-<kernel_vers>_plamo64 という名前で、 インストールするカーネルパッケージ(Plamo-7.1ではkernel-4.19.35-x86_64-B1.txz)に 収めています。

# tar tvf kernel-4.19.35-x86_64-B1.txz
drwxr-xr-x root/root         0 2019-04-25 11:37:25 boot/
-rwxr-xr-x root/root   4048671 2019-04-25 11:37:00 boot/System.map-.19.35_plamo64
-rwxr-xr-x root/root    221794 2019-04-25 11:37:00 boot/config-4.19.35_plamo64
-rwxr-xr-x root/root   6862720 2019-04-25 11:37:00 boot/vmlinuz-4.19.35_plamo64
-rwxr-xr-x root/root  17596355 2019-04-25 11:37:00 boot/initrd.img-4.19.35_plamo64
drwxr-xr-x root/root         0 2019-04-25 11:33:18 lib/
drwxr-xr-x root/root         0 2019-04-25 11:33:18 lib/modules/
drwxr-xr-x root/root         0 2019-04-25 11:37:25 lib/modules/4.19.35-plamo64/
drwxr-xr-x root/root         0 2019-04-25 11:36:55 lib/modules/4.19.35-plamo64/kernel/
drwxr-xr-x root/root         0 2019-04-25 11:33:19 lib/modules/4.19.35-plamo64/kernel/arch/
....

initrd を起動時に読み込ませるには grub.cfg に設定が必要なものの、 付属の grub-mkconfig でgrub.cfgを作れば、 カーネルのバージョンに適合したinitrdイメージを自動的に見つけて登録してくれるので、 特に何もする必要はありません。

grub.cfg(MBRの場合は /boot/grub/grub.cfg, UEFIの場合は/boot/efi/grub/grub.cfg) の該当箇所は、以下のようになります。なお、root=UUID=... の部分は、 環境ごとに異なります。

   echo    'Loading Linux 4.19.35_plamo64 ...'
   linux   /boot/vmlinuz-4.19.35_plamo64 root=UUID=47749fa2-16d6-4b5a-bb44-9538e8605ac3 ro  net.ifnames=0 quiet
   echo    'Loading initial ramdisk ...'
   initrd  /boot/initrd.img-4.19.35_plamo64

このgrub.cfgから起動すると、画面に一瞬、以下のような grub の起動メッセージが表示され、

Loading Linux 4.19.35_plamo64 ...
Loading initial ramdisk ...

その画面がクリアされると initrd のメッセージが表示され、

mdadm: No arrays found in config file or automatically
Successfully mounted device UUID==47749fa2-16d6-4b5a-bb44-9538e8605ac3

その後、init の起動メッセージが表示される、という順番になります。

Init version 2.88 booting
  *  Mounting virtual file systems: /run                            [OK]
  *  Bring up the loopback interface...                             [OK]
  *  Setting hostname to plamolinux.linet.jp...                     [OK]
     Populating /dev with device nodes...

起動処理はこういうステップで進むはずですが、もし途中で、

 "The device XXX, which is supposed to contain the
  root file system, does not exist.
  Please fix this problem and exit this shell."

とか

"Could not mount device XXXX
 Sleeping forever. Please reboot and fix the kernel command line."

みたいなエラーが出て止まってしまう場合は、 何らかの理由で initrd が本来のroot filesystemをマウントできていません。 この種のエラーの多くは環境依存なため手元での再現が難しいものの、 機器構成等を報告いただければ、可能な限り対応します。


2019/3/13 (水)

diary/Kojima

・手作りチョコレート

バレンタインデーに手作りチョコレートのキットをもらったもので、ホワイトデーにあわせて作ってやろうかと挑戦。

P_20190312_093001.jpg

ホントに「手作り」で、焙煎したカカオ豆の皮を剥くところから始まる(w。

P_20190312_100729.jpg

皮を剥いたら100gのカカオ豆が87gほどになった。ここまでで経過時間約40分。

P_20190312_103946.jpg

説明書ではここから50分くらいかけてすり鉢で砕いていくことになっているのだけど、コーヒーミルがあったので、まずそれで粉砕しておく。

P_20190312_104416.jpg

後はひたすらすり鉢でゴリゴリ細かくしていく。

P_20190312_105654.jpg
P_20190312_110637.jpg

湯煎をしつつ、40分弱すり鉢で錬っていくと、だんだん油分が出てきてまとまってくる。

P_20190312_112108.jpg

同梱されていた甜菜糖30gを投入し、さらに擂り続ける。

P_20190312_113136.jpg
P_20190312_113814.jpg

砂糖が入ると、いったんパサパサになるものの、メゲずに擂り続けると、再度油分が出てきて全体的にねっとりしてくる。

P_20190312_120056.jpg

約1時間擂り続けると、チョコレートっぽいツヤとねばりも出てきた。

P_20190312_122504.jpg

付属の型に流しこんで何とか完成。最初に多めに入れすぎたせいか、3つ分ほど足りなかった(;_;)

P_20190312_124038.jpg

カカオ豆が87g、甜菜糖が30gだから、87/(87+30)=0.7435、カカオ分74%のチョコレートってところか。

60℃ほどの温度で擂り続ければ、あれだけ油分が出てくるというのはちょっとびっくりだったけど、すり鉢の溝よりも粒子は細かくならないから、4時間弱擂り続けてもまだちょっと粗さを感じるところ。いかに粒子を細かくして滑らかにするかがチョコレート作りのツボっぽい印象。

まーでも、一度やったら十分だわ(苦笑


2019/2/18 (月)

diary/Kojima

・LinuxでのBluray Disc再生の現状(その3)

前回紹介したように、smplayer/mpvならば bd:////dev/sr1 というURL指定で Blurayメディアが再生できるようになったはずなのに、 日を改めて再度試すと「MPlayer/mpvは予期せず終了しました。終了コード:2」という メッセージでエラー終了してしまう。

smplayer_ng.jpg

エラーログはこんな感じ。

/usr/bin/mpv --no-config --no-quiet --terminal --no-msg-color
   --input-file=/dev/stdin --msg-level=ffmpeg/demuxer=error --no-fs
   --hwdec=no --sub-auto=fuzzy --no-input-default-bindings
   --input-vo-keyboard=no --no-input-cursor --cursor-autohide=no
   --no-keepaspect --wid=62914577 --monitorpixelaspect=1 --osd-level=1
   --osd-scale=1 --osd-bar-align-y=0.6 --sub-ass --embeddedfonts
   --sub-ass-line-spacing=0 --sub-scale=1 --sub-font=Arial
   --sub-color=#ffffffff --sub-shadow-color=#ff000000
   --sub-border-color=#ff000000 --sub-border-size=0.75 --sub-shadow-offset=2.5
   --sub-font-size=50 --sub-bold=no --sub-italic=no --sub-codepage=ISO-8859-1
   --vid=1 --aid=2 --sid=1 --secondary-sid=1 --sub-pos=100 --volume=86
   --cache=auto --start=668 --screenshot-template=cap_%F_%p_%02n
   --screenshot-format=jpg
   --screenshot-directory=/home/kojima/画像/smplayer_screenshots
   --audio-pitch-correction=yes --volume-max=110
   --term-playing-msg=MPV_VERSION=${=mpv-version:}
INFO_VIDEO_WIDTH=${=width}
INFO_VIDEO_HEIGHT=${=height}
INFO_VIDEO_ASPECT=${=video-aspect}
INFO_VIDEO_FPS=${=container-fps:${=fps}}
INFO_VIDEO_FORMAT=${=video-format}
INFO_VIDEO_CODEC=${=video-codec}
INFO_AUDIO_FORMAT=${=audio-codec-name}
INFO_AUDIO_CODEC=${=audio-codec}
INFO_AUDIO_RATE=${=audio-params/samplerate}
INFO_AUDIO_NCH=${=audio-params/channel-count}
INFO_LENGTH=${=duration:${=length}}
INFO_DEMUXER=${=current-demuxer:${=demuxer}}
INFO_SEEKABLE=${=seekable}
INFO_TITLES=${=disc-titles}
INFO_CHAPTERS=${=chapters}
INFO_TRACKS_COUNT=${=track-list/count}
METADATA_TITLE=${metadata/by-key/title:}
METADATA_ARTIST=${metadata/by-key/artist:}
METADATA_ALBUM=${metadata/by-key/album:}
METADATA_GENRE=${metadata/by-key/genre:}
METADATA_DATE=${metadata/by-key/date:}
METADATA_TRACK=${metadata/by-key/track:}
METADATA_COPYRIGHT=${metadata/by-key/copyright:}
INFO_MEDIA_TITLE=${=media-title:}
INFO_STREAM_PATH=${stream-path}
 --audio-client-name=SMPlayer --term-status-msg=STATUS: ${=time-pos} / ${=duration:${=length:0}}
 P: ${=pause} B: ${=paused-for-cache} I: ${=core-idle}
 VB: ${=video-bitrate:0} AB: ${=audio-bitrate:0} bd:////dev/sr1
Playing: bd:////dev/sr1
aacs.c:546: Error calculating media key. Missing right processing key ?
[bd] AACS error: no matching processing key
No protocol handler found to open URL bd:////dev/sr1
The protocol is either unsupported, or was disabled at compile-time.
Exiting... (Errors when loading file)

「あれれ、、昨日まではちゃんと再生できてたのに何で？？」と首をひねりつつ、 ライブラリや環境変数、PATH等を確認するも異常なし。

「じゃぁ、makemkvだと？」と、modprobe sg してから makemkv を実行すると、 makemkv からは問題なくディスクを読み込める。

「えー、なんで？？」と首を傾げつつ、smplayerで試すと、 今度はちゃんとBDを読み込んで、前回同様に再生できるようになった。

再生できるようになったログ(コンソールに出力される)はこんな感じで、 "aacs.c:546: Error calculating media key. Missing right processing key ?" というエラーは再生できなかった場合と同様に出力されているものの、 その後は"[bd] List of available titles:"、 "[bd] idx: 0 duration: 00:00:00 (playlist: 0001"、 という形でメディアを読み出せている。

Debug: SMPlayer::processArgs: arguments: 2
Debug: SMPlayer::processArgs: 0 = smplayer
Debug: SMPlayer::processArgs: 1 = bd:////dev/sr1
Debug: SMPlayer::processArgs: files_to_play: count: 1
Debug: SMPlayer::processArgs: files_to_play[0]: 'bd:////dev/sr1'
Debug: SMPlayer::gui: changed working directory to app path
Debug: SMPlayer::gui: current directory: /usr/bin
Debug: Screen::setAutoHideCursor: 0
Debug: Screen::setAutoHideCursor: 0
Debug: Images::setTheme: "H2O" is an internal theme
Debug: Images::setThemesPath: ""
Debug: MediaSettings::reset
Debug: Core::changeFileSettingsMethod: hash
Debug: PlayerID::Player: player_bin: "/usr/bin/mpv" filename: "mpv"
...skipping...
Debug: BaseGui::checkStayOnTop
 Debug: MPVProcess::parseLine: "aacs.c:546: Error calculating media key. Missing right processing key ?"
Debug: BaseGuiPlus::updateShortcutsContext
Debug: BaseGui::checkReminder
Debug: MPVProcess::parseLine: "[bd] List of available titles:"
Debug: MPVProcess::parseLine: "[bd] idx:   0 duration: 00:00:00 (playlist: 00010.mpls)"
Debug: MPVProcess::parseLine: "[bd] idx:   1 duration: 01:36:59 (playlist: 00001.mpls)"
Debug: MPVProcess::parseLine: "[bd] idx:   2 duration: 00:00:00 (playlist: 00011.mpls)"
....

あれこれ試してみたところ、どうやらシステムを再起動してしまうと、 一度makemkvを実行しない限り、smplayerでBDが再生できる状態にはならないらしい。

一方、一度smplayerで再生できるようになると、 別のディスクに取り替えても問題なく再生できるし、 suspend/resumeしても、その状態は変わらない。

これらを合わせ考えると、 どうやら makemkv はBDメディアを読み出すだけではなく、 ドライブ(のfirmware?)に対しても何らかの処理を施して、 AACSの復号化を容易にしているような感じ。 一度その処理を施されたドライブは、 再起動して初期化されるまではその状態を維持し続けるのだろう。

ということで、LinuxでBDメディアを再生するには、smplayer/mpvを使う場合でも、 makemkvの手を借りる必要がある、というのが現状での結論。

「その1」でも触れたように、 makemkvはコアの部分は非公開なsharewareなものの、 GUIはソースコードを公開しているし、 コアの部分のAPIもlibmmbd.so経由で外部から使えるらしいから、 ずいぶん良心的なソフトだと感じているので、 試用期間を延長するためのコードを毎月入力するよりも、 ちゃんとレジストレーション(6256円+消費税500円 らしい)して、 Linux版の開発を支援した方がいいかな、、と思っているところ。

まぁ、厳密に言うと、正当に入手したBDメディアでも、 AACSを解除してMKV形式に変換するのは、 日本の今の著作権法では違法になるので、

$ sudo modprobe sg
$ makemkvcon info dev:/dev/sr1

でBDドライブを初期化して、後はsmplayerあたりで直接視聴する、 というのが精神衛生上もよろしかろうということで。


<<前の10件次の10件>>
トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS