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

2026-09-07

FreeBSD/amd64の電力設定を見直す

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。X.orgでKDE Plasma 6を入れて、日本語環境も整えました。このマシンは、dynabook SS SX/15Aの代替として使っていくつもりです。dynabookは、当初Windows Vistaでしたが、NetBSD/i386に変更しています。旧いマシンだから劣化しただけではない気がしますが、起動しているだけでもバッテリを使い切ってしまうので、ACアダプタを常時つないでいました。それに比べるとLet's noteは、バッテリがもちます。感動的です。

 

FreeBSDの電力設定を見直して、よりバッテリがもつようにしておきたいと思います。このために、以下の設定を変更しました。

  1. hw.acpi.cpu.cx_lowest=Cmax
  2. hw.pci.do_power_nodriver="1"

 

1番目の設定は、当初「hw.acpi.cpu.cx_lowest: C1」 でした。「sysctl dev.cpu.0.cx_usage」すると「dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 71921us」のようになりました。この設定を「/etc/sysctl.conf」に加えると「hw.acpi.cpu.cx_lowest: C8」となり、cx_usageも「dev.cpu.0.cx_usage: 17.34% 67.87% 14.78% last 34861us」のようになりました。

 

2番目の設定は、当初「0」でした。Geminiのアドバイスでは、「1」が推奨されるとのことなので、「/boot/loader.conf」に設定を追加しました。

 

これらの設定を見直したことで、より長くバッテリがもつと良いのですが。 

2026-09-04

FreeBSD 15.1-RELEASEのKDE Plasmaでfcitx-mozcが無かったのでja-fcitx5-anthyを入れた

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。それからX.orgでKDE Plasmaを入れましたが、このままでは日本語環境がありません。日本語環境として、日本語フォントを日本語変換エンジンを入れます。

 

最初に日本語フォントを入れました。IPAexにしようかと思いましたが、調べてみるとnoto-jpが良さそうです。

  1. pkg install noto-jp

 

これで日本語が表示できるようになりましたので、次は日本語変換エンジンです。ネットの情報を調べるとKDEなら「fcitx-mozc」が選ばれているようです。しかしパッケージからは消えていました。それならば「ibus-mozc」にしようかとも考えましたが、これもありませんでした。そうなると「ja-fcitx5-anthy」をインストールすることにしました。インストール中に多少手間取ったところはありましたが、ほぼ問題なくインストールし、設定を終えました。

  1. pkg install fcitx5 fcitx5-configtool fcitx5-qt{5,6} fcitx5-gtk{2,3,4} ja-fcitx5-anthy 
  2. 環境変数の設定が必要です。シェルの初期設定ファイルに書いても良いのですが、ログインクラスを使うことにしました。~/.login_confに次のように書いて、データベースを更新します。

    me:\
    :charset=UTF-8:\
    :lang=ja_JP.UTF-8:\
    :setenv=XMODIFIERS=@im=fcitx,GTK_IM_MODULE=fcitx,QT_IM_MODULE=fcitx:

  3. ここからはKDEの設定です。「System Settings」で「System」>「Autostart」において「New Application」として「Fcitx5」を追加します。ここいったんログアウトし、再ログインします。
  4. システムトレイにあるキーボードアイコンを右クリックし「Input Method Settings」を選びます。
  5. 「+ Add Input Method ...」として「Anthy」を追加し、「Select System layout ...」として「Japanese (jpn)」を選択しました。
  6. 以上の設定が済んだら「Apply」しておきます。

 

これで日本語入力もできるようになりました。以前にdynabook SS SX/15AにNetBSD/i386をインストールした時は、そうとう苦労して日本語環境を整えましたが、あまりにも簡単なので、驚きです。 

2026-08-23

FreeBSD 15.1-RELEASEの無線LAN設定

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。インストール中は有線でネットワークに繋ぎました。今後デスクトップ環境を入れていくつもりですが、その前に無線LANの設定を済ませておこうと思います。

 

『FreeBSD Handbook』では「7.4. Wireless Networks」として設定手順が説明されています。それに従って作業すると、次のようになります。

  1. 接続先となるSSIDとPSKを入手しておきます。
  2. 「/etc/wpa_supplicant.conf」を作成します。ひな形が示されているので、そこに入手したSSIDなどの情報を入れます。
  3. 「/etc/rc.conf」に無線LANの情報を追加します。これも示された手順のとおりです。ただし設定ファイルを直接編集せずに、「sysrc」というコマンドを使っているのを初めて知りました。
  4. 以上で設定が済んだので「service netif restart」とすれば、繋がるはずです。

 

ところが繋がりませんでした。これまではdynabook SS SX/15AのNetBSD/i386で接続できていたので、何が違うのか確認してみました。私の自宅ではステルスSSIDとしていたため、「network」の設定の中に「scan_ssid=1」を入れておく必要があるようです。これを追加したら、繋がるようになりました。しかしGeminiと相談した結果、ステルスSSIDはセキュリティ的に望ましくないという意見だったので、ステルスSSIDを止めて公開設定に変更しました。そうなると「scan_ssid=1」は不要です。

 

さらに「/etc/rc.conf」に「create_args_wlan0="country JP regdomain JAPAN"」という設定も追加しました。『FreeBSD Handbook』が英語版であるからなのか、日本特有の設定については記述がありません。これもまたGeminiとの相談の結果ですが、この設定は必須とのことでしたので、追加しました。

 

以上で無線LANが使えるようになりました。若干トラブルがありましたが、とても簡単でした。 

2026-05-25

dynabook SS SX/15Aの代替を探したい

20年ほど前に購入した「dynabook SS SX/15A」には「Windows Vista」がインストールされていましたが、2017年にサポート終了となったので「NetBSD/i386」に入れ替えて使い続けてきました。メモリは4Gなので、32bit CPUとしてはフル実装ですが、HDDが60Gしかないので、窮屈です。換装しようにも、1.8インチHDDが使われているため、代替品を入手するのが困難です。

 

さらに昨今はソフトウェア側で32bit CPU対応を止めるものが多くなってきています。日常的に使用しているわけではないので、最新版を使いたいわけでもないのですが、利用可能なバージョンが古くて不便な状況に追い込まれてきました。

 

しかも、電源を入れても素直にOSが起動しない場合があります。そういう場合は、ノートPCごとを揺すってみたり、表面とか裏面から手で押してみるとかを繰り返すと、起動できるようになります。いったん起動してしまえば、動作中に落ちることはありません。大昔の家電製品は故障したら叩けば直ると(嘘か真か)言われていましたが、それに近いものがあります。

 

このままダマしダマし使い続けるのは可能だと思いますが、そろそろ代替品を探して、移行しようと思います。次もNetBSDにしようと考えています。新品である必要はないので、中古かジャンク品を入手しようと思っています。2万円くらいで入手できないかと思い探しています。通販でもよいのですが、現物を確認して買いたいところです。

2026-02-26

NFD形式ファイルをFDI形式に変換するスクリプトを作成

Windows11上のT98-NEXTでWizardryをプレイするとNFD形式でフロッピーディスクイメージが作られます。これをNetBSD/i386上のxnp2で利用するにはFDI形式に変換しなくてはなりません。NFD形式とFDI形式の構造について調べたので、NFD→FDIの変換をおこなうスクリプトを作りました。この目的はWizardryでプレイしたファイルを変換したいだけなので、大雑把な作りになっています。 

以前なら、GoogleなどでWebを検索して、参考となるサイトを探していました。今でも同様なのですが、最近はGeminiと対話しながら、作成するようになりました。世間一般では、生成されたスクリプトを何も考えずに使うだけなのか、それとも生成されたものを参考にしながら自前で作るのか、どうしているのかはわかりません。私の場合には、Geminiが生成したスクリプトを参考にして、自分で作り上げるようにしています。

その結果、以下のようなスクリプトが出来上がりました。これを使用して、T98-NEXTが出力したNFD形式ファイルを変換してみました。それをxnp2で読み込んでみましたが、問題ないようです。これでT98-NEXT(NFD)→xnp2(FDI)ができるようになったので、途中まで冒険した続きができます。xnp2が出力するファイルはFDI形式になりますが、T98-NEXTはFDI形式も読めるので、FDI→NFD変換スクリプトは作らなくても良いでしょう。

#!/usr/bin/python3
import os
import pathlib
import sys
import ctypes

# 基本的な型のエイリアス
BYTE  = ctypes.c_uint8
WORD  = ctypes.c_uint16
DWORD = ctypes.c_uint32

# セクタ情報
class NFD_SECT_ID(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ("C",        BYTE),
        ("H",        BYTE),
        ("R",        BYTE),
        ("N",        BYTE),
        ("flMFM",    BYTE),
        ("flDDAM",   BYTE),
        ("byStatus", BYTE),
        ("byST0",    BYTE),
        ("byST1",    BYTE),
        ("byST2",    BYTE),
        ("byPDA",    BYTE),
        ("Reserve1", ctypes.c_char * 5),
    ]

# NFDヘッダ
class NFD_FILE_HEAD(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ("szFileID",    ctypes.c_char * 15),
        ("Reserve1",    ctypes.c_char * 1),
        ("szComment",   ctypes.c_char * 0x100),
        ("dwHeadSize",  DWORD),
        ("flProtect",   BYTE),
        ("byHead",      BYTE),
        ("Reserve2",    ctypes.c_char * 10),
        ("si",          NFD_SECT_ID * (163 * 26)),
        ("Reserve3",    ctypes.c_char * 0x10),
    ]

# FDIヘッダ
class FDI_FILE_HEAD(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ("Reserve1",   DWORD),
        ("dwMedia",    DWORD),
        ("dwHeadSize", DWORD),
        ("dwDataSize", DWORD),
        ("dwSectSize", DWORD),
        ("dwSecter",   DWORD),
        ("dwHead",     DWORD),
        ("dwCylinder", DWORD),
        ("Reserve2",   ctypes.c_char * (4096 - 4 * 8)),
    ]

if __name__ == "__main__":
    try:
        nfd = open(sys.argv[1], "br")
    except:
        print("usage: NFD2FDI <filename>")
        exit(1)

    try:
        nfdpath = pathlib.Path(sys.argv[1])
        fdi = open(nfdpath.with_suffix(".FDI"), "wb")
    except:
        print("cannot open FDI file")
        exit(1)

    NFDheader = NFD_FILE_HEAD()
    nfd.readinto(NFDheader)

    FDIheader = FDI_FILE_HEAD()
    FDIheader.dwMedia = 0x90
    FDIheader.dwHeadSize = 4096
    FDIheader.dwSectSize = 256
    FDIheader.dwSecter = 26
    FDIheader.dwHead = 2
    FDIheader.dwCylinder = 77
    FDIheader.dwDataSize = (FDIheader.dwSectSize
                            * FDIheader.dwSecter
                            * FDIheader.dwHead
                            * FDIheader.dwCylinder)


    try:
        nfd.seek(NFDheader.dwHeadSize)
        rawdata = nfd.read(FDIheader.dwDataSize)
        fdi.write(FDIheader)
        fdi.write(rawdata)
    except:
        print("read/write error")
        exit(1)

    exit(0)
#[EOF]

2026-02-25

T98-NEXTのNFD形式はxnp2では扱えなかった

NetBSD/i386でxnp2が動くようになり、PC-9801用Wizardryが動作したので、Windows 11上のT98-NEXTで保存したファイルを使おうとしたら、認識されませんでした。T98-NEXTではNFD形式ですが、xnp2はFDI形式を期待しているようです。FDイメージファイルの形式は、なんでも良いかと思っていましたが、そうでもないようです。

 

ネットを検索すると、FDイメージファイルの形式を変換するプログラムが見つかりました。NFD形式からFDI形式に変換できましたが、xnp2では認識されません。

 

変換されたフィルを確認すると、認識されるFDI形式とはファイルサイズが違うようです。強引ですが、バイナリエディタを使い、余分なところを切り詰めてみました。そうしたら、xnp2でも認識されるようになりました。

 

これで、Windows11上のT98-NEXTで途中までプレイした結果ファイル(NFD形式)を、FDI形式に変換し、末尾を切り落として、NetBSD/i386にコピーすれば、xnp2で続きをプレイできます。途中の手順がやや面倒ですが、機械的に処理する方法を探ってみようと思います。

2026-02-24

NetBSD/i386 9.4上のxnp2 0.86でPC-9801用Wizardryが動いた

NetBSD/i386 9.4にxnp2 0.86をインストールできたので、PC-9801用のWizardryを動かしてみました。何のトラブルに見舞われることもなく、あっさりと動作しました。

 

Windows11上でT98-NEXTを使っている場合には、FDイメージのファイルには拡張子「.NFD」がつくのですが、xnp2は「.FDI」か「.D88」を期待するようです。しかしこれは拡張子のネーミングの問題に過ぎないと思うので、FDイメージの構造が異なるわけではないでしょうから、おそらく問題にはならないと思います。

 

 xnp2は、FDイメージファイルをアクセスする際に、FDドライブのシーク音を出します。これはT98-NEXTには無かった機能です。物理的なFDドライブが存在するわけではないので、気分の問題ですが、シーク音を耳にすると懐かしさを覚えます。またリセット直後には、おなじみの「ピポッ」という音がなります。これはT98-NEXTもそうでした。これが聞こえるとPC-9801の思い出が蘇ります。

 

これで、Windows11上のT98-NEXTと、NetBSD/i386上のxnp2で、Wizardryが遊べるようになりました。両方の環境を使って遊ぶには、途中経過を記録したFDイメージの取り扱いが問題になってくるでしょう。何か良い方法を考えようと思います。 

NetBSD/i386 9.4でxnp2 0.86が動作した

NetBSD/i386 9.4環境で、パッケージからnxp2をインストールしようとしました。そうしたら共有ライブラリの不整合が発生し、pkgin full-upgradeを実行しました。するとエラーが出て、Geminiに相談しながら調査したら、パッケージ管理ディレクトリが/var/db/pkgと/usr/pkg/pkgdbの2箇所に見つかり、これが原因で深刻な不整合が起きていることが発覚しました。Geminiのアドバイスを受けながら、インストール済みの全パッケージを削除し、入れ直しました。しかし欠けているパッケージがあるので、確認しながら、追加インストールして、ようやくMATEデスクトップ環境が復活しました。

 

あらためて、本来の目的だったxnp2をインストールしました。何も問題がなくインストールできました。

 

動かしてみたのですが、PC-9801の起動時画面が出るはずですが、文字がかすれて読めません。フォントを別途入手する必要があるようです。Neko Project 21/Wのサイトから「font.bmp」を入手して「~/.np2/font.bmp」に置きました。これで起動時画面の文字が読めるようになり、一歩前進です。

 

次は、Wizardryが動くか確認しようと思います。 

2026-02-23

NetBSDのパッケージ管理情報が/usr/pkg/pkgdbと/var/db/pkgで混乱していた

NetBSD/i386にxnp2を入れようとしたら、共有ライブラリのトラブルが発生したので、pkginを使ってfull-upgradeを試みました。そうしたら、MATEが消えてしまい、ログインできなくなりました。あらためてpkginでMATEをインストールしようとしたら、多くのエラーメッセージが出て、インストールできません。

 

以前であれば、問題解決のためにGoogleで検索して似たような事例を探していたのですが、最近はGeminiに相談するようになりました。MATEのパッケージがインストールできないので解決したいというのが、Geminiに相談したことなのですが、Geminiがアドバイスしてくれたコマンドを叩くとエラーが発生します。それをGeminiに伝えると、また別のアドバイスをくれるので、対話を繰り返していると、次第に深みにはまってきました。

 

トラブルの根本原因は、NetBSDのパッケージ管理情報が/usr/pkg/pkgdbと/var/db/pkgの2か所に存在していることが判明しました。このように2か所に存在しているので、双方の情報が重複したりしていて、不整合も発生しているようです。こうなってしまうと、MATEがどうこうという問題よりも、この不整合を如何に解決するかという方が、重大な問題になりました。

 

Geminiのアドバイスを貰いながら対処を試みましたが、深刻な障害が解消しません。多少強引ですが、最後の奥の手として、インストール済みのパッケージをリストしておき、インストール済み全パッケージを削除し、あらためてインストールしなおすことにしました。

 

今は、インストール済のパッケージを削除しているところです。1,000以上ものパッケージがインストールされていたので、削除するだけでも長時間かかります。削除が終わったら、再インストールしますが、それも長時間かかるでしょう。 

NetBSDにバイナリパッケージxnp2を入れたらMATEが動かない

NetBSDのパッケージにはPC98エミュレータxnp2が含まれていることがわかったので、バイナリパッケージを入れてみました。バイナリパッケージを入れるのに「pkgin」を利用しています。OSがNetBSD/i386 9.0なので、パッケージ2025Q4のNetBSD/i386の9.0用を参照しました。

 

xnp2に依存関係のあるパッケージが有るのか無いのか不明ですが、最近1年以上もパッケージを更新していなかったので、追加更新に60個弱のパッケージが必要になりました。各々のパッケージが本当に必要なのか厳密に確かめることができるかもしれませんが、それをするなら「pkgin」を使う意味がないと思い、それらのパッケージを全てインストールしました。

 

インストール自体には問題がありませんでしたが、ログインできなくなりました。正確には、XDMでログインしたあとで、MATEを動かしているのですが、共有ライブラリが見つからないとのことで、XDMログイン画面に戻ってしまいます。rootは、MATEではなく,TWMのままなので、問題ありませんでした。「~/.xsession-errors」を確認すると、共有ライブラリが見つからないとあります。確かにその通りでしたが、シンボリックリンクを張れば解決できそうなので、対処しました。そして再度ログインしてもXDMに戻ってしまいます。別の共有ライブラリが見つからないようです。これを繰り返したら、最終的に共有ライブラリに定義されていないものがあるというエラーになりました。

 

もうお手上げなので、Geminiに相談したら、libxkbcommonという共有ライブラリを再インストールすることを勧められました。やってみましたが、解決しませんでした。それをGeminiに訴えると「pkgin full-upgrade」を試してみるように言われました。これなら解決できそうですが、作業時間が長いですし、xnp2とは関係ないところで、別な不具合が出てくるかもしれません。

 

しかし、これ以外に対処方法はないと思うので、もう後戻りはできない状態になっています。何か別の問題がでたら、また解決方法を模索するしかないでしょう。 

2026-02-21

NetBSDでPC98エミュレータ

Windows 10を使っていたころに、T98-NEXTというPC98エミュレータを使ってWizardryを遊んでいました。「PC-9800シリーズエミュレータの現況」という記事によると、PC98エミュレータは他にもあるようです。しかしMicrosoft Windowsなら選択肢は多いかもしれませんが、非Windowsでは選択肢が限られると思います。

 

ちょっと検索したら、次のような記事が見つかりました。これらの記事では、NP2kai(Neko Project II 0.86 kai)を使って、ソースからビルドしているようです。OSにはUbuntuを使っているようなのですが、私はNetBSD/i386を使いたいのです。

 

上述した記事を参考にすれば、NetBSD/i386環境であっても、ソースからビルドできるのではないかと思います。ビルド環境を整えたり、ビルドしてみてエラーが出るかもしれませんし、何かと手間がかかるだろうとは思います。もしかしたら何の苦労もなくビルドできてしまう可能性もありますが、そう簡単ではないだろうと予想しています。

 

自前でビルドする前に、ちょっとパッケージを確認したら、なんと「emulators/xnp2」がありました。これは「Xnp2 is a port for UNIX with X11 of "Neko Project II" PC-9801 emulator.」だそうです。自前でビルドしなくても、既にパッケージが用意されていました。

 

このパッケージをインストールしてみようと思います。このPC98エミュレータでWizardryを動かしてみようと考えていますが、問題なく無事に動いてくれるか心配です。もしトラブルようであれば、デバッグすることになるかもしれませんので、自前でビルドできる環境を整えておく必要が出てくるかもしれません。 

2024-08-16

LibreOfficeで日本語変換をおこなうために追加処置は必要なかった

dynabook SS SX/15AにNetBSD/i386 10.0を入れたらLibreOfficeが起動しなくなりました。調べてみても、簡単には解決に至らなそうだったので、NetBSD/i386 9.4に戻すことにしました。このバージョンならLibreOfficeが起動するのを確認しました。

 

2016年末頃、このマシンにNetBSD/i386環境を構築していた時には、LibreOfficeで日本語変換をおこなうには追加処置が必要でした。その手順は「NetBSD/i386でLinuxバイナリ版LibreOfficeの日本語変換に成功 」に書いたとおりです。今回も同様の手順をおこなう必要があるのかと思っていました。

 

この追加処置を行う前に、試しにLibreOfficeで日本語変換をおこなってみたら、なんと普通に日本語変換が可能でした。いつのまにか改善されていたようです。

2024-08-15

NetBSD/i386 9.4にダウングレードしたら、LibreOfficeが動作した

まさかLibreOfficeが動かなくなるとは思わなかったので、dynabook SS SX/15AのNetBSD/i386を9.3から10.0にアップグレードしました。VirtualBOX環境を利用して調べてみたところ、理由は不明ですが、NetBSD/i386 10.0ではLibreOfficeが動かないようです。このままにしておいて、LibreOfficeが動作するまで待つという方法もありますが、何時になるかわかりません。それまで待っていられないので、NetBSD/i386 9.4にダウングレードすることにしました。

 

いままでバージョンアップしたことは何度もありますが、バージョンを下げた経験はありません。慎重に作業しようと思います。

 

バージョンアップの歳は、まず最初にカーネルだけを入れ替えてみて、起動できるか確認していました。その後、問題なさそうなら、ユーザランドをTGZファイルで入れ換えていました。今回はダウングレードなので、カーネルを先に入れ換えてしまうと、ユーザランドが新しいカーネルの機能を利用しようとしている場合に、致命的な問題を引き起こしてしまう可能性があります。そこで最初に9.4用TGZでユーザランドを入れ替えます。この時点ではカーネルは10.0になっています。ここでリブートしてみて、問題なければ、カーネルも9.4に入れ換えます。特に問題がおきることもなく、カーネルもユーザランドも9.4になってくれたようです。そしてetcupdateでファイルを置き換えます。

 

これでNetBSD/i386 9.4環境になったので、pkginでLibreOfficeとSUSEをインストールしました。試しにLibreOfficeを起動してみたところ、スプラッシュ画面が出たあとで、問題なく起動しました。そうなると、やはりNetBSD/i386 10.0には、問題の所在は不明ですが、何か問題が潜んでいるのではないかと思います。 


NetBSD/i386上でLibreOfficeが動くようになりましたが、過去の経験では、日本語を扱うには多少追加作業が必要だったはずです。どのような作業だったのか、当時の記録を確認して、設定を済ませたいと思います。

パッケージ「libreoffice6-bin」で入れたLibreOfficeは、NetBSD/i386 10.0では動かないが、NetBSD/i386 9.3なら動いた

Windows Vistaを使っていたノートPCをNetBSD/i386に入れ換えて使っています。先日NetBSD/i386 9.3から10.0に更新しましたのですが、インストールされていたLibreOfficeが動作しなくなりました。


問題が発覚した場合には、僕のマシン環境に何か原因があるのか、いかなる環境だろうと問題が発生するのか、最初に見極めなければなりません。このためにVirtualBOXを利用して、NetBSD/i386とLibreOfficeだけをインストールしてみて、動作するか否かを確認するのが、まず最初におこなうことです。

 

VirtualBOX上でNetBSD/i386 10.0とLibreOfficeを入れて、動作を確認してみました。LibreOfficeのスプラッシュ画面は出るのですが、いつまで待っても、そこから先に進みません。これは僕のノートPCと同じ挙動なので、まだ断言はできませんが、NetBSD/i386 10.0とパッケージ「libreoffice6-bin」の組み合わせには、何か致命的な問題が潜んでいそうな気がします。

 

念のために別の環境でも試してみました。

 

VirtualBOX上でNetBSD/i386 9.3とLibreOfficeを入れて、動作を確認してみました。LibreOfficeのスプラッシュ画面が出たあと、すぐにLibreOffice本体が起動します。ごく当たり前の動作です。何の問題もありません。

 

以上を踏まえると、NetBSD/i386 10.0でLibreOfficeを利用するのは、当面は難しいのではないかと思われます。何が問題なのか突き止める必要がありますが、全く見当もつかないので、直ちに解決できる気がしません。それならば、NetBSD/i386 10.0にバージョンアップしたノートPCを、NetBSD/i386 9.3に戻すのが良いのかもしれません。

 

NetBSD/i386側なのか、LibreOffice側なのか、問題の原因がどちらにあるのかわかりませんが、問題が解消するまでNetBSD/i386 10.0を利用するのは控えようかと思います。

2024-08-14

NetBSD 10.0のLinuxエミュレーション環境でLibreOfficeが起動するようになったものの、別の問題が生じた

NetBSD/i386を9.3から10.0に更新したら、SUSE13.1を利用しているLinuxエミュレーション環境で動作するLibreOfficeが動かなくなってしまったので、調査してみました。何が問題なのか分からないので、LibreOfficeとSUSEに関するパッケージを全て削除し、関連しそうなディレクトリ「/usr/pkg/emul」 も消してから、再度LibreOfficeのパッケージを入れてみました。SUSE関連パッケージは依存関係にあるので、自動的にインストールされます。

 

そのインストール中に、次のようなメッセージが表示されました。

Do not forget to modload the compat_linux or compat_linux32 modules. Linux binaries require these in order to work. In older NetBSD versions these will be autoloaded. Edit /etc/modules.conf to load the modules automatically on boot.

 

NetBSD 9.3の時には、このような設定をしていませんでしたが、Linuxエミュレーション機能は使えていました。そこで起動した時点からLinuxエミュレーションが有効になるようにしたかったので、ファイル「/etc/modules.conf」でモジュール「compat_linux」を指定しておきました。Webには「NetBSD で Linux binary を実行する方法について」という記事もあるようです。

 

上述した設定を済ませた上でマシンを再起動したところ、LibreOfficeが動き出しました。良かった!と思ったのですが、Calc本体が使えるようになりません。GUIだとエラーが出ても分からないので、コマンドラインから/usr/pkg/opt/libreoffice6.2/program/scalcを直接実行してみました。すると、次のようなメッセージが出ていました。他のメッセージはありません。

javaldx: Could not find a Java Runtime Environment!


一難去ってまた一難というところです。

NetBSD/i386を9.3から10.0に更新したら、LibreOfficeが動かなくなった。

数か月前にNetBSD 10.0がリリースされたので、dynabook SS SX/15AにインストールされているNetBSD/i386を9.3から更新しました。更新自体は問題なく、既にインストールされているアプリケーションも問題なさそうです。ところが、LibreOfficeが起動しないことに気付きました。


NetBSDのパッケージとして提供されているLibreOfficeがインストールしていたのですが、これはSUSEエミュレーション環境上で動作するようになっています。LibreOfficeのパッケージは「libreoffice6-bin-6.2.8」のまま変化していないようだったのですが、念のためにパッケージをインストールし直してみました。すると依存関係にあるSUSEエミュレーション環境のパッケージも更新されました。

 

パッケージを入れ直してから、あらためてLibreOfficeを起動してみましたが、やはり起動しません。coreを吐いている訳ではなさそうです。もしかするとSUSEエミュレーション環境の動的ライブラリが不足しているのかもしれません。

 

NetBSD/i386上でLibreOfficeを動作させないと「とても困る」という状況にはないのですが、今まで動作していたので、動かない筈はないだそうと思います。何が原因なのか追究してみようと思います。このような問題追及は、苦労する割に、解決に至らないで苦しむことも少なくないのですが、そうはならないことを願っています。

2024-02-03

dynabook SS SX/15Aの不調

かなり昔に購入したdynabook SS SX/15Aの調子が最近よくありません。購入当時はWindows Vistaがインストールされていましたが、2017年に延長サポートが終了したので、それ以降はNetBSD/i386に入れ換えています。

 

購入当初より、電源を入れてもOSが起動しないことがありました。画面に「TOSHIBA」というグラフィカルな表示が出たまま先に進まず、なぜか突然ファンが全力で回り出すので、電源を強制的に落としていました。こうなった場合、何度か電源オンと電源オフを繰り返すこともありましたが、何回かするとOSが起動してくれます。 


この原因が何なのか分かりませんが、最近になって、OSが起動するまで電源のオンオフを繰り返す回数が、数回では済まなくなり、数十回になることが出てきました。しかし、一発で順調にOSが起動することもあるので、不調なのは確かですが、完全に壊れた訳でもないようです。

 

マシン本体の調子が良くないし、CPU自体も旧いのでパワー不足を感じるところもあります。さらに1.8インチのHDDが使われているようなので、2.5インチHDDのように気軽に換装できないのも、ちょっと困りものです。メインで使っている訳ではないので、いきなり完全に壊れたことが発覚したとしても、それほど実害はないのですが、できれば気持ちよく使えるマシンの方が有り難いのは確かです。

 

完全に壊れたことが確認されてから、代替機種を入手しても構わないのですが、そろそろ次のマシンを物色してみようかと考え始めました。今はNetBSD/i386ですが、次はNetBSD/amd64にしたいと思います。HDDでもSSDでも構いませんが、自分で換装作業が出来るマシンにしておきたいところです。そして最も重要なポイントは、持ち歩く都合上、B5サイズのサブノートPCであることが必須条件です。


OSは自分でNetBSDを入れるつもりなので、Windowsが入っている必要はありません。また最新機種である必要もないので、中古で十分です。むしろ1~2万円程度で購入したいと思っています。中古で入手できれば良いので、メーカーには拘りません。ただし、ノートPCのキーボードは、左下が「Fn」キーになっている事がありますが、Emacsなどを利用するので「Ctrl」キーになっていてくれれば良いとは思います。

2021-03-30

NetBSD/i386 9.1でパッケージを9.0_2020Q4に更新

dynabook SS SX/15AにNetBSD/i386を入れて使っています。OS本体やパッケージを更新する作業を時々おこなっています。OS自体は昨年末に9.1にしたので、今度はパッケージを9.0_2020Q4で更新しました。


パッケージはpkginを使って、バイナリで更新します。いきなり更新作業を始めると、必要なパッケージをダウンロードしようとして、何故かストールしてしまうので、事前に別のマシンで必要なパッケージを入手しておきます。必要なパッケージは576もありました。これを/var/db/pkgin/cacheに置いておきます。 


pkgin full-upgradeで、全て更新してくれるはずなのです。しかし途中で何やらエラーが発生したようで、2時間半たって処理が完了した時点では、必要なパッケージがゴッソリ消えて、不完全な状態になっていました。エラーログを見て、問題がありそうなファイルを見つけて、個別に対処しました。まったくエラーのない状態には出来ませんでしたが、なんとか復旧できたと思います。


エラーログを確認していると、パッケージ構成スクリプトのバグではないか?と思わせるような記録も残っています。もしかすると気付かないところで、問題が残っている可能性もあると思います。


いろいろと苦労しますが、そのような問題を解決していく過程も、技術力を磨くには良いのかもしれません。

2021-02-26

Windows10でWSL2

いままでWindows10でWSLを利用してきましたが、WSL2も使えるようにしました。


WSL2はWindows10 2004から利用できることになっていますが、去年は2004がいつまで経っても配信されず、なかなかWSL2が使えるようになりませんでした。そのうちに1909でも利用できるというアナウンスが流れたので、2004が待ちきれずに1909でWSL2を使えるようにしてみました。しかしWSL2を使えるようにする設定をおこなうと、VirtualBoxやVMwareに不具合が出たので、WSL2を諦めて、WSLに戻りました。


MicrosoftがWSLとWSL2を同等に機能拡張してくれればよいのですが、WSL2だけしか機能拡張されないような気がするので、なんとかWSL2に移行したいと思っていました。WSL2への移行に挑戦し、もし駄目なら再びWSLに戻るつもりで、移行作業をおこないました。結果としてWSL2が使えるようになりましたが、これまでVirtualBoxで動かしてきた環境が動かなくなるという問題も発生しました。


まずWindow10のバージョンは「バージョン 20H2 (OSビルド 19042.804)」です。ちなみにVirtualBoxは「バージョン 6.1.18 r142142 (Qt5.6.2)」を、VMwareは「VMware(R) Workstation 15 Player 15.5.7 build-17171714」を使っています。


作業手順は次の通りです。「Windows 10 用 Windows Subsystem for Linux のインストール ガイド」を参考にしました。

  1. ダイアログ「Windowsの機能」から「Linux用Windowsサブシステム」と「仮想マシンプラットフォーム」を有効にしました。前者は既に有効になっており、後者はWSL2のために有効にしました。
  2. ここでマシンを再起動しました。
  3. インストールガイドに従い「wsl_update_x64.msi」をダウンロードし、インストールしました。
  4. WSLではUbuntuを入れていたので、WSL2へ移行作業をおこないました。この作業に数時間かかったという報告をWebで見かけますが、15分くらいで終わりました。

    C:\Users\FURUSAWA>wsl --set-version Ubuntu 2

    変換中です。この処理には数分かかることがあります...

    WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

    変換が完了しました。

    C:\Users\FURUSAWA>wsl --list --verbose

      NAME      STATE           VERSION

    * Ubuntu    Stopped         2


これで無事にWSL2が使えるようになりましたが、これまでVirtualBoxで動かしていたCentOS 7.4が起動しなくなりました。しかしVMwareを使えばCentOS 7.4が動くので、それで良しとします。VirtualBoxでは、他にも、openSUSE、FreeBSD、NetBSDを動かしており、それらに問題はありませんでした。

2020-09-27

SSHを鍵認証する場合の鍵作成の方針とは?

SSHで鍵認証を利用する際に必要となる秘密鍵・公開鍵は、どのような方針で作成するものなのでしょうか?ssh-keygenで鍵を作成するわけですが、コマンドを打てば鍵が出来てしまいますが、それがSSH鍵認証で想定している方針に合致しているとも限らないわけです。


ssh-keygenで作成した公開鍵は、以下のような形をしています。右端にあるのはコメントでオプションで変更することができますが、デフォルトでは鍵を作成したユーザ名が入ります。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABErI+RbZ foo@bar.com


このデフォルトで与えられるコメントを考えると、鍵は「ユーザ(とホスト)」を単位に作成されるものと考えるのが基本なのかと思います。SSH鍵認証の入門レベルの説明としては、それで構わないと思います。しかし現実の環境において、多数のサーバを扱う管理者であれば、どうなってしまうのでしょうか。サーバが何十台もあったとしても、各サーバでssh-keygenを用いて鍵を作成することは可能でしょう(サーバ上に秘密鍵を置くことの是非はあるかもしれませんが)。作成された公開鍵を全サーバに配置していく作業は(できるかもしれませんが)大変です。さらに作業が大変か否かという実務的な問題だけではなく、各サーバに秘密鍵が置かれていることがセキュリティ的に妥当といえるのかという問題もあるでしょう。


このような問題はssh-agentssh-addを利用することで解決できそうです。「エージェント転送」を使えば、クライアントマシンだけに秘密鍵を置いておけば、その他のサーバに秘密鍵を置く必要がなくなるようです。


管理者が使用しているクライアントマシンで鍵を作成しておけば、全サーバでは鍵を作成しなくて良くなるのですから、これで疑問は解消したと言えるのでしょうか。つまり鍵は「個人」を特定するものなのでしょうか。


それでは管理者が複数のマシンをクライアントとして利用している場合には、どうなるのでしょうか。鍵が「個人」を特定するのであれば、同一管理者が使用する全クライアントマシンでは、秘密鍵を使いまわすことになります。それでも構わないのかもしれませんが、そのような運用を認めると、複数の管理者で秘密鍵を使いまわすことに繋がる恐れもないとは言えません。


運用次第で何とでもなるという話ではなく、SSH鍵管理の発想とは何だったのかという事を知りたいと思います。