2021/04/18(日)なんと! FreeBSD 13 から、ソースコード管理が subversion から git へ・・・

2021/04/18 5:47 サーバ運営・管理
2021/04/13 付けで、FreeBSD 13 が公開されました。
今回から、aarch64(arm64) と称されるアーキテクチャが amd64 と同等の Tier 1 に、
最初のTier 1 サポートになった i386 が Tier 2 に変更となっています。時代の変化です。
aarch64 は Raspberry pi に代表される小型のボードが主な対応機器になります。

Tier 1 は、フルサポートが保証されるプラットフォームで amd64 と aarch64 が該当、
Tier 2 は、実使用出来るものの、新機能追加やセキュリティサポートが積極的に行われないバージョンで、最も多くのプラットフォームがこれです。

FreeBSD の Tier ランクは4つあり、Tier 3 が実験的アーキテクチャ(FreeBSD 13 では該当なし)、
Tier 4 は「サポート終了宣言」のアーキテクチャで、現在は、pc98(NEC系の古いパソコン) と sparc64(20年近く前にかなり普及していた、サンマイクロシステムズのワークステーション) が主に該当します。

前置きが長くなりましたが、今回から変更になったものがもう一つ。ソースコードの管理です。。
リリースが近くなってから話には聞いていたものの、『実に厄介だ』というのが第一印象。

いつものように、メンテナンスのためにソースコードからアップデートかけようと、
ソースコード取得を下記のように試みるが・・・
20210418.png

このように「そんなものは無い」と拒絶されます。

今まではOSバージョンアップデート時には、/usr/src と /usr/obj 配下をまっさらにしてから、
# svnlite checkout https://svn.freebsd.org/base/releng/xx.x/ /usr/src
パッチアップデート時には、
# svnlite update
みたいな形で、と直感的なものがあったが、今回からはそれぞれ、
# cd /usr
# git clone -b releng/xx.x ssh://anongit@git.freebsd.org/src.git
# cd /usr/src
# cd /usr
# git pull
# cd /usr/src
とする必要がある。
-b に続く文字列は FreeBSD のリリースブランチ(タグ名とも称す)を示し、
FreeBSD 12.2 だと releng/12.2 FreeBSD 13.0 だと releng/13.0 FreeBSD 13-stable だと stable/13 のようになります。

慣れの問題なのでしょうが、git の第一印象は悪い(当方と同世代なエンジニアは概ね同じ印象を持っている人が案外多い)のもあり、抵抗感がややあります。

git ツールはデフォルトではインストールされていないので、
portsツリーを最新版にしてから、
# cd /usr/ports/devel/git
# make install
# rehash
みたいなコマンドを実行して、git をインストールすることが必要なのです。
ただ、ソースコード取得は subversion よりは高速なようです。

また、今回から、make buildworld , make buildkernel にかかった所要時間が秒数で表示されるようになったようです。
コンパイルにかかる所要時間は、FreeBSD 12 より若干高速になったようです。

2021/04/18(日)FreeBSD におけるディスク追加・変更・パーティション管理

2021/04/18 4:35 サーバ運営・管理
どちらかというと、自分メモ的記事。
今どきの FreeBSD では、HDDなどのストレージデバイス管理に GEOM と呼ばれるフレームワークを採用しています。

昔は、専用のユーティリティツール(FLabel や FDisk ユーティリティ)を使うのが一般的だった記憶があるが、
現在は、GEOM フレームワークの下で gpart というコマンドひとつでも出来るようになっており、
あとからHDDを交換したり、増設やパーティション割り当て変更したい場合は gpart コマンドの方がやりやすい。

後日の参考とするため、手順や注意点などを記述していきます:

注意点) メンテナンス作業対象のHDDやパーティションは mount 状態であってはいけない。
単純なHDD増設なら何も考えることは無いですが、
パーティション変更や交換であれば、mount を外すか、OS起動時に mount されないようにする必要があります。
例えば、ada0 と ada1 の2つのHDDがあって、ada1 を交換またはパーティション変更するのであれば、

# vi /etc/fstab

として、該当ファイルの内容を、

# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0p2     /               ufs     rw      1       1
/dev/ada0p3     none            swap    sw      0       0
/dev/ada0p4     /usr            ufs     rw      2       2
/dev/ada0p5     /tmp            ufs     rw      2       2
# /dev/ada1p1   /home           ufs     rw      2       2
# /dev/ada1p2   /db             ufs     rw      2       2
# /dev/ada1p3   /ftp            ufs     rw      2       2
# /dev/ada1p4   /var            ufs     rw      2       2
のように、該当デバイスに関係する部分全てを、コメントアウト編集しておく必要があります。
もちろん、必要に応じて事前にバックアップしておくことは言うまでもありません。
このあとは、シャットダウンして、機器の電源を落としましょう。

手順1)HDD増設・取り外しの作業を行う
該当HDDを除去するだけなら、HDDを取り外し後、再度電源ON・起動すれば作業完了です。
HDD増設の実作業は、このタイミングで行います。
マザーボードとHDDの結線状態によっては、増設後の起動時にデバイス名の認識順序が変わる場合があるため、要注意です。
通常はマザーボードに振られているコネクタ番号(SATA1,SATA2,SATA3.... といったもの)順にデバイス名が割り当てされていきます。

推奨 )インストールCD・DVDにて shell を起動するのが確実
前述したように、メンテナンス対象のHDDが mount 状態になるのを避けるために、
最も確実な手法は、インストールCD・DVDでOSを起動させ、shell が稼動する状態にすることです。
この状態では、全てのHDDは mount 状態になりません。
しかしながら、この状態にするのは実際には結構面倒なので、OS起動時にシングルユーザモードで起動するのも手法のひとつです。
但し、この場合は、起動ディスクのルートパーティション '/' が mount された状態になります。
上記で言うと、
/dev/ada0p2     /               ufs     rw      1       1
のみが mount された状態になります。
また、あまりお勧めはしませんが、初めに /etc/fstab で該当HDDのパーティション全てをコメントアウト編集したした状態で再起動した場合、通常の起動はマルチユーザーモードですが、この通常起動モードでも作業は出来ます。
マルチユーザモードの場合、必ず root ユーザにて作業を行います。

手順2)パーティションの状態を確認し、余計なパーティションが有れば削除
パーティションの確認は、
# gpart show ada1

=>        34  1953525101  ada1  GPT  (932G)
          34   901775360     1  freebsd-ufs  (430G)
   901775394   251658240     2  freebsd-ufs  (120G)
  1153433634   251658240     3  freebsd-ufs  (120G)
  1405091874   548433260     4  freebsd-ufs  (262G)
  1953525134           1        - free -  (512B)
のような形で確認できます。'show' はサブコマンド、'ada1' OSがHDDに割り当てたデバイス名です。
上記パーティションの削除は、
# gpart delete -i 1 ada1
ada1p1 deleted
# gpart delete -i 2 ada1
ada1p2 deleted
# gpart delete -i 3 ada1
ada1p3 deleted
# gpart delete -i 4 ada1
ada1p4 deleted
# gpart destroy ada1
ada1 destroyed
または、
# gpart destroy -F ada1
ada1 destroyed
一旦、パーティション情報をまっさらにすると、この後の作業確実です。
尚、初めて使用する新品HDDの場合は
# gpart show ada1

=>        34  1953525101  ada1  none  (932G)
          34  1953525101        - free -  (932G)
みたいな表示になるため、この作業は必要ないはずです。

手順3)パーティションを設定
現在は殆どの場合、GPT 形式のパーティションテーブルを採用します。
かなり古いマザーボードだと、GPT 形式に対応していないことがあるため、この場合は MBR 形式を使用します。

先ずは、 GPT 形式パーティションを使用する宣言・指定です。
# gpart create -s GPT ada1
ada1 created
次に、具体的にパーティションを指定します。
パーティションの追加は下記のようにします:
# gpart add -t freebsd-ufs -s 12G ada1
# gpart add -t freebsd-ufs ada1
-t でパーティションタイプ、-s でパーティションサイズを指定し、最後のキーワードは該当HDDデバイス名です。
-s のサイズ指定を省略すると、自動的に残部の割り当て可能最大領域を確保したパーティションサイズになります。
上記の場合、パーティションを確認すると、下記のような感じになるはずです:
# gpart show ada1
=>        40  1953525088  ada1  GPT  (932G)
          40    25165824     1  freebsd-ufs  (12G)
    25165864  1928359264     2  freebsd-ufs  (920G)

手順4)パーティションの初期化(フォーマット)
パーティションを設定した後は、必ずファイルシステムの初期化を行います。
Windows などでいうところの「論理フォーマット」に該当する作業になります。
# newfs -U /dev/ada1p1
# newfs -U /dev/ada1p2
各コマンドを実行すると、数字の羅列が表示されて初期化が行われます。
この数字は、HDDが一部破損した時などのバックアップに使用する管理上の番号ですが、UNIX系のファイルシステム詳部に関わる話題なので、ここでは説明を割愛します。

OS起動HDDとするには、もう少し面倒な手順を踏みますが、通常はインストーラがナビゲートするため、これも説明を割愛します。

手順5)自動マウントの設定
最初の「注意点)」の項目で、 /etc/fstab の該当デバイスをコメントアウトしましたが、
今度はOS起動時に自動的に今回作成したパーティションをマウントさせるために、再び書き換えを行います。

今回の例において、/dev/ada1p1 と /dev/ada1p2 に自動マウントさせるには、以下のようにします:
# vi /etc/fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0p2     /               ufs     rw      1       1
/dev/ada0p3     none            swap    sw      0       0
/dev/ada0p4     /usr            ufs     rw      2       2
/dev/ada0p5     /tmp            ufs     rw      2       2
/dev/ada1p1     /home           ufs     rw      2       2
/dev/ada1p2     /backup         ufs     rw      2       2
ルートディレクトリ '/' 配下にマウントポイントとなるディレクトリが存在しない場合、エラーになりますので、ルートディレクトリにマウントポイントとなるディレクトリを作ります:
# cd /
# mkdir backup
これで、通常の再起動を行えば、作業完了です。
起動後、freebsd-ufs パーティションを追加した場合に限りますが、
% df
/dev/ada0p2  73122268    664920  66607568     1%    /
devfs               1         1         0   100%    /dev
/dev/ada0p4 335160852  23687292 284660692     8%    /usr
/dev/ada0p5  48491312     36960  44575048     0%    /tmp
/dev/ada1p1  12180252     32836  11172996     0%    /home
/dev/ada1p2 933907000     32836 859161604     0%    /backup
のように、増設または変更したパーティションが表示されていれば作業完了。

2021/04/12(月)落下させた東芝製HDDのテスト結果公表

どうも「本当か??」みたいな反応が多いので、
一応、再度試験してテスト結果のスクリーンショット撮影を。

下記 ada0 は落下させた東芝製HDD、 ada1 は2年半ほど使って遊休状態だった東芝製HDD。
型番同じですが、 ada1 の方が製造時期は2ヵ月ほど遅い。
20210412.jpg

※ 画像をクリックすると、大きめの画像が表示されます。

全領域の読み出しテストを行っています。
FreeBSD 12.2(Release版) のインストールCD上のOSを起動しています。

of の指定が /dev/null なので、実際には書き込みは一切行いませんが、
読み込みが出来なければ、書き込みも出来ない故、HDDの損傷検出に使えるのです。
ちなみに、読み込み出来ない場合は、TIMEOUT や FAILURE などのメッセージが必ず表示されます。

2つのHDD共に「エラーがありませんでした」という結果でした。

2021/04/10(土)日本メーカのHDDは丈夫らしい・・・

今や、ハードディスクを製造しているメーカは減っていて、
東芝は現在では日本で唯一と思われるが。。ただ、このHDDの生産自体は中国共産党な国。
#最近は、違うらしい

以前は、日立が HGST という名称の傘下企業を抱えていたが、これは今は Western Digital の傘下。
20210410_1.jpg


2015年10月に購入し、2年くらい使っていたが、
容量の大きなものに換装するために交換作業をしていたところ、誤って床に強打する形で落下させてしまい、
「壊してしまった・・・」と半ばあきらめていたのですが、認識はするので暫く使う用途もなく放置状態でした。

ところが、どうしてもハードディスクが必要な状況が発生し、2~3回全領域の読み取りテストを行ったところ、
全く異常が無いことが判り、ちょっと驚いているところ。

最初、Western Digital の製造ラインを引き継いだころは、東芝製は何かとトラブルが多かったが、
数年でこの品質に改善なのでこれもちょっと驚き。

今年は、今のところ5月から6月と、8月に多忙の山が来そうです。