Как установить линукс без загрузчика

Загрузка GNU/Linux без стороннего загрузчика

В данной статье я приведу пример, как можно отказаться от использования стороннего загрузчика, будь то Grub или Lilo, если ваш компьютер поддерживает современный стандарт UEFI, пришедший на замену BIOS. Интересной особенностью будет то, что все работы проводим на уже установленной и рабочей системе.
По уровню сложности данная статья ориентирована на опытных пользователей Linux, т.к. некоторых моментов я касаюсь поверхностно, полагаясь на очевидность, чтобы не уходить от основной освещаемой темы.

Введение

Расскажу немного истории — являюсь пользователем Gentoo Linux уже более 5 лет, причем как основной и единственной ОС на всех используемых мною ноутбуках: Lenovo (от X61s до X1) и Apple MacBook Pro. Всегда при новой инсталляции использовал классический метод установки Gentoo на чистый жесткий диск, с использованием chroot. Таблицу партиций и загрузку системы настраивал дедовским способом, как завещал Handbook, на основе традиционного MBR.

Настройка ядра

Необходимо обеспечить поддержку загрузки с использованием UEFI в нашем ядре:

• CONFIG_EFI=y — включение поддержки стандарта UEFI
• CONFIG_EFI_STUB=y — включение возможности загружать ядро прошивкой UEFI, то что нам и надо
• CONFIG_EFI_VARS=y — включение интерфейса управления UEFI через переменные /sys/firmware/efi/vars/*, понадобится чтобы указать где искать ядро для загрузки, используется утилитой efibootmgr

При переходе на UEFI необходимо учесть то, что он не принимает параметры загрузки ядра, поэтому добавим все наши параметры в само ядро:

В примере используемые мною параметры, если говорить о необходимом минимуме, то хватит и указания где находится корневая файловая система:

После внесения указанных изменений компилируем и устанавливаем ядро по обычной процедуре. В Gentoo для этого есть очень удобный инструмент под названием genkernel. После сборки нам потребуется перезагрузить компьютер, т.к. некоторые новые параметры нам нужны для работы с прошивкой UEFI.

Тестирование

Для проверки работоспособности нашего ядра нужно попробовать загрузить ОС через UEFI, но чтобы не рисковать загрузочным разделом нашей рабочей системы, мы будем использовать usb-флешку, предварительно удалив с нее все разделы.

Подготовка

Для загрузки средствами UEFI нам потребуется особый раздел, который называется EFI Secure Partition или сокращенно ESP, на котором будет лежать всего один файл — это подготовленное нами ранее ядро с поддержкой UEFI. По своей сути это обычный GPT раздел с определенным типом и файловой системой FAT32.

Создание ESP-партиции

Для создание ESP-раздела нам потребуется пакет gptfdisk, информация из пакетной базы Gentoo:

Установить его можно выполнив команду с правами root’а:

Работа с данным инструментом почти ничем не отличается от всем знакомого fdisk. Допустим что наша usb-флешка определилась в системе как /dev/sdb и мы, конечно же, имеем права root’а. Выполняем следующие шаги:

В результате мы создали новую партицию sdb1 с типом ‘EFI System’ и размером 100 Мб, для тестирования этого вполне хватит. Теперь, как и с любой новой партицией, нам надо создать на ней файловую систему, в нашем случае это FAT32. Сделать очень просто — достаточно выполнить всего одну команду с правами root’а:

После выполнения команды, файловая система будет создана.

Копирование ядра

Монтируем новую партицию sdb1 в любой каталог и копируем туда наше подготовленное ядро, с включенным CONFIG_EFI_STUB и другими параметрами описанными выше (все команды выполнять с правами root’а):

Настройка BIOS

После подготовки тестовой usb-флешки необходимо перезагрузить компьютер и зайти в настройки BIOS и в разделе отвечающем за процесс загрузки выбрать использование UEFI. После чего загрузка системы должна пройти без каких-либо проблем, если ядро и флешка были подготовлены без ошибок. Тестирование можно считать пройденным и оставить систему загруженную с флешки.

Перенастройка загрузки на рабочей системе

По результатам пройденного выше теста, мы проверили что наше ядро корректно работает с прошивкой UEFI в нашем компьютере, поэтому приступим к миграции нашей рабочей системы на использование нового типа загрузки. Основная проблема в том что, система расположена на разделе созданном традиционной схемой разбиением на основе MBR (Master Boot Record), а для UEFI необходим GPT-раздел. Решается это проблема знакомым нам уже инструментом — gdisk из пакета sys-apps/gptfdisk. При первом запуске gdisk для нашего жесткого диска, пусть это будет /dev/sda, он предложит нам конвертировать таблицы разделов в формат GTP, предупредив о возможной потери данных. После чего проделаем все то что делали при создании usb-флешки, но с небольшими изменениями.
С учетом вышесказанного, план работ будет выглядеть следующим образом:

1. отключить загрузочный раздел
2. сделать резервную копию раздела
3. выполнить конвертацию MBR -> GPT
4. создать новую файловую систему на загрузочном разделе
5. подключить к точке монтирования и скопировать ядро
6. настроить прошивку UEFI
7. перезагрузить систему и проверить результат

Далее остановимся на каждом пункте более подробно.

Отключить загрузочный раздел

В большинстве случаев загрузочный раздел подключен в каталог /boot и имеет первый номер среди партиций блочного устройства, т.е. /dev/sda1, с учетом того, что sda это наш системный диск. В моей системе все именно так, поэтому выполняем следующую команду, с правами root’а:

Если данный каталог не используется какими либо приложениями, то он молча и без проблем отключиться от корня и мы сможем выполнить резервное копирование всей партиции /dev/sda1.

Резервное копирование загрузочного раздела

На данном этапе нам необходимо сделать резервную копию всего раздела, чтобы иметь возможность быстро откатить все изменения. В идеальном случае можно выполнить бекап всей системы, если у вас есть под рукой необходимые инструменты. Копирование партиции выполняется следующим образом, опять же под root’ом:

Проверим пригодность нашей резервной копии:

После выполнения команды ls мы должны увидеть содержимое каталога аналогичное тому, что было в рабочей системе до отключения точки монтирования /boot.

Выполнить конвертацию таблицы MBR -> GPT

Переходим к работе с утилитой gdisk. Весь процесс конвертации прост и требует минимум участия с нашей стороны. От нас необходимо запустить команду gdisk, сменить тип партиции sda1 на EF00 (EFI System) и сохранить изменения, т.е. процедура полностью аналогична той что мы делали с usb-флешкой, за исключением того что партиции уже созданы. После сохранения настроек, наша таблица будет переведена в новый формат, используемый GPT и пригодный для работы с UEFI.

Создать новую файловую систему на новом загрузочном GPT-разделе

По аналогии с процедурой создания usb-флешки, нам надо подготовить файловую систему FAT32 на нашем загрузочном разделе, теперь уже типа ‘EFI System’, выполнив команду:

После выполнения команды, файловая система будет создана.

Подключить sda1 и скопировать ядро

На данном этапе нам необходимо скопировать подготовленное ядро на новый раздел. Для этого выполните:

Подготовка загрузочного раздела на этом закончена.

Настроить прошивку UEFI

Для того чтобы UEFI мог передать управление нашему ядру, необходимо указать где оно находится. Настройкой параметров прошивки UEFi занимается инструмент под названием efibootmgr:

Его необходимо установить, выполнив команду:

После установки выполним настройку UEFI следующей командой:

Подробное описание всех параметров можно посмотреть в man-странице по efibootmgr. Мы используем следующие параметры:

• —create — создаем новую переменную в загрузчике
• —label ‘Gentoo-3.6.11’ — название которое будет отображаться в списке загрузочных устройств
• —loader ‘\bzImage.efi’ — путь к загрузчику, в нашем случае он встроен в ядро, путь абсолютный и с использованием «\»
• —part 1 — использовать первую партицию блочного устройства sda

После выполнения команды будет показан подробный вывод о том какие изменения в UEFI были внесены.

Перезагрузить систему и проверить результат

На этом вся настройка завершена и нам осталось перезагрузить систему, предварительно отключив usb-флешку, чтобы посмотреть как система загрузится без использования стороннего загрузчика.

После успешной загрузки системы, пакет загрузчика можно удалять:

На этом все и можно работать с системой.

Обновление ядра средствами genkernel

При обновлении ядра в будущем, с использованием инструмента genkernel, несколько изменится процедура, т.к. ядро больше не надо инсталлировать в /boot. Поэтому вместо ‘genkernel all’ необходимо выполнять ‘genkernel kernel’, предварительно поправив параметр в значение INSTALL=«no» в конфигурации /etc/genkernel.conf. После сборки ядра, его необходимо переименовать и вручную скопировать в каталог /boot.

Процесс обновления в итоге будет выглядеть следующим образом:

Итоги

Плюсы:

• отказались от одной прокладки в процессе загрузки ОС
• уменьшилось время загрузки системы
• изучили приемы работы с новым стандартом UEFI, пришедшему на смену BIOS

Источник

Установка Linux без .ISO и виртуализации

Создание файловой системы, установка и клонирование Debian и Ubuntu с помощью скриптов radish.

Обычно установка системы Linux производится путём запуска какой-либо программы-установщика, поставляемой разработчиками дистрибутива. Это производится либо непосредственно на компьютере, на котором производится установка, либо в какой-либо изолированной среде, например, используя виртуализацию. Описываемые ниже процедуры следуют этим принципам только в самом минимально необходимом виде. При создании образа системы какие-либо установщики сводятся к генератору минимальной системы debootstrap и интерфейсу менеджера пакетов apt (оба поверх менеджера пакетов dpkg), а вместо виртуализации используется chroot.

Установка образа диска на устройство производится минимальным скриптом, который вообще никак не использует установщик или менеджер пакетов, тем не менее создавая конфигурацию, полностью управляемую менеджером пакетов в образе диска — все установленные компоненты, включая загрузчик и ядро, могут обновляться и заменяться теми же действиями менеджера пакетов, которые бы использовались на системе, установленной стандартным установщиком дистрибутива.

Скрипты находятся на сервере Github и доступны по ссылке.

1.1. Ограничения

Скрипты разрабатывались для дистрибутивов Debian, Ubuntu и других, основанных на менеджере пакетов Debian. В принципе, нет каких-либо фундаментальных ограничений, которые бы препятствовали переносу тех же процедур на дистрибутивы, основанные на rpm, менеджере пакетов Red Hat или других, менее распространённых механизмах. Однако автору в первую очередь была необходима поддержка Debian и Ubuntu, и поэтому разработка велась именно в этом направлении.

Другое существующее ограничение связано с использованием механизма загрузки и разметки разделов диска MBR, а не более современного GPT. Это ограничивает размер загрузочного устройства 2 терабайтами и требует соответствующей конфигурации BIOS на устройствах архитектуры x86. Нет принципиальных ограничений, препятствующих поддержке GPT/UEFI, однако автор ставил себе целью создать простую конфигурацию, никак не привязанную к чему-либо за пределами загрузочного диска. На архитектуре x86, MBR при всех его недостатках и ограничениях обладает одним полезным свойством — если BIOS выбрал диск с MBR как загрузочное устройство, весь последующий процесс загрузки исключительно подконтролен цепочке стадий загрузчиков, находящихся на этом устройстве и получающих конфигурацию из файлов на этом же устройстве. Видимо, в будущем имеет смысл добавить поддержку GPT и UEFI — благо, проблемы с нестандартным поведением UEFI намного уменьшились на текущем поколении аппаратуры.

1.2. Процедура сборки образа диска, его модификации и установки на загрузочное устройство

Процедура установки состоит из двух стадий — создания образа диска и его установки на устройство. При этом каждое устройство, на котором установлен такой образ диска, становится загрузочным на компьютерах с архитектурой x86 (32-битной или 64-битной в зависимости от исходной сборки). Процедура установки образа файловой системы включает в себя создание уникальных идентификаторов (UUID) файловых систем, что помогает исключить путаницу во время загрузки и обновления системы, которая может произойти, если в момент загрузки к одному и тому же компьютеру окажутся подключены несколько устройств с идентичными разделами.

Корневая ( / ) и загрузочная ( /boot ) файловые системы идентифицируются в конфигурации GRUB и файле /etc/fstab по их UUID, чтобы избежать зависимости от наличия или порядка идентификации других устройств (накопителей и разделов). GRUB всегда читает собственную конфигурацию (BIOS всегда устанавливает загрузочный диск, содержащий первую стадию GRUB в MBR, «первым жёстким диском» при обращении через свои функции), конфигурация GRUB содержит UUID корневой файловой системы, передаваемый ядру через командную строку. Процесс загрузки использует этот идентификатор для определения устройства, монтируемого, как / , а затем с того же устройства читается файл /etc/fstab , из которого, также по UUID, определяется файловая система, которая монтируется как /boot, если это требуется (например, при обновлении ядра или загрузчика). Также UUID корневой файловой системы в /etc/fstab при этом гарантированно совпадает с UUID файловой системы, смонтированной как / (и содержащей сам этот файл). Если бы несколько подключённых устройств содержали одни и те же UUID файловых систем, вполне возможна была бы ситуация, когда после загрузки с одного из устройств, файловые системы были смонтированы с других устройств с теми же UUID. Если UUID уникальны, и каждое физическое устройство в конфигурации GRUB и /etc/fstab содержит ссылки на UUID собственных разделов, такая ситуация невозможна.

В целом, образы дисков и сами устройства с установленными на них скриптами radish файловыми системами рассчитаны на максимальную совместимость с аппаратурой и сохранение работоспособности в широком диапазоне возможных конфигураций при условии, что конфигурация аппаратуры и BIOS не препятствует традиционной (через MBR) загрузке с этих устройств.

При желании пользователь может распаковать образ диска, добавить файлы и пакеты, запустить распакованные образы диска под chroot, и собрать новый образ диска после этих изменений. Пользователь может также установить образ диска на устройство, загрузиться с него, использовать его обычным образом, а затем с помощью простой процедуры создать образ диска, который создаёт копии устройства в том состоянии, в котором его оставил на момент клонирования пользователь. При этом процедура установки остаётся неизменной, если пользователь не менял какие-либо фундаментальные механизмы (например, метод загрузки или аппаратную архитектуру).

1.3. Использование образа диска для восстановления с резервных копий и переноса работающей конфигурации на новую аппаратуру

Последнее позволяет решить проблему восстановления загрузочных устройств с резервных копий — достаточно создать образ диска с копии устройства, созданного таким способом, и запустить процедуру установки образа на устройство на устройстве, которое должно стать загрузочным. Как набор файлов, так и механизм загрузки после этой процедуры функционально будут копией устройства, с которого была сделана резервная копия. Совместимость с различными наборами аппаратуры позволяет полностью заменять аппаратуру при выходе из строя серверов или замене на новое оборудование, и получать работоспособную, загружаемую систему без какой-либо ручной конфигурации. При этом должно соблюдаться одно требование – хотя бы в одной из работоспособных конфигураций система должна быть загружаемой с одного диска, распознаваемого сохранённой конфигурацией операционной системы.

То есть, может оказаться, что образ диска с сервера, загружаемого с массива RAID, не сможет загрузиться после восстановления на совершенно другой конфигурации, требующей дополнительной настройки аппаратно и программно поддерживаемый массивов, разделов и логических томов. Для этого имеет смысл иметь хотя бы одно устройство с «простой» конфигурацией, содержащей MBR, разделы и файловые системы, и поддерживать на нём копию загружаемой системы даже если при обычной эксплуатации сервера оно не будет загрузочным устройством. Тогда после смены аппаратуры можно будет сначала запустить восстановленную копию этого устройства, и только затем, вручную или автоматически, восстановить оставшуюся часть конфигурации.

1.4. Создание образа диска для архитектур процессоров, отличающихся от архитектуры компьютера, на котором производится сборка

В данный момент radish не может полностью создать файловую систему для «чужой» архитектуры, однако может быть использована по частям для сборки исходного дерева каталогов для запуска на устройстве с требуемой архитектурой, и затем завершения процедуры сборки на этом устройстве (реальном или эмулируемом) до получения полностью работоспособной файловой системы.

Несмотря на то, что это наименее доработанная часть radish, она вполне пригодна для включения в скрипты для создания встроенного программного обеспечения различных устройств «с нуля» – требуется только добавить создание минимальной файловой системы для запуска radish (например, компиляцией системы на основе busybox), конфигурации загрузчика, и процедуры копирования файлов, созданных radish, на устройство (например, включением в загрузочную файловую систему, через ssh / scp, и т. п.).

2. Принцип действия

radish реализован в виде radish-build и radish-install, скриптов шелла bash, использующих небольшой набор утилит, входящих в минимальную конфигурацию Linux, плюс несколько утилит, специфичных для него. В самом radish есть список этих утилит. Для сборки файловой системы используются:

bzip2
cat
chroot
cut
dd
echo
fgrep
grep
kill
mktemp
mount
mv
pwd
readlink
rm
rmdir
sleep
umount
debootstrap
mkfs.ext4
fsck.ext4
resize2fs
partclone.ext4

radish проверяет их наличие при запуске, и завершается с ошибкой, если какие-либо из них отсутствуют. При этом делается предположение, что сами утилиты должны присутствовать даже если сам шелл их реализует как встроенные команды – подобное предположение позволяет избежать ошибок при смене версий и реализаций шелла, и соответствует типичной конфигурации современных дистрибутивов Linux, даже самых минимальных на базе Busybox.

Пять из этих файлов выполняют функции, специфичные для создания файловых систем с дистрибутивом Debian:

1. debootstrap . Это основной скрипт, выполняющий конфигурацию доступа к репозитории и установку базовых пакетов системы. Он хорошо поддерживается и обновляется при выпуске новых версий различных систем, совместимых с Debian. Также он распространяется в стандартных репозиториях многих дистрибутивов, не совместимых с Debian, и может запускаться под ними, создавая дерево каталогов, содержащее работоспособную систему, совместимую с Debian. Единственное требование для его работы – наличие аппаратуры, ядра и минимальной конфигурации Linux для соответствующей архитектуры, и доступ к репозитории.
2. mkfs.ext4 и fsck.ext4 . Эти утилиты создают и проверяют файловую систему EXT4, обычно используемую для загрузочных / корневых устройств для Linux. radish полностью работает под Linux’ом, поэтому EXT4, традиционно поддерживаемая всеми дистрибутивами и конфигурациями Linux, может использоваться для всех операций без какого-либо перевода форматов или копирования.
3. resize2fs . Эта утилита изменяет размер собранной файловой системы EXT2, EXT3 или EXT4. Во время сборки файловой системы изначально размер образа файловой системы выбирается с запасом. В конце сборки файловая система сжимается до минимального размера, и в таком виде переводится в формат partclone. При установке на устройство сначала устанавливается, с помощью partclone, этот образ файловой системы минимального размера, а затем эта файловая система расширяется до размера раздела на устройстве. Это позволяет избежать проблем при установке на устройства различного размера – образ всегда соответствует минимальному поддерживаемому размеру, определяемому общим размером установленных файлов (плюс неполные блоки, каталоги и метаданные), но после установки используется всё устройство.
4. partclone.ext4 . Утилита для копирования образа файловой системы в формате, позволяющем сохранять только блоки, занятые данными. Так как копирование происходит после сжатия файловой системы, вместо этой утилиты можно бы было использовать dd, однако, dd не может определить, является ли скопированный образ диска полным, а partclone выдаст ошибку, если по какой-либо причине файл оказался урезан.

Для установки используются:

bzip2
clear
cut
dd
echo
head
id
mount
sed
sleep
sort
stat
sync
tail
tempfile
umount
uniq
wc
xargs
blockdev
dialog
fsck.ext4
partclone.ext2
parted
resize2fs
tune2fs
blkid

В этом списке есть некоторые другие утилиты, также специфичные для операций, производимых этим скриптом:

1. blockdev . Эта утилита позволяет запрашивать операции ядра на блоковом устройстве, в данном случае перечитывание таблицы разделов.
2. dialog . Утилита, реализующая простой пользовательский интерфейс на текстовом экране. Используется для выбора устройства и ввода текста – имени машины, паролей.
3. parted . Утилита, создающая и редактирующая таблицу разделов диска. В данном случае используется только в режиме для формата с MBR, хотя также поддерживает и GPT.
4. tune2fs . Утилита, редактирующая параметры файловой системы. Используется для создания уникального идентификатора (UUID) для созданных файловых систем. После клонирования сохраняется исходный идентификатор, который должен быть заменён на новый, чтобы исключить возможность совпадения идентификаторов нескольких файловых систем, одновременно доступных на одном и том же компьютере.
5. blkid . Утилита, определяющая список блоковых устройств в системе и находящая их идентификаторы (метки и UUID).

2.1. Создание образа файловой системы

В основе работы radish находится создание дерева каталогов и файлов на файловой системе, находящейся на файле образа системы, который монтируется на локальном каталоге через блоковое устройство, на которое отображён этот файл ( /dev/loopn ). То есть, скрипт radish‑build создаёт файл, форматирует его как файловую систему, создаёт временный каталог, и под ним монтирует эту файловую систему. В этом каталоге сначала устанавливается минимальная система через debootstrap, а а затем она дополняется до минимально работоспособной конфигурации сервера или встраиваемой системы (набор пакетов может быть изменён пользователем, но для этого требуется редактирование скрипта). В таком работоспособном виде файловая система переводится в формат partclone и сжимается с помощью bzip2. После этого файловая система размонтируется, исходный файл образа и каталог удаляются, и остаётся сжатый файл в формате partclone, готовый к установке скриптом radish‑install.

При разработке radish стояла задача обеспечить возможность установки программного обеспечения из произвольно выбранных пакетов Debian. Пакеты Debian разрабатываются для установки на компьютере, на котором уже установлена полностью работоспособная система. Стадия конфигурации, заключительная стадия установки каждого пакета, запускается после установки всех пакетов, от которых зависит данный пакет, и может полагаться на их присутствие. Это условие всегда выполняется при установке на загруженной и работающей системе, однако, при работе radish невозможно гарантировать подобное поведение, потому что каталог, под которым смонтирован образ файловой системы, не является полным эквивалентом работающей системы Debian. Поэтому потребовались дополнительные меры, позволяющие временно создать среду, достаточно приближенную к работающему Debian на время установки пакетов, но «помещающуюся» в смонтированный каталог и после установки не оставляющую запущенных процессов, из-за которых этот каталог не может быть размонтирован. Как оказалось, в большинстве случаев для правильной установки пакетов достаточно:

1. Запускать все операции над смонтированным образом файловой системы под chroot.
2. Смонтировать специальные файловые системы /proc и /sys ( /dev работоспособен в том виде, в котором он создан при запуске debootstrap).
3. Переименовать /usr/sbin/invoke-rc.d (из SysV init) и /sbin/initctl (из upstart), если эти скрипты установлены в системе перед запуском установки и переименовать эти файлы обратно после завершения установки. Системы, использующие systemd, не требуют каких-либо изменений, потому что про такой процедуре установки systemd не находит собственный процесс и его интерфейсы под chroot – они запускаются только при «настоящей» загрузке системы.

Для полной гарантии того, что после установки пакетов не останется запущенных процессов, скрипт также включает в себя процедуру поиска процессов, запущенных под chroot (функция termprocesses() ). Файлы найденных процессов переименовываются (чтобы предотвратить автоматический перезапуск), процессы завершаются сначала сигналом TERM и переименовываются обратно. Если они не завершились через 5 секунд (предполагается, что процессы могут потратить некоторое время для восстановления состояния, удаления файлов, и т. п,), процедура повторяется с сигналом KILL, что приводит к немедленному завершению.

После завершения такой процедуры установки файловая система размонтируется, сжимается утилитой resize2fs, и переводится в формат partclone, сжатый bzip2. После создания файла в этом формате исходный файл с образом файловой системы и временный каталог удаляются.

Как аргумент командной строки radish-build принимает имя версии дистрибутива, например, «artful» для Ubuntu 17.10 или «stretch» для Debian 9. Скрипт создаёт файл root-image.bin .

2.2. Установка системы из образа на устройство

Скрипт radish-install устанавливает систему на устройство и конфигурирует это устройство для загрузки. Этот скрипт:

1. Интерактивно запрашивает устройство из списка пригодных для установки. Список устройств, пригодных для установки, создаётся из /sys/class/block/sd* исключением устройств, содержащих смонтированные разделы, находящихся вне ожидаемого диапазона размеров а также рассматриваемых операционной системой как фиксированные. Эти критерии (находящиеся в radish‑install после сканирования устройств по вышеупомянутой маске), видимо, во многих случаях потребуется изменить.
2. Создаёт два раздела: загрузчика и корневой файловой системы.
3. Форматирует файловую систему загрузчика.
4. Копирует подготовленный образ на корневую файловую систему, создаёт новые UUID для файловых систем.
5. Монтирует файловые системы, переносит каталог /boot с установленной корневой на файловую систему загрузчика.
6. Создаёт конфигурационные файлы /etc/fstab , /etc/inittab или /etc/init/ttyS0.conf , /etc/default/grub .
7. Устанавливает загрузчик GRUB на устройство, используя уже установленные файлы этого загрузчика из-под chroot. Только на этом этапе установки производится запись загрузчика системы в MBR и пространство до начала разделов, то есть, в те части устройства, которые не покрываются файловыми системами. При этом также устанавливаются файлы загрузчика на файловую систему, находящуюся в разделе загрузчика. Эти процедуры совершенно эквивалентны установке GRUB при последующих обновлениях, потому что производятся теми же программами, поставляемыми с пакетом GRUB. Различие лишь в том, что в данном случае они запускаются из-под chroot.
8. Размонтирует файловые системы.
9. Расширяет корневую файловую систему до размеров раздела устройства и монтирует её опять.
10. Запрашивает имя машины и пароли для предопределённых пользователей root и user, создаёт файл /etc/hostname и редактирует пароли пользователей с помощью утилиты chpasswd.
11. Размонтирует полученную корневую файловую систему и выполняет запись всех буферов на устройства.

После всех этих действий устройство может быть использовано для загрузки работоспособной системы Linux. Идентификаторы файловых систем соответствуют конфигурации GRUB и /etc/fstab , то есть, независимо от номеров и имён устройств для Linux или BIOS, процедура загрузки правильно распознает собственные файловые системы. После загрузки система может без каких-либо изменений обновляться менеджером пакетов Debian и использовать все утилиты, поддерживающие синхронизацию и обновление из удалённых репозиторий.

При желании (и наличии достаточного свободного места) можно скопировать в какой-либо каталог на это устройство сам radish и сжатый образ диска, из которого это устройство устанавливалось. В этом случае нужно дополнительно установить утилиты, используемые скриптами radish. Таким образом полученная система сможет далее создавать копии своего исходного состояния – это может быть удобно для распространения «образца» файловой системы с установленным программным обеспечением пользователям, которые далее смогут создавать собственные копии.

2.3. Изменение созданного образа файловой системы

После того, как файл образа файловой системы создан с помощью скрипта radish-build, может потребоваться установка и конфигурация программного обеспечения или каких-либо данных вручную. Файл образа сам по себе непригоден для редактирования, однако есть, как минимум, две возможности создать такой отредактированный образ:

2.3.1. Установка программного обеспечения на физическом устройстве с последующей подготовкой для клонирования

Файл образа файловой системы используется для установки полной загружаемой системы на устройстве, которое после этой установки используется для загрузки. После загрузки пользователь устанавливает и конфигурирует (и, если необходимо, тестирует) программное обеспечение так же, как он бы его устанавливал на обычном компьютере. Обновление пакетов и даже переход на новые версии дистрибутива при этом могут производиться обычными механизмами менеджера пакетов. При этом получается файловая система, содержащая необходимую конфигурацию.

Добившись желаемой конфигурации, пользователь перезагружает компьютер и подключает устройство с модифицированной файловой системой к тому же или другому компьютеру. Устройство становится доступным как то, что далее будет обозначаться как $TDEV . К примеру, устройство при этом получает имя /dev/sdb , в этом случае можно установить:

Пользователь временно переводит корневую файловую систему $2 в состояние, пригодное для клонирования. Для этого он монтирует файловые системы и копирует содержимое файловой системы загрузчика в каталог boot корневой файловой системы:

Затем файловая система сжимается до минимального размера:

(последняя операция может занять значительное время – сжатие может потребовать перемещение многих блоков внутри устройства).

Полученная файловая система переводится в формат partclone, сжатый bzip2:

Затем файловая система возвращается в исходное состояние:

После всех этих действий файловая система возвращается в исходное состояние, а файл root‑image.bin содержит образ файловой системы, пригодный для установки.

2.3.2. Работа с распакованной файловой системой

При необходимости можно не устанавливать и не загружать систему, а распаковать образ в файл, отображаемый на блоковое устройство /dev/loopn , а затем после изменения перевести файловую систему в формат partclone, сжатый bzip2. Для этого есть скрипты radish-unpack-image и radish-pack-image. Они создают каталог и смонтированный под ним образ файловой системы.

Для работы с этими каталогами можно смонтировать под ними /proc , /sys и /dev . После распаковки файла скриптом radish-unpack-image (например, файл radish‑image‑bbbbbbbbbb в каталог radish‑mount‑aaaaaaaaaa ):

(файл распаковывается, скрипт выдаёт имена созданного файла и каталога)

(далее следует работа под chroot)

(происходит выход из-под chroot)

Затем можно перевести файловую систему в исходный формат, запустив:

Скрипт создаст файл root‑image.bin, размонтирует и удалит файлы и каталоги. Если упаковка не требуется, можно просто размонтировать и удалить файлы вручную:

Эти скрипты не предотвращают запуск процессов, поэтому пользователь должен сам убедиться, что к после выхода из шелла под chroot не остаётся процессов, запущенных под этой системой. В противном случае размонтирование завершится с ошибкой, и скрипт radish‑pack‑image не запустит все остальные операции, пола все процессы не будут удалены.

Можно также использовать распакованную файловую систему для копирования её в дерево каталогов, которое может использоваться как частично изолированная среда для работы под schroot или другими утилитами. В этом случае для копии каталога, которая может быть создана, например, командой

Добавляется запись в /etc/schroot.conf, например:

В этом случае команда

позволяет пользователю запустить частично изолированную среду, в которой доступен домашний каталог, но вся система запущена из-под заданного каталога, в данном случае /var/lib/chroot‑environments/debian‑system‑1

В этом случае для удобства пользователя можно также скопировать данные из-под домашнего каталога образа файловой системы в настоящий каталог пользователя (в данном случае это могут быть каталоги под /home/user/chroot‑environments/debian‑system‑1/home/user/ в каталоги под /home/user/ ), однако делать это следует осторожно, потому что во многих случаях программное обеспечение полагается на файлы конфигурации под $HOME/.config , $HOME/.local , и т. п., что может быть не переносимо, и требует индивидуальной конфигурации. Тем не менее, таким способом можно легко избежать проблем, связанных с наличием пакетов, библиотек, подготовленных каталогов с данными, и т. п.

3. Особенности установленной системы, обычно требующие вмешательства пользователя

radish исходно предназначался для создания файловых систем серверов, встраиваемых систем и создания носителей для загрузки систем в процессе восстановления после сбоев и аварий. Поэтому некоторые части конфигурации отражают именно подобное применение. В частности, radish-install устанавливает в /etc/default/grub опции в командной строке ядра Linux, отключающие установку графической конфигурации драйвером графического адаптера ( «nomodeset» ) и включающие поддержку консоли на первом устройстве последовательного порта ( «console=ttyS0,115200n8» ). Для устройств, использующих графический адаптер в графическом режиме и не имеющих последовательных портов эти опции следует удалить из скрипта. Также устанавливается запуск на первом последовательном порту программы входа пользователя в систему (конфигурационные файлы /etc/inittab или /etc/init/ttyS0.conf ) и загрузчик использует тот же последовательный порт для конфигурации при запуске, /etc/default/grub содержит :

Для устройств, использующих консоль графического адаптера эти установки следует удалить, а GRUB_TERMINAL вернуть значение «console» . В частности, эти изменения необходимы для традиционных настольных компьютеров.

Для предотвращения «накапливания» имён сетевых интерфейсов при использовании системы на различной аппаратуре и клонировании, скрипт /lib/udev/rules.d/75‑persistent‑net‑generator.rules , если он присутствует, редактируется в radish‑build так, чтобы процедура записи нового номера сетевого устройства не запускалась. В данный момент этот механизм устарел, а когда он применялся, он часто создавал проблемы для пользователей, поэтому, видимо, нет необходимости включать его, кроме, возможно, в случае подготовки образа старых версий системы для установки на серверы с несколькими сетевыми интерфейсами.

При установке пакетов SSH и клонировании устройств с ними пользователь должен учесть, что создание ключей сервера SSH производится в момент установки пакета, и они окажутся в образе файловой системы. Обычно это нежелательно, и пользователь может добавить в процедуру установки создание нового ключа для каждой копии. Также при необходимости можно добавить туда какие-либо другие ключи, например, исходные ключи клиентов SSH, которые должны иметь удалённый доступ к установленному устройству.

Конфигурация имени машины и пароли запрашивается интерактивно. Это неприемлемо для автоматической установки, и поэтому эта часть radish-install может быть заменена на что-либо соответствующее желаемой конфигурации. Можно также вообще не устанавливать доступ этих пользователей ( «x» в поле пароля в /etc/passwd , не включать какую-либо запись в /etc/shadow ), и вместо них установить соответствующие ключи в /home/user/.ssh/authorized_keys , обратите внимание на правильную установку идентификатора пользователя и прав доступа).

Также пользователи могут счесть необходимым установить какую-либо начальную конфигурацию сетевых устройств. В данный момент конфигурация минимальна.

Источник