Anybody knows which elilo.efi version will be released with EL4? It
seems base on version 3.4.
Elilo version 3.5 failed on booting EL4 for at least 3 different
platform for us! Has anyone tried /elilo/elilo-3.5-pre1-ia64.efi
d (either source or binary) to boot EL4 kernel & disk? We have tested
it to boot EL3 only and it failed with 3 systems running with EL4.
We will submit patch with enhancement with "vmmodule=" with current
elilo 3.4.11 version if version3.5 still fails to boot EL4.
from Magenheimer, Dan (HP Labs Fort Collins) wrote:
> I just talked to Brett Johnson, the maintainer for elilo.
> My suggestion of having initrd= and module= be synonyms
> doesn't work well with the elilo parser. However,
> he prefers a solution that AFAIK has not yet been proposed:
> - Leave image= for the Linux kernel image.
> - Leave initrd= for the Linux kernel's initrd
> - Add a NEW keyword, xenimage=, to specify the xen binary.
> He says that the module= proposal is already Xen-specific;
> he doesn't see any other uses for it on the horizon. The
> term "module" is also very vague and doesn't describe what
> it is being used for. So, he says, why not just be explicit
> that we are booting Xen and leave the image= and initrd=
> keywords with the same Linux meaning. Thus:
> (and if we don't want to explicitly encode the term "Xen"
> in the keyword, we could use "hvimage=" or "hv=" or
> "hypervisor="** instead.)
> Brett's solution seems the best to me. It will also
> work quite nicely for a transparently paravirtualized
> system: If xenimage= is specified but the file is not
> found, just load and boot image= which will boot normal
> On a related note: Anthony, Brett said that he would much
> prefer to see a patch against elilo v3.5-pre1 as there are
> additional bug fixes in that base.
> ** probably don't want to use "hypervisor=" since the
> word has been trademarked by a certain big blue company :-)
>> -----Original Message-----
>> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx]
>> Sent: Tuesday, September 06, 2005 10:45 AM
>> To: Magenheimer, Dan (HP Labs Fort Collins); Xu, Anthony
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [Xen-ia64-devel] PLEASE REPLY and RE: [PATCH]
>> Patch for loading module[2of2]
>> Backward compability issue is only happened on "deployed"
>> product, not the "in development" project as xen/ia64. Why need so
>> much "options"?
>> Magenheimer, Dan (HP Labs Fort Collins) wrote:
>>> Well, so far the community is overwhelmingly in favor of B...
>>> Which is OK with me. I've come around to being OK with this
>>> after thinking on it overnight. I was uncomfortable with
>>> losing the backward compatibility, but if this is going
>>> to happen, now is the best time to do that while Xen/ia64 has few
>>> One other thought I had overnight though:
>>> Both the domain0 image and the initrd image could be
>>> considered parameters to Xen. So suppose that "initrd="
>>> and "module=" are simply aliases for each other and the
>>> first two files specified as either module or initrd
>>> are passed (in order) as parameters to Xen. This would
>>> not only be backwards-compatible with existing Xen elilo.conf
>>> files, but would be more compatible with grub. So
>>> all of the following do the right thing:
>>> # choice A
>>> initrd=xenlinux # backward compatible
>>> #no initrd
>>> # choice B
>>> # grub and Xen/x86 compatible
>>> #no initrd
>>> # grub and Xen/x86 compatible and probably
>>> # the best to document for Xen/ia64?
>>> What do you think?
>>>> -----Original Message-----
>>>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>>>> Sent: Monday, September 05, 2005 10:19 PM
>>>> To: Magenheimer, Dan (HP Labs Fort Collins); Yang, Fred
>>>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>>> Subject: RE: [PATCH] Patch for loading module[2of2]
>>>>>> Elilo is a gerernal OS loader,it doesn't and doesn't need to know
>>>>>> presence of domain0, For elilo, xen.gz is a OS kernel, initrd=
>>>>>> it's Os's initial ramdisk, module= is Os's parameter, we should
>>>>>> keep all this meaning, we shouldn't make elilo special just for
>>>>> Yes, module= is OS's parameter, but domain0 is not
>>>>> really a parameter.
>>>> From the view of Elilo, xen is an OS, domain0 is a parameter to
>>>> xen. As far as how to handle this parameter, it's up to xen.
Xen-ia64-devel mailing list