install FreeBSD
Table of Contents
FreeBSD in USB Drive
前回は、女房のおかげで、思わぬ掘り出し物が出てきた。そう、昔使ってたバッ ファローの外付けUSB Drive。全面をクリアしたんで、情報漏洩の恐れもない。
最終的に、64Bit版のFreeBSDを入れたい。だって、BSD四方山話を読んでいた ら、amd版なら、bhyveが動くから、qemuの代わりになる。頑張れば、OpenBSD を入れて、そこでvmmを動かせるかも知れない。画餅にならない様に、i386版 のFreeBSDを練習で入れてみる。使うマシンは古いSL510だ。
念の為にハンドブックを参照。 第2章 FreeBSD のインストール
インストール中に、WiFiが設定できるみたい。これはdebianみたいに頑なじゃ なくて、いいな。
インストーラーをメモリースティクに焼いて、そこから起動。ダエモン君が出 てきたら、USB DriveをONにする。こうしないと、Driveの方を先に見てしまい ブートに失敗するからだ。
一番気を使う場面は、どのメディアにインストールするかの指定。da0がスティッ クでda1がドライブだった。
Wifiは、iwn0を検出してくれたので、設定してみたけど、動作しなかった。か の昔、FreeBSDでちゃんと動作してたんだけどな。古いマシンは、ソフトのサ ポートがおざなりになるんかな？
とりあえず起動させるのが先だな。WiFiの設定は、 【FreeBSD】無線LAN(Wi-Fi)に接続したい を見て後からできるからね。
missing /etc/fstab
起動時に、/ がマウント出来なくて中途半端になった。前回qemuでFreeBSDを 入れた時と同様の画面。お勧めに従って、ufs:/dev/d0s1a したら無事に loginまで行けた。
すかさず、/etc/fstabを確認してみたら、/dev/da1s1a になってたぞ。 インストール時は、メモリースティックが、da0を占めていたんで、da1が fstabに記録されたんだな。それが、実使用になると、メモリースティクを抜 いたあるんで、USB driveは、da0に繰り上がたんだな。こういう事が有るんで、 注意しないとな。
sakae@slfb:~ $ cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/da0s1a / ufs rw 1 1 /dev/da0s1b none swap sw 0 0 tmpfs /tmp tmpfs rw,size=512m,mode=1777 0 0
WiFi
sysctl net.wlan.devices ifconfig wlan0 create wlandev iwn0 country JP ifconfig wlan0 up ifconfig wlan0 scan wpa_passphrase XXX-B hogehoge > /etc/wpa_supplicant.conf wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf dhclient wlan0
wpa_supplicant で認識するまで、時間がかかる事があるので注意。そうか、イ
ンストール時の失敗は、これが影響していたのか。
rc.conf
wlans_iwn0="wlan0" ifconfig_wlan0="WPA DHCP" create_args_wlan0="country JP regdomain ETSI"
電波法をきちんと守らないと、最大300万円の罰金です。電波は公共財産です からねぇ。きちんと日本の空へ発射できる範囲に設定しておきましょう。
ifconfig_wlan0="WPA inet xx.xx.xx.xx netmask 255.255.255.0" defaultrouter="xx.xx.xx.1"
固定IPを設定する場合は、上記の様に。
sakae@slfb:~ $ cat /etc/resolv.conf nameserver 8.8.8.8
その場合は、この設定も、お忘れなく。
see disk by OpenBSD
伝統的にMBR方式で、区画を作ったんだけど、それがOpenBSDから、どの様に見 えるか確認しておく。
ob# fdisk sd1
Disk: sd1 geometry: 19457/255/63 [312581808 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
*0: A5 0 1 2 - 19450 181 59 [ 64: 312475648 ] FreeBSD
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused
3: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused
ラベルの方は、OpenBSD専用っぽくて、FreeBSD側の設定は、認識していない。 そんなものなのか。
ob# disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: SAMSUNG SP1604N duid: 0000000000000000 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 19457 total sectors: 312581808 boundstart: 0 boundend: 312581808 16 partitions: # size offset fstype [fsize bsize cpg] c: 312581808 0 unused i: 312475648 64 unknown
ports
portsを維持する為のportsnapが無いぞ。昔は有ったんだけどな。 pkgになってたので、取り寄せ。
portsnap fetch extract ;; 初回のみ portsnap fetch update cd /usr/ports; make fetchindex ;; for make search key=xxx
後で調べたら、gitを使うようだ。何か現代風になったな。 FreeBSD 14.0でportsnapが削除 Portsツリーを更新する方法
更新が速いんで、履歴もどんどん膨れるだろう。爆発しないか心配です。それ に目をつぶれば、gitって楽だわなあ。
gitは嫌だと言う方には、OpenBSDの独自実装である、got ってのも有るようで す。
Game of Trees (Got) is a version control system which prioritizes ease of use and simplicity over flexibility. Got is still under development; it is being developed exclusively on OpenBSD and its target audience are OpenBSD developers. Got is ISC-licensed and was designed with pledge(2) and unveil(2) in mind. Got uses Git repositories to store versioned data. At present, Got supports local version control operations only. Git can be used for any functionality which has not yet been implemented in Got. It will always remain possible to work with both Got and Git on the same repository. This package includes the got(1) command-line interface and the tog(1) read-only repository browser. EXAMPLES in the got(1) man page contains a quick-start guide for OpenBSD developers.
vt sc or X
普段はsshしてるんで、コンソールを放置してる。昔はダエモンのスクリーン セーバーを動作させてたんだ。えと、どう設定するんだったかな？ Display とか How do you set a screensaver in console mode? あたりかな。 vidcontrol splash なんてmanも参照だな。
man rc.consすると山のようにキーワードが出てくる。これらは、主に /etc/rc.d/にある、スクリプトの変数名になっている。見繕って設定してみた。
/etc/rc.conf
blanktime="123" saver="beastie"
が、思うように動作しない。
cd /etc/rc.d sh -x syscons restart >/tmp/LOG 2>&1
ログでも眺めてみれば、何かヒントが得られるかな。これだとメチャ長いログ になっちゃう。rc, rc.subr(8)すると、自分なりのdebug方法が見えてきた。
rc.d/sysconsを/tmpにコピして、いじり倒すのが楽。
# load_rc_config $name set -xv blanktime="123" saver="beastie" run_rc_command $*
ファイルの最後をちょいと改変。 load_rc_config を無効化する。その代わ
りに、次の2行で、rc.confの設定を代行させる。そして、set -xv でログを開
始。このスクリプトの引数によって、実行開始。
sakae@fb:/tmp $ doas ./syscons start >LOG 2>&1
下記はログの一部。冒頭が + になってるのは、実行したコマンド。何も付い ていないのは、これから実行するソース。
blanktime="123"
+ blanktime=123
saver="beastie"
+ saver=beastie
run_rc_command $*
+ run_rc_command start
:
+ sysctl -n kern.vty
+ [ xvt '=' xvt ]
+ _sc_console=vt
+ _sc_config=vt
+ echo -n 'Configuring vt:'
Configuring vt:+ _sc_initdone=yes
+ echo -n ' blanktime'
blanktime+ vidcontrol -t 123
+ sc_init
+ [ -z yes ]
+ echo -n ' screensaver'
screensaver+ kldstat
+ awk '$5 ~ "_saver\.ko$" { print $5 }'
+ load_kld -e _saver beastie_saver
どうも、コンソソールがvtだと、スクリーンセーバーが動作しない様だ。昔の scならちゃんと動作する。まあ、今時、Xを使っておけ。そうすれば、黙って いても、10分で天然のスクリーンセーバー、ブランク版が動く。
それにしてもBSD系は天国だと思うぞ。何が天国なの？ 世にはこびっているOS と比べてみんしゃい。あちらは、起動にブラックボックスなsystemdなんての を採用してる。こちらは、公正明大なshell script。ちょいとdebugっぽい事 も簡単にできる。この透明感がすがすがしいんだよな。
OpenBSDだと/etc/rcに、ほとんどの機能が詰め込まれている。FreeBSDだと、 それぞれのjobが、単機能として、/etc/rc.d/* に格納されている。して、そ の数は、173個にのぼる。その中には、必須の物も含まれている。
sakae@f64:~ $ service -e /etc/rc.d/hostid : /etc/rc.d/utx /etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/bgfsck /etc/rc.d/sendmail
で、件のUSB driveに 思い余って、これでもかってぐらい、X関係を入れたよ。そしたらドライブが 思わぬ程に発熱した。秋になるまで、放置ですかね。
それより、こんな警告が気になるぞ。
sakae@slfb:~ $ dmesg|grep WAR WARNING: 32-bit kernels are deprecated and may be removed in FreeBSD 15.0. WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD 15.0. WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 15.0. WARNING: 32-bit kernels are deprecated and may be removed in FreeBSD 15.0.
FreeBSD/64Bit on VMWare
KADOKAWAさんの所、身代金を払った、払っていないってんで、色々な噂が飛びかっていま すな。大変だーーー。
ランサムウェア「TargetCompany」のLinux型亜種がVMware ESXiの仮想環境を 攻撃
ユーザー数の多いリナも、悪い人に狙われています。被害に会わないように、 辺境なOSを使いましょう。理想はOpenBSDだと思うんだけど、せめてFreeBSDぐ らいは選択肢に入れておいて下さい。
32Bitは末永く使えないと思うので、FreeBSD 14.1/64Bitを入れてみたよ。 素直なユーザーに徹する事にします。
インストール時、32Bitアプリを動かすために、lib32を入れるか質問あり、 YES。
sakae@f64:~ $ du -sh /lib /usr/lib /usr/lib32 17M /lib 267M /usr/lib 132M /usr/lib32
sakae@f64:~ $ file /lib/libc.so.7 /usr/lib/libc.so /usr/lib32/libc.so.7 /lib/libc.so.7: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 14.1, stripped /usr/lib/libc.so: ASCII text /usr/lib32/libc.so.7: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, for FreeBSD 14.1, stripped
ASCII textってのが面白いな。
sakae@f64:~ $ cat /usr/lib/libc.so GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a )
bhyve
気になったのは、これであります。qemuと同等な機能の実現。何も余計な物を 入れずに、仮想PCが実現できる様です。ゲストはi386でも大丈夫なのかな？
bhyve の ubuntu で Intel Wi-Fi 6 AX200 を利用する
24.6. FreeBSD as a Host with bhyve (by HandBookなんだけど、本文が読み 難いので、閲覧にはw3mがお勧め)
vmm
そして、FreeBSDに対抗すべく、OpenBSDでも同様な機能が実装されている。ただし、どんなゲストOSでも 実行できる訳ではなく、ホストOSのみを仮想化する機能です。安全重視の砂場 環境です。
ob$ cd vmd ob$ ls Makefile i8253.c mmio.c proc.c virtio.h atomicio.c i8253.h mmio.h proc.h vm.c atomicio.h i8259.c ns8250.c vioblk.c vm.conf.5 config.c i8259.h ns8250.h vionet.c vm_agentx.c control.c loadfile.h packet.c vioqcow2.c vmd.8 dhcp.c loadfile_elf.c parse.y vioraw.c vmd.c dhcp.h log.c pci.c vioscsi.c vmd.h fw_cfg.c mc146818.c pci.h vioscsi.h vmm.c fw_cfg.h mc146818.h priv.c virtio.c vmm.h
Makefileには、.if ${MACHINE} == "amd64" ~ .endif こんな記述があって、 amd64関係者以外は、立ち入り禁止になってる。これを突破したら、どんな報 復が有るのだろう？
ob# make
cc -O2 -pipe -Wall -I/usr/src/usr.sbin/vmd -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer
-arith -Wcast-qual -Wsign-compare -Werror-implicit-function-declaration -MD -MP -c vmd.c
In file included from vmd.c:48:
In file included from /usr/src/usr.sbin/vmd/vmd.h:26:
/usr/include/dev/vmm/vmm.h:40:36: error: use of undeclared identifier 'VMM_MAX_MEM_RANGES'
struct vm_mem_range vcp_memranges[VMM_MAX_MEM_RANGES];
^
規制線を回避する呪文のファイルを探してみる。
ob$ cd /usr/src/ ob$ find . -name '*.[ch]' | xargs grep VMM_MAX_MEM_RANGES ./sys/arch/amd64/include/vmmvar.h:#define VMM_MAX_MEM_RANGES 16
マシン固有の定義が有るとな。vmd.cをちょっと改造。
/* #include <machine/vmmvar.h> */ #include "/sys/arch/amd64/include/vmmvar.h"
これで、vmd.cのコンパイルは成功するけど、他にも12個のファイルを改造し なければならない。もう、これぐらいにしといちゃる。
ChatGPT
Q: C言語のソースコードについて、尋ねます。32Bit用と64Bit用のコードは、ソース上で判別できますか？ 出来るなら、どこに注目すれば良いですか？ この疑問の背景: FreeBSD/64Bit版のインストール時に、32Bit用のアプリの為に、lib32を 追加インストールできる用になってました。それで、ソース上での違い判別に興味をもった次第です。
A: C言語のソースコードにおいて、32ビット用と64ビット用のコードを判別するためには、いくつかの方法や指標があります。以下に、主なポイントを挙げます。
### 1. プリプロセッサディレクティブ C言語では、プリプロセッサディレクティブを使用して、コンパイル時にコードを切り替えることがよくあります。特にビット数に関する条件分岐には、`_LP64__` や `WIN64`、`_x8664__` といった定義が用いられます。
#ifdef __LP64__ // 64ビット用のコード #else // 32ビット用のコード #endif
例えば、`_LP64__` は主に64ビット環境（特にUNIX系システム）で定義されます。
### 2. 型のサイズ 32ビットと64ビットの環境では、いくつかの基本的なデータ型のサイズが異なります。特に、`long` 型やポインタのサイズが異なることがあります。以下のようなコードで確認することができます。
#include <stdio.h>
int main() {
printf("Size of long: %zu bytes\n", sizeof(long));
printf("Size of void*: %zu bytes\n", sizeof(void*));
return 0;
}
32ビット環境では、`long` とポインタは通常4バイトですが、64ビット環境では8バイトになります。
### 3. プラットフォーム固有のヘッダファイル 特定の環境に依存するヘッダファイルが使用されている場合、それが手がかりになることがあります。例えば、Windowsでは`windows.h`、UNIX系システムでは`unistd.h`などが使われます。
### 4. コンパイル時のフラグ ソースコードには明示的に32ビットや64ビット用のコンパイルフラグが書かれていることがあります。例えば、`-m32` や `-m64` フラグを使用してコンパイルすることができます。
### 5. 条件付きコンパイル ソースコードに条件付きコンパイルの指示が書かれている場合があります。
#if defined(__x86_64__) || defined(_M_X64) // 64ビットアーキテクチャ用のコード #elif defined(__i386) || defined(_M_IX86) // 32ビットアーキテクチャ用のコード #endif
### まとめ 32ビット用と64ビット用のコードをソース上で判別するためには、上記のようなプリプロセッサディレクティブや型のサイズ、プラットフォーム固有のヘッダファイルなどに注目すると良いでしょう。また、コード内で明示的に条件付きコンパイルの指示が書かれている場合もあります。
FreeBSDの64ビット版で32ビット用のライブラリ（lib32）を追加インストールする理由は、32ビット用にコンパイルされたバイナリが動作するための互換性を提供するためです。これは、古い32ビットアプリケーションを64ビット環境で動作させるための一般的な方法です。