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

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

1. Назначение и возможности скриптов 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 есть список этих утилит. Для сборки файловой системы используются:

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 выдаст ошибку, если по какой-либо причине файл оказался урезан.

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

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

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, в этом случае можно установить:

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

mount ${TDEV}2 /mnt
mount ${TDEV}1 /mnt/tmp
cp -a /mnt/tmp/* /mnt/boot/
umount /mnt/tmp
umount /mnt

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

fsck.ext4 -f ${TDEV}2
resize2fs -M ${TDEV}2

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

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

partclone.ext4 -c -s ${TDEV}2 -o - | bzip2 -9 -c > root-image.bin

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

fsck.ext4 -f ${TDEV}2
resize2fs ${TDEV}2
mount ${TDEV}2 /mnt
rm -rf /mnt/boot/*
umount /mnt

После всех этих действий файловая система возвращается в исходное состояние, а файл 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):

./radish-unpack-image root-image.bin

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

mount --bind /proc radish-mount-aaaaaaaaaa/proc
mount --bind /sys radish-mount-aaaaaaaaaa/sys
mount --bind /dev radish-mount-aaaaaaaaaa/dev
mount --bind /dev/pts radish-mount-aaaaaaaaaa/dev/pts
mount --bind /dev/shm radish-mount-aaaaaaaaaa/dev/shm
chroot radish-mount-aaaaaaaaaa /bin/bash

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

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

umount radish-mount-aaaaaaaaaa/dev/shm
umount radish-mount-aaaaaaaaaa/dev/pts
umount radish-mount-aaaaaaaaaa/dev
umount radish-mount-aaaaaaaaaa/sys
umount radish-mount-aaaaaaaaaa/proc

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

./radish-pack-image radish-mount-aaaaaaaaaa

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

umount radish?mount?aaaaaaaaaa
rmdir radish?mount?aaaaaaaaaa
rm radish?image?bbbbbbbbbb

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

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

cp -a radish?mount?aaaaaaaaaa /var/lib/chroot?environments/debian?system?1

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

[debian-system-1]
type=directory
directory=/var/lib/chroot?environments/debian?system?1
users=user
root-users=root

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

schroot -c debian?system?1

позволяет пользователю запустить частично изолированную среду, в которой доступен домашний каталог, но вся система запущена из-под заданного каталога, в данном случае /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 содержит :

# Uncomment to disable graphical terminal (grub-pc only) 
#GRUB_TERMINAL=console
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Для устройств, использующих консоль графического адаптера эти установки следует удалить, а 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, обратите внимание на правильную установку идентификатора пользователя и прав доступа).

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