未来から過去へ表示(*) 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). とのこと。
コメント一覧
- コメントはありません。
この記事にコメントする
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年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
その後、再起動して、正常に起動することを確認しておしまいです。
コメント一覧
- 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 になってるくらいですねえ。
この記事にコメントする
2015年5月2日
systemdを使うのをあきらめた
目次: 自宅サーバー
独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われて起動しないので、sysvinitに戻しました。ぶっちゃけsystemdだろうがsysvinitだろうが、どっちでもいいわ…。
しかしudevといい、systemdといい、便利は便利なんでしょうけど、Linux固有の機能に依存しまくりで面倒です。ブート周りを司るソフトがOS依存になるのは仕方ないのかなあ？
コメント一覧
- コメントはありません。
この記事にコメントする
2015年5月1日
オープンソースプロジェクトの持続性
コンパイラ, エディタなど、かつて有料が当たり前だったのに、今やオープンソースが当たり前になっていて、有料だと逆に「なぜ有料なの？」と思ってしまいます。
良い時代になったよなあ、と思う一方で、オープンソースプロジェクトの持続性には疑問があります。
従来のようにソフトウェアを売る、という形での開発費回収が出来ませんから、最初は個人の情熱で維持できても、いつか開発費が捻出できなくなって破綻すると思うんです。
でも、あまり破綻したという話を聞かないのはなぜでしょう？実は零細プロジェクトから静かに破綻していってるけれど、影響力が小さいからニュースにならないだけなのか、それとも何か別の秘密があって、巧妙に回避できているのか…？
メモ: 技術系？の話はFacebookから転記しておくことにした。
コメント一覧
- コメントはありません。
この記事にコメントする
2015年4月30日
Debian 8.0 Jessieにアップデート
目次: 自宅サーバー
Debianのアップデートが来ていたので、試しに職場のPCをアップデートしたところ、大きな問題なくアップデートできました。なぜか数時間かかりましたが…。
唯一引っかかったところと言えばApache 2.2から2.4にバージョンが変わっていて、Apache 2.2から引き継いだ設定が効いていなかったくらいです。
具体的にはOrder, Allowと書いていたところをRequireで書き直す必要があります。（Apacheのドキュメント Upgrading to 2.4 from 2.2 に詳しく記載があります）
Apache 2.2系
Order allow,deny
Allow from all
Apache 2.4系
Require all granted
検索すると結構出てくるので、有名なハマりどころなのだと思います。
自宅サーバ
気を良くして、自宅のファイルサーバをアップデートしたところudevのアップデートでコケました。カーネルのコンフィグがudevのお気に召さないようです。
余程この問題でハマる人が多いのか、異常なまでに丁寧なエラーメッセージが出ます。
udevのアップグレードでエラー
Preparing to unpack .../archives/udev_215-17_i386.deb ... Since release 198, udev requires support for the following features in the running kernel: - inotify(2) (CONFIG_INOTIFY_USER) - signalfd(2) (CONFIG_SIGNALFD) - accept4(2) - open_by_handle_at(2) (CONFIG_FHANDLE) - timerfd_create(2) (CONFIG_TIMERFD) - epoll_create(2) (CONFIG_EPOLL) Please upgrade your kernel before or while upgrading udev. ...
あまりのメッセージの量に何事かと思いましたが、要はCONFIG_INOTIFY_USER, SIGNALFD, FHANDLE, TIMERFD, EPOLLを有効にしなさいと言いたいだけのようです。言われた通りに設定しカーネルを再コンパイルしたところアップデートが無事進みます。
独自ビルドしたカーネルを使うのを止めれば、こんな苦労はないのですけど。微妙なマザーボードを買うことが多いせいか、独自ビルドの方が楽なんですよね…。
コメント一覧
- コメントはありません。
この記事にコメントする
| < | 2015 | > | ||||
| << | < | 05 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | - | - | - | 1 | 2 |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | - | - | - | - | - | - |
こんてんつ
wiki Linux JM Java API過去の日記
2002年 2003年 2004年 2005年 2006年 2007年 2008年 2009年 2010年 2011年 2012年 2013年 2014年 2015年 2016年 2017年 2018年 2019年 2020年 2021年 2022年 2023年 2024年 2025年 過去日記についてその他の情報
アクセス統計 サーバ一覧 サイトの情報
合計:
本日:
