「PC」カテゴリーアーカイブ

Hyfaxのこと(7)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の7回目です。前回まででboot0、boot1を経てmonitorを起動するところまでできました。やっとmonitor本体のお話ができます。
今回はmonitorにSysCallを導入したいと思います。Linuxでも使われている仕組みで、「直接BIOSを呼ばない」ための約束事です。なんかかっこいいですよねw

本格的に機能として実装しようとすると多岐にわたるのですが、今回は最低限、すぐに使うものだけを実装しようと思います。

HyfaxのSysCall

実装にはint 0x80割り込みを使います。定番だそうなのでそれに乗っかった感じです。
into 0x80を実行するとソフトウェア割り込みが発生し、事前に登録されたハンドラに制御が移り、実行後に戻る形ですね。

HyfaxのSysCall ABI

ABI(Application Binary Interface)はバイナリ同士が守る約束事です。APIがソースコード上の約束事(関数名、引数、型など)であるように、ABIは実行時の約束事(どのレジスタに何を入れるか、どこに戻り値が来るか)になります。

今回は5つの機能を実装します。

AH機能引数戻り補足
20hwriteDS:SIなし文字列出力
22hgetkeyなしAL一文字入力
23hputcharALなし一文字出力
24hnewlineなしなし改行
26hrebootなし戻らない再起動

実装

はい。実装です。こんな感じにしてみました。

実行結果はこんな感じになります。

なんだかそれらしくなってきましたね♪

さて、今日はここまでです。やっと終わりが見てうれしい限りです。

《2025/12/19 3:01:43》

Hyfaxのこと(6)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の6回目です。今回は予告通りFATクラスタチェーンの追跡を取り込みたいと思います。

クラスタチェーン

FATはクラスタという単位で管理されています。クラスタは標準で4セクタ=0x800Byte=2048Byteになります。ここで、

  • もしすべてのファイルサイズが2014Byte未満だったら
    この場合は管理が簡単で、ディレクトリ管理領域にあるファイル名と開始LBAだけあれば内容にアクセスできます。
  • もしファイルが1回書いたら消せないとしたら
    この場合もファイル名と開始LBAがあればファイルにアクセスできます。

ところがわたしたちのやりたいことは、ファイルのサイズが自由に変えられて、削除追加ができることなんですね。例えば2048ByteのファイルAとB、4096ByteのファイルCがあったとします。ファイルA、Bと追加した後ファイルAを削除し、ファイルCを追加すると木のことを考えてみます。

ファイルAとファイルBを空きディスクに追加します。

すると感じになります。

次にファイルAを削除するとこう。

ここにファイルCを追加すると、空きエリアをできるだけ少なくするように(言い換えると効率的にディスクを使うために)ファイルCを分割して格納することになります。

結果としてディスクにはこのように格納されることになります。

このように異なるサイズのファイルを削除追加できるようにすると、場合によってファイルが分割され泣き別れになって格納されることになるわけです。このような場合、ファイルの先頭とサイズだけわかっていても全体を扱うことができません。ファイルが分割されたときに、その先がどこにあるかを記録しておく必要があります。これがFATです。FATでは特定のクラスタがどのクラスタにつながっているかが記録されています。開始クラスタから終端クラスタまでの単方向リストです。
あまりいい例ではないのですが、何度か見たディスクイメージのダンプを覗いてみます。

ディレクトリ領域は0x110800から始まります。最初のエントリはボリュームラベルです。『MONITOR BIN』のエントリは0x110820から始まり、開始クラスタが0x0002(エンジ色の部分)サイズが0x000008c5Byte(水色の部分)だとわかります。0x08c5=2245なので1クラスタを少し超えています。
次にFAT1を見ます。FATは2バイト=1エントリで、ゼロオリジンなので0x0002クラスタに対応する箇所は0x100804(エンジ色の部分)になります。そして1クラスタに入りきらないので次の空きクラスタに行くのですが、この例では隣が開いていたみたいでクラスタ0x0003に続いています。クラスタ0x0003ですべて格納できますのでクラスタ0x0003に続きはなく0xffff(EOF)で終了しています。
『MONITOR BIN」の次のファイルは『APP BIN』なのですが、同様に0x0004クラスタと0x0005クラスタの2クラスタ使用して格納されていることがわかります。

このような構造になっているのですが、使い方はそれほど複雑ではなく、ファイルの内容を読みに行くときにクラスタが終端ならばそこで終了、先があるなら先を読む。これを終端になるまで繰り返す。
言葉にしてしまえばこれだけなんです。

実装

コードにするとこんな感じになります。
前回のfind_dir_ent:から先を修正したものになります。

ね?めんどくさいでしょ?

さてキリがいいところで今日はここまでです。実行結果は前回、前々回と変わらないので載せません。でも『結果が同じことを確認する』ことができるだけで、言い換えれば『ゴールが明確になる』だけで、かなり気持ち的に楽になります。

次回は『MONITOR BIN』に機能を追加しようかなとか思ってますが、どうなるかわかりません。未来のわたしに聞いてください♪

Hyfaxのこと(5)

x86リアルモードで動くモニタプログラムのHyfaxを作るお話の5回目です。前回ではBOOT1.BINが起動するところまでを作成し確認しました。今回はBOOT1.BINにディレクトリ検索機能とFATチェーン追跡機能を追加してBOOT1.BINを完成させたいのですが、果たしてうまく事が運ぶかどうか。不安でいっぱいです。

BOOT1.BINの機能

BOOT1.BINはVBRに置かれ、MBRにあるboot0.binからメモリに読み込まれ実行されます。そしてFAT16ファイルシステム内にあるMONITOR.BINを検索して読み込み、さらにこれを実行します。MBRは完全固定で、VBRは半分ほど固定でディスク内に配置されるので、読み込む際に考慮する点は多くなく、というかとても少なく、ある意味LBA固定で作成することもできます。MONITOR.BINもLBAを固定で済ますこともできないわけじゃないです。というか、前回それをやりました。が、ご存じのようにファイル内にはいくつもファイルを置くことができますし、並び順も固定ではありません。なのでFAT16ファイルシステムを使うのであれば(言い換えれば使うときに便利にするためには)、手順を踏まなければいけません。

ファイルシステムを使うからどこにMONITOR.BINを置いてもいいかというと、そうはいきません。ブートプログラムはサイズ制限が厳しいのでMONITOR.BINはルートディレクトリに置くことになります。BOOT1.BINはルートディレクトリ管理領域からMONITOR.BINの開始クラスタ番号とサイズを読み取り、メモリに読み込んで実行することになります。

ディスクイメージダンプ

ここでもう一度ディスクイメージのダンプを見てみます。

ルートディレクトリの管理領域は0x110800Byteから始まります。数字の羅列でなにがなにやらなんですが、その右側にあるASCII表示を見ると、『MONITOR BIN』『APP BIN』『APP1 BIN』……とどこかで見たような名前があります。そうファイル名です。ディレクトリエントリは1エントリ=32Byteでファイル名、属性、開始クラスタ番号、サイズ等を持っています。最大エントリ数であるROOT_ENT_CNT(0x0200)個並んでいる中から、お目当てのファイル名を探し出して開始クラスタ番号、サイズを取り出し使用するわけです。
ディレクトリエントリの構造はこんな感じ。この例だと『MONITOR BIN』の開始クラスタは0x0002、サイズは0x000008c5ですね。(注:リトルエンディアン)あ、FAT16前提なので上位クラスタ番号は使いません。

実装

前々回DIR_START_LBA、DATA_START_LBA、ROOT_ENT_CNTを保存しました。
①DIR_START_LBAから32Byteずつ取り出し
②先頭の11文字を照合して
③目当てのファイルだったら
④下位クラスタ番号とサイズを取り出し
⑤クラスタ番号からLBA値を算出し
⑥DATA_START_LBAから始まってその値にあたる部分からファイルサイズだけ読み込む

という実装になります。うむぅ。FATのクラスタチェーンの話は次回ですね。今回は連続して置かれているだろうことを信じてサイズをそのまま使いましょう。(今回の例ではクラスタが連続していないということはあり得ないんですけどね。)
検索処理をコードにするとこんな感じになります。
前回のコードのFILEのLBAを算出する部分とファイルサイズ・セクタ変換する部分をまるっと置き換えると動くはずです。

これを見て『なんをしてるかわかんな~い』と思ったあなた。悲観する必要はありません。書いたわたしが今そう思ってます。書いた時点では理解していても時間がたつと忘れます。ホント。コメント大事です。きっぱり。

実行結果

一応実行結果もあげておきますね。

まぁ、前回と変わらないんですけどねw
とはいえゴールが明確に示され、達成がはっきりわかるのはいいことです。うんうん。

さて、今回はここまでにします。次回こそラスボス感のある掛け算七の段こと、FATクラスタチェーンの追跡を実装しようと思います。
お疲れさまでした。

《2025/12/14 17:35:29》

Hyfaxのこと(4)

x86リアルモードでモニタプログラムを作ろうの第4回目です。今回はブート処理の2段階目、VBRからの起動になります。
前回、boot1.asmで使用するであろう数値群をあらかじめ用意したので、モニタプログラムを起動することだけなら簡単にできます。ちょっと重複しますが確認しておきますね。

①MBRからVBRのLBAを取り出して読み込み遷移する。
②BPBから必要な数値を得る。
③FAT開始位置を得る。
④DIR領域開始位置を得る
⑤DIR領域からファイルの開始LBAとサイズを得る。
⑥サイズとFATを比べながらファイルを読み込む
⑦ファイルに遷移する。

ざっくり言うとこういう流れになります。①②はboot0.asmでやってますので、boot1.asmは③~⑦をやることになります。盛りだくさんですね。
FATを利用して、となるとこうなるのですが、このシリーズではファイル位置は固定ですので(作り方がいつでも一緒なので同じ位置に作られる)単にモニタプログラムを起動するだけなら、モニタの開始位置とサイズがあれば実現できます。モニタが複数クラスタにまたがったとしても、連続領域に配置されることは確定なので、FATによるクラスタチェーンも追う必要はなかったりします。
要するに突き詰めれば⑤だけあればいいことになります。
モニタプログラムは『MONITOR .BIN』という名前なので、ダンプして調べてみるとこんな感じ。

VBR領域の後、FAT1、FAT2の領域があって、その後ろにDIR領域があります。『MONITOR .BIN』はDIR領域の2番目のエントリにあって、開始クラスタは0x0002、サイズは0x000008c5となっています。(注:リトルエンディアン)
開始クラスタが2番目ということはセクタ数は0セクタ(先頭2クラスタは予約)。データ開始LBAの最初に『MONITOR BIN』ですね。
データ開始LBAは前回保存したものがあるのでそれを使うとLBAは0x08a4、バイト数で0x114800になります。
これらを踏まえてboot1.asmのプロトタイプとmonitor.asmのスタブを作ってみます。

boot1.binプロトタイプ

boot1.asmプロトタイプです。前回保存した各種数値を取り出して使えるようにしつつ、LBA0x8a4にある『MONITOR .BIN』をサイズ0x08c5Byte(5セクタ)で読込、遷移させます。

こんな感じ。

monitor.asmスタブ

monitor.asmのスタブは遷移されたことがわかるだけでいいので、メッセージを出すだけにします。こんな感じでしょうか。

実行結果

実行するとこんな感じになります。

Hello from Monitorが表示されてますね。正しく読み込まれて遷移されたことがわかります。これで一つのゴールが明確になりました。monitorを読み込んで遷移する。このゴールを崩さないように、ディレクトリエントリの検索、fatチェーンの追跡を行うことになります。

さて、そろそろいい時間なので、今日はここまでです。お疲れさまでした。
細切れにして情報量少なくなってごめんなさいです。
でもね、この程度でも書くのとってもしんどいんですよ?
ともあれ、また次回お会いしましょう。

《2025/12/14 4:59:42》

Hyfaxのこと(3)

前回boot0.asmを作ったわけですが、次のboot1.asmを作るにあたって用意しておくと多少楽になって整理がしやすい数値群があります。今回はboot0.asm側であらかじめそういった数値を用意しておこうと思います。

用意するのは
BOOT_DRIVE
VBR_START_LBA
ROOT_ENT_CNT
FAT_START_LBA
DIR_START_LBA
CLUS_SIZ
DATA_START_LBA
です。

それぞれ少し説明しますね。

BOOT_DRIVE

Bootされたドライブの値です。boot0.asm実行時にdlレジスタに渡されてきます。boot0.asmでしか拾えない値なので、保存して使いまわします。

VBR_START_LBA

文字通りVBRが開始されるLBAです。これはMBRのパーテションテーブルの中にしかないので、これまた保存して使いまわします。

ROOT_ENT_CNT

ルートディレクトリの中にいくつエントリが入るかを示します。FAT16ではROOTディレクトリがサイズ固定なので、この数値を見て最大値を算出します。BPBと呼ばれる領域に設定されています。

FAT_START_LBA

文字通りFATが解されるLBAです。計算で出します。VBR開始後、リザーブされた領域を挟んで、そのあとからFATが始まります。

FAT_START_LBA = VBR_START_LBA + BPB_FAT16.RsvdSecCnt

となります。
余談ですが、MBRはMAX512Byte、パーテションテーブルを除くと446Byte「しか」取れません。必達です。ですがVBRの方はVBRの開始からFATの開始までの領域を使うことができます。VBR_START_LBA + BPB_FAT16.RsvdSecCnt分だけ余裕があるわけです。

DIR_START_LBA

ディレクトリ領域が開始されるLBAです。FATの後に位置し、計算で出します。FATは2個あるので、FAT開始LBAのあと、FAT領域を2つ分追加した後がこの値になります。

DIR_START_LBA = FAT_START_LBA + BPB_FAT16.FATSz16 * BPB_FAT16.NumFATs

CLUS_SIZ

クラスタの総バイト数です。標準では4セクタ=1クラスタ、512Byte=1セクタなので0x800Byteになるはずです。

CLUS_SIZ = BPB_FAT16.SecPerClus * BPB_FAT16.BytesPerSec

DATA_START_LBA

DIR_START_LBAにディレクトリエントリの分の領域を要した後がデータ開始LBAになります。

DATA_START_LBA = ROOT_ENT_CNT * 32 / BPB_FAT16.BytesPerSec

boot0.asmの修正

boot0.asmにデータ保存用のコードを入れていきます。主処理の間にチマチマ出てきてうっとうしいし見通しが悪くなるんですが、まぁ、しかたがないですね。で、修正したソースがこれ。

あと、定義ファイルも使用しています。これですね。

これでboot1.asmを作成する準備ができました。

次回こそはboot1.asmを公開したいと思います。

《2025/12/12 22:00:47》

Hyfaxのこと(2)

このテーマを進めるにあたって、どうしようかいろいろ考えたのですが、まずはディスクイメージを作るところから始めることにしました。
QEMUでの実行ではプログラムを指定というよりディスクイメージを指定しするので、これがないと何もできません。今回はFAT16の32MByteのハードディスクイメージを作成します。

作り方はこれ。

ddでファイルのガワを作って、パーティションテーブル作って、ブート可能にして、フォーマットしてます。
まんまですねw

プログラムの方なんですが、オレオレOSというかオレオレ環境なので、どんな構成でも構わないっちゃ構わないんですが、FAT16を選択してしまった以上、決まったお作法があります。

Fat構造だとまず最初にMBR(Master Boot Record)から512Byte 読み込んで実行します。そこでパーティションテーブルを確認して、最初にブート可能なパーティションのVBR(Volume Boot Record)の位置を取り出して、そこを読み込みます。
VBRでは実行するプログラムをファイルシステムから探して読み込みます。

というような、ちょっと面倒くさいお作法になります。
都合上、MBRに置くプログラムをboot0.bin、VBRに置くプログラムをboot1.bin、ファイルシステムから読み込むプログラムをmonitor.binとしています。
アイキャッチの図の通りです。

今回はboot0.binを作りたいと思います。
これは結構楽なんですよね。なにせMBRに置いておけばあとは勝手に読み込まれて実行されるので。
まずは「とにかく動けばいいや」というコードを書いてみます。実はVBRの位置は0x800セクタ、VBRの大きさはMAX4セクタとわかっているので、パラメータを揃えて実行するだけです。
こんな感じ?

確認用に読み込んだ内容の先頭16バイトを表示しています。実行結果はこんな感じ。

ディスクイメージをダンプするとこんな感じ。

セクタ0x800、バイトで0x100000の先頭はeb 3c 90。正しく実行されてますね。

さて、骨格ができたところで肉付けを。というかパーテションテーブルをきちんと見るように修正します。パーティションテーブル、4エントリをなめて当たりを探す処理を追加です。
一気に行っちゃいます。

事項結果は前と変わらないので省略。
最後にboot0.binをディスクイメージに書き込む例を挙げて終わりにします。
パーティションテーブルより前の446バイトを書き込んでいます。

お疲れさまでした。(主にわたしが疲れてるという……)

《2025/12/3 223:41:32》

Hyfaxのこと

これまでBIOSやらBootやらで遊んできたわけなんですが、何か機能とかが気になって遊ぼうとするたびに、boot、機能読み込み、実行とかすることになるわけです。
で、ブートの部分とか機能の読み込みの部分はほぼ同一だという。
同じものを使いまわしするので面倒くささはあまりないのですが、同じものを何度も使うならソースの再利用じゃなくてバイナリの再利用をしたいなぁ、とか思っちゃうんですね。ほとんど同じソースがあちこちにあると、心がゾワゾワするというかなんというか。プログラム作成者の性って奴かもしれません。
そういった流れで処理を見直すと、結局は3つのパートに集約されるなぁと。

①ブートする

②機能を読みこんで遷移する

③試したい機能

流れとしてはこんな感じ。流れ図にするならこうかな。

この形は言うまでもなくOSの基本機能なわけですが、OSというほどたいそうなものを作りたいわけじゃありません。いわばモニタプログラムといったところでしょうか。

よく使う形を一般化して何度も使いまわせるようにするわけです。OSなんておこがましいささやかなものですが、名前がないと不便なのと、名前があると愛着がわくので、仮にHyfaxと名付けました。

今回からしばらくは、このHyfax君を作っていきたいと思います。

大雑把な方針とか

まずは媒体からです。QEMUを使うのは確定です。なので一般的なものとしてFDDとHDDがあります。ですが今更FDDはないだろうというわけでHDDの一択。

ファイルフォーマットはFATなのは当然です。フロッピーでないのでFAT12は没。FAT32は64Bit 演算ができないと辛いのでこれも没。まことに中途半端ながらFAT16で実行できるようにしましょう。

モニタプログラムは0x0ffffまでを占有することにします。アプリエリアは0x10000~0xA0000までの576KByteとしましょう。

モニタプログラムからアプリはjmpで遷移することにします。アプリからはモニタの先頭にjmpすることで復帰することにします。

モニタプログラムはアプリのファイル名を使ってディスクをリードし、0x10000に展開した後で同アドレスに遷移するものとします。

完全なシングルタスク・シングルユーザですね。だってモニタですもの、高機能は望みません。

忘れてましたけど、リアルモード厳守で行きます。拡張レジスタとか使わない方向で。

今日はここまで

大雑把な方針が決まったところで今日はここまでです。やってみなくてはわかりませんが都合6回くらいになるんじゃないでしょうか。

わたしの『やる気スイッチ』と連動しているので、次回がいつになるかはわかりません。

《2025/11/28 13:54:22》

📝 BIOSと戯れてみる♪(5)

今日のバグ:「読み込んだはずのセクタが全部 0x00 だった件」

今日は BIOS の int 0x13 を使ってディスクを読んでいたんですけど、
なぜか返ってくるバッファが全部 00 00 00 00 ...

いやいや、そんなわけないでしょう。
ダンプで見るとデータ入ってます。。
仕様の制限か?BIOS がサボってるのか?と思って、いろいろ調べてみました。

結論から言うと──
サボっていたのは BIOS じゃなくて『 わたし』でした。


■ まず疑ったのは「LBAの指定ミス」

セクタ 1 を読んでるつもりだったんです。
「いや、もしかして 0 で読んでる?」
と思ってコードを見返します。

mov word [DAP_LBA], 1

はい、ちゃんと 1 になってる。
LBA 1(つまりパーティション先頭)のはず。

なのに全ゼロ。

うーん。LBAが悪いわけじゃない。


■ 次に疑ったのは「ES:BX の指定ミス」

読み込み先のメモリだ。

これをミスると BIOS が ちゃんと読み込んでるのに
全然違う場所を見て「ゼロだ!」と思い込む典型的なパターン。

実際わたしは何度もやってる。

mov ax, 0x0000
mov es, ax
mov bx, 0x8000

問題なし。
……いや、ほんとに?


■ そして真犯人が登場

ES:BX でもなく
LBA でもなく
DAP の構造でもなく。

犯人は “デバイス番号 DL”

mov dl, 0x00

はい、FDD でした〜。

ひたすら HDD(0x80)だと思いこんで
ずっと 0x00(フロッピー)に読め読め言ってたら、
そりゃ BIOS も「そんなデバイスないし…」ってなる。

返ってくる AH はちゃんとエラーコード出してたのに、
わたしが見てなかっただけ。


■ 「見えてるようで見てない」ってやつ

メモリダンプのログも
読み込みコードも
全部「それっぽく」見えるのよね。

でも
“デバイス番号が 80 かどうかを見ない”
という基本を忘れてた。
ほんと初歩。

こういうときって、
「バグって難しい」とかじゃなくて
**“自分の思い込みの方が強い”**というのが原因だったりする。


■ 今日の学び

バグは複雑なところには潜んでない。
単純な場所に潜んでいる。

  • LBAが0か1か
  • ES:BXが本当にそこを指しているか
  • DLが0x80か
  • AHのエラーコードをちゃんと見るか

OS 自作や BIOS で遊んでると、
もっと難しい問題が出るように思えるけど、
実際は “基本の3つくらい” でだいたい片付きますね。


■ おまけ:

『記憶ではそうなっていてもコードは正直。ほれ、ほれほれ。』

宿敵『バグ』の嘲笑が聞こえるような一件でした。

BIOSと戯れてみる(4)

x86レガシーBIOSで遊んでみようというネタの4回目になります。
環境は以前と変わってWindows11+VSCode+WSLになります。

さて、拡張ディスクリードというBIOSコールがあるそうです。
なんでもシリンダ、ヘッダ、セクタの構成を気にしないで、セクタ番号だけでディスクを読み込めるとか。それは何気に嬉しいなぁ、というわけで試してみました。

拡張ディスクリード

拡張ディスクリードがどんなものかというと、DAP構造体とかいうものを使うそうです。DAP構造体に必要なパラメータを設定して実行すると、ディスクから読み込まれるらしいです。DAP構造体ってのは1バイト目が0x10固定、2バイト目が0固定……
説明するよりソース見た方が早いですかね。なのでソースです。

実行するとBIOS.BINの最初のセクタの冒頭がダンプされます。
で、DAP構造体です。

DAP構造体

内容というか意味はコメントである程度分かると思います。
size of packet : 16固定です。
reserved :0固定なのかな?
sectors to read :読み込むセクタ数
offset of load :データを読み込むバッファのアドレス
segment to load :データを読み込むバッファのセグメント
LBA :読み込み開始セクタ(0オリジン)

下4つを指定して読み込むわけですね。
今回は

sectors to read :1
offset of load :0x8000
segment to load :0x0000
LBA :0

ですから、ディスクの0セクタ目から1セクタ分を0x0x0000:8000に読み込むことになります。ディスクをダンプしてみて0x100000バイト目を読み込みたいときは1セクタ分の512で割って0x800セクタを読めばいいわけです。
いやぁ、楽です。ヘッダ・シリンダ・セクタを計算しないですむってホント楽です。

固定データだと、読み込む場所が変わるたびに構造体を用意しなければいけないんで面倒だし不合理です。せっかくなのでこの辺を可変にしてみましょう。

パラメータ指定

パラメータ指定する場合のサンプルコードはこちら。

キモというかポイントはこの部分。

ここで、DAPの位置から2バイト目にセクタ数、4バイト目にメモリオフセット、6バイト目にセグメント、8バイト目に開始セクタを指定しています。
実行すると第2セクタが読み込まれます。
これを少し修正すれば汎用のディスク読み込みルーチンができそうですね。

さて、今日はここまでです。お疲れさまでした。

《2025/11/02 07:56:23》

Debian 13 Trixieの各種設定

  1. IPアドレスの設定
    クライアントとしてのみ使うのであればDHCPでIPアドレスを配布してもらったほうが楽なんですが、リモートデスクトップとかSSHとかで外から接続する場合があるので固定IPは必須だったりします。
    なので、まずは何をおいてもIPアドレスの設定になります。
    アプリケーション→設定→高度なネットワーク設定


    Wired connection


    『IPv4設定』タブを選択します。


    アドレスを設定します。

  2. sudoユーザの設定
    自分のアカウントをsudoユーザにします。ルートになって作業するという危険な行為をしないようにですね。
    Debianではsudoグループに所属しているとsudoが使えるみたいです。
    なので一瞬だけrootになって、sudoグループにr-aikaを追加します。

    su -

    adduser r-aika sudo


    ログインしなおすと反映されるみたいです。

  3. リモートデスクトップ接続
    リモートデスクトップはxrdpをインストールすることで使えるようになります。
    なのでインストール。

    sudo apt-get update
    sudo apt-get install xrdp

    これだけだとxrdpのサーバが起動していないので起動させます。
    debianを再起動してもいいです。

    sudo systemctl enable xrdp
  4. ディスク拡張
    Linuxとか使っていてディスクがいっぱいになることが稀にあります。
    テラバイトのHDDとかが当たり前の昨今では、めったにないかもしれませんが、いっぱいになってしまうと、ものすごく切ないです。必死になって不要なファイルを削除しても焼け石に水だったり。
    「ディスク容量を増やすことが出来たら」と、本気で思う瞬間ですね。
    そんなわけで、インストールとは直接関係ないんですが、ディスク容量を増やしてみようと思います。
    いろんなシナリオが考えられるんですが、今回はわかりやすくHDDを追加する場合です。
    VMware Workstationの管理画面から『仮想マシンの設定の編集』に入ります。


    『追加』ボタンを押下します。


    『ハードディスク』を選択して『次へ』を押下。


    『SCSI』を選択して『次へ』を押下。


    『仮想ディスクの新規作成』を選択して『次へ』を押下。


    『ディスク最大サイズ』を設定して『次へ』を押下。


    ファイル名を確認して『完了』を押下。


    30GBのHDDが1台増設された形になります。


    仮想マシンを立ち上げてターミナルで確認します。
    もともと存在した10GB(/dev/sdb)の他に30GB(/dev/sda)のディスクがマウントされずに存在することがわかります。


    ここから先、詳しくはそれぞれ別途ググってください。
    追加した/dev/sdaを全て使って物理ボリューム(Physical Volume)を作成します。


    現在のボリュームグループ(volume group)の状況を確認します。
    ボリュームグループ名は『vd-mustang-base-vg』らしいです。


    作成した物理ボリュームの/dev/sdaをrootボリュームのボリュームグループ(Volume Group)に追加します。これで/dev/sdaの領域が論理ボリュームから使えるようになるはずです。


    論理ボリュームを見てみるとボリュームグループ内にrootとswap_1があるらしいです。容量を増やしたいのは当然rootですね。


    rootを追加した容量いっぱい使うように拡張します。


    ディスクの容量は増えましたが、ファイルシステムは変わってません。なので最後にファイルシステムをディスクいっぱい使うように拡張します。


    論理ボリュームを確認します。root領域が30GB増えているのが確認できます。


    以上となります。

    《2025/10/12 13:47》