Installing windows over a network with linux. AOMEI PXE Boot: Booting computers over the network from a disk image file

For a long time it remained a mystery to me why Ubuntu has only two installation disk options - Desktop and Alternate. In Debian, in addition to the usual full installation disks that install the full GNOME or KDE at once, there is also a NetInstall disk designed for installing the system over the network.

A boot CD in this version is designed to launch an installer that installs the minimum required set of packages. Everything else is downloaded and installed from the network if necessary. This option requires greater qualifications of the user performing the installation, but provides flexibility in installing only the necessary system components. This also saves disk space.

It turned out that Ubuntu also has an installation disk option designed for installation over a network. It's just that the download link is not located on the main page of the site. And it is hidden at the following address.

I was interested in the question of what minimum size you can get installed Ubuntu without performing special tricks. For the test, it was decided to install Ubuntu from a minimal disk in VirtualBox.

The minimum disk image size is 11MB. This is not much, and allows you to pump it out at any speed, even the smallest one.

But during installation, it is advisable to have a faster Internet channel. Because the minimal disk, apart from the installer itself, does not contain anything. Therefore, during the installation process everything will download. That's all, really!

I made my first attempt to install Ubuntu from a minimal disk by connecting to the Internet via ADSL at a speed of 128 kbps. The installation (mostly downloading packages) took several hours.

For a repeat experiment, we were able to find a connection at a significantly higher speed.

When booting from a minimal disk, we are first greeted with a text prompt:

and then the standard boot graphical(!) Ubuntu menu:

The existing "Command-line install" item does not mean that the installation will be done from the command line. In any case, the installer starts in text mode.

The “Advanced options” item contains an additional menu:

allowing you to perform Expert install. When you select it, a menu appears with installation actions, allowing you to perform them in almost random order:

I select the item “Install”.

The text installer is normal. Same as in Alternate disk. The only difference is that the packages are not taken from the disk, but are downloaded over the network.

The installer traditionally asks for the language:

configures the keyboard layout:

then prompts you to select a repository:

which by default is offered local for the selected country:

In server rooms, servers without CD/DVD drives are increasingly being found. From time to time they need to install an operating system, and installing over a network can greatly help with this. You simply turn on the server and begin the installation. The network card must support PXE technology. PXE - Pre-Boot Execution Environment - allows you to boot over the network.

But PXE is not enough for complete happiness; a technology that will completely automate the installation is kickstart (developed by Red Hat). Its essence is simple - we compile a file in advance containing the values ​​of all options that may be needed during installation. Moreover, we can execute our scripts before and after installation, thereby setting the settings for the future OS.

Installing a typical Linux kit using kickstart takes 5-7 minutes.

The Install server requires 3 services and 1 package.

• DHCP provides clients with network credentials


• TFTP is an easy way to share files over the network


• Syslinux contains the pxelinux.0 bootloader and some other files


• NFS allows file system access over the network

The installation process can be divided into stages:

1. pxe - pxe firmware starts working when we set the installation over the network in the BIOS, or when the MBR is not found on the HDD.


2. DHCP phase 1 - the client receives network details and the address of the tftp server, as well as the name of the loader file (pxelinux.0). By default, the TFTP server is a DHCP server.


3. TFTP - the pxelinux.0 loader contacts the TFTP server and requests from it initrd.img (Initial RAM disk, temporary file system), the Linux kernel.


4. Kernel - transfer of control to the Linux kernel.


5. DHCP phase 2 - the Linux kernel makes a request to the DHCP server to obtain network details and subsequently the NFS server address.


6. NFS - the stage when the NFS partition is mounted


7. init - /sbin/init is launched and control is transferred to it. Init is the main process in the system, other processes are child processes of init.

Freely stated:

The DHCP server listens for bootp requests on its network; after it receives a request, it looks at the source MAC address, and if it has a corresponding entry for that MAC address, it starts working with it. The DHCP server provides the client with network details (IP address, gateway, DNS server,...) and sends the boot image pxelinux.0 using the TFTP protocol. This image is enough to display the OS selection menu.

Having selected the OS, we begin loading the kernel and begin the installation, in the process selecting the installation source - the NFS server. You need to upload the prepared content of the future operating system to the NFS server and make sure that the corresponding directories are exported.

DHCP

Install DHCPD and add it to startup:
# yum -y install dhcp
# chkconfig dhcpd on

Make the file /etc/dhcpd.conf like this:

Ddns-update-style interim;
ignore client-updates;
subnet 192.168.146.0 netmask 255.255.255.0 (
option routers 192.168.146.1;
option subnet-mask 255.255.255.0;
option domain-name "domain.local";
option domain-name-servers 192.168.146.1;
default-lease-time 21600;
max-lease-time 43200;
Allow boot;
Allow booting;
host unixbox (
hardware ethernet 00:0c:29:77:9c:9c;
fixed-address 192.168.146.128;
filename "pxelinux.0";
option host-name "unixbox";
next-server 192.168.146.1;
}
}

Launch DHCPD or reboot if it was running:
# service dhcpd restart

Disable the firewall, which is enabled by default (otherwise the target computer will receive the error “ICMP Destination unreachable (Host administratively prohibited)” upon boot):
# service iptables stop
# chkconfig iptables off

TFTP

Install the tftp-server package from the repository:
# yum -y install tftp-server

Now you need to enable tftp in the xinetd configuration; to do this, in the /etc/xinetd.d/tftp file, change “disable = yes” to “disable = no” and enable xinetd:
# service xinetd start

We check that the tftp server port is listening (tftp runs on port 69):
# netstat -nlp | grep:69
udp 0 0 0.0.0.0:69 0.0.0.0:* 3105/xinetd

Syslinux

The package contains a set of files for downloading over the network. We need pxelinux.0, which we will serve as a boot image via DHCP, and menu.c32, with which a more attractive user menu will be drawn. (For CentOS 4, the updated syslinux with dependencies must be downloaded from rpmfind.net.)

# cp $(rpm -ql syslinux | grep menu.c32) /tftpboot/
# cp $(rpm -ql syslinux | grep pxelinux.0) /tftpboot/

NFS

By default, the system most likely has NFS, if not, install it using yum.
# chkconfig nfs on

Add an entry to the /etc/exports file:
echo “/var/install-server/ *(ro,no_root_squash)” >> /etc/exports

Launch the nfs server:
# service nfs start

We check that the directory has been exported:
#exportfs
/var/install-server

We create the structure of the tftp server, add content to the server:
# mkdir -p /tftpboot/(pxelinux.cfg,centos5_x86)
# mkdir -p /var/install-server/centos5_x86

We mount our DVD with CentOS 5 and upload the contents to /var/install-server/centos5_x86:
# mount /dev/cdrom /mnt/
# cp -r /mnt/* /var/install-server/centos5_x86/
# cp /var/install-server/centos5_x86/images/p xeboot/* /tftpboot/centos5_x86/

In the /tftpboot/pxelinux.cfg directory, create a default file and fill it in as shown below:
default menu.c32

prompt 0
timeout 100

kernel /centos5_x86/vmlinuz
append initrd=/centos52_x86/initrd.img
label Quit
localboot 0

Installing the OS over the network

After all the manipulations described above, we can begin installing the OS. We start our machine with the MAC address 00:0c:29:77:9c:9c, enabling network boot in the BIOS. When the installation begins, we do everything in the standard way, except that in the list of where to install the OS, you need to select NFS, and then, when asked, indicate:
NFS server name: 192.168.146.1
CentOS directory: /var/install-server/centos5_x86

Automate installation with Kickstart

To automate, you need to create a file containing all the necessary information that may be required during the installation process. Such a file is created by the system-config-kickstart program (GUI tool) in any CentOS with X Window:
# yum -y install system-config-kickstart
#system-config-kickstart

After we have created the file using system-config-kickstart, it needs to be transferred to the Install server and made available via one of the HTTP, NFS or FTP protocols. Since the Install server actively uses NFS, we will use it.

In my case, the kickstart file is located in /var/install-server/centos5_x86/centos5_ x86_ks.cfg .

To the file /tftpboot/pxelinux.cfg/default you just need to add the ks directive indicating the location of the kickstart file. Example with kickstart file:
default menu.c32
menu title Linux Install Server. Please choose OS to install.
prompt 0
timeout 100
label CentOS 5 x86 Custom install
kernel /centos5_x86/vmlinuz
append initrd=/centos5_x86/initrd.img
label CentOS 5 x86 Kickstart Install
kernel /centos52_x86/vmlinuz
append initrd=/centos5_x86/initrd.img ks=nfs:192.168.146.1:/var/install-server/c entos5_x86/centos5_x86_ks.cfg
label Quit
localboot 0

Now, having selected “CentOS 5 x86 Kickstart Install” in the OS selection menu, we will only have to wait for the server with the OS installed on it.

Below is an example of my Kickstart file. I wanted the installed OS to have the “PermitRootLogin yes” option in the sshd settings. The Kickstart file allows you not only to set OS installation parameters, but also to execute scripts before installation (%pre) and after (%post). This way you can write a lot of tuning scripts and get a completely finished OS in 5-10 minutes of installation.

#platform =x86, AMD64, or Intel EM64T
# System authorization information
auth --useshadow --enablemd5
# System bootloader configuration
bootloader --location=mbr
# Clear the Master Boot Record
zerombr
#Partition clearing information
clearpart --all --initlabel
# Use text mode install
text
# Firewall configuration
firewall --disabled
# Run the Setup Agent on first boot
firstboot --disable
#System keyboard
keyboard us
# System language
lang en_US
# Installation logging level
logging --level=info
# Use NFS installation media
nfs --server=192.168.146.1 --dir=/var/install-server/centos5_x86
# Network information
network --bootproto=dhcp --device=eth0 --onboot=on
#Root password
rootpw --iscrypted $1$Bz09jb2I$hfzh2vApqMjG0sEPsAwNr/
# SELinux configuration
selinux --disabled
# Do not configure the X Window System
skipx
#System timezone
timezone Europe/Moscow
# Install OS instead of upgrade
install
# Disk partitioning information
part swap --bytes-per-inode=4096 --fstype=”swap” --size=512
part / --bytes-per-inode=4096 --fstype=”ext3” --grow --size=1

%post --interp /bin/bash
PATH=/somework
/bin/mkdir$PATH
/bin/sed -e ‘s/#PermitRootLogin yes/PermitRootLogin yes/g’ /etc/ssh/sshd_config > $PATH/sshd_config_edited
/bin/cp $PATH/sshd_config_edited /etc/ssh/sshd_config
/bin/rm -rf $PATH

This article will cover installing Ubuntu Linux from a network boot repository.

So, we will install Ubuntu 10.04 on client computers from server 192.168.0.3, which hosts the network boot server and dhcpd. To install, the repository must have a directory dists/lucid/main/debian-installer. If you add similar directories for other repositories (multiverse, universe, restricted), then at the “Selecting and installing software” stage the list of software will be larger. In this guide I will consider this option. If you made a debmirror mirror, then most likely you don’t have these directories at all. You can download them, for example, from ftp://mirror.yandex.ru. Also, during installation, the installer, regardless of the selected repository, often accesses security.ubuntu.com.

Step 1: Server Installation

Installation of necessary applications:

apt-get install tftpd-hpa openbsd-inetd

Download and unpack the image for network installation:

tar -xvzf netboot.tar.gz -C /var/lib/tftpboot/

chown -R nobody:nogroup /var/lib/tftpboot

For network boot, you need to pass 2 parameters to the client: the name of the boot file and the boot file server (in dhcpd these are the filename and next-server parameters):

next-server 192.168.0.3;
filename "pxelinux.0";

The server is installed, you can install the system.

Step 2: System Installation

To install the system from a server on the network, you must enable network boot (PXE) in the BIOS. If your bios supports the boot menu, then it is better to use it to select the boot device - so that there are no problems if you forget to change the boot order.

If everything is fine, then you will see the installer welcome screen:

• Basic Ubuntu Server
• Name server (DNS)
• Edubuntu server
• LAMP server
• Mail server
• OpenSSH server
• PostgreSQL database
• Print server
• Samba file server
• Ubuntu Enterprise Cloud
• Virtual Machine host
• 2D/3D creation and editing suite
• Audio creation and editing suite
• Edubuntu KDE desktop
• Edubuntu desktop
• Kubuntu desktop
• Kubuntu netbook
• LADSPA and DSSI audio plugins
• Large selection of font packages
• Mythbuntu additional roles
• Mythbuntu frontend
• Mythbuntu master backend
• Mythbuntu slave backend
• Ubuntu Netbook
• Ubuntu Desktop
• Video creation and editing suite
• Xubuntu desktop
• Manual package selection

The article examines in detail the process of deploying a network of "thin clients" running under the control of the Thinstation Linux distribution and using an application server based on Windows 2000

Using diskless Linux stations with network boot

First published in the magazine "System Administrator" N11/2004

Formulation of the problem

The work of an automation department employee is a constant struggle with problems and solving problems that are alternately presented by users, developers of the software being used and the management of the organization. And if the first two areas of work are simply a “struggle for the survivability of the ship,” then the last, as a rule, is a progressive movement forward. It was in the course of solving one of these problems that this article was born.

So, the automation department was tasked with quickly commissioning two new remote offices, each with five to ten people. Both offices and the “head” were connected through VPN technologies into one network. The minimum channel width between three points was 256 Kbps, which fully satisfied our needs. An additional Windows 2000 domain controller was deployed in each office, and the domain was divided into several sites to minimize traffic. Everything described above is a standard solution, and I did not expect any surprises here. The main question for us was how the main work environment of the organization’s employees would behave – a complex automation system, which was quite problematic when working with it even within one site. Originally targeting Novell/BTRIVE 6.15 after network migration to Windows, it ran under Windows/Pervasive.SQL 7.

After a week of testing this main business application of the organization, it turned out that the developer did not leave us a choice at all, since the use of the built-in terminal mode of the automated system used did not suit us for a number of reasons. Again, due to the operating features, the Microsoft Windows Server platform was chosen as the terminal server. We did not test Citrix solutions, since working with “native” Windows terminal services completely satisfied us, and the use of add-ons only increases the cost of the entire system.

When everything was decided on the server part, the question arose about the client component of the system. First of all, I would like to reduce the need for administering user machines, since it was not planned to have a dedicated administrator at remote sites. In addition, it seemed desirable to reduce the cost of the solution, which had increased due to the need to purchase terminal licenses. It was also necessary to take into account the intention to place outdated Celeron-400 class computers with RAM from 32 to 64 MB in offices.

From all points of view, it turned out to be ideal to use diskless stations with network loading as workstations. In this case, the only computer that requires the administrator’s attention is an additional domain controller in each office, controlled via VNC. It goes without saying that within the framework of this article I am leaving out of attention the equipment and software that provides traffic encryption, Internet access, etc.

In the role of the OS that will be loaded onto workstations over the network, I chose Linux - which ensures the licensed purity of the solution (at least for now). Access to the Windows 2003 desktop was to be achieved through the development of the www.rdesktop.org project, which became the standard for solving this problem. As the DHCP and TFTP servers necessary for such loading, it would be logical to use the additional Windows 2000 domain controllers already available in each site. Fortunately, there are free DHCP/TFTP implementations for this operating system, as well as built-in servers. However, TFTP is available within the Remote Installation Services (RIS).

Network cards of client machines must naturally support the ability to boot via Etherboot/PXE. In some cases, due to hardware incompatibility, I allowed the use of a boot loader located on a floppy disk.

Selecting a Linux Implementation

When choosing a Linux OS option with the ability to boot over the network, first of all, I paid attention to ready-made distribution kits of a similar focus with a built-in rdesktop package. The most famous of them is NetStation (netstation.sourceforge.net), which has been frozen in beta since the end of 2002, and its successors: PXES (pxes.sourceforge.net), Thinstation (thinstation.sourceforge.net), and DIET-PC (diet-pc.sourceforge.net). At the same time, DIET-PC is intended primarily for users who are familiar with the Linux OS, which immediately excludes it from the scope of consideration. Since the procedure for setting it up is quite painstaking, and DIET-PC contains quite a lot of settings that a mere mortal, and not a Linux guru, will never need. PXES is the most “advanced” with a large number of additional features, including its own graphical environment, which is also unnecessary in my case. In my configuration, the client, bypassing intermediate menus, had to immediately load the remote desktop and go to the Windows 2003 Server password entry window. Thus, I turned my attention to the remaining distribution - Thinstation.

Let's briefly look at its capabilities:

support for X, RDP, VNC, SSH, Telnet, ICA and Tarantella protocols;

ability to use the Firefox browser;

work on a PC of x86-100 MHz class with 16 MB of RAM;

the presence of a pre-build image, and the possibility of self-assembly via the web interface;

support for local disks, USB and LPT printers

Of all the boot options, the simplest is PXE using the Etherboot bootloader. In this article, we will follow the simplest path - using a pre-compiled image.

Installation and initial setup

Let's start by downloading from the page http://struktur.kemi.dtu.dk/thinstation/download/, available via a link on the official website, the last of the archives, in my case it was Thinstation-2.0.2-prebuilt-NetBoot .zip. The archive contains everything you need, including the TFTP/DHCP server Tftpd32, which is convenient for initial setup and configuration. By the way, if you use it, I would recommend immediately updating it from the home page, where there is a more recent version. By the way, Tftpd32 (http://tftpd32.jounin.net/) is an excellent program in itself. So much so that it is even recommended by Cisco for some of the needs of the company’s clients.

Having expanded the archive, we get five directories:

BootDisk – floppy disk image with Etherboot bootloader, for PCs with unsupported network cards

BootPXE – PXE bootloader for Etherboot emulation

BuildFiles – examples of configuration files

TFtp – Tftpd32 server

TftpdRoot – root directory of the TFTP server

So, first of all, we launch the self-extracting archive thinstation.nbi (autoextract).exe, containing one single thinstation.nbi file. The archive was made so that you have the opportunity to familiarize yourself with the “CITRIX(R) LICENSE AGREEMENT”.

Now we copy TFtp and TftpdRoot to a Windows server in our network segment. When using Tftpd32, any Windows machine with a static IP address can act as such a server. Let's say we copied both directories to the C:\ drive. We launch C:\TFtp\Tftpd32.exe for execution. The appearance of the program window is shown in the figure.

You must set the server parameters. Click the “Settings” button and enter the value “C:\TftpdRoot” as the “Base directory”. Next, go to the “DHCP server” tab. There you need to specify the starting IP address allocated by the DHCP server (“IP pool starting address”), the size of the address pool (“Size of pool”), the subnet mask (“Mask”), the name of the file with the Etherboot loader (“Boot file” ), in our case it is thinstation.nbi.zpxe. Click the “Save” button to save the settings and close the application.

Everything is ready to go. You can try turning on one of the machines with a network card that supports PXE boot, remembering to set the boot order in the station's BIOS. When turned on, the machine must obtain an IP address from the allocated range and download the thinstation.nbi.zpxe file via TFTP. It contains a bootloader that emulates the operation of a network card with Etherboot support. Then, control is transferred to the bootloader, which in turn once again requests an address via DHCP and downloads a file with a name that matches the file name of the bootloader itself minus the zpxe extension, that is, thinstation.nbi. This file is the Thinstation image. When the image is loaded, Thinstation tries to load the configuration file thinstation.conf- from the root directory of the TFTP server, then thinstation.conf- . If such files are found, then Thinstation combines their contents with the general configuration file thinstation.conf.network, which, unlike the two listed above, must be present on the TFTP server. Try to avoid conflicts between the main settings file and the group-specific or station-specific ones. In addition, you can combine entire groups of IP and MAC addresses with one configuration file. This is done using the thinstation.hosts file, which has the following format:

# HOST MAC GROUPS COMMENTS ws-oper1 0002B3655065 hi_res # Operator No. 1 ws-oper2 0002B3651075 hi_res # Operator No. 2 ws-oper3 0002B365A021 hi_res ssh_en # Operator No. 3

This example assumes that there are two files thinstation.conf.group-hi_res and thinstation.conf.group-ssh_en. The settings specified in the first file are applied to all three stations, and the settings from the second are applied only to the ws-oper3 computer.

You can see how terminal client sessions are displayed in the Terminal Services Manager snap-in in the figure.

Clients with names like ts_ are just client terminals running Thinstation. Clients with names like P run under the PXES distribution, which is beyond the scope of this article. Next, I will provide a simple but fully functional version of the configuration file with comments. # Session options # # The first session must start with number 0. # If there is no need to select a session, for example when you are using # only rdesktop, you can uncomment the following parameter, and # exclude the session selection menu. #AUTOSTART=On SESSION_0_TITLE="Windows 2003 terminal server (16 bit color depth)" SESSION_0_TYPE=rdesktop SESSION_0_RDESKTOP_SERVER=192.168.0.1 SESSION_0_RDESKTOP_OPTIONS="-u Administrator -p password -a 16" SESSION_1_TITLE="VNC server" SESSION_1_TYPE=vncviewer SESSION_1_VNCVIEWER_SERVER=192.168.0.2 SESSION_2_TITLE="Telnet server" SESSION_2_TYPE=telnet SESSION_2_TELNET_SERVER=192.168.0.3 SESSION_3_TITLE="SSH server" SESSION_3_TYPE=ssh SESSION_3_SSH_SERVER=192.168.0.4 # Общие опции # # Раскладка клавиатуры. В случае работы с rdesktop она роли не играет KEYBOARD_MAP=en_us # Опции XServer # SCREEN_RESOLUTION="1024x768" SCREEN_COLOR_DEPTH="16" SCREEN_HORIZSYNC="30-64" SCREEN_VERTREFRESH="56-87" MOUSE_RESOLUTION=100 # Опции печати # PRINTER_0_NAME=usb PRINTER_0_DEVICE=/dev/usb/lp0 PRINTER_2_TYPE=U !}

In conclusion of the article, I would like to say that after debugging the work with terminal clients, it is best to transfer the functions of TFTP and DHCP servers to software that can work in service mode on Windows NT/2000/2003/XP, for example, as I already said, “ native" Windows services, or use the corresponding services of any other operating system.

In addition, on the project website thinstation.sourceforge.net using the web interface, you can independently recompile the Thinstation image without downloading source codes, including any functions missing in the prebuild image, for example, a browser, or excluding unnecessary modules.

Andrey Markelov. Andrey Markelov (www.markelov.net) - Using diskless Linux stations with network loading

Everyone who even occasionally does administration has needed to install an operating system on their computer at least once. And often everything happens like this: the image is downloaded, written to a disk or flash drive, loaded and installed. But it may turn out that you don’t have a flash drive or disk at hand, and the installation needs to be completed yesterday... Then you can boot over the network, and there are no particular problems with Linux in this regard. A typical configuration is a bunch DHCP, TFTP And NFS. But I didn’t have it set up at hand NFS, but there was Samba. So I had to figure out how to use Samba instead of NFS.

It seemed like nothing, I changed the settings and that’s it, but something didn’t work at first, I had to tinker...

But I'll start from the very beginning here. So first you need to get a distribution kit. Since we put Linux Mint We are looking for a fresh image. Download the distribution that suits us (I installed the one with MATE, but obviously this doesn't really matter). After downloading the image, you need to gain access to the image files. Some guides recommend unpacking the image, but I don’t see the point in this, so I support the opinion that is to mount the image as loop. In order not to interfere with the existing order, we simply create a new directory where we mount the image:

# mkdir /mnt/mint
# mount -o loop /home/user/download/linuxmint-17-mate-64bit-v2.iso /mnt/mint

Next, you need to make the files available over the network for the installer to read. As I said above, for this purpose I use Samba. Therefore, open the configuration file and add a new share by adding the following section:

path = /mnt/mint
available = yes
browsable = yes
public = yes
writable = no

Should work over default settings Samba. If it doesn’t work, then most likely you changed something yourself, which means you’ll find a way to solve the problem. So we added the ball mint, through which you can get files for installation from the network. Don't forget to restart Samba to accept the new settings.

For Archlinux:

# systemctl restart smbd
# systemctl restart nmbd

For Gentoo:

# /etc/init.d/samba restart

Next you need to prepare a network bootloader. The program will help us with this tftp-hpa. IN Archlinux and in Gentoo That's what the package is called. You need to place the loader files in the working directory of the ftp server (in arch /srv/tftp). Copy the kernel and initrd from the mounted image there:

# cp /mnt/mint/casper/(vmlinux,initrd.lz) /srv/http

# cp /usr/lib/syslinux/bios/(pxelinux.0,menu.c32,ldlinux.c32,libutil.c32) /srv/http

DEFAULT menu.c32
LABEL LinuxMint
KERNEL vmlinuz
APPEND showmounts toram root=/dev/cifs boot=casper netboot=cifs nfsroot=//192.168.0.1/mint NFSOPTS=-oguest,ro initrd=initrd.lz nosplash

Where 192.168.0.1 - our IP address relative to the machine on which we will install. Oh yes, and about nfs there - this is not a typo, in the mode of working with cifs, you need to pass type options as for nfs, I can't say why. Particular attention should be paid to the toram option, since without it everything falls off halfway and we cannot boot (maybe these are features of samba). But with this option, you need to remember that the target machine must have enough RAM to copy the installer there. The TFTP server needs to be started. For Archlinux:

# systemctl tftpd.socket start

For Gentoo:

# /etc/init.d/in.tftpd start

Now the BIOS of the target machine needs to somehow tell where it is loading from. This will help us dnsmasq(although not necessary, you can use another DHCP server; here I describe what was at hand). Setting up IP distribution (optional dhcp-range) at your own discretion, for your own “network” between machines. For installation, only three options are important to us:

Dhcp-boot=/pxelinux.0
dhcp-option=vendor:PXEClient,6,2b
pxe-service=x86PC, "Install Linux", pxelinux

They need to be added to the configuration dnsmasq, and of course launch it (or restart).

For Archlinux:

# systemctl start dnsmasq

For Gentoo:

# /etc/init.d/dnsmasq start

Remember, for everything to work, the ports must be on DHCP(UDP 67.68), TFTP(UDP 69), Samba(UDP 137.138, TCP 139.445) must be open; be sure to take this into account in your firewall configuration. If there is no firewall or the interface is completely open - oh well, it should work.

Note: Due to the fact that systems are constantly updated, the given file paths may be invalid, that is, different from those on your system. Therefore, carefully look at the package structure of your system.