2025年11月の記事一覧 | ふるた技工所(てっこうしょ)

QEMU で RaspberryPi OS Trixie の GUI Desktop を動かす - lightdm.conf 修正 /etc/X11/xorg.conf.d に Device, ServerLayout, Screen, Monitor を記述した 00-fbdev.conf を配置

QEMU で RaspberryPi OS Trixie の GUI Desktop を動かすことができた。前の日記の続きで watchdog は無効化した状態に追加の修正を加えている。QEMU で起動する流れで関係がある修正を順に示す。Kernel parameter に bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768 も追記する必要がある。次は qemu-system-aarch64 に渡す option で書いた例だ。-append "console=ttyAMA1,115200 console=tty1\ root=/dev/mmcblk0p2 rootfstype=ext4 fsck.repair=yes rootwait\ dwc_otg.fiq_fsm_enable=0\ bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768\"Xorg で動く様に raspi-config で設定する。sudo raspi-configで起動すると容易に操作できる Text Graphic Interface が始まるので 6 Advanced Options / A7 Wayland / W1 X11 Openbox window manager with X11 backend で設定する(この設定だけでは QEMU 上で GUI Desktop は起動しない)。display-manager.service (実体は lightdm.service) の設定を修正する。sudo systemctl edit --full display-manager.service で次の様に修正する。--- /lib/systemd/system/lightdm.service 2025-03-15 00:02:00.000000000 +0900+++ lightdm.service 2025-11-25 13:14:40.222838504 +0900@@ -1,8 +1,10 @@ [Unit] Description=Light Display Manager Documentation=man:lightdm(1)-After=systemd-user-sessions.service dev-dri-card0.device dev-dri-renderD128.device-Wants=dev-dri-card0.device dev-dri-renderD128.device+#After=systemd-user-sessions.service dev-dri-card0.device dev-dri-renderD128.device+#Wants=dev-dri-card0.device dev-dri-renderD128.device+After=systemd-user-sessions.service+Wants= # replaces plymouth-quit since lightdm quits plymouth on its own Conflicts=plymouth-quit.service/etc/lightdm/lightdm.conf を修正する(差分ファイルのリンク)、(修正後のファイル、lightdm-qemu.conf を lightdm.conf にリネームして /etc/lightdm 以下に配置する)。差分は次の通り、logind-check-graphical=false に変更する。このようにすると lightdm.service が Xorg を起動する様になる。--- lightdm.conf 2025-11-25 13:45:47.000000000 +0900+++ lightdm-qemu.conf 2025-11-30 02:11:13.000000000 +0900@@ -26,7 +26,7 @@ #lock-memory=true #user-authority-in-system-dir=false #guest-account-script=guest-account-#logind-check-graphical=true+logind-check-graphical=false #log-directory=/var/log/lightdm #run-directory=/var/run/lightdm #cache-directory=/var/cache/lightdmXorg 設定ファイル /etc/X11/xorg.conf.d に Device, ServerLayout, Screen, Monitor を記述した 00-fbdev.conf を配置する必要があった(00-fbdeb.conf ファイルのリンク)。Section "Device" Identifier "Card0" Driver "fbdev"EndSectionSection "ServerLayout" Identifier "ServerLayout0" Screen 0 "QEMUFB"EndSectionSection "Screen" Identifier "QEMUFB" Device "Card0" Monitor "QEMUFBPanel" DefaultDepth 24 SubSection "Display" Depth 24 EndSubSectionEndSectionSection "Monitor" Identifier "QEMUFBPanel" VertRefresh 60EndSectionwatchdog 無効化に対してBooting Debian Trixie (13) on Qemu(Disable watchdog by modifying /etc/systemd/system.conf) が提案されていた。自分の手元では上手くいかず。RuntimeWatchdogSec, RuntimeWatchdogPreSec の設定も上手くいっていない。systemd の設定で watchdog の問題解決はできていない。まだスクリプト化をしていない。

2025.11.30

コメント(0)

新野田変電所で 11/26 18:43 に事故が有ったようだ - 瞬時電圧低下の記録あり

新野田変電所で作業事故があったようだ(新聞記事なので消えるかもしれない)。商用電源監視サーバーの記録に 11/26 18:43:50 頃に瞬時電圧低下があったことが記録されていた。東京電力パワーグリッドの瞬時電圧低下記録 11月26日 18:43 に栃木県、群馬県、埼玉県、千葉県、東京都、山梨県、神奈川県、静岡県で瞬時電圧低下が発生したと記録されている。500kV 系統かその下流の 275kV 系統で事故が起きた？同時刻に停電記録もあるサージ電圧で放電した？急に周波数は 0.1Hz、電圧は 2.0V ほど上がっているのは瞬時電圧低下で停止した器機類が原因だろうか。あるいは 500kV 系統の遮断器を瞬時(恐らく 0.5 ～ 1 cycle の間)に操作して事故周辺切り離しをして迂回路を接続したのだろうか？夕飯時、突然 IH コンロ、電子レンジ、電気釜が停止して料理中断？気づかずご飯が炊けてなかったとか...1999年には世界最大の変電所として記録された新野田変電所、自転車で見に行ったこともあった。今は体調が良くなくどうなっているのかは見に行けず。

2025.11.26

コメント(0)

QEMU で Raspberry Pi OS trixie (Debian13) を動かす - watchdog を止めて console mode で起動する様になった

Raspberry Pi OS が更新されて Debian 13 "trixie"になった。QEMU 上で上手く動かせていない(GUI desktop が動く様になる追加修正)。今のところ console mode で起動する様になった。対応作業の途中経過はgithub qemu-raspberrypi の follow-trixie に入れてある。状況と課題を挙げる。device tree を修正して watchdog を止める必要がある (修正 diff), (修正後の source), (修正後の device tree blob (表示はできないと思うので download をして下さい))上記に伴い shutdown をしても QEMU が終了しなくなった。watchdog driver が shutdown driver も抱えている。GUI desktop が動かない。/dev/fb0, Xorg driver 周りの問題だと思う。原因を特定できいない。最新の QEMU 10.1.50 を使わなくても動くのか？あー、bookworm (Debian 12) から kernel, initrd, kernel module だけ持って来る？

2025.11.21

コメント(0)

Redox OS を試してみる - 仕様説明不足・不具合でやる気ゲージがすぐに 0% になる

Redox OSを試す。動機はごく単純に rust で書かれた OS に対する興味だ。試し始めてすぐに「使えない」という結論になった。ここからは自分で可能な試行と解釈の結果で書いていく。他の人と意見が合わないかもしれない。まず現実的に実行可能な環境はQEMU Emulator 一択 (リンク先は Running Redox in a Virtual Machine - Redox OS)だ(Redox OS を QEMU にインストールしてみた結果をまとめたページへのリンク)。実マシンで動くとの説明は「そうかもしれないけれど」という疑問がある。試した結果、PS/2 Keyboard(US 配列限定), Mouse でのみ操作可能 (USB HID をサポートしているとの説明に対して、動いた環境は無かった)HDD/Optical drive の IDE 接続は ISA BUS address 空間に配置されている H/W だけ動作する(PCI Bus Configuration Register で配置情報が得られる I/F はサポートしていない。ソースコードを見る限りレジスタが Memory Mapped になっているのは非対応)SATA 接続の HDD は認識しないか認識・読み込み途中でハング(恐らくアクセスタイミングや手順に問題がある)サポートしているネットワークカードはRealtek RTL8139, Realtek RTL8168, Realtek RTL8169, Intel 82543GC, Intel 82540EM, Intel 82545EM, Intel 82573L, Intel 82579V だけだ。Realtek RTL8139, RTL8168, RTL8169 系列の OEM VID:PID や互換/クローンチップはサポートされていない(この様に判断した8139 driver と8168 driver のリンク)。Intel NIC も大雑把に e1000 系列であってもサポートは限定的だ(e1000d driver のリンク)ほぼ骨董品になってしまった PC, Keybpard, Mouse, NIC, IDE-HDD, IDE-Optical Drive を見つけて動かすしかない。骨董品が見つかり揃ったったとして、絶望的に Live USB Memory や CD-R(他の光学媒体も同様) の読み込みが遅い。精々 1 ～ 3Mbytes/sec の読み込み速度で live image を主記憶に読み込む。600Mbyte 程あるので、(linux で言う所の kernel + initrd) 起動だけで 3 ～ 10 分程度待たされる。それで起動すれば良い。大抵は HDD を認識したところでハングするか、起動まで漕ぎつけたとして、インストール先の HDD が見つからない。普通の人なら、窓から投げ捨てるだろう。自分はこの時点でやる気ゲージが 50% まで落ちてしまった。VirtualBox を普段使いしている人もいるかもしれない。VirtualBox は使えない。実マシン同様にHDD のアクセスに問題が有り(リンク先はログ、末尾に VirtualBox が検出した問題が記録されている)(VirtualBox は実マシンで起こりえる問題も厳密にエミュレーションしていると思われる)、Frame Buffer 書き込みで CPU cache 制御の問題も露見している様に見える(こちらも厳密エミュレーションなのだろう、そして実マシンで起動のための読み込みが遅いのも cache 制御に問題が有りそうだ)。QEMU で動かすことに辿り着き、試しにプログラムを動かしてみる(リンク先は試したプログラムのソースコード)ことにした。rust で書かれた OS には失礼だとは思いつつ C 言語と bash を使う。必要な package を GUI の cosmic-terminal ウインドウで sudo pkg install git gcc13 gnu-make gnu-grep と入力してインストールする。Page fault: 000000000000000C USRFLAG: 0000000000010297CS: 000000000000002bRIP: 000000000061ad77RSP: 0000000000d61e00SS: 0000000000000023FSBASE 000000000023e000GSBASE 0000000000000000KGSBASE ffff80007fc64000RAX: 0000000000000001RCX: 0000000000000000RDX: 0000000000000000RDI: 0000000000000004RSI: 0000000000000000R8: 0000000000000000R9: 000000000061ad70R10: 0000000000000001R11: 0000000000000246RBX: 0000000000000004RBP: 0000000000000010R12: 0000000000d61e60R13: 0000000000000018R14: 0000000000000001R15: 0000000000000000 FP ffff80000f02fe80: PC ffffffff8007c115 FFFFFFFF8007BF40+01D5 kernel::arch::x86_shared::interrupt::exception::page::inner FP ffff80000f02ff50: PC ffffffff80078e87 FFFFFFFF80078E50+0037 kernel::arch::x86_shared::interrupt::exception::page 0000000000000010: GUARD PAGEいきなり segmentation fault ですか(メッセージに UNIX 伝統の segmentation fault は含まれない。とは言ってもアドレス 0x000000000000000C って NULL pointer で指した構造体メンバーのアドレスだと思う)。え？ rust で書いて segmentation fault ってあるの？なんだかなぁ... この問題は QEMU の monitor/terminal 混合ターミナル(Linux を動かすと serial port の tty になる疑似端末)で操作すれば解決した。やる気ゲージ 20% down。Linux 上で一通り動作確認してたのですんなりコンパイルができて、動くかと思っていたら、コマンドライン解釈に問題がでた。getopt() が動作しない。何かの error return とか、"Not Implemented" の様なコンソールメッセージを出力するのかと思っていたら、沈黙をもって動作しない。うん、ここに辿り着くまでに次のような未実装メッセージを散々見ている。example 1: setsockopt(23, 1, 9, 0x20c7e0, 4) - unknown optionexample 2: relibc getgroups(65536, Pointer { addr: 0xd5a0, metadata: 65536 }): not implementedexample 3: relibc getrlimit(7, 0x7ffffffffba8): not implementedやる気ゲージ 10% down。ああ、普通に動いていない環境なんだ。普段使いは JP keyboard なので、US keyboard 入力を強要する GUI にも不満が溜まる(keyboard driver を見ると layout は hard coding だし JP layout は stub すらない)。急遽 getopt() の簡易代替実装をする(ソースコードのリンク)。コンパイルも通ったし、実装した個別のコマンドも動くようになった。test loop が回りだしてしばらくすると、kernel panic が起きる(起きなくても loop が途中で動かなくなって、UNIX で言う所の kill -HUP $pid をしないと終了しない)。できることは QEMU 毎終了するだけだ。KERNEL PANIC: panicked at src/memory/mod.rs:954:9:allocator-owned frames need a PageInfo, but none for [frame at 0x7ffffffffffff000] FP ffff800016caf730: PC ffffffff80050e55 FFFFFFFF80050CD0+0185 kernel::panic::panic_handler_inner FP ffff800016caf820: PC ffffffff8004ef39 FP ffff800016caf830: PC ffffffff800a732f FP ffff800016caf860: PC ffffffff80075d90 FFFFFFFF80075AF0+02A0 kernel::memory::deallocate_p2frame FP ffff800016caf8f0: PC ffffffff8001d2ae FFFFFFFF8001CAC0+07EE <kernel::context::memory::AddrSpace as core::ops::drop::Drop>::drop FP ffff800016cafac0: PC ffffffff80033b1c FFFFFFFF80033B00+001C alloc::sync::Arc<T,A>::drop_slow FP ffff800016cafb30: PC ffffffff80049d8f FFFFFFFF80049720+066F <kernel::scheme::proc::ProcScheme as kernel::scheme::KernelScheme>::close FP ffff800016cafc40: PC ffffffff800968ea FFFFFFFF800964B0+043A kernel::context::file::FileDescription::try_close FP ffff800016cafcd0: PC ffffffff80096464 FFFFFFFF800963A0+00C4 kernel::context::file::FileDescriptor::close FP ffff800016cafd40: PC ffffffff80066baa FFFFFFFF80066A30+017A kernel::syscall::fs::close FP ffff800016cafd70: PC ffffffff8006b2c3 FFFFFFFF8006AEF0+03D3 kernel::syscall::syscall FP ffff800016cafea0: PC ffffffff8005f6ee FFFFFFFF8005F640+00AE __inner_syscall_instruction FP ffff800016caff50: PC ffffffff80058693 FFFFFFFF80058650+0043 kernel::arch::x86_64::interrupt::syscall::syscall_instruction 0000000000000000: GUARD PAGECPU #2, CID 0xffffff7f801b7f20NAME: /usr/bin/tr, DEBUG ID: 825SYSCALL: close(8)HALTpipe line / redirect で繋いだ file descriptor の close() で問題が起きる？と言うことは、file descriptor で参照するかその操作で更新する情報の reference counter が不正操作されるか、そもそも up / down が必要な処理が抜けているか余計なのか。あれ、rust って Rc<> とか Arc<> とか有るんじゃなかったの(kernel 用に再実装するとして設計思想的に強要されるやり方では)？ここまできてやる気ゲージは 0% になった。他にも一々 UNIX 系 command とコマンドラインの使い方が違うとか、おせっかいすぎる completion とか、不便は微塵も感じていなかったことが変わっている。変えた意図を汲めないことが多い。rust への理解は殆どない。それでもRedox OS を実装している rust のソースコードを眺めて思う。rust を使えば Linus 氏程の才能が無くても安全かつ安定して動く kernel を書けるようになる訳では無いと。

2025.11.04

コメント(0)