Селим OpenSolaris рядом с Linux: загрузка одним bootloader'ом или история одной глупости

Уже довольно давно, может с месяца с 4, у меня валялся набор из 2 дисков OpenSolaris 10 Starter Kit. Так как солярой я интересовался и раньше и эпизодически ею пользовался (Sun Solaris 9 x86), то решил наконец попробовать и этот продукт. На диске есть 3 дистрибутива в редакции community: Nexenta, Schilix и Belenix. Опробовав последовательно все 3 образа (они загружаются с DVD-диска как Live без необходимоси установки), я остановил свой выбор на последнем, как на наиболее соответствующем моим требованиям дистре (gcc в комплекте и всё необходимое для разработки - библиотеки, плюс, конечно, zfs, Solaris zones, DTrace и прочее).

Кратко о самом дистре Belenix: довольно симпатичный дистр, в качестве рабочей графической среды предоставляется на выбор KDE 3.5 или Xfce, коим я и пользуюсь. По умолчанию графика не запускается. В смысле, она запускается на полуавтомате при загрузке LiveCD, но не в уже установленном солярисе, где по умолчанию пускать Xfce нужно явно, руками (хотя, никто не мешает Вам настроить этот момент под Ваши нужды). Порадовало, что без проблем определяются интегрированное аудио и eth-адаптер на nForce430, с дисковым контроллером проблем также никаких (у меня 2 SATA-II винчестера). В отличие от Nexenta здесь ничего не валится в коры буквально на ровном месте. Установка проходит без проблем и в принципе, процедура довольна тривиальна, поэтому на ней я останавливаься не буду. Единственное, что хотелось бы отметить, что инсталлятор как был во всех версиях Solaris, что мне попадались - текстовый, таковым остался и здесь. Однако, я не считаю это недостатком. Но вместе с тем, опций здесь лишь самый минимум - думаю, можно было бы сделать и побольше, хотя бы на предмет того, какой софт нужно ставить, а какой нет.

Итак, я выкроил свободное место на втором винчестере и поставил OS туда. Непредвиденные трудности начались, когда я попытался при перезагрузке получить мой свежеустановленный Belenix. Суть проблемы в следующем: до этого у меня уже был установлен Debian GNU/Linux 'Etch' и всё, что обреталось у меня на компьютере, грузилось его grub'ом. Честно говоря, мне не было особого резона использовать в качестве общесистемного загрузчика Solaris'овский grub, потому как всё же большую часть времени я провожу в Linux и такая схема была бы не очень удобна. Но Linux'овый grub понятия не имеет о zfs или ufs2 (хотя, последнее по идее должен уметь). В конце концов я уже готов был пойти на крайность и сделать общесистемным загрузчиком Solaris'овский grub. Перезагрузившись с Belenix LiveCD, вызвал installgrub со следующими параметрами:

# grubinstall -m /mnt/solaris0/boot/grub/stage1 /mnt/solaris0/boot/grub/stage2 /dev/rdsk/c2d0s0

В общем, здесь всё довольно self-explanatory: указываем файл для первой стадии загрузки grub (сектор, внедряемый в MBR), образ для второй стадии и слайс, на котором стоит Solaris (честно говоря, я до сих пор путаюсь в схемах BSD и Solaris, но если я не ошибаюсь, то это должен бы быть лейбл, а не слайс, ведь слайс - это раздел в терминологии DOS, однако по имени видно, что у нас контроллер 2, первый диск на 2-м контроллере и 1-й слайс на этом диске - так или иначе, но эта схема совершенно отлична от той, что используется в Linux и не совсем похожа на Free- или NetBSD'шную. ИМХО в FreeBSD имена устройств выглядят логичнее и нагляднее, чем в Solaris). Ключ -m здесь просто добавляет интерактивности. Если Вы не накачались пивом и прекрасно понимаете, что Вы собираетесь сделать, то им можно и пренебречь :) /mnt/solaris0 - подмонтированная ФС с уже установленной на диск солярой - мы будем брать необходимые файлы с этой ФС. Так вот, каково было моё разочарование, когда я обнаружил, что первый загрузочный сектор оказался не в MBR первого винчестера, как я ожидал, а в mboot'e второго. Указать installgrub'у явным образом, куда необходимо воткнуть загрузочный сектор не представлялось возможным.

В общем, ситуация вышла достаточно комичной. Linux'овый grub в упор не воспринимал Solaris'овскую ufs2 и о том, чтобы он мог грузить соляровое ядро непосредственно не могло быть и речи, а с другой стороны соляровый загрузчки упорно становился в mboot второго диска и, следовательно, пролетал при загрузке.

Решение было ясно как день и простое, как карандаш. Честно говоря, если бы не лень, можно было бы не морочить себе голову. Дело в том, что я пытался редактировать меню загрузки на лету, добавляя
rootnoverify (hd1)
chainloader +1
Но по не совсем понятной мне причине Linux'овый grub ругался кодом ошибки 27 и как резанный кричал, что не знает такой команды. Редактирование menu.lst для Linux'ового grub'а расставило всё по своим местам (хотя и странно, почему такого результата не удавалось добиться редактированием параметров загрузки на лету - ограничение внедряемого кода grub-шелла для экономии, чтобы по возможности сократить число секторов, которые необходимо внедрить?). Теперь и солярис и линукс грузятся одним загрузчиком - Linux'овым, с той поправкой, что солярис грузится не непосредственно, а через встроенный в цепь собственный загрузчик, который живёт в MBR второго диска.

Результат: в MBR 1-го диска установлен Linux grub, а в файл menu.lst для загрузки зацеплённого солярового grub'a, что установлен нами ранее в MBR 2-го винчестера installgrub'ом, были добавлены строки:

title  Belenix 32-bit
rootnoverify (hd1)  # Используем в качестве корня MBR 2-го диска (hd1), и не пытаемся ничего монтировать - не получится, т.к. там просто нет ФС и нечего монтировать :)
chainloader +1  # Встраиваем в цепь вторичный бутлоадер, на к-й ссылается MBR 2-го диска

Есть ещё одно обстоятельство. Файл menu.lst для солярового grub'a также нуждается в небольшой правке, которую лучше сделать именно в файле, чем каждый раз корректировать на лету команды загрузки. А именно, по непонятному недоразумению, которое уже описывалось ранее, соляровый инсталлятор grub'a, а вместе с ними вдогонку и сам grub почему-то считают, что они установлены на 1-м диске, а не на 2-м, как у меня обстоит дело в реальности. В результате, в /boot/grub/menu.lst для соляриса имеем такие сроки:

title  Belenix (32Bit, ACPI)
  root (hd0,3,a) # Ошибка: Корневая ФС, на которой находятся файлы образа ядра и загрузочный архив находится на втором диске, а не на первом (первое число должно быть 1, а не 0)!
  # Далее - всё в полном порядке ：）
  kernel /platform/i86pc/multiboot kernel/unix
  module /platform/i86pc/boot_archive

Строка root нуждается в следующей правке: 0 необходимо заменить на 1 для второго диска, а в остальном всё правильно в моём случае - слайс 3, лейбл - а. С учётом сказанного, она должна выглядеть так: root (hd1,3,a). Хотя, если у Вас OS установлен на 1-м винчестере, то эта правка Вам не нужна.

Вместо Afterword: как и в Linux'e в OpenSolaris есть определённые ограничения для корневой ФС или, по крайней мере, /boot. Так, в Linux нет возможности внедрить секторы со второй стадией загрузки grub в раздел, который отформатирован в xfs (просто в xfs исторически не предусмотрена такая возможность, т.к. эта ФС была разработана для SGI IRIX и изначально к Linux никакого отношения не имела. Итог состоит в том, что в голове xfs-раздела нет необходимых 64 Кб для внедрения grub-секторов. Поэтому или всю корневую ФС или, по крайней мере, /boot нужно держать на ФС, более традиционной для Linux - ReiserFS, Ext2/3 и т.п.) Аналогично, grub на самом деле не имеет понятия о пулах zfs (на самом деле, если не ошибаюсь), но тот, что имеется в OS прекрасно работает по крайней мере с ufs2. Поэтому, выход здесь, как и в случае с Linux - держать корневую ФС на ufs2, а уже остальное, типа /home - в пуле на zfs.

PS: небольшая попроавка к примеру с xfs и grub. Честно говоря, я не уверен, что информация актуальна, но насколько можно судить сейчас по некоторым данным grub прекрасно работает и с корневой ФС на xfs. Но так как я не уверен, то текст оставил без исправлений. Если я всё-таки ошибся, то извините за неточность - мы все учимся, и не редко на ошибках и с их же помощью :)