On Tuesday, April 20, 2010 08:06:13 am Stefan Hajnoczi wrote:
> Unfortunately, there is no documentation, but you can peruse the Legacy
> GRUB source that is bundled with Solaris. The specific workaround I'm
> referring to involves the use of the drives_addr field in the
> multiboot_info structure. On netboot, the entire DHCP ACK packet is
> referred-to there.
> See line ~1422 of usr/src/uts/i86pc/os/fakebop.c to see how that is
> interpreted."
Besides this issue, there seems to be another one.
Judging by the (lack of) debug messages, something goes wrong before even
reaching that function.
I noticed that when I load kernel and boot_archive (ramdisk), the last debug
message is:
==
*** DBOOT DONE -- back to asm to jump to kernel
==
If I only load the kernel it goes a bit further, before complaining it misses
its boot_archive:
==
==
*** DBOOT DONE -- back to asm to jump to kernel
*** Entered Solaris in _start() cmdline is: unix -kvd -B
console=ttya,kbm_debug=true,prom_debug=true,map_debug=true
next_phys is 1813000
next_virt is 1813000
Initializing boot time memory management...done
Initializing boot properties:
Building boot properties
(uintptr_t)propbuf is 1814000
Parsing command line for boot properties
Boot properties:
0x1816280 boot-ncpus = len=2 1
0x1816240 cpu_apicid_array = len=1
0x1816200 impl-arch-name = len=6 i86pc
0x18161d0 mfg-name = len=6 i86pc
0x18161a0 stdout = len=4
0x1816170 bootargs = len=6 -kvd
0x1816140 boot-args = len=6 -kvd
0x1816110 map_debug = len=5 true
0x18160e0 prom_debug = len=5 true
0x18160b0 kbm_debug = len=5 true
0x1816080 console = len=5 ttya
0x1816050 whoami = len=5 unix
0x1816020 boot-file = len=5 unix
failed to get ramdisk from boot
==
==
I also noticed that the reported ramdisk length is much larger with gpxe than
with pxegrub, and close to the memory limit my VM has.
gpxe:
==
Finding Modules
next_avail_addr is 0xc12000
module #0: boot_archive at: 0x3d10c000, len 0x3fcd0534
==
pxegrub:
==
Finding Modules
next_avail_addr is 0xc12000
module #0: /platform/i86pc/amd64/boot_archive at: 0xde8000, len
0xb1b2000
==
Does gpxe uncompresses or otherwise alters the ramdisk?
And if so, is there an easy option to disable that behavior?
- Floris
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
