Parted Magic PXE / Network Boot Guide

Parted Magic may be booted via PXE (Preboot Execution Environment), allowing for deployment of Parted Magic to as many computers as you have connected to your LAN with no need for USB drives or optical disks. It is compatible with standard PXE infrastructure (a DHCP server and a boot server), and it has support for three different protocols (wget and HTTP; TFTP; NFS).

This guide will cover the setup of the server side, how to set up the boot parameters, along with example configurations for each of the three supported protocols.

How It Works

PXE boot sequence for Parted Magic:

The client machine sends out a DHCP request using its PXE ROM. The DHCP server receives the request and sends back an IP address along with the location of a boot loader (pxelinux.0 or ipxe.efi).
The client loads and executes the boot loader that retrieves the bzImage (kernel) and initrd.img (initial ram disk) from either TFTP or HTTP.
Once loaded, the kernel will execute and run the init script in the initrd.img. It will bring up the network via DHCP, and use the protocol named by the netsrc= parameter to retrieve PMAGIC_V.V.SQFS (the primary SquashFS image), as well as any additional files, and load them into memory.
When all files have been retrieved, the client releases its DHCP leases, mounts the SquashFS, and transitions into a fully functional Parted Magic environment.

All of the files you download to the machine get stored in RAM. The machine does not need to use the network at all once it has finished the initial download, and it will continue to run normally even when the network cable gets pulled out.

Boot Parameters Reference

How PXE boots behave is determined entirely by your kernel command line options. This is done via your PXE boot loader config (for example, in pxelinux.cfg/default or an iPXE script).

Required Parameters

Parameter	Description
`netsrc=wget`, `netsrc=tftp`, or `netsrc=nfs`	Selects the download protocol. If `netsrc` is not set, PXE boot is skipped entirely.
`neturl=...`	The URL or address of the boot files on your server. The format depends on which `netsrc` you choose (see protocol-specific sections below).

Optional Parameters

Parameter	Description
`netargs=...`	Extra flags passed directly to the download command (`wget`, `tftp`, or `mount.nfs`). Useful for things like custom timeouts or NFS mount options.
`iso_filename=...`	Not used by a network boot. When Parted Magic boots from an ISO file on a local disk, this names that file if it was renamed from its default `pmagic_V.V.iso`.
`boot=live`	Not usually needed for PXE: the system uses live mode automatically, since the files are already in RAM. Listed here for completeness.
`directory=...`	Not needed for a network boot: the path on the server is part of `neturl=`. It names the subdirectory that holds the `pmagic` tree when Parted Magic boots from a local disk. Defaults to empty.

Server Directory Layout

Regardless of the method of delivery (protocol) that you choose, the server must host the Parted Magic pmodules directory structure. The easiest method to achieve this is by mounting or extracting the Parted Magic ISO file.

Extracting files from the ISO

# Mount the ISO
sudo mkdir -p /mnt/pmagic
sudo mount -o loop pmagic_V.V.iso /mnt/pmagic

# The files you need are here:
ls /mnt/pmagic/pmagic/pmodules/
#   PMAGIC_V.V.SQFS    (main squashfs image, required)
#   *.SQFM              (optional module bundles)
#   scripts/            (optional startup scripts)

The kernel and initrd are contained within the ISO file under the pmagic directory:

ls /mnt/pmagic/pmagic/
#   bzImage             (kernel)
#   initrd.img          (initial ramdisk)

At boot-time via your preferred protocol, the PMAGIC_V.V.SQFS (and any .SQFM bundles) will be downloaded. V.V represents the release. For example, with Parted Magic 26.11_1, the ISO file would be named pmagic_26.11_1.iso and the image would be called PMAGIC_26.11_1.SQFS. The name of the SQFS image has to correspond to the version number built into the initrd.img you boot; therefore, take both from the same ISO.

Or let the ISO lay it out

The ISO’s boot/pxelinux directory has a pm2pxe.sh script that will create a new directory that includes a copy of pmagic/bzImage, pmagic/initrd.img and all files under pmagic/pmodules/ from the mounted ISO. It writes a pxelinux.cfg/default menu for BIOS computers and a grub/grub.cfg menu for UEFI computers, each with entries for HTTP, TFTP and NFS pointing to your server. For UEFI computers it also copies the ISO’s signed boot files, bootx64.efi (shim, signed by Microsoft), grubx64.efi (GRUB for the network, signed by Canonical) and mmx64.efi, so they start with Secure Boot on. You can use this directory as your TFTP root or just copy everything over to your current one. For BIOS computers, add pxelinux.0 and ldlinux.c32 from your syslinux package. Point your DHCP server’s boot file at pxelinux.0 for BIOS computers (client architecture 0) and at bootx64.efi for UEFI computers (client architecture 7, or 9 on some). The script prints these steps when it finishes. Beside it, sample_pxelinux.cfg and sample_grub.cfg are the same two menus written out for a server at 192.168.1.10.

# SERVER is your boot server's address (default 192.168.1.10);
# DIR is the directory to create (default ./pm2pxe)
sh /mnt/pmagic/boot/pxelinux/pm2pxe.sh SERVER DIR

Protocol 1: HTTP (wget)

The recommended method of deployment for most systems. HTTP provides speed, allows for resume of interrupted transfers and will usually work with all standard networking equipment configurations.

Server setup

You can use any HTTP server to serve your pmodules directory. In order for wget --recursive to crawl the directory listing, you must have directory listing turned on.

Example: nginx

# /etc/nginx/sites-available/pmagic
server {
    listen 80;
    server_name pxe.local;

    location /pmagic/ {
        alias /srv/pmagic/pmodules/;
        autoindex on;     # Required: wget needs directory listings
    }
}

Example: Apache

# /etc/apache2/sites-available/pmagic.conf
<VirtualHost *:80>
    Alias /pmagic/ /srv/pmagic/pmodules/
    <Directory /srv/pmagic/pmodules>
        # Indexes is required: wget --recursive reads the listings
        Options +Indexes
        Require all granted
    </Directory>
</VirtualHost>

Example: Python (quick testing)

# Quick and simple: fine for testing, not for production
# Serving /srv puts /srv/pmagic/pmodules under http://SERVER/pmagic/
cd /srv
python3 -m http.server 80

Boot loader configuration

pxelinux / syslinux

# pxelinux.cfg/default
DEFAULT pmagic
LABEL pmagic
    KERNEL pmagic/bzImage
    INITRD pmagic/initrd.img
    APPEND netsrc=wget neturl=http://192.168.1.10/pmagic/

iPXE

#!ipxe
kernel http://192.168.1.10/pmagic/bzImage netsrc=wget neturl=http://192.168.1.10/pmagic/
initrd http://192.168.1.10/pmagic/initrd.img
boot

GRUB (UEFI PXE)

# grub.cfg
menuentry "Parted Magic (PXE)" {
    linux pmagic/bzImage netsrc=wget neturl=http://192.168.1.10/pmagic/
    initrd pmagic/initrd.img
}

How it works internally

The init script performs the following when netsrc=wget:

wget --no-check-certificate \
     --reject index.html* \
     --quiet --continue --show-progress \
     --recursive -nH --no-parent \
     ${netargs} "${neturl}"

It uses wget to recursively transfer every file from the specified URL. It excludes directory listings with the --reject index.html* flag. Once it has completed the recursive transfer, the init script looks for PMAGIC_V.V.SQFS in the transferred directory tree and then relocates everything to where it should be.

Passing extra wget flags

You can add additional arguments to wget via netargs=. For example, if you want to set a timeout for the download:

APPEND netsrc=wget neturl=http://192.168.1.10/pmagic/ netargs=--timeout=30

Protocol 2: TFTP

TFTP is the traditional PXE protocol. All that you require to use TFTP is what you are already using for your PXE boot loader. That being said, TFTP can be much slower than HTTP when working with larger files, does not natively support resuming downloads, and requires you to list every file that needs to be downloaded.

Server setup

Place all the Parted Magic files in your current TFTP root (most likely either /srv/tftp or /tftpboot).

# Copy files into the TFTP root
mkdir -p /srv/tftp/pmagic/pmodules
cp /mnt/pmagic/pmagic/bzImage     /srv/tftp/pmagic/
cp /mnt/pmagic/pmagic/initrd.img  /srv/tftp/pmagic/
cp /mnt/pmagic/pmagic/pmodules/*  /srv/tftp/pmagic/pmodules/

# Verify
ls /srv/tftp/pmagic/pmodules/
#   PMAGIC_V.V.SQFS
#   *.SQFM  (if any)

neturl format for TFTP

The neturl for TFTP uses a colon-separated format instead of a standard URL:

neturl=HOST:PATH:FILE1,FILE2,FILE3

Where:

HOST: IP address or hostname of the TFTP server
PATH: directory path on the TFTP server containing the files (relative to the TFTP root)
FILE1,FILE2,…: comma-separated list of additional files to download besides the main SQFS. The SQFS itself (PMAGIC_V.V.SQFS) is always downloaded automatically, so you do not need to list it here.

Boot loader configuration

Basic: SQFS only (no extra modules)

# pxelinux.cfg/default
DEFAULT pmagic
LABEL pmagic
    KERNEL pmagic/bzImage
    INITRD pmagic/initrd.img
    APPEND netsrc=tftp neturl=192.168.1.10:pmagic/pmodules:

Note how there is a colon at the end of the path. Even if you don’t have any additional files, it still needs to be in the three-field format.

With additional module bundles

# Download SQFS plus two SQFM bundles
APPEND netsrc=tftp neturl=192.168.1.10:pmagic/pmodules:extras.SQFM,tools.SQFM

With scripts in a subdirectory

# Download SQFS plus a startup script
APPEND netsrc=tftp neturl=192.168.1.10:pmagic/pmodules:scripts/autorun.sh

Since subdirectories get generated on the client automatically, you could put something like scripts/autorun.sh into the file list and it would go into the appropriate subdirectory.

Block size tuning

The init script sets the block size to 65535 bytes for the primary SQFS file download and to 32768 bytes for any other files. It attempts to download each file up to three times. When downloading from your TFTP server, if it doesn’t allow large block sizes (some older tftpd implementations), then your downloads will likely fail. Your server should support the TFTP blocksize option; tftpd-hpa and dnsmasq both do this by default.

Protocol 3: NFS

NFS maps the remote directory straight into your file system, then copies all of those files over to memory. So this approach is a good choice for large scale deployments with the same NFS export serving many machines, because the server only has to read them from disk one time (after that, the operating system’s page cache will handle the remainder).

Server setup

# /etc/exports
/srv/pmagic/pmodules    192.168.1.0/24(ro,no_subtree_check,no_root_squash)

# Apply the export
sudo exportfs -ra

# Verify
showmount -e localhost
#   /srv/pmagic/pmodules    192.168.1.0/24

You should have your export set up to be read-only for security. Parted Magic never writes to the NFS share. It takes a complete copy of what exists on the NFS share into RAM and then unmounts it prior to completing the boot process.

Boot loader configuration

# pxelinux.cfg/default
DEFAULT pmagic
LABEL pmagic
    KERNEL pmagic/bzImage
    INITRD pmagic/initrd.img
    APPEND netsrc=nfs neturl=192.168.1.10:/srv/pmagic/pmodules

Passing NFS mount options

Use netargs= to add command line arguments that you wish to use when mounting with mount.nfs. They will be passed as an additional -o argument. For example, if you want to force NFS version 3 and also set a timeout:

APPEND netsrc=nfs neturl=192.168.1.10:/srv/pmagic/pmodules netargs=vers=3,timeo=300

All mounts are always done with ro,nolock. Any arguments you provide with netargs will be appended to these.

Complete Worked Examples

Example 1: Minimal dnsmasq PXE server

This is a PXE server based upon dnsmasq to provide DHCP and TFTP services, and Python to serve files over HTTP. Suitable for a small test environment or one-time use.

# Step 1: Extract the ISO
sudo mkdir -p /srv/pmagic
sudo mount -o loop pmagic_V.V.iso /mnt
sudo cp -r /mnt/pmagic /srv/pmagic/
sudo umount /mnt

# Step 2: Set up the TFTP root with the boot loader and kernel
sudo mkdir -p /srv/tftp/pmagic
sudo cp /usr/lib/PXELINUX/pxelinux.0    /srv/tftp/
sudo cp /usr/lib/syslinux/modules/bios/ldlinux.c32 /srv/tftp/
sudo cp /srv/pmagic/pmagic/bzImage       /srv/tftp/pmagic/
sudo cp /srv/pmagic/pmagic/initrd.img    /srv/tftp/pmagic/

# Step 3: Create the PXE menu
sudo mkdir -p /srv/tftp/pxelinux.cfg
cat <<'EOF' | sudo tee /srv/tftp/pxelinux.cfg/default
DEFAULT pmagic
PROMPT 0

LABEL pmagic
    KERNEL pmagic/bzImage
    INITRD pmagic/initrd.img
    APPEND netsrc=wget neturl=http://192.168.1.10/pmagic/pmodules/
EOF

# Step 4: Configure dnsmasq
cat <<'EOF' | sudo tee /etc/dnsmasq.d/pxe.conf
interface=eth0
bind-interfaces

# DHCP range: adjust for your network
dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,1h

# PXE boot
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp
EOF

sudo systemctl restart dnsmasq

# Step 5: Serve /srv/pmagic over HTTP, so that
# http://192.168.1.10/pmagic/pmodules/ is /srv/pmagic/pmagic/pmodules
cd /srv/pmagic
sudo python3 -m http.server 80 &

Boot a client computer via the network and it will be booted into Parted Magic via PXE.

Example 2: UEFI PXE with GRUB and HTTP

This method of netbooting may not work on modern UEFI hardware, as it may not support pxelinux. Instead you can use GRUB’s network boot capability.

# Build a GRUB PXE image (on the server)
grub-mknetdir --net-directory=/srv/tftp

# This creates:
#   /srv/tftp/boot/grub/x86_64-efi/core.efi   (the UEFI PXE bootloader)
#   /srv/tftp/boot/grub/grub.cfg               (GRUB config)

# Copy PM kernel and initrd alongside it
cp /srv/pmagic/pmagic/bzImage    /srv/tftp/pmagic/
cp /srv/pmagic/pmagic/initrd.img /srv/tftp/pmagic/

# Create /srv/tftp/boot/grub/grub.cfg
cat <<'EOF' > /srv/tftp/boot/grub/grub.cfg
set timeout=5
set default=0

menuentry "Parted Magic (PXE - HTTP)" {
    linux pmagic/bzImage netsrc=wget neturl=http://192.168.1.10/pmagic/pmodules/
    initrd pmagic/initrd.img
}

menuentry "Parted Magic (PXE - NFS)" {
    linux pmagic/bzImage netsrc=nfs neturl=192.168.1.10:/srv/pmagic/pmagic/pmodules
    initrd pmagic/initrd.img
}
EOF

# Point UEFI clients at the GRUB image via DHCP option 67:
# In dnsmasq:
#   dhcp-match=set:efi-x86_64,option:client-arch,7
#   dhcp-boot=tag:efi-x86_64,boot/grub/x86_64-efi/core.efi

The core.efi generated by grub-mknetdir is unsigned, so firmware that has Secure Boot enabled will not allow it to run. You will need to turn off Secure Boot on each client computer you wish to netboot this way. The layout pm2pxe.sh makes, above, uses the ISO’s signed files instead and works with Secure Boot on.

Example 3: iPXE chainloading

iPXE is an open source PXE firmware that supports native HTTP access to files. As such, if you find that your hardware’s PXE ROM is limited, you can chainload iPXE first.

#!ipxe
# Serve this script via your DHCP server's boot-file option

# Optionally set a static IP instead of DHCP:
# set net0/ip 192.168.1.50
# set net0/netmask 255.255.255.0
# set net0/gateway 192.168.1.1
# set dns 192.168.1.1

echo Booting Parted Magic via HTTP...
kernel http://192.168.1.10/pmagic/bzImage netsrc=wget neturl=http://192.168.1.10/pmagic/pmodules/
initrd http://192.168.1.10/pmagic/initrd.img
boot || shell

Both the kernel and the initrd are pulled down using HTTP in an iPXE-based environment, along with the SQFS download via HTTP; this makes it much faster than pulling all of the items directly off a TFTP server.

Example 4: TFTP-only deployment (no HTTP server)

On the other hand, if you do not have the capability to pull down items from a web server, you can use TFTP for all downloads; this will be the easiest setup to implement, albeit the slowest.

# All files in the TFTP root:
/srv/tftp/
├── pxelinux.0
├── ldlinux.c32
├── pxelinux.cfg/
│   └── default
└── pmagic/
    ├── bzImage
    ├── initrd.img
    └── pmodules/
        ├── PMAGIC_V.V.SQFS
        ├── extras.SQFM
        └── scripts/
            └── autorun.sh

# pxelinux.cfg/default:
DEFAULT pmagic
LABEL pmagic
    KERNEL pmagic/bzImage
    INITRD pmagic/initrd.img
    APPEND netsrc=tftp neturl=192.168.1.10:pmagic/pmodules:extras.SQFM,scripts/autorun.sh

Example 5: NFS with custom mount options

# Server: /etc/exports
/srv/pmagic/pmagic/pmodules  10.0.0.0/8(ro,no_subtree_check,async)

# Client boot parameters:
APPEND netsrc=nfs neturl=10.0.0.5:/srv/pmagic/pmagic/pmodules netargs=vers=3,rsize=32768

The rsize=32768 parameter allows for increased NFS read sizes for improved throughput. The vers=3 forces NFSv3, which avoids potential issues with NFSv4 ID mapping in the minimal initrd environment.

Unattended Erase over PXE

All of the above gets Parted Magic booted from a network. If you want to get computers to self-erase (i.e., boot, then follow your chosen policy for wiping themselves, then send back evidence that they were erased before shutting down, without someone physically typing on their keyboards), just append the parameters used by the Erase utility to whatever you’re putting into that append line. The netsrc= and neturl= parameters are interpreted by the initrd. The pmerase_ parameters are interpreted by the Erase utility once the machine has come up. Both parameter lists can coexist in the same line.

Set up a report server

Having a report server isn’t mandatory but is highly recommended. If you don’t have one, all the logs and certificates are left behind on the erased machine. Also, with no report server, a machine that has its evidence stored entirely in memory will remain turned on after an erase rather than shutting off. With one, the evidence leaves each machine while the erase is still running. If your configured report server is unavailable, the run will log a warning message and continue to perform an erase. The report server is simply one file named pmagic_report_server, located in the root directory of the Parted Magic ISO. This file is bundled with all licenses. To use it, copy it to any always-on computer which runs Python version 3. Then run it:

# Linux / Mac
./pmagic_report_server

# Windows
py pmagic_report_server

It will run on port 8341 by default but can be instructed to use another port; it does not require installation or access to a database; and it provides a dashboard which shows all sessions in real time. For additional information, please go to the Secure Erase webpage.

Required erase parameters

Parameter	Description
`pmerase=auto`	Turns unattended mode on. It must be spelled exactly this way; nothing else turns it on.
`pmerase_confirm=ERASE-ALL-DATA`	The confirmation token, word for word. A typo here means nothing is erased.
`pmerase_targets=all` or `sda,sdb`	Which drives may be erased. There is no default on purpose, so no drive is ever erased without being named in the policy.
`pmerase_method=KEY`	The block-wipe method: `zero`, `random`, `ops2`, `dod_short`, `dod`, `gutmann` or `prng`. Required whenever a target needs a block wipe: a drive with no hardware erase, or one named in `pmerase_blockwipe=`.

Optional erase parameters

Parameter	Description
`pmerase_exclude=sdc,sdd`	Drives never to touch, even under `pmerase_targets=all`.
`pmreport=HOST[:PORT]`	The report server. Recommended, as above.
`pmerase_verify=off\|10\|25\|50\|100`	How much of the medium to read back after the erase (default 100).
`pmerase_blockwipe=sdb,sdc`	Erase these drives with Block Wipe although they have a hardware erase: for a drive whose firmware reported a clean erase and left data behind. NIST Clear.
`pmerase_no_fallback_wipe=1`	A drive whose firmware refuses its hardware erase is reported failed instead of being block-wiped.
`pmerase_no_tcg_revert=1`	A self-encrypting drive whose firmware refuses its hardware erase goes straight to the block wipe, without the cryptographic erase (TCG revert) that would otherwise come first.
`pmerase_sanitize=MODE` / `pmerase_se=MODE`	Pick which Sanitize or Secure Erase variant is issued where the firmware advertises more than one.
`pmerase_nist=1` / `pmerase_dod=1`	Certify against NIST SP 800-88r2 or DoD 5220.22-M.
`pmerase_delay=SECONDS`	Abort window before anything is written.
`pmerase_on_done=poweroff\|reboot\|halt\|stay`	What to do when every drive has finished (default poweroff). A refusal never powers the machine off.
`pmerase_work_order=TOKEN`	Work order reference, recorded on the certificate.

Each of the above parameters has a corresponding command-line equivalent. The command-line flag overrides any parameters that were specified on the kernel command line. To see the complete listing of flags available for erase, run erase -h on your booted computer.

A complete append line

Network boot over HTTP, then erase every drive, verify in full, report to the server and power off:

# pxelinux.cfg/default
DEFAULT pmagic
LABEL pmagic
    KERNEL pmagic/bzImage
    INITRD pmagic/initrd.img
    APPEND netsrc=wget neturl=http://192.168.1.10/pmagic/pmodules/       pmerase=auto pmerase_confirm=ERASE-ALL-DATA pmerase_targets=all       pmerase_method=zero pmerase_verify=100 pmerase_on_done=poweroff       pmreport=192.168.1.10:8341

What it refuses to do

If either a necessary parameter has been omitted or entered incorrectly, or if the abort window has been interrupted at the console, then the run will leave the machine powered on, erase nothing, and print out why this occurred. A mistyped append line does not execute anything.

Four types of drives may never be automatically erased, and there is no way to override this: the drive upon which the current operating system resides, PSID-locked self-encrypting drives, drives with file systems mounted, and ATA-frozen drives. For unattended operations the program attempts to unfreeze the ATA-frozen drives first by suspending the machine for five seconds, and then looks again to see if there is still a problem. Therefore, only drives that stay frozen are left alone. Under pmerase_targets=all these drives are skipped and reported; when they are named explicitly, they stop the run instead of being skipped. NIST Purge requests are rejected outright when executed against RAID LUNs and hypervisor virtual disks because a firmware command cannot access the media.

The exit code will indicate what took place: 0 = all drives were successfully erased. 1 = a drive failed, or the evidence could not be produced. 2 = the policy was refused. 3 = the run was aborted at the console, or none of the available drives met the criteria to be erased.

Split-File PXE (Advanced)

Some PXE systems may also limit file size due to some of their older TFTP versions. Parted Magic allows you to break larger files into smaller pieces called “chunks” by adding a number to each one, which will then be automatically combined back together upon bootup via concat.

If a file named /p0000 exists in your initrd, it will be treated like a shell script when booted up at an early stage, and it can contain the commands for using concat to combine the chunks. The concat command requires a filename prefix and the path where you want to put the new file. For example, concat /data /data.img would take the files /data00, /data01 etc. and make them into /data.img.

Splitting files

# Split a large file into 10MB chunks
split -b 10M -d largefile.bin largefile
#   Produces: largefile00, largefile01, largefile02, ...

Each chunk should be named with a two-digit numeric suffix starting from 00. The base or initial piece (the 00) will become the first piece, and all other pieces are added after it in sequence and then deleted.

pmodules and Startup Scripts

Besides the standard SQFS image at the core of the PXE download, there may also be other .SQFM modules and start-up scripts included, which are run once the operating system has completed booting up.

Module bundles (.SQFM)

SQFM files are SquashFS images that are mounted as an overlay layer on top of the base system. The files can add applications, configuration items and/or customizations. These should be placed alongside PMAGIC_V.V.SQFS in the pmodules directory. Once in this location, these files will load automatically.

Startup scripts

Any shell scripts placed within the pmodules/scripts/ directory will be copied into /tmp/scripts/ when the OS boots. At this point, the post-boot initialization process will have access to run any number of these scripts, including those used to automate functions such as running a wipe tool or setting up network connectivity.

Loading optional modules

On a USB stick or an ISO, optional SQFM bundles can sit in their own optionals/ directory beside pmodules/. When you use the oload= parameter at boot time, you may select which of these bundles you wish to load. However, when using PXE, only the pmodules files are downloaded, so there is no optionals/ directory to choose from; therefore, all of your bundles should go into pmodules, where they load automatically.

# USB stick or ISO: load only the optionals whose filenames contain "network" or "drivers"
oload=network:drivers

A colon (:) is used to delimit multiple module names. The module names are matched as substrings against the filenames in the optionals/ directory.

RAM Requirements

PXE boots all of its files into RAM. The client’s machine must be able to fit the SQFS image of Parted Magic, plus any of the SQFM bundles, plus the running system into RAM. For example, for Parted Magic version 26.11_1, the PMAGIC_26.11_1.SQFS image is 2.03 GiB. When booted off of a USB drive, Parted Magic will copy it into RAM only when there is room for an additional 2 GiB of working space for the system, the overlay and tmpfs, and otherwise it runs in Live mode. There isn’t such an alternative when using PXE, because the image is already loaded into RAM. Therefore, a 4 GB machine would be too small, while a 6 GB machine would be large enough.

The easiest way to estimate how much RAM is required by your system is simply adding up the amount of space that each component requires: Required RAM ≈ size of PMAGIC_V.V.SQFS + size of all .SQFM files + 2 GB (the 2 GB is the working room the boot code allows for the running system, overlay, and tmpfs).

Troubleshooting

“PMAGIC_V.V.SQFS not found” after download

Verify that the SQFS file exists on the server at the expected path.
For HTTP, check that directory listing is enabled by your web server. Without it, wget --recursive will not be able to find files.
For TFTP, verify that the path in neturl is relative to the TFTP root and not an absolute filesystem path.
For NFS, verify that the export path in neturl matches exactly what is found in /etc/exports.
Check that the Parted Magic version in the filenames matches the version built into the initrd.img you are booting.

DHCP fails / no IP address

Make sure that your DHCP server is operational, and that both the client and the DHCP server are on the same network segment.
If a machine is equipped with multiple NICs, the init script will use the interface that the PXE ROM booted from when the boot loader passes BOOTIF= (pxelinux does this with IPAPPEND 2), and otherwise it will try all non-loopback interfaces. Therefore, you must make sure that the correct interface is connected to the VLAN that your DHCP server serves.
Put tracing=yes on the kernel command line so that verbose output is turned on. This way you can see exactly what interfaces are being tried.

Download is extremely slow

Use HTTP instead of TFTP (netsrc=wget) if you are using TFTP. HTTP transfers data much quicker than TFTP for large amounts of data.
If you are using NFS, add netargs=rsize=32768 in order to increase your read buffer size.
Look for mismatched duplex settings on your network. A 1 Gbps NIC that negotiates at 100 Mbps half-duplex will be very slow.

Debugging with tracing and initrd_shell

Two boot parameters help when trying to debug your PXE boot process:

# Enable bash xtrace: every command is printed before execution
APPEND netsrc=wget neturl=http://... tracing=yes

# Drop to a shell inside the initrd before PXE starts
# Useful for manually testing network connectivity or file paths
APPEND netsrc=wget neturl=http://... initrd_shell=yes

initrd_shell=yes will give you a shell prompt before the PXE download begins. Once you have run commands such as ip addr, ping or wget to diagnose connectivity issues, type exit in order to go back into your normal boot sequence.

Version mismatch warnings

If you see “The above file was created for another PM version” during boot, it means that there is an SQFM bundle on the server made for a different version of Parted Magic than the SQFS you are booting. Either update the SQFM bundles to be compatible with the new version of Parted Magic (if they are still applicable), or simply delete them if they are not needed.

Protocol Comparison

	HTTP (wget)	TFTP	NFS
Speed	Fast	Slow for large files	Fast
Resume support	Yes	No	N/A (mount-based)
File discovery	Automatic (recursive crawl)	Manual (explicit file list)	Automatic (directory mount)
Server requirements	Any HTTP server	TFTP server (usually already present)	NFS server
Firewall complexity	Single port (80 or 443)	UDP 69 + dynamic high ports	Multiple ports (111, 2049, mountd)
Best for	Most deployments	Minimal environments, legacy setups	Large-scale / high-throughput LANs

Quick-Start Cheat Sheet

Copy-paste boot lines for each protocol. Replace 192.168.1.10 with your server’s IP and adjust paths as needed.

HTTP

APPEND netsrc=wget neturl=http://192.168.1.10/pmagic/pmodules/

TFTP (SQFS only)

APPEND netsrc=tftp neturl=192.168.1.10:pmagic/pmodules:

TFTP (with extra files)

APPEND netsrc=tftp neturl=192.168.1.10:pmagic/pmodules:extras.SQFM,scripts/autorun.sh

NFS

APPEND netsrc=nfs neturl=192.168.1.10:/srv/pmagic/pmagic/pmodules

Unattended erase (HTTP)

APPEND netsrc=wget neturl=http://192.168.1.10/pmagic/pmodules/ \
  pmerase=auto pmerase_confirm=ERASE-ALL-DATA pmerase_targets=all \
  pmerase_method=zero pmerase_verify=100 pmerase_on_done=poweroff \
  pmreport=192.168.1.10:8341