Эта статья прислана на конкурс.
misha_weba (автор играет на конкурсе под псевдонимом)
Сегодня я хочу поделиться своими мыслями о такой вещи, как мультизагрузка старых систем, и как я её вижу.
Небольшой отмазон (дискляймер): наша целевая платформа — старые x86-машинки с объёмами оперативной памяти примерно от 32 до 512 Мб, в которые можно воткнуть пару IDE-дисков хотя бы метров на 400, с которых местный биос сможет бутнуться.
Конечная цель — получить удобную, переносимую и максимально бесконфликтную мультизагрузку, пусть даже часть софта будет не совсем аутентичной тому времени.
Идея — заставить нужный нам софт работать так, как удобно нам.
1. Введение
Сама идея пробовать загружать одну и ту же машинку разными операционными системами родилась почти сразу, как только эти самые разные операционки у нас появились. В те далёкие времена, когда жесткий диск мог стоить как два автомобиля, а операционки влезали на дискету, именно с помощью загрузки с разных дискет и осуществлялось изучение всей этой софтварной радости.
Но дискеты — носитель весьма медленный и при частом использовании — хрупкий, так что при первой же возможности основная рабочая ОС переносилась на жесткий диск, отличавшийся куда большей скоростью и надёжностью.
Дальнейшее увеличение размеров дисков попутно с плавным снижением стоимости хранения дало возможность попробовать размещать на них несколько разных операционных систем, выбирая при включении, какую именно ОС загружать.
Сейчас эта тема несколько подзабылась — современные CPU нереально чудовищной вычислительной мощности, вкупе с решениями аппаратной виртуализации, позволяют запускать многий экзотический софт в отдельных хорошо изолированных окружениях.
В моей практике был интересный случай, когда потребовалось предоставить в виде готового образа виртуальной машины некий софт из прошлого тысячелетия. То есть у нас есть мощная машина, на которой может быть запущена виндовс 7/8/10, какой-нибудь линукс или даже макось-Хэ, в которой стоит среда виртуализации — VМWare/VirtualBox, в неё импортируется ВМ (ova-файл) с очень сильно обрезанной виндовс-XP, на ней — DOSBox, внутри досбокса — Windows 3.11, а на ней — уже собственно сам столь остро понадобившийся клиенту учётный государственный софт 1996 года выпуска. Почему так сложно и кошмарно криво? Оказалось, что если не применять некоторые опции DOSBox и замедление эмулируемого процессора, а просто поставить DOS+Win311 в ВМ — то сама ОС работает, а вот убер-программулина — уже нет. Также некоторый софт может весьма сильно удивиться, обнаружив при запуске внутри ВМ фантастическую конфигурацию из Core i7 на чипсете 440BX и с объёмом оперативной памяти в 32 Мб =)
Пришлось соединить наши квадратно-колёсные велосипеды деревянными костылями.
Казалось бы, виртуализация нас спасёт. Но увы — не везде и не всегда. Как только мы захотим поработать с чуть более экзотической аппаратной частью, особенно из старого железа — виртуализация перестаёт нас спасать, и нам придётся загрузиться на реальном железе, на тех самых старых машинах.
А поскольку разнообразие софта ничуть не уступает разнообразию железа, и многие версии софта чувствительны к окружению (количество комбинаций настроек которого огромно), то у нас логично возникает потребность грузить на реальном железе (без всяких эмуляций/виртуализаций!) разные версии разных систем.
Самые очевидные примеры — ISA-платы, старые промышленные контроллеры, софт для перепрошивок старого фирмваре и прочее и прочее. Каждый раз диджеить дискетами и уж тем более жесткими дисками — удовольствие сомнительное. Хотелось бы всё это держать внутри корпуса и лишний раз не дёргать.
2. Как грузиться?
Классический путь решения такой задачи — разбиение диска на логические разделы, установка в каждый раздел своей ОС (в правильной последовательности!) и прописывание хитрого мульти-загрузчика или даже целого каскада загрузчиков, которые бы всё это правильно делали. Но тут нас поджидает целая куча проблем.
- не все ОС / загрузчики совместимы;
- некоторые загрузчики крайне убоги и не имеют нужных возможностей;
- число разделов в MBR-разметке очень и очень ограничено;
- этим очень неудобно управлять, конструкция очень хрупка;
- поломки в разделах и загрузчиках сложно и довольно рискованно чинить;
- совсем мелкие разделы создавать нерентабельно;
- это сложно резервировать и переносить на другую машину;
- сложно добиться отказоустойчивости;
Из плюсов — каждая система имеет свой постоянный раздел, где легко вносить изменения в рамках этой системы прямо в процессе её работы. Список проблем тут огромен, и если мы хотим реально большое разнообразие загружаемого ПО — то скорее всего трудности будут непреодолимы. Об отказоустойчивости хотелось бы сказать дополнительно пару слов. Диски в таких системах — чаще всего старые, да и новые диски тоже могут внезапно отказать. Тут очень хочется применить готовое решение — RAID.
Если вы подумали было про старый аппаратный SCSI-контроллер и аналогичные диски к нему — то в данном случае я буду вас решительно отговаривать. Такие диски сейчас — редкая экзотика, к тому же чаще всего ушатанная и с огромными значениями наработки, часто — в весьма суровых условиях постоянных нагрузок в ритме 24/7. К тому же частенько очень шумная, по-своему капризная и трудно заменяемая. Хотя теоретически допустимая. Если вы собираете аутентичный сервер времён раннего палеозоя — супер, в музее будет смотреться очень достойно, но в рабочий стенд — не, не надо.
Второй путь, который мне гораздо более симпатичен — это загрузка с восстанавливаемых из образов рам-дисков, создаваемых кое-какой интересной магией.
Есть такой очень навороченный загрузчик — GRUB2. Это штатный загрузчик, которым давно уже комплектуются почти все современные линукс-системы. Но помимо своего прямого предназначения он также умеет грузить образы дискет и что самое приятное - образы жестких дисков. А поскольку GRUB2 понимает уйму файловых систем и софт-рейд — то мы совместим приятное с полезным. Да, я вполне в своём уме — мультизагрузка старых систем DOS-ом и античными виндами/никсами/планом-9 у нас будет с софтверного линуксячьего RAID-1!
Сперва немного плохого. У всей этой затеи есть один значимый минус — для внесения изменений в загружаемую сборку нам придётся пересобрать загружаемый образ.
Минус поменьше — у нас по умолчанию нет постоянного хранилища, ибо всё работает с рам-дисков. Для обмена данными, если он нужен, мы либо приспосабливаем сторонний диск / раздел в какой-нибудь максимально всеми поддерживаемой ФС (FAT16?), либо мутим в нужных нам образах поддержку USB или TCP/IP.
Также некоторые системы типа вин9х могут капризно воспринять перенос на другие машинки (местный Plug&Pray может не всё осилить), но тут проблемы негров шерифа не волнуют тоже есть свои возможности локально применяемого решения.
Дальше идут сплошные плюсы.
Для получения желаемого результата наш первый подготовительный этап — поставить любой линукс на софтверный RAID-1.
То есть берём два диска примерно равной ёмкости, и с помощью fdisk (используем встроенный линуксовый fdisk здорового человека или gparted, если можем его загрузить с ливки) создаём на каждом диске новую таблицу разделов и первый примари-раздел (для корня / фс) такой ёмкости, чтобы он гарантированно влез на оба диска с запасом. Тип этого первого раздела- «linux raid autodetect». Я часто применяю красивые круглые числа, то есть если у нас диски по 10Гб, создаем первые разделы по 8192 Мб. На остатках места в конце дисков создаем вторые примари, которые можем сделать линуксовой подкачкой или разделом FAT16, чтобы он мог использоваться как общее обменное хранилище для данных нашими загружаемыми образами. Дальше процедура установки делается как обычно, на это есть готовые мануалы — собираем из двух разделов raid-1, ставим на него систему, если спросит, куда писать загрузчик — пишем на оба диска. Тип и версия используемого линукса малосущественна — главное, чтобы там был GRUB. Софт-рейды в качестве системного диска поддерживают все современные линуксы без исключения.
MBR позволяет иметь до 4 примари-разделов — если диски крупные, можно выделить части для второго рейда под /home . Из используемых ОС применимы Ubuntu c LXDE или Alpine, если вас устроит минималистичный вариант.
Дальше мы грузимся этим линуксом, заходим туда по SSH, делаем каталог /boot/iso, и копируем туда наши образы. Ставим пакет syslinux, он добавит нам файлик /boot/memdisk.
Обратите внимание, что кроме образов дискет *.ima у нас есть ещё образы HDD - *.dd
Затем с помощью дополнительных конфигов в /etc/grub.d/ типа 40_custom или 50_memdisk, а также команды grub-mkconfig -o /boot/grub/grub.cfg просто и незатейливо добавляем в конфиг граба такие строчки:
menuentry "Virtual Floppy - Victora 3.5.2" {
linux16 /boot/memdisk floppy
initrd16 /boot/iso/Victoria-3.5.2.img
}
menuentry "FFORMAT" {
linux16 /boot/memdisk disk
initrd16 /boot/iso/FFORMAT.dd
}
menuentry 'Virtual Win 3.10' {
linux16 /boot/memdisk disk
initrd16 /boot/iso/Win-3-10.dd
}
После этого у нас в загрузочном меню помимо основной системы (убунты/альпина) появятся пункты "Virtual Floppy - Victora 3.5.2", "FFORMAT" и 'Virtual Win 3.10'
При выборе этих пунктов линуксовая тулза memdisk прочитает образ из файла, указанного параметром в initrd16, разместит его в памяти и сделает эмуляцию виртуального флоппи или рамдиска. В первом случае используется тип загрузки floppy. Загруженный dos будет считать, что он работает с диска A:\ , тогда как системный первый дисковод станет недоступен.
Во втором и третьем случае тип загрузки — disk. Загруженные dos-системы будут видеть наш распакованный в памяти образ как C:\ . Если у вас старая машинка с двумя дисководами — то при такой загрузке оба дисковода будут доступны тому же fformat-у.
Дополнительные бонусы от такого типа загрузки тоже существенны.
- используя такие режимы, как raw, мы можем загружать на нашем железе из образов такую экзотику, как античные юниксы, колибри, cp/m и Plan-9;
- конфиги систем очень хорошо изолированы друг от друга и не мешают друг другу;
- загрузчик на железе всего один, он тривиально ставится и по нему море документации;
- конфиги загрузки и готовые образы тривиально бэкапятся и переносятся;
- format с: , неосторожное удаление и многие дос-вирусы становятся менее опасны, остаются только вирусы, способные воздействовать на аппаратную часть (CIH!);
- все данные лежат на RAID-1;
- образы тривиально переносятся на сетевую загрузку через PXE;
- нет никаких проблем держать много разный версий;
- размеры образов могут быть любые — лимитируется объемом оперативки;
- легко контролировать целостность образов с помощью хэшсумм;
- пересборка образов относительно проста;
3. А что это за образы и где они живут?
С образами дискет проще всего — они используются как есть. Файлы с расширением ima / img, пригодные для rawrite - это оно. Если вы решили добавить в образ что-либо — просто подключаете его к виртуальной машине, вносите изменения, новый образ копируете на сервер. Если это новая версия — то с другим именем файла и добавлением строчек в конфиг. Тут всё тривиально. Я использовал подобные сборки для PXE, когда требовалось обновить bios на старых машинках — это прекрасно работает.
Образы жестких дисков готовить чуть сложнее. В отличие от флоппи, у них внутри есть своя таблица разделов, свой внутренний загрузчик и свой внутренний раздел. Основной метод тут — создаём виртуальную машину с диском нужного размера, туда всё ставим, доводим до рабочей кондиции, а затем делаем посекторную копию диска ВМ в файл, который и размещаем на стенде.
Несколько трюков напоследок:
- образ HDD из VirtualBox можно получить, используя линуксовые livecd и жуткую утилиту dd с копированием файла сперва в tmpfs, а потом уже куда надо по SSH;
- никто не мешает в качестве промежуточного диска использовать реальный стенд и отдельный физический диск, но там возможно придется с помощью gparted и dd снять только нужную часть данных / сразу использовать разделы нужного размера;
- dd + losetup + gparted позволяют сделать пустой файл-образ hdd без проблем;
- утилита kpartx позволяет смонтировать внутренние разделы из dd-образа напрямую;
- если памяти реально много, можно грузить файлы iso с эмуляцией cdrom;
- машинки могут лагать, если вы заходите по ssh, авторизуясь 8-килобитными ключами =);
Спасибо всем, кто дочитал это до конца. Надеюсь, тут было что-то для вас полезное.
Обсудить статью в специально созданной ветке форума. Эта статья прислана на конкурс.
Другие статьи автора на сайте:
Новый порох для старой гвардии — установка новых версий Linux на старый компьютер
© Текст, фотографии — misha_weba (автор играет на конкурсе под псевдонимом)
© Железные призраки прошлого — 2019 г.
Опубликовано 06.03.2019 г.
Дополнения или поправки на phantom@sannata.ru
|
