similar to: problem reading PXELinux's code

I am sending a patch that makes the debugging output of PXELINUX slightly more concise, without (intentionally) affecting its completeness at all. Additionally, I am proposing that the debugging output of PXELINUX -- specifically the messages that appear after the copyright statement, but before the menu is loaded -- only be shown in response to keyboard input (such as holding Shift or Alt, or

Now that pxechain.com can work (with my patch to core/pxelinux.asm), a PXE Chainload COM32 is not as big of a deal but I agree with HPA that it would be a good idea, especially considering the possible flexibility that this may allow. For the moment, I've named the chain module pxechn.c32 in order to not collide with the name pxechain.com when not specifying the .com/.c32 extension.

I've been using syslinux on my own Linux recovery CDs for almost a year now, and in that time I've found it useful to be able to automatically load a 64-bit-capable kernel if the CPU supports it. I'd like to share my efforts and submit this patch for syslinux-3.31. It adds a new config file keyword, 'default64', which overrides the default image if a 64-bit CPU is detected.

In pxelinux.asm the xchg instruction in xchg ax,ax . data_on_top: should be xchg ax,dx, I think At the end of pxe_get_cached_info routine,there is and ax,ax jnz .err It is supposed to test for AX status, but since pxenv does pushad and popad, AX doesn't contain status. In fact the other routines calling pxenv don't have this bug.

Hi all, I currently use iPXE to load memdisk and, subsequently, a FreeBSD disk image to perform an OS installation to disk. This works great in BIOS, but upcoming requirements make UEFI a prerequisite. Because memdisk is not UEFI-aware, new UEFI-aware media is necessary. The current plan is to integrate the installation scripts (currently in the hard drive image) into a bootable FreeBSD ISO

(Interesting, it's exactly a month since the last email about this.) pxechn.c32 is (slowly) moving along. It can now successfully perform the same task as pxechain.com calling PXENV_RESTART_TFTP except it's done without that call. Currently, it's implemented such that it could use PXENV_RESTART_TFTP however using the PXE ROM in VMware Server 2.0.2 fails while using gPXE 1.0.1 it

Attached patch addresses following problems with pxelinux: 1. If a x0y number is present in ip address to be ipappend-ed, middle zero is omitted, e.g. 192.168.0.109 is passed as 192.168.0.19. 2. UDP port numbers allocated by pxelinux.0 are 100% predictable, which might cause trouble when client reboots too fast for orphaned tftpd process to time out. The latter problem is [suggested to

On 1/23/2017 09:17, Rick Miller via Syslinux wrote: > Hi all, > > I currently use iPXE to load memdisk and, subsequently, a FreeBSD disk > image to perform an OS installation to disk. This works great in BIOS, but > upcoming requirements make UEFI a prerequisite. Because memdisk is not > UEFI-aware, new UEFI-aware media is necessary. The current plan is to > integrate the

Whoops, apologies. The intent was to send this email to ipxe-devel. I'll repost to that list. On Mon, Jan 23, 2017 at 10:12 AM, Shao Miller <ipxe at sha0.net> wrote: > On 1/23/2017 09:17, Rick Miller via Syslinux wrote: > >> Hi all, >> >> I currently use iPXE to load memdisk and, subsequently, a FreeBSD disk >> image to perform an OS installation to

Hi, I've been hacking this week-end on a Vortex86[0] based device (ebox 3300) and had quite a few trouble with pxelinux.0 on it. Actually, I narrowed the problem to the `pxenv' routine always returning 1. This lead to an infinite loop while trying to transfer the config file. I'm not sure what the problem is, but the FreeBSD PXE bootloader does work on the same hardware, with the same

Hi, We're planning to deploy PXELINUX as a primary kernel loader in cluster environment. Problem is that we plan to have IP numbers assigned dynamically while there is no guarantee that all machines has same CPU architecture. This makes IP-based config search algorithm inappropriate for our purposes because we [naturally] expect loaded kernel to match hardware. For this reason I've

Hello, I write to you for the announcement in this blog: http://blog.hartwork.org/?p=86. I am interested in the open-source solution proposed in this article (the preprocessor-macros solution). Have you solved the problem? Does the offer still stands? Kind Regards, Fernando Pelliccioni. Buenos Aires, Argentina

Hi, I've got pxelinux 2.00 working to boot rh 7.3, 8.0, and phoebe-beta pxe install images but I've recently tried to load the rh 9 pxe install images and I get this.. 4000 AX:0208 BX:0200 CX:0002 DX:0000. Any thoughts? Thanks aaron

Hi, I just tried to boot my token ring devices with 2.05 - to no avail, it hangs after loading the kernel. I then tried older versions, and found 2.03 booting like a charm, and every 2.04-pre including 2.04 hanging. Here's the config of the devices: - Networkstation 2800 with IBM PCI Token Ring card 2 - IBM Thinkpad T21 with IBM PCI Token Ring card 2 Maybe this has to do with the changes

From: Matt Fleming <matt.fleming at intel.com> Since we can't use __intcall() for EFI, and since we can now have the ELF module code resolve all our symbols at runtime, we should delete as many references to __intcall() as possible and just access the symbols directly. The most interesting patch is the support for weak symbols. We need to be able to reference derivative-specific

H. Peter Anvin, The following problem came to my attention with memdisk. I cannot claim the credit, but wanted to be sure the information made it back into the program for the benefit of all users... In file memdisk.asm, in respect of the operation of the raw and bigraw options, the order of pop instructions does not correspond to the order registers are pushed;

Hi Peter, The main part of this pull request includes commits that try to replace as many __intcall() invocations as possible. Some remain, but not many (and eventually they'll be gone too). There's also a patch to make better use of ld's --as-needed option and various other bug fixes/cleanups. The following changes since commit ff7334a2ce536b7f4b1f6d6f93ff4e285a3bd45a: Only

Hello again and thanks for your support. I am trying out the pxe floppy - rbfg that you mentioned in your previous email for some machines that are not pxe capable but have supported network cards. It looks like it is going to work but then hangs. The dialog below is from a vmware session just for testing but I have the exact same problem on an old IBM box with a Intel e100 card. Here is

It seems that 2.03-pre1 resolves PXELINUX problem on a reasonable number of hosts. Perhaps somewhat importantly this seems to include the RBFG PXE boot floppy, which did not work with 2.02. This was somewhat of a surprise, since it didn't exhibit the failure mode that I would have thought would have been the trigger of the bug. Instead, it was one of those stacks that would transmit packets

Hi, I am mucking around with the pxelinux code for S&G's and I have a generic question about the pxe calling convention: Does the parameter structure and opcode HAVE to be passed onto the stack the PXE BIOS passed in when the pxelinux binary is executed at 0:7C00? The PXE spec says: "SS:SP is to contain the address of the beginning of the unused portion of the PXE services