Pxe �������� iso linux

Preboot Execution Environment

The Preboot eXecution Environment (PXE, most often pronounced as pixie) specification describes a standardized client-server environment that boots a software assembly, retrieved from a network, on PXE-enabled clients. On the client side it requires only a PXE-capable network interface controller (NIC), and uses a small set of industry-standard network protocols such as DHCP and TFTP.

In this guide, PXE is used to boot the installation media with an appropriate option-rom that supports PXE on the target. This works well when you already have a server set up.

Contents

Preparation

Overview

It is useful to give an overview of the PXE boot process in order to understand the #Server setup, the #Installation on the client side and the Arch Linux files needed.

The client starts by broadcasting packets asking for a DHCP server and containing specific PXE options. The DHCP server responds with networking information (the IP address assigned to the client) and also provides, by using specific bootstrap protocol (BOOTP) parameters of the DHCP, additional information like the TFTP server address, the path of the initial network bootstrap program (NBP) to download or the boot configuration file name.

The NBP is transferred from the PXE server to the client using TFTP, to be loaded into memory and executed. The kernel and the initramfs are also transferred this way.

Then the root filesystem is transferred using one of the following protocols: HTTP, NFS or NBD.

Boot from install media

In order to gather the files that will be transferred from the server to the client for booting, get the latest official install media from the download page.

Next mount the image:

where release_date is the release date in the ISO filename like, e.g., 2020.10.01 .

Boot from netboot

Arch Linux netboot images can be used to download the latest Arch Linux release on the fly upon system boot. Download the image compatible with your configuration.

Pixiecore

A all-in-one solution is provided by pixiecore

1. Install pixiecore-gitAUR
2. Run pixiecore quick arch —dhcp-no-bind as root
3. Boot via PXE

Server setup

You will need to setup a DHCP server, a TFTP server for transferring the NBP and one of the following services for transferring the root filesystem: HTTP server, NFS or NBD.

Network

Bring up your wired network adapter, and assign it an address appropriately.

DHCP + TFTP

You will need both a DHCP server and a TFTP server to configure networking on the install target and to facilitate the transfer of files between the server and the client. dnsmasq does both, and is extremely easy to set up.

dnsmasq needs to be configured. See instructions on how to setup a dnsmasq#TFTP server and a dnsmasq#PXE server.

Are provided below some common configuration instructions. tftp_root is the directory where the Arch ISO is mounted (e.g. /mnt/archiso ) or where the network boot program is located.

To enable the DHCP server and give IPv4 addresses within a range, add to the configuration file a line similar to:

Or in case there is already a DHCP-server running on the network and you want to interoperate with it, see dnsmasq#Proxy DHCP.

Two examples covering different boot style and installation media are provided below.

Once configured according to your needs, start dnsmasq.service .

BIOS boot from install media

The path of the initial bootstrap program to be transferred is defined with the dhcp-boot option in the configuration file.

In order to send specific bootstrap protocol (BOOTP) parameters, like the configuration file path, the dhcp-option-force=flag,value line is used.

UEFI boot from netboot

To send a file depending on the architecture, here the netboot image for UEFI-style boot, use:

If using netboot, the rest of the server setup section which focuses on the Arch ISO does not apply.

Transferring archiso root filesystem

Thanks to archiso_pxe_http , archiso_pxe_nfs and archiso_pxe_nbd initcpio hooks in archiso, it is possible to boot using HTTP, NFS or NBD. Boot time is approximately the same in all three methods, but HTTP method allows you to watch a state of downloading airootfs.sfs in percents.

Among all alternatives, darkhttpd is by far the most trivial to setup (and the lightest-weight).

Then start darkhttpd using our /mnt/archiso as the document root:

You will need to set up an NFS server with an export at the root of your mounted installation media, which would be /mnt/archiso if you followed #Preparation. After setting up the server, add the following line to your /etc/exports file:

If the server was already running, re-export the filesystems with exportfs -r -a -v .

The default settings in the installer expect to find the NFS at /run/archiso/bootmnt , so you will need to edit the boot options. To do this, press Tab on the appropriate boot menu choice and edit the archiso_nfs_srv option accordingly:

Alternatively, you can use /run/archiso/bootmnt for the entire process.

After the kernel loads, the Arch bootstrap image will copy the root filesystem via NFS to the booting host. This can take a little while. Once this completes, you should have a running system.

Install the nbd package and configure it:

where release_date is the release date in the ISO filename like, e.g., 2020.03.01 .

Existing PXE server

If you have an existing PXE server with a PXELINUX system setup (e.g. a combination of DHCP and TFTP), you can add the following menu items to your /tftpboot/pxelinux.cfg/default file in order to boot Arch via your preferred method:

You can replace archiso_http_srv with archiso_nfs_srv for NFS or archiso_nbd_srv for NBD (see usage examples in arch/boot/syslinux/archiso_pxe.cfg file resided on ArchLinux iso). Whichever method you choose, you must pass ip= parameter to instruct the kernel to bring up the network interface before it attempts to mount the installation medium over the network. Passing BOOTIF= is required when there are several wired interfaces on the client side and/or you want resolv.conf to be already configured inside booted archiso. You can use sysappend mask 3 (which is 1+2) to pass these parameters automatically. For available boot parameters see README.bootparams.

Installation

For this portion you will need to figure out how to tell the client to attempt a PXE boot; in the corner of the screen along with the normal post messages, usually there will be some hint on which key to press to try PXE booting first. On an IBM x3650 F12 brings up a boot menu, the first option of which is Network; on a Dell PE 1950/2950 pressing F12 initiates PXE booting directly.

Looking at journald on the PXE server will provide some additional insight to what exactly is going on during the early stages of the PXE boot process:

After you load pxelinux.0 and archiso.cfg via TFTP, you will (hopefully) be presented with a syslinux boot menu with several options, where you can select Boot Arch Linux (x86_64) (HTTP).

Next the kernel and initramfs (appropriate for the architecture you selected) will be transferred, again via TFTP:

If all goes well, you should then see activity on darkhttpd coming from the PXE-target; at this point the kernel would be loaded on the PXE-target, and in init:

After the root filesystem is downloaded via HTTP, you will eventually end up at the normal live system root zsh prompt.

Post-boot

Unless you want all traffic to be routed through your PXE server (which will not work anyway unless you set it up properly), you will want to stop dnsmasq.service and get a new lease on the install target, as appropriate for your network layout.

You can also kill darkhttpd; the target has already downloaded the root filesystem, so it is no longer needed. While you are at it, you can also unmount the installation image:

At this point you can follow the Installation guide.

Low memory systems

The copytoram initramfs option can be used to control whether the root filesystem should be copied to ram in its entirety in early-boot.

It highly recommended to leave this option alone, and should only be disabled if entirely necessary (systems with less than

256MB physical memory). Append copytoram=n to your kernel line if you wish to do so.

Sharing internet with PXE clients

If your network for PXE clients is private (for example, 192.168.1.0/24), and you want them to be able to access internet (for example, for packages installation), you should configure masquerade/source nat properly. Your PXE server must have a separate NIC connected to the internet. You can use such command to pass through the internet to clients:

To make this rule persistent after reboot, run the following command:

Troubleshooting

DHCP interface rename bug

FS#36749 causes default predictable network interface renaming to fail and then DHCP client to fail because of it. A workaround is to add the kernel boot parameter net.ifnames=0 to disable predictable interface names.

VirtualBox cannot boot while real machines can

When using VirtualBox to test your configuration, the virtual machine may get stuck at:

While PXE booting with a real machine works fine. The problem may be because you have set several CPU cores to your client machine, and you set its type as Other and version as Other/Unknown (64 bit). So VirtualBox does not know which paravirtualization interface to use by default.

Adding loglevel=7 to the kernel parameters lets you see where it actually got stuck:

To resolve this, either use one CPU core, or go to Machine > Settings > System > Acceleration and set one of the following paravirtualization interface: Minimal, Hyper-V or KVM.

Источник

Сетевая установка Linux

Недавно столкнулся с установкой Centos 7 в необычных условиях.

Во-первых, дома. То есть имел дело с локальными компьютером, а не с сервером с IPMI.

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

В моем распоряжении осталась сеть. Приведу пример установки Centos 7 по PXE и iPXE

Итак, начнем.

Как установить Linux через ipxe?
Как установить Linux через pxe?

Установка через PXE

Соединим ethernet кабелем компьютер1 — на котором будут DHCP, TFTP и компьютер2 — на который должна быть установлена ОС.

Добавим статичные настройки сетевого адаптера на компьютер1. Мой адрес 192.168.1.50.

Скачаем и установим TFTP. В этой программе настроим DHCP и TFTP сервер с которого отдадим IP адрес и установочные файлы компьютеру2.

Отключим брандмауэр и запустим tftpd с правами администратора. Выставим аналогичные установки, как на картинках. Возможно потребуется перезапуск tftpd.

На компьютере2 в boot меню выберем сетевой адаптер. В окне tftpd на компьютере1 будет отображаться шкала прогресса.

После этого, на компьютере2 загрузится окно инсталлятора ОС.

Установка Linux через iPXE

Скачаем образ ipxe.iso. Rufus-ом создадим загрузочную флешку на основе этого образа.

Выложим скрипт install.ipxe на любой веб сервер. О том, как поднять веб сервер на локальном компьютере можно узнать тут. Адрес моего скрипта будет таким sitename.ru/install.ipxe

Содержимое скрипта install.ipxe для установки Centos 7

По аналогии с этим скриптом для установки Centos 7, можете подготовить свой скрипт для установки другой ОС.

Соединим компьютер, на который необходимо установить Linux, и роутер ethernet кабелем. Вставим флешку и загрузимся с нее. После нажатия F12 появится ipxe консоль. Используем следующие команды для получения IP адреса и скачивания скрипта

После этого загрузится окно инсталлятора ОС.

Источник

PXE загрузка живого образа linux

Пытаюсь сделать pxe-загрузку по сети ubuntu live cd. Настроил isc-dhcp-server. Пробовал syslinux, grub2. Результат пока что один — после опроса оборудования компьютера оказываюсь в busybox.

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

Если использовать grub, то все немножко по другому. Вот boot/grub/grub.cfg:

В обоих случаях результат один — busybox после опроса оборудования. Я видимо не понимаю чего-то очевидного, подскажите куда копать.

Вам нужно посредством NFS расшарить файлы в ISO образе и указать в параметрах ядра адрес этого NFS сервера.

А можно ли как то обойтись без nfs?

А к файлам по tftp доступ есть?

можно ли как то обойтись без nfs?

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

я бы даже спросил — а из bisybox видно, что сеть доступна? Ну там, сетевая карточка определилась? tftp-клиент запускается?

append iso initrd=xubuntu-13.04-desktop-i386.iso

Ты не понимаешь, что это такое. Абсолютно. Как класс.

В обоих случаях результат один — busybox после опроса оборудования.

Ээээ, а что ты ожидал? Я знаю только один способ передачи данных, который работает без носителей: это молитва. Все остальные требуют что-то.

Вот этого я и хочу добиться.

В busybox довольно много команд, ifconfig показывает сетевые карточки. Я в этом далеко не спец, но выглядит это так, будто сам линукс загружен, не загружены только дополнительные пакеты и пользовательское окружение.

Объясните что тут не так..

Вот почитайте официальную документацию по сетевой загрузке Ubuntu LiveCD: https://wiki.ubuntu.com/LiveCDNetboot

Если вы хотите использовать только tftp, то вам нужно редактировать init сценарий в initrd, добавив в него функционал по загрузке в память с tftp сервера iso образа Ubuntu LiveCD, ну или хотя бы sqaushfs образа корневой файловой системы LiveCD системы и дальнейшего монтирования этого squashfs образа из памяти. С учётом того, что squashfs образ размером примерно 700 Мб у вас будут ограничения на минимально требуемый размер оперативной памяти и ввиду того, что нужно предварительно эти 700 Мб скачать по сети, довольно длительное время запуска.

Вот поэтому и нужен nfs, в любом случае там ничего сложного нет.

Читайте официальную документацию, настраивайте.

Ну и ответьте на вопрос чем вас так пугает nfs?

busybox — это утилита, которая включает в себе минимально необходимые команды для подключения в частности реальной корневой системы.

В общем, в initrd находится минимальная система, которая нужна для монтирования реальной корневой файловой системы и последующее переключение в эту файловую систему. Т.е. на этапе загрузки в начале в качестве корневой файловой системы монтируется файловая система в initrd, затем сценарий в initrd монтирует другую файловую систему, которая в последствии станет корневой, а если нужно, то предварительно и файловую систему, например, nfs, на которой находится образ корневой файловой системы, а затем вызывается команда по переключению корневой файловой системы, например pivot_root или switch_root.

Так что раз, как вы пишете, вы не спец, то просто последуйте официальной документации, ссылку на которую я вам привёл, а именно настройте доступ к файлам в iso образе посредством NFS.

nfs нужен для записи.

Потому аргумент «нужно скачивать целиком» не работает — архив можно на сервере разархивировать и пересылать только нужные файлы по tftp.

Нет, nfs нужен для простого доступа к squashfs образу корневой файловой системы Ubuntu LiveCD. К тому же для монтирования squashfs образа его не нужно целиком скачивать по сети, он просто монтируется с смонтированной nfs напрямую.

Потому аргумент «нужно скачивать целиком» не работает — архив можно на сервере разархивировать и пересылать только нужные файлы по tftp.

Как раз таки при использовании tftp, как вы предлагаете, для того, что бы смонтировать squashfs образ корневой файловой системы, его нужно предварительно загрузить целиком в память, ибо tftp — это не файловая системы, а протокол передачи данных. А squashfs образ Live CD системы Ubuntu размером примерно 700 Мб, так что загрузка по сети такой системы будет занимать довольно длительное время. К тому же tftp передаёт пакеты не по tcp, а по udp протоколу, который не гарантирует доставки данных, с учётом этого шанс скачать «битый» squashfs образ возрастает. К тому же ТС придётся по вашим рекомендациям распаковать initrd образ Ubuntu LiveCD, внести правки в init сценарий, добавив код для скачивания по tftp образа squahsfs в память, а затем его смонтировать, ну и потом опять же запаковать initrd.

Вот и получается, что проще, удобнее и надёжнее использовать nfs.

Не надо давать вредные советы, если сами этого не делали, а лишь примерно понимаете как это работает в теории.

Тем более есть официальная документация по сетевой загрузке Ubuntu Live.

Всем спасибо за ответы! Теперь стало понятнее. Попробую покурить в сторону smb, а не nfs, так как самба уже настроена и работает. Посмотрим, если не выйдет буду смотреть в сторону nfs или nbd.

Попробую почитать документацию по smb

держи нас в курсе результатов опытов.

Окей, кое какие подвижки есть.

какие ? тебе удалось запустить smbclient из initramfs ?

Нет конечно ), все уже придумано за нас. С nfs оказалось сильно проще, но с самбой тоже можно все организовать. Судя по этому http://manpages.ubuntu.com/manpages/hardy/man7/casper.7.html загрузку можно осуществлять и с nfs и с cifs файловой системы (параметр netboot). Но трудности возникли с правами на шару.

Сделал я в самбе такую шару:

В общем все оказалось довольно просто, почти так же как с NFS, но тонкости с правами, заглавными буквами и пр.. и опять же это чисто для Убунты, с другими системами все может быть по другому, к примеру арч у меня запускался прямо из .iso-образа, причем довольно шустро, образ сам по себе небольшой.

ps: мне сетевая загрузка убунты или арча (или еще чего) нужна только для того, чтобы сесть за любой компьютер, загрузиться из сети, разметить на компьютере диск (gparted, parted, ntfsprogs)и распаковать на него образ винды (ntfsclone). Вот такие дела.

А вы уверены, что в initrd есть поддержка cifs? Маловероятно, но вы можете распаковать initrd, внести самостоятельно правки в init сценарий для поддержки cifs, запаковать его обратно. К тому же для монтирования samba (cifs) вам нужен в initrd cifs-client (samba-client), к тому же его собрать статически не получится, поэтому вам придётся так же в initrd поместить libc и прочие зависимости, а так же файл mount.cifs, которым как раз и производится монтирование.

Поэтому для вас проще всего, как я вам уже сказал, использовать nfs.

Чем он вас пугает?

Это будет самый простой для вас способ.

UPD: Если судя по приведённой документации поддержка cifs (samba) есть, пробуйте. Но вы сами уже увидели, что nfs проще.

Да, вы сказали все правильно. С nfs оказалось реально проще.

мне сетевая загрузка убунты или арча (или еще чего) нужна только для того, чтобы сесть за любой компьютер, загрузиться из сети, разметить на компьютере диск (gparted, parted, ntfsprogs)и распаковать на него образ винды (ntfsclone).

Clonezilla не подойдёт?

clonezilla-live выглядит подходящей, но меня сейчас и так устраивает =)

Весь комплекс проще заюзать. Или хотя бы доку по нему прочитать 😉

Источник