Toshiba Canvio Basics 3TB を購入2018年04月06日 13時36分07秒

Canvio Plus 750GB が故障したので、交換用に Toshiba Canvio Basics 3TB を購入。

故障した日に値段を調べたら、3TB で 80 ドル。4TB で 100 ドルで売っていた。探していたのはポータブル型。4TB の方がバイトあたりの単価が安い。深夜遅くなったので、次の日に注文することにした。

その次の日に何と、丁度見ていた 3TB の外付けディスクが日替わりセールになっていて、70 ドルに。昨日は 4TB は大きすぎて迷っていたので、そちらに決めた。そして注文したのが週末。それが数日前の夜に届いていた。

早速 FreeBSD 11.1-RELEASE に繋いでみる。dmesg はこうなった。

da1 at umass-sim1 bus 1 scbus4 target 0 lun 0
da1:  Fixed Direct Access SPC-4 SCSI device
da1: Serial Number 20180127xxxxxxF
da1: 40.000MB/s transfers
da1: 2861588MB (5860533164 512 byte sectors)
da1: quirks=0x2
シリアルナンバーは日付を使っている様だ。USB3 だが、古いHP Pavilion dv6425us と同じ時期に買った HP Pavilion dv6426us なので、ホスト側はスピードは出ないのは折り込み済み。

前回。

Canvio Plus 750GB の FreeBSD ufs をまず復旧2018年04月02日 13時22分29秒

東芝の Canvio Plus 750GB External USB 2.0 Portable Hard Drive が誤動作を起こし始めた。新しいディスクは注文した。fsck の直せない ufs の復旧が第一の課題。

このディスクは ufs と zfs で使っている。zfs は raid-z の一部。こちらには大量の写真や家族の動画が入っている。これは、新しいハードディスクを購入してから、zpool replace で交換する必要があるので、こちらの復旧作業は後回し。

この ufs はホームディレクトリとして利用している一番重要なデータ。こちらは、時おり ufs_copy でディスクをファイルシステム毎バックアップしている。ディスクは何度も移り変わっているが、既に十年、十五年以上前に作ったファイルシステムなので、29GB のみ。作成当時はディスク一台で、全てのファイルが入っていたが、既に写真などの大容量は別途保管して、それこそ日頃のメールやブラウザの履歴などが入っている。zfs のバックアップに週に一度ぐらい気の向いたときにバックアップを取っている。

別の zfs には二、三日前に取ったホームディレクトリのバックアップはある。ただ、税金申告の期限が迫っているので、あれこれ更新していたものがあるので、出来れば故障したディスクから復旧したい。手元を漁ると I-O DATA の HDPS-U に 30GB のスペースがすぐに融通できるのでそれを使う事にした。これは、実家に帰っていた時に、写真が入りきらなくなった時に、譲り受けた機械。父の手書きで、2009 年と日付が書いてある。

ディスクの復旧は recoverdisk。dd よりも優れている。recover_disk はファイルブロックサイズを大きめで始める。エラーがあるとエラー箇所を一度飛ばし、そのままコピーを終端まで終らせる。その後で、ブロックサイズを小さくして、エラーのあった箇所を再試行する。-w オプションを付けると、経過とエラー箇所をファイルに書き出す。

$ recoverdisk -w home.err /dev/label/home.eli /dev/da0s2
最終的に読めなかったブロックは六つぐらい。fsck が先に進めないので、このブロックはシステム情報が管理されているのだろう。その後、壊れたディスクを読み出しのみの mount -r でマウントを試みた。
$ mount -r /dev/label/home.eli /home
これでもマウント出来ない。

このファイルシステムは完全に壊れてしまった様だ。直せないのなら、更に壊しても、新たに失うものは無いので、強制復旧を試みる。そして、ufs のメタデータだったとの推測から、古いディスクイメージからこの故障セクタのみを写すという荒技を試すことにした。

$ mdconfig -a -t vnode -f /mnt/backup/20180301/home.ufs -oreadonly
md1
$ recoverdisk -r home.err /dev/md1 /dev/da0s2
$ fsck_ufs -y /dev/da0s2
$ fsck_ufs -y /dev/da0s2
$ mount -r /dev/da0s2 /home
mdconfig で古いディスクイメージを読み出しのみで設定する。ファイルのままでも処理できるが、間違えた時にダメージを回避するため md デバイスを利用。さっきの recoverdisk に home.err を渡して、破損セクタだけをコピーする。fsck を動かしたら、ファイルシステムを修正したので、再度 fsck を行うように指示された。

この後、mount は成功し、zfs のバックアップを元に復旧度合を確かめた。特にファイルの損失もなく、こちらの方が新しいので、ディスクからの普及には成功したとの結論に至った。

前回次回

東芝の Canvio Plus 750GB が故障した2018年04月01日 14時36分11秒

東芝の Canvio Plus 750GB External USB 2.0 Portable Hard Drive が故障直前の様だ。いきなり FreeBSD が panic を起こした。 fsck を試すと、読めないセクタがある。

東芝の Canvio Connect II を購入したのは 2016年02月18日 となっている。これよりも大分前から使っていたが、購入した時期はまったく覚えていない。私の両親は、電器製品には必ずと言って程購入日を本体に書き込んでいた。子供の頃はなぜそんな事をするのか不思議だったのを思い出した。

現状では、この外付けディスクを繋ぐだけで、cam のエラーが連発する。そのまま五分ぐらいでも放置しておくと安定してくるようで、一旦cam エラーは止まる。

このディスクには ufs と zfs が納められている。fsck がファイルシステムの復旧を出来ないので、ufs は致命的な損傷を受けている模様。zfs は raid-z の一部なのだが、今のところは zfs を壊さないように、ファイルシステムは外してある。

ufs は実は私のホームディレクトリ。取り敢えず、この ufs の復旧は急を要す。また、写真なども多いので、新しい外付けのディスクは注文した。

次回

bhyve に必要なデバイス2018年01月11日 13時38分51秒

GENERIC カーネルでは既に有効になっているが、カーネルを作り直している場合には、virtio や vtnet 等のデバイスが有効になっていないとブートローダが第三ステージに移行できなかったり、ネットワークが使えなくなる。

仮想デバイスに以下の物がある。

device          virtio          # Generic VirtIO bus (required)
device          virtio_pci      # VirtIO PCI Interface
device          vtnet           # VirtIO Ethernet device
device          virtio_blk      # VirtIO Block device
device          virtio_scsi     # VirtIO SCSI device
device          virtio_balloon  # VirtIO Memory Balloon device
device          virtio_random   # VirtIO Entropy device
device          virtio_console  # VirtIO Console device
手元では、virtio と cirtio_pci と virtio_blk を有効にして起動でき、vtnet を追加して、ネットワークが使えるようになった。

FreeBSD の bhyve の環境で新規環境を四つのコマンドで最短起動2018年01月09日 11時57分31秒

bhyve は FreeBSD のハイパーバイザ型の仮想環境。FreeBSD のサイトの FreeBSD as a Host with bhyve や他にも新規の試し方などは載っている。

実は、bhyve はディスクイメージそのままを使っているので、配布されている VM イメージがそのまま利用できる。vmm カーネルモジュールを読み込み、fetch でイメージを取って、xz -d で展開し、そのまま起動できる。

bhyve-host$ kldload vmm
bhyve-host# fetch https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-RELEASE/i386/Latest/FreeBSD-11.1-RELEASE-i386.raw.xz
FreeBSD-11.1-RELEASE-i386.raw.xz              100% of  212 MB 1826 kBps 02m00s
bhyve-host# xz -d FreeBSD-11.1-RELEASE-i386.raw.xz
bhyve-host# sh /usr/share/examples/bhyve/vmrun.sh -d FreeBSD-11.1-RELEASE-i386.raw FreeBSD-11.1
Launching virtual machine "FreeBSD-11.1" ...
Consoles: userboot

FreeBSD/amd64 User boot, Revision 1.1
(Tue Jan 16 20:53:23 EST 2018 hiro@rv515.advok.com)
Loading /boot/defaults/loader.conf
...
/boot/kernel/kernel text=0x127d5b5 data=0xe42bc+0x284034 syms=[0x4+0xe6250+0x4+0x173393]
Booting...
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017
    root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): text 80x25
CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1646.25-MHz 686-class CPU)
  Origin="AuthenticAMD"  Id=0x500f20  Family=0x14  Model=0x2  Stepping=0
  Features=0x1783fbff
  Features2=0x80802201
  AMD Features=0x26500800
  AMD Features2=0x31fb
  TSC: P-state invariant
Hypervisor: Origin = "bhyve bhyve "
...



Starting background file system checks in 60 seconds.

Sat Jan 20 00:05:52 UTC 2018

FreeBSD/i386 (Amnesiac) (ttyu0)

login: root
Jan 07 16:05:58  login: ROOT LOGIN (root) ON ttyu0
FreeBSD 11.1-RELEASE (GENERIC) #0 r321309: Fri Jul 21 04:10:47 UTC 2017

Welcome to FreeBSD!

...
Edit /etc/motd to change this login announcement.
root@:~ # uname -s -r -m
FreeBSD 11.1-RELEASE i386
起動してログインも完了。

今回は、amd64 機で i386 システムを動かしてみた。ネットワークを使ったりするには tap を設定したりする必要もあるが、今回はそれこそ起動して簡単に使って感触を得るのが目的。

bhyve は特殊なインストラクションを使うので、実機で使えるかを調べる必要がある。AMD だと、Features2 に POPCNT が、Intel のだと Vt-x に EPT と UG が dmesg で確認する必要がある。安くなっていたから四年前に買ったラップトップにもついていたので、ここ数年で購入したコンピュータなら動くと思われる。

FreeBSD で amd64 を i386 システムに上書きインストールした環境2017年11月14日 13時53分07秒

FreeBSD 11.1-STABLE のコードを i386 システム上で amd64 をコンパイルし、i386 システムに上書きインストールしてみた。

カーネルだけ入れ換えた時は、zfs 等の一部のシステムコマンドが使えなかった。今回は、installworld も行い、ユーザランドもしっかりと amd64 のシステムにした。

これにより、zfs 等を始めとするシステムコマンドが置き換えられたために、起動時にいつくか見られていたエラーは全て消えた。

しかし、pkg から入れた Xorg のライブラリがまだ、見付からずに X 関連がまだ起動しない。それ以外は動いているようだが、X が動かないと使えるプログラムがかなり限られてしまう。

最終的に、pkg も pkg update と pkg upgrade をして、全て入れ換えてしまった。pkg は i386 から amd64 に切り替わったのを認識し、upgrade で全てを入れ換えた。この後は、X 関連も全て動いている。

前回

FreeBSD で buildworld のクロスコンパイルとインストール2017年11月09日 13時01分30秒

FreeBSD で amd64 カーネルだけを i386 システムに上書きインストールしたら、zfs 等が使えない。そこで、今度は buildworld と installworld も行った。

クロスコンパイルの buildkernelをやった後に、以下の二つのコマンドを追加して、ユーザランドも入れ換えた。

% make buildworld TARGET=amd64
% su -l
$ make installworld TARGET=amd64 DESTDIR=/mnt/stable -C /usr/src
なお、buildworld の最後に 32bit の互換ライブラリが作られていた。

まとめると、今回までで、最終的にクロスコンパイルとインストールに使ったコマンドは以下の通り。i386 上で amd64 を作りインストールをした。ただ、まだこれが最短手順かの確認は出来ていない。

% make xdev-build TARGET=amd64
% make kernel-toolchain TARGET=amd64
% make buildkernel TARGET=amd64
% make buildworld TARGET=amd64
% su -l
$ make installkernel TARGET=amd64 DESTDIR=/mnt/stable -C /usr/src
$ make installworld TARGET=amd64 DESTDIR=/mnt/stable -C /usr/src

前回次回

FreeBSD で amd64 カーネルを i386 システムにインストール2017年11月07日 13時46分53秒

amd64 のカーネルが作れたので、i386 システムに上書きインストールをしてみる。

FreeBSD 11.1-STABLE の i386 版が母艦。11.1-RELEASE が出た後の、11-STABLE ブランチになる。i386 の機械で amd64 向けのバイナリを作った。これを、複製した i386 システムに入れてみた。

前回の手順

% make xdev-build TARGET=amd64
% make kernel-toolchain TARGET=amd64
% make buildkernel TARGET=amd64
に加えて、/mnt/stable にマウントしてある別のシステムに、インストールをする。root での作業。
$ make installkernel TARGET=amd64 DESTDIR=/mnt/stable

この後再起動してみた。init は問題なく進んだが、幾つか起動に失敗したものがあった。zfs などを筆頭とする、ライブラリとシステムの依存関係の強いシステム系のコマンドは動いていない。X もライブラリだか何かに問題があるらしく、起動しない。

amd64 のカーネルは、i386 の単純なライブラリやコマンドは問題なく動かせるようだ。amd64 のシステムコールとライブラリに依存するコマンドも動かなかった。取り敢えず、amd64 の i386 バイナリ互換は現在もあるようだ。

前回次回

FreeBSD でのクロスコンパイル 事始め2017年10月31日 13時53分52秒

最近、FreeBSD 上のクロスコンパイルに関する文章が少ない。i386 を常用しているが、amd64 限定の機能を試したくて、試行錯誤をしている。自身で、amd64 を i386 上でクロスコンパイルしたのは既に十年以上も前の事だった。

FreeBSD 上でのクロスコンパイルの記述が少ないので、少し見付けたことを順次残しておこうと思う。なお、クロスコンパイルとは動かしている機械とは異ったアーキテクチャのバイナリを作ること。FreeBSD でも長らくサポートされてはいるが、利用頻度は随分と低いようだ。

/usr/src/Makefile が一番の情報源の様だ。make targets でサポートされているアーキテクチャが表示される。

% make targets
Supported TARGET/TARGET_ARCH pairs for world and kernel targets
    amd64/amd64
    arm/arm
    arm/armeb
    arm/armv6
    arm64/aarch64
    i386/i386
    mips/mipsel
    mips/mips
    mips/mips64el
    mips/mips64
    mips/mipsn32
    pc98/i386
    powerpc/powerpc
    powerpc/powerpc64
    sparc64/sparc64
amd64 や sparc64 等のように、TARGET と TARGET_ARCH が一対の場合は、TARGET と TARGET_ARCH のどちらを指定しても補完してくれるようだ。一つのダーゲットであれば、TARGET_ARCH でしっかりと指定するか、TARGET_ARCH と TARGET の両方を指定しておけば、後々の混乱が少ないと思う。

以前は、amd64 を i386 上で構築して、そのままi386 を amd64 に入れ換える事をしている。あの後、そして今でも、結局 64 ビットをサポートしていない機械を使っているので、i386 のままになっている。

前回次回

VirtualBox が サポートしているファイルフォーマット2017年10月24日 12時59分20秒

VirtualBox がサポートしているファイル形式が分かりづらかったので調べてみた。

  1. VHD - マイクロソフトが制定したフォーマット。FreeBSD で配布されているのがこれ。
  2. VDI - VirtualBox の固有のフォーマット。VirtualBox で新しい仮想マシンを作るとこの形式で作成される。ただ、他では使われていないフォーマットの様で、VirtualBox 以外でファイルを扱わなければいけなくなったら大変そう。
  3. VMDK - VMware のフォーマット。FreeBSD でも配布されている。VMWare と共有するのであれば、便利かも。
  4. HDD - Apple Parallels のフォーマット。仕様が公開されていないので、サポートされているのは バージョン 2 まで。
FreeBSD でホストとして使うのなら、VHD か VMDK が良さそう。

前回次回