Bean wrote:
Hi,
The problem with initrd is that it can't allocate enough memory.
Please try the following patch, it will show some info that could be
be useful in debugging.
linux (hd0,4)/vmlinuz
[Linux-EFI, setup=0x2a00, size=0x1d2798]
initrd (hd0,4)/initrd.img
679000 1ffe 832
___
On Wed, Jun 4, 2008 at 12:28 AM, Isaac Dupree
<[EMAIL PROTECTED]> wrote:
> Bean wrote:
>>
>> Hi,
>>
>> The problem with initrd is that it can't allocate enough memory.
>> Please try the following patch, it will show some info that could be
>> be useful in debugging.
>
> linux (hd0,4)/vmlinuz
>[
I've been thinking a bit more about this, and I think it should be
possible to solve the problem at hand without extending the existing
framework. I'm concerned about finding a solution that is as simple
(and small) as possible.
Do you mind waiting a few days? I'll send a proposal tomorrow or s
On Mon, Jun 02, 2008 at 10:11:50AM -0400, Pavel Roskin wrote:
> On Mon, 2008-06-02 at 15:50 +0200, Robert Millan wrote:
> > There's no reason grub-probe should fail if it can't resolve drive, when we
> > just asked for -t fs, -t fs_uuid or -t partmap.
> >
> > This patch solves the problem by split
On Tue, 2008-06-03 at 23:12 +0200, Robert Millan wrote:
> On Mon, Jun 02, 2008 at 10:11:50AM -0400, Pavel Roskin wrote:
> > On Mon, 2008-06-02 at 15:50 +0200, Robert Millan wrote:
> > > There's no reason grub-probe should fail if it can't resolve drive, when
> > > we
> > > just asked for -t fs, -t
On Wed, Jun 4, 2008 at 5:09 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
>
> I've been thinking a bit more about this, and I think it should be
> possible to solve the problem at hand without extending the existing
> framework. I'm concerned about finding a solution that is as simple
> (and small)
