FreeBSD/sparc64の話題


Ultra30 FreeBSD-10.2インストール備忘録(2015.10.31)

Sun Ultra30にFreeBSD-10.2/sparc64をインストールしたときの顛末です。せっかくFreeBSDを使用するので、ZFSでmirrorを構築してみました。

インストールしたマシンのスペックは下記の通りです。

インストールはシリアルコンソールで行いました。シリアルコンソール環境は、IBM ThinkPad T43+iBuffalo BSUSRC0605BS+TeraTermです。

使用したUltra30はCreatorを積んでいるのでコンソールで使えるようにもしたいとは思いましたが、設置場所の問題とシリアルコンソールの方がログを楽にとれるのがわかっていたので、シリアルコンソールにしました。

インストール手順は、root on ZFSといってもamd64であればインストーラーにメニューが出てきてそれを選ぶだけです。しかし、sparc64のインストーラーにはこの項目がありませんので、シェルにおりて手動で設定する必要があります。といっても、ほぼInstalling FreeBSD 9.x Root on ZFS using VTOC8 (sparc)の通りに行っただけです。変更点、注意点は下記の通りです。

  1. ディスクラベルのないHDDにgpart destroyするとエラーが出ましたが、実害はないので無視しました。
    
    # gpart destroy -F da0
    gpart: arg0 'da0': Invalid argument
    # gpart destroy -F da1
    gpart: arg0 'da1': Invalid argument
    
    
  2. zpool createでメッセージが出るので、眺めておきました。
    
    # zpool create -o altroot=/mnt -O canmount=off zroot mirror da0a da1a
    ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present;
                to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf.
    ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior.
                 Consider tuning vm.kmem_size and vm.kmem_size_max
                 in /boot/loader.conf.
    ZFS filesystem version: 5
    ZFS storage pool version: features support (5000)
    
    
  3. 2回目以降のインストールではzpool createがエラーになるので、コマンドが表示するように-fオプションを追加しました。
    
    # zpool create -o altroot=/mnt -O canmount=off zroot mirror da0a da1a
    ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present;
                to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf.
    ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior.
                 Consider tuning vm.kmem_size and vm.kmem_size_max
                 in /boot/loader.conf.
    ZFS filesystem version: 5
    ZFS storage pool version: features support (5000)
    invalid vdev specification
    use '-f' to override the following errors:
    /dev/da0a is part of potentially active pool 'zroot'
    /dev/da1a is part of potentially active pool 'zroot'
    
    # zpool create -f -o altroot=/mnt -O canmount=off zroot mirror da0a da1a
    
    
  4. /boot/loader.confにもともとzfs_load="YES"の行があったので、この行は追加しませんでした。
    
    # cat /boot/loader.conf
    zfs_load="YES"
    
    

インストールにかかる時間は想定していたほど長くはなく、手作業の部分を含めて1時間半もあれば十分でした。

インストール後にインストーラーで設定した項目の修正を1点行いました。インストール時にPCのごとくハードウェアクロックをlocaltimeにしてしまいましたが、OBPはUTCで時刻を保持するようなので、tzsetupを実行しUTCに変更しました。

インストール後の作業として、以下の3つを行ってみました。


portsによるインストール(2015.10.31)

最初は、OS付属のports treeを使用しました。まず、make indexを実行したのですが、4時間程度かかりました。

Xorgは就寝中の(コンフィグ)入力待ちもあったため、足かけ3日かかりました。

Emacsをインストールしようとしたところ、OS付属のpcre-8.37_2は脆弱性があるといわれたので、portsnap fetch & extract & updateをしました。 バージョンは、pcre-8.37_4になりました。

editors/emacsのビルドでは、コンフィグでX11を有効にしているのに、なぜか下記のように無効のメッセージが表示されました。


root@ultra30:/usr/ports/editors/emacs # make install clean

====> To disable X11 support, define: WITHOUT_X11.

途中、下記のエラーとなり、devel/llvm36のビルド(インストール)が失敗しました。


===>  Checking if llvm36 already installed
===>   Registering installation for llvm36-3.6.2_2 as automatic
pkg-static: Unable to access file /usr/ports/devel/llvm36/work/stage/usr/local/share/doc/llvm36/html/jquery-1.11.1.js: No such file or directory
pkg-static: Unable to access file /usr/ports/devel/llvm36/work/stage/usr/local/share/doc/llvm36/html/underscore-1.3.1.js: No such file or directory
*** Error code 74

Stop.

MLの情報を参考に、日を置いてportsnap fetch; portsnap updateした上で、textproc/py-sphinxをmake reinstallしました。

ports-mgmt/pkgが古いといわれたので、make reinstallしようとしましたが、下記メッセージが出たので、make deinstall; make reinstallしました。


===>  Installing for pkg-1.6.0
===>  Checking if pkg already installed
===>   An older version of pkg is already installed (pkg-1.5.4)
      You may wish to ``make deinstall'' and install this port again
      by ``make reinstall'' to upgrade it properly.
      If you really wish to overwrite the old port of pkg
      without deleting it first, set the variable "FORCE_PKG_REGISTER"
      in your environment or the "make install" command line.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

Stop.
make: stopped in /usr/ports/ports-mgmt/pkg

改めて、py-sphinxのmake reinstallをしたところ、成功しました。

続けて、emacsのmake installすると、llvm36のインストールが成功しました。

しばらく順調に依存パッケージがビルドされていきましたが、devel/libclcのビルドが失敗しました。

devel/libclcはLLVMのclangとlibc++を使用してビルドしますが、clangとlibc++の整合性が悪いように見えたので、修正が入るのを何日か待ちましたが直る気配が全くないので、結局、editors/emacsのインストールはあきらめました。

代わりに、editors/emacs-nox11をインストールしました。こちらは特に問題なくインストールできました。

japanese/sj3-server、editors/tamagoとmail/mewもインストールして、メールの送受信環境を構築しました。


DNSサーバーのインストール(2015.10.31)

ハンドブックを参考に、dns/bind910をインストールしました。


Sambaのインストール(2015.10.31)

net/samba42をインストールしようとしましたが、依存するp5-Parse-Yapp-1.05_1のビルドに失敗しました。portsの問題(マニュアルページのパスに"share"が入るか入らないか)と思われるので何日か待ちましたが解決しないため、あきらめてdevel/p5-Parse-Yappに依存しないnet/samba36をインストールしました。


Apacheのインストール(2015.10.31)

www/apache24をインストールしました。特に問題なくビルドできました。


使用しての所感(2015.10.31)

portsはうまくビルド出来ないものがあり、それにあたると苦労します。

OSの安定性は悪くなく、数日portsのビルドで放っておいてもクラッシュすることはありません。また、CPUやHDDの性能を考えるとパフォーマンスもそれなりに出ていると思います。

全体としては、古いUltraを再生するにはFreeBSDは悪くないと感じています。


10.3RELEASEへのアップグレード(2016.5.14)

ハンドブックにしたがって、以下の手順でアップグレードしました。

  1. root CA更新
    
    # cd /usr/ports/security/ca_root_nss
    # make install clean
    
    
  2. subversionインストール
    
    # cd /usr/ports/devel/subversion
    # make install
    # make clean
    
    
  3. /usr/src/の待避
    
    # mv /usr/src /usr/src_10.2-Release
    # mkdir /usr/src
    
    
  4. sourceの取得(svn実行)。当初、httpsで実行していたがエラーになるため、svnプロトコルに変更
    
    # svn checkout svn://svn.FreeBSD.org/base/release/10.3.0 /usr/src
    
    
  5. /usr/src/UPDATINGを読む
    
    less /usr/src/UPDATING
    
    
  6. 古い/usr/obj/を削除
    
    # chflags -R noschg /usr/obj/*
    # rm -rf /usr/obj
    
    
  7. make buildworld実行(約20時間かかった)
    
    # cd /usr/src
    # make buildworld
    
    
  8. make buildkernel実行(約6時間かかった)
    
    # make buildkernel
    
    
  9. make instllkernel実行(数分で終わった)
    
    # make installkernel
    
    
  10. シングルユーザーモードに移行
    
    # shutdown now
    
    
  11. ファイルシステムを読み書き可能でマウント
    
    # zfs set readonly=off zroot
    # zfs mount -a
    
    
  12. キーマップをJapanese 106に設定
    
    # kbdmap
    
    
  13. 日付時刻を修正
    
    # adjkerntz -i
    
    
  14. 現在の/etcを保存
    
    # cp -Rp /etc /etc.old
    
    
  15. mergemsterを実行(1)(passwd、group、shells以外は置き換え)
    
    # mergemaster -iF
    
    
  16. make installworldを実行(30分程度で完了)
    
    # cd /usr/src
    # make installworld
    
    
  17. mergemasterを実行(2)
    
    # mergemaster -p
    
    
  18. 古いファイルの確認と削除(とりあえず不用とされたものはすべて削除)
    
    # cd /usr/src
    # make check-old
    # make delete-old
    
    
  19. 新しいバージョンで起動
    
    # reboot
    
    

kernel panicで落ちました。


(省略)
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
pci1:  at device 0.0 (no driver attached)
hme1:  mem 0x2800000-0x2807fff at device 0.1 on pci1
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc0581ca0 at panic+0x20
#1 0xc08e9e54 at trap+0x554
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Resetting ...

以下、試した復旧内容です。

  1. ブート途中の下記のところで、リターン以外のキーを押下し、loaderに入る
    
    Hit [Enter] to boot immediately, or any other key for command prompt.
    
    
  2. 古い(10.2RELEASE)のkernelで起動。これで、立ち上がりました。
    
    OK boot kernel.old
    
    
  3. 古い(10.2RELEASE)のkernelを保存
    
    # cd /boot
    # cp -Rp kernel.old kernel.10.2
    
    
  4. 新しいユーザーランドでビルドしたらpanicしない可能性もあると思い、make buildkernelおよびmake installkernelを実行
    
    # chflags -R noschg /usr/obj/*
    # rm -rf /usr/obj
    # cd /usr/src
    # make buildkernel
    # make installkernel
    
    
  5. 新しいユーザーランドでビルドしたkernelで起動
    
    # reboot
    
    

やっぱり落ちます。


(省略)
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
pci1:  at device 0.0 (no driver attached)
hme1:  mem 0x2800000-0x2807fff at device 0.1 on pci1
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc0581ca0 at panic+0x20
#1 0xc08e9e54 at trap+0x554
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Resetting ...

10.3RELEASEのインストールCDでどうか試してみました。


(省略)
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
pci1:  at device 0.0 (no driver attached)
hme1:  mem 0x2800000-0x2807fff at device 0.1 on pci1
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc0581ca0 at panic+0x20
#1 0xc08e9e54 at trap+0x554
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Resetting ...

やっぱり落ちます。

ということで、今のところはここまで。

OBPからloaderにパラメーターが渡せると便利だと思う今日この頃。


send PR(2018.10.15)

そうこうしているうちに、11.0-RELEASEがリリースされたので、こちらでも試しましたが、同様にpanicで落ちました。

試しに12.0-CURRENT(r315864)のインストールCDで試してみました。


(省略)
sym0: <875> port 0x1000-0x10ff mem 0x108000-0x1080ff,0x10a000-0x10afff at device 3.0 on pci0
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
mpt0:  port 0x1000-0x10ff mem 0x100000-0x11ffff,0x120000-0x13ffff at device 1.0 on pci1
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
time = 1
KDB: stack backtrace:
vpanic() at vpanic+0x224
panic() at panic+0x20
trap() at trap+0x5cc
-- fast data access mmu miss tar=0 %o7=0xc0a0f768 --
userland() at psycho_route_interrupt+0xd4
user trace: trap %o7=0xc0a0f768
pc 0xc0a0f794, sp 0xc1416271
done
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x80: ta              %xcc, 1
db>

やっぱり落ちます。

しかし、よく見るとヒントがありました。以下の部分です。


userland() at psycho_route_interrupt+0xd4

"psycho_route_interrupt"のあたりでpanicを起こしていそうです。

カーネルソース(/usr/src以下)をgrepで総あたりで検索してみると、/usr/src/sys/sparc64/pci/psycho.cに"psycho_route_interrupt"という関数が見つかりました。

psycho.cの先頭のほうにコメントがあり、"psycho"とは、UltraSPARC IIマシンに搭載された"UPA to PCI bridge"とのことです。

少しソースコードから離れて、panicが起こる条件を調べてみました。

すると、PCIスロットに拡張カードをさしていない場合はpanicせず、さしている場合にpanicすることがわかりました。PCIスロットにさすカードの種類や枚数の組み合わせを変えてみましたが、どのカードでも1枚(以上)させばpanicすることがわかりました。

ここまでわかったので、/usr/src/sys/sparc64/pci/psycho.cの更新履歴をソースコードリポジトリのウェブインタフェースで追いかけてみました。

10.3-RELEASEで探すと、revision 266020とrevision 292789の間で関数 psycho_route_interruptに気になる差異がありました。

具体的には、r266020では、


sc = device_get_softc(bridge);

r292789では、


sc = device_get_softc(dev);

となっていました。

scはローカル変数で、一度値が代入されると参照しかされません。また、bridgedevは、関数psycho_route_interruptの引数として渡されているため、明らかに別物です。

これらの情報から、r266020(sc = device_get_softc(bridge);)に先祖返りするパッチを作り、カーネルソールに適用し、カーネルを再構築したところ、問題なく立ち上がるようになりました。

なお、パッチはたったの1行です。


--- /usr/src/sys/sparc64/pci/psycho.c.orig      2017-03-18 05:47:13.173917051 +0900
+++ /usr/src/sys/sparc64/pci/psycho.c   2017-03-18 06:49:05.436646972 +0900
@@ -950,7 +950,7 @@
	 * for bus A are one-based, while those for bus B seemingly have an
	 * offset of 2 (hence the factor of 3 below).
	 */
-	sc = device_get_softc(dev);
+	sc = device_get_softc(bridge);
	intrmap = PSR_PCIA0_INT_MAP +
	    8 * (pci_get_slot(dev) - 1 + 3 * sc->sc_half);
	mintr = INTINO(PSYCHO_READ8(sc, intrmap)) + pin - 1;

ここまでの情報をもとに、 FreeBSD Bugzillaで検索しても該当しそうなPRがなかったことと、freebsd-sparc64メーリングリストに問いかけを行いましたが、明確な回答は得られなかったため、send PRすることにしました。

PRはBug 218478 - [patch] Ultra30 panics during boot with PCI cardです。

send PRするには、まず、Bugzillaにアカウントを作成する必要があります。send PRするページcreate a new accountというリンクがあるので、リンク先のページにしたがってアカウントを作成します。

ログイン直後のページで、どのカテゴリーに属する問題かを指定します。今回はカーネルの問題なので"Base System"を選択しました。

その次のページで、詳細項目を入力します。ここでは、Severityに少し悩みました。"Affects Only Me"、"Affects Some People"、"Affects Many People"の3つの選択肢がありますが、Ultra30を使用しているユーザーが私以外にもいるだろうと考え、"Affects Some People"を選択しました。

Descriptionには、簡単な説明を記載し、panicするときのログとパッチを適用後、問題なく起動したときのログをはりつけました。

また、パッチをアップロードしました。ちなみに、パッチを添付する場合にはSummaryに[patch]という文字列を先頭に付与し、パッチ形式はunified diffと指定されています

なお、今回panic時のログは12.0-CURRENTのものにしましたが、パッチと正常起動ログは10.3-RELEASEのものを使用しました。つまり、修正を10.3-RELEASEに対して行ったわけですが、これは、私のUltra30はこのWebページの作成をはじめ、実運用に使用しているため、テスト環境として12.0-CURRENTを用意できなかったためです。

しかし、カーネルソースコードの修正はまずCURRENTに適用されます。このため、本来send PRする際のパッチはCURRENTに対するものにすべきです。

send PRして3週間ほどで12.0-CURRENT にパッチが取り込まれました(r317578)。その後、2週間ほどで11.0-STABLE(r318272)および10.3-STABLE(r318273)にも取り込ま(MFCさ)れました。

対応していただいたコミッターMariusさんにはたいへん感謝しています。

修正直後の20170510版CURRENT(r318137)、および、20170602版11.1-PRERELEASE(r318893)、10.3-STABLE(r318886)のインストールCDで問題が修正されていることを確認しました。

その後、11.1-RELEASEのインストールCDで、また、10.3-RELEASEを11.1-RELEASEにバージョンアップして問題なく動作することを確認しました。さらにその後、10.4-RELEASEのインストールCDでも確認しました。


Ultra30の構成変更(2018.10.15)

現在のUltra30の構成は下記の通りです。

メモリーを2GBに増強しました。

HBAはUltra320 SCSIのものを3枚追加しました。1枚は66MHz PCIスロットに残りの2枚は33MHz PCIスロットにさしています。ZFS mirrorを組んだUltra320 HDD 2台を66MHz PCIスロットにさしたHBAに接続しています。

なお、Ultra30の内蔵HDDベイはSCAで内蔵HBA直結のため、このベイをUltra320 HDD用には使用できません。このため、外付けHDDケースにUltra320 HDDを搭載しています。

Ultra320 HDDは3台ありますが、このうち2台しか使用していません。もともとは合計4台のUltra320 HDDを搭載しており、通常使用するZFS mirror以外にもう1セットRAID mirrorを作成する予定でした。しかし、1台が故障してしまい、1台が宙に浮いています。

現在、以前使用していた内蔵SCA SCSI HDDは使用していません。

光学ドライブは、ATA-Ultra Wide SCSI変換アダプターを介して、ATAPI DVDマルチドライブをUltra320 SCSI HBAに接続しています。

全体的にスペックアップをはかりましたが、体感速度は上がっていません。CPUがボトルネックになっているようです。


同一名称のzpool(2018.10.15)

上述のとおり、新しい環境をUltra320 SCSI HDDに作成しました。その際、あまり深く考えず、新しいzpoolにも古い環境を同一の"zroot"という名称を使用しました。

当然、FreeBSDとしては両者の区別ができません。

このため、インストール時に以下のエラーが発生しました。


# zpool import -o altroot=/mnt zroot
cannot import 'zroot': more than one matching pool
import by numeric ID instead

メッセージのとおり、名称では一意にしぼれないので、IDで指定します。


# zpool import
   pool: zroot
     id: 13658352886394297511
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

	zroot       ONLINE
	  mirror-0  ONLINE
	    da2a    ONLINE
	    da4a    ONLINE

   pool: zroot
     id: 15304101956561618852
  state: ONLINE
 status: The pool was last accessed by another system.
 action: The pool can be imported using its name or numeric identifier and
	the '-f' flag.
   see: http://illumos.org/msg/ZFS-8000-EY
 config:

	zroot       ONLINE
	  mirror-0  ONLINE
	    da0a    ONLINE
	    da1a    ONLINE
# zpool import -o altroot=/mnt 13658352886394297511

zpool importでIDを確認し、そのIDを名称の代わりに使用します。

また、新システムで旧システムのzpoolをマウントしたいときも同様の問題が発生しますので、やはりIDで指定しますが、下記のようにエラーになります。


# zpool import -R /mnt 15304101956561618852
cannot import 'zroot': pool may be in use from other system, it was last accessed by  (hostid: 0x9b1c1734) on Sun Jun  4 15:05:44 2017
use '-f' to import anyway
# zpool import -f -R /mnt 15304101956561618852
cannot import 'zroot': pool already exists

結局、zpoolの名称はつけかえるしかないようです。


# zpool import -f -R /mnt 15304101956561618852 zroot2
# zpool status
  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: resilvered 14.5G in 1h27m with 0 errors on Sun Nov 19 16:03:11 2017
config:

        NAME                           STATE     READ WRITE CKSUM
        zroot                          ONLINE       0     0     0
          mirror-0                     ONLINE       0     0     0
            diskid/DISK-DN63P83004FLa  ONLINE       0     0     0
            diskid/DISK-UP76P4A00L7Pa  ONLINE       0     0     0

errors: No known data errors

  pool: zroot2
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zroot2      ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            da0a    ONLINE       0     0     0
            da1a    ONLINE       0     0     0

errors: No known data errors


Emacsのflavor化対応(2018.10.15)

2018年になって、Emacs-26.1がリリースされたので、バージョンアップを行いました。これまで、emacs-nox11パッケージを使用していましたが、emacsパッケージがflavor化されたため、バージョンアップに少してこずりました。

まずは、editors/emacsでmake FLAVOR=nox installし、configをX11に依存しないように選択したつもりですが、何度configを調整しビルドしてもX11がらみ、というかSPARC64ではビルドできないLLVMを必要とするMesa libEGLが必要なCairoパッケージを作成しようとしてしまいます。

原因は、初めてflavor化したemacsパッケージをビルドした際にflavorの仕組みを理解しておらず、FLAVORS=noxオプションをせずにビルドしてしまっており、そのconfigが残ってしまっていたためでした。

解決策としては、まず、make rmconfigし、その後、make FLAVOR=nox installしました。また、インストール時にすでにインストールされていたemacs-nox11パッケージとコンフリクトとしたため、すでにeditors/emacs-nox11は存在しないので、pkg delete emacs-nox11しました。なお、その際、mewとegg4パッケージがあわせて削除されました。その後、再度make FLAVOR=nox installしました。


Fire V445 11.2インストール(2018.11.3)

Sun Fire V445にFreeBSD-11.2をインストールしてみました。

インストールしたマシンのスペックは下記の通りです。

今回もシリアルコンソールを使用しました。

インストールCDから起動すると下記のところでハングアップします。


(省略)
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
cd0 at ata2 bus 0 scbus2 target 0 lun 0
Trying to mount root from cd9660:/dev/iso9660/11_2_RELEASE_SPARC64_CD [ro]...
cd0:  Removable CD-ROM SCSI device
cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes)
cd0: 514MB (263670 2048 byte sectors)
da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-2 SCSI device
da0: Serial Number 000736S0DRHP
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 70007MB (143374738 512 byte sectors)
uhub3: 8 ports with 8 removable, self powered
ugen3.2:  at usbus3
uhub4 on uhub3
uhub4:  on usbus3
uhub4: MTT enabled
uhub4: 4 ports with 4 removable, self powered
random: unblocking device.
Starting file sy

最後の行は、他の機器のログから、下記行の途中までが表示されているようです。


Starting file system checks:

なお、NetBSD-8.0およびOpenBSD-6.4は問題なくインストールできました。


Fire V445システムコントローラーバッテリー(2018.11.3)

Sun Fire V445ではNVRAMは使用されておらず、IDPROMとバッテリーは分離したコンポーネントになっています。

IDPROMとバッテリーはいずれもシステムコントローラーボード上にあり、簡単に交換できます。バッテリーはCR1225が使用されています。BR1225も使用できました。

システムコントローラーボードのバッテリーが切れていると、以下のメッセージを表示し、ALOMが再起動を繰り返します。


SC Alert: SC initiating soft host system shutdown due to fault at SC.BAT.V_BAT.

SC Alert: SC Request to Power Off Host.

SC Alert: VOLTAGE_SENSOR @ SC.BAT.V_BAT has exceeded low soft shutdown threshold.


USBデバイスサーバーによるシリアルコンソールのLAN接続(2018.11.5)

Sunの機器への接続はシリアルコンソールを使用しています。始めのうちはシリアルケーブルを伸ばしてPCとつないでいましたが、煩わしくなったのでシリアルコンソールのLAN化を検討しました。

思い付く範囲で、以下の2つの方法がありました。

コンソールサーバーの方が専用に作られていて扱い勝手がよいとは思いましたが、機材が高価で、また、一箇所にまとめてではなく複数場所に機器を置く環境ではあまりマッチしないと考えました。

USBデバイスサーバーでUSB-シリアル変換ケーブルを共有するには、USBデバイスサーバーがUSB-シリアル変換ケーブルをサポートしている必要がありますが、おおよそFTDIProlificの2社寡占のUSB-シリアル変換チップなので心配する必要はないかと考えました。

また、調べていくうちにUSBデバイスサーバーの仕組みはsilexのものが業界標準だとわかりました。たとえば、アイ・オー・データ機器net.USBもそのひとつです。私は試していませんが、他にも、組み込み機器用やバッファローにも該当製品があるようです。

残念ながら、USBデバイスサーバーのはやりはすでに終わっていて、新製品は本家のsilexからしか発売されていません。しかしその分、中古市場にはsilex互換のUSBデバイスサーバーが安価で出回っています。

私はアイ・オー・データ機器のETG-DS/US-HSを使用しています。

USB-シリアル変換ケーブルは以下の3本を使用しています。これらはいずれもFTDIのUSB-シリアル変換チップを積んだ製品です。

USBデバイスサーバーに接続したUSB機器を使用するには、接続元の機器にユーティリティソフトウェアをインストールして、このソフトウェアでUSB機器を予約する必要があります。アイ・オー・データ機器からもnet.USBクライアントというユーティリティが提供されていますが、私は本家silexのSX Virtual Linkを使用しています。

なお、SX Virtual LinkはUSBデバイスサーバー上のUSB機器をあたかもローカルにあるかのようにみせかけるソフトウェアなので、使用したいUSB機器のデバイスドライバーはあらかじめ別途インストールしておく必要があります。これまで、USBポートに直接接続して使用していた機器であればすでにデバイスドライバーはインストール済みだと思うので、改めてのインストールは不要です。新たにインストールする場合、FTDIは積極的にデバイスドライバーの更新を行っているので、デバイスドライバーはFTDIのサイトからダウンロードしたものを使います。その際、Windowsではsetup executableを使うと便利です。また、私の環境の問題かもしれませんが、MacOSではデバイスドライバーのインストール後にOSの再起動を行う必要がありました。

SX Virtual Linkを起動すると、USBデバイスサーバーとそれに接続されたUSB機器のリストが表示されます。Windowsではリストの取得がうまくいかないことが何度かあり、その場合、「オプション」の「デバイスサーバ検索」で「ブロードキャストアドレスを有効にする」をチェックした上で、ブロードキャストアドレスを「追加」するとリストに表示されました。

なお、SX Virtual Linkのデフォルトの設定では、ウィンドウの閉じるボタンを押すと、終了してしまいます。これを避けるには「オプション」の「全般」で「閉じるボタンでメイン画面を隠す」をチェックします。

SX Virtual LinkでETG-DS/US-HSは「ETG-DSUSmmmmmm [MM:MM:MM:mm:mm:mm ETG-DS/US-HS]」と表示されます。ここで、MはMACアドレスの上位3オクテット、mは下位3オクテットです。また、私が使用したUSB-シリアル変換ケーブルは3本とも「FTDI USB HS SERIAL CONVERTER」と表示されました。表示される位置は固定のため、何番目が〜につながっているやつ、という感じで場所を記憶しています。

私の使用しているUSB-シリアル変換ケーブルのシリアル端子の形状はいずれもDB9オスです。これは、通常PC本体に装備されるのと同じ形です。

Ultra30に接続する場合、Ultra30側のシリアル端子がDB25メスのため、Ultra30側にDB25メス-DB9オス変換アダプターを使用し、DB9クロスケーブルで接続します。

また、Fire V245やV445に接続する場合、シリアル端子がRJ45のため、USB-シリアル変換ケーブル側にDB9メス-RJ45変換アダプターを使用し、UTPストレートケーブルで接続します。UTPストレートケーブルを使用する代わりに、CiscoのDB9メス-RJ45変換アダプターとロールオーバーケーブルの組み合わせ、または、DB9-RJ45ケーブル(CAB-CONSOLE-RJ45)を使用することもできます。

UTPストレートケーブルを使用するには、DB9メス-RJ45変換アダプターの半キットを利用するのが便利です。私は以下の製品を使用して、変換アダプターを作成しました。いずれも、RJ45側はあらかじめケーブルが接続されており、DB9側のピンを任意の位置にさして完成させる形になっています。

DB9-RJ45変換アダプターの結線は下記のとおりです。DB9側にピンをさす際には、コネクターの表と裏を意識してピン番号を確認してください。

DB9 RJ45
1 4
2 茶または灰 7
3 6
4 3
5 (空) N/A
6 (空) N/A
7 1
8 8
9 2
N/A 5(空)

disk IDラベル名に自動的に変更される(2018.11.10)

HDDのデバイス名として、デバイスファイル名を使ってインストールしても、運用しているとあるタイミングでdisk IDラベル形式の名称に自動で変わってしまうことがあります。

私の場合、HDDを接続するバスをつなぎ変えた場合に発生しました。

HDDの接続変更前は下記の状態でした。


# zpool status
  pool: zroot
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            da2a    ONLINE       0     0     0
            da4a    ONLINE       0     0     0

errors: No known data errors

このときのbootログは下記のとおりでした。


da0 at sym0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: Serial Number B8DL3GJM
da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit)
da0: Command Queueing enabled
da0: 140014MB (286749480 512 byte sectors: 255H 63S/T 17849C)
da1 at sym0 bus 0 scbus0 target 1 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: Serial Number B8DL38YM
da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit)
da1: Command Queueing enabled
da1: 140014MB (286749480 512 byte sectors: 255H 63S/T 17849C)
da2 at mpt4 bus 0 scbus5 target 0 lun 0
da2:  Fixed Direct Access SCSI-3 device
da2: Serial Number 3HY6X8GA0000743962GK
da2: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da2: Command Queueing enabled
da2: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C)
da4 at mpt5 bus 0 scbus6 target 0 lun 0
da4:  Fixed Direct Access SCSI-3 device
da4: Serial Number DN63P83004FL
da4: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da4: Command Queueing enabled
da4: 140014MB (286749480 512 byte sectors: 255H 63S/T 17849C)
da3 at mpt4 bus 0 scbus5 target 1 lun 0
da3:  Fixed Direct Access SCSI-3 device
da3: Serial Number 3KQ0TLTT00007603KZCK
da3: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da3: Command Queueing enabled
da3: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C)
da5 at mpt5 bus 0 scbus6 target 1 lun 0
da5:  Fixed Direct Access SCSI-3 device
da5: Serial Number 3KQ0TP7R00007603LF5Y
da5: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da5: Command Queueing enabled
da5: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C)

HDDの接続変更後は下記の状態になりました。


# zpool status
  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: none requested
config:

        NAME                                   STATE     READ WRITE CKSUM
        zroot                                  ONLINE       0     0     0
          mirror-0                             ONLINE       0     0     0
            diskid/DISK-3HY6X8GA0000743962GKa  ONLINE       0     0     0
            diskid/DISK-DN63P83004FLa          ONLINE       0     0     0

errors: No known data errors

このときのbootログは下記のとおりです。接続変更前と比較して、デバイス名が付け変わってしまっています。


da0 at sym0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: Serial Number B8DL3GJM
da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit)
da0: Command Queueing enabled
da0: 140014MB (286749480 512 byte sectors)
(da1:sym0:0:1:0): UNMAPPED
da1 at sym0 bus 0 scbus0 target 1 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: Serial Number B8DL38YM
da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit)
da1: Command Queueing enabled
da1: 140014MB (286749480 512 byte sectors)
(da2:mpt1:0:0:0): UNMAPPED
(da3:da2 at mpt1 bus 0 scbus2 target 0 lun 0
da2:  Fixed Direct Access SCSI-3 device
da2: Serial Number DN63P83004FL
da2: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da2: Command Queueing enabled
da2: 140014MB (286749480 512 byte sectors)
mpt1:0:1:0): UNMAPPED
(da4:mpt4:0:da3 at mpt1 bus 0 scbus2 target 1 lun 0
da3:  Fixed Direct Access SCSI-3 device
da3: Serial Number 3KQ0TP7R00007603LF5Y
da3: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da3: Command Queueing enabled
da3: 35003MB (71687372 512 byte sectors)
0:0): UNMAPPED
(da5:mpt4:0:1:0): UNMAPPED
da4 at mpt4 bus 0 scbus5 target 0 lun 0
da4:  Fixed Direct Access SCSI-3 device
da4: Serial Number 3HY6X8GA0000743962GK
da4: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da4: Command Queueing enabled
da4: 140014MB (286749488 512 byte sectors)
da5 at mpt4 bus 0 scbus5 target 1 lun 0
da5:  Fixed Direct Access SCSI-3 device
da5: Serial Number 3KQ0TLTT00007603KZCK
da5: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da5: Command Queueing enabled
da5: 35003MB (71687372 512 byte sectors)

disk ID形式のラベルは、HDDのシリアルナンバーを使用しているようです。

デバイス名とdisk IDラベルのマッピングはglabel listで確認できます。


# glabel list
Geom name: da0
Providers:
1. Name: diskid/DISK-B8DL3GJM
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 286749480
   length: 146815733760
   index: 0
Consumers:
1. Name: da0
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r0w0e0

Geom name: da1
Providers:
1. Name: diskid/DISK-B8DL38YM
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 286749480
   length: 146815733760
   index: 0
Consumers:
1. Name: da1
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r0w0e0

Geom name: da2
Providers:
1. Name: diskid/DISK-UP76P4A00L7P
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r2w2e3
   secoffset: 0
   offset: 0
   seclength: 286749480
   length: 146815733760
   index: 0
Consumers:
1. Name: da2
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r2w2e4

Geom name: da3
Providers:
1. Name: diskid/DISK-DN63P83004FL
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r2w2e3
   secoffset: 0
   offset: 0
   seclength: 286749480
   length: 146815733760
   index: 0
Consumers:
1. Name: da3
   Mediasize: 146815733760 (137G)
   Sectorsize: 512
   Mode: r2w2e4

Geom name: da4
Providers:
1. Name: diskid/DISK-3KQ0TP7R00007603LF5Y
   Mediasize: 36703934464 (34G)
   Sectorsize: 512
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 71687372
   length: 36703934464
   index: 0
Consumers:
1. Name: da4
   Mediasize: 36703934464 (34G)
   Sectorsize: 512
   Mode: r0w0e0



Fire V445 12.0インストール(2018.12.25)

Sun Fire V445にFreeBSD-12.0をインストールしてみました。

インストールCDから起動すると11.2同様、下記のところでハングアップします。


(省略)
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
cd0 at ata2 bus 0 scbus2 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes)
cd0: 573MB (293590 2048 byte sectors)
arc4random: no preloaded entropy cache
da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-2 SCSI device
da0: Serial Number 000736S0DRHP
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 70007MB (143374738 512 byte sectors)
Trying to mount root from cd9660:/dev/iso9660/12_0_RELEASE_SPARC64_CD [ro]...
GEOM: da0: adding VTOC8 information.
GEOM: diskid/DISK-000736S0DRHP: adding VTOC8 information.
uhub3: 8 ports with 8 removable, self powered
random: unblocking device.
arc4random: no preloaded entropy cache
ugen3.2:  at usbus3
uhub4 on uhub3
uhub4:  on usbus3
uhub4: MTT enabled
uhub4: 4 ports with 4 removable, self powered
arc4random: no preloaded entropy cache
Starting file sylo0: link state changed to UP


Fire V245 12.0インストール(2018.12.25)

Sun Fire V245にFreeBSD-12.0をインストールした際の顛末です。

インストールしたマシンのスペックは下記の通りです。

今回もシリアルコンソールを使用しました。

HDDを4台内蔵しているため、ZFSでRAIDZ1を組むことにしました。インストール手順は、Ultra30同様、Installing FreeBSD 9.x Root on ZFS using VTOC8 (sparc)にほぼしたがいました。具体的には下記の通りです。

  1. OBPでboot cdrom
  2. そのままインストーラーにそって進める
  3. PartitioningメニューでShellを選択
    
    # sysctl kern.disks
    kern.disks: cd0 da3 da2 da1 da0
    # 
    # zpool labelclear -f da0a
    ZFS filesystem version: 5
    ZFS storage pool version: features support (5000)
    # zpool labelclear -f da1a
    # zpool labelclear -f da2a
    # zpool labelclear -f da3a
    # 
    # gpart destroy -F da0
    da0 destroyed
    # gpart destroy -F da1
    da1 destroyed
    # gpart destroy -F da2
    da2 destroyed
    # gpart destroy -F da3
    da3 destroyed
    # 
    # gpart create -s VTOC8 da0
    da0 created
    # gpart create -s VTOC8 da1
    da1 created
    # gpart create -s VTOC8 da2
    da2 created
    # gpart create -s VTOC8 da3
    da3 created
    # 
    # gpart add -s 270G -t freebsd-zfs da0
    da0a added
    # gpart add -s 270G -t freebsd-zfs da1
    da1a added
    # gpart add -s 270G -t freebsd-zfs da2
    da2a added
    # gpart add -s 270G -t freebsd-zfs da3
    da3a added
    # gpart add -t freebsd-swap da0
    da0b added
    # gpart add -t freebsd-swap da1
    da1b added
    # gpart add -t freebsd-swap da2
    da2b added
    # gpart add -t freebsd-swap da3
    da3b added
    # 
    # zpool create -o altroot=/mnt -O canmount=off zroot raidz1 da0a da1a da2a da3a
    # 
    # zpool export zroot
    # 
    # gpart bootcode -p /boot/zfsboot da0
    partcode written to da0
    # gpart bootcode -p /boot/zfsboot da1
    partcode written to da1
    # gpart bootcode -p /boot/zfsboot da2
    partcode written to da2
    # gpart bootcode -p /boot/zfsboot da3
    partcode written to da3
    # 
    # sysctl kern.geom.debugflags=0x10
    kern.geom.debugflags: 0 -> 16
    # 
    # dd if=/boot/zfsloader of=/dev/da0a bs=512 oseek=1024 conv=notrunc,sync
    551+1 records in
    552+0 records out
    282624 bytes transferred in 5.881700 secs (48051 bytes/sec)
    # dd if=/boot/zfsloader of=/dev/da1a bs=512 oseek=1024 conv=notrunc,sync
    551+1 records in
    552+0 records out
    282624 bytes transferred in 3.350490 secs (84353 bytes/sec)
    # dd if=/boot/zfsloader of=/dev/da2a bs=512 oseek=1024 conv=notrunc,sync
    551+1 records in
    552+0 records out
    282624 bytes transferred in 3.334079 secs (84768 bytes/sec)
    # dd if=/boot/zfsloader of=/dev/da3a bs=512 oseek=1024 conv=notrunc,sync
    551+1 records in
    552+0 records out
    282624 bytes transferred in 3.345863 secs (84470 bytes/sec)
    # 
    # zpool import -o altroot=/mnt zroot
    # 
    # zfs set checksum=fletcher4                                   zroot
    # zfs set atime=off                                            zroot
    # 
    # zfs create -o mountpoint=/                                   zroot/ROOT
    # 
    # zpool set bootfs=zroot/ROOT zroot
    # 
    # cat << EOF > /tmp/bsdinstall_etc/fstab
    # Device        Mountpoint      FStype  Options Dump    Pass#
    /dev/da0b       none            swap    sw      0       0
    /dev/da1b       none            swap    sw      0       0
    /dev/da2b       none            swap    sw      0       0
    /dev/da3b       none            swap    sw      0       0
    EOF
    # exit
    
    

    Wikiとの差異は以下の点です。

  4. 引き続き、インストーラーにしたがい、インストールを続行
  5. Manual ConfigurationメニューでYesを選択
    
    # echo 'zfs_enable="YES"' >> /etc/rc.conf
    # 
    # zpool set cachefile=/boot/zfs/zpool.cache   zroot
    internal error: failed to initialize ZFS library
    # 
    # exit
    
    

    Wikiとの差異は以下の点です。

最後のコマンドの失敗との関連が気になりますが、HDDから起動ができませんでした。

disk(0)とdisk1からの起動時は下記のようになります。


{1} ok boot disk
Boot device: /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@0,0  File and args: 
 
>> FreeBSD/sparc64 ZFS boot block
   Boot path:   /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@0,0:a
Consoles: Open Firmware console  
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ZFS: i/o error - all block copies unavailable
ZFS: failed to read pool zroot directory object
ZFS: can't find pool by guid

FreeBSD/sparc64 bootstrap loader, Revision 1.0
bootpath=""

can't load 'kernel'

Type '?' for a list of commands, 'help' for more detailed help.
OK 

disk2とdisk3からの起動時は下記のようになります。


{1} ok boot disk2
Boot device: /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@2,0  File and args: 
 
>> FreeBSD/sparc64 ZFS boot block
   Boot path:   /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@2,0:a
Consoles: Open Firmware console  
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ZFS: i/o error - all block copies unavailable
ZFS: failed to read pool zroot directory object

FreeBSD/sparc64 bootstrap loader, Revision 1.0
bootpath="/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@2,0:a"
|/-\|/-\
|/-\|/-\|/-\|/-\|/-\|/-\can't load 'kernel'

Type '?' for a list of commands, 'help' for more detailed help.
OK 


Ultra30のNVRAM交換(2019.4.23)

Ultra30を長く使用するとさけて通れない、NVRAMの話です。

私の所有するUltra30はNVRAMの電池切れのため、すでに1度NVRAMの交換をしていますが、再度電池切れになったため、対応が必要になりました。あまり工作はしたくなかったので、前回同様、新しいNVRAMを入手して、交換しようと考えました。

前回は、NVRAMを若松通商の旧店舗で入手したのですが、Webサイトで事前調査したところNVRAMを扱っているか分からなかったのと、購入できるにしても前回実績から6,000円程度かかると思われたので、eBayで入手することにしました。

Sun UltraシリーズのNVRAMは、STMicroelectronics M48T59Y-70PC1です。eBayには安価なものから数千円台のものまでありましたので、異なるsellerからほぼ最安値の300円台のものを3個購入しました。

しかし、Ultra30にさしてみると、残念ながら3つともlow batteryで使用できませんでした。それなりの値段のものを購入すれば違ったかも知れませんが、このままでは交換してもしかたないので、当初の予定を変更して、手持ちのNVRAMの工作を行うことにしました。

工作方針としては、NVRAMの電極を露出させ、NVRAMの上に載せたボタン型電池から給電するようにします。このため、下記の物品を秋月電子通商で購入しました。

カバー付きの電池ケースを選択したのは、絶縁に有利と考えたからです。配線は今後も利用できると思い、10色のものを選びました。

この他に、はんだと電池ケースをNVRAMは固定するためのエポキシ接着剤を入手しました。

作業は、まず、カッターで14/15ピン側(NVRAM上面の文字を読めるように置いた際の右側)の側面を削ること合計1時間半、内部の電池の配線とNVRAMの電極2つを露出させました。けっこう力が必要だったので、20分削っては休憩という感じで進めました。電極の作業を楽に進めるため、なるべく深く掘ったほうがよいです。

ちなみに、もともとささっていた電池切れしたNVRAMと新規に購入したNVRAMの電池の電圧をはかったところ、すべて0Vでした。

次に、内部の電池から電極に伸びている配線を外します。電極をきれいに露出させておけば、電極にはんだごてをあてると簡単にはずれます。なお、はんだごてでなくても、カッターを電池の配線の隙間に差し込んで少し力を入れてもはずせます。はずした配線は再度電極にふれないようにはねておきます。切断しても問題ないと思います。

このあとは、電池ケースから電極に配線をします。2つポイントがあります。1つめはNVRAMがソケットのケースのようなものに載っているため、電極の位置がソケットに埋まってしまいます。このため、電極に配線をはんだづけする際には、配線を少し上向きにすることです。もう1つは、Ultra30のシステムボード上のNVRAMの搭載位置のすぐ下にケースのフレームがあり、下方向にあまりスペースがないことです。NVRAMは(1番ピンを左側として)横向きにさしますが、下方向に余裕がないことから、電池ケースを下側にあまりはみ出すことができません。今回使用する電池ケースは端子をNVRAMの電極の配置と平行にそろえると、上下に端子がきますが、NVRAMの中央に設置すると下側の端子がフレームに干渉します。このため、NVRAM上に電池ケースを固定する場合は、電池ケースの添付位置を少し上よりにずらすか、電池ケースの端子をNVRAMの電極とは90°回転させた方向で添付する必要があります。私は、電池ケースを90°回転させました。

配線のはんだづけははんだがうまくのれば簡単だと思います。電極は14ピン側がプラス、15ピン側がマイナスです。電池ケースはエポキシ接着剤でNVRAMの上面にはりつけました。

電池ケースに電池を装着するには、電池をカバーにのせてから、ケース側に取り付けると簡単です。なお、電池は、上がプラス、下がマイナスです。

あとは、電池ケース付きNVRAMをUltra30に取り付けます。NVRAMを削るのに力をかけていると思いますので、ピンが曲がっていることがあります。まっすぐに直してから、ソケットケースに入れてシステムボード上のソケットに挿入します。ソケットケースがあるため、それほど深くはささりません。

電源を投入すると長いdiagが走ります。しばらく待つと、OBPで止まるので、NVRAMの設定を行います。


ok set-defaults
Setting NVRAM parameters to default values.
ok setenv diag-switch? false
diag-switch? =        false
ok 01 0 mkp
ok 80 1 mkp
ok 08 2 mkp
ok 00 3 mkp
ok 20 4 mkp
ok aa 5 mkp
ok bb 6 mkp
ok cc 7 mkp
ok 00 8 mkp
ok 00 9 mkp
ok 00 a mkp
ok 00 b mkp
ok ll c mkp
ok mm d mkp
ok nn e mkp
ok 0 f 0 do i idprom@ xor loop f mkp
ok .idprom
Format/Type: 1 80 Ethernet: 8 0 20 aa bb cc Date: 0 0 0 0 
Serial: ll mm nn Checksum: XX 
ok 

ここで、aa〜cc、ll〜nn、そして、XXは下記の通りです。

aa
MACアドレスの4オクテット目
bb
MACアドレスの5オクテット目
cc
MACアドレスの6オクテット目
ll
ホストIDの1バイト目
mm
ホストIDの2バイト目
nn
ホストIDの3バイト目
XX
OBPによって計算されたチェックサム

このあと、必要であれば、他の環境変数も設定します。(printenvで確認。)

念のため、設定が反映されたか確認します。


ok reset-all
Resetting ... 


Sun Ultra 30 UPA/PCI (UltraSPARC-II 296MHz), No Keyboard
OpenBoot 3.27, 2048 MB memory installed, Serial #xxxxxxx.
Ethernet address 8:0:20:aa:bb:cc, Host ID: 80llmmnn.

(省略)

次に、OSを起動して、日付時刻を設定します。

電源を落として、しばらくたってから、再度起動し、NVRAMの設定が保持されていれば、問題ありません。作業完了です。


Fire V445 12.1インストール(2019.11.8)

Sun Fire V445にFreeBSD-12.1をインストールしてみました。

インストールCDから起動すると12.0同様、下記のところでハングアップします。


(省略)
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
cd0 at ata2 bus 0 scbus2 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes)
cd0: 581MB (297910 2048 byte sectors)
arc4random: no preloaded entropy cache
da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-2 SCSI device
da0: Serial Number 000736S0DRHP
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 70007MB (143374738 512 byte sectors)
Trying to mount root from cd9660:/dev/iso9660/12_1_RELEASE_SPARC64_CD [ro]...
GEOM: da0: adding VTOC8 information.
GEOM: diskid/DISK-000736S0DRHP: adding VTOC8 information.
uhub3: 8 ports with 8 removable, self powered
ugen3.2:  at usbus3
uhub4 on uhub3
uhub4:  on usbus3
uhub4: MTT enabled
uhub4: 4 ports with 4 removable, self powered
random: unblocking device.
arc4random: no preloaded entropy cache
arc4random: no preloaded entropy cache
Starting file sylo0: link state changed to UP


OSの話題(新)のページ