メモがわりのブログ: Debian

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

2020年1月21日火曜日

Chromium 79.0.3945.79-1 (Debian sid)がSEGVる (1/21: version upで解決済み)

*** update ***

2020-01-21、Sidにてchromiumがupdateされていて (79.0.3945.79-1 → 79.0.3945.130-2)、こちらのversionでは特に問題なく使用できている。

*** updateここまで ***

Web browserのchromiumを79.0.3945.79-1 (12/19現在の最新版)にupgradeしてからSEGVるようになった。起動しないとか、起動してすぐとかではなく、しばらくするといつの間にか落ちている感じ。

Debian Bug Tracking System (BTS)を見てみると既に複数の報告がなされている:

cf. [#945920 - Chromium randomly crashes in the latest version. - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945920)

現状でできる対策は前のversion (78.0.3904.108-1とか)に戻すことだが、もしかしたらsecurity flawとかがあるかも知れない。

2019年7月28日日曜日

Debianで暗号化したroot fsを読めなくなりunbootableになった

Linux kernel 5.2.3のreleaseに伴ったupgradeを実施してrebootした所、LUKSで暗号化したroot filesystemが読めず (passphraseを尋ねてくるpromptも出ず)にunbootableに陥った。

原因は、dependencyの関連でcryptsetup-initramfsというpackageがuninstallされ、その後にregenerateされた/boot/initrd.imgにcryptsetup関連のbinaryが含まれなくなったことだった。

症状と対策

* Linux kernelがloadされboot processは進行するが、暗号化されたroot filesystemが開けずにretryを繰り返して何れgive upする
* 前回別のmachineでGRUB2関連のトラブルを経験していたので、GRUB2 (今回はx86_64-efi)を入れ直したのだが↑と同じ症状でbootできず
* 以前のkernel (v5.1.15)からbootできることに気付き、kernel optionなどの変更によるものかと疑いはじめる。また、他のinitrd.imgと比較した所、bootできないinitrd.imgは1MBほどsizeが小さくなっていると気付き、ここに問題が潜んでいると推定
* 通常の方法では中に含まれているものが見えないので、lsinitramfsという専用のprogramで中身を検めた所、cryptsetup関連のprogramなどが含まれていないと判明
* 最終的にcryptsetup-initramfsというpackageがuninstallされていたことに気付いて再びinstallし、initrd.imgをregenerate (update-initramfs)して解決した

蛇足

根本的な理由に辿り着くまで非常に時間が掛かったのだが、それは以下の要因のため。

* 数日前に別のmachine (Linux box)でGRUB2関連のトラブルに遭遇していた。今回もそれに類似する、或いは見た目は違っていても根本に同じ問題があるのではないかと推定し (結果的に外れていた)、そちらの問題の解消のため作業に取り掛かった

* 前回のmachineと今回のmachineでは使っているGRUB2の種類が違っており、作業に慣れていなかった。前回はDOS形式のdiskにi386-pc方式でMBRにGRUBをinstallしていたが、今回はGPT形式のdiskにx86_64-efi方式でEFI領域にGRUBをinstallしていた

* LVMの扱いに習熟していなかった

参照したwebsites

* [mount: unknown file system type LVM2_member | SvennD](https://www.svennd.be/mount-unknown-filesystem-type-lvm2_member/)
* [Recovering from an unbootable Ubuntu encrypted LVM root partition](https://feeding.cloud.geek.nz/posts/recovering-from-unbootable-ubuntu-encrypted-lvm-root-partition/)
* [GRUB - ArchWiki](https://wiki.archlinux.jp/index.php/GRUB#GUID_Partition_Table_.28GPT.29_.E7.89.B9.E6.9C.89.E3.81.AE.E6.89.8B.E9.A0.86)

2019年5月6日月曜日

パスコードでロックされたiPad mini 2をfirmware等の入れ直しで復旧する

これは何？

パスコードロックされた状態のiPad mini 2 (以下、iPad)を、idevicerestoreというtoolで初期化し、Windows 10のiTunesを使ってiOS 12.2にupdate後、新しいApple IDと紐付けた時の記録。

動機と目的

iPad mini 2を譲り受けた。先方で本体内データは削除済みとのことで早速自分のApple IDに紐付けしようとしたが、パスコードを要求されてしまった。先方と相談しながら思い当たるパスコードを入力したのだが結局分からず、最終的に「このiPadは使用不可能」な状態 (=パスコードロック)に陥る。

色々調べてみると、idevicerestoreというtoolでLinux boxからfirmwareなどを書き込んで強制的に初期化＆パスコードロック解除できる (勿論内部のデータは消える)と分かったので試してみた。

用意するもの

* Apple iPad mini 2
* USB-A to Lightning cable
* Linux box (w/ Debian GNU/Linux) ※idevicerestoreを利用するためのmachine
* Windows box (w/ Microsoft Windows 10) ※iTunesを利用するためのmachine

手順

idevicerestoreのinstall

Linux boxにidevicerestoreをinstallする

* libusb-devやlibimobiledevice-*あたりをinstallしておく
* idevicerestoreがdependしているlibirecoveryをinstall
* idevicerestoreをinstall

iPadの強制再起動

* Linux boxにiPadを接続する
* iPadをホームボタン＋スリープボタン同時長押しで強制再起動する

idevicerestoreでiPadにfirmwareを書き込む

* sudo idevicerestore -l -n ※iPadを認識するかを確認する
* sudo idevicerestore -l -x ※basebandをupdateしない (-x)

iTunesでiPadのiOSをupdateする

iPad単独でもiOSをupdateできるはず、もしくはiTunesでなくてもupdateできるらしいが今回は試していないので割愛。

* Windows 10 machineにApple iTunesをinstallする
* iTunesを立ち上げる
* iPadをWindows boxに接続する
* iTunesがiPadを認識したかを確認し、updateなどに関するwindowが出るのを待つ
* 必要に応じてupdateなどを行う

補遺

* iPadのデータを消したくない場合は別の方法を取る必要がある
* 有料のツールを使うのも手。3000〜4000円ぐらいからあるので、急ぎで確実に行いたいならばそちらを使うのも良いだろう

参照したwebsites

基礎知識について

* [Show UDID of iPhone Using awk, cut, grep, lsusb, sed](https://www.commandlinefu.com/commands/view/9632/show-udid-of-iphone)
* [ECID - The iPhone Wiki](https://www.theiphonewiki.com/wiki/ECID)

Softwareのrepositories

* [GitHub - libimobiledevice/idevicerestore: Restore/upgrade firmware of iOS devices](https://github.com/libimobiledevice/idevicerestore)
* [GitHub - libimobiledevice/libirecovery: Library and utility to talk to iBoot/iBSS via USB on Mac OS X, Windows, and Linux](https://github.com/libimobiledevice/libirecovery)

その他

* [Device never fully restores · Issue #124 · libimobiledevice/idevicerestore · GitHub](https://github.com/libimobiledevice/idevicerestore/issues/124) ※-x option

2018年12月9日日曜日

HiKey 620 (HiKey LeMaker)へのDebian stretch (stable) installで嵌った

*** 更新履歴 ***

* 2019-01-28 画像にミスがあったので差し替え (WiFi/BT chipの名称を修正)

*** 更新履歴ここまで ***

※この記事で紹介しているHiKey 620 (HiKey LeMaker)は古い (2015年頃の)SBCなので、これから購入するのなら後継機であるHiKey 960やHiKey 970或いはDragonBoard 410cなどが推奨される

図1 HiKey 620とmicroSD card

図2 表面のIC配置

図3 インタフェースの配置

結論: 公式websiteのdocumentに従おう

これからHiKey 620 (HiKey LeMaker)にDebianをinstallしたい人が参照すべきdocuments

cf. [Documentation for HiKey - 96Boards](https://www.96boards.org/documentation/consumer/hikey/hikey620/)

英語だが難しくないので、downloadするfilesや手順を確認しつつ従っていけばできるはず。

重要な点としては、

* 最初にrecovery.binをhisi-idt.pyで書き込むこと
* この時にPython 2.7を使うこと

簡単な経緯

* HiKey 620 (LeMaker version)、以下HiKeyにDebian stretchを導入しようと考えた
* 以前eMMCにinstallしていたDebian jessie (oldstable) → stretch (stable)にupgradeする最中に止まってunbootableになった
* eMMCにUEFIを導入するために色々試してみたがことごく失敗 (switch scienceやDebian Wikiの手順など)
* Linaroの公式websiteのdocumentをよく見ると、他で紹介されている手順とは異なっていることに気付く (hisi-idt.pyでrecovery.binを書き込むなど)
* Linaroの公式documentのやり方に従ったらDebian stretchの導入に成功

Debian Wikiやswitch scienceで紹介されている(古い)手順から変更されていることに気付くのが遅れて、随分遠回りをする羽目になった。もう一度改めて書くが、

上で紹介したLinaro公式websiteのdocumentに従うこと

を強く推奨する。

おまけ

microSD cardからのboot

Setting jumper の1-2をclose、3-4と5-6はopenにしておく。

root partitionの拡張

SD cardにDebianをinstallした場合、SD cardの一部の領域 (たぶん1.8GiBぐらい)しか利用されていない。Raspberry Pi seriesにinstallするRaspbianの場合はinstallerが拡張してくれるoptionがあるが、こちらはfdisk等を使って手動で行う必要がある。

* fdisk /dev/mmcblk1
* partition tableの表示 (p)
* partition 1がboot partition、partition 2がDebianのroot (ext4)
* ここで一旦partition 2を消す (d)
* 以前partition 2だった部分を含めたpartitionを改めて作製する (n) → 新生partition 2
* ext4のsignatureが残っているけどどうするかを聞かれたら「残す」を選択
* 一応書き込んでおく (w) ※著者の環境では失敗しfdiskから抜けた

動いているLinux kernelは変更前のpartition tableの情報を持ったままなので、更新するためにHiKeyをrebootする。無事に立ち上がったらsudo resize2fs /dev/mmcblk1p2を発行。ext4の場合、filesystemをonlineで拡張できる。

最後に確認すると、こんな感じになるはず:

linaro@linaro-developer:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 912M 0 912M 0% /dev
tmpfs 196M 5.4M 191M 3% /run
/dev/mmcblk1p2 29G 1.6G 26G 6% / ← root filesystem
tmpfs 979M 0 979M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 979M 0 979M 0% /sys/fs/cgroup
/dev/mmcblk1p1 64M 848K 64M 2% /boot/efi
tmpfs 196M 0 196M 0% /run/user/0
tmpfs 196M 0 196M 0% /run/user/1000

今回は32GB (=29.8GiB)のmicro SD card (Toshiba)を使ったので、root partitionが29Gである。

2018年11月24日土曜日

Debian packageのinstall/uninstall processが失敗した時に手動でどうにかする方法

Debian packageのinstall/uninstall processの実体は、packageに含まれている幾つかのshell scriptである。

これらは/var/lib/dpkg/info/以下に展開されており、例としてx11-utils packageについてのfilesは、

x11-utils.conffiles
x11-utils.list
x11-utils.md5sums
x11-utils.postinst
x11-utils.postrm

がある。このうち、scriptが.postinstと.postrmの2つで、名前の通りそれぞれinstall後及びuninstall後に実行される内容が記述されている。

何かしらの要因でinstall scriptに不具合が発生してinstall processが失敗する時 (unstableでは時々ある)は、ここを直接修正すれば中途半端な状態を解消できる可能性がある。

最近では、iptables packageのpostinst scriptにinstall (upgrade)が失敗する不具合があった (2018-11-24現在修正済み)。この場合は、/var/lib/dpkg/info/iptables.postinstを手動で修正してaptitudeなどからupgradeをやり直した。

cf. [#913811 - iptables fails to upgrade from 1.8.1-2 to 1.8.2-1 - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913811)

2018年10月21日日曜日

Debian sidでnfsdが立ち上がらなくなったのでscriptを修正 (sysvinit)

*** 注意 ***

Debianはinit daemonとしてsystemdを採用している。

個人的な趣味から今回の問題が起きたPCではsystemdを入れていない (sysvinitで運用)。おそらく、maintenanceされていないsysvinit用のscriptが原因でこのような問題が発生したと考える。

よって、普通にsystemdを使っているuserにはaffectしない。

*** 注意ここまで ***

大容量HDDを搭載したPCでnfsdを立ち上げて、LAN内にあるPCからNFSv4でmountできるようにしてあるのだが、kernelのupgrade後にmountできなくなった。

Debianでは、NFSの機能がnfs-commonとnfs-kernel-serverに分割されている。このうちnfs-commonの方は問題なかった。

一方、nfsdが立ち上がっていないし、以下のようなmessageも出るので、nfs-kerrnel-server側のscript内でerrorが発生しているとわかった。

% sudo service nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd
[warn] Not starting: portmapper is not running ... (warning).

script (/etc/init.d/nfs-kernel-server)を眺めてみると、92-99行にportmapperがどうのというwarningを出力する箇所で、rpcinfoというcommandへのpathが$PREFIX/sbin/rpcinfoとなっている:

# See if rpcbind is running
$PREFIX/bin/rpcinfo -p >/dev/null 2>&1
RET=$?
if [ $RET != 0 ]; then
echo
log_warning_msg "Not starting: portmapper is not running"
exit 0
fi

rpcinfoのreturn valueがnon zeroなのでifに引っ掛かってexit 0している訳だ。

rpcinfoがどういう出力なのか確かめてみようと打ってみる:

% sudo /usr/sbin/rpcinfo -p
sudo: /usr/sbin/rpcinfo: command not found

/usr/sbin/rpcinfoが存在しない。では、rpcinfoがどのpackageに含まれているのか (あるいは存在しないのか)調べてみる:

% dpkg -S rpcinfo
rpcbind: /usr/bin/rpcinfo
nmap-common: /usr/share/nmap/scripts/rpcinfo.nse
rpcbind: /usr/share/man/man8/rpcinfo.8.gz

sbinじゃなくてbinになっている。移動したようだ。では改めて:

% /usr/bin/rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 57281 status
100024 1 tcp 59599 status
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 3 tcp 2049
100003 3 udp 2049 nfs
100227 3 udp 2049
100021 1 udp 49265 nlockmgr
100021 3 udp 49265 nlockmgr
100021 4 udp 49265 nlockmgr
100021 1 tcp 33993 nlockmgr
100021 3 tcp 33993 nlockmgr
100021 4 tcp 33993 nlockmgr
100005 1 udp 49349 mountd
100005 1 tcp 53921 mountd
100005 2 udp 60977 mountd
100005 2 tcp 32831 mountd
100005 3 udp 52847 mountd
100005 3 tcp 49695 mountd

scriptではrpcinfoの実行結果 (というか出力は/dev/nullに棄てて、return valueだけを見て)からportmapperがsupportされているかどうかを確認していた。この出力を見る限り、portmapperはsupportされていると分かる。

scriptの当該箇所を修正 ($PREFIX/sbin/rpcinfo → $PREFIX/bin/rpcinfo) して、改めて試してみる:

% sudo service nfs-kernel-server restart
[ ok ] Stopping NFS kernel daemon: mountd nfsd.
[ ok ] Unexporting directories for NFS kernel daemon....
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd mountdrpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
rpc.mountd: svc_tli_create: could not open connection for udp6
rpc.mountd: svc_tli_create: could not open connection for tcp6
. ok

ここでtcp6やudp6に関するerror或いはwarningが出ているのは、IPv6を使ってないのでkernel levelでsupportを切っているため。明示的に使っていなくても切らない方がいいのかも知れない。或いは、/etc/netconfigのtcp6とudp6の行をcomment outする手もある。

何れにしてもnfsdが立ち上がるようになり、NFS clientからもmountできるようになった。

今回このような問題が発生したのは、Debianではinit daemonがsystemdに変更されたため、sysvinitに由来するscriptが既にmaintenanceされていないからと考えられる。

2018年10月19日金曜日

Debian packageのdependencyをごまかして (強制的に) installする方法

*** 更新情報 ***

2018-10-22現在、Debian sidにおけるcalibreの最新版はqtbase-abi-5-11-2へ対応したversionへ更新されたので、以下の不整合は発生しない。

*** 更新情報ここまで ***

calibreというebook readerがある。

読むだけではなく、formatの変換なども行える (swiss army knife的に)多機能なsoftwareで、個人的に使えないと非常に困るのだが、先にupdateされるQt libraryへのdependencyで不整合を起こしuninstallされ (かけ)ることがままある。

最近も、Qt relatedなpackagesが更新されて、これらが提供するvirtual packageであるqtbase-abi-5-11-0がqtbase-abi-5-11-2へ上がった。calibreの実体programを提供するpackageであるcalibre-bin 3.32.0_dfsg-1+b1はqtbase-abi-5-11-0にdependしているため不整合を起こしてuninstallされかけた。

calibreを新しいQtとlinkしてbuildした上でcontrolを修正するのが最も真っ当な方法だが、たかが5.11.0 → 5.11.2の変化ならどうにかなるだろう、という根拠のない推測からdependencyをごまかしてuninstallされないようにした。実際、calibreは無事立ち上がり、特に問題なく動作しているので、ひとまずこの状態で使ってみる。

無論、ABIのversionが変わっている以上互換性は保証されず、強制的にinstallしても動作しなかったり、意図しない動作になったりする可能性があるので注意。

やり方の概要

以前にも同じようなことをした記憶があったので検索してみた所、

cf. https://typeinf-memo.blogspot.com/2015/08/debian-unstable-sidexperimental.html

に似たような記事を書いていた。

前回はcontrolから不要なdependencyを削除していたが、今回もやることは余り変わらない (今回はversionを書き換えるだけ)。

* binary packageをdownloadして展開
* control.tar.xzを展開してcontrolを書き換える
* 改編したcontrolを含むcontrol.tar.xzを生成
* 変更したcontrol.tar.xzを含むbinary packageを生成
* installして動作確認

具体的な手順

* calibre-binのbinary packageをdownload

% apt-get download calibre-bin

* arでbinary packageを展開

% ar x calibre-bin_3.32.0_dfsg-1+b1_amd64.deb

control.tar.xz、data.tar.xz、debian-binaryが生成される。

* control.tar.xzを展開

% tar xJf control.tar.xz

control、md5sumsが生成される

* 適当なtext editor (vimなど)でcontrolを書き換える。今回の場合"qtbase-abi-5-11-0"を"qtbase-abi-5-11-2"へ書き換えて保存する

* 書き換えたcontrolを含むcontrol.tar.xzを作る

% tar --create --file control.tar.xz --xz md5sums control

* 作り直したcontrol.tar.xzを含むbinary packageを生成する

% ar rcs calibre-bin_3.32.0_dfsg-1+b1_amd64.deb debian-binary control.tar.xz data.tar.xz

* dpkg -iでinstallし動作確認

% sudo dpkg -i calibre-bin_3.32.0_dfsg-1+b1_amd64.deb

* aptitudeなどを使っている場合はupdateによる書き換えを防ぐためにcalibre-binをholdしておくとよい

おつかれさまでした。

2017年12月26日火曜日

SwissMicros DM42のfirmware update (w/ dfu-util)

update information:

* 2018-10-15: 2018-10-07にfirmware v3.11がreleaseされた。USB cable接続時にfreezeするbugが解決されたのでupgrade推奨
* 2018-03-26: 2018-03-25にfirmware v3.5がreleaseされた
* 2018-02-19: 2018-02-12にfirmware v3.3がreleaseされた
* 2018-01-07: 2018-01-05にfirmware v3.2がreleaseされた

(追記は以上)

届いたDM42のfirmwareはv3.0だったので、2017-12-26現在の最新版であるv3.1にupgradeした。

upgrade前 (v3.0)

upgrade後 (v3.1)

手順はhttps://www.swissmicros.com/dm42/doc/dm42_user_manual/#_firmware_updateに詳しく解説されているので参照のこと。

たぶん、Windowsでdm_toolを使ったfirmware upgradeは誰かがやっていると思うので、Linux (Debian)からdfu-utilを使ってやってみた。

概要

必要なもの

* SwissMicros DM42
* Linux box (w/ USB)
* USB cable (A-microB)
* 細いピン (或いは伸ばしたゼムクリップ)

手順

準備 ※一度行えば以降は不要

* Linux machineにdfu-utilをinstall (apt-get install dfu-util)
* DM42を認識するようにudevを設定 (あるいはsudoでdfu-utilを使う)

firmware update

* firmwareをdownload (DM42_flash_XX.bin)
* DM42をbootloader modeに移行
* DM42とLinux machineをUSB cableで接続 (DM42側はmicroUSB, PC側はA)
* dfu-utilsで書き込み
* DM42の背面にあるRESET buttonを細いピンのようなもので押してreset

実際のlog

USB cableでDM42 (bootloader mode)を接続した際のdmesg。

% dmesg
...
[676590.811335] usb 1-1.7: new full-speed USB device number 8 using ehci-pci
[676590.890786] usb 1-1.7: New USB device found, idVendor=0483, idProduct=df11
[676590.890789] usb 1-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[676590.890791] usb 1-1.7: Product: STM32 BOOTLOADER
[676590.890792] usb 1-1.7: Manufacturer: STMicroelectronics
[676590.890794] usb 1-1.7: SerialNumber: ************

dfu-utilで認識しているか確認。

% dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="1-1.7", alt=2, name="@OTP Memory /0x1FFF7000/01*0001Ke", serial="************"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="1-1.7", alt=1, name="@Option Bytes /0x1FFF7800/01*040 e/0x1FFFF800/01*040 e", serial="2069328B4834"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="1-1.7", alt=0, name="@Internal Flash /0x08000000/512*0002Kg", serial="************"

実際の書き込み。

% dfu-util -D DM42_flash_3.1.bin -d 0483:df11 -a "@Internal Flash /0x08000000/512*0002Kg" -s 0x8000000
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 865928
Download [=========================] 100% 865928 bytes
Download done.
File downloaded successfully

蛇足: 失敗例

ちなみに、CLIで実行する場合には手順を説明したpageから (ここからではなく)のcopy'n'pasteを推奨する。著者は-s 0x8000000とすべきところを-s 0x800000と「0」を1つ少なく書いたばかりに「書き込めない」とのerrorを見る羽目になった。

% dfu-util -D DM42_flash_3.1.bin -d 0483:df11 -a "@Internal Flash /0x08000000/512*0002Kg" -s 0x800000

dfu-util 0.9

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature

dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

Opening DFU capable USB device...

ID 0483:df11

Run-time device DFU version 011a

Claiming USB DFU Interface...

Setting Alternate Setting #0 ...

Determining device status: state = dfuIDLE, status = 0

dfuIDLE, continuing

DFU mode device DFU version 011a

Device returned transfer size 2048

DfuSe interface name: "Internal Flash "

Downloading to address = 0x00800000, size = 865928

dfu-util: Last page at 0x008d3687 is not writeable

2017年12月2日土曜日

PostgreSQL10への移行に伴うMediaWikiのupgrade

注: 2017-09-23ごろの情報なので古い (eg. PostgreSQLは10rc1ではなく10.1になっている)が、うっかり忘れていたので今更ではあるがup。

PostgreSQLをupgradeした際 (cf. http://typeinf-memo.blogspot.com/2017/09/postgresql-10.html)に、PostgreSQLをbackendとして利用しているMediaWikiのupgradeも行ったのでメモ。

環境は:

* Debian GNU/Linux (AMD64)
* MediaWiki 1.29.1
* Nginx 1.13.5-1
* PHP-FPM 7.0.22-3
* PostgreSQL 10rc1

という、主流ではない構成なので注意。大体の場合はapache2 + php module + MySQLとか、nginx + php-fpm + mariaDBとかだと思う。

MediaWiki本体のupgrade手順

* sudo service php7.0-fpm stop
* sudo service nginx stop
* cd /path/to/wiki/
* git checkout <VERSION>
* cd maintenance/
* php update.php
* sudo service nginx start
* sudo service php7.0-fpm start

※MediaWikiをgitでinstallする場合は、必要に応じてPHPのpackage managerであるcomposerのupdateを行う → composer update

外部packageのupgrade

pg_upgradeclusterを使ったdatabaseの移行に際し、必要に応じてtextsearch_jaなど外部packageのupgradeも行う

* make USE_PGXS=1
* sudo make USE_PGXS=1 install
→ これで/usr/lib/postgresql/10/textsearch_ja.so他必要filesがinstallされる

sudo -u postgres psql -f /usr/share/postgresql/10/contrib/textsearch_ja.sql wikidb
が失敗する場合は、一度uninstallを試みる
sudo -u postgres psql -f /usr/share/postgresql/10/contrib/uninstall_textsearch_ja.sql
そしてもう一度改めてinstallを試みるとうまくいく場合がある

MediaWikiでerrorが出た時見るべきlog files

* MediaWikiのlogは、LocaleSettings.phpの$wgDebugLogFile = "/path/to/the/debuglogfile";で指定する。comment outするとlog fileを作らない
* /var/log/postgresql/
* /var/log/nginx/
* /var/log/syslog
* /var/log/php7.0-fpm.log

2017年9月23日土曜日

PostgreSQL 10への移行

PostgreSQL 9.6 → PostgreSQL 10への移行作業について。

Debian SidにPostgreSQL 10のrc1が入ったので移行した。

upgradeの手順は/usr/share/doc/postgresql-10/README.Debian.gzの"Default clusters and upgrading"にある通り。

cf. PostgreSQL 9.5→9.6へupgradeに伴うMediaWikiへの影響と対策
(https://typeinf-memo.blogspot.jp/2016/09/postgresql-9596upgrademediawiki.html)

PostgreSQLのupgradeに伴うdatabaseの移行手順

現行のdatabase serverを止める

% sudo service postgresql stop

※ps aux | grep postgresqlあたりで確認して止まっていない場合:

% sudo pg_ctlcluster 10 main stop

Install時に自動で作られた新しいversionの (空の)database clusterを削除

10をinstallした際に自動で作られたclusterをdrop:

% sudo pg_dropcluster 10 main

pg_upgradeclusterでdataを移行する

今回は9.6 → 10へ移行:

% sudo pg_upgradecluster 9.6 main

Portの変更

新しい側 (10)のport numberはinstall時に5433なので、これをdefaultの5432に変更する。うっかり忘れるとphp-fpmなど外部のprocessからdatabaseに接続できなくなる。

或いはclient側を新しいport numberに接続するよう変更する。

% sudoedit /etc/postgresql/10/postgresql.conf

新しいdatabaseを立ち上げる

% sudo pg_ctlcluster 10 main start

動作を確認した後、古い方のversionを削除する

必要に応じて。

2017年7月7日金曜日

libc6 (glibc)をgcc-7でbuildする (@Debian Sid)

Debian Sidのgcc-7 (7.1)でlibc6 (glibc)をsource packageからbuildしようとすると、-werrorの効果でwarningがerror扱いになり途中で止まってしまう。これは使い方によっては有用なoptionだが、取り敢えずbuildを通したい時には面倒なので細工してみる。

glibcの./configure scriptには--disable-werrorという便利なoptionがあるのでこれを与えれば良さそうだと分かる。問題は、dpkg-buildpackageでbinary packageをbuildする際にどのようにこのoptionを./configureに渡すか。

まず最初に思い付いたのがdebian/rulesに適当な記述を加える方法だが、./configureに直接optionを渡せそうな設定項目が無かった。

次に目を付けたのがdebian/sysdeps/amd64.mkで、これはamd64 (aka. x86_64, x64) platformにて利用されるbuild script。中身を見てみると、丁度利用できそうな部分があったので次のように書き換え:

extra_config_options = --enable-multi-arch

↓

extra_config_options = --enable-multi-arch --disable-werror

あとはいつも通り、top levelで:

% dpkg-buildpackage -us -uc -B -d -rfakeroot -j8

あたりを発行しbinary packageをbuild。

2016年10月23日日曜日

Debian unstableのgcc-6 6.2.0-7以降でLinux kernelなどのbuildができない件への対処 (2016-12-03更新)

Debian unstableのgcc-6は、6.2.0-7から--enable-default-pieというflag付きでbuildされており、これがあちこちで問題を引き起こしている。

cf. https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=gcc-6

影響を受けているのはLinux kernelやSeaBIOSなど。

今の所backoutされる予定はなさそうなので、upstream (kernel側)で対応する迄は以下のworkaroundで我慢するか、自前でgcc-6 (6.2.0-6)をbuildするしかない。

Linux kernelのbuild

(2016-12-03追記)

Linux kernel 4.8.11でDebianのGCCで行われた変更に対応した。よって、それ以降のversionを利用する場合以下のworkaroundは不要。

stack protectorをenableにしていると:

> -fstack-protector not supported by compiler

と出てbuildが止まったり、そうでなくても:

> error: code model kernel does not support PIC mode

と出てbuildが止まったりする。

何れも、KCPPFLAGS=-fno-picをmake-kpkgあたりに渡してbuildするというworkaroundが紹介されている (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841533)。

著者の環境ではworkaroundによりmake-kpkgでkernelがbuildできた。

ccache userへ

FirefoxやEmacsのbuildにも影響が出た。

一旦、ccache -C -zでcacheを破棄してrebuildすると良い。

ZoL (ZFS on Linux)

(2016-10-28追記)

ZoLはkernel modulesとしてbuildする関係から、もろにこの変更の影響を受ける。しかも、KCPPFLAGS=-fno-picを渡しても./configure scriptが途中でコケる。

(2016-12-03追記)

SPLもZFSも正常にbuildできるようになった。

それがGCC側の変更なのか、kernel sourceのupgradeの結果なのかは切り分けられなかった。

2016年9月9日金曜日

GCC 5.x → GCC 6.xへ完全移行 @Debian Sid

Debian GNU/Linux Sidではしばらく前にdefaultのGCCが5→6になったのだが、Firefoxのbuildに不具合がありGCC 5.xを残してあった。

今日、Firefox 49 (release)をbuildしてみた所、mach packageがうまくいかない不具合が解消されていたので、晴れてGCC 5 seriesをuninstallした。

2016年6月1日水曜日

Linux kernel 4.7-rc1をmake-kpkgでbuildする

概要

Linux kernel 4.7-rc1がreleaseされたが、buildでコケた。

Build environment

* Intel Core i7-6700K + DDR4 64GByte
* Debian Sid / Experimental
* gcc.real (Debian 6.1.1-4) 6.1.1 20160519

* Linux 4.7-rc1 (from Git)

* time (MAKEFLAGS= DEBIAN_BUILDARCH=native CONCURRENCY_LEVEL=8 CC='ccache gcc' CXX='ccache g++' fakeroot make-kpkg --initrd kernel_image)

error message

いつも通り、早速make-kpkgでbuildを試みたのだが、見事にコケた:

> CC arch/x86/boot/edd.o
> /tmp/ccENSHy1.s: Assembler messages:
> /tmp/ccENSHy1.s:35: Error: instruction `shlx' isn't supported in 16-bit mode.
> /tmp/ccENSHy1.s:39: Error: instruction `andn' isn't supported in 16-bit mode.
> CC arch/x86/boot/main.o
> scripts/Makefile.build:289: recipe for target 'arch/x86/boot/cpucheck.o' failed
> make[2]: *** [arch/x86/boot/cpucheck.o] Error 1
> make[2]: *** Waiting for unfinished jobs....

見ての通り、16bit modeでsupportされていないinstructionが使われている。

workaround

arch/x86/以下にあるcodeは-m32でcompileされるんじゃないのかな？と思い、関係しているであろうarch/x86/boot/Makefile@68を編集 (-m32を追加):

KBUILD_CFLAGS := $(USERINCLUDE) $(REALMODE_CFLAGS) -D_SETUP

↓

KBUILD_CFLAGS := $(USERINCLUDE) $(REALMODE_CFLAGS) -D_SETUP -m32

これでbuildは通ったが、本当にこんなworkaroundで大丈夫なのかは不明。

ちなみに、Linux 4.6では全く同じ環境でbuildが通っているので、Linux 4.7で色々変わった関係だろう。

2016年5月5日木曜日

ASUS X200LAのFocaltech touchpadがうまく動かなくなった件

概要

Debian SidでX関連packageの変更？によりsynclientが動かなくなった
/etc/X11/xorg.conf.d/以下にsynaptics関連のfileを配置したら直った

不具合とworkaround

以前のpostで、ASUS X200LAに搭載されているFocaltech touchpadをsynclientで設定すると使いやすくなると書いたが、Linux kernelのupgradeに際してrebootした後、tapなどが動作しなくなっていることに気付いた。

何かの拍子に設定が戻ったのかとsynclient -lで設定を確認してみようとしたら"Couldn't find synaptics properties. No synaptics driver loaded?"を吐く。~/.xsessionにtouchpadを設定する一連のcommandsを書いているので、synclientのこのerrorのせいで動作がおかしくなっている。

当初はkernelを疑って以前のversionに戻したり、幾つかkernel optionsを弄ってみたが関係ないと分かった。

結局、cp -i /usr/share/X11/xorg.conf.d/50-synaptics.conf /etc/X11/xorg.conf.d/を実行した後にXをrestartしたら解決した。よくわからないが、Linux kernelではなく、X側の設定で何かしら変更があったようだ。

参考リンク

[fedora - synclient does not find synaptics properties despite Synaptics Touchpad in xinput list - Unix & Linux Stack Exchange](http://unix.stackexchange.com/questions/210144/synclient-does-not-find-synaptics-properties-despite-synaptics-touchpad-in-xinpu)
[SynapticsTouchpad - Debian Wiki](https://wiki.debian.org/SynapticsTouchpad)

2016年3月28日月曜日

PulseAudioのloopback moduleを使う

Loginした時にmodule-loopbackがloadされるように設定した。

/etc/pulse/default.paをcopyする
loopback moduleの設定を加える

具体例

motherboard内蔵のIntel HD Audioで、line-in → line-outへ音声を流す設定 (~/.config/pulse/default.paの最後の部分):

> ...
> ### loopback
> .ifexists module-loopback.so
> load-module module-loopback source=alsa_input.pci-0000_00_1b.0.analog-stereo sink=alsa_output.pci-0000_00_1b.0.analog-stereo
> .endif

module-loopbackへのparamterはsourceが入力元、sinkが出力先。これらはindex numberか (長い) unique nameで指定できる。Deviceの認識順とかでindexは変化するみたいなので、nameで指定しておいた。

unique nameやindexはpactl listやpacmd list-sources、pacmd list-sinksで表示できる。

参考リンク

[PulseAudio - ArchWiki](https://wiki.archlinuxjp.org/index.php/PulseAudio)

Debian Sid + Linux 4.6-rc1でPlanex GW-450D KATANAを使う

Google等で検索すると既に様々な方が実施されているのだが、GCC 6だからなのか、それともLinux kernelが4.6rc1だからなのか、そのままではdriverがbuildできなかったのでメモしておく。

全体の流れ

x86_64対応のdriverをdownloadし展開して修正する

tarballを展開するかgit clone
Makefileに変更: CHIPSETへ追加、LINUX_SRCの変更
common/utusb_dev_id.cへUSB_DEVICE_ID追加
conf/RT2870STA.datを修正
os/linux/config.mkを修正 (-Wno-error=incompatible-pointer-types)
os/linux/rt_linux.cを修正 (__vfs_read, __vfs_writeへ変更)

Kernelの修正とrebuild (CONFIG_WIRELESS_EXT=y, CONFIG_WEXT_PRIV=y)
buildしてinstall

make
make install (もしくは手動でcopy)
depmod -a

Debian specificなnetworkの設定 (or NetworkManagerやwicdで設定する)

/etc/Wireless/RT2870STA/RT2870STA.datの調整
/etc/networking/interfacesの変更
modprobe mt7650u_sta
service networking restart

今回遭遇した問題

主にdriverのbuildに際して問題があった。

incompatible-pointer-typesのwarningがerror扱いされてbuildが止まる
net_device、iw_handler_defなどstructの初期化を行う部分でerrorが出る

incompatible-pointer-types対策

1つ目のincompatible-pointer-typesに関しては、gccに-Wno-error=incompatible-pointer-typesを渡して見逃してもらった。os/linux/rt_linux.cのWFLAGSに直接書き込むという力技を使ったが、たぶんもっと適切な場所 (もしくは方法)があると思う。

unknown field対策

2つ目のstructの初期化 (designated initializer)に関しては、kernel moduleとしてbuildする際に見ているLinux kernelの設定に問題があった。

具体的には"error: unknown field 'private' specified in initializer"といったerrorが出るのだが、kernel sourceの側で必要なsymbolを有効にしていないのが原因だった。必要なのはCONFIG_WIRELESS_EXTとCONFIG_WEXT_PRIV。

これらはmake menuconfigで'/'を使って調べると出て来るが、依存関係の問題なのか有効にできなかったのでnet/wireless/Kconfigを直接編集して対応。make oldconfigを実行して.configに2つが=yで出力されているのを確認して、kernelをrebuild & install。

以上でdriver (mt7650u_sta.ko)をbuildできる。

Pitfalls

普段楽をしてmake-kpkgでkernel packageをbuildしているので、driverをinstallした後にdepmod -aを忘れていた
SSIDがstealthなので/etc/networking/interfacesあたりにap_scan=1とかssid_scan=1を設定する必要があった

追記

Rebootが必要とあるが、本当に必要なのはkernelでCONFIG_WIRELESS_EXTとCONFIG_WEXT_PRIVが有効になっていない場合に新しくbuildしたkernelに切り替える時だけで、後はservice networking restartとかmodprobe (-r) mt7650u_staでどうにかなる。

参考リンク

Driverのsource code

[sanrath / MediaTek_mt7610u_STA_driver_Linux 64bit — Bitbucket](https://bitbucket.org/sanrath/mediatek_mt7610u_sta_driver_linux-64bit.git)

GW-460DをLinuxで使う方法について

[パリッと行こう！: Planex GW-450Dをlinuxで使う](http://paritparit.blogspot.jp/2013/08/planex-gw-450dlinux.html)

Buildに必要なLinux kernelの設定について

[BeagleBoard上のAndroidでWiFiを使う - h_kojimaの日記](http://d.hatena.ne.jp/h_kojima/20110617/1308324429)

/etc/Wireless/RT2870STA/RT2870STA.datの読み込みに失敗する問題への対策

[neuralassemblyのメモ: Raspberry Pi 2 + kernel 4.1.6 で5GHz対応WifiドングルGW-450Dを動かした](http://neuralassembly.blogspot.jp/2015/09/raspberry-pi-2-kernel-416-5ghzwifigw.html)

Cのdesignated initializerについて

[Designated Initializer - BOOLEANLABEL](http://d.hatena.ne.jp/fd0/20100213/p1)
[プログラミング言語 C の新機能](http://seclan.dll.jp/c99d/c99d07.htm#dt19991025)
[Using and Porting the GNU Compiler Collection (GCC) - C 言語ファミリに対する拡張機能](http://www.asahi-net.or.jp/~wg5k-ickw/html/online/gcc-2.95.2/gcc_4.html#SEC81)
[Designated Inits - Using the GNU Compiler Collection (GCC)](https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html)

2016年3月27日日曜日

Linux kernel 4.6-rc1をdebianでbuildする

Linux kernel 4.6-rc1がreleaseされたので、早速make-kpkgでbuildしようとしたら……

> In file included from arch/x86/decode.c:26:0:
> arch/x86/../../elf.h:22:18: fatal error: gelf.h: No such file or directory
> #include <gelf.h>
> ^
> compilation terminated.

gelf.h……？

今までこんなerrorは出ていなかったので検索してみた所:

> I guess your system didn't install libelf library.

cf. [compiling error gelf.h · Issue #34 · ktap/ktap · GitHub](https://github.com/ktap/ktap/issues/34)

なる記述を発見。取り敢えずaptitudeでlibelf-devというpackageをinstallしたら解決した。

なお、Debian experimentalに入っているgcc-6 seriesで無事buildできたことを申し添えたい。

2016年3月10日木曜日

Debian GNU/LinuxでUSB3.0なGigabit Ethernet

LogitechのLAN-GTJU3というUSB3.0のnetwork adapterを使ってみた。

何故か100Mbpsまでしか有効にならず色々と試してみたのだが、switching hubのportを別の場所に変更したら1000Mbpsが有効になった。

理由はよく分からないが、想像するに、元々100Mbpsのadapterが接続されていたportだったので、switching hub側が「100Mbpsまで」と記憶していたのが問題なんじゃないかと。

2016年1月31日日曜日

Linux boxでラジオ番組を自動録音する

*** 注意 (2018-12-09追記) ***

この記事は古いため以下の記事を参照されたい:

cf. [Linux boxでラジオ番組を自動録音する]

(https://typeinf-memo.blogspot.com/2018/12/linux-box-returns.html)

*** 注意ここまで ***

概要

やりたいこと

Linux boxのline-inに接続されているtunerから流れてくるラジオ番組を自動で録音したい

Solution

line-inから録音してOgg Vorbisにencodingするscriptを書く
cronに登録して定期的に走らせる

これだけのいたって簡単なお仕事……のはずがどうしてこうなった。

落とし穴と対策

pipeしたprocessの殺し方にハマる
cronのdefaultのshellは/bin/sh
PulseAudio関連のprogramをcronから呼んだ時の挙動にハマる

対策としては:

parec ... | oggenc ... の組み合わせではなくffmpegで録音する → 1、2
環境変数XDG_RUNTIME_DIRを渡す → 3

わかったこと

pipeでつないだprocessesの殺し方
parecの他にもffmpegで録音できる
PulseAudioを使う時は環境変数に注意

結論

こんな感じのscriptをcronで回している:

# 録音
XDG_RUNTIME_DIR=/run/user/1000 /usr/local/bin/ffmpeg -f pulse -ac 2 -ar 44100 -i
alsa_input.pci-0000_00_1b.0.analog-stereo -acodec libvorbis -q 3 "${FILEPATH}" &
RECPID=$!

# 録音停止
sleep ${DURATION}
kill -TERM ${RECPID}

補足

なお、ffmpegではdurationを指定できるので:

... /usr/local/bin/ffmpeg -f pulse -ac 2 -ar 44100 -i alsa_input.pci-0000_00_1b.0.analog-stereo -acodec libvorbis -q 3 -t ${DURATION} ${FILEPATH} &

とかでも良さそう。また、ffmpegのかわりにparecとoggencを組み合わせても良い:

parec --fix-format --fix-rate --file-format=raw --format=s16ne > >(oggenc -B 16
-C 2 -q 3 -o "${FILEPATH}" - >/dev/null 2>&1) &

ただし、この方法 (process substitution)はbashやzshでないと使えないので注意が必要。因みに:

parec ... | oggenc ...

とpipeでつないでも良いが、この場合job単位でprocessesを殺す必要がある (kill %%とかで殺せる)ので少々面倒。

補足2

暫くの間:

XDG_RUNTIME_DIR=/run/user/1000 /usr/local/bin/ffmpeg -f alsa -ac 2 -ar 44100 -i
pulse -acodec libvorbis -q 3 "${FILEPATH}" &

で運用していたが、これだとdeviceの認識順と共にdefaultのsourceが変わって、無音の状態になることがあった。そこでdeviceを限定するため以下のように変更:

XDG_RUNTIME_DIR=/run/user/1000 /usr/local/bin/ffmpeg -f pulse -ac 2 -ar 44100 -i
alsa_input.pci-0000_00_1b.0.analog-stereo -acodec libvorbis -q 3 "${FILEPATH}" &

おまけ

cronで実行したscriptの出力を見ようと思ったら/usr/bin/mailがsymbol lookup errorを吐いた。原因を追求していると本来の目的を忘れそうだったので、とりあえず/var/mail/以下のfileを直接読んで凌いだ。

また、Debian sidだと/usr/bin/mailは/etc/alternatives/mailへのsymlinkであり、これは更に/usr/bin/mail.mailutilsへのsymlinkで、如何なるpackageにも属していない。

参考URL

補足2関連

[Capture/Desktop – FFmpeg](https://trac.ffmpeg.org/wiki/Capture/Desktop)
[FFmpeg Devices Documentation](https://www.ffmpeg.org/ffmpeg-devices.html)

登録: 投稿 (Atom)