- PXE — грузим всё! Осваиваем мультизагрузку по локальной сети
- Содержание статьи
- Xakep #201. Как стать киборгом
- Что будем реализовывать?
- Собираем все в кучу и взлетаем
- Syslinux. Ставим загрузчик
- Раздел Linux. Готовим на примере Ubuntu 14.04
- Тонкие клиенты / Thinstation Linux
- Acronis
- Windows PE
- Заключение
- Александр «Plus» Рак
- Pxe iscsi boot windows
PXE — грузим всё! Осваиваем мультизагрузку по локальной сети
Содержание статьи
Сегодня автоматизируется все больше задач, для максимальной отдачи серверов все шире используют виртуализацию. Но устанавливать операционки по-прежнему приходится. Каждый делает это по-своему: у кого-то полные карманы различных образов на все случаи жизни, кто-то по старинке носит с собой «барсетку» с дисками, а то и две. Как правило, администраторы выполняют эту работу с невеликим удовольствием. Давай посмотрим, как сократить время на тривиальные задачи, как научить компьютеры устанавливать системы самостоятельно, вообще без участия админа, используя при этом только локальную сеть.
Итак, сегодня мы научимся: устанавливать Windows и Linux по сети, грузить небольшие ISO-образы, полезный софт (всяких там Касперских, Акронис, WinPE, мемтесты), разворачивать тонкие клиенты и рулить ими. Чтобы, например, бухгалтер, работающая с 1С по RDP, не прибила тебя за то, что у нее слетела винда, а отчет нужно было подготовить еще вчера. Или скупой начальник, который не хочет обновлять свой комп, восхитился твоим профессионализмом, когда увидит, как на стареньких компах летает Windows 8. В достижении наших коварных целей нам поможет сервер, предоставляющий загрузку по сети (PXE).
Xakep #201. Как стать киборгом
У любого системного администратора в заначке есть универсальный USB-диск для экстренной реанимации компьютера. Согласись, было бы куда лучше иметь ту же функциональность, используя одну лишь сетевую карту. Нельзя при этом не отметить возможность одновременной работы с несколькими узлами сразу. Итак, исходя из наших потребностей у нас есть два пути решения: использовать PXE или LTSP.
LTSP нам не очень подходит: он призван грузить по сети ОС, установленную на самом сервере, что позволяет использовать приложения сервера LTSP. Это не совсем то, что нам нужно. PXE — инструмент для загрузки компьютера по сети без использования локальных носителей данных, так же как и LTSP. PXE позволяет организовать мультизагрузочное меню загрузки, аналогичное универсальному «USB-реаниматору».
Главное меню загрузки PXE, графический режим
Что будем реализовывать?
Началось все с необходимости иметь под рукой инструмент для удаленной установки Ubuntu/Debian Server по сети, с возможностью загрузки Live CD маленькой системы, вроде SliTaz или Kolibri OS.
Как говорится, аппетит приходит во время еды: намеченное не успели реализовать, а к плану добавился еще ряд «хотелок». В итоге список получился весьма внушительным.
- Тонкие клиенты на базе Thinstation Linux.
- Раздел Linux.
- Установка Ubuntu 14.04 x86.
- Установка Ubuntu 14.04 x64.
- Установка Ubuntu 12.04 x86.
- Установка Ubuntu 12.04 x64.
- Загрузка SliTaz Live CD.
- Раздел Windows.
- Установка Windows 2012.
- Установка Windows 7.
- Acronis.
- Windows PE с пакетом полезного ПО.
- Acronis True Image.
- Legacy BIOS.
- UEFI.
- Acronis Disk Director.
- Legacy BIOS.
- UEFI.
- Касперский Rescue v 10.
- ERD Commander от 5 до 8 через ISO-образ.
- Memtest.
Собираем все в кучу и взлетаем
В качестве дистрибутива для сервера выбор пал на Ubuntu Server 14.04.2 LTS. Можно остановиться на любой другой ОС, разница будет только в синтаксисе. Итак, приступим. Нам потребуется TFTP, DHCP (необязательно установленный на этом же сервере, в роли DHCP-сервера может выступить роутер), сервис для организации сетевой файловой системы NFS. Рассматривать будем только те настройки, которые нас интересуют в рамках темы. Первым делом установим все необходимое, предварительно сделав все обновления:
Параметр -y означает, что на все вопросы отвечаем согласием. Настройка TFTP сводится к правке пары строк в соответствующем месте:
Обрати внимание, параметр TFTP_DIRECTORY=»/var/lib/tftpboot» указывает место расположения корневого каталога TFTP-сервера. После сохранения перезапускаем удобным для себя способом:
Далее настроим DHCP-сервер. Приведу простую конфигурацию файла /etc/dhcp/dhcpd.conf:
Данная конфигурация говорит о том, что DHCP-сервер работает в локальной сети 192.168.0.0/24. Клиенту присваиваются адреса из диапазона 192.168.0.150–192.168.0.200, им будут присвоены параметры шлюза — 192.168.0.1, DNS-сервера — 192.168.0.2 и 192.168.0.5. Класс pxeclients, а именно параметр filename — это имя файла загрузчика, расположенного в корневой папке TFTP-сервера, в нашем случае /var/lib/tftpboot/pxelinux.0, на сервере с адресом 192.168.0.10.
Syslinux. Ставим загрузчик
В качестве загрузчика будем использовать Syslinux. Последнюю версию можно взять здесь. Распаковываем и кладем в /var/lib/tftpboot следующие файлы: ldlinux.c32, libcom32.c32, pxelinux.0 и lpxelinux.0 и каталог boot, в который складываем chain.c32, ldlinux.c32, libcom32.c32, libcom32.elf, libutil.c32, linux.c32, memdisk, menu.c32, vesamenu.c32 (menu.c32 — только текстовое меню, vesamenu.c32 позволяет украсить меню, например добавив фон). Файл меню загрузки по умолчанию должен находиться в /var/lib/tftpboot/pxelinux.cfg/default и иметь вид
На этом этапе загрузчик должен работать и иметь единственный пункт меню «Загрузка с первого жесткого диска». Далее необходимо создать подменю. Чтобы не путаться и не городить огромные файлы, рекомендую вынести подпункты в отдельные файлы меню, например так:
Все, что относится к разделу меню Install/Boot Linux, вынесем в отдельный файл /var/lib/tftpboot/linux. Аналогично выносятся другие пункты меню. Остальные параметры загрузки рассмотрим при добавлении каждого пункта/продукта.
Раздел Linux. Готовим на примере Ubuntu 14.04
Первым пунктом ставим возврат в предыдущий раздел меню. Далее будет установка Ubuntu 14.04 i386 и amd64. Скачиваем образ Ubuntu 14.04 mini.iso, распаковываем, находим прямо в корне два файла: linux и initrd.gz. Напомню, что корневой каталог сервера для загрузки — это каталог TFTP-сервера /var/lib/tftpboot . Исходя из этого, располагаем файлы внутри tftpboot. В случае с установкой Ubuntu, например, в images/linux/ubuntu14/i386 для x86 и в /images/ubuntu14/amd64 для x64 архитектур соответственно. Заметь, пути указаны относительно каталога FTFP-сервера. Здесь можно задавать параметры для установки, для автоматизации процесса установки. Например, задать параметр установки в качестве окружения рабочего стола при установке Debian KDE: append desktop=kde . Следующим шагом запустим маленький SliTaz. Грузить ISO-образы будем через memdisk. Из листинга сверху видно раздел slitaz, memdisk у нас расположен в каталоге boot, сам образ — в каталоге images. Параметры аналогичны тем, что используются в мультизагрузочных дисках.
Тонкие клиенты / Thinstation Linux
Следующим шагом научим запускать тонкие клиенты. Образ Thinstation Linux можно скачать готовый в виде сборки, можно взять конструктор для сборки и собрать самостоятельно. Можно качнуть с GitHub. Будь готов, что в последнем случае для подготовки образа потребуется около 3 Гбайт свободного места и времени в районе часа. Подготовка образа из Git хорошо описана в статье на сайте quaded.com. Я взял сборку с сайта nixts.org. В образе, который мы используем, много «ненужных» файлов, потому что там сразу и загрузчик, и дефолтные конфиги. Берем ядро и образ файловой системы (initrd и vmlinuz), которые складываем, например, в /var/lib/tftpboot/images/thinstation/ . Файлы конфигураций ( thinstation.conf.network , thinstation.hosts , thinstation.conf-user ) располагаем в корневом каталоге TFTP-сервера! Thinstation позволяет при загрузке учитывать MAC-адреса, IP-адреса, определять имя и группировать клиентов, в зависимости от параметров регулировать загрузку, например уводить на разные RDP- или VNC-серверы, сессии. Это позволяет, например, наклепать кучу виртуалок с десктопными операционными системами и посадить каждого клиента на отдельную виртуалку. Для каждого клиента можно также отдельно задавать настройки доступа к локальным устройствам: принтерам, флешкам, дискам, приводам и так далее. В общем, каждый ограничен только своей фантазией, благо вариантов использования с описанием настроек в сети навалом.
Acronis
Продукты Acronis загружаются аналогично инсталляторам Linux-систем. Скачал в Сети первый попавшийся образ Acronis, исключительно в научных целях. Распаковал. Нас интересуют только два каталога: ADD12 и ATI2015. Внутри каждого каталога видим по два файла с одинаковым именем и разным расширением. Это сделано для загрузки на 32-битных и x64-системах. Если открыть файл menu.lst того же образа, можно посмотреть, что чему соответствует. Для удобства складываем True Image и Disk Director аналогичным образом. Создаем папку acronis в рабочем каталоге ( /var/lib/tftpboot ). В него копируем ADD12 и ATI2015 со всем содержимым. Для удобства продукты Acronis выносим в отдельный раздел меню, так же как и раздел Linux. В pxelinux.cfg/default добавляем:
Файл acronis приводим к такому виду:
Windows PE
Windows-образы грузить несколько сложнее. В реализации загрузки практически любого WinPE-образа с любым содержимым внутри нам поможет загрузчик WIMBoot. WIMBoot — это системный загрузчик WIM-образов по сети. Довольно хорошо о самом продукте рассказывается на сайте, там же есть ссылка на скачивание. На сайте Microsoft есть инструкция по созданию WIM-образов. Образ, с которым я работал, был щедро вручен мне нашим системным администратором с продуктами Акронис. Назывался он Acronis_WinPE_Sergei_Strelec_25.11.2013.iso . Распаковав его, увидел в папке source заветный образ acronis.wim . Для WIM-образов для большего порядка использую отдельный каталог wim. Чтобы не путаться, внутри сделал еще один каталог winpe. В него копируем acronis.wim . Еще нам потребуются два файла из каталога BOOT этого же образа: BCD, BOOT.SDI и файл BOOTMGR из корня образа. На этом образ можно закрыть, удалить, больше он не пригодится. Переходим к подготовке загрузчиков (WIMBoot и syslinux). Распаковываем куда-нибудь архив wimboot-latest.zip . Копируем загрузчик WIMBoot на сервер TFTP, для удобства в каталог boot. Поскольку образ содержит Windows PE и различное программное обеспечение, в том числе и Acronis, то отнести можно в любой раздел меню. Я расположил его в главном меню. Итак, в файл pxelinux.cfg/default вносим изменения:
Заключение
На этом всё. В следующей статье мы научимся подготавливать и добавлять Windows-образы, сетевой установке в ручном и автоматическом режимах. Добавим Kaspersky Rescue v10, ERD Commander, именуемый MSDaRT. Разберемся, как запускать диагностические утилиты на примере memtest, а также покажем, как украсить меню загрузки.
Александр «Plus» Рак
Участник сообщества OmskLUG. Инженер отдела электронного взаимодействия МКУ «Информационно-технического управления».
Pxe iscsi boot windows
I’m making loads of progress with iPXE, and I love it. But, i’m having tons of problems with windows and iSCSI boot. So, let me back up and give you some troubleshooting information.
I am using both undionly.kpxe and ipxe.kpxe, built from a git pull from a few weeks back. version is 1.0.0 + (d0bfd)
my DHCP server is configured to give out undionly.kpxe, and I have a script that loads from which I can chain over to the full ipxe.kpxe when needed.
I have successfully built a linux diskless client that boots from iSCSI. Its screaming fast. My iSCSI server is an HP DL380 G7 running ubuntu server and the iscsitarget software stack. Seems to work very well, no problems with either using iSCSI to boot ISO images and also my linux diskless image.
However, when I try using it with Windows, it is crazy, terribly slow. I have a custom PE image that I load using iPXE and winboot, works great.
So, here’s what I tried to get windows installed:
grab the shell and do a sanhook iscsi:192.168.15.25. iqn.2016-01.com.mjbrowns:mbstudio
(works, maps to 0x80)
proceed to winboot my PE image. Image takes longer than usual to boot, but when it finishes, I can see the ISCSI device, but any I/Os to it take forever. diskpart clean (to clean the disk headers) took over 10 minutes!
I’ve tried this sequence inserting a variety of:
set keep-san 1
set netX/gateway 0.0.0.0
I also put a disk in, booted, mapped the iSCSI LUN and cloned the boot disk (using Paragon Partition Manger) to the ISCSI disk, then shut down, removed the drive and tried to do a sanboot — it basically just seems to hang on the logo screen and goes nowhere.
I’ve tried Strategy #1 using both physical diskless client and virtual machine in VMware Workstation running on my laptop -same thing happens.
brownmit  iPXE User  | Posts: 4 Joined: 2016-Feb Reputation: 0 |
I may be making a habit of getting frustrated, posting a message to the forums, then figuring it out myself 
Once again, here’s what I learned that may help other people.
First of all, and most importantly, Microsoft has broken installation of Windows 10 via ISCSI. You can get it to deploy the image but you will end up with an inaccessible boot device error when it goes on to the second phase of installation.
The short answer is that what you need to do is to follow this process:
1. Install Windows 10 on a local hard drive
2. iPXE boot with iSCSI sanhook device to a PE environment loaded up with HD copy tools
3. Copy your fully installed Windows 10 HD to the iSCSI device
4. Shut Down, remove local HD, boot to iSCSI device.
There are however, some things you really need to know, that I learned the hard way from various experimentation.
1. With Windows, this will NOT work with undionly.kpxe. You must use the full iPXE stack or when windows switches out of preboot it will lose the connection to your iSCSI drive and you end up with inaccessible boot device.
2. With Windows 8 and later, when you first boot off the iSCSI HD, you will get an error about unsigned drivers. You can deal with this in two ways. One, hit F8 and select the option to enable unsigned drivers, or Two, make sure the PE environment you used in step 2 above has EasyBCD or something similar so you can tweak this flag in the BCD before you reboot.
3. Its incredibly important to have set netX/gateway 0.0.0.0 before your sanboot command otherwise it will take a VERY long time to boot (10 min +)
4. It is helpful to set initiator-iqn properly in your ipxe script. This can avoid issues with secured iSCSI devices.
5. I’m not certain if it’s important or not to use root-path; it seemed to be important when doing my Windows 7 iSCSI install testing, but once installed it doesn’t seem to be needed.
Here’s my boot script that works, again, using the full ipxe.pxe/ipxe.lkrn rather than undionly.kpxe
#!ipxe
set iqn-base iqn.2016-01.com.mydomain
set client mysystem
set initiator-iqn $
set root-path iscsi:$
set netX/gateway 0.0.0.0
sanboot -k $
Here’s a copy of my script that I used to boot into a PE environment with the iSCSI LUN attached:
set iqn-base iqn.2016-01.com.mydomain
set client mysystem
set initiator-iqn $
set root-path iscsi:$
set netX/gateway 0.0.0.0
set keep-san 1
sanhook -d 0x80 $
set wpath $
kernel $
initrd $
initrd $
initrd $
initrd $
boot
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
Following your instructions, I installed Win10 onto a local ssd, started iscsi initiator & press yes. Booted to w10pese, used macrium free to clone the disk to an iscsi disk (scst). Booting into this w10 iscsi disk gives me «Preparing automatic repair»
what have i done wrong?
| pazhanii iPXE User | Posts: 11 Joined: 2015-May Reputation: 0 |
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
has this to do with «driver signature»? which ive already disabled via f8 prior to copying to iscsi disk.
so how did you fix it?
| pazhanii iPXE User | Posts: 11 Joined: 2015-May Reputation: 0 |
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
 | MultimediaMan iPXE Fan | Posts: 199 Joined: 2011-May Reputation: 8 |
Bringing the answer from ipxedevel.list: Please use the latest GIT Version (cc9f31 or later); MCB noted a regression and fixed in this commit:
librm] Do not unconditionally preserve flags across virt_call()
Commit 196f0f2 («[librm] Convert prot_call() to a real-mode near
call») introduced a regression in which any deliberate modification to
the low 16 bits of the CPU flags (in struct i386_all_regs) would be
overwritten with the original flags value at the time of entry to
prot_call().
The regression arose because the alignment requirements of the
protected-mode stack necessitated the insertion of two bytes of
padding immediately below the prot_call() return address. The
solution chosen was to extend the existing «pushfl / popfl» pair to
«pushfw;pushfl / popfl;popfw». The extra «pushfw / popfw» appears at
first glance to be a no-op, but fails to take into account the fact
that the flags restored by popfl may have been deliberately modified
by the protected-mode function.
Fix by replacing «pushfw / popfw» with «pushw %ss / popw %ss». While
%ss does appear within struct i386_all_regs, any modification to the
stored value has always been ignored by prot_call() anyway.
The most visible symptom of this regression was that SAN booting would
fail since every INT 13 call would be chained to the original INT 13
vector.
Reported-by: Vishvananda Ishaya
Reported-by: Jamie Thompson
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
on the latest ipxe right now.. still getting the same problem.
funny thing is i can enter command prompt and list the drives content, which does mean that theres iscsi connectivity.
| | MultimediaMan iPXE Fan | Posts: 199 Joined: 2011-May Reputation: 8 |
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
| | MultimediaMan iPXE Fan | Posts: 199 Joined: 2011-May Reputation: 8 |
(2016-03-13 09:33) biatche Wrote: I don’t know, but cloning local disk to local disk works fine. So if something isn’t right, it should be something related to iscsi/network. i doubt its ipxe/iscsi related problem but more on windows, but anyway thought brownmin would have the answer to it since he has already done it.
match, otherwise the OS won’t know where the target is.
What OS is this?
| biatche iPXE User | Posts: 18 Joined: 2013-Apr Reputation: 0 |
it was fine in win7 though, im quite tempted to test win7 again, although i dont wish to use win7 anymore.
| BofA iPXE User | Posts: 1 Joined: 2016-May Reputation: 0 |
| scan80269 iPXE User | Posts: 12 Joined: 2016-Aug Reputation: 0 |
I just achieved a breakthrough in installing Win10 directly to iSCSI LUNs. I have posted some info on how this is done on the ComputerAudiophile.com site:
I’ve been able to get clients to boot Win10 diskless since early this year, but only recently did I figure out how to do Win10 installations over-the-network into iSCSI LUNs. My previous attempts were plagued by either the dreaded «INACCESSIBLE BOOT DEVICE» or the error «iSCSI deployment is disabled since no NICs referenced in the iBFT can be resolved to actual NT-visible devices» that blocks OS installation into the iSCSI LUN, but now I can install Win10 into iSCSI LUNs without going through physical hard disks or removable storage like USB flash drives.
| scan80269 iPXE User | Posts: 12 Joined: 2016-Aug Reputation: 0 |
(2016-08-13 02:55) scan80269 Wrote: I just achieved a breakthrough in installing Win10 directly to iSCSI LUNs. I have posted some info on how this is done on the ComputerAudiophile.com site:
I’ve been able to get clients to boot Win10 diskless since early this year, but only recently did I figure out how to do Win10 installations over-the-network into iSCSI LUNs. My previous attempts were plagued by either the dreaded «INACCESSIBLE BOOT DEVICE» or the error «iSCSI deployment is disabled since no NICs referenced in the iBFT can be resolved to actual NT-visible devices» that blocks OS installation into the iSCSI LUN, but now I can install Win10 into iSCSI LUNs without going through physical hard disks or removable storage like USB flash drives.
I’d like to clarify that my success in installing Win10 directly into iSCSI virtual drive is limited to Windows 10 Anniversary Edition (Version 1607 «Redstone 1»). The same procedure continues to fail with Windows 10 Version 1511 («Threshold 2») and Windows 10 RTM (build 10240).
It may also depend on whether the NIC in the system has inbox driver support by the OS. Apparently Win10 Anniversary Edition has improved inbox NIC support to enable over-the-network OS installation into iSCSI virtual drive.
| Snowbird iPXE User | Posts: 3 Joined: 2012-Feb Reputation: 0 |
(2016-08-13 02:55) scan80269 Wrote: I just achieved a breakthrough in installing Win10 directly to iSCSI LUNs. I have posted some info on how this is done on the ComputerAudiophile.com site:
I’ve been able to get clients to boot Win10 diskless since early this year, but only recently did I figure out how to do Win10 installations over-the-network into iSCSI LUNs. My previous attempts were plagued by either the dreaded «INACCESSIBLE BOOT DEVICE» or the error «iSCSI deployment is disabled since no NICs referenced in the iBFT can be resolved to actual NT-visible devices» that blocks OS installation into the iSCSI LUN, but now I can install Win10 into iSCSI LUNs without going through physical hard disks or removable storage like USB flash drives.
I’d like to clarify that my success in installing Win10 directly into iSCSI virtual drive is limited to Windows 10 Anniversary Edition (Version 1607 «Redstone 1»). The same procedure continues to fail with Windows 10 Version 1511 («Threshold 2») and Windows 10 RTM (build 10240).
It may also depend on whether the NIC in the system has inbox driver support by the OS. Apparently Win10 Anniversary Edition has improved inbox NIC support to enable over-the-network OS installation into iSCSI virtual drive.
