Ok, let me explain.
If that stick is (senselessly) booting to Syslinux, it's only business is to load grub.exe as a Linux kernel passing it some parameters.
The menu.lst is not used at all in that configuration.
However the parameters passed to grub.exe are the same as the contents of the menu.lst
ls /images/pmagici686.iso || find --set-root /images/pmagici686.iso
map --heads=0 --sectors-per-track=0 /images/pmagici686.iso (0xff) || map --heads=0 --sectors-per-track=0 --mem /images/pmagici686.iso (0xff)
map --hook
chainloader (0xff)
The first line tries to look for the file "pmagici686.iso" inside the directory /images/ of "current root" and if it can't find it, tries to look for it in the same path but on other devices (normally when you boot from a USB stick, it becomes the root device, but there may be cases when this doesn't happen).
Second lines tries to map the .iso to a grub4dos virtual drive (CD-like) or, if this fails (typically because the .iso is not contiguous) it attempts to map the .iso to a virtual dirve but residing in memory.
Third line "hooks" the mapping, i.e. makes the mapping "static".
Fourth line chainloads the boot sector of the virtual drive.
Till now everything is fine and dandy, BUT chainloading the bootsector means to have it call the *whatever* bootloader the .iso has (namely in this case it will be most probably be Isolinux), from this point on everything that was made before (with the exception of the mapping of the.iso to a virtual drive in BIOS) is "lost" as the Isolinux will load it's own .cfg which is INSIDE the .iso.
So what is really executed and passed to the kernel is the contents of the /boot/syslinux/syslinux.cfg or the /boot/isolinux/isolinux.cfg inside the .iso.
This has no "cheatcodes" and (evidently) the .iso is made to have a "default" name of "pmagici686.iso" and a "default" path of "/images/"
OR XBOOT while building the stick corrects the .cfg adding these data.
If you think about it, you should gather the futility of the whole approach in this case, you boot to syslinux that loads syslinux.cfg to load grub4dos that loads menu.lst to load a bootsector that loads isolinux that loads syslinux.cfg that loads the kernel and initrd
.
Once you are in grub4dos, it makes more sense to directly chainload the kernel and initrd, giving it whatever parameters they need, try adding to the menu.lst an entry *like* (adapting it to your needs):
title Parted Magic /ISO/pmagic_2013_02_28.iso (booting the kernel)
map /ISO/pmagic_2013_02_28.iso (0xff)
map --hook
root (0xff)
kernel /pmagic/bzImage edd=off load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=10 loglevel=0 max_loop=256 vmalloc=384MiB keymap=us iso_filename=/ISO/pmagic_2013_02_28.iso
initrd /pmagic/initrd.img
This way you get directly to the kernel and initrd.
Wonko
P.S.: as a side note, you won't ever learn anything about syslinux or grub4dos if you use a "wrapper" (such as XBOOT) which is nowadays way obsolete besides never having been particularly "smart" or flexible, you'll learn much more things reading the grub4dos or the syslinux subforums and/or perusing Steve6375's site for RMPREPUSB and/or Easy2boot (the latter being another "wrapper" but at the same time simpler and much more evolved than XBOOT and using a recent - of not the very last - version of grub4dos).
Also, you should study the (now getting a bit outdated, newer versions of grub4dos have many additional capabilities, but it remains a valid "base") diddy's guide:
http://diddy.boot-la...os/Grub4dos.htm Finally Grub (which has been senselessly renamed "grub legacy") is NOT grub4dos, Grub 2 (which has now been senselessly renamed Grub) is NOT grub4dos, grub4dos is grub4dos and should be called grub4dos to avoid confusion with the other two.