コグノスケ


2015年5月1日

オープンソースプロジェクトの持続性

コンパイラ, エディタなど、かつて有料が当たり前だったのに、今やオープンソースが当たり前になっていて、有料だと逆に「なぜ有料なの?」と思ってしまいます。

良い時代になったよなあ、と思う一方で、オープンソースプロジェクトの持続性には疑問があります。

従来のようにソフトウェアを売る、という形での開発費回収が出来ませんから、最初は個人の情熱で維持できても、いつか開発費が捻出できなくなって破綻すると思うんです。

でも、あまり破綻したという話を聞かないのはなぜでしょう?実は零細プロジェクトから静かに破綻していってるけれど、影響力が小さいからニュースにならないだけなのか、それとも何か別の秘密があって、巧妙に回避できているのか…?

メモ: 技術系?の話はFacebookから転記しておくことにした。

編集者:すずき(2015/05/02 14:14)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2015年5月2日

systemdを使うのをあきらめた

目次: 自宅サーバー

独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われて起動しないので、sysvinitに戻しました。ぶっちゃけsystemdだろうがsysvinitだろうが、どっちでもいいわ…。

しかしudevといい、systemdといい、便利は便利なんでしょうけど、Linux固有の機能に依存しまくりで面倒です。ブート周りを司るソフトがOS依存になるのは仕方ないのかなあ?

編集者:すずき(2024/03/05 02:58)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2015年5月3日

GRUB2が起動しなくなってしまった

目次: 自宅サーバー

サーバにインストールしていたDebian 32bit版 のJessieへのアップデートは一段落したので(systemdを諦めたりしてかなり適当ですが…)、ノートPCの仮想マシンにインストールしていたDebian 64bit版をapt-get dist-upgradeしました。

無事アップデートできたように見えたので再起動したら、GRUB2が起動しなくなりました。正確に言うとCUI画面で止まるようになってしまいました。

GRUB2 CUIから起動
grub> ls
(hd0) (hd0,msdos1) (hd0,msdos2) (hd1)

grub> set root=hd0,msdos1
grub> ls /boot
grub/ config-3.16.0-4-amd64 config-3.2.0-4-amd64 
vmlinuz-3.16.0-4-amd64 vmlinuz-3.2.0-4-amd64 initrd.img-3.2.0-4-amd64
System.map-3.16.0-4-amd64 initrd.img-3.16.0-4-amd64 System.map-3.2.0-4-amd64

grub> linux /boot/vmlinuz-3.16.0-4-amd64 root=/dev/sda1
grub> initrd /boot/initrd.img-3.16.0-4-amd64
grub> boot

この時点では上記のように手打ちで起動できたのですが、その後、間違えてgrub-installを実行してGRUB1をインストールしてしまい、なぜかrootパーティションのReiserFSを認識しなくなり、手打ちでも起動できなくなりました。ああー…。

復旧

ダメ元でKnoppixからgrub-installしてみると、なぜかReiserFSが読めたので、そこからもう一度Debian Jessieを起動し(GRUB1 CUIもGRUB2 CUIとほぼ同じ手順で起動できる)て、GRUB2を入れなおしました。

GRUB2再インストール
# apt-get install grub-pc --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/220 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 188824 files and directories currently installed.)
Preparing to unpack .../grub-pc_2.02~beta2-22_amd64.deb ...
Unpacking grub-pc (2.02~beta2-22) over (2.02~beta2-22) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up grub-pc (2.02~beta2-22) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

# dpkg-reconfigure grub-pc
    - Linux command line: はそのまま空欄で [ok]
    - Linux default command line: はそのまま "quiet" で [ok]
    - GRUB install devices: は [*] /dev/sda ... を選択して [ok]
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

その後、再起動して、正常に起動することを確認しておしまいです。

編集者:すずき(2024/03/05 02:59)

コメント一覧

  • hdkさん(2015/05/04 21:40)
    あれれ、grub-install で GRUB2 のインストールできますよね? 何か残骸が残ってる?

    それはともかく、最初の GRUB2 が起動しなくなったのは、他に OS を入れていない環境ですかね。手元の環境でもなぜか GRUB2 の MBR へのインストールが自動的に行われなかったケースがあって、デュアルブートの Windows と手動で追加した項目だけが一覧に出る状態となっていました。
  • すずきさん(2015/05/04 22:57)
    >hdk さん
    アップデート前の GRUB2 が起動している状態だったのですが、grub-install したら GRUB1 のまっ黒画面に戻りましたね。何か残骸があったのかもしれないですが、今となってはわからんです。

    単なる 64bit 実験用の環境なので、OS は他に何も入れていないし、rootfs も /dev/sda1 で特に変な設定じゃないんですが、インストールに失敗しました。

    他の環境はうまくいってたのに何でだろうなあ…??
  • hdkさん(2015/05/06 21:45)
    たぶん /var/lib/dpkg/info/grub-pc.postinst がインストールをしてくれるスクリプトなのですが、古い GRUB1 からの移行の処理がごちゃごちゃ書かれていて、失敗してる環境って GRUB1 のファイルが一部 /boot/grub に残ってる環境かも...?

    と思って改めて手元のダメ環境を見直すと、debconf で grub-pc/install_devices_empty が true になっていたりして、そりゃインストールされないわな、みたいな、だいぶ前のアップグレードの時に GRUB2 への移行を嫌った選択が残ってたのかもなぁ、と。
  • すずきさん(2015/05/07 23:18)
    >hdk さん
    うーむ、どれが GRUB1 のファイルなのか良くわからない…。

    debconf って /var/lib/dpkg/info/grub-pc.templates の grub-pc/install_devices_empty のこと?値は false でした。
    似たような項目名を探すと grub-pc/install_devices_failed_upgrade が true になってるくらいですねえ。
open/close この記事にコメントする



2015年5月8日

GPSは世界一正確な時計 その2

前回(2015年3月9日の日記参照)はGPSモジュールをPCと接続して、情報を取得するところまで試しました。

今回はGPSモジュールからの時刻情報を使ってNTPサーバの時刻を合わせたいと思います。

NTPサーバの設定方法

設定はとても簡単で、下記をntp.confに書き加えてntpdを再起動させるだけです。当然ですがgpsdも起動している必要があります。

/etc/ntp.confの設定

server 127.127.28.0
fudge 127.127.28.0 refid GPS

設定の127.127というのは、決まり文句(ネットワーク上のサーバではない、くらいの意味だと思う)で、その後の28.0に意味があります。この28.0は共有メモリを使って時刻を取得するドライバを使ってくださいね、という意味になります(NTPのドキュメント参照)。

なぜここで急に共有メモリが出てくるのか?というと、実はgpsdとntpは共有メモリを介して通信しているからです。

gpsdとntp起動前後の共有メモリ領域数
# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

# /etc/init.d/gpsd start
Starting gpsd (via systemctl): gpsd.service.

# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4e545030 3375104    root       600        96         1
0x4e545031 3407873    root       600        96         1
0x4e545032 3440642    root       666        96         1
0x4e545033 3473411    root       666        96         1
0x47505344 3506180    root       666        31616      1

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

# /etc/init.d/ntp start
Starting ntp (via systemctl): ntp.service.

# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4e545030 3375104    root       600        96         2                 ★★1 → 2に増えた ★★
0x4e545031 3407873    root       600        96         1
0x4e545032 3440642    root       666        96         1
0x4e545033 3473411    root       666        96         1
0x47505344 3506180    root       666        31616      1

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

上記の実行結果を見るとgpsdを起動する前と、起動した後で、共有メモリの領域数が増えていることと、ntpを起動した後で、共有メモリへのアタッチ数(nattch)が1から2になっていることがわかると思います。

動作確認

実際NTPサーバがGPSから時刻を取得できているか、確認するときはntpqコマンドを使います。

ntpqコマンドでNTPサーバの状態確認
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.28.0    .GPS.            0 l    -   64    0    0.000    0.000   0.000
*127.127.1.0     .LOCL.          10 l   17   64    3    0.000    0.000   0.002

本来、127.127.28.0の方に * が付く(* は時刻合わせに使っているという意味)はずなのですが、調子が悪くてGPSで時刻を合わせている状態になりませんでした。

調べてみると、どうもGPSレシーバが壊れたようでxgpsで見ても全く衛星を捕捉していません。6000円くらいしたのに…なんてこった…。

お勧めしないデバイス?

さらにgpsdの動作確認済みハードウェアリスト(ハードウェアリストへのリンク)の中に、私が買ったGlobalsat BU-353-S4も載っており「感度悪いし、衛星の捕捉も遅いし、絶対買わない方が良いぜ(※)」と紹介されていました。

言われてみれば、かなり開けた窓際、しかも数センチ近くまで持っていかないと衛星捕捉せず、設置場所探しに大変苦労していたのですが、まさかここまでボロクソに書かれるほどのハズレ製品だったとは…。

壊れたのと合わさって、二重のショックです。せっかく買ったのに…ううーん。

(※)引用すると、Has poor sensitivity and takes a lot longer to cold-start than the vendor claim 45 of 45 seconds. Gary Miller rates this device "DO NOT EVER BUY ONE!" だそうです。

編集者:すずき(2015/05/10 03:15)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2015年5月9日

自作ARMエミュレータ - 今さら気づいたブートローダのバグ

目次: Linux

ずっと気づいていなかった自作ARMエミュレータememuのバグを直しました。

エミュレータは、内部に簡易ブートローダを持っているのですが、この簡易ブートローダが変なパラメータをLinuxカーネルに渡していたため、Linuxのブート時に「Ignoring unrecognised tag 0x00000000」と怒られていました。

変なパラメータを渡してLinuxに怒られる
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.18.11 (katsuhiro@falcon) (gcc version 4.9.1 20140710 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.07 - Linaro GCC 4.9-2014.07) ) #1 Fri Apr 17 03:18:38 JST 2015
[    0.000000] CPU: ARM926EJ-S [41069260] revision 0 (ARMv5TEJ), cr=00003137
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: ARM-Versatile PB
[    0.000000] Ignoring unrecognised tag 0x00000000★★★これ★★★
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 16384

古き時代からARM LinuxではATAGという仕組み(ATAGの仕様はここにあります)でカーネルのロード位置、InitramFSのイメージの位置、カーネルのコマンドラインなどをブートローダからカーネルに渡しています。

このうち、もうパラメータはない、すなわちパラメータの配列の終端を示すためのATAG_NONEの渡し方が間違っていました。わざわざ仕様書にも0x2を渡すなよ、0x0だぞ(※)と強調して書かれているのに、サイズに0x2を渡していました。マヌケです…。

このバグに気づいたとき、パラメータの終端が無い状態でも動くのか、さすがLinuxなどとアホなことを思っていたのですが、実はRAMの初期値が0だったため、パラメータの配列の終端を突き抜けた後に、0x00が4連続する部分(ATAG_NONEと同じ意味で解釈される)で解析が終了していただけでした。

つまり、今まで動いていたのは偶然!ってことですね。

このバグは現状では問題を引き起こしませんが、今後RAMを初期化しないが、ブートローダは通る、と言う処理を実装すると問題が起きます。例えば、リセット例外によるソフトリセット処理が当てはまりそうです。恐らくRAMの内容に応じてランダムにクラッシュする厄介なバグとして表面化するでしょう。

(※)引用するとThis tag is used to indicate the list end. It is unique in that its size field in the header should be set to 0 (not 2). とのこと。

編集者:すずき(2024/03/05 03:00)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2015年5月17日

どういう状況なの?これ

Redmineチューニングの実際と限界を読んで。

プロジェクト分割すれば良いだけなのに…、200万チケットを1つのRedmineに入れる必要があるって、恐ろしいです…。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/11/29 04:54)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2015年5月26日

ピリオドとユーザ名の不思議

Debianのセットアップでユーザ名にピリオドを使ったら「不正なユーザ名」と言われるので、何故?と思って調べたら思いのほか歴史がありました。

元々BSDでは、chownのユーザ名とグループ名の区切りにピリオドを使っていたそうで、ユーザ名にピリオドを使うなど以ての外でした。

しかしPOSIXがユーザ名にピリオドも使えるよ、と決めてしまったので、哀れchownの区切りはピリオドからコロンになりました。

Debianのセットアップスクリプトは安全側、つまりユーザ名のピリオドに対応していない古いツールを考慮してBSD時代のルールを守っているのだろう、と思われます。

実は誰も直さずに放置されているだけかも知れませんけど…真相はわかりません。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/06/05 01:01)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2015年5月28日

GPS故障?

先日(2015年5月8日の日記参照)の日記で壊れているのかと思っていたGlobalsat BU-353-S4ですが、実は壊れていませんでした。

GPS受信機が受信状態を伝える通信方式には、NMEA 0183という規格に基づいたテキストデータで送ってくるか、GPSの受信機メーカー独自のバイナリデータで送ってくるか、の2つがあるようです。

恐らく大抵のメーカーは両方に対応しており、NMEAか、メーカー独自バイナリかが選択できます。もちろんGlobalsat BU-353-S4が採用しているSiRF Star IVもどちらかを選ぶことができます。

どうも色々いじっているうちにバイナリモードになってしまっていたらしく、NMEAを期待していたGPSのデータ表示アプリなどが「何言ってるのかわからんわ、このデバイス」状態に陥っていました。故障じゃなくて良かったです。

GPSデータの確認方法
stty -F /dev/ttyUSB0 ispeed 4800 && cat < /dev/ttyUSB0
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,12,01,00,000,,02,00,000,,03,00,000,,04,00,000,*7C
$GPGSV,3,2,12,05,00,000,,06,00,000,,07,00,000,,08,00,000,*77
$GPGSV,3,3,12,09,00,000,,10,00,000,,11,00,000,,12,00,000,*71
$GPRMC,,V,,,,,,,,,,N*53
...

もし上記のようにテキストデータが受信されればNMEAモードになっています。もしグチャグチャの字が受信されるときは、ボーレートが間違っているか、バイナリモードになっている可能性が高いです。

モードの切り替え方

GPSデータの通信方式を切り替えるにはgpsctlというコマンドを使います。GPSデバイスが /dev/ttyUSB0として認識されているとして、

GPSデータの通信方式切り替え
# to NMEA
gpsctl -f -n /dev/ttyUSB0

# to Binary
gpsctl -f -b /dev/ttyUSB0

オプション-nはNMEAモードにする、-bはバイナリモードにするという意味で、-fはローレベル(gpsdを介さないという意味らしい)でGPSデバイスにアクセスするという意味です。

ちなみにSiRF Star IVはモード切り替えに数秒〜10秒近くの時間がかかることがあります。さすが「絶対買わない方が良いぜ」と言われるだけのことはある…。

無理やり変えてみる

これで終わりだとあまり面白くなかったので、Globalsat BU-353-S4の通信方式をgpsctl -n以外で切り替える方法も試してみます。

ありがたいことにGlobalsat USのサイトからSiRFバイナリデータの仕様書を入手できますので、NMEAモードへの切り替えコマンドを送ってみようと思います。仕様書のダウンロードはこちらのサイトの「SiRF Binary Protocol Document」からできます。

ちなみに仕様書の「Switch To NMEA Protocol – Message ID 129」にそのまま使える例が載っていますので、これをそのまま送ってみます。

  • A0A20018 - Start Sequence and Payload Length
  • 810201010001010105010101000100010001000100012580 - Payload
  • 013AB0B3 - Message Checksum and End Sequence

このデータをバイナリエディタなどでファイル(to_nmeaというファイル名だとします)に書いておき、

GPSデータの通信方式切り替えSiRF用
# gpsctl -f -b /dev/ttyUSB0
/dev/ttyUSB0 identified as a SiRF 9GSD4e_4.1.2-B2_RPATCH.02-F-GPS-4R-1301151 01/17/2013 017 at 9600 baud.
gpsctl:SHOUT: switching to mode BINARY.
falcon:~# stty -F /dev/ttyUSB0 ispeed 9600 && cat < /dev/ttyUSB0 | hexdump -C
00000000  a0 a2 00 29 02 00 00 00  00 00 00 00 00 00 00 00  |...)............|
00000010  00 00 00 00 00 00 00 00  00 00 03 36 02 6a 9c 5a  |...........6.j.Z|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 01 9d b0  |................|
00000030  b3 a0 a2 00 09 09 00 00  00 00 00 00 00 00 00 09  |................|
...

# cat to_nmea > /dev/ttyUSB0

# stty -F /dev/ttyUSB0 ispeed 9600 && cat < /dev/ttyUSB0
$GPGGA,163721.731,,,,,0,00,,,M,0.0,M,,0000*53
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPRMC,163721.731,V,,,,,,,280515,,,N*43
...

以上のようにバイナリをGPSデバイスに送りつけると、無事NMEAモードに切り替わります。ちなみに上記の設定例だとボーレートが4800bpsから9600bpsに変わってしまうので注意してください。

編集者:すずき(2015/05/29 01:42)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報