>>> On 27.08.15 at 19:56, <426...@gmail.com> wrote:
>> If you advocate direct booting ( no boot loader) on production machines I
> wont argue much, as long as there is good recovery tools to deal with
> failed boots (grub does this very well, I am not aware of anything
> comparable that is pure ef
On 28/08/15 07:54, Jan Beulich wrote:
>
>> Therefore I am very much +1 get grub working.
> Then you kind of misunderstood: I'm not against getting grub2
> working (i.e. patches prior to this one are fine in principle). What
> I'm against is hacking around firmware+grub2 combinations not
> suitable
On Fri, Aug 28, 2015 at 02:22:46AM -0600, Jan Beulich wrote:
> >>> On 27.08.15 at 19:56, <426...@gmail.com> wrote:
> >> If you advocate direct booting ( no boot loader) on production machines I
> > wont argue much, as long as there is good recovery tools to deal with
> > failed boots (grub does th
>>> On 28.08.15 at 15:42, wrote:
> And I am not comfortable to say 'GRUB2+Xen cannot run on this hardware
> because your firmware vendor is not following the EFI spec in spirit.'
Well, not the least since I don't really agree with this (albeit I can
see where you're coming from) ...
> Now that s
>>> On 27.08.15 at 17:29, wrote:
> You're right, there's no such requirement on memory use in the spec.
> But you're missing the point. Supporting grub2 on UEFI is already a
> hack (ignoring all intentions EFI had from its first days). And now
> you've found an environment where that hack needs an
ipv6 routing in grub2 is broken, we cannot talk to anything outside our local
network or anything that doesn't route in our global namespace. This patch
fixes this by doing a couple of things
1) Read the router information off of the router advertisement. If we have a
router lifetime we need to
