Показаны сообщения с ярлыком системное администрирование. Показать все сообщения
Показаны сообщения с ярлыком системное администрирование. Показать все сообщения

вторник, 26 сентября 2017 г.

Как собрать altcoin-qt под Windows? Еще раз о компиляции.

Сегодня мы с вами рассмотрим каким образом можно собрать из исходников или проще говоря скомпилировать кошелек (wallet) практически любого AltCoin'а. В предыдущей статье, которая вышла на Яндекс.Дзене - Руководство. Как собрать ccminer из исходников под Windows? я уже рассматривал сборку из исходников, там мы использовали MSVC (Visual Studio 2013) для сборки ccminer. Теперь пришло время рассмотреть как же собрать кошелек для криптовалют под Windows. Почему именно altcoin-qt? Как вы уже поняли - это обобщенное название. Структура большинства монет состоит из нескольких исполняемых файлов - непосредственно демона (altcoind), консольного кошелька или же просто консольного средства управления демоном (altcoin-cli) и кошелька с графическим интерфейсом (altcoin-qt). В частности "комплект" популярного кошелька Bitcoin Core также состоит из этих трех компонентов.

Зачем это может понадобиться, спросите вы. Ведь в большинстве случаев скачать готовую сборку в виде exe'шника можно на официальном сайте проекта или на многочисленных форумах и т.п. Ну во-первых, это более безопасно. Собранный самостоятельно кошелек из скачанных с официального Git репозитория разработчика исходников, как вы понимаете, гораздо безопаснее чем некий exe'шник с непонятного форума, во-вторых - конечно же у любого разработчика есть раздел releases, но, например, релиза собранного релиза со свежими изменениями еще нет, а вам очень хочется получить их. В-третьих, уже собранная релизная версия может не включать в себя каких-то функций, которые есть в dev или night сборках, а здесь вы можете запросто включить их. Ну и в четвертых, сборка из исходников может быть познавательна в образовательных целях, кто знает, может вы всерьез решите заняться программированием и добавите в ПО какую-то существенно полезную функцию, упрощающую его использование. Вообщем вариантов ответа на вопрос "зачем" тут масса. Если вы читаете эту статью - значит вам уже стало интересно.

Сразу скажу, что сборка подобных вещей под Windows занятие не из легких. В мире Linux подобное делается в разы проще, если упрощенно, т.е. не затрагивая установку зависимостей, хотя она тоже делается с помощью нескольких простых команд, для сборки проекта в Linux, как правило, необходимо выполнить всего три простых команды - git clone, ./configure и make. Первая из которых предназначена для клонирования репозитория, т.е. скачивания исходников, вторая и третья для конфигурации и непосредственно сборки. Так что для тех кому по каким-либо причинам придется делать подобные вещи достаточно часто - проще установить Linux (поверьте, это не так сложно и достаточно удобно в целом), если же вы ярый приверженец Windows и эта ваша единственная ОС, тогда читаем дальше.

Говоря о сложностях при сборке под Windows необходимо учитывать, что хотя большинство altcoin'ов представляют собой кроссплатформенное ПО (т.е. теоретически его можно собрать на любой ОС - Linux, Windows, MacOS и т.п.), сделать это под Windows не так просто. И первым камнем преткновения здесь становятся зависимости от библиотек, которые также нужно скачивать отдельно и собирать из исходников. Плюс разнообразие версий компиляторов и отсутствие единых стандартов при конфигурации сборки. В результате чего сборку под Windows можно назвать не совсем тривиальным процессом. А как же разработчики, спросите вы? Неужели они проходят все те же этапы, т.е. для сборки релизной версии своего ПО ставят Windows, собирают под него свой тулчейн (toolchain) и т.п.? В большинстве случаев - нет. В мире Linux опять же все проще, за счет использования такой вещи как кросскомпиляция. Там это удобно. Грубо говоря, поставив соответствующий toolchain для сборки под Windows на Linux платформу, на выходе мы будем получать exe'шники и dll'ки, вместо исполняемых ELF-файлов и .so библиотек. Не все так просто, но в общем случае собрать что-то под Linux'ом (даже предназначающееся для использования в другой ОС) зачастую бывает проще, чем выполнить аналогичную задачу под Windows. Однако, мы ведь не боимся сложностей?


Скажу сразу, что для того чтобы достигнуть того что будет описано в этой статье - у меня ушли примерно сутки рабочего времени (по чуть-чуть, по чуть-чуть, но получилось), т.к. со многими нюансами я и сам был не знаком, а что-то пришлось осваивать прямо на ходу. Ну что ж, начнем готовить нашу сборочную платформу. Вам понадобится Windows 7 и выше, можно x86, можно x64, т.к. собирать мы будем 32-bit'ные сборки. Также вам понадобится умение работать с консолью и несколько утилит, которые я описывал в этой статье. Итак, обязательно ставим:

  1. Архиватор 7-zip или WinRar, если он у вас еще не установлен.
  2. Git for Windows - средство для работы с Git репозиториями.
  3. Far Manager - консольный файловый менеджер.
Ссылки на все это ПО вы можете найти в статье по ссылке выше, также настоятельно рекомендуется прочитать раздел "Курс молодого бойца Far Manager" в ней и попробовать выполнить в Far'е простейшие операции, такие как, смена диска на панели, копирование файлов, создание папок, редактирование файлов и т.п. Сразу учитесь делать это при помощи хоткеев, старайтесь не пользоваться мышкой при совершении этих действий. Это существенно поможет вам сэкономить время в будущем. Также, если вы решили следовать этой инструкции - давайте возьмем за правило, все описанное в ней выполнять обязательно . Т.е. если сказано что нужно взять Far Manager - возьмите Far Manager, даже если вы любите Total Commander. Если сказано, скачать компилятор или toolchain именно такой версии - значит нужно именно такой, не надо брать последнюю версию / самый свежий релиз и т.п. Потому что в результате у вас может ничего не получиться. Не нужно полагаться на собственную "интуицию" и думать в ключе "так тоже заработает, ведь это практически то же самое" - это не всегда верно и поможет вам избежать многих ошибок. Скажем так, перед началом сборки я тоже читал в интернете различные статьи, кстати, вот наиболее полезные из них:


И когда разбирался со всем этим не всегда был внимателен к деталям. В результате куча времени была потрачена на поиск и устранение "детских ошибок", когда, например, весь проект у нас был собран с gcc 4.9.2 (posix) версии, а одна из библиотек случайно (из-за неправильно настроенной переменной окружения PATH) с использованием gcc 6.3.0 (win32), в результате на этапе линковки получались достаточно неинформативные ошибки, выловить которые было достаточно сложно. Имейте ввиду, что система сборки проекта сама по себе достаточно сложная, все просто когда вы компилируете программу состоящую из нескольких десятков или сотен исходных файлов, но когда в дело идет целая система сборки огромного проекта, который использует различные библиотеки, разные части проекта написаны на различных языках и собираются разными компиляторами, причем со своими ключами и т.п., все гораздо сложнее. Ну что ж ... пожалуй начнем. 

Подготовка окружения

К этому моменту я считаю что у вас уже установлено ПО из списка выше и ваша ОС - это Windows 7 и выше. Если у вас на ПК уже были установлены какие-то среды компиляции и т.п. - имейте ввиду, что они могут вызвать неявные ошибки и в этом случае вам придется либо устранить их, либо начать сборку с нуля на свежеустановленной ОС. Чтобы избежать этого лучше всего так и сделать, например, установив такую же копию ОС в бесплатный VirtualBox. Однако, имейте ввиду, что лучше делать все на реальном ПК, потому что так быстрее. Также, желательно чтобы все файлы окружения и исходники ПО размещались на SSD, это может повысить скорость компиляции. 

1. Запускаем Far Manager и создаем в корне диска C:\ папки deps и Qt. В первую мы будем складывать различные зависимости (исходники библиотек), во второй собирать статическую сборку Qt. Все дистрибутивы, да и вообще все что мы скачиваем - будем скачивать в папку deps, т.к. так будет удобнее в будущем. Вся подсистема сборки будет завязаны именно на эти папки, поэтому лучше изначально использовать именно эти пути.

Собирать мы с вами будем кошелек монеты Interzone, вот соответствующая тема на BitcoinTalk. Если в двух словах, то это один из форков Dash'а на алгоритме c11. Но здесь мы не будем вдаваться в подробности, т.к. монета выбрана просто для примера. Тем кто изучает это руководство впервые - советую проделать все описанные в нем шаги именно для Interzone, чтобы вы поняли как это работает.

Да, еще, в процессе работы мы будем использовать несколько окон. Первое - это командная строка Windows, второе - это командная строка MSYS (его мы установим чуть позже). третья - это окно Far Manager. Когда мы будем вводить какие-то команды и т.п., я буду предварительно указывать где именно мы из вводим. Если это не указано дополнительно, то подразумевается что мы их вводим в командной строке Far'а. 

2. Скачаем исходники Interzone. Для этого создадим папку itz в корне диска c:\ и опять же находясь в коре выполним в Far Manager следующую команду: 
git clone https://github.com/projectinterzone/ITZ itz
На всякий случай на первый раз покажу в виде скриншота:


В результате последние исходники будут скачаны и размещены в папке c:\itz .

3. Устанавливаем консоль MSYS отсюда. Обратите внимание, на самом деле это дистрибутив проекта MinGW (Minimalist GNU for Windows), но нам потребуется только MSYS оттуда. Как мы и договаривались, качать мы будем все в папку c:\deps (зависимости), поэтому запускаем файл mingw-get-setup.exe и в инсталляторе MinGW installation manager -> All packages -> MSYS выбираем следующие пакеты:

  • msys-base-bin
  • msys-autoconf-bin
  • msys-automake-bin
  • msys-libtool-bin

Путь по-умолчанию C:\MinGW и все галочки на первом шаге инсталлятора оставляем по-умолчанию и нажимаем кнопку Install, а вот уже на втором шаге помечаем галочками нужные пакеты:

Здесь на самом деле важно не сделать ничего лишнего. Т.е. на вкладке Basic Install мы ничего не трогаем, нигде больше, особенно все что касается MinGW тоже. Просто нажимаем по All packages, переходим в раздел MSYS и выбираем 4 указанных выше пакета. Некоторые галочки там уже будут стоять, их не снимаем. Новых тоже не выставляем, только эти четыре. Также убедитесь в том что галочки на пакетах msys-gcc и msys-w32api не стоят. Если вы что-то перепутали, закройте инсталлятор и запустите его снова. Если все верно, выбираем в меню Installation -> Apply changes и затем снова нажимаем кнопку Apply. После того как все помеченные пакеты будут скачаны и установлены закрываем инсталлятор. Признаком того что вы все сделали правильно является содержимое папки C:\MinGW\bin , там должен быть один исполняемый файл mingw-get.exe . Если там есть что-то еще - значит вы напутали с галочками на предыдущем шаге, в этом случае удаляем C:\MinGW\ полностью и повторяем все вышеописанное более внимательно.

4. Далее мы создаем два файла msys_shell.cmd и cmd_shell.cmd в корне C:\ со следующим содержимым:

msys_shell.cmd
set PATH=%PATH%;C:\mingw32\bin;C:\Qt\5.3.2_Static\bin
C:\MinGW\msys\1.0\msys.bat
cmd_shell.cmd
set PATH=%PATH%;C:\mingw32\bin;C:\Qt\5.3.2_Static\bin
start cmd
И запускаем их:

Здесь (1) - это окно MSYS, (2) - это окно CMD, (3) - это окно Far. В них мы и будем работать. Фактически и (1) и (2) представляют собой командную строку, только в первом случае командным интерпретатором является bash, а во втором - стандартный командный интерпретатор cmd.exe из Windows.

< продолжение следует, статья достаточно объемная и написать ее за один вечер нереально >

вторник, 25 июля 2017 г.

Ubuntu. UEFI. Восстановление загрузки.

Сегодня мы рассмотрим с вами один из вариантов восстановления загрузки Ubuntu 16.04, установленной в режиме UEFI. Предыстория этого эпизода очень простая - на ПК были установлены две ОС - Ubuntu и Windows 10, при этом разбиение по разделам было "хитрым", т.е. на одном диске был загрузочный раздел EFI System (ESP), а также раздел Linux filesystem и Linux своп, а на другом диске был системный раздел NTFS Windows и еще один дополнительный раздел ext4 от Linux. который монтировался в отдельную папку. Материнская плата - Asus Z170-P. Потребовалось просто физически переставить всю эту систему, т.е. материнскую плату, накопители и т.п. в другой корпус. Однако, после включения Ubuntu уже не загружалась :( Начнем с того что в обычном варианте загрузки (когда все работает и Ubuntu, и Windows установлены с использованием UEFI) мы видим в BIOS'е следующие варианты загрузки:


Т.е.:
  • Ubuntu
  • Windows Boot Manager
Однако, после переустановки MB и накопителей в другой корпус вариант загрузки с Ubuntu просто пропал. Что могло произойти? GRUB находящийся на разделе с Ubuntu никуда не делся, его конфигурация тоже вообщем-то не изменилась, однако, из списка доступных типов загрузки вариант с Ubuntu просто пропал. Попытка выбрать накопитель с установленной Ubuntu в качестве приоритетного для загрузки - тоже вообщем-то ничего не дала, т.к. BIOS находил Windows Boot Manager и упрямо загружал Windows. В интернете можно найти множество потрясающих (в хорошем смысле этого слова), но бесполезных в данной ситуации мануалов (приведу ссылки на них, т.к. ситуации возможны разные и информация в любом случае будет полезной):


Но в большинстве из них не приводится информация о восстановлении загрузки именно в UEFI режиме или найти ее достаточно сложно или же рекомендуется использовать утилиту boot-repair,  которой нет на LiveCD по-умолчанию. А между тем все достаточно просто.

Загружаемся с LiveCD с Ubuntu через UEFI (если у вас ПК подключен через HDMI может возникнуть проблема с загрузкой с LiveCD, решается она добавлением параметра nomodeset, как описано здесь), в крайнем случае если GUI не стартует - переключаемся на текстовую консоль (Ctrl-Alt-F1). Далее смотрим какие разделы у нас есть с помощью sudo fdisk -l :

Device        Start      End  Sectors  Size Type
/dev/sda1      2048  1128447  1126400  550M EFI System
/dev/sda2   1128448 79626398 78497951 37.4G Linux filesystem
/dev/sda3  79628288 85917854  6289567    3G Linux swap

Здесь наша задача определить загрузочный EFI раздел. Как мы видим - это /dev/sda1. Монтируем раздел /dev/sda1 так - sudo mount /dev/sda1 /mnt и убеждаемся в том в ней есть EFI загрузчик Ubuntu /EFI/ubuntu/grubx64.efi :


Теперь осталось только прописать этот вариант загрузки в BIOS:
efibootmgr -c -d /dev/sda -p НОМЕР_РАЗДЕЛА -L "Ubuntu" -l "\Efi\ubuntu\grubx64.efi"

В нашем случае НОМЕР_РАЗДЕЛА = 1, т.к. EFI System находится на /dev/sda1. Еще несколько полезных возможностей efibootmgr:

  • sudo efibootmgr - просмотреть список доступных вариантов загрузки.
  • sudo efibootmgr --bootnum xxxx --delete-bootnum - удалить вариант с номером xxxx.
Вот и все, перезагружаем ПК, выбираем в UEFI Bios первичным только что добавленный нами вариант загрузки "Ubuntu" и радуемся работающей ОС. 

среда, 19 июля 2017 г.

Telegram. Используем несколько аккаунтов на одном ПК.

В этой маленькой заметке я расскажу вам о том как одновременно запустить несколько аккаунтов Telegram на одном ПК. В сети есть множество мануалов по этому поводу в которых приводится множество решений, начиная от установки Telegram Beta или запуска мессенджера от имени другого пользователя и заканчивая пересборкой Telegram из исходников. Но почему-то "штатную" возможность все из них обходят стороной. Сегодня я постараюсь восполнить этот пробел. И начнем мы с версии Telegram для Linux.

Как настроить несколько профилей в Telegram для Linux?

В моей десктопной Ubuntu 16.04 основной профиль Telegram хранится в ~/.local/share/TelegramDesktop . При запуске мессенджер использует по-умолчанию именно его. Для запуска Telegram со вторым аккаунтом можно конечно использовать что-то вроде sudo -u otheruser ./Telegram, т.е. запускать его от имени другого пользователя, но есть способ проще.

  1. Создаем папку в которой у нас будет храниться второй профиль: mkdir -p ~/.telegram2ndprofile
  2. Запускаем Telegram со следующими ключами: ./Telegram -many -workdir ~/.telegram2ndprofile
В результате у нас запустится новая копия от имени текущего пользователя, но абсолютно с другим профилем. Таким же образом можно настроить сколько угодно профилей.

Далее создаем в /home/decker/Рабочий\ стол/ файл telegram2.desktop следующего содержания:

[Desktop Entry]
Version=1.0
Name=Telegram (Other)
Comment=Official desktop version of Telegram messaging app
#TryExec=~/Telegram/Telegram
Exec=/home/decker/Telegram/Telegram -many -workdir /home/decker/.telegram2ndprofile 
Icon=telegram
Terminal=false
StartupWMClass=TelegramDesktop
Type=Application
Categories=Network;InstantMessaging;Qt;
MimeType=x-scheme-handler/tg;
X-Desktop-File-Install-Version=0.22

В результате получаем удобную иконку для запуска прямо на Desktop'е.

Как настроить несколько профилей в Telegram для Windows?

В Windows ситуация обстоит примерно аналогично, т.е. метод фактически остается без изменений:

  1. Создаем папку в которой будет храниться другой профиль, например в D:\Temp\.telegram2ndprofile
  2. Прописываем в ярлык для запуска Telegram в поле "Объект":
    "C:\Users\Decker\AppData\Roaming\Telegram Desktop\Telegram.exe" -many -workdir "D:\Temp\.telegram2ndprofile"
    А в поле "Рабочая папка":
    "C:\Users\Decker\AppData\Roaming\Telegram Desktop"
Естественно что имя Decker в пути необходимо изменить на ваше имя пользователя.

Как видите - все достаточно просто. Приятного общения!

p.s. Ключ -many необходим для разрешения запуска мессенджера с одним и тем же профилем несколько раз. Т.е. при повторном запуске ярлыка Telegram (Other) у нас откроется еще один экземпляр приложения с тем же самым профилем. Если вам не нужно такое поведение, достаточно использовать ключ -workdir для указания папки с профилем.

среда, 5 июля 2017 г.

И еще раз про майнинг ... Стартовый набор.

Сегодня мы с вами еще раз поговорим о майнинге, но подойдем немного с другой стороны, не с программной, как в прошлый раз, а аппаратной. Какое именно железо сейчас стоит покупать для майнинга, во что примерно обойдется "стартовая платформа" при текущих ценах, как понять насколько это выгодно и, самое интересное, как посчитать примерную прибыльность и окупаемость. Скажем так, что на эксперта в этой роли я далеко не претендую, поэтому статья будет скорее всего носить обзорный характер. И начнем мы не с видеокарт, как многие могли бы подумать, а с материнской платы, CPU, памяти, SSD и т.п. Т.е. с некоего стартового набора на базе которого будет строиться все остальное. Почему не с видеокарт, ведь это основной компонент который используется в процессе? Все просто, в связи с тем что ценник на видеокарты сейчас практически удвоился, а найти топовые видеокарты RX470 / RX480 / RX570 / RX580 / GTX1060 / GTX1070 / GTX1080 даже у таких гигантов как Ulmart, Citilink, Regard, DNS и т.п. практически невозможно (все моментально раскупается даже по ценнику x2) - довольно сложно советовать что-либо конкретное. Т.к. любой названный вариант скорее всего приведет к тому - что вы просто не найдете их в наличии, поэтому отталкиваться здесь нужно именно от того что доступно в вашем регионе и что вы реально сможете достать. Но т.к. материнская плата и прочие комплектующие нам все равно потребуются - то начнем мы именно с них.

На данный момент в качестве "стартового набора" для майнинга, который еще вполне возможно достать (правда нехватка подходящих материнских плат уже начинает наблюдаться) я бы рассматривал:
  1. Материнская плата ASUS PRIME Z270-P - данная MB имеет 2 x PCI-E x16 и 4 x PCI-E x1 , т.е. всего 6 PCI-E слотов для подключения ВК (видеокарт), с использованием райзеров (райзер - это переходник с PCI-E x1 на PCI-E x16) , а также два M.2 разъема, с помощью которых через специальные переходники (M.2 -> PCI-E) теоретически можно подключить еще 2 ВК. Однако, "стандартом" в данном случае является 6 ВК, поэтому вариант с 8 ВК на этой материнской плате мы не рассматриваем. Цена этой материнской платы на момент написания этого поста - ~8999 руб.
  2. Процессор Intel Celeron G3900 - практически самый дешевый в линейке от Intel CPU, дополнительное достоинство - минимальный TDP (51 Вт). Т.к. процесс майнинга большинства альткоинов целиком и полностью зависит от GPU, то какой у нас будет CPU в принципе не так важно. Цена в ~2199  руб. за него вполне адекватна.
  3. Кулер для процессора DEEPCOOL Theta 21 PWM - т.к. CPU мы взяли OEM версии, т.е. без кулера в комплекте, то придется докупить еще какое-нибудь дешевое охлаждение. При выборе кулера обратите внимание, чтобы разъем на нем совпадал с разъемом на материнской плате, в данном случае и (1) и (3) имеют 4-pin, так что здесь все нормально. Ценник на кулер - ~499 руб.  Можно было конечно найти и что-то чуть дешевле, но DeepCool не такой уж и плохой вариант, тем более что именно эта модель рассчитана на 95 Вт рассеиваемой мощности, т.е. в нашем случае получается даже с запасом.
  4. Kingston ValueRAM [KVR24N17S8/4] 4 ГБ - без оперативной памяти (RAM) также ничего не получится, поэтому выбираем оптимальную 4 Gb'ную планку с привлекательной ценой - ~2199 руб. 
  5. 120 ГБ SSD-накопитель Smartbuy Revival 2 [SB120GB-RVVL2-25SAT3] - и наконец SSD на 120 Gb, также из бюджетных - ~3699 руб. SSD выбран не только из-за скорости, но также и из-за низкого потребления. Строго говоря, вместо него вообще можно использовать обычную дешевую USB Flash на 8 Gb со специальным дистрибутивом Linux для майнинга, но т.к. этот вариант также имеет как свои плюсы, так и минусы - то его мы рассматривать не будем, а воспользуемся более распространенным решением.

Именно так выглядит "стартовый набор". Естественно что помимо этого вам потребуются райзеры, сами видеокарты и один или несколько (в зависимости от количества видеокарт и их потребления) блоков питания. Вопрос выбора БП выходит за рамки этого поста, т.к. все опять же зависит от того что вам удастся найти в наличии, а также от количества и типов ВК которые вы будете использовать. На тестовом стенде у нас будет одна ВК - Gigabyte AMD Radeon RX 580 AORUS XTR [GV-RX580XTRAORUS-8GD] и один БП - Corsair HXi 1000W [CP-9020074-EU], к сожалению, и то, и другое сейчас практически отсутствует в продаже или есть в различных предложениях по сомнительным ценам. Для того чтобы примерно ориентироваться по стоимость, скажу что в июне эта RX580 мелькала в том же DNS по цене в 25999 руб., а БП по цене в 18499 руб.

Ну что ж ... давайте попробуем собрать это "чудо техники":

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


Установка ОС на подобную конфигурацию у нас займет около 5-10 минут, т.к. все-таки SSD априори быстрее любого HDD (естественно, что нам понадобится еще и ODD привод, либо любой другой установочный носитель), еще какое-то время уйдет на установку драйверов материнской платы и видеокарты с прилагаемых DVD-ROM'ов. В случае с установкой Windows 10 (вариант, который скорее всего выберет большинство, хотя, как я уже и говорил, все необходимое ПО для майнинга есть и под Linux-based ОС) не помешает установить еще пару полезных утилит:
  1. Архиватор WinRar или 7-Zip для работы с архивами.
  2. Файловый менеджер Far Manager (именно Far, а не Total Commander как любят многие) для упрощения работы с конфигурационными файлами майнеров и, опять же, архивами. Для меня, например, этот инструмент уже давно стал незаменимым в любых отношениях.
  3. Какую-нибудь утилиту вроде Stardock Start10 для "человеческого" меню "Пуск" в 10-тке (хотя это уже дело вкуса). Ну и плюс рекомендуется включить иконки рабочего стола и настроить autologin пользователя в систему. Самый простой способ сделать включить иконки это воспользоваться файлом win7_desktop_icons.cmd из этого win7_bat_scripts набора, ну а для настройки autologin'а достаточно набрать в консоли control userpasswords2 и выбрать вариант в котором для входа в систему не требуется нажатия кнопок Ctrl-Alt-Del.
  4. TightVNC - для удаленного управления этим ПК, если необходимо. Можно конечно воспользоваться RDP, Radmin, TeamViewer или любым другим ПО для удаленного администрирования, но плюс в TightVNC, по-сравнению с тем же Radmin в бесплатности, а по-сравнению с RDP, в том что он позволяет подключиться к текущей активной сессии (текущему рабочему столу), а не открыть новую RDP-сессию. 
  5. Также можно воспользоваться утилитой DWS (Destroy-Windows-10-Spying) для тонкой настройки системы, например, отключения телеметрии, блокировки автоматического обновления (бывают ситуации, когда заботливая функция autoupdate'а в Windows автоматически устанавливает обновленные драйвера GPU в системе, а в некоторых случаях это совсем не требуется) и т.п.
В моем случае, после всех этих настроек, т.к. БП у меня был с поддержкой технологии Corsair Link, я установил еще и Corsair Link Dashboard отсюда - Corsair-LINK-Installer-v4.7.0.77.zip.


Как вы уже поняли - это та самая утилита от Corsair, которая предназначена для мониторинга параметров БП и подключенных к нему устройств. В будущем, благодаря ей мы сможем измерить потребление RX580 при максимальной нагрузке (кстати, как видно из скриншотов - в состоянии "абсолютного покоя", вся система, правда еще без подключенной видеокарты, берет из розетки 35W, при этом вентилятор на БП не крутится совсем, т.е. фактически такая система без нагрузки - абсолютно бесшумна, но все изменится когда мы подключим видеокарту и запустим майнер ;).

Полученная система в сборе с видеокартой выглядит как-то так:


Заметьте, что если бы мы собирали обычный ПК, например, с двумя Gigabyte RX580 AORUS XTR и хотели бы использовать CrossFire (честно говоря сам я на практике ни разу его не использовал), то вторая видеокарта ввиду ее исполинской ширины на эту материнскую плату уже бы не стала, т.к. расположение PCI-E 16x для двух "толстых" видеокарт настолько неудачное, что первая видеокарта закрывает своим корпусом слот PCI-E 16x для установки второй. Но в случае с подключением ВК через райзеры, мы конечно же сможем поставить все 6 ВК, т.е. в этом случае мешаться при подключении к материнской плате нам ничего не будет.


На установочном диске от Gigabyte, кстати, шла утилита Aorus Graphics Engine, которая представляет собой некий аналог MSI Afterburner или Sapphire TriXX. Утилита позволяет управлять настройками разгона видеокарты (выбирать частоту GPU и Memory), а также служит средством мониторинга параметров / построения графиков  и т.п. Однако, в сравнении с той же MSI Afterburner параметров доступных для изменения в ней существенно меньше:


Теперь давайте попробуем провести пару тестов в майнинге (ради чего все это собственно и затевалось) и в рамках тестирования установим NiceHash Miner с официального сайта Nicehash. По большому счету Nicehash Miner - это даже не майнер в прямом смысле этого слова, а скорее удобная оболочка для управления и мониторинга различными сторонними майнерами, который NHM автоматически скачивает со своего сайта. В этом как раз и заключается его удобство для нас, т.к. в тесте производительности при запуске он обязательно покажет нам производительность карты в большинстве распространенных алгоритмов:


Получившиеся результаты вы можете видеть на скриншотах. Настройки стоковые - т.е. без какого-либо разгона и т.п. Итого, по оценкам NHM одна RX580 8 Gb даст вам 0.0011019 BTC в день (что-то около 169 руб. при текущем курсе). Также мы видим, что в данный момент NHM выбрал для майнинга алгоритм DaggerHashimoto (ETH) и текущая скорость майнинга с использованием Claymore's Dual ETH + DCR/SC/LBC/PASC GPU Miner v9.5 составляет ~24 Mh/s, энергопотребление карты (по данным MSI Afterburner) составляет ~120 Вт, а ее температура при оборотах кулера на 35% (Auto) составляет 71 градус. Однако, по показаниям БП (Corsair Link) в момент 100% загрузки GPU мы видим несколько другую картину:


Общее потребление составляет 226/208W (in/out), из них по линии 12В - 194W.

Ниже приведены hashrate'ы Gigabyte RX580 AORUS XTR 8 Gb на некоторых популярных алгоритмах / монетах без разгона, т.е. в "стоковом варианте":

Монета / алгоритм Майнер Скорость
ETH (Ethereum) Claymore's Dual GPU Miner v9.5 24.093 MH/s
ETH (Ethereum) Claymore's Dual GPU Miner v9.3 24.137 MH/s
ETH + DCR (Ethereum + Decred) Claymore's Dual GPU Miner v9.3 24 MH/s + 700 MH/s
XMR (Monero) Claymore CryptoNote GPU Miner v9.7 Beta 646 H/s
XMR (Monero) xmr-stak-amd v1.1.0-1.4.0 629 H/s
ZEC (ZCash) Claymore's ZCash AMD GPU Miner v12.4 305 H/s

Теперь давайте попробуем хотя бы примерно посчитать прибыльность майнинга на одной видеокарте. Для этого воспользуемся калькуляторами на www.cryptocompare.com и попробуем посчитать "грязную прибыль" без учета затрат на электричество, т.е. Power consumption (w) и Cost per KW/h ($) мы выставим в 0.

При текущей сложности сети (не забывайте что она растет с каждым днем), например, для ETH с хешрейтом 24 MH/s (одна RX580) мы получим 0.01082 ETH в день или 2.86 USD / 169.39 руб. в день. В месяц это получается около 85.90 USD (5087 руб.) ... Другие монеты / алгоритмы вы можете просчитать самостоятельно (майнинг ETH наиболее выгоден для GPU на данный момент, поэтому будем ориентироваться на него).

Нетрудно посчитать через сколько примерно "отобьются" наши вложения, если учесть что на "платформу", т.е. на все без стоимости карточек и БП мы затратили - 17595 руб., не забудьте добавить сюда стоимость всех ВК в системе, блоков питания, райзеров и конечно же электричества. После чего вы сможете сделать некий вывод для себя - выгодно это или нет.

Также не забывайте, что курс криптовалют вещь относительно неустойчивая и что если сегодня 1 ETH = ~264 USD, то завтра он может измениться как в большую, так и в меньшую сторону (как правило все надеются что в большую ;) Плюс, если вы рассчитываете майнить именно ETH, то не забывайте читать новости проекта, а также учитывайте то, что через какое-то время будет запущен Casper и ETH целиком и полностью уйдет на PoS, т.е. майнинг эфира видеокартами перестанет существовать. Уже сейчас наблюдается значительный рост сложности сети Ethereum, что наглядно видно на графике Ethereum Difficulty Chart and Graph и рост этот по большей части "искусственный" и связан с предстоящим переходом на PoS (кому интересно читаем здесь):


Конечно помимо ETH (Ethereum) существуют и другие криптовалюты, но если на данный момент по показателям доходности / окупаемости вас привлекает именно ETH, то учитывайте что с запуском Casper вы не сможете добывать ETH на GPU, а до этого момента сложность сети будет все возрастать, делая процесс майнинга все менее выгодным. Т.е. в конечном итоге доход приносимый вашим оборудованием сравняется со счетами за электричество, т.е. "упадет до уровня розетки". 

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

p.s. Продолжение статьи обязательно будет ... ну а пока, как всегда буду рад выслушать ваши советы, замечания и просто мысли по теме в комментариях. В качестве постскриптума несколько наблюдений, которые не вошли в пост:

  • Кулеры в Gigabyte AMD Radeon RX 580 AORUS XTR 8 Gb достаточно хорошие. При 40% оборотов FAN'ов их вообще не слышно, даже если подойти к карте вплотную и прислушаться. Для майнинга это имеет весьма посредственное значение (какая разница какой уровень шума у оборудования), а вот геймеров данный факт безусловно порадует.
  • При 100% нагрузке на GPU и потреблении всей системой около 200W из БП (или 218W из розетки) вентиляторы в БП остаются неподвижными (!). Т.е. его температура остается в пределах допустимой для простоя вентиляторов. Поэтому надпись на коробке "Zero RPM up to 400 Watts at 25°C" полностью оправдывает себя, по факту Corsair HXi 1000W является одним из самый бесшумных БП, которые я когда-либо видел.

пятница, 23 июня 2017 г.

Apple Keyboard (MB110/B). Настраиваем Insert и PrintScreen под Ubuntu.

Сегодняшний пост наверное будет из серии "чем бы дитя не тешилось, лишь бы не покупало девайсы от Apple", да простят меня поклонники и многочисленные фанаты "яблочной" корпорации. Началось все с того что я решил поддаться искушению и приобрести себе клавиатуру Apple MB110/B. Не то чтобы я относил себя к числу фанатов Apple, просто работать с текстами, кодом и т.п. приходится достаточно часто, а следовательно удобство в их наборе играет важную роль. Те кто так или иначе следил за моим блогом, наверное помнит, что в свое время я купил Defender'овскую клавиатуру с "низкопрофильными" кнопками, подсветкой и прочими радостями жизни, т.к. она по-сути очень походит на клавиатуру моего ноутбука HP, которая меня максимально устраивает. Так вот, спустя несколько месяцев работы на стационарном ПК за Defender'ом я понял что она конечно напоминает ноутбучную, но достаточно отдаленно. Т.е. ход клавиш немного не тот, ощущения от нажатий и т.п. Т.е. аналог конечно, но как-то немного не тот. В поисках максимально удобной для меня клавиатуры я попробовал Apple Wired Keyboard (беспроводные просто не люблю по многим причинам) и как мне показалось - это именно то, что мне подходит. Так что я оформил заказ в DNS - и вот он, час "X" настал. Я забрал заказ, разорвал в клочья Apple'овскую коробку, которую вот в этом видео автор открывает с каким-то непонятным мне благоговейным трепетом и подключил ее к ПК.

Несколько минут знакомства с новым гаджетом подтвердили первоначальный тест - это удобно, но было несколько моментов, которые практически сводили удобство использования клавиатуры на нет, это:

  • По-умолчанию, верхний ряд кнопок F1-F12 работал не как функциональные, а как дополнительные кнопки (!), например, F1 - уменьшал яркость, F2 - увеличивал и т.п. Т.е. это были вовсе не функциональные клавиши, а дополнительные. Теперь представьте, если нам нужно нажать комбинацию кнопок Alt-F1 или Alt-F2, то приходится нажимать целых три кнопки Alt-F1-Fn или Alt-F2-Fn расположенных в разных местах, что чертовские неудобно. Я конечно понимаю, что акробатические этюды на клавиатуре в какой-то степени возможно и востребованы, но я то брал клавиатуру именно для работы, а не для освоения новых трюков. Поэтому F1-F12 мне были нужны как воздух и чтобы они нажимались без дополнительных модификаторов.
  • Отсутствие кнопки Insert ... Да, да ... на Apple'овской клавиатуре эта кнопка отсутствует в принципе (см. фото в начале статьи), открою секрет, чтобы нажать Insert нужно нажать комбинацию Fn+Enter или переключить дополнительную клавиатуру с помощью NumLock и нажать 0 на дополнительной клавиатуре. Представьте себе каково это вместо Ctrl-Insert или Shift-Insert исполнять этюд в виде Ctrl-Fn-Enter.
  • Отсутствие кнопки Prtsc / SysRq, т.е. банальный PrintScreen знакомый всем Windows пользователям на этом чуде техники отсутствует физически.
  • Ну и последнее ... расположение кнопок Ctrl-Alt-Cmd (Cmd на Mac клавиатуре - это Windows-key). Кнопки Ctrl и Cmd большие, а вот Alt находится между ними. Но лично я привык к другому порядку, Ctrl-Win-Alt, при этом Win - маленькая, а Ctrl и Alt должны быть большими. Я привык именно так и переучиваться не собирался. Поэтому в моем понимании нужно было поменять местами Alt и Cmd и тогда все стало бы на свои места.

Казалось бы всего 4 пункта в списке, но для меня они являлись существенными, без них, многие привычные и удобные вещи в работе превращались в 9-й круг ада, т.к. нажимать вместо обычного Ctrl-Ins целых три кнопки я явно не собирался. Да и реакция функциональных кнопок по-умолчанию меня совсем не устраивала. 

Первое что я решил сделать - это обратиться к официальному сайту Apple, где я нашел вот это: Изменение назначения функциональных клавиш компьютера Mac. Отлично, всего лишь одна настройка «Использовать функциональные клавиши F1, F2 и др. как стандартные» для первого пункта. Но вот незадача, у нас нет компьютера Mac, у нас даже нет MacOS, а только клавиатура Apple от которой мы хотим добиться такого же поведения. Дальнейшие поиски привели меня к следующему замечательному мануалу, вернее двум:


Автору первого руководства - отдельно спасибо. Честно говоря я не пробовал использовать Apple MB110 в Windows, но почему-то мне кажется что по написанному все пройдет достаточно гладко. Назначение функциональных клавиш в Windows определяется ключом реестра OSXFnBehavior, как видно из статьи. Однако как быть с другими ОС? И в частности моей Ubuntu 16.04? Чтобы найти ответ на этот вопрос пришлось провести еще немного времени с Google и в конечном итоге я наткнулся на мануал:


Который и послужил отправной точкой для решения всех перечисленных задач, правда с небольшими изменениями. Чтобы сделать функциональные клавиши как F1-F12 по-умолчанию в моей Ubuntu 16.04, а также, чтобы поменять местами Alt и Cmd (WinKey) я воспользовался следующими двумя командами:

sudo echo 2 | sudo tee /sys/module/hid_apple/parameters/fnmode - включение режима F1-F12 на функциональных кнопках по-умолчанию.
sudo echo 1 | sudo tee /sys/module/hid_apple/parameters/swap_opt_cmd - поменять назначение Alt и Command (Win-Key)

Честно говоря я небольшой специалист в Linux и в Ubuntu в частности, но здесь, как я понял, мы просто определяем параметры модуля hid-apple.ko (/lib/modules/4.4.0-81-generic/kernel/drivers/hid/hid-apple.ko), которые изначально предусмотрены в нем. Желающие могут погуглить про модуль ядра hid-apple и тогда все станет более ясно. После двух этих команд две озвученные проблемы были успешно решены, однако, надо было что-то делать с Insert'ом и PrintScreen'ом. И вот как раз на это у меня ушло несколько часов.

Remap кнопок с помощью xmodmap у меня работал из рук вон плохо. Т.е. если в окне терминала дать команду:

xmodmap -e "keycode 191 = Insert NoSymbol Insert NoSymbol Insert"

То remap работал, но только какое-то ограниченное время и не совсем понятно. Например мы открываем отдельное окно терминала и вводим в нем эту команду, все вроде получается. Т.е. при нажатии F13 в этом окне срабатывает Insert, однако стоит только открыть LibreOffice с помощью ярлыка на рабочем столе - то вот в нем уже почему-то F13 не работает как Insert. Также, соответствующие изменения ~/.Xmodmap с последующей перезагрузкой не привели к желаемому результату. Почитав немного многочисленные сообщения людей, которые пробовали на форуме сделать то же самое, я пришел к выводу что "это не наш метод". Т.к. среди решений было даже что-то вроде создать .desktop файл с запуском xmodmap /home/decker/.Xmodmap и поместить его в Startup Applications ... Но и этот метод не у всех работал, как его "дальнейшее развитие", люди делали bash скрипт с чем-то вроде sleep 4 && xmodmap /home/decker/.Xmodmap и все равно, когда-то это работало, а когда-то нет. С этого момента я понял что искать способ remap'а кнопок нужно на более низком уровне.

В одной из статей (было уже достаточно поздно и я читал их по диагонали), я нашел фразу, что чтобы переназначить кнопки или вообще что-то сделать с клавиатурой в Ubuntu нужно представлять каким образом вообще это работает, т.е. представлять как работает "стек драйверов" и каким образом обрабатывается нажатие по цепочке, начиная от нажатия пользователем кнопки на физическом устройстве, обработки этого нажатия драйверами и передачи соответствующего события приложению. Т.к. в Linux'е я не особенно специалист, то приведенная схема (которая по идее должна была открыть глаза на все):

hardware --scancode--> kernel --keycode--> X11 --> keysym --> application

что-то прояснила для меня, но далеко не все (да, да, я не совсем хорошо представляю как работает X11 и что происходит в ядре). Но эта статья дала очередной импульс поискам и я набрел на следующее:

Ключевой точкой был абзац из первой статьи:


Теперь рассказываю как сделал я и как я к этому пришел. Итак, мы решили назначить F13 на Insert, а F15 на PrintScreen. Что же, приступим

1. Ставим утилиту evtest через sudo apt install evtest и запускаем ее, как sudo evtest
2. В появившемся списке выбираем "Apple Inc. Apple Keyboard", у меня это было устройство /dev/input/event17. В выводе утилиты мы увидим нечто вроде:

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x5ac product 0x250 version 0x111
Input device name: "Apple Inc. Apple Keyboard"

Нажимаем кнопку F13 чтобы определить ее KEYBOARD_KEY_%VALUE%, после нажатия F13 мы увидим:


Event: time 1498176151.012832, -------------- SYN_REPORT ------------
Event: time 1498176154.612842, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70068
Event: time 1498176154.612842, type 1 (EV_KEY), code 183 (KEY_F13), value 1
Отсюда нам нужно запомнить значение value - 70068, это шестнадцатиричное значение. Руководствуясь статьей User XKB Customization проверяем версию udev - udevadm info --ver, в моем случае результатом было 229. Таким образом теперь нам необходимо написать соответствующий файл /etc/udev/hwdb.d/98-apple-keyboard.hwdb . Но как узнать идентификатор для evdev:input? Здесь нам поможет статья How to find the .hwdb header of a general input device? .

3. Выполняем udevadm info /dev/input/event17 и запоминаем ID_VENDOR_ID, в нашем случае это 05ac. Далее делаем find /sys -name *modalias | xargs grep -i 05ac , где 05ac наш vendor_id. Ответом будут множество строк, в том числе и одна, следующего вида: 

/sys/devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11.2/1-11.2:1.0/0003:05AC:0250.0005/input/input20/modalias:input:b0003v05ACp0250e0111... # далее много всего

Здесь нас интересует все что находится после modalias:input до 'e', т.е. в нашем случае b0003v05ACp0250 .

4. Создаем файл /etc/udev/hwdb.d/98-apple-keyboard.hwdb от имени root и вписываем туда следующие строки:

evdev:input:b0003v05ACp0250*
 KEYBOARD_KEY_70068=insert      # F13: Insert

Обратите внимание, пробел перед KEYBOARD_KEY важен. После чего делаем:

sudo udevadm hwdb --update и sudo udevadm trigger (убедиться в том что все сработало можно сделав udevadm info /dev/input/event17 | grep KEYB , если в выводе будет что-то вроде KEYBOARD_KEY_70068=insert - значит все Ок).

5. Проверяем визуально, идем в Параметры системы -> Клавиатура -> Ввод текста и нажимаем на иконку клавиатуры под списком раскладок, у нас откроется вот такое окно:


Теперь нажимая F13 мы видим что у нас засчитывается нажатие Insert. Аналогично делаем с F15 -> PrintScreen. Здесь я приведу уже готовый вариант /etc/udev/hwdb.d/98-apple-keyboard.hwdb :

evdev:input:b0003v05ACp0250*
 KEYBOARD_KEY_70068=insert      # F13: Insert
 KEYBOARD_KEY_7006a=sysrq       # F15: PrinScr / SysRq

Вот таким нехитрым образом мы заставили работать функциональные клавиши, а также Insert и PrintScreen на клавиатуре Apple MB110/B под Ubuntu 16.04. При этом мы не использовали "плясок с бубном" вокруг отложенного запуска xmodmap, не разбирались почему не "подцепляется" наш ~/.Xmodmap, а решили проблему "уровнем ниже". И хотя в данном случае до полного понимания принципов работы и назначения udevadm и hwdb нам еще "расти и расти", поставленную задачу успешно удалось решить. Конечно, ее можно было решить и другими путями, например сборкой модифицированного hid-apple.ko (на эту тему также есть соответствующие статьи в интернете, например эта), но фраза "Macbook keyboard is painful" в самом начале как бы намекает ;) Нет, конечно, можно собрать hid-apple.ko с модифицированным / пропатченным hid-apple.c (кстати есть даже проект на Git'е), однако, для этого нужно еще качать исходники ядра, разбираться как собираются модули, а если у вас Ubuntu на системе с UEFI, как у меня, например, то еще и понимать каким образом заставить грузиться собранный неподписанный hid-apple.ko. Конечно, при наличии времени и должного энтузиазма можно сделать и это, но способ описанный мной чуть проще. Этот пост я уже писал на Apple'овской клавиатуре с работающими так, как мне нужно кнопками.

p.s. Комментарии, предложения, пожелания - приветствуются ... и да, Macbook keyboard is painful ;)

Обновлено 24.07.2017 15:56 (MSK)

Для того чтобы сделать предпочтение в работе функциональных клавиш F1-F12 описанное в статье по-умолчанию (т.е. при загрузке системы), а также поменять местами Alt и Cmd (WinKey), достаточно выполнить следующие команды:

echo options hid_apple fnmode=2 | sudo tee -a /etc/modprobe.d/hid_apple.conf
echo options hid_apple swap_opt_cmd=1 | sudo tee -a /etc/modprobe.d/hid_apple.conf
sudo update-initramfs -u -k all
sudo reboot

Обновлено 21.02.2019 23:27 (MSK)

Для Apple Magic Keyboard, которая wireless (т.е. беспроводная) последовательность действий абсолютно такая же. Только в данном случае значения будут несколько другими:

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x5ac product 0x26c version 0x110
Input device name: "Apple Inc. Magic Keyboard with Numeric Keypad"

Как видно, изменился код product. А соответствующее значение по find /sys -name *modalias | xargs grep -i 05ac будет выглядеть следующим образом:

/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:05AC:026C.000A/input/input24/modalias:input:b0003v05ACp026Ce0110

Т.е. в /etc/udev/hwdb.d/98-apple-keyboard.hwdb мы должны прописать следующий идентификатор b0003v05ACp026C. Целиком же 98-apple-keyboard.hwdb для поддержки и проводной и беспроводной клавиатуры выглядит следующим образом:

evdev:input:b0003v05ACp0250*
 KEYBOARD_KEY_70068=insert      # F13: Insert
 KEYBOARD_KEY_7006a=sysrq       # F15: PrinScr / SysRq

evdev:input:b0003v05ACp026C*
 KEYBOARD_KEY_70068=insert      # F13: Insert
 KEYBOARD_KEY_7006a=sysrq       # F15: PrinScr / SysRq
 KEYBOARD_KEY_700e2=leftmeta    # key marked left alt -> left meta
 KEYBOARD_KEY_700e3=leftalt  # key marked left meta -> left alt

Обратите внимание, что символ перевода строки между устройствами важен. После изменения файла также нужно выполнить: sudo udevadm hwdb --update и sudo udevadm trigger

Да, обратите внимание еще на одну особенность. Почему-то рецепт для обмена местами Alt и Cmd (WinKey) рекомендованный выше и отлично работавший с проводной Apple'овской клавиатурой здесь у меня не сработал (хотя надо отметить что функциональные клавиши F1-F12 работали как именно F1-F12 по-умолчанию, с использованием рекомендаций из основной статьи). Поэтому для решения данной проблемы я также применил low-level key remapping. В результате левый Option (700e2) на Mac'овской беспроводной клавиатуре у меня работает как Command / Meta / Win, а левый Command (700e3) как левый Alt. Впрочем в комментариях получившегося 98-apple-keyboard.hwdb - это описано.

Также, в рассматриваемом примере клавиатура была подключена к ПК посредством комплектного Lightning/USB кабеля. С беспроводным подключением разбираться пока не стал, т.к. на текущий момент для меня достаточно обычного проводного подключения. А, собственно, беспроводная версия клавиатуры бралась исключительно по причине отсутствия в продаже проводных.

p.s. Да, ну и пока я писал это небольшое дополнение, наткнулся на еще одно небольшое руководство с примерами - Linux udev keys binding, возможно для кого-то окажется полезным.

Для того чтобы запустить проверку корректности переназначения кнопок (аналог меню Параметры системы -> Клавиатура -> Ввод текста в Ubuntu 16.x) в Ubuntu 18.x достаточно набрать в терминале gkbd-keyboard-display -l us , т.к. как вызвать это приложение в 18.x из настроек системы для меня честно говоря до сих пор не очевидно.

p.p.s. Ну и совсем последний постскриптум к этой части. Наверняка многие задались вопросом, а откуда собственно взять "названия кнопок" для mapping'а, т.е. где можно посмотреть возможные значения вроде insert, sysrq, leftmeta, leftalt и т.п. В этом вам может помочь следующее: Where is “keyboard-keys-from-name.h” used by udev of systemd of Linux? , keyboard-keys-from-name.h . Ну и как говорится по первой ссылке - не лишним будет заглянуть в /usr/include/linux/input-event-codes.h .

пятница, 16 июня 2017 г.

Corsair HX1000i. Качественные блоки питания, какими они должны быть?

Сегодняшний пост будет несколько необычным, в нем я бы хотел затронуть тему качественных блоков питания для ПК и попробовать разобраться, насколько они востребованы и актуальны для домашнего применения. Согласитесь, что собирая обычный домашний или игровой ПК, мало кто из нас задумывался какой БП стоит приобрести. Обычно процесс выбора комплектующих сводится к подбору материнской платы, процессора, видеокарты и уже на последнем этапе мы выбираем корпус и БП. Причем в выборе последних двух компонентов мало кто из нас руководствуется какими-то "критериями выбора", скорее это выглядит так: все куплено, какой бы корпус нам выбрать? А возьмем вот этот черненький, вроде ничего, да и по цене адекватный ... БП? Видюшка не такая мощная, да и зачем покупать что-то дорогое, возьмем вот этот 600-750 Вт'ник, в бюджет вписывается и ладно. Т.е. при выборе комплектующих для ПК мы расставляем акценты на CPU + GPU, а уже БП, корпус и все остальное получается чем-то вроде "второстепенной покупки" на то что осталось и что вписывается в планируемые расходы.

Скажу честно, что сам руководствовался таким подходом долгое время (например, сейчас в моем домашнем ПК стоит какой-то Aerocool KCAS 600W и единственным критерием его выбора послужила цена - до ~3000 руб. на момент покупки, что я посчитал приемлемым), однако, после того как я "вживую" познакомился с флагманскими БП от Corsair я понял что разница на самом деле есть и довольно существенная. Заключается она даже в мелочах, начиная от упаковки / комплектации БП и заканчивается качеством сборки, используемыми компонентами, качеством комплектных проводов (!) и реально выдерживаемыми БП нагрузками (далеко не каждый БП на котором написано, к примеру, 600W реально способен потянуть такую нагрузку по 12В линии). Но обо всем по-порядку ... Да, кстати, еще одно существенное замечание, если вы внимательно рассмотрели фотографию коробки от Corsair HX1000i в заголовке поста, то наверняка заметили надпись Ultra Low Noise на ней. В случае с Corsair и других топовых БП на практике это действительно означает бесшумность. Т.е. с небольшими нагрузками, например, вы просто включили ПК, открыли браузер, поставили музыку и т.п. - кулер на БП совсем не будет вращаться, т.е. фактически, если нагрузки нет - ваш БП превращается в абсолютно бесшумный компонент ПК, что, согласитесь, достаточно важно, особенно в ситуации, когда вам частенько приходится работать по ночам, а в той же самой комнате спят ваши близкие.

Перед тем как начать рассказ о Corsair HX1000i давайте попробуем разобраться с сериями БП этого производителя, ведь у них есть серии AX, HX/HXi, RM, TX-M, SF, CX, VS и другие и немногие представляют чем например HX отличается от той же RM-серии и т.п. Для начала рекомендуется ознакомиться с описанием серий на официальном сайте производителя:

  • AXi Series — наша основная линейка блоков питания, предназначенная для использования в сверхмощных ПК. Это первая линейка блоков питания для настольных ПК, оснащенная процессором цифровых сигналов для обеспечения непревзойденной эффективности без ущерба для электрических характеристик. Если вам необходим блок питания для новой системы вашей мечты — это именно то, что вам нужно.
  • Блоки питания HX и HXi Series разработаны для игровых компьютеров, разогнанных систем и прочих ПК, где ключевую роль играет надежность и бесперебойность работы. Сертификация 80 PLUS Platinum означает, что блок питания работает без перегрева, бесшумно и эффективно. Модели HXi Series обладают еще лучшими характеристиками благодаря мониторингу и управлению с помощью Corsair Link, а также модернизированным вентиляторам.
  • Блоки питания RMx и RMi Series изготовлены с применением высококачественных компонентов, обеспечивающих отличные рабочие характеристики и невероятно низкий уровень шума. Эти блоки питания сертифицированы по стандарту 80 PLUS Gold и обеспечивают чрезвычайно точную регулировку напряжения, работая практически бесшумно. Использование конденсаторов исключительно японского производства с рабочей температурой 105 °C делает эти блоки питания отличным выбором для использования в высокопроизводительных ПК, для которых надежность имеет решающее значение. Комплект полностью модульных кабелей упрощает установку и замену. Благодаря совместимости с RMi Link вы сможете контролировать параметры блока питания, которые ранее не были доступны для пользователей.

Таким образом AX - представляет собой "флагманскую линейку", HX - были "топовыми" до появления линейки AX, ну и RM, соответственно, также высококачественная линейка БП, сертифицированная как 80+ Gold (большинство БП AX серии имеют 80+ Titanium, а HX - 80+ Platinum сертификацию, более подробно о сертификатах для БП вы может прочитать здесь - 80 PLUS). 

Энергоэффективность потребления - фактически это КПД вашего БП. Т.е. отношение выходной мощности к потребляемой, для стандарта 80+ он должен быть не менее 80% при 20%, 50% и 100% нагрузке относительно номинальной мощности БП:


Не нужно быть специалистом в электронике, чтобы понять, что БП тем лучше, чем лучше его КПД. Т.е. если считать что БП берет из розетки 100% мощности, то по стандарту 80 PLUS он должен отдавать не менее 80% полезной мощности подключенным к нему устройствам при 20% нагрузке. В случае с 80+ Platinum мы видим этот показатель как 90%, т.е. "потери" при 20% нагрузке всего 10%. Думаю что с классификацией мы разобрались, ну а теперь посмотрим на HX1000i более пристально.

p.s. Продолжение следует ... 


вторник, 6 июня 2017 г.

PXE Boot. Бездисковые устройства. Загружаемся по сети.

В этом небольшом посте я расскажу вам о практических способах реализации загрузки бездисковых устройств через PXE. Скажем так, что до определенного момента я совсем не интересовался этой проблемой и о PXE имел весьма посредственное представление, также, наверное как и у большинства. Т.е. все из нас знают, что в современных ПК есть возможность загрузки по сети, каждый видел в BIOS'е собственного ПК такую возможность (PXE Boot, LAN Boot), но мало кто использовал ее на практике. Реализацией этой возможности мы и займемся на практике, а также рассмотрим какое практическое применение в "домашних условиях" может иметь сетевая загрузка.

Наша "тестовая лаборатория" включает в себя:

  • Маршрутизатор Mikrotik 951G-2HnD с RouterOS v6.39 (stable)
  • Сетевое хранилище Western Digital My Cloud EX2

Для реализации загрузки через PXE вовсе не обязательно наличие подобных устройств, т.е. по сути нам потребуются DHCP Server, TFTP Server, NFS и/или HTTP для организации хранения и передачи тяжеловесных образов по сети. Все эти компоненты можно установить например и на обычный ПК под управлением Windows, или же, поставить тот же Ubuntu на отдельную машину в локальной сети и настроить все эти сервисы там, благо мануалов в сети предостаточно. Но раз уж так получилось что у нас есть Mikrotik'овский роутер и NAS - то функции DHCP + TFTP логично возложить на Mikrotik, а NFS / HTTP на NAS.


Также нам понадобится самая обычная USB Flash'ка, любого размера, которую мы вставим в Mikrotik чтобы обеспечить хранение файлов, которые будут отдаваться по TFTP. Если у вас уже есть подобная конфигурация (DHCP+TFTP+NFS+HTTP), то можно приступать. 

Здесь я расскажу путь, которым прошел я. Первоначально мне было интересно сделать бездисковую загрузку LiveCD дистрибутива Ubuntu, т.е. чтобы любой ПК в сети с HDD или без можно было включить и получить на экране работоспособный Ubuntu, а-ля посидеть в сети / почитать почту и т.п. Подобное решение может оказаться удобным и в местах организации коллективного доступа в интернет, например, различных компьютерных клубах, библиотеках и т.п. Плюс в том, что когда машина не имеет собственного HDD и грузится с единственного образа по сети "сломать" или испортить что-то случайно или умышленно - пользователи вряд-ли смогут. Т.е. после одного сеанса работы пользователя в Интернет можно будет просто перезагрузить ПК и все будет "как новое". Но перед тем как приступить к реализации этой идеи я решил почитать "что пишут в интернете" на тему сетевой загрузки Ubuntu и т.п. Статей как раз нашлось много, но конкретных работоспособных реализаций, в которых описываются все нюансы конфигурирования - было как раз мало. Чтобы у вас на этом же этапе был ровно тот же запас знаний что и у меня, приведу несколько ссылок на статьи, которые меня заинтересовали:
  • PXE - Сетевая загрузка с микротика - здесь описывается настройка Mikrotik + TFTP для сетевой загрузки с использованием GRUB (Grub4DOS), а также приведен пример рабочей конфигурации для загрузки ALKID LiveCD и VINCOME LiveCD через PXE. Немного не то что нам хотелось (мы то хотели грузить Ubuntu LiveCD), но тем неменее информация полезная, берем на заметку.
  • Настройка TFTP сервера на Mikrotik RouterOS - а вот здесь рассматривается настройка TFTP на Mikrotik, правда тут уже у нас уже используется не GRUB, а PXELINUX (SysLinux) в качестве загрузчика. Который, как мы убедимся позже, можно будет использовать и для реализации сетевой установки Ubuntu, и для загрузки LiveCD и для множества других вещей. Уже интересно, не правда ли? Знакомимся со статьями дальше.
  • Загрузочный сервер — как загрузочная флешка, только сервер и по сети - пост на Хабре, в котором рассказывается о том как сделать "загрузочную флешку" по сети. Собственно такая конфигурация отлично подойдет для различных сервисных центров и т.п., с другой стороны, выбрать то, что будет грузиться по сети лично у него - это решение каждого, благо примеров полно. К концу чтения этого поста, вы (по-крайней мере я на это надеюсь) поймете, насколько это удобно.
  • Домашний роутер с PXE-Boot и сервисами. - приводится пример организации PXE загрузки на Asus'овском роутере с прошивкой Merlin-Firmware. Честно говоря я сам подобную никогда не использовал, но статья ценна уже как минимум различными примерами рассмотренных в ней конфигураций для загрузки. А также как отличная иллюстрация того, что при желании, для реализации PXE загрузки можно использовать только лишь ресурсы бюджетного SOHO устройства.
  • Как воспользоваться сетевой загрузкой (PXE) для Ubuntu LiveCD - переводная статья с HowToGeek, в принципе тоже может быть интересна. Кстати, именно по теме сетевой загрузки Ubuntu LiveCD вы так или иначе наткнетесь на различные ее вариации в поиске.
  • Мультизагрузочный PXE-реаниматор - статья на 3DNews от 2012 года, но тоже в принципе интересно. Если вы читая этот пост пока просто просматриваете эти ссылки "по диагонали" - то наверное уже поняли, что PXE загрузка предоставляет практически неограниченный набор возможностей, наша задача лишь научиться правильно применить их для наших задач.
  • [How-To] Запуск LiceCD Ubuntu (и не только) с любого ПК в сети с помощью PXE - название поста говорит само за себя, все действия автор проводит на сервере под управлением Debian 7. Т.е. DHCP + TFTP и т.п. у него развернуты на отдельном ПК с Debian 7. Тоже интересно, помечаем в "копилку".
  • Configure PXE Server In Ubuntu 14.04 - похожий англоязычный вариант.
  • Установка Ubuntu по сети (DHCP, PXE, boot-menu) на примере Ubuntu 14.04. 
  • Ubuntu 16.04 / Debian 8: Run PXE boot server for automated install - конфигурирование сервера для автоматизированной установки Ubuntu и Debian по сети. Лично мне эта статья понравилась различными комментариями и дополнительными пояснениями. Если читать вдумчиво, а не по диагонали, то становится (хотя бы на базовом уровне) понятно что такое pxelinux.0, ldlinux.c32 и т.п.
  • Booten vom Netzwerk: Ubuntu 16.04 via PXE starten - статья, правда на немецком, подробно рассказывающая про то, как правильно настроить загрузку LiveCD с Ubuntu по сети. Собственно она и легла в основу решения поставленной задачи.
  • Руководство по сетевой загрузке предустановочной среды Windows (WinPE)
  • IT Geek: How to Network Boot (PXE) the WinPE Recovery Disk with PXElinux v5 & Wimboot
Ну и на первое время достаточно. Просмотрев / прочитав все это начнем ваять что-то свое. Первое что мы делаем - это подключаем флешку к Mikrotik'у и форматируем ее в FAT32: System -> Disks -> Format drive ... Сделать это можно как через WinBox, так и через Web-интерфейс Mikrotik. Проблем с этим возникнуть не должно.

Затем скачиваем заранее подготовленный архив pxe-mikrotik-disk1.rar и распаковываем его содержимое в корень флешки. Сделать это можно как в меню Files в web-интерфейсе Mikrotik'а, так и через FTP в Mikrotik, ну или просто вставив отформатированную USB Flash в ПК и распаковав в корень содержимое архива. В результате там должна получиться следующая структура файлов (смотреть скриншот справа).

Некоторых файлов, например kolibri.iso (образ Kolibri OS) в архиве не будет, т.к. их можно без труда найти и скачать в интернете, также в архиве не будет содержимого папки winpe (т.к. все эти файлы есть на любом установочном диске с Windows и включать их в состав архива я не вижу смысла). А вот на остальных мы остановимся подробнее.

pxelinux.0 - это основной загрузчик, на который направляются DHCP сервером все клиенты сетевой загрузки, он входит в состав пакета syslinux. Все что касается данного загрузчика, а также используемых им библиотек (*.c32) можно взять в следующих пакетах:

Чем я успешно и воспользовался. Возможно это и не совсем правильно делать "сборную солянку" из netboot и syslinux разных версий, но, например, готовый бинарник memdisk, использующийся в отдельных сценариях загрузки я нашел только в каком-то одном из этих пакетов. С файлами загрузчиков, ядер и т.п. более менее понятно. Т.е. у вас есть набор который получился у меня pxe-mikrotik-disk1.rar и набор источников откуда это бралось.

ipxe.lkrn здесь - это загрузчик Open Source Boot Firmware iPXE, собранный из исходников с поддержкой HTTP, NFS (!) и некоторых друг фич. Но к нему мы вернемся чуть позже, т.к. не рассказать про него я не могу, ввиду его обширного функционала (по хорошему достаточно только iPXE, т.е. PXELinux он как бы не обязателен, т.к. iPXE обладает более широким функционалом и удобнее в конфигурации, но так уж сложилось, что изначально я начал настраивать именно PXELinux, а возможность загрузки iPXE я добавил уже потом).

После того как вы распаковали все файлы из архива pxe-mikrotik-disk1.rar на флешку, заходим в Mikrotik в меню IP -> TFTP и настраиваем в нем следующие соответствия: Req. Filename -> Real Filename:


Для удобства все эти правила в виде одного скрипта:

/ip tftp
add real-filename=disk1/tftpboot/pxelinux.0 req-filename=pxelinux.0
add real-filename=disk1/images/kolibri.iso req-filename=images/kolibri.iso
add real-filename=disk1/images/winvblock.gz req-filename=images/winvblock.gz
add real-filename=disk1/images/pxetheme.gz req-filename=images/pxetheme.gz
add real-filename="disk1/images/Hiren's.BootCD.15.2.iso" req-filename="images/Hiren's.BootCD.15.2.iso"
add real-filename=disk1/tftpboot/memdisk req-filename=memdisk
add real-filename=disk1/winpe/bootmgr req-filename=winpe/bootmgr
add real-filename=disk1/menu.lst/default req-filename=menu.lst/default
add real-filename=disk1/winpe/bootmgr.exe req-filename=winpe/bootmgr.exe
add real-filename=disk1/winpe/boot/boot.sdi req-filename=winpe/boot/boot.sdi
add real-filename=disk1/winpe/boot/bcd req-filename=winpe/boot/bcd
add real-filename=disk1/tftpboot/ldlinux.c32 req-filename=ldlinux.c32
add real-filename=disk1/tftpboot/grldr req-filename=grldr
add real-filename=disk1/tftpboot/undionly.kpxe req-filename=undionly.kpxe
add real-filename=disk1/tftpboot/ipxe.lkrn req-filename=ipxe.lkrn
add real-filename=disk1/tftpboot/wim-boot.ipxe req-filename=wim-boot.ipxe
add real-filename=disk1/tftpboot/boot.ipxe req-filename=boot.ipxe
add real-filename=disk1/tftpboot/boot.png req-filename=boot.png
add real-filename=disk1/tftpboot/wimboot req-filename=wimboot
add real-filename=disk1/tftpboot/pxelinux.cfg/default req-filename=pxelinux.cfg/default
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/boot-screens/vesamenu.c32 req-filename=\
    ubuntu-installer/amd64/boot-screens/vesamenu.c32
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/boot-screens/linux.c32 req-filename=ubuntu-installer/amd64/boot-screens/linux.c32
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/boot-screens/chain.c32 req-filename=ubuntu-installer/amd64/boot-screens/chain.c32
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/boot-screens/libcom32.c32 req-filename=\
    ubuntu-installer/amd64/boot-screens/libcom32.c32
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/boot-screens/libutil.c32 req-filename=\
    ubuntu-installer/amd64/boot-screens/libutil.c32
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/boot-screens/menu.cfg req-filename=ubuntu-installer/amd64/boot-screens/menu.cfg
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/linux req-filename=ubuntu-installer/amd64/linux
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/initrd.gz req-filename=ubuntu-installer/amd64/initrd.gz
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/vmlinuz.efi req-filename=ubuntu-installer/amd64/vmlinuz.efi
add real-filename=disk1/tftpboot/ubuntu-installer/amd64/initrd.lz req-filename=ubuntu-installer/amd64/initrd.lz
add real-filename=disk1/winpe/sources/boot.wim req-filename=winpe/sources/boot.wim

Для чего они? После загрузки PXELinux на устройство начинается поиск дополнительных файлов и библиотек, т.е. устройство пытается подключиться к TFTP серверу, указанному в опциях отдаваемых DHCP сервером и запросить у него, например, файл ldlinux.c32, так вот TFTP сервер должен знать о реальном местоположении файла, чтобы отдать его, например в нашем случае он лежит в disk1/tftpboot/ldlinux.c32. Честно говоря я не экспериментировал, можно ли задать соответствие не отдельным файлам, а папкам или файлам по маскам, поэтому на всякий случай сделал правила для всех файлов на TFTP сервере. После того как мы прописали правила необходимо настроить наш DHCP сервер.

Переходим на закладку IP -> DHCP Server -> Networks в Mikrotik, выбираем нашу подсеть и делаем там следующие настройки:


На этом приготовления к первому запуску закончены. Можно брать любой ПК и пробовать загрузиться по сети. Для меня наиболее простым решением было создание отдельной виртуальной машины в VirtualBox и настройка ее на загрузку по сети. В результате, если все сделано правильно, вы увидите вот такую вот симпатичную менюшку PXELinux:


Сама конфигурация этого меню находится в файле disk1/tftpboot/ubuntu-installer/amd64/boot-screens/menu.cfg . Если мы попробуем загрузиться в Kolibri OS для примера, то заметим что передача казалось бы маленького (всего 66.5 Mb) образа kolibri.iso через TFTP даже по гигабитной сети займет довольно продолжительное время:


Связано это с тем, что протокол TFTP не предназначен для передачи тяжеловесных файлов и в этом отношении работает крайне медленно (плюс еще, как вы понимаете, USB порт в Mikrotik'е, да и флешка не являются высокоскоростными), поэтому хранить на этой флешке какие-то тяжеловесные образы, например тот же Hirens Boot CD, который занимает ~650 Mb и отдавать их по TFTP устройствам - превращается в настоящую муку. Т.е. грузится - да, но оЧЧень медленно. Первая мысль которая приходит в голову - а что если в качестве средства доставки тяжеловесного контента использовать не TFTP, а HTTP или NFS? И да, действительно, такая возможность есть.

Посмотрите как реализована в конфигурации (menu.cfg) загрузка того же Ubuntu LiveCD:

label Ubuntu 16.04 LiveCD [RU]
 kernel ubuntu-installer/amd64/vmlinuz.efi
 append nfsroot=172.17.112.46:/nfs/Public/iso/ubuntu16.04_live_amd64/ netboot=nfs ro file=/cdrom/preseed/ubuntu.seed boot=casper initrd=ubuntu-installer/amd64/initrd.lz locale=ru_RU bootkbd=ru console-setup/layoutcode=ru --

Здесь ядро vmlinuz.efi и рамдиск initrd.lz у нас грузятся по TFTP, а вот содержимое rootfs уже берется с NFS ресурса (благо Ubuntu так умеет). Порядок создания папки ubuntu16.04_live_amd64 на NFS ресурсе описан тут.

Ну или если вкратце, то я создал отдельную папку на WDMyCloud EX2, разрешил доступ к ней по NFS:


Затем смонтировал ее на машине с Ubuntu в ~/nfs и просто скопировал необходимые файлы с LiveCD с Ubuntu в нее:

sudo apt-get install nfs-kernel-server nfs-common # добавляем поддержку NFS в Ubuntu
sudo mount -t nfs -O uid=1000,iocharset=utf-8 172.17.112.46:/nfs/Public/iso ~/nfs # монтируем NFS шару в ~/nfs
wget http://mirror.yandex.ru/ubuntu-releases/16.04/ubuntu-16.04.2-desktop-amd64.iso # качаем LiveCD с Ubuntu
sudo mount -o loop ubuntu-16.04.2-desktop-amd64.iso /mnt # монтируем его в /mnt
mkdir -p ~/nfs/ubuntu16.04_live_amd64 # создаем папку на nfs шаре
sudo cp -a /mnt/. ~/nfs/ubuntu16.04_live_amd64 # копируем все файлы с LiveCD в нее

В результате содержимое папки ubuntu16.04_live_amd64 у нас полностью идентично корню LiveCD с Ubuntu:


Просто? Просто. Теперь пробуем загрузиться по PXE выбрав в меню LiveCD:


С гигабитной сетью все получилось достаточно быстро. Основное время здесь правда тратится на загрузку vmlinuz.efi (7 Mb) и initrd.lz (27 Mb) по TFTP. И вот здесь мы подходим к главному? А можно ли как-то грузить эти файлы тоже с NFS или с HTTP ресурса? Можно! И ответом здесь является использование вместо PXELinux (который к сожалению так не умеет), загрузчика iPXE. Настоятельно рекомендую вам познакомиться с ним и изучить примеры и т.п. на официальном сайте. В архив pxe-mikrotik-disk1.rar уже входит ipxe.lkrn , собранный мной из исходников с включенной поддержкой HTTP, NFS и т.п.:


Обратите внимание, есть поддержка DNS, HTTP, iSCSI, NFS, TFTP и др. вещей. Т.е. грубо говоря используя iPXE вы можете разместить необходимые файлы не только на NFS шаре, но и где-нибудь в интернете, например, на http://yourdomain.ru/files/ ... и загрузчик будет брать их оттуда. При выборе опции Load iPXE SuperBoot Menu в PXELinux открывается меню загрузчика iPXE:


И вот здесь уже, согласитесь, есть чем впечатлиться. Сама конфигурация этого меню находится в файле boot.ipxe, который был взят мной из этого проекта bradgillap/IPXEBOOT на GitHub'е. Внутри подробные примеры и комментарии для всех вариантов загрузки, фактически это означает что вы с минимальными усилиями сможете настроить у себя загрузку любого из приведенных пунктов меню, просто разместив необходимые файлы у себя в сети и скорректировав boot.ipxe .

Ну и последнее о чем хотелось бы рассказать - это о загрузке *.wim образов WinPE через PXE. Для этого в моем примере используется именно iPXE и wimboot. Пример конфигурации вы можете увидеть в menu.cfg от PXELinux в пункте меню "Load iPXE [wim-boot.ipxe]". Фактически там грузится ipxe.lkrn, который читает файл конфига wim-boot.ipxe. Просто размещаете файлы wimboot, bootmgr, bcd, boot.sdi и boot.wim вашего WinPE дистрибутива где-либо в сети (на HTTP, NFS ресурсах) и все замечательно загружается. Примеры опять же, смотрите в wim-boot.ipxe.

Кстати, в меню iPXE SuperBoot от bradgillap есть пункт External Linux Installs. Фактически это внешнее (т.е. находящееся в интернет) загрузочное меню, которое позволяет вам установить некоторые Linux-based ОС, а также загрузить некоторые варианты LiveCD онлайн. Т.е. для того чтобы установить тот же Ubuntu, фактически достаточно только соответствующим образом сконфигурировать DHCP . Все остальное, даже на этапе загрузочного меню может быть взято из сети.

p.s. Чуть не забыл ;) Архив pxe-mikrotik-disk1.rar со всеми необходимыми загрузчиками и примерами конфигураций (пароль на архив стандартный - decker.su). Также буду рад любым вашим мнениям и отзывам в комментариях. Если у вас уже есть свои конфигурации для PXE загрузки распространенных LiveCD дистрибутивов, например, DrWeb Live CD, Kaspersky Rescue Disc и др. популярных инструментов - делитесь ими в комментариях. Также, если у кого-то есть опыт (или ссылки на соответствующие статьи) о настройке бездисковых RDP клиентов, например на базе Thinstation - это тоже приветствуется.

Как вы уже поняли, я далеко не гуру в Linux'е и по-сути как работает PXE я узнал только вчера. Поэтому в архиве по факту используется несколько загрузчиков: PXELinus (SysLinux) как основной, а из него уже можно загрузить iPXE или Grub4DOS, хотя по факту, в реальной жизни достаточно использовать что-то одно. Все это оставлено просто в качестве примера, чтобы было наглядно понятно как работать и с тем, и с другим, и с третьим. Так что, как говорится, "ногами не пинать", а ценные комментарии всегда приветствуются.