> /EFI/Boot/GRUB/bootx64.efi
> /EFI/Boot/eLilo/bootx64.efi
> /EFI/Boot/Microsoft/bootx64.efi
>
> I need a way to load both Boot Manager and eLilo for grub. Can you please
> show me the example of > config file?
>
> The command to use is chainloader or similar (as opposed to the
> 'linux' comm
Hello everybody.
I am currently trying to build grub for UEFI (I got new modern Intel
motherboard that support boot loading).
According to the grub manual, I use
./configure --with-platform=efi --target=x86_64
make
./grub-mkimage -d- -o bootx64.efi modules_list
and try to load from it. it does
Vladimir can you please send me your compiled grub2 for efi, 64 bit? I will try
to run it on my computer?
>
I tested with 64-bit qemu-tianocore actually, and in this case it's not
an emulation.
--
This message was sent on behalf of gbura...@gmail.com at openSubscriber.com
http://www.opensubs
Hello everybody.
I am currently trying to realize the following functionality: I want grub to
load the kernel from GPT partition. I am using grub build for UEFI. So, I got
following questions for now:
I don't want to use standart naming conversion, here are some reasons:
* It is not clear what
> The NTFS "UUID" (actually the volume serial number rather than a proper
> UUID) is 64 bits long, so we have a space of 2^64 possible UUIDs. That's
> very close to the number of stars in the observable universe. I believe
> that the volume serial number is typically generated based on the date
>
-- Vladimir 'φ-coder/phcoder' Serbinenko wrote :
Colin Watson wrote:
>> It would be ideal if we can search the GPT partition/disk by GUID -
>> that's what we got NTFS GUID for =)
>>
>
> That would be nice, and it might not be all that difficult to implement,
> but of course it would take up e
Hello,
> It is. Can you write a ChangeLog entry?
Done
> ;1 is so called version. Basically all terminating ; have to be
> stripped but only if filename doesn't come from rockridge or joliet.
> Apparently nobody uses grub2 on non-rockridge, non-joliet iso. While
> this bug should be fixed using
> Hi,
> trunk repository is now frozen in preparation for GRUB 1.98, which will be
> released soon, most likely this month.
> I leave Vladimir in charge of this freeze process. Please ask him for
> approval when in doubt.
Hello,
I am really newbie to the process of reviewing/comming code to GNU r
> As I already said I have a working prototype for this in newreloc branch.
Thanks you, it works!
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
--
This message was sent on behalf of gbura...@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/grub-devel@gnu.org/13437030.h
> First part applied
Thanks!
> Please don't put unrelated patches into single file. Fast look on the
> joliet.c of mkisofs suggests that it's not the case for its joliet. It
> seems there is more to it. Can you find some normative documents?
I searched a bit and found the following information:
D
What about this patch? It is possible to integrate it, at least in the
experimental branch?
--
This message was sent on behalf of gbura...@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/grub-devel@gnu.org/13421616.html
___
Grub-
> I asked you for at least a usecase when it makes a difference but till
> now I've read only about theoretical advantages.
Ok, my usecase is the following:
We are installing grub to EFI system partition and on the next load it must
load itself (rmadisk&kernel) from Windows partiton (where our ma
In Febryary I was testing GRUB for UEFI and noticed that it was simply crashing.
See topic
http://lists.gnu.org/archive/html/grub-devel/2010-02/msg0.html
At that time I blamed incorrect UEFI implementation on that computer (cause it
worked fine on another one), but now I noticed that when I
Great that somebody agrees with me on the GUIDs =)
In you have problems with compile/testing, feel free to reply here (or to my
mail directly). I ahave made some fixes to it.
Again, I am talking about integration it to the GRUB. This is MUST HAVE
feature, at least for UEFI support
--
This mess
> It may be a recent regression because we have a reports of successful
> boot in such configuration
> (http://lists.gnu.org/archive/html/grub-devel/2009-05/msg00179.html and
> neighbour threads).
> Be sure that grub is compiled with -mcmodel=large. You can also try
> disable usage of >4GiB memory
15 matches
Mail list logo