Jacek

It works ;D

Is there something I can provide to try helping?

There's some problem with what iPXE changes in OS. When I boot FD12CD.iso directly from VM's CD-ROM - even original vdelay work. Problem appears when I sanboot it through http. To replicate: - get QEMU - run iPXE in QEMU - run local http server supporting range requests in directory with FD iso file eg. python -m RangeHTTPServer in iPXE call command: sanboot -d 0xe0 http://local_server:port/FD_path.iso In booted FreeDOS try running vdelay /d 2000 - it blocks forever. And please. Next time don't close...

There's some problem with what iPXE changes in OS. When I boot FD12CD.iso directly from VM's CD-ROM - even original vdelay work. Problem appears when I sanboot it through http. To replicate: - get QEMU - run iPXE in QEMU - run local http server supporting range requests in directory with FD iso file eg. python -m RangeHTTPServer in iPXE call command: sanboot -d 0xe0 http://local_server:port/FD_path.iso In booted FreeDOS try running vdelay /d 2000 - it blocks forever.

There's some problem with what iPXE changes in OS. When I boot FD12CD.iso directly from VM's CD-ROM vdelay work. Problem appears when I sanboot it through http. To replicate: - get QEMU - run iPXE in QEMU - run local http server supporting range requests in directory with FD iso file eg. python -m RangeHTTPServer in iPXE call command: sanboot -d 0xe0 http://local_server:port/FD_path.iso In booted FreeDOS try running vdelay /d 2000 - it blocks forever.

It didn't fix the issue. EDIT: I even removed vdelay from setup directory to be sure it runs from disk. Still the same issue.

It didn't fix the issue.

It's exactly as you said - first command did sleep for 2 seconds and second doesn't return. VM doesn't hang tho, as prompt is blinking. It's just not returning.