Re: OpenSolaris and multiboot

[Hollis Blanchard]

This is great information, so I hope you don't mind if I CC grub-devel.

On Mon, 2006-11-20 at 17:13 -0800, Joe Bonasera wrote:
> 
> I guess I should give you some background on how Solaris uses
> grub 0.9x. One important thing to remember is that when you install
> Solaris you get both the 64 bit kernel and 32 bit kernel. Hence
> you always have the choice of at boot time to go 32 or 64 bit.
> Currently Solaris 10 and OpenSolaris have a grub entry
> that looks like:
> 
> title Solaris
>      kernel multiboot [/platform/i86pc/[amd64/]unix] [ -B 
> bootprop=value[,...]] [-v] [-k] etc..
>      module /platform/i86pc/boot_archive
> 
> The multiboot program is the vestiges of our pre-grub boot loader
> that basically just decides if this is a 64 bit capable machine or
> not. If the machine can boot 64 bits, it boots the 64 bit kernel,
> otherwise it falls back to the 32 bit kernel. You can explicit
> tell it which kernel executable to boot as an argument.
> 
> We're just about to change all that and eliminate the multiboot
> program all together.  The Solaris entries would soon look like:
> 
> title Solaris 32 bit
>      kernel /platform/i86pc/kernel/unix [ -B bootprop=value[,...]] [-v] [-k] 
> etc..
>      module /platform/i86pc/boot_archive
> 
> title Solaris 64 bit
>      kernel /platform/i86pc/kernel/amd64/unix [ -B bootprop=value[,...]] [-v] 
> [-k] etc..
>      module /platform/i86pc/amd64/boot_archive
> 
> The /platform/i86pc/kernel/unix file is a 32 bit ELF, so grub
> can load it. The /platform/i86pc/kernel/amd64/uni file is ELF 64,
> so we embed a multiboot header into it and rely on grub's a.out
> hack to get it loaded appropriately. It's the only part of the
> multiboot header we use. The fields in the multiboot header are
> setup so that the entire file amd64/unix gets placed in a known location
> in memory. Then we just decode the ELF64 ourselves to relocate
> the text and data into their final virtual locations.

GRUB2's 'multiboot' command will load ELF64 files, so the "a.out hack"
shouldn't be necessary for you in the future.

And at that point, you may ask yourself why you need a multiboot header
at all. I'd like to remove that requirement entirely. The only argument
I've heard for keeping it is that
     1. The multiboot header is needed when using the a.out hack or
        specifying the VGA mode.
     2. GRUB will only search 8KB of the image looking for the header.
     3. If the header (with VGA mode) appears after 8KB due to
        programming error, GRUB would load the ELF file anyways but
        without the proper VGA mode.
     4. OS silently crashes.

This seems to be a bit of a corner case to me, especially that
"programming error" part.

There are only two pieces of information communicated via the multiboot
header: VGA mode and load addresses. The load addresses are superfluous
in ELF32/ELF64 files, so that leaves us with the VGA mode as the only
reason to keep the header in an ELF file.

> One of the problems we stumbled into was matching the old
> multiboot behavior that can boot 64 bit kernels if possible and fall
> back to 32 bit.  The way we're doing this is to actually extend
> grub. We're adding the idea of environment variables to grub that
> reflect the boot environment.  The simplest way to explain it
> is to show you how it looks:
> 
> title Solaris
>      kernel$ /platform/i86pc/kernel/$ISADIR/unix [ -B bootprop=value[,...]] 
> [-v] [-k] etc..
>      module$ /platform/i86pc/$ISADIR/unix
> 
> 
> The idea is that "kernel$" and "module$" lines may have variables
> expanded to reflect something that grub detects about the boot
> environment. In this case if a machine is long mode capable, $ISADIR
> expands to "amd64", otherwise it's an empty string. This is useful
> for example for a live CD that automatically boots to the most
> apprpriate (32 or 64) bit kernel.
> 
> Another place where we may use variables is for ZFS root/boot partitions.
> The ZFS plugin for grub will be able to know how to choose among multiple
> bootable file systems or snapshots inside a ZFS dataset. We hope to use
> s $ZFS style variable expansion to also pass the information to the kernel.

Yup, this is a very common use case. GRUB2 supports scripting, so this
exact behavior should be possible without needing to patch anything.
Scripting support is currently incomplete, but it may actually be
possible to implement this functionality now, since variable expansion
has been working for a while.

-Hollis