LXF170:Дис­тро­ст­рой: сде­ла­ем са­ми

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Со­би­ра­ем ди­ст­ри­бу­тив Linux

Воо­ру­жась под­го­тов­лен­ны­ми ин­ст­ру­мен­та­ми, Дмит­рий Куз­не­цов за­вер­ша­ет де­ло по­строе­ния ми­ни­маль­но­го ди­ст­ри­бу­ти­ва Linux.

Наш эксперт Дмит­рий Куз­не­цов бо­лее 10 лет ве­дет не­рав­ный бой с мон­ст­ра­ми слож­но­сти, хо­тя не­ко­то­рые по­че­му-то их счи­та­ют вет­ря­ны­ми мель­ни­ца­ми.

На про­шлом уро­ке мы об­за­ве­лись ин­ст­ру­мен­та­ри­ем для сбор­ки ди­ст­ри­бу­ти­ва. Те­перь на­ста­ло вре­мя при­менить его на де­ле!

Сбор­ка ком­понен­тов

Вроде бы в Linux, где поч­ти все ПО от­кры­то, не долж­но быть ниче­го проще и стан­дарт­нее, чем со­би­рать ком­понен­ты ди­ст­ри­бу­ти­ва из ис­ход­ников. Увы, это не так. Де­та­ли сбор­ки мо­гут серьез­но от­ли­чать­ся от про­ек­та к про­ек­ту: раз­нятся ме­то­ды по­лу­чения ис­ход­но­го ко­да, фор­ма­ты ар­хи­вов, сис­те­мы кон­фи­гу­ри­ро­вания и т. д. К это­му сто­ит отнестись с пониманием – слиш­ком уж раз­но­об­раз­ны про­ек­ты, и по мас­шта­бу, и по на­зна­чению: от яд­ра со­вре­мен­ной ОС до мел­кой биб­лио­теч­ки, реа­ли­зую­щей все­го пару по­лез­ных функ­ций. Но ре­шае­мые при сбор­ке за­да­чи оди­на­ко­вы для лю­бо­го ПО. Это по­зво­ля­ет сфор­му­ли­ро­вать об­щую схе­му:

1 По­лу­чение ис­ход­ных ко­дов (на­при­мер, за­груз­ка ар­хи­ва).

2 Под­го­тов­ка ис­ход­ных ко­дов (на­при­мер, их рас­па­ков­ка в ра­бо­чий ка­та­лог).

3 Кон­фи­гу­ри­ро­вание (на­при­мер, за­пуск ./configure с нуж­ны­ми па­ра­мет­ра­ми).

4 Ком­пи­ля­ция (на­при­мер, за­пуск make).

5 Ус­та­нов­ка (на­при­мер, за­пуск make install).

Де­таль­ные ин­ст­рук­ции по сбор­ке кон­крет­но­го про­ек­та вы уз­наете толь­ко из его до­ку­мен­та­ции. Это един­ст­вен­но вер­ный путь!

За­груз­чик Grub

Са­мый из­вест­ный и раз­ви­тый за­груз­чи­к для ПК –Grub. Он ис­поль­зу­ет­ся боль­шин­ст­вом со­ве­мен­ных ди­ст­ри­бу­ти­вов Linux, в том чис­ле и Ubuntu. Соберем его, действуя по нашей схеме.

1 Ис­ход­ные ко­ды Grub мож­но за­гру­зить с сай­та gnu.org в ви­де ар­хи­ва в фор­ма­те tar.xz: wget -nd -P /root/work/download/ ftp://ftp.gnu.org/gnu/grub/grub-1.99.tar.xz.

2 В дан­ном слу­чае тре­бу­ет­ся толь­ко рас­па­ко­вать ар­хив в ра­бо­чий ка­та­лог:

tar -C /root/work/src -xvf /root/work/download/grub-1.99.tar.xz

cd /root/work/src/grub-1.99/

3 Скон­фи­гу­ри­ро­вать Grub про­сто: за­дайте нуж­ный ком­пи­ля­тор C в пе­ре­мен­ной ок­ру­жения CC и за­пустите скрипт configure с па­ра­мет­ром prefix, ука­зывающим ка­та­лог для уста­нов­ки (обыч­но /usr).

На беду, у ключа prefix в Grub двой­ное на­зна­чение: во-первых, он указывает ме­сто уста­нов­ки (ка­та­лог, ку­да скла­ды­вать ре­зуль­та­ты сбор­ки по ко­ман­де make install); а во-вторых, ком­понен­ты Grub ищут друг дру­га по это­му пу­ти, ра­бо­тая в со­ста­ве ди­ст­ри­бу­ти­ва. Итак, по­лу­ча­ется два ва­ри­ан­та сбор­ки. Пер­вый ва­ри­ант:

» При сбор­ке ука­зы­ва­ем prefix=/root/work/src/_install_grub. Make install скла­ды­ва­ет ре­зуль­та­ты сбор­ки в /root/work/src/_install_grub (в /usr ниче­го не за­ти­ра­ет­ся). Но в фай­ло­вой сис­те­ме ди­ст­ри­бу­ти­ва мы вы­ну­ж­де­ны раз­мес­тить Grub то­же в /root/work/src/_install_grub (ина­че ком­понен­ты не смо­гут най­ти друг дру­га).

Ва­ри­ант дол­жен ра­бо­тать, но очень хо­чет­ся раз­мес­тить за­груз­чик в /usr. Вто­рой ва­ри­ант:

» При сбор­ке ука­зы­ва­ем prefix=/usr. Make install скла­ды­ва­ет ре­зуль­та­ты сбор­ки в /usr, за­ти­рая сис­тем­ный Grub.

Тут уж со­всем все пло­хо. По­это­му пред­ла­га­ет­ся путь, со­вме­щаю­щий досто­ин­ст­ва обо­их ва­ри­ан­тов:

» Бе­рем два де­ре­ва ис­ход­ных ко­дов Grub.

» В пер­вом де­ре­ве со­би­ра­ем Grub с prefix=/usr (толь­ко make install не де­ла­ем), во вто­ром де­ре­ве со­би­ра­ем Grub с prefix=/root/work/src/_install_grub (make install то­же не де­ла­ем).

» В пер­вом де­ре­ве за­ме­ня­ем все Makefile’ы на со­от­вет­ст­вую­щие из вто­ро­го де­ре­ва и вы­зы­ва­ем make install.

По­лу­ча­ем: make install скла­ды­ва­ет ре­зуль­та­ты сбор­ки в /root/work/src/_install_grub, но в фай­ло­вой сис­те­ме ди­ст­ри­бу­ти­ва мы мо­жем раз­мес­тить за­груз­чик в /usr.

Кон­фи­гу­ри­ро­вание с клю­чом prefix=/usr:

CC=/root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-cc ./configure --prefix=/usr

4 Командуем CC=/root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-cc make.

5 Итак, до це­ли – один шаг. Ос­та­лась од­на про­бле­ма, об­ход­ной путь для ре­шения ко­то­рой был обе­щан в раз­де­ле «На­строй­ка». Как уста­но­вить Grub, скон­фи­гу­ри­ровн­ный с клю­чом prefix=/usr, в ка­та­лог /root/work/src/_install_grub? Обыч­ная ко­ман­да make install уста­но­вит его в /usr и за­трет фай­лы сис­тем­но­го за­груз­чи­ка.

Порас­су­ж­даем ло­ги­че­­ски. Суть уста­нов­ки в про­стом ко­пи­ро­вании фай­лов в нуж­ный ка­та­лог. Вся ло­ги­ка это­го со­сре­до­то­че­на в Makefile’ах. Значит, нуж­но их от­кор­рек­ти­ро­вать должным об­ра­зом. Но при кон­фи­гу­ри­ро­вании с клю­чом prefix=/root/work/src/_install_grub нуж­ные Makefile’ы соз­да­ют­ся ав­то­ма­ти­че­­ски. Ис­поль­зо­вание их при уста­нов­ке ре­ша­ет по­став­лен­ную за­да­чу.

Соз­да­дим Makefile’ы для уста­новки Grub в локаль­ный ка­та­лог:

mkdir /root/work/src/grub-1.99_temp/

tar -C /root/work/src/grub-1.99_temp/ -xvf /root/work/download/grub-1.99.tar.xz

cd /root/work/src/grub-1.99_temp/grub-1.99/

CC=/root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-cc ./configure –prefix=/root/work/src/_install_grub

За­меним Makefile’ы (их всего шесть) в основ­ном де­ре­ве ис­ход­ных ко­дов. Мож­но ко­пи­ро­вать по од­но­му вруч­ную, но удобнее сделать это из ко­ман­дной строки:

cd /root/work/src/grub-1.99_temp

find ./grub-1.99/ | grep «Makefile$» | xargs -I {} -t cp --remove-destination {} .{}

На­ко­нец-то мож­но ус­та­но­вить Grub в ло­каль­ный ка­та­лог:

cd /root/work/src/grub-1.99/

make install

Действительно, в ка­та­ло­ге /root/work/src/_install_grub лежит го­то­вый за­груз­чик.

Описанный трюк с за­ме­ной Makefile’ов не стоит считать универ­саль­ным прие­мом. Нет никаких гарантий, что он сра­бо­тает для дру­го­го ПО или да­же дру­гих вер­сий Grub.

Яд­ро Linux

1 Ис­ход­ные ко­ды яд­ра уже за­гру­же­ны, о чем за нас по­за­бо­тил­ся crosstool-ng. Ар­хив в фор­ма­те tar.xz ле­жит здесь: /root/work/download/linux-3.2.25.tar.xz.

2 Нуж­но рас­па­ко­вать ар­хив в ра­бо­чий ка­та­лог:

tar -C /root/work/src/ -xvf /root/work/download/linux-3.2.25.tar.xz

cd /root/work/src/linux-3.2.25/

3 Во-пер­вых, в фай­ле Makefile корнево­го ка­та­ло­га ис­ход­ных ко­дов нуж­но уста­но­вить зна­чения пе­ре­мен­ных ARCH и CROSS_COMPILE (стро­ки 195 и 196) сле­дую­щим об­ра­зом:

ARCH ?= x86_64

CROSS_COMPILE ?= /root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-.

Пер­вая оп­ре­де­ля­ет це­ле­вую ар­хи­тек­ту­ру со­би­рае­мо­го яд­ра. Вто­рая на­страи­ва­ет сис­те­му сбор­ки на применение нуж­но­го ин­ст­ру­мен­та­рия, пу­тем до­бав­ления ее зна­чения как пре­фик­са при вы­зо­ве ин­ст­ру­мен­тов сбор­ки. На­при­мер, в дан­ном слу­чае имя ком­пи­ля­то­ра из cc пре­вра­тит­ся в /root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-cc. От­ре­дак­ти­ро­вать Makefile мож­но вруч­ную в лю­бом тек­сто­вом ре­дак­то­ре или с по­мо­щью команд:

sed -i 's/^ARCH.*?=.*$/ARCH ?= x86_64/' ./Makefile

sed -i 's/^CROSS_COMPILE.*?=.*$/CROSS_COMPILE ?= \/root\/work\/files\/toolchain\/result\/bin\/x86_64-unknown-linux-gnu-/' ./Makefile

Во-вто­рых, нуж­но соз­дать файл .config, с по­мо­щью ко­то­ро­го за­да­ет­ся кон­фи­гу­ра­ция яд­ра Linux. К сча­стью, в ис­ход­ных ко­дах для ка­ж­дой из под­дер­жи­вае­мых ар­хи­тек­тур есть при­ме­ры кон­фи­гу­ра­ций. Как и в слу­чае с crosstool-ng, удоб­но взять один из них за осно­ву, а за­тем немно­го под­кор­рек­ти­ро­вать в слу­чае необ­хо­ди­мо­сти. Но здесь не при­дет­ся ис­кать нуж­ный файл настройки в де­ре­ве ис­ход­ных ко­дов и ко­пи­ро­вать его вруч­ную. Для это­го есть спе­ци­аль­ная ко­ман­да make defconfig.

Она соз­даст файл .config в те­ку­щем ка­та­ло­ге на осно­ве стан­дарт­ной кон­фи­гу­ра­ции для дан­ной ар­хи­тек­ту­ры, ко­то­рая уже бы­ла за­да­на ранее в пе­ре­мен­ной ARCH.

Для из­менения кон­фи­гу­ра­ции яд­ра Linux слу­жит спе­ци­аль­ная ин­те­рак­тив­ная сис­те­ма, по­хо­жая на ту, что ис­поль­зу­ет­ся в crosstool-ng. За­пустить ее мож­но командой make menuconfig.

Пра­вок все­го три.

» В раз­де­ле Processor type and features вклю­чи­те Build-in kernel command line, а за­тем в Build-in kernel command string вве­ди­те root=/dev/sda1 rootfstype=ext4. Эта стро­ка опи­сы­ва­ет па­ра­мет­ры, ко­то­рые яд­ро бу­дет ис­поль­зо­вать при за­груз­ке. Здесь доста­точ­но ука­зать рас­по­ло­жение и тип корневой фай­ло­вой сис­те­мы.

» Как вид­но из пре­ды­ду­ще­го пунк­та, ис­поль­зу­ет­ся фай­ло­вая сис­те­ма ext4, по­это­му ее нуж­но вклю­чить: раз­дел File systems, па­ра­метр The Extended 4 (ext4) filesystem.

» В раз­де­ле Kernel hacking от­клю­чи­те Stack utilization instrumentation. Это из­ба­вит от на­зой­ли­вых со­об­щений о со­стоянии сте­ка. Они бывают по­лез­ны при от­лад­ке, но иначе толь­ко раз­дра­жа­ют.

Ос­та­лось за­крыть сис­те­му кон­фи­гу­ри­ро­вания (два­ж­ды на­жать Esc), со­гла­сив­шись с со­хранением из­менений в фай­ле .config. Кон­фи­гу­ра­ция яд­ра го­то­ва.

4 Ком­пи­лируем: make.

5 Го­то­вый об­раз яд­ра Linux п­ре­дстав­ля­ет со­бой един­ст­вен­ный файл /arch/x86/boot/bzImage, по­это­му уста­нов­ка не тре­бу­ет­ся.

При­клад­ное ПО и init

При­клад­ных про­грамм ве­ли­кое мно­же­ст­во. Да­же ес­ли ог­раничить­ся лишь основ­ны­ми ути­ли­та­ми команд­ной стро­ки, тра­ди­ци­он­ны­ми для лю­бо­го ди­ст­ри­бу­ти­ва Linux, опи­сание их сбор­ки за­ня­ло бы не один де­ся­ток страниц. К сча­стью, есть пре­крас­ный про­ект busybox. Он реа­ли­зу­ет функ­цио­наль­ность init, shell и еще бо­лее чем 300 про­грамм команд­ной стро­ки Linux. Да­же уди­ви­тель­но, что все это уме­ща­ет­ся в единствен­ном ис­пол­няе­мом фай­ле объемом 2,5 МБ. Не­ко­то­рые про­грам­мы слегка уре­за­ны – например, мо­жет от­сут­ст­во­вать под­держ­ка некоторых па­ра­мет­ров. Но на­до быть уж очень боль­шим фа­на­том кон­со­ли, что­бы ощу­щать эти неудоб­ст­ва. Оче­вид­но, что в дан­ном слу­чае вполне ра­зум­но ис­поль­зо­вать busybox. Не­об­хо­ди­мо толь­ко сде­лать два за­ме­чания:

» Син­так­сис фай­ла inittab, необ­хо­ди­мо­го для init, в busybox немно­го от­ли­ча­ет­ся от его клас­си­че­­ско­­го ана­ло­га.

» Ути­ли­та grep из busybox не уст­раи­ва­ет один из ск­риптов в Grub. Ис­сле­до­вания по­ка­за­ли, что все де­ло в па­ра­мет­ре -x. По­это­му grep при­дет­ся со­брать от­дель­но. Воз­мож­но, в бу­ду­щих вер­си­ях busybox эта про­бле­ма бу­дет ис­прав­ле­на.

1 Ис­ход­ные ко­ды busybox мож­но за­гру­зить с сай­та про­ек­та в ви­де ар­хи­ва в фор­ма­те tar.bz2: wget -nd -P /root/work/download/ www.busybox.net/downloads/busybox-1.20.2.tar.bz2.

2 Рас­па­ков­ка ар­хи­ва в ра­бо­чий ка­та­лог:

tar -C /root/work/src/ -xjvf /root/work/download/busybox-1.20.2.tar.bz2

cd /root/work/src/busybox-1.20.2/

На сай­те про­ек­та для ка­ж­дой вер­сии busybox мож­но най­ти пат­чи (на мо­мент на­пи­сания ста­тьи для вер­сии 1.20.2 был досту­пен толь­ко один), ко­то­рые же­ла­тель­но за­гру­зить и при­менить к рас­па­ко­ван­ным ис­ход­ным ко­дам:

wget -nd -P /root/work/download/ www.busybox.net/downloads/fixes-1.20.2/busybox-1.20.2-kernel_ver.patch

patch -p1 </root/work/download/busybox-1.20.2-kernel_ver.patch

3 Кон­фи­гу­ри­ро­вание busybox и яд­ра Linux ана­ло­гич­ны: взять стан­дарт­ную кон­фи­гу­ра­цию, от­крыть ин­те­рак­тив­ную сис­те­му кон­фи­гу­ри­ро­вания и из­менить несколь­ко па­ра­мет­ров:

make defconfig

make menuconfig

Как всегда, пра­вок немно­го.

» В раз­де­ле Busybox Settings > Build Options уста­но­вить па­ра­метр Building BusyBox as a static binary (no shared libs). Он оз­на­ча­ет, что busybox нуж­но со­брать в ви­де един­ст­вен­но­го ис­пол­няе­мо­го фай­ла. Все под­дер­жи­вае­мые про­грам­мы бу­дут реа­ли­зо­ва­ны в ви­де сим­во­ли­че­­ских ссы­лок на него.

» Там же, па­ра­мет­ру Cross Compiler prefix уста­но­вить зна­чение /root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-. Его смысл ана­ло­ги­чен пе­ре­мен­ной CROSS_COMPILE в яд­ре Linux.

» В раз­де­ле Network utilities > inetd от­клю­чить Support RPC services. Для сбор­ки с этим па­ра­мет­ром в ис­поль­зуе­мом ин­ст­ру­мен­та­рии не хва­та­ет за­го­ло­воч­ных фай­лов. По­сколь­ку эта воз­мож­ность не нуж­на, про­ще ее от­клю­чить, чем мо­дернизи­ро­вать ин­ст­ру­мен­та­рий.

Как и в слу­чае кон­фи­гу­ри­ро­вания яд­ра Linux, вый­дя из ин­те­рак­тив­ной сис­те­мы и со­гла­сив­шись с со­хранением из­менений в .config, по­лу­ча­ем го­то­вую кон­фи­гу­ра­цию busybox.

4 Ком­пи­ля­ция: make.

5 Ус­та­нов­ка: make install.

В од­ном из па­ра­мет­ров настройки мес­том уста­нов­ки был ука­зан ка­та­лог ./_install. Дей­ст­ви­тель­но, был соз­дан /root/work/src/busybox-1.20.2/_install с го­то­вым busybox.

Ос­та­лось со­брать grep. К сча­стью, это на­столь­ко про­сто, что не по­тре­бу­ет ника­ких по­яснений. Все бы про­грам­мы так со­би­ра­лись!

1 По­лу­чае­м ис­ход­ные ко­ды:

wget -nd -P /root/work/download/ ftp://ftp.gnu.org/gnu/grep/grep-2.10.tar.xz

2 Готовим ис­ход­ные ко­ды:

tar -C /root/work/src/ -xvf /root/work/download/grep-2.10.tar.xz

cd /root/work/src/grep-2.10/

3 Конфигурируем:

CC=/root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-cc ./configure --prefix=/root/work/src/_install_grep

4 Компилируем:

CC=/root/work/files/toolchain/result/bin/x86_64-unknown-linux-gnu-cc make

5 Ус­та­нав­ливаем: make install.

Ус­та­нов­ка вы­пол­не­на в ка­та­лог /root/work/src/_install_grep.

За­го­тов­ка корневой ФС из crosstool-ng

Как уже го­во­ри­лось ранее, в Linux всем при­клад­ным про­грам­мам необ­хо­ди­ма стан­дарт­ная биб­лио­те­ка язы­ка C. Без нее не об­хо­дит­ся ни один ди­ст­ри­бу­тив. К сча­стью, она вхо­дит в со­став на­ше­го ин­ст­ру­мен­та­рия, по­это­му с ее сбор­кой во­зить­ся не при­дет­ся, об этом уже по­за­бо­тил­ся crosstool-ng. Со­б­ран­ную для це­ле­вой плат­фор­мы вер­сию мож­но най­ти здесь: /root/work/files/toolchain/result/x86_64-unknown-linux-gnu/sysroot/. Как нетрудно до­га­дать­ся по на­званию, со­дер­жи­мое ка­та­ло­га sysroot слу­жит от­лич­ной за­го­тов­кой для корневой фай­ло­вой сис­те­мы но­вого ди­ст­ри­бу­ти­ва.

Минималь­ный на­бор стар­то­вых скриптов

Ка­та­лог /etc лю­бо­го со­вре­мен­но­го ди­ст­ри­бу­ти­ва Linux со­дер­жит море сложней­ших ск­риптов и фай­лов настройки. С виду ка­жет­ся, что ра­зо­брать­ся в них невоз­мож­но. Но сто­ит по­гру­зить­ся в изу­чение, как ста­нет яс­но, что боль­шин­ст­во из них от­ве­ча­ют за на­строй­ки некой при­клад­ной про­грам­мы. Нет про­грам­мы, нет и со­от­вет­ст­вую­щих фай­лов. Для минималь­но­го ди­ст­ри­бу­ти­ва, опи­сы­вае­мо­го в дан­ной ста­тье, хватит трех. И их со­дер­жи­мое так при­ми­тив­но, что по­яснения мо­гут по­ка­зать­ся из­лишними.

Создание рабочего каталога:

mkdir /root/work/files/etc_files

cd /root/work/files/etc_files

Са­ми фай­лы мож­но соз­дать в лю­бом тек­сто­вом ре­дак­то­ре или, как по­ка­за­но ни­же, с по­мо­щью ко­манд echo.

» Файл /etc/inittab, ко­то­рый кон­фи­гу­ри­ру­ет init.

echo '::sysinit:/etc/rcS' >> ./inittab

echo 'tty1::respawn:/bin/sh' >> ./inittab

echo 'tty2::respawn:/bin/sh' >> ./inittab

echo 'tty3::respawn:/bin/sh' >> ./inittab

echo '::restart:/sbin/init' >> ./inittab

echo '::ctrlaltdel:/sbin/reboot' >> ./inittab

Смысл понятен, де­та­ли син­так­си­са прояснит до­ку­мен­та­ция.

» Файл /etc/rcS, ука­занный с inittab как стар­то­вый ск­рипт.

echo '#!/bin/sh' >> ./rcS

echo 'mount -av' >> ./rcS

echo 'mdev -s' >> ./rcS

echo 'echo «Hello, my micro linux!»' >> ./rcS

Этот обыч­ный ск­рипт команд­ной обо­лоч­ки вы­пол­ня­ет три дей­ст­вия:

> Мон­ти­ру­ет фай­ло­вые сис­те­мы, ука­зан­ные в фай­ле /etc/fstab.

> Соз­да­ет в ка­та­ло­ге /dev все необ­хо­ди­мые фай­лы уст­ройств. Здесь это де­ла­ет­ся с по­мо­щью про­грам­мы mdev из busybox, хо­тя в боль­ших ди­ст­ри­бу­ти­вах Linux обыч­но ис­поль­зу­ет­ся спе­ци­аль­ная сис­те­ма udev, ко­то­рая тре­бу­ет от­дель­ной сбор­ки и на­строй­ки.

> Вы­во­дит при­вет­ст­вие.

По­сколь­ку он бу­дет за­пускать­ся, дадим ему на это пра­ва:

chmod 777 ./rcS

» Файл fstab. Стро­го го­во­ря, он не обя­за­те­лен. Но труд­но удер­жать­ся от со­блаз­на все­го дву­мя строчка­ми по­лу­чить доступ к со­дер­жи­мо­му фай­ло­вых сис­тем proc и sysfs, ко­то­рые да­ют ог­ром­ное ко­ли­че­­ст­во по­лез­ной ин­фор­ма­ции о ра­бо­таю­щий сис­те­ме.

echo -e 'proc\t/proc\tproc\tdefaults\t0\t0' >> ./fstab

echo -e 'sysfs\t/sys\tsysfs\tdefaults\t0\t0' >> ./fstab

Все вме­сте

Итак, необ­хо­ди­мые ком­понен­ты го­то­вы. Ос­та­лось со­брать из них корневую фай­ло­вую сис­те­му бу­ду­ще­го ди­ст­ри­бу­ти­ва. Это дела­ет­ся про­стым ко­пи­ро­ванием по­лу­чен­ных ком­понен­тов в один ка­та­лог. Пер­вым де­лом нуж­но ско­пи­ро­вать за­го­тов­ку корневой фай­ло­вой сис­те­мы, соз­дан­ную crosstool-ng, в ра­бо­чий ка­та­лог:

cp -r /root/work/files/toolchain/result/x86_64-unknown-linux-gnu/sysroot/ /root/work/files/

Те­перь ту­да мож­но до­ба­вить все ос­таль­ные ком­по­нен­ты.

» Busybox

cp -r /root/work/src/busybox-1.20.2/_install/* /root/work/files/sysroot/

» Grep (про­грам­мы из па­ке­та grep долж­ны за­менить со­от­вет­ст­вую­щие сим­во­ли­че­­ские ссыл­ки busybox, по­это­му при ко­пи­ро­вании нуж­но ука­зать ключ remove-destination):

cp -r --remove-destination /root/work/src/_install_grep/* /root/work/files/sysroot/

» За­груз­чик Grub нуж­но ко­пи­ро­вать в ка­та­лог /usr, как бы­ло ука­за­но при сбор­ке:

cp -r /root/work/src/_install_grub/* /root/work/files/sysroot/usr/

» Стартовые скрипты и конфигурационные файлы

cp -r /root/work/files/etc_files/* /root/work/files/sysroot/etc

» Об­раз яд­ра Обыч­но рас­по­ла­га­ет­ся в ка­та­ло­ге /boot. Нуж­но соз­дать его и ско­пи­ро­вать ту­да bzImage, пе­ре­име­но­вав в со­от­вет­ст­вии с тре­бо­ва­ния­ми Grub в vmlinuz-3.2.25:

mkdir /root/work/files/sysroot/boot

cp /root/work/src/linux-3.2.25/arch/x86/boot/bzImage /root/work/files/sysroot/boot/vmlinuz-3.2.25

Ос­та­лось соз­дать пус­тые ка­та­ло­ги /proc, /sys и /dev для мон­ти­ро­ва­ния фай­ло­вых сис­тем и соз­да­ния фай­лов уст­ройств:

cd /root/work/files/sysroot/

mkdir proc sys dev

Корневая файловая система готова.

Запуск го­то­во­го ди­ст­ри­бу­ти­ва

Итак, можно считать, что дистрибутив Linux собран. На­до бы проверить его работоспособность и настроить загрузчик. Для этого нужено компьютер или раздел на жестком диске. Но свободный компьютер для экспериментов мало у кого найдется, а чтобы уверенно выполнять такие трюки на отдельном разделе жесткого диска своей рабочей машины, нужен немалый опыт. Идеальное решение – виртуальная машина (ВМ): делаешь все что угодно, а если что-то не вышло, всегда можно удалить файл с образом жесткого диска и попробовать еще раз. Ос­та­лось вы­брать эту ВМ.

Вир­ту­аль­ная ма­ши­на KVM

Тех­но­ло­гии вир­туа­ли­за­ции в по­следние го­ды до­воль­но бур­но раз­ви­ва­ют­ся, по­это­му вы­би­рать есть из че­го. Но вир­туа­ли­за­ция не яв­ля­ет­ся те­мой дан­ной ста­тьи, по­это­му хо­те­лось бы най­ти ре­шение по­про­ще. Тут внимание сра­зу при­вле­ка­ет KVM (Kernel Virtual Machine), ВМ яд­ра Linux. Она в яд­ре, а яд­ро уже есть; зна­чит, с ней будет мень­ше все­го про­блем. Здесь сле­ду­ет от­ме­тить, что по­пасть в яд­ро дав­но меч­та­ли все. Мно­гие го­ды шла из­ну­ри­тель­ная борь­ба за это «ме­сто под солн­цем». Но поя­ви­лась KVM – и в два сче­та обош­ла ста­рич­ков. По­бе­да, ви­ди­мо, бы­ла одер­жа­на ком­пакт­но­стью: для ра­бо­ты KVM доста­точ­но за­гру­зить один мо­дуль яд­ра и уста­но­вить QEMU для вир­туа­ли­за­ции вво­да/вы­во­да. Правда, такое ре­шение ра­бо­та­ет толь­ко на со­вре­мен­ных про­цес­со­рах Intel и AMD с ап­па­рат­ной реа­ли­зацией тех­но­ло­гии под­держ­ки вир­туа­ли­за­ции. Но эта про­бле­ма с ка­ж­дым го­дом те­ряет свое зна­чение. Про­ве­рить на­ли­чие у про­цес­со­ра данной функ­цио­наль­но­сти мож­но так (ес­ли вы­во­дит­ся ok, то под­дер­жи­ва­ет):

[ «`egrep '^flags.*(vmx|svm)' /proc/cpuinfo`» != “” ] && echo “ok”

Установить KVM просто:

apt-get install kvm qemu

Теперь загрузите нужный драйвер, и можно приступать к работе. Для процессоров AMD скомандуем modprobe kvm-amd, для процессоров Intel – modprobe kvm-intel. Ес­ли при за­груз­ке драй­ве­ра вы­да­ет­ся ошиб­ка Operation is not supported [Опе­ра­ция не под­дер­жи­ва­ет­ся], ве­ро­ят­но, в BIOS от­клю­че­на вир­туа­ли­за­ция.

Установка ОС

Пора разобраться в работе инсталлятора ОС. Непосвященным эта задача может показаться неподъемной. Уж очень большое впечатление производит программа, способная превратить груду микросхем в современный компьютер. Однако все эти чудеса обеспечиваются ПО, входящим в состав дистрибутива ОС, а процедура установки сводится к подготовке жесткого диска и простому копированию на него нужных файлов. Кто бы мог подумать, что таинственный образ инсталятора ОС так легко развенчать? Далее вся его работа будет подробно рассмотрена и проделана вручную.

Пер­вым де­лом ну­жен сам же­ст­кий диск, на ко­то­рый бу­дет уста­нав­ли­вать­ся ОС. Для ВМ его роль иг­ра­ет обыч­ный файл, на­зы­ва­емый об­ра­зом же­ст­ко­го дис­ка. Для ра­бо­ты с ними в QEMU есть спе­ци­аль­ная про­грам­ма. Вот как с ее по­мо­щью мож­но соз­дать об­раз же­ст­ко­го дис­ка раз­ме­ром 1 ГБ:

qemu-img create /root/work/files/sysroot.img 1G

Это об­раз са­мо­го про­сто­го ти­па (raw-фор­мат), то есть обыч­ный файл, за­полнен­ный ну­ля­ми. С та­ким же успе­хом для его соз­дания мож­но бы­ло бы восполь­зо­вать­ся ко­ман­дой dd.

Итак, диск есть. Как с ним ра­бо­тать? С ре­аль­ны­ми же­ст­ки­ми дис­ка­ми все бы­ло бы по­нят­но: в Linux они пред­став­ле­ны фай­ла­ми в ка­та­ло­ге /dev. А с об­раз­ами? Хо­ро­шо бы уметь и с ними ра­бо­тать ана­ло­гич­но. Это воз­мож­но с по­мо­щью тех­но­ло­гии се­те­во­го блоч­но­го уст­рой­ст­ва (Network Block Device, NBD). Она да­ет воз­мож­ность ра­бо­тать с уда­лен­ны­ми же­ст­ки­ми дис­ка­ми че­рез сеть TCP/IP. Сер­вер – ком­пь­ю­тер, ко­то­рый пре­достав­ля­ет доступ к сво­ему же­ст­ко­му дис­ку. На нем ра­бо­та­ет при­клад­ная сер­вер­ная про­грам­ма, принимаю­щая за­про­сы из се­ти и транс­ли­рую­щая их в локаль­ные дис­ко­вые опе­ра­ции. Кли­ент – ком­пь­ю­тер, же­лаю­щий по­лу­чить доступ к уда­лен­но­му же­ст­ко­му дис­ку. На нем яд­ро Linux (для это­го оно долж­но быть со­б­ра­но с па­ра­мет­ром CONFIG_BLK_DEV_NBD) соз­да­ет в ка­та­ло­ге /dev на­бор фай­лов nbdN, ко­то­ры­ми бу­дут пред­став­лять­ся уда­лен­ные дис­ки. Как все это по­мо­жет в ра­бо­те с об­раз­ами? В QEMU есть спе­ци­аль­ная про­грам­ма qemu-nbd, по­зво­ляю­щая пред­ста­вить об­раз же­ст­ко­го дис­ка вир­ту­аль­ной ма­ши­ны уда­лен­ным же­ст­ким дис­ком. Сле­до­ва­тель­но, мож­но под­клю­чить об­раз к фай­лу, на­при­мер, /dev/nbd0, и ра­бо­тать с ним как с обыч­ным же­ст­ким дис­ком. Ес­ли NBD в яд­ре Linux со­б­ра­на в ви­де мо­ду­ля (на­при­мер, так сде­ла­но в Ubuntu 12.04 LTS), нуж­но не за­быть его за­гру­зить:

modprobe nbd max_part=16

qemu-nbd -c /dev/nbd0 /root/work/files/sysroot.img

partprobe /dev/nbd0

Теперь с помощью обычных средств для разметки дисков можно создать разделы. В данном случае достаточно простейшего варианта: один большой первичный раздел, занимающий все доступное пространство. Нужно только учесть, что в начале диска необходимо оставить 32,3 КБ для установки загрузчика.

parted /dev/nbd0 mklabel msdos

parted -a cylinder /dev/nbd0 mkpart primary 32.3k 1024

parted /dev/nbd0 set 1 boot on

В ка­та­ло­ге /dev поя­вил­ся но­вый файл nbd0p1. Это и есть толь­ко что соз­дан­ный раз­дел. Для пол­ной го­тов­но­сти к ра­бо­те оста­лось толь­ко от­фор­ма­ти­ро­вать его. Ка­кую фай­ло­вую сис­те­му вы­брать? Лю­бую. Глав­ное, что­бы яд­ро при за­груз­ке смог­ло ее опо­знать и смон­ти­ро­вать корневую фай­ло­вую сис­те­му. Опи­сан­ная вы­ше кон­фи­гу­ра­ция яд­ра тре­бу­ет ext4:

mkfs.ext4 /dev/nbd0p1

Те­перь ту­да нуж­но за­пи­сать корневую фай­ло­вую сис­те­му. Как это сде­лать? Тут то­же все стан­дарт­но для поль­зо­ва­те­ля Linux: смон­ти­ро­вать раз­дел в ка­кой-нибудь ка­та­лог (на­при­мер, мож­но соз­дать для этой це­ли /root/work/files/mnt) и ско­пи­ро­вать ту­да нуж­ные фай­лы.

mkdir /root/work/files/mnt

mount -t ext4 /dev/nbd0p1 /root/work/files/mnt/

cp -r /root/work/files/sysroot/* /root/work/files/mnt

Об­раз го­тов. Ос­та­лось толь­ко под­чис­тить «хво­сты»: раз­мон­ти­ро­вать раз­дел, осво­бо­дить файл nbd0 и вы­гру­зить мо­дуль nbd.

umount /root/work/files/mnt/

qemu-nbd -d /dev/nbd0

modprobe -r nbd

Настройка загрузчика

По­следний штрих – на­стро­ить и уста­но­вить за­груз­чик. Ес­ли сей­час по­про­бо­вать за­гру­зить KVM с об­ра­зом же­ст­ко­го дис­ка sysroot.img, ниче­го не по­лу­чит­ся. BIOS безуспеш­но по­про­бу­ет най­ти за­груз­чик, по­сле че­го про­цесс за­груз­ки оста­но­вит­ся. Мож­но про­ве­рить: kvm -m 512 /root/work/files/sysroot.img.

Дей­ст­ви­тель­но, даль­ше бес­конеч­но­го со­зер­цания со­об­щения Booting from Hard Disk [За­гру­жа­ет­ся с же­ст­ко­го дис­ка]... про­дви­нуть­ся не по­лу­ча­ет­ся.

К сча­стью, у KVM есть сред­ст­во во­об­ще обой­тись без за­груз­чи­ка: па­ра­метр kernel. Он по­зво­ля­ет ука­зать внешний файл об­раза яд­ра Linux, вме­сто то­го, что­бы до­ве­рять его по­иск за­груз­чи­ку на же­ст­ком дис­ке вир­ту­аль­ной ма­ши­ны:

cp /root/work/src/linux-3.2.25/arch/x86/boot/bzImage /root/work/files/bzImage

kvm -m 512 /root/work/files/sysroot.img -kernel /root/work/files/bzImage

За­гру­зи­лась! Поя­ви­лось при­гла­шение команд­ной стро­ки. Те­перь мож­но на­стро­ить Grub, что­бы в дальней­шем об­хо­дить­ся без внешнего яд­ра (внимание! Сле­дую­щие ко­ман­ды да­ют­ся в ОС, ко­то­рая за­пу­ще­на на KVM):

/usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg

/usr/sbin/grub-install /dev/sda

sync

Итак, за­груз­чик на­стро­ен, мож­но за­крыть вир­ту­аль­ную ма­ши­ну (про­сто за­крыть ок­но, ко­ман­да sync не даст по­те­рять дан­ные) и по­про­бо­вать за­пустить ее без па­ра­мет­ра kernel:

kvm -m 512 /root/work/files/sysroot.img

Загружается с жесткого диска!

Заключение

Спасибо всем, кто дочитал до конца. Хочется верить, что труд, вложенный в написание этой статьи, не пропал даром. Надеюсь, многие узнали что-то новое про внутреннее устройство Linux и стали чувствовать себя более уверенно в работе с любым дистрибутивом. А это, в свою очередь, послужит надежным фундаментом для поддержания интереса и дальнейшего углубления в удивительный и захватывающий мир открытого ПО. Кроме того, дистрибутив, сборка которого подробно описана в статье, не так уж бесполезен, как может показаться на первый взгляд. Например, он может служить прекрасным испытательным полигоном для экспериментов с ядром Linux. |