Посты с тегом Gentoo

К предыдущему посту, оказывается, ларчик открывается просто. EFI-установщик семерки переборчиво относится к видеодрайверу, поэтому, чтобы он запустился, нужно добавить к qemu параметр -vga qxl. В таком варианте установщик отрабатывает нормально и мы получаем рабочую Windows 7 на GPT.

Источник: Tianocore README

В предыдущем посте на тему я довольно пространно описывал, как решить проблемы арбитрации VGA, патчил ядро и т.д. и т.п. Надо сказать, что при использовании Windows 8/8.1 (и возможно Windows Vista/7, если удастся поставить ее в режиме EFI – мне не удалось) эту проблему можно обойти. Смысл в том, что при загрузке в режиме EFI, интерфейс VGA вообще не используется. Как достичь такого эффекта? Довольно просто.

Давно хотел сделать заметку об этом лайфхаке, и все забывал. Уже довольно давно в portage есть волшебная функция epatch_user, которая применяет патчи (файлы с расширением patch) из /etc/portage/patches/%category%/%package% , где %package% может быть полным названием (с ревизией или без), либо только именем, опционально с указанием слота (i.e. %package% = %name%[-%version%[-%revision%]][:%slot%]). Проблема в том, что далеко не все ебилды это поддерживают (т.е. не в каждом ебилде на стадии prepare эта функция вызывается). Но можно это исправить, не правя ни одного ебилда.

Давеча я уже писал о пробросе видеокарты средствами Xen. Какое-то время оно работало, но после обновлений как-то перестало. Xen 4.4 в Gentoo вообще выкинул qemu-traditional, а апстрим сломан. А 4.3, который раньше вполне себе работал, почему-то сотрудничать на ядрах с 3.14 со мной отказывается. В связи с этим я решил проверить, как дела у соседей, то бишь у KVM. На моих прошлых тестах он показал себя не то чтобы очень хорошо: периодически подвисал. Но с тех пор многое могло измениться (и изменилось!)

Оказывается, iPXE умеет сообщать системе, с какого, собственно, iSCSI Target надо грузиться. Чтобы это все заработало с initrd, который генерирует genkernel даже особых телодвижений предпринимать не надо, достаточно вкомпилировать поддержку iBFT в ядро:

CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=y

При этом в параметрах ядра не требуется указывать iscsi_target, iscsi_address и iscsi_initiatorname (но не забывайте про ip=dhcp), а в скрипте загрузки, который у меня называется xx-xx-xx-xx-xx-xx.ipxe (где xx-xx-xx-xx-xx-xx — это mac-адрес бездисковой станции в нижнем регистре), указать

set initiator-iqn %initiator-name%

Где initiator-name – iqn инициатора (т.е. бездисковой станции). Либо можно тот же параметр указать в настройках DHCP (iscsi-initiator-iqn code 203)

Поддержка ibft появилась с версии 3.4.13 (аж в 2011 году). В многочисленных доках оно описано чуть менее, чем никак. Понимание пришло в результате чтения исходников genkernel’овского linuxrc

P.S. Ссылки на тему: http://ipxe.org/cfg/initiator-iqn https://blog.hartwork.org/?p=1066

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

Из-под dom0 микрокод конвенциональными методами (типа microcode_ctl) не обновляется. Но xen начиная с 4.2 умеет обновлять микрокод сам. Увы, документация практически никакая, поэтому вот мои 5 копеек.

Уже много копий переломано и текста понаписано (http://habrahabr.ru/post/149416/, http://habrahabr.ru/post/137327/, http://forums.linuxmint.com/viewtopic.php?t=112013&f=42), но я решил добавить 5 копеек для полноты картины (и чтобы самому не забыть) Карточка пробрасывается как второй видеоадаптер.

Без комментариев, под катом просто версия старого скрипта, которой я пользуюсь сейчас. Куча опций при помощи getopt и поддержка кросс-компиляции прилагается.

Еще кое-что стоит помнить при работе с линуксовым софтрейдом и метадатой 0.90. Если в рейде находятся, скажем /dev/sda2 – причем раздел находится в самом конце диска – то автодетект может запутаться и случайно воткнуть в рейд /dev/sda вместо /dev/sda2, что, в общем, смерть данным и системе*. Еще может не собрать ничего, что в данном случае оптимальный вариант, но от этого не легче. Выходов два. Либо оставлять какое-то пространство в конце диска неразмеченным (минимум 128К), либо не пользоваться автодетектом, а честно писать всё в mdadm.conf.

* Для любопытных, происходит такое потому, что в 0.90 суперблок рейда размещается в самом конце диска. Но “самый конец” оказывается и у раздела, и у всего диска в одном месте. А в суперблоке не прописано, к чему он относится – к разделу, или к диску. Так что угадать шанс минимальный. Ситуация усугубляется, если в рейде несколько “последних разделов” – по теории вероятностей, для двух дисков шанс собрать массив правильно – 1/4 (хотя принцип сборки не совершенно случаен, так что на самом деле еще меньше), для трех – 1/8, и так далее.