path: root/markup/pod/live-manual/media/text/ja/user_basics.ssi

:B~ 基本

1~the-basics 基本

この章ではビルドプロセスの概要と最も広く利用されている3種類のイメージの使用手順について簡単に述べます。最も汎用性の高い形式のイメージである
#{iso-hybrid}#
は、仮想マシンや光学メディア、USBポータブルストレージ機器上で利用できます。特に変わった状況では後述のように、#{hdd}#
形式の方が適するかもしれません。この章では #{netboot}#
形式のイメージをビルド、利用する手順を記載しています。この形式はサーバ上で必要とする準備のためにやや複雑になります。これは netboot
についてまだ不慣れな人にとってはわずかに高度な話題となりますが、その準備さえできればローカルネットワーク上でブートするためのイメージをテスト、展開するのに非常に便利な方法で、難なくイメージのメディアを扱うことができるため、ここに収録しています。

この節は {ウェブブート}#webbooting
の簡単な手引きで終えています。これは恐らく異なる目的の異なるイメージを必要に応じて切り替えて使う最も簡単な方法で、手段としてインターネットを使います。

この章全体を通して、live-build
により作成されるデフォルトのファイル名を頻繁に参照しています。{ビルド済みイメージをダウンロード}#downloading-prebuilt-images
した場合、実際のファイル名は異なる場合があります。

2~what-is-live Live システムとは何?

Live システムとは、 通常 CD-ROM
やUSBメモリ等の取り外し可能メディア、あるいはネットワークからコンピュータ上でブートされるオペレーティングシステムを意味し、普通のドライブに何もインストールせずに利用でき、実行時に自動設定が行われます
({用語}#terms 参照)。

Live システムはオペレーティングシステムで、サポートしているうちの単一のアーキテクチャ (現在 amd64 と i386)
向けにビルドされています。以下から構成されています。

_* *{Linux カーネルイメージ}*、通常 #{vmlinuz*}# という名前です

_* *{初期 RAM ディスクイメージ (initrd)}*: Linux ブート用に用意された RAM
ディスクで、システムのイメージをマウントするのに必要となる可能性があるモジュールとマウントするためのスクリプトをいくつか収録しています。

_* *{システムイメージ}*: オペレーティングシステムのファイルシステムのイメージです。通常、Live
システムのイメージサイズを最小限にするため、SquashFS
圧縮ファイルシステムが利用されています。このファイルシステムは読み込み専用であることに注意してください。そのため、ブート処理中は Live
システムはRAMディスクと「ユニオン」機構を利用して実行中のシステム中でファイルを書き込むことができるようにしています。ただし、オプションの保持機能を使っていない限り、変更は全てシャットダウンにより失われます
({保持機能}#persistence 参照)。

_* *{ブートローダ}*:
選択したメディアからブートするように作られた短いコードの集合で、オプション/設定を選択できるプロンプトやメニューを恐らく提示します。Linux
カーネルとその initrd
を読み込んでそのシステムのファイルシステム上で実行します。前に言及した構成要素を収録する対象メディアやファイルシステムの形式によっては別の方法があります。isolinux
では ISO9660 形式のCDやDVDからのブート、syslinux ではHDDやUSBドライブの VFAT
パーティションからのブート、extlinux では ext2/3/4 や btrfs パーティション、pxelinux では PXE
netboot、GRUB では ext2/3/4 パーティション、等。

live-build を使って Linux カーネル、initrd、それを実行するためのブートローダを独自仕様で用意して全て1つのメディア特有の形式
(ISO9660 イメージやディスクイメージ等) でシステムのイメージをビルドできます。

2~downloading-prebuilt-images ビルド済みイメージのダウンロード

このマニュアルの対象は自分の Live
イメージの開発やビルドですが、使い方の手引き、あるいは自分でビルドする代わりにビルド済みイメージを簡単に試してみたいこともあるでしょう。{live-images
のgitリポジトリ}#clone-configuration-via-git と公式の安定版 (stable) リリースを使ってビルドされたイメージが
https://www.debian.org/CD/live/ で公開されています。さらに、古いものや今後のリリース、non-free
ファームウェアを収録する非公式のイメージ、あるいはドライバが http://live-systems.org/cdimage/release/
から利用できるようになっています。

2~using-web-builder ウェブ Live イメージビルダーの利用

コミュニティへのサービスとして、ウェブベースの Live イメージビルダーサービスを http://live-systems.org/build/
で運営しています。このサイトはベストエフォートの方針で保守されています。つまり、最新でいつでも使える状態の維持に努め、大規模な運用停止については問題を告知しますが、100%
いつでも使えることやイメージの高速なビルドを保証することはできず、サービスについて解決に時間を要する問題が時々あるかもしれないということです。サービスについて問題や疑問があれば、問題のあるビルドへのリンクを添えて{連絡}#contact
してください。

3~ ウェブビルダーの使い方と注意

ウェブインターフェイスでは現在、オプションの不正な組み合わせを避ける対策を何も取っていません。また、特に、変更すると通常ウェブフォームにある他のオプションのデフォルト値
(つまり live-build を直接使った場合の値)
が変わるオプションを変更した場合にウェブビルダーはそのデフォルト値を変更しません。最も顕著な例として、#{--architectures}#
をデフォルトの #{i386}# から #{amd64}# に変更すると対応するオプション #{--linux-flavours}# をデフォルトの
#{586}# から #{amd64}# に変更する必要があります。ウェブビルダーにインストールされている live-build
のバージョンやさらなる詳細については #{lb_config}# man ページを見てください。live-build
のバージョン番号はウェブビルダーのページ下部に記載されています。

ウェブビルダーにより提示される時間の推定は条件を考慮しない推定であり、実際にビルドにかかる時間を反映していないかもしれません。表示された後に更新もされません。それについては我慢してください。ビルド条件を送信した後にこのページを更新しないでください。更新すると同一のパラメータで再び新たにビルドを送信することになります。ビルドの通知をただの一度も受け取っておらず、十分な時間が確実に過ぎて、通知メールが自分の
spam メールフィルタに引っかかっていないことを確認した場合、{連絡}#contact してください。

ウェブビルダーがビルドできるイメージの種類は限定されています。これにより、利用や保守を簡単、能率的に維持できます。ウェブインターフェイスで提供されていない独自化を行いたい場合は、live-build
を使って自分のイメージをビルドする方法をこのマニュアルの残りで説明しています。

2~building-iso-hybrid 最初の段階: ISO hybrid イメージのビルド

イメージの種類を問わず、イメージをビルドするのに同一の基礎手順を毎回実行する必要があります。最初の例ではビルド用のディレクトリを作成して、このディレクトリに移動してから
live-build コマンドを以下の順で実行し、X.org のないデフォルトの Live システムを収録する基本的な ISO hybrid
イメージを作成します。このイメージはCDやDVDメディアへの書き込み、さらにUSBメモリへの複製にも適しています。

作業ディレクトリの名前は完全に自由ですが、live-manual
全体で利用されている例を参考にする場合、特に異なる種類のイメージについて作業、実験している場合、各ディレクトリで作業しているイメージの識別を支援する名前を使うのは良い方法です。ここではデフォルトのシステムをビルドするとして、例えば
live-default と呼びましょう。

code{

 $ mkdir live-default && cd live-default

}code

それから #{lb config}# コマンドを実行します。これにより他のコマンドが利用する「config/」階層を現在のディレクトリに作成します。

code{

 $ lb config

}code

上記のコマンドにはパラメータが渡されていないので、様々な選択肢についてそれぞれのデフォルト値が使われます。さらなる詳細については {lb config
コマンド}#lb-config を見てください。

これで「config/」階層ができました。#{lb build}# コマンドでイメージをビルドします。

code{

 # lb build

}code

コンピュータやネットワーク接続の速度により、このプロセスには少々時間がかかるかもしれません。完了すると、#{live-image-i386.hybrid.iso}#
イメージファイルが使える状態で現在のディレクトリにできているはずです。

*{注意:}* amd64 システムでビルドした場合は、出来上がるイメージの名前は #{live-image-amd64.hybrid.iso}# となります。マニュアル全体でこの慣例を採用していることに留意してください。

2~using-iso-hybrid ISO hybrid Live イメージの利用

ISO hybrid イメージをビルド、または https://www.debian.org/CD/live/
にあるものをダウンロードした後、通常は次にブート用メディアとして CD-R(W) や DVD-R(W) の光学メディアかUSBメモリを用意します。

3~burning-iso-image ISOイメージの実際のメディアへの書き込み

ISOイメージの書き込みは簡単です。/{xorriso}/ をインストールしてそれをコマンドラインから使ってイメージを書き込むだけです。例えば:

code{

 # apt-get install xorriso
 $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed live-image-i386.hybrid.iso

}code

3~copying-iso-hybrid-to-usb ISO hybrid イメージのUSBメモリへのコピー

#{xorriso}# で作られたISOイメージは #{cp}#
プログラムや同等プログラムを使って単純にUSBメモリにコピーすることができます。イメージファイルを置けるだけの十分に大きなサイズのUSBメモリを差し込んでそれがどのデバイスなのか決定します。以後
#{${USBメモリ}}# として参照します。これは例えば #{/dev/sdb}# といったUSBメモリのデバイスファイルで、例えば
#{/dev/sdb1}# といったパーティションではありません! USBメモリを差し込んでから #{dmesg}# か、もっと良いのは #{ls -l
/dev/disk/by-id}# の出力を見ると正しいデバイス名を調べることができます。

正しいデバイス名を得られたことを確信できたら #{cp}#
コマンドを使ってイメージをUSBメモリにコピーします。*{これを実行すると以前そのUSBメモリにあった内容は全て確実に上書きされます!}*

code{

 $ cp live-image-i386.hybrid.iso ${USBメモリ}
 $ sync

}code

*{注意:}* /{sync}/ コマンドはイメージのコピー中にカーネルによりメモリに記憶されているデータが全てUSBメモリに書き込まれたことを保証するのに有用です。

3~using-usb-extra-space USBメモリの空きスペースの利用

#{live-image-i386.hybrid.iso}# をUSBメモリにコピーすると、最初のパーティションは Live
システムで埋められます。残った空きスペースを利用するには、/{gparted}/ や /{parted}/
といったパーティション作業ツールを使ってそのUSBメモリに新しいパーティションを作成します。

code{

 # gparted ${USBメモリ}

}code

パーティションの作成後にはファイルシステムを作成する必要があります。選択肢には ext4 等があります。#{${パーティション}}#には例えば
#{/dev/sdb2}# 等パーティションの名前が入ります。

code{

 # mkfs.ext4 ${パーティション}

}code

*{注意:}* 余った容量を Windows で使いたい場合ですが、このOSでは最初のパーティション以外にアクセスすることは通常できません。この問題に対する解決策が{メーリングリスト}#contact でいくらか議論されていますが、簡単な解はないようです。

*{Remember: 新しい live-image-i386.hybrid.iso をUSBメモリにインストールする度に、パーティションテーブルがイメージの内容で上書きされるために USB メモリにあるデータは全て失われるので、追加パーティションをまずバックアップしてから、Live イメージの更新後に復帰させるようにしてください。}*

3~booting-live-medium Live メディアのブート

Live メディアCD、DVD、USBメモリ、あるいは PXE ブートでの初回ブート時に、そのコンピュータの BIOS
をまず設定する必要があるかもしれません。BIOS により機能やキーの割り当てが大きく異なるため、ここではそれについて深くは触れません。BIOS
によってはブートするデバイスのメニューをブート時に提示させるキー割り当てを提供しているものがあり、そのシステムでこれが利用できる場合は最も簡単な方法でしょう。それがない場合は
BIOS 設定メニューに入って Live システムのブートデバイスを通常のブートデバイスよりも前に配置するようにブート順を変更する必要があります。

メディアをブートするとブートメニューが表示されているでしょう。ここで単に enter を押すと、システムはデフォルトの項目 #{Live}#
とデフォルトのオプションを使ってブートします。ブートオプションのさらなる情報については、メニューの「ヘルプ」の項目や Live システム内にある
live-boot 及び live-config の man ページを見てください。

#{Live}# を選択してデフォルトのデスクトップ Live イメージをブートしたとして、ブートメッセージが流れた後、自動的に #{user}#
アカウントにログインし、デスクトップがすぐに使える状態で見えているはずです。{ビルド済みイメージ}#downloading-prebuilt-images
の #{standard}# 等コンソールだけのイメージをブートした場合はコンソールで自動的に #{user}#
アカウントにログインし、シェルプロンプトがすぐに使える状態で見えているはずです。

2~using-virtual-machine 仮想マシンを利用したテスト

Live イメージを仮想マシン (VM) 内で実行すると開発の面で大きな時間の節約になるかもしれません。これには注意事項がないというわけではありません:

_* VMの実行にはゲストOSとホストOSの両方に十分なRAMが必要で、CPUには仮想化をハードウェアでサポートしているものを推奨します。

_* VM上での実行には、例えばビデオ性能が低いこと、エミュレーするハードウェアの選択肢が限られていること等内在する制限がいくらかあります。

_* 特定のハードウェア向けの開発ではそのハードウェア自体での実行に代わるものはありません。

_* VMでの実行にのみ関連するバグが時々あります。その疑いがあるときはイメージをハードウェアで直接テストしてください。

こういった制約があることを理解した上で利用可能なVMソフトウェアを調べて要件に合うものを選択してください。

3~testing-iso-with-qemu QEMU でのISOイメージのテスト

Debian で最も汎用性の高いVMは QEMU です。プロセッサが仮想化をハードウェアでサポートしている場合は /{qemu-kvm}/
パッケージを使ってください。/{qemu-kvm}/ パッケージの説明に要件の簡単な一覧があります。

プロセッサがサポートしている場合はまず /{qemu-kvm}/ をインストールしてください。サポートしている場合は /{qemu}/
をインストールしてください。以下の例ではどちらの場合もプログラム名は #{kvm}# ではなく #{qemu}# とします。/{qemu-utils}/
パッケージもあると #{qemu-img}# で仮想ディスクのイメージを作成するのによいでしょう。

code{

 # apt-get install qemu-kvm qemu-utils

}code

ISOイメージのブートは簡単です:

code{

 $ kvm -cdrom live-image-i386.hybrid.iso

}code

詳細については man ページを見てください。

3~testing-iso-with-virtualbox VirtualBox でのISOイメージのテスト

/{virtualbox}/ でISOをテストするには:

code{

 # apt-get install virtualbox virtualbox-qt virtualbox-dkms
 $ virtualbox

}code

新しい仮想マシンを作成し、#{live-image-i386.hybrid.iso}# を CD/DVD
デバイスとして利用するようにストレージ設定を変更して仮想マシンを起動します。

*{注意:}* X.org を収録している Live システムを /{virtualbox}/ でテストしたい場合は live-build 設定に VirtualBox X.org ドライバパッケージ /{virtualboxbox-guest-dkms}/ 及び /{virtualboxbox-guest-x11}/ を収録するとよいでしょう。収録しない場合、解像度は 800x600 に限定されます。

code{

 $ echo "virtualbox-guest-dkms virtualbox-guest-x11" >> config/package-lists/my.list.chroot

}code

dkms
パッケージを機能させるためには、そのイメージで利用しているカーネルの種類のカーネルヘッダもインストールする必要があります。正しいパッケージの選択は上記で作成したパッケージ一覧に正しい
/{linux-headers}/ パッケージを手作業により列挙する代わりに live-build により自動的に行うことができます。

code{

  $ lb config --linux-packages "linux-image linux-headers"

}code

2~using-hdd-image HDDイメージのビルド及び利用

HDDイメージのビルドは全面的に ISO hybrid イメージのビルドと似ていて、#{-b hdd}# を指定することと出来上がりのファイル名が
#{live-image-i386.img}#
で光学メディアに書き込んで使うことができないという点が異なります。このイメージはUSBメモリやUSBハードドライブ、その他様々な他のポータブルストレージデバイスからのブートに適しています。通常、この目的には
ISO hybrid イメージを代わりに使えますが、BIOS が hybrid イメージを適切に処理できない場合はHDDイメージが必要となります。

*{注意:}* 前の例で ISO hybrid イメージを作成している場合 #{lb clean}# コマンド ({lb clean コマンド}#lb-clean 参照) で作業ディレクトリをきれいにする必要があります:

code{

 # lb clean --binary

}code

前と同様に #{lb config}# コマンドを実行します。今回はイメージの種類にHDDを指定する点が異なります:

code{

 $ lb config -b hdd

}code

それから #{lb build}# コマンドでイメージをビルドします:

code{

 # lb build

}code

ビルドが完了すると現在のディレクトリに #{live-image-i386.img}# ファイルができているはずです。

生成されたバイナリイメージには VFAT パーティションと syslinux
ブートローダが収録され、そのままUSB機器に書きこめます。繰り返しますがHDDイメージの使い方はUSBで ISO hybrid
イメージを使うのと同様です。{ISO hybrid Live イメージの利用}#using-iso-hybrid
の指示に従ってください。#{live-image-i386.hybrid.iso}# に代えて #{live-image-i386.img}#
をファイル名に使う点が異なります。

同様に、Qemu でHDDイメージをテストするには上記の {Qemu でのISOイメージのテスト}#testing-iso-with-qemu
で説明しているように /{qemu}/ をインストールしてください。それから #{kvm}# か #{qemu}#
のホストシステムで必要バージョンを実行し、最初のハードドライブとして #{live-image-i386.img}# を指定します。

code{

 $ kvm -hda live-image-i386.img

}code

2~building-netboot-image netboot イメージのビルド

以下の順でコマンドを実行すると X.org のないデフォルトの Live システムを収録する基本的な netboot
イメージを作成します。ネットワーク越しのブートに適しています。

*{注意:}* 前に示した例からどれかを実行した場合、作業ディレクトリを #{lb clean}# コマンドできれいにする必要があります:

code{

 # lb clean

}code

この特定の場合必要な段階の掃除が #{lb clean --binary}# では不十分です。netboot イメージのビルドで live-build
が netboot の準備を自動的に実行するにあたって異なる initramfs 設定が必要なことがその原因です。initramfs の作成は
chroot の段階で行われるため、既存のビルドディレクトリで netboot に切り替えるということは chroot
の段階も再ビルドするということになります。したがって、#{lb clean}# (これは chroot の段階も削除します) を使う必要があります。

#{lb config}# コマンドを以下のように実行してイメージを netboot 用に設定します:

code{

 $ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server "192.168.0.2"

}code

ISO及びHDDイメージとは対照的に netboot
自体ではクライアントに対してファイルシステムのイメージを提供しないため、ファイルをNFS経由で提供する必要があります。lb config
で異なるネットワークファイルシステムを選択することもできます。#{--net-root-path}# 及び #{--net-root-server}#
オプションはそれぞれ、ブート時にファイルシステムのイメージが置かれるNFSサーバの位置とサーバを指定します。ネットワークやサーバに合う適切な値がセットされていることを確認してください。

それから #{lb build}# コマンドでイメージをビルドします:

code{

 # lb build

}code

ネットワーク経由のブートでは、クライアントは通常イーサネットカードの EPROM にある小さなソフトウェアを実行します。このプログラムは DHCP
リクエストを送り、IPアドレスと次に行うことについての情報を取得します。次の段階は通常、TFTP
プロトコルを経由した高レベルブートローダの取得です。これには pxelinux や GRUB、さらには直接 Linux
のようなオペレーティングシステムをブートすることもできます。

例えば生成された #{live-image-i386.netboot.tar}# アーカイブを #{/srv/debian-live}#
ディレクトリに展開すると、#{live/filesystem.squashfs}# にファイルシステムのイメージ、カーネルや
initrd、pxelinux ブートローダが #{tftpboot/}# にあることがわかるでしょう。

ネットワーク経由でのブートをできるようにするにはサーバ上でサービスを3つ、DHCP サーバ、TFTP サーバ、NFSサーバを設定する必要があります。

3~ DHCP サーバ

ネットワーク経由でブートするクライアントシステムに対して確実にIPアドレスを1つ与え、PXEブートローダの位置を通知するようにネットワークの DHCP
サーバを設定する必要があります。

イメージしやすいように #{/etc/dhcp/dhcpd.conf}# 設定ファイルで設定する ISC DHCP サーバ
#{isc-dhcp-server}# 向けに書かれた例を示します:

code{

 # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server

 ddns-update-style none;

 option domain-name "example.org";
 option domain-name-servers ns1.example.org, ns2.example.org;

 default-lease-time 600;
 max-lease-time 7200;

 log-facility local7;

 subnet 192.168.0.0 netmask 255.255.255.0 {
   range 192.168.0.1 192.168.0.254;
   filename "pxelinux.0";
   next-server 192.168.0.2;
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.0.255;
   option routers 192.168.0.1;
}

}code

3~ TFTP サーバ

これはカーネルと初期RAMディスクをシステム実行時に提供します。

/{tftpd-hpa}/ パッケージをインストールすべきです。これはルートディレクトリ、通常 #{/srv/tftp}#
内にある全ファイルを提供できます。#{/srv/debian-live/tftpboot}# 内にあるファイルを提供させるには root で

code{

 # dpkg-reconfigure -plow tftpd-hpa

}code

を実行し、tftp サーバの新しいディレクトリについて聞かれたら回答します。

3~ NFSサーバ

ゲストコンピュータが Linux カーネルをダウンロード、ブートして initrd を読み込むと、NFSサーバ経由で Live
ファイルシステムのイメージをマウントしようとします。

/{nfs-kernel-server}/ パッケージをインストールする必要があります。

それから #{/etc/exports}# に

code{

 /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

}code

のような行を追記してファイルシステムのイメージをNFS経由で利用できるようにし、この新しいエクスポートについてNFSサーバに知らせます:

code{

 # exportfs -rv

}code

この3つのサービスの設定にはやや注意が必要かもしれません。全て協調して機能させるまでには忍耐がいくらか必要かもしれません。さらなる情報については
http://www.syslinux.org/wiki/index.php/PXELINUX にある syslinux wiki や
http://d-i.alioth.debian.org/manual/ja.i386/ch04s05.html にある Debian
インストーラマニュアルの TFTP ネットブート節を見てください。方法はとても似ているので手助けになるかもしれません。

3~ ネットワーク経由のブートをテストする方法

Netboot イメージの作成は live-build
により簡単になりましたが、イメージを実際のマシンでテストするのは本当に時間がかかるものとなるかもしれません。

日常を楽にするために仮想化を利用できます。

3~ Qemu

_* /{qemu}/、/{bridge-utils}/、/{sudo}/ をインストールします。

#{/etc/qemu-ifup}# を編集します:

code{

 #!/bin/sh
 sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
 echo "Executing /etc/qemu-ifup"
 echo "Bringing up $1 for bridged mode..."
 sudo /sbin/ifconfig $1 0.0.0.0 promisc up
 echo "Adding $1 to br0..."
 sudo /usr/sbin/brctl addif br0 $1
 sleep 2

}code

#{grub-floppy-netboot}# を取得またはビルドします。

「#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#」を引数にして #{qemu}# を実行します

2~webbooting ウェブブート

ウェブブートは手段としてインターネットを使い Live
システムをブートするための便利な方法です。ウェブブートの要件はとても少なくなっています。ある言い方をすれば必要なのはブートローダと初期RAMディスク、カーネルを収録したメディアです。別の言い方をすれば必要なのはファイルシステムを収録する
squashfs ファイルを置くウェブサーバです。

3~ ウェブブートファイルの取得

いつものように、イメージを自分でビルドすることも、プロジェクトのホームページ http://live-systems.org/
から取得できるビルド済みファイルを利用することも可能です。自身の必要に応じて微調整ができるまでの初期テストにはビルド済みイメージの利用が手軽でしょう。Live
イメージのビルド後ならウェブブートに必要なファイルは #{binary/live/}# 下のビルドディレクトリで見つけられるでしょう。ファイルは
#{vmlinuz}#、#{initrd.img}#、#{filesystem.squashfs}# と呼ばれます。

必要なファイルを既に存在するISOイメージから抽出することも可能です。そのためには以下のようにしてそのイメージをループバックマウントします:

code{

 # mount -o loop image.iso /mnt

}code

ファイルは #{live/}# ディレクトリで見つけられます。この例の場合は #{/mnt/live/}#
になります。この方法にはそのイメージをマウントするのに root
になる必要があるという欠点があります。しかしこれには簡単に定型処理、つまり自動化できるという利点があります。

しかし疑いようもなく、ISOイメージからファイルを抽出すると同時にウェブサーバにアップロードするのに最も簡単なのはミッドナイトコマンダーや /{mc}/
の利用でしょう。/{genisoimage}/
パッケージをインストールしていれば2ペインのファイルマネージャによりISOファイルの内容を確認しながらもう1つのペインではftp経由でファイルをアップロードできます。この方法は手作業の介入が必要とはなりますが
root 権限を必要としません。

3~ ウェブブートイメージの起動

ユーザによってはウェブブートのテストに仮想化を好みますがここでは以下の活用事例に合わせて実際のハードウェアについて言及します。あくまで例だと思ってください。

ウェブブートイメージの起動は上記で示した構成要素、つまり #{vmlinuz}# と #{initrd.img}# をUSBメモリの #{live/}#
ディレクトリ以下に書き込み、ブートローダとして syslinux をインストールすれば十分です。そしてUSBメモリからブートしてブートオプションに
#{fetch=URL/ファイル/への/パス}# を入力します。live-boot は squashfs
ファイルを取得してRAMに格納します。こうして、ダウンロードした圧縮ファイルシステムを普通の Live システムとして使えるようになります。例えば:

code{

 append boot=live components fetch=http://192.168.2.50/images/webboot/filesystem.squashfs

}code

*{活用事例:}* ウェブサーバがあり、squashfs ファイルが2つ、1つは例えば gnome のようなデスクトップ環境一式を収録したものともう1つは標準のものが置かれているとします。あるマシンでグラフィカル環境が必要であればUSBメモリを差し込んで gnome 用イメージをウェブブートできます。後者のイメージに収録されている何かのツールが別のマシン等で必要になった場合は標準的なイメージをウェブブートできます。