[gPXE-devel] Opensolaris workaround

[Floris Bos]

Hi,

On Sunday, April 25, 2010 07:38:52 pm Stefan Hajnoczi wrote:
> Syslinux mboot.c32 supports Solaris so I have CCed H. Peter Anvin who
> might have some ideas and has solved GRUB and Solaris multiboot quirks
> for Syslinux.
> 
> > - Opensolaris expects to receive the full path to the kernel, not just
> > the filename.
> 
> Do you have a link to the code?  Depending on how the image command
> line is parsed it may be possible to satisfy Solaris without forcing
> the image command-line to start with "/platform/i86pc/kernel/unix".
> Maybe ;).

Don't have a code link.

But when you only pass "unix" it complains that it cannot find relocation 
information. 
I assume it searches the ramdisk for supplemental kernel files and uses the 
path to determine where those are.


> > - Grub loads modules at the beginning of the address space, while Gpxe
> > seems to do at the end.
> > Opensolaris's kernel startup routine expects grub's behavior, and
> > searches for a region of free memory after the address of the last
> > loaded module, which is normally not available when you use gpxe.
> 
> Do you have a link to the code?  Any idea what the minimum free memory
> requirement is?
> 
> We can't hardcode urealloc(UNULL, 255*1024*1024) since multiboot
> should work on machines with 256 MB or less.

Don't know the exact memory need. 
Tried it with 20 MB first, but that was not sufficient.

It is related to the following code: 
http://cvs.opensolaris.org/source/xref/onnv/onnv-
gate/usr/src/uts/i86pc/dboot/dboot_startkern.c

When it detects modules around line 810, it calls check_higher() which sets 
the variable "next_avail_addr" to the address of the end of the last module.

The generic memory allocation method do_mem_alloc() around line 940, uses 
"next_avail_addr" to allocate memory.
It apparently does not cope well with the situation that there is no free 
memory available after the ramdisk, and the end of address space is reached.


Anyway, my code in multiboot_opensolaris_workarounds() only runs when the ABI 
of the ELF image is Solaris.
And Opensolaris is unlikely to run on systems with little memory, as the 
ramdisk alone is 171 MB uncompressed.


Alternate solution would be to alter gpxe's memory allocation algorithm in 
memtop_umalloc.c. Currently the heap seems to grow downwards from the top of 
memory space.

Or write a patch for Opensolaris's memory routine, and hope Oracle accepts it.


> > - Opensolaris expects to be passed the DHCP ACK packet.
> 
> This quirk disregards the multiboot specification by replacing what
> would normally be a drive description with a DHCP packet.  This means
> gPXE cannot unconditionally fill the DHCP packet in since non-Solaris
> images might try to interpret this information as a drive.
> 
> The Solaris kernel either needs to be recognized automatically by gPXE
> or a setting is needed to control this variation from the multiboot
> specification.
> 
> Any ideas on recognizing a Solaris kernel?  If there is no simple
> unique way to identify a Solaris kernel image then a settings variable
> could be used.

The patch only passes the DHCP packet in multiboot_execute() if the dhcp_ack 
variable is set (checks if the op-code is bootp_reply).

And the dhcp_ack variable is only set in multiboot_opensolaris_workarounds() 
when the ABI of the image is Solaris.

I used the ELF format's EI_OSABI field: 
http://www.freebsd.org/cgi/man.cgi?query=elf&sektion=5



Another issue not yet addressed by my patch, is that PXEGRUB normally 
uncompresses the (gzipped) ramdisk for Solaris.
I currently "solved" it by uncompressing the ramdisk manually, and putting the 
uncompressed file on my webserver, for gpxe to fetch.
But that causes a 171 MB download each time, which even on local networks can 
be a bit slow.
Would probably be better to add gzip support to gpxe as well, but not sure 
where the right place to add that is.


Yours sincerely,

Floris Bos