You are not logged in.
I set up a PXE server, and there were no issues when booting Ubuntu for installation. However, when booting Arch, the network cannot be accessed.
''' OCR arch
ERROR; Failed to configure network
Falling back to interactiue prompt
You can try to fix the problem manually, log out
can't access tty; job control turned off.
'''
ipxe_config
:ubuntu22
kernel ${boot-url}/ubuntu22/vmlinuz ip=dhcp url=${boot-url}/iso/ubuntu-22.04.5-live-server-amd64.iso initrd=initrd
initrd ${boot-url}/ubuntu22/initrd
boot || goto failed
:ubuntu24
kernel ${boot-url}/ubuntu24/vmlinuz ip=dhcp url=${boot-url}/iso/ubuntu-24.04.3-live-server-amd64.iso initrd=initrd
initrd ${boot-url}/ubuntu24/initrd
boot || goto failed
:archlinux
kernel ${boot-url}/archlinux/vmlinuz-linux \
ip=dhcp \
archisobasedir=arch \
copytoram=n \
archiso_fetch_url=${boot-url}/iso/archlinux-2025.10.01-x86_64.iso
initrd ${boot-url}/archlinux/initramfs-linux.img
boot || goto failed
Offline
when in doubt copy official ipxe stub:
#!ipxe
set release latest
set extrabootoptions ip=dhcp net.ifnames=0
set mirrorurl http://archlinux.mirrors.ovh.net/archlinux/
kernel ${mirrorurl}iso/${release}/arch/boot/x86_64/vmlinuz-linux
initrd ${mirrorurl}iso/${release}/arch/boot/x86_64/initramfs-linux.img
imgargs vmlinuz-linux initrd=initramfs-linux.img archiso_http_srv=${mirrorurl}iso/${release}/ archisobasedir=arch ${extrabootoptions}
bootanother option is to just chain-load the official
chain https://archlinux.org/static/netboot/ipxe-arch.efialso: please use code tags
Last edited by cryptearth (2025-10-20 14:55:14)
Offline

Using your configuration still has the same problem.
After my ipxe.efi boots, it first does DHCP, then loads http://url/boot.ipxe. It might be doing DHCP twice in a row, causing the server to stop assigning an address.
Offline
please post your dhcp config - it's likely misconfigured to only serve the initial bootp request but not the regular one at bootup
also: there will be a third dhcp after the boot up of the setup environment
also: please see the rules about image embed - your (quite shaky) image is way too oversized - please exchange for a link
Last edited by cryptearth (2025-10-20 17:40:18)
Offline
dhcp server Ikuai


Offline
I guess unless someone here has experience with that product you have to contact thier support
you could also try other dhcp servers - see the wiki: https://wiki.archlinux.org/title/Preboo … rver_setup https://wiki.archlinux.org/title/Router#DNS_and_DHCP
but TL;DR: your issue is a dhcp server config issue
Last edited by cryptearth (2025-10-20 18:59:26)
Offline
Hi xiao-yu,
It does seem like this is probably an issue with your DHCP server. But it would be interesting to know if you're able to manually assign an IP address and continue boot (or just ping the router)?
It would also be interesting to see Wireshark captures of the DHCP exchange, if you have the ability to capture those. It should be broadcast traffic so you may be able to avoid needing to set up any kind of port mirroring or capture on the server.
Offline
the issue is likely that the initial bootp discover is accepted by the dhcp but second regular dhcp request is not as it likely lacks the pxe identifier and the dhcp server likely just ignores it
another option could be to setup a regular non-pxe dhcp server along the existing one which then handles the regular request
Offline
Albeit unlikely, "link flapping" came to mind.
As crypt indicated, the server seems to respond to the 1st DHCPDISCOVER request.
To me, It also looks like iPXE is downloaded which indicates the 2nd DHCPDISCOVER was also acknowledged. Then moves to the kernel where the 3rd DHCPDISCOVER takes place. The client MAC Addr for eth0 is shown and DCHP times out. (based on shakey picture)
:: running early hook [udev]
:: running early hook [archiso_pxe_ndb]
:: running hook [memdisk]
:: running hook [archiso]
:: running hook [archiso_loop_mnt]
:: running hook [archiso_pxe_common]
IP-Config: eth0 hardware address e4:a8:df:ee:df:81 mtu 1500 DHCP RARP
IP-Config: no response after 60 secs - giving upIs there any managed switches between the server and the client?
If so, is Spanning Tree Protocol (STP) enabled?
If yes to both, look in to enabling PortFast (cisco) or admin-edge-port (hpe/aruba/cx) on the interface your laptop is plugged into.
This could prevent any potential port blocking the from the switch during a listen/learn state. Could also rule this out by putting an unmanaged switch between the server and client and try again or just wait 60 seconds after the pxe boot fails and see if you can get an IP from dhcp while in emergency shell.
ip link
ip link set {interface} up
dhclient {interface}
ip addr show {interface}Offline