Bug-fix elf.c powerpc ieee1275
Hi, There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275), causing load linux to fail on my powerpc64 g5 and ibook g4 32bit. Here is a diff of the fix I found necessary for rev 1878 (bug has existed in previous versions). It was a one liner - diff -pu grubsvn/kern grubtry/kern/elf.c - --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000 +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000 @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e if (load_hook load_hook (phdr, load_addr)) return 1; -load_addr = phdr-p_paddr; +/** pxwdebug - not required - load_addr = phdr-p_paddr; **/ if (load_addr load_base) load_base = load_addr; @@ -413,8 +413,7 @@ grub_elf64_load (grub_elf_t _elf, grub_e if (load_hook load_hook (phdr, load_addr)) return 1; -load_addr = phdr-p_paddr; - +/**pxwdebug - not required - load_addr = phdr-p_paddr; **/ if (load_addr load_base) load_base = load_addr; - pcros. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug-fix elf.c powerpc ieee1275
Explanation. It seems to be a case of spurious line that got back into grub_elf32_load and grub_elf64_load, nested function. if (load_hook load_hook (phdr, load_addr)) return 1; load_addr = phdr-p_paddr; That sequence did not make sense to me, it overwrites the correct value of load_addr from the preceding line. Briefly - with set debug=elf Result - for the bug - ..kernel/elf.c:429 Loading segment at 0x0 size 6ae0c8 fails to load kernel at 0x0 as expected. the fix /* load_addr = phdr-p_paddr; */ ..kernel/elf.c:429 Loading segment at 0x140 size 6ae0c8 loads kernel -- Details - Both 32bit ibook G4 and 64bit powerpc G5 were affected, and failed to load linux kernel. I rechecked and got some debug results to illustrate, hand copied from boot screen. I used grub_dprintf(elfpxw,phdr-p_paddr=%llx, load_addr=%x\n,phdr-p_paddr,load_addr); In grub_elf64_load as used by my powerpc64 g5. The debugging outputs shown as they occur in sequence with the code (approx line umbers) if (load_hook load_hook (phdr, load_addr)) return 1; ..kernel/elf.c:421 phdr-p_paddr= c000 load_addr= 140 /* spurious line overwrites load_addr value from load_hook*/ load_addr = phdr-p_paddr; ..kernel/elf.c:424 phdr-p_paddr= c000 load_addr= 0 grub_dprintf (elfpxw, Loading segment at 0x%llx, size 0x%llx\n, (unsigned long long) load_addr, (unsigned long long) phdr-p_memsz); ..kernel/elf.c:429 Loading segment at 0x0 size 6ae0c8 - load kernel at 0x0 fails as expected = The correct result with /* load_addr = phdr-p_paddr;*/ if (load_hook load_hook (phdr, load_addr)) return 1; phdr-p_paddr= c000 load_addr= 140 /*load_addr = phdr-p_paddr; */ phdr-p_paddr= c000 load_addr= 140 Loading segment at 0x140 size 6ae0c8 - load kernel at 0x140 succeeds. = peter cros. On Mon, Sep 29, 2008 at 12:46 AM, Robert Millan [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:42:36AM +1000, peter cros wrote: Hi, There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275), causing load linux to fail on my powerpc64 g5 and ibook g4 32bit. Here is a diff of the fix I found necessary for rev 1878 (bug has existed in previous versions). It was a one liner - diff -pu grubsvn/kern grubtry/kern/elf.c - --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000 +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000 @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e if (load_hook load_hook (phdr, load_addr)) return 1; -load_addr = phdr-p_paddr; +/** pxwdebug - not required - load_addr = phdr-p_paddr; **/ Hi, Thanks for pointing this out. Unless someone understands your change, we'd need you to explain why this line isn't necessary, and why it was causing trouble. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug-fix elf.c powerpc ieee1275
The change was between svn version 1421 and 1509 which had bugfixes, in grub_elf32_load, and grub_elf64_load. [EMAIL PROTECTED]:~/src/grub$ diff -pu grub1421/kern/elf.c grub1509/kern/elf.c --- grub1421/kern/elf.c2008-09-30 14:49:46.0 +1000 +++ grub1509/kern/elf.c2008-09-30 14:41:31.0 +1000 @@ -228,9 +232,9 @@ grub_elf32_load (grub_elf_t _elf, grub_e if (phdr-p_type != PT_LOAD) return 0; -load_addr = phdr-p_paddr; if (load_hook load_hook (phdr, load_addr)) return 1; +load_addr = phdr-p_paddr; if (load_addr load_base) load_base = load_addr; @@ -407,9 +411,9 @@ grub_elf64_load (grub_elf_t _elf, grub_e if (phdr-p_type != PT_LOAD) return 0; -load_addr = phdr-p_paddr; if (load_hook load_hook (phdr, load_addr)) return 1; +load_addr = phdr-p_paddr; if (load_addr load_base) load_base = load_addr; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pager=1 as default? (Re: too many commands, help output rolls of screen)
Not yet, its not perfect just yet. For me on an apple efi macbook, pager=1 works very nicely on grub-efi (I did not know about it before), and can be unset, and it is great. But for grub ieee1275 on an apple ibookG4, it is useful, but has some erratic behaviour (garbling screen) and does not turn off with 'unset pager', so you don't want to be stuck with it. I don't know about grub-pc. On Mon, Nov 3, 2008 at 5:41 AM, Robert Millan [EMAIL PROTECTED] wrote: Since this was intentional, I'd like to know what others (specially the maintainers) think about this before proposing that it is changed... -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel peter cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Compilation PowerPC64
Also here on powerpc64 G5, after the recent change from grub_available_iterate() to grub_machine_mmap_iterate(). ... kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 There is a separate startup memory bug for G5 powerpc64 with grub_available_iterate()/grub_machine_mmap_iterate() '#address-cells' incorrect interpretation for Apple G5, causing grub_claim_heap to fail and the [Welcome to Grub! out of memory], I want to recheck this and explain if still present. Peter Cros. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
After Revision 1924 Harmonize ieee1275's grub_available_iterate() with the generic grub_machine_mmap_iterate() Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I am stuck with this error: kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 I cant find it, would appreciate help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
all fixed now thanks. On Sat, Nov 29, 2008 at 11:16 AM, peter cros [EMAIL PROTECTED] wrote: Yes, thanks, I already ran the patch and checked the files, but still get the error. I will recheck, I may be doing something wrong here, but no compile problems before 1924 . I dont know if the machine could affect this, it is Apple powermac G5. On Sat, Nov 29, 2008 at 12:57 AM, Manoel Rebelo Abranches [EMAIL PROTECTED] wrote: I have already sent a patch to correct this. look at the email with subject [PATCH] Compilation PowerPC64. It should work for you. On Sat, 2008-11-29 at 00:12 +1100, peter cros wrote: After Revision 1924 Harmonize ieee1275's grub_available_iterate() with the generic grub_machine_mmap_iterate() Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I am stuck with this error: kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 I cant find it, would appreciate help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Best Regards, Manoel Abranches [EMAIL PROTECTED] IBM Linux Technology Center Brazil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Peter Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 on efi32 - Apple Mac Mini
My current preferred bootloader is SVN version 1913 grub2.efi here on an Apple MacBook2,1. running Macosx10.4 and Ubuntu810 i386 32bit kernel (2.6.27 kernel), together with rEFIt 0.12 (but also used standalone). The amd64 kernel loaded but failed to complete initialization. Glad to know grub.efi still runs on the mini. To date I have not seen any reports of running on later MacBook versions. and the apple efi refused to load grub.efi on a macbook3,1. I have been trying to get Ubuntu forum people to test on other macs. I can comment on some of the issues mentioned. The rEFIt blesser resets to bless rEFIt on exit from Macosx. The explanation for this is on the rEFIt site. rEFIt has a case problem. The efi directory, containing grub.efi and refit.efi, needs to be upper case 'EFI' not 'efi', rEFIt confuses the case in the prefix passed to grub, hence loss of the grub.cfg menu. The failure to boot legacy bios may be associated with loss of MBR sector partitioning table (happens with the ubuntu linux parted partitioner for GPT/MBR disks). Check by a hexdump of the MBR sector. I can't get grub.efi to load rEFIt using chainloader, but I don't want to do that. I find considerable advantage over grub-pc is separate installation, off the linuix file system, and off the disk MBR sector, plus external drive bootability. Requirement to disable accelerated graphics is a stopper for some people. Pity it doesn't work on more macs. Peter Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
Hi, The kernel vesion may be the bug there, I have found grub.efi needs 2.6.26 or later, configured with EFI enabled, else the result is similar to yours. I have had a grub.efi test package built from vesion 1913, running in ubuntuforums.com (apple intel) for a while, a number of people tried it. grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, but no reports for Apple xserver, Imac or Mac Pro. It is therefore very interesting that grub.efi loads and runs on the Mac Pro, I would like to know what your the Model version is. peter cros On Wed, Jan 7, 2009 at 8:42 AM, Ziling Zhao zilingz...@gmail.com wrote: I'm trying to get grub2 working on a Mac Pro using pure EFI. So, I've mucked around a bit and grub is loading. I can have it load the linux image as well, but it freezes soon after. Output is: Booting 'Gentoo' [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Video mode: 180x1050...@0 Video frame buffer: f000 -- Then it freezes -- I seeded a bunch of grub_printf statements to see where it dies, and it seems like it calls grub_machine_fini() (grub_loader_noreturn) is set to 1. However, it doesn't seem to get back to grub_cmd_boot, which is calling grub_loader_boot. Anybody know what this is doing? I've heard that people have successfully gotten non rEFItted makes to boot Linux, can anybody confirm this? I compiled the grub2 stuff with ./configure --with-platform=efi --target=i386, this is grub trunk. -- ~Ziling Zhao ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
On Wed, Jan 7, 2009 at 4:14 PM, Bean bean12...@gmail.com wrote: On Wed, Jan 7, 2009 at 12:54 PM, peter cros pxwp...@gmail.com wrote: Hi, The kernel vesion may be the bug there, I have found grub.efi needs 2.6.26 or later, configured with EFI enabled, else the result is similar to yours. I have had a grub.efi test package built from vesion 1913, running in ubuntuforums.com (apple intel) for a while, a number of people tried it. grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, but no reports for Apple xserver, Imac or Mac Pro. Later models have switched to 64-bit firmware, you need to use x86_64-efi version of grub2. -- Bean Thanks, I tried a --target =x86_64, using multilib, compiled on the MacBook2,1 in i386, built OK, but could not run it on the macbook2,1. (I dont have a later model ) So does that mean I need to build another package for x86_64 and put that up for test on later version Mac, quite a few people interested, especially for external drive booting. peter cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
If not using refit, but using 'bless' from macosx - then grub.efi needs to be in an hfsplus partition on the usb stick. The built grub efi i386 tarball I use for macbook2,1 is on the ubuntu forum site, should suffice to show if you need x86_64. grub2 EFI boot loader http://ubuntuforums.org/showthread.php?t=995704 On Thu, Jan 8, 2009 at 12:34 AM, Türker SEZER turkerse...@tsdesign.infowrote: On Wednesday 07 January 2009 06:54:47 peter cros wrote: grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, but no reports for Apple xserver, Imac or Mac Pro. I have a clean xserve 8-core. I havent installed any service on it, yet. So i can test grub2, x86_64-efi etc. I tried to use steps at http://grub.enbug.org/TestingOnEFI address. But xserve doesnt accept my usb stick as a bootable media. (at startup, i hold option key, there is only my harddisks) If you tell me more way about testing grub2 on efi, i can do these tests. Türker Sezer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
It all seems a bit strange, [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Size=50 MB - very big kernel if it is true. On Fri, Jan 9, 2009 at 5:36 PM, Bean bean12...@gmail.com wrote: On Fri, Jan 9, 2009 at 5:32 AM, Ziling Zhao zilingz...@gmail.com wrote: I haven't had much success with testing directly on the XServe that I have here, but I was able to get as far as getting grub to show up. However, it stalls after: [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Video mode: 180x1050...@0 Video frame buffer: f000 Just as far as I can get the Mac Pro. I don't exactly have a macbook to test on, so I don't know if I'm just doing something wrong, or the Mac Pro/XServes are just different. Of course, using refit works on the mac pros, but applying the same process to the XServes didn't work. I've attached my .config just in case someone wants to look it over, I believe I have all the EFI stuff in there. Hi, The video mode line doesn't seem to be valid, so I guess xserver is indeed different. Fedora also have efi loader, which is basically some hacking with grub legacy. Perhaps you can try that and see if it works. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
iMac8,1 - grub.efi x86_64 hangs. built and run on the imac81 --with-platfrom=efi --target=x86_64 version 1913 and 1940 (current). Host ubuntu 810 amd64 kernel Linux im64 2.6.27-9-server #1 SMP Thu Nov 20 22:56:07 UTC 2008 x86_64 GNU/Linux grub.efi appears to be accepted by the firmware (started), but hangs immediately without any message. Tried with macosx bless, and with rEFIt, on HD and external usb. This differs from the 64/32 mismatch behaviour with the refit message 'unsupported while loading grub.efi') or the apple boot default to MacOSX. The x86_64 reult is different - bug in the start up? I will try to get some debug info. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
typo --with-platform=efi On Sun, Jan 11, 2009 at 1:44 PM, peter cros pxwp...@gmail.com wrote: iMac8,1 - grub.efi x86_64 hangs. built and run on the imac81 --with-platfrom=efi --target=x86_64 version 1913 and 1940 (current). Host ubuntu 810 amd64 kernel Linux im64 2.6.27-9-server #1 SMP Thu Nov 20 22:56:07 UTC 2008 x86_64 GNU/Linux grub.efi appears to be accepted by the firmware (started), but hangs immediately without any message. Tried with macosx bless, and with rEFIt, on HD and external usb. This differs from the 64/32 mismatch behaviour with the refit message 'unsupported while loading grub.efi') or the apple boot default to MacOSX. The x86_64 reult is different - bug in the start up? I will try to get some debug info. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
It is here - (return checked in refit efi shell and gui)
Can't go any further until that is fixed.
kern/x86_64/efi/startup.S
---
This hangs -
codestart:
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
+ret
callEXT_C(grub_main)
ret
-
This returns -
codestart:
+ret
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
callEXT_C(grub_main)
ret
--
Would really like to see the solution for the imac8,1.
peter cros
On Sun, Jan 11, 2009 at 6:35 PM, Bean bean12...@gmail.com wrote:
On Sun, Jan 11, 2009 at 10:44 AM, peter cros pxwp...@gmail.com wrote:
iMac8,1 - grub.efi x86_64 hangs.
built and run on the imac81 --with-platfrom=efi --target=x86_64
version 1913 and 1940 (current).
Host ubuntu 810 amd64 kernel Linux im64 2.6.27-9-server #1 SMP Thu Nov 20
22:56:07 UTC 2008 x86_64 GNU/Linux
grub.efi appears to be accepted by the firmware (started), but hangs
immediately without any message.
Tried with macosx bless, and with rEFIt, on HD and external usb.
This differs from the 64/32 mismatch behaviour with the refit message
'unsupported while loading grub.efi') or the apple boot default to
MacOSX.
The x86_64 reult is different - bug in the start up?
I will try to get some debug info.
Hi,
I only test the x86_64 version in macbook, which works nicely. Perhaps
you can add some debug code in kern/main.c
void
grub_main (void)
{
/* First of all, initialize the machine. */
grub_machine_init ();
+ grub_env_set (debug, all);
+ grub_printf (init\n);
/* Hello. */
grub_setcolorstate (GRUB_TERM_COLOR_HIGHLIGHT);
grub_printf (Welcome to GRUB!\n\n);
grub_setcolorstate (GRUB_TERM_COLOR_STANDARD);
Also, the tsc code may has some effect, remove grub_tsc_init in
kern/i366/efi/init.c:
void
grub_machine_init (void)
{
grub_efi_init ();
-grub_tsc_init ();
}
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
I tried your 64bit grub.efi, same result - hangs at start (on current
imac8,1).
I wonder if you have tested on the current MacBook or MacBook Pro, perhaps
Apple have made another change. Also I dont have any info on previous Imac
models.
I was able to get a return via grub_main() only by excluding both of the
movq lines in the code before the call. Either one hangs it.
Looks to be a problem with grub_efi_image_handle and grub_efi_system_table?
---
kern/x86_64/efi/startup.S
codestart:
callEXT_C(grub_main)
ret
-movq%rcx, EXT_C(grub_efi_image_handle)
-movq%rdx, EXT_C(grub_efi_system_table)
-
kern/main.c
void
grub_main (void)
{
return;
}
-
Is there anything else I can try?
peter cros
On Mon, Jan 12, 2009 at 4:04 AM, Bean bean12...@gmail.com wrote:
On Mon, Jan 12, 2009 at 12:00 AM, peter cros pxwp...@gmail.com wrote:
It is here - (return checked in refit efi shell and gui)
Can't go any further until that is fixed.
kern/x86_64/efi/startup.S
---
This hangs -
codestart:
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
+ret
callEXT_C(grub_main)
ret
-
This returns -
codestart:
+ret
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
callEXT_C(grub_main)
ret
--
Would really like to see the solution for the imac8,1.
Hi,
This is quite strange, it might be caused by the compiler. You can try
my version of grub.efi:
http://grub4dos.sourceforge.net/grub.zip
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
Those numbers look better. Hanging at that stage can be due to incorrect boot command - trying to boot a kernel which requires an initrd. (not the only possibility). In my case I use - linux /vmlinuz root=/dev/sda3 video=efifb initrd /initrd.img If I try to boot without initrd I get your result. On Tue, Jan 13, 2009 at 7:06 AM, Ziling Zhao zilingz...@gmail.com wrote: On Fri, Jan 9, 2009 at 4:06 PM, peter cros pxwp...@gmail.com wrote: It all seems a bit strange, [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Size=50 MB - very big kernel if it is true. On Fri, Jan 9, 2009 at 5:36 PM, Bean bean12...@gmail.com wrote: On Fri, Jan 9, 2009 at 5:32 AM, Ziling Zhao zilingz...@gmail.com wrote: I haven't had much success with testing directly on the XServe that I have here, but I was able to get as far as getting grub to show up. However, it stalls after: [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Video mode: 180x1050...@0 Video frame buffer: f000 Just as far as I can get the Mac Pro. I don't exactly have a macbook to test on, so I don't know if I'm just doing something wrong, or the Mac Pro/XServes are just different. Of course, using refit works on the mac pros, but applying the same process to the XServes didn't work. I've attached my .config just in case someone wants to look it over, I believe I have all the EFI stuff in there. Hi, The video mode line doesn't seem to be valid, so I guess xserver is indeed different. Fedora also have efi loader, which is basically some hacking with grub legacy. Perhaps you can try that and see if it works. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel I've just checked the kernel's size, and nothing is 50MB. After fiddling, now it says. (for x86 kernel) 3.5MB [Linux-bzImage, setup=0x3000, size=0x367f70] Video mode: 1280x1024...@0 Video frame buffer: f000 The x86_64 kernel has: [Linux-bzImage, setup=0x2c00, size=0x2ff470] Video mode: 1280x1024...@0 Video frame buffer: f000 -- ~Ziling Zhao ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 on MacBook4,1
Hi, I have the same results on different Apple Macs - hung after the refit boot screen Starting grub.efi . ( Stops in startup.S ) grub2 rev 1952 --with-platform=efi --target=x86_64 MacBook Pro 4,1 Boot ROM Version: MBP41.00C1.B03 SMC Version: 1.28f1 GeForce 8600M GT Vendor: NVIDIA (0x10de) Resolution: 1920 x 1200 - iMac8,1 Boot ROM Version: IM81.00C1.B00 SMC Version: 1.30f ATI Radeon HD 2600 Pro Vendor: ATI (0x1002) Resolution: 1920 x 1200 The same build runs on earlier 64bit EFI Macbooks. (with other problems later booting kernel ). Peter Cros On Fri, Jan 30, 2009 at 10:42 PM, pistacchie...@hotmail.com wrote: Hi, I tried grub2 rev 1962 on my MacBook4,1 Boot ROM Version:MB41.00C1.B00 SMC Version:1.31f0 I copied grub.efi mod files to grub folder in efi folder (I use refit 0.12) When I select start from grub.efi I'm unable to get grub prompt because it stop to starting grub.efi without any messages Thanks Davide -- check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messageshttp://www.microsoft.com/windows/windowslive/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub.efi x86_64 on Apple 64bit efi models - status of testing
I have got to a standstill with this, some major stoppers found and could
use some help to debug further. I hope someone can take a look at this
please, its getting beyond my limited C code reading and hacking
capabilities, but I do want to see grub.efi working on current Apple Intel
Macs.
Apple Linux/OSX users can benefit from grub.efi major advantages over the
Apple pc-bios emulation which cannot boot external drives and has other
installation problems for Linux users. Apple Mac users multi-booting
GNU/Linux and Mac OSX are a good testing ground for EFI booting. A number of
people in the ubuntuforums have tested grub.efi x86 and x86_64 on Apple
intel Macs from intel core2duo on. There have also been some recent reported
problems posted on grub-devel list.
I have not seen anything for IA32/64 machines.
From early 2008, Macs have been using 64bit EFI, needing x86_64 grub.efi,
and I have posted on ubuntuforums a full x86_64 grub.efi package with all
modules and grub.cfg for people to try.
No one has been able to get x86_64 grub.efi to boot and run either Mac OSX
(boot.efi) or ubuntu 810 2.6.27 kernels (configured for EFI). All this works
well for x86 grub.efi on Intel Macs with the earlier 32 bit firmware.
---
Three specific issues are stopping useful testing -
1. Mac models from imac8,1 early 2008 are unable to boot grub.efi 64bit when
4GB RAM is fitted.
Dropping to 2GB RAM enables grub.efi to boot and display grub.cfg menu
with fully functional command line. This leads to the next problems -
2. The grub.efi chainloader command fails to load
/usr/standalone/i386/boot.efi, reporting ' error: cannot load image '
3. grub.efi successfully loads ubuntu x86 2.6.7-7 kernel ( or earlier debian
2.6.26 ) using command line or menuentry, but the boot fails.
After boot command, the boot screen goes to black and no further progress
seen,
except in one case some garbled video indicating possible boot but failure
to init.
4. Finally, there was a problem getting ubuntu 810 amd64 to complete
initialization after booting in earlier 32 bit grub.efi tests, and other
issues with accelerated graphics and keyboard. - Not yet the issue here.
-
I got as far as locating the area in the grub2 code as shown in the attached
diffs of commented files, and will continue to look throught the code, or
can try any suggested debugging. I have some access to an Imac8,1 MacBook
Pro 4,1 and a MacBook2,1.
( So far using set debug=all or selective, grub_printf(); grub_getkey();
asm volatile (ret : : ); )
But I am not a programmer and need help to go further. The x86 32 bit
grub.efi functions very well on MacBook2,1 and other earlier 32 bit EFI
Apples, but the later models need the x86_64 build, and at present it is not
functional at all. The Apple firmware and EFI seems to need special
treatment.
-
Diffs - ( these are just grub2 rev 1972 commented 'pxwdebug' to show where I
got to )
Diff 1. Failing to run grub.efi with 4GB RAM.
grub2 r=1972
--- grub2a/kern/x86_64/efi/startup.S2009-02-04 17:04:14.0 +1100
+++ grub2b/kern/x86_64/efi/startup.S2009-02-09 18:19:32.0 +1100
@@ -57,10 +57,12 @@ VARIABLE(grub_prefix)
codestart:
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
+/*pxwdebug - with 4GB RAM, startup hangs before the call */
+
callEXT_C(grub_main)
ret
-
Diff 2. Failure of efi chainloader for Mac OSX
grub2 r=1972
--- grub2a/loader/efi/chainloader.c2009-02-04 17:04:22.0 +1100
+++ grub2b/loader/efi/chainloader.c2009-02-09 17:50:35.0 +1100
@@ -253,21 +253,21 @@ grub_rescue_cmd_chainloader (int argc, c
if (grub_errno == GRUB_ERR_NONE)
grub_error (GRUB_ERR_BAD_OS, too small);
goto fail;
}
-
+/* pxwdebug macosx 10.4 10.5 fail to load with grub.efi x86_64 */
status = efi_call_6 (b-load_image, 0, grub_efi_image_handle, file_path,
(void *) ((grub_addr_t) address), size,
image_handle);
if (status != GRUB_EFI_SUCCESS)
{
if (status == GRUB_EFI_OUT_OF_RESOURCES)
grub_error (GRUB_ERR_OUT_OF_MEMORY, out of resources);
else
grub_error (GRUB_ERR_BAD_OS, cannot load image);
-
+/*pxwdebug error message is cannot load image */
goto fail;
}
---
Diff 3. efi Linux boot fails.
grub2 r=1972
--- grub2a/loader/i386/efi/linux.c2009-02-04 17:04:22.0 +1100
+++ grub2b/loader/i386/efi/linux.c2009-02-09 18:09:22.0 +1100
@@ -419,19 +419,19 @@ grub_linux_boot (void)
asm volatile (cli : : );
/* Load the IDT and the GDT for the bootstrap. */
asm volatile (lidt %0 : : m (idt_desc));
asm volatile (lgdt %0 : : m (gdt_desc));
-
+/*pxwdebug x86_64 linux boot fails */
#ifdef __x86_64__
jumpvector.kernel_entry = (grub_uint64_t) grub_linux_real_boot;
jumpvector.kernel_cs =
Re: grub_machine_fini on efi systems
There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). On Tue, Feb 17, 2009 at 9:53 AM, phcoder phco...@gmail.com wrote: Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
1. Initially - With 2GB RAM Imac8,1 has 256MB VRAM Radeon HD2600 1920x1200 MBP4,1 has 512MB VRAM Nvidia 8600 1920x1200 Imac8,1 grub boot linux shows Video frame buffer at 9052 and blank screen. MBP4,1 gives 9000 and scrambled video. 2. By overriding video_base to set it at 2GB grub_linux_setup_video () video_base = 0; grub_pci_iterate (grub_find_video_card); /* override */ video_base = 0x8000; Result - MBP gets readable text screens from kernel boot and init. Imac gets scrambled video (better than nothing) 3. further fiddling with grub_linux_setup_video() params-lfb_line_len = 8192; changed fromm 8192 to = width*4 gets clear script for Imac, but MBP wants 8192. 4. The results with 4GB RAM will differ I expect, and later effects unknown as the linux initialization is not completing (other issues with libata). On Tue, Feb 17, 2009 at 2:02 PM, Bean bean12...@gmail.com wrote: On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros pxwp...@gmail.com wrote: There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). Hi, What's your frame buffer address, does grub_find_video_card detect it wrong ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bug fix for x86_64 efi
Tested the patch applied to rev 1996 for grub.efi 64 bit and 32 bit, on Imac81 (4GB ram), MacBookPro41 (4GB and 2GB ram) MacBook21 (i386) with Macosx 10.4 10.5, ubuntu810. All good. 64bit Macs have other ongoing EFI problems with linux kernel initializtion and keyboard. On Fri, Feb 20, 2009 at 2:12 AM, Bean bean12...@gmail.com wrote: Hi, This patch contains several important update for x86_64 efi: 1, Support memory larger than 2G. 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. 3, Improve the method to detect frame buffer address and line length in linux loader. 2009-02-19 Bean bean12...@gmail.com * configure.ac: Check for -mcmodel=large in x86_64 target. * include/grub/efi/api.h (efi_call_10): New macro. (efi_wrap_10): New function. * include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. (GRUB_PE32_REL_BASED_HIGH): Likewise. (GRUB_PE32_REL_BASED_LOW): Likewise. (GRUB_PE32_REL_BASED_HIGHLOW): Likewise. (GRUB_PE32_REL_BASED_HIGHADJ): Likewise. (GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. (GRUB_PE32_REL_BASED_SECTION): Likewise. (GRUB_PE32_REL_BASED_REL): Likewise. (GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. (GRUB_PE32_REL_BASED_DIR64): Likewise. (GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. * kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Fixed relocation issue. * kern/x86_64/efi/callwrap.S (efi_wrap_6): Bug fix. (efi_wrap_10): New function. * kern/x86_64/efi/startup.S (codestart): Use relative addressing. * loader/efi/appleloader.c (devpath_5): Add support for late 2008 MB/MBP model (NV chipset). (devdata_devs): Add devpath_5 to the list. * load/i386/efi/linux.c (video_base): Remove variable. (RGB_MASK): New macro. (RGB_MAGIC): Likewise. (LINE_MIN): Likewise. (LINE_MAX): Likewise. (FBTEST_STEP): Likewise. (FBTEST_COUNT): Likewise. (fb_list): New variable. (grub_find_video_card): Remove function. (find_framebuf): New function. (grub_linux_setup_video): Use find_framebuf to get frame buffer and line length. * util/i386/efi/grub-mkimage.c (grub_reloc_section): Fix relocation problem for x86_64. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bug fix for x86_64 efi
Hi, True we don't have any grub.efi Apple intel Xserve hardware tests so far, at the apple intel ubuntu forum, but the grub-efi test packages there could be used to test. Seems you will need to get some current grub.efi test result to point to problems specific to the Xserve, sufficient to attract help at developer level. There are also some graphics limitations (use of framebuffer driver) after EFI linux booting for other intel macs, might be important for your application. On Sun, Feb 22, 2009 at 2:16 PM, Drew Rosen drew...@mac.com wrote: Thanks for your interest in helping Peter. At first look, the ubuntu forum looks like we're seeing xserver info, but no one using MacIntel Xserve hardware to test grub. If you know anyone who could help us push thru what is causing the Xserve to not work like the MacIntel Mac Pro Desktops, I'M LOOKING FOR THAT PERSON... Cheers. On Feb 20, 2009, at 9:32 PM, Peter Cros wrote: I am just a grub.efi user/tester/enthusiast. I don't know the Xserve but some previous reports in this list of people getting grub.efi to boot on Xserve, and if so it will boot hd/usb linux on other Apple intel Macs with varying results . There are some grub.efi 64/32 bit test packages on ubuntuforums that you might try (include the patch) . Xserve results would be interesting. grub2 EFI boot loader internal/external bootinghttp://ubuntuforums.org/showthread.php?t=995704 On Sat, Feb 21, 2009 at 3:16 AM, Drew Rosen drew...@mac.com wrote: Hi Peter / phcoder / all other grub gurus, I've joined the grub-devel mail list while attempting to get MacIntel Xserves to boot linux. I work with a 3d Movie Effects company that has 25 MacIntel Xserves that are becoming close to as useful as paperweights because they can't run Maya at 64bit for rendering. (and we can't repurpose them as linux servers). Any chance we can help test this patch in an xserve environment, and/or do you have any ideas that would help us? Here's the most discouraging info I've received in my research to date: The Xserve does not have BIOS compatibility, and so you'll need to boot through EFI. The Apple EFI implementation will not boot directly off ISO9660 media, so you'll need to find a way to get to the EFI console. You'll need a kernel configured with EFI support. There's no especially sensible way to get a working framebuffer on this hardware, so you'll need to work out what arguments need to be passed to your distribution's installer in order to get it to run over the serial port. elilo or grub-efi should be able to boot the kernel and initramfs. I've been catologing my research at: http://drewsta.com/xserve.html Thanks! Drew On Feb 20, 2009, at 6:28 AM, Peter Cros wrote: Tested the patch applied to rev 1996 for grub.efi 64 bit and 32 bit, on Imac81 (4GB ram), MacBookPro41 (4GB and 2GB ram) MacBook21 (i386) with Macosx 10.4 10.5, ubuntu810. All good. 64bit Macs have other ongoing EFI problems with linux kernel initializtion and keyboard. On Fri, Feb 20, 2009 at 2:12 AM, Bean bean12...@gmail.com wrote: Hi, This patch contains several important update for x86_64 efi: 1, Support memory larger than 2G. 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. 3, Improve the method to detect frame buffer address and line length in linux loader. 2009-02-19 Bean bean12...@gmail.com * configure.ac: Check for -mcmodel=large in x86_64 target. * include/grub/efi/api.h (efi_call_10): New macro. (efi_wrap_10): New function. * include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. (GRUB_PE32_REL_BASED_HIGH): Likewise. (GRUB_PE32_REL_BASED_LOW): Likewise. (GRUB_PE32_REL_BASED_HIGHLOW): Likewise. (GRUB_PE32_REL_BASED_HIGHADJ): Likewise. (GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. (GRUB_PE32_REL_BASED_SECTION): Likewise. (GRUB_PE32_REL_BASED_REL): Likewise. (GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. (GRUB_PE32_REL_BASED_DIR64): Likewise. (GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. * kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Fixed relocation issue. * kern/x86_64/efi/callwrap.S (efi_wrap_6): Bug fix. (efi_wrap_10): New function. * kern/x86_64/efi/startup.S (codestart): Use relative addressing. * loader/efi/appleloader.c (devpath_5): Add support for late 2008 MB/MBP model (NV chipset). (devdata_devs): Add devpath_5 to the list. * load/i386/efi/linux.c (video_base): Remove variable. (RGB_MASK): New macro. (RGB_MAGIC): Likewise. (LINE_MIN): Likewise. (LINE_MAX): Likewise. (FBTEST_STEP): Likewise. (FBTEST_COUNT): Likewise. (fb_list): New variable. (grub_find_video_card): Remove function. (find_framebuf): New function. (grub_linux_setup_video): Use find_framebuf to get
Re: Boot delay when using grub.efi on Mac Mini
Hi, Try the other instructions for MacBook http://grub.enbug.org/TestingOnMacbook ( recentlu updated ) including bless --folder --file --setBoot (not --mount) Some more tests done at ubuntuforums.org http://ubuntuforums.org/showthread.php?t=995704 On Wed, Mar 11, 2009 at 10:48 AM, Grant Edwards gra...@visi.com wrote: On 2009-03-10, Grant Edwards gra...@visi.com wrote: I installed EFI grub (svn r2024) on a Mac Mini (1.8GHz Core 2 Duo) following the instructions at http://grub.enbug.org/TestingOnEFI. Grub seems to work fine: the menu works, and I can either boot a Linux kernel or I can chainload OS X via /usr/standalone/i386/boot.efi. One more problem I haven't figured out: the control keys don't work (known issue), so after you've edited a menu entry, how do you boot it? -- Grant Edwards grante Yow! Quick, sing me the at BUDAPEST NATIONAL ANTHEM!! visi.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
I have used a separate small hfs+ partition, works well, and fast if blessed. The EFI FAT32 partition is OK and a good backup if using rEFIt to recognise it without needing to bless, but cant be blessed --folder. On Thu, Mar 12, 2009 at 9:51 AM, Grant Edwards gra...@visi.com wrote: On 2009-03-11, phcoder phco...@gmail.com wrote: Grant Edwards wrote: On 2009-03-11, Grant Edwards gra...@visi.com wrote: Moving grub from the EFI FAT32 partition to the HFS+ partition eliminates the 30-second delay. In this case the status looks like this: It's usable this way except it would be nice to have grub in a second parition. That way if I break grub, I can still hold down the option key and select the OS-X HFS+ partition. You can always format an additional HFS+ partition That sounds like something worth trying. We don't know if it's working because it's in an HFS+ partition or if it's working because it's in the same parition as OS-X. Maybe I'll stick in a USB flash drive with a GPT partition table and an HFS+ partition. -- Grant Edwards grante Yow! -- I love KATRINKA at because she drives a visi.comPONTIAC. We're going away now. I fed the cat. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
A brief read of the mininmyth docs suggests it can also run on a fat partition on the gpt hard disk. You can put an hfs+ partition on a msdos disk, or a fat32 partition on a gpt disk and grub.efi can handle both. plus linux ext2/3. Have you installed the rEFIt boot manager http://refit.sourceforge.net/ It simplifies testing and the web site has good information on Apple efi booting and some history. You need to read the Mac OSX bless manual closely to compare the options, and experiment. Seems to me the key issue is getting your kernel and system running, identity any grub development issues, the other stuff can be optimised later. My experience has been with other users of Apple Intel Macs bootng Debian/Ubuntu linux and Mac OSX, using grub-pc and grub-efi. It helps to have a linux installation on the hard drive. On Fri, Mar 13, 2009 at 1:37 AM, Grant Edwards gra...@visi.com wrote: On 2009-03-12, Peter Cros pxwp...@gmail.com wrote: I have used a separate small hfs+ partition, works well, and fast if blessed. I think that's what I'll try next. The other option I'd like to try is a GPT-partitioned USB flash drive. For that to be advantageous, I would need to add GPT partition table support to my Linux kernel to avoid having to plug in a second USB flash drive for the MiniMyth files. [The goal of the exercise is to use a Mac Mini as a diskless MythTv frontend using the distro from www.minimyth.org. This Mini is my first Mac since the 68k days, and I'm very impressed with the hardware, but the firmware seems mediocre at best.] The EFI FAT32 partition is OK and a good backup if using rEFIt to recognise it without needing to bless, but cant be blessed --folder. That's what I'd more-or-less concluded. I tried blessing the device (/dev/disk0s1) and that didn't make any difference either. What's odd is that I found step-by-step instructions that specifically show booting elilo from the EFI partition on an Intel Mac Mini at http://www.mythic-beasts.com/resources/macmini/walkthrough.html Did other versions of firmware allow blessing the EFI partition somehow? -- Grant Edwards grante Yow! Now I understand the at meaning of THE MOD SQUAD! visi.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
grub.efi booting from hfsplus on external msdos usb drive has worked for me, maybe I was usiing rEFIt. On Sat, Mar 14, 2009 at 4:20 AM, phcoder phco...@gmail.com wrote: Apple says that booting from msdos partition is unsupported, however I've reports of people successfully doing so Grant Edwards wrote: On 2009-03-13, phcoder phco...@gmail.com wrote: Have you tried booting from hfs+ on msdos? Actually I haven't. I found multiple postings in various places saying that Mac firmware would only boot from USB drives if they were GPT partitioned, so I never bothered to try it. I'll give that a try as well. -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
On Sat, Mar 14, 2009 at 1:26 AM, Grant Edwards gra...@visi.com wrote: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. I got curious and rechecked this - Here is grub.efi booting from usb msdos drive with hfsplus partition - sh-3.2# diskutil list /dev/disk1 /dev/disk1 #: TYPE NAMESIZE IDENTIFIER 0: FDisk_partition_scheme*1.9 Gi disk1 1: Linux 1.2 Gi disk1s1 2: Apple_HFS disk1s2 572.6 Mi disk1s2 3: DOS_FAT_32 fat32 100.4 Mi disk1s3 sh-3.2# bless --folder /Volumes/disk1s2 --file /Volumes/disk1s2/grub64.efi --label msdoshfsp --setBoot sh-3.2# bless --info /Volumes/disk1s2 finderinfo[0]: 2 = Blessed System Folder is /Volumes/disk1s2/ finderinfo[1]: 85 = Blessed System File is /Volumes/disk1s2/grub64.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 2 = OS X blessed folder is /Volumes/disk1s2/ 64-bit VSDB volume id: 0x795006DDA23084CA sh-3.2# --setBoot gives deafult fast boot to grub menu, but when booted that way, grub can only see its own disk (hd0) If booted via Option key or rEFIt all drives are seen and bootable. 2) MiniMyth kernel lacks support for EFI/GPT parition tables and SATA hard drives. On the GPT drive, an MSDOS partition table is generated from gpt tables by the Mac OSX Bootcamp utility which creates a fat32 partition for the Windows msdos compatible mode. Or the msdos MBR can also be checked and generated by rEFIt (used by apple intel linux users). The list of drivers for minimyth seems to include those used for sata on my macs, but you may have better info. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
Don't know, rechecked it here and it sees all the usb partitions whichever way its booted, maybe something wrong with your grub.efi build preloaded modules. Check the latest svn. On Sun, Mar 22, 2009 at 8:30 AM, Grant Edwards gra...@visi.com wrote: On 2009-03-14, Peter Cros pxwp...@gmail.com wrote: On Sat, Mar 14, 2009 at 1:26 AM, Grant Edwards gra...@visi.com wrote: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. I got curious and rechecked this - Here is grub.efi booting from usb msdos drive with hfsplus partition - When I try that, I get one of two things: 1) When it boots directly into grub, grub can only see hd0 (which appears to be the USB drive), but it can't see any of the paritions on hd0. Needless to say, it can't find it's config file. 2) Holding down the Option key and selecting grub allows it to see both disks -- it can see partitions on the GPT-partitioned hard drive but not on the MS-DOS partitioned USB drive. I can manually load a config-file from the hard drive, none of the menu entries work -- I see stuff like error: unknown command `initrd' or error: unkown command `search' Here's the info on the USB drive: bash-3.2# diskutil list /dev/disk1 /dev/disk1 #: TYPE NAMESIZE IDENTIFIER 0: FDisk_partition_scheme*3.7 Gi disk1 1: DOS_FAT_32 minimyth1.9 Gi disk1s1 2: Apple_HFS mmhfs 1.9 Gi disk1s2 bash-3.2# bless --info /Volumes/mmhfs finderinfo[0]: 2 = Blessed System Folder is /Volumes/mmhfs/ finderinfo[1]:120 = Blessed System File is /Volumes/mmhfs/efi/grub/grub.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 2 = OS X blessed folder is /Volumes/mmhfs/ 64-bit VSDB volume id: 0xA3FBF66150DE9BB1 --setBoot gives deafult fast boot to grub menu, but when booted that way, grub can only see its own disk (hd0) Same here, and it can't see any of the partitions on that disk. End result: still no luck booting from USB drive, just a larger variety of failure modes. -- Grant ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New frame buffer detection algorithm and loadrom command for efi platform
Hi,
svn rev 2043 patched loadrom.diff on imac81 with ati fglrx.
I find loadrom needs time when called in menuentry, otherwise linux load
fails or loadrom fails. So I had to use sleep.
Then it works very nicely.
--
insmod sleep
menuentry loadrom hd0,4 sda4 {
search --set /ivt.bin
loadrom /bios.bin /ivt.bin
sleep 1
root=hd0,4
linux /vmlinuz root=/dev/sda4 video=vesafb
initrd /initrd.img
}
This is not apparent from command line with manual entry pauses.
-
2009/3/21 Bean bean12...@gmail.com
Hi,
This patch improves the frame buffer detection algorithm. It uses pci
to find the video memory base, then scan it for frame buffer.
It also add a loadrom command which can be used to enable accel
graphic driver. The idea is that you can grab the video bios dump, and
optionally the IVT from pc mode, then load them in efi.
To grab bios dump:
sudo dd if=/dev/mem of=bios.bin bs=65536 skip=12 count=1
You can also include the system bios by changing the count to 4.
To grab IVT dump:
sudo dd if=/dev/mem of=ivt.bin bs=1024 count=1
Then, to load them in grub-efi (ivt.bin is optionally):
loadrom /bios.bin /ivt.bin
Here are some of the findings concerning different video cards:
Old 32-bit efi model, intel card:
Works with intel driver, no need to load vbios or ivt.
New 64-bit efi model, intel card:
Works with intel driver, needs to load vbios.
New 64-bit efi model, nvidia card:
Works with nvidia driver, no needs to load vbios or ivt. However, the
backlight value is set too low so desktop is barely visible. You need
to use a small tool to adjust backlight. The nv driver doesn't work.
New 64-bit efi model, ati radeon card:
Works with fglrx driver, needs to load vbios and ivt. The radeonhd
driver doesn't work.
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Cros (pxw)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: no commit allowed under discussion
Hi, It will be good to get this resolved and on SVN grub2 so people (ubuntuforums) can build for Apple efi with the latest 'hacks' (fakebios, loadbios etc) found necessary in testing. Particlarly Xserve which requires efi boot. On 4/7/09, Bean bean12...@gmail.com wrote: On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji ok...@enbug.org wrote: On Tuesday 07 April 2009 01:43:17 Bean wrote: On Sat, Apr 4, 2009 at 8:53 PM, Bean bean12...@gmail.com wrote: On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji ok...@enbug.org wrote: I've undone r2063, since we're still discussing how to / not to split modules. Bean, you must respect teamwork. If you are unable to follow such a fundamental rule, I will have to disable your permission. Hi, I thought the previous mail is about replacing grub_printf with grub_dprint, I'm ok with that. This patch has been in mail list for sometime, it is essential to get a working display in intel macs. Hi, How about this patch ? The split is necessary as it introduces new command loadbios and fakebios that uses the fake_bios_data function, and it would be ugly to put them all inside linux.c. Do you have any strong reason to make loadbios and fakebios separate? I think the overhead is negligible. Hi, loadbios and fakebios are sort of like hacks for the efi platform, I think they shouldn't be placed in the linux loader. Also, by moving the platform dependent code out, we can merge it with i386 generic loader loader/i386/linux.c. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: no commit allowed under discussion
I posted binaries from grub2 rev 2074 with all modules, for further evaluation - http://ubuntuforums.org/showpost.php?p=7061606postcount=595 (post #595 grub2074.tar.gz ) On Tue, Apr 14, 2009 at 9:17 PM, Peter Cros pxwp...@gmail.com wrote: Hi, SVN rev 2074 should be good for Xserve1,1 and 1,2 according to tests we ran at ubuntu forums. On Tue, Apr 14, 2009 at 6:23 PM, Drew Rosen drew...@mac.com wrote: Hi Peter Cros, If you need anyone to run tests on the Xserve, I have a score of machines that we want to use on Linux... On Apr 9, 2009, at 7:23 AM, Peter Cros wrote: Hi, It will be good to get this resolved and on SVN grub2 so people (ubuntuforums) can build for Apple efi with the latest 'hacks' (fakebios, loadbios etc) found necessary in testing. Particlarly Xserve which requires efi boot. On 4/7/09, Bean bean12...@gmail.com wrote: On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji ok...@enbug.org wrote: On Tuesday 07 April 2009 01:43:17 Bean wrote: On Sat, Apr 4, 2009 at 8:53 PM, Bean bean12...@gmail.com wrote: On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji ok...@enbug.org wrote: I've undone r2063, since we're still discussing how to / not to split modules. Bean, you must respect teamwork. If you are unable to follow such a fundamental rule, I will have to disable your permission. Hi, I thought the previous mail is about replacing grub_printf with grub_dprint, I'm ok with that. This patch has been in mail list for sometime, it is essential to get a working display in intel macs. Hi, How about this patch ? The split is necessary as it introduces new command loadbios and fakebios that uses the fake_bios_data function, and it would be ugly to put them all inside linux.c. Do you have any strong reason to make loadbios and fakebios separate? I think the overhead is negligible. Hi, loadbios and fakebios are sort of like hacks for the efi platform, I think they shouldn't be placed in the linux loader. Also, by moving the platform dependent code out, we can merge it with i386 generic loader loader/i386/linux.c. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
Hi, Tested and works on Apple imac81 with Mac OSX 10.5, patch applied to r 2074 grub hfspbless (hd0,3)/efi Last login: Sun Apr 19 14:30:23 on console im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 52 = Blessed System Folder is /Volumes/hfsp/efi finderinfo[1]: 0 = No Blessed System File finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 0 = No OS 9 + X blessed X folder 64-bit VSDB volume id: 0x0F87F7680B9C5211 im81:~ pxw$ Now it just needs to bless the file in order to boot from grub.efi on Apple EFI hfspbless DIRECTORY FILE This would be VERY useful, making grub.efi boot possible on Apple Mac without needing Mac OSX or refit. hfspbless is fine for a name 2009/4/19 Vladimir Serbinenko phco...@gmail.com Hello, due to request by ams I wrote this. It's an analog of bless command available under OSX rewritten using grub2 fs functions and according to apple specification of hfs+ on-disk format. This command only update the blessed folder on a partition it doesn't change which drive is used for booting. The later will be a separate command. Also you can choose which volume to boot from by holding option key. Syntax: hfspbless DIRECTORY It works only on HFS+ volumes. Also due to the lack of hardware I wasn't unable to test this in vivo ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
bless.diff version 2. success. cleared all bless on hfsplus partition in OSX. grub hfspbless (hd0,3)/efi/test/grub523.efi Back to OSX - Last login: Sun Apr 19 22:48:43 on console im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 75 = Blessed System Folder is missing finderinfo[1]: 7857 = Blessed System File is /Volumes/hfsp/efi/test/grub523.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 0 = No OS 9 + X blessed X folder 64-bit VSDB volume id: 0x0F87F7680B9C5211 It boots - Restart with option key gives the Apple EFI disk icon, which boots grub523.efi Confirmed with shutdown-restart again. Redundant info - I checked the OSX bless utility, it requires both folder and file, or it will not agree to bless the file. im81:~ pxw$ sudo bless --folder /Volumes/hfsp/efi/test --file /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 7882 = Blessed System Folder is /Volumes/hfsp/efi/test finderinfo[1]: 7885 = Blessed System File is /Volumes/hfsp/efi/test/grub523.efi Now all we need is --setBoot to make grub.efi the default boot, no Option key required. Oh, and how do we get grub.efi booted to bless itself - the only way I know at present is to use a rEFIt CD, which is bootable by Apple EFI. On Sun, Apr 19, 2009 at 8:50 PM, Vladimir Serbinenko phco...@gmail.comwrote: Hello, thank you for the testing. Two concepts together (system folder and system file) are clearly redundant. I thought that intel macs look which folder is blessed and load boot.efi file from this directory. Here I attach a patch which updates finderinfo[0] when argument is a directory and finderinfo[1] when argument is a file. Can you do a test and tell me which concept is really used by intel macs? When doing tests don't forget to hold option key and select your testing partition. I will do a similar test on my ppc mac On Sun, Apr 19, 2009 at 6:51 AM, Peter Cros pxwp...@gmail.com wrote: Hi, Tested and works on Apple imac81 with Mac OSX 10.5, patch applied to r 2074 grub hfspbless (hd0,3)/efi Last login: Sun Apr 19 14:30:23 on console im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 52 = Blessed System Folder is /Volumes/hfsp/efi finderinfo[1]: 0 = No Blessed System File finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 0 = No OS 9 + X blessed X folder 64-bit VSDB volume id: 0x0F87F7680B9C5211 im81:~ pxw$ Now it just needs to bless the file in order to boot from grub.efi on Apple EFI hfspbless DIRECTORY FILE This would be VERY useful, making grub.efi boot possible on Apple Mac without needing Mac OSX or refit. hfspbless is fine for a name 2009/4/19 Vladimir Serbinenko phco...@gmail.com Hello, due to request by ams I wrote this. It's an analog of bless command available under OSX rewritten using grub2 fs functions and according to apple specification of hfs+ on-disk format. This command only update the blessed folder on a partition it doesn't change which drive is used for booting. The later will be a separate command. Also you can choose which volume to boot from by holding option key. Syntax: hfspbless DIRECTORY It works only on HFS+ volumes. Also due to the lack of hardware I wasn't unable to test this in vivo ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
Thanks that is going to be very useful. Just some further comment from the little I know - On Mon, Apr 20, 2009 at 12:14 AM, Vladimir Serbinenko phco...@gmail.comwrote: Now the question is how we do it. We can either keep the current syntax or IMO it's better to have two commands: intelmacbless and ppcmacbless both accepting file as an argument. First one updates finderInfo[1] and the second one updates finderInfo[0] and sets filetype of given file to tbxi and if any other file has the type tbxi in the same directory then change it to any other value (e.g. tbxj) The finderinfo[1] file blessing does seem the best for intel mac, but just based on my imac81 test with current EFI. Now all we need is --setBoot to make grub.efi the default boot, no Option key required. In my todo. Thanks to ams I have all the needed info now Oh, and how do we get grub.efi booted to bless itself - the only way I know at present is to use a rEFIt CD, which is bootable by Apple EFI. I don't understand your question but hfspbless works in grub-emu too. Do you mean run grub-emu as part of a linux installation to bless grub.ef? It seems to leave the problem of booting the linux installer, which is easy to do from grub.efi - if it is blessed. At present we install grub.efi manually, using only grub-mkimage to build grub.efi, without using other grub utilities, and mostly just use preloaded modules. Here is some more info for the intel mac - Further checking shows that Apple EFI will detect and boot an unblessed file named boot.efi but only if the enclosing folder is blessed. Will not boot unblessed grub.efi in the same folder. im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 7891 = Blessed System Folder is /Volumes/hfsp/efi/test finderinfo[1]: 0 = No Blessed System File finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 7891 = OS X blessed folder is /Volumes/hfsp/efi/test 64-bit VSDB volume id: 0x0F87F7680B9C5211 im81:~ pxw$ ls /Volumes/hfsp/efi/test boot.efi grub.cfg grub523.efi grub523.icns grub64.icns im81:~ pxw$ That boots boot.efi using the Option key. For OSX boot.efi - im81:~ pxw$ bless --info / finderinfo[0]:149 = Blessed System Folder is /System/Library/CoreServices finderinfo[1]: 297081 = Blessed System File is /System/Library/CoreServices/boot.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]:149 = OS X blessed folder is /System/Library/CoreServices 64-bit VSDB volume id: 0x0F8CB2A6A4C456E8 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Hi, Compiled with rev 2121, --with-platform=efi but got no gptsync module. It could be a useful tool for macs, I would like to try it. On Mon, Apr 20, 2009 at 9:17 AM, Vladimir Serbinenko phco...@gmail.comwrote: Hello, this is a common way to boot non GPT-aware OS on GPT systems. For this protective MBR is replaced by a so-called hybrid mbr where first partition entry is a protective entry and the rest contains legal partitions. So here is the syntax: gptsync DISK [PARTITIONSPEC1] [PARTITIONSPEC2] [PARTITIONSPEC3] PARTITIONSPEC says which partitions have to be shown to legacy OS. It always begins with the partition number. Then optionally goes one of the following: nothing. Autodetect partition type, not active partition +. Like preceding but make partition active -TYPE. Use TYPE type as MBR partition type +TYPE. Like preceding but make partition active ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
Hi, On Mon, Apr 20, 2009 at 6:05 AM, Vladimir Serbinenko phco...@gmail.comwrote: Hello You can use the bootable CD of your favourite distro. I hope that grub2.efi will become a default bootloader to install on efi system for major linux distributions The thought was just to avoid dependance on the apple pc-bios emulation and go toward a grub.efi installation as you suggest. (Also the apple Xserve machines do not have pc-bios emulation.) Could you determine the priority? E.g. if you have both blessed file and boot.efi in blessed directory which one is loaded? In both these cases the blessed grub.efi file is selected and boots. The boot.efi file here is a copy of the OSX boot.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 7891 = Blessed System Folder is missing finderinfo[1]: 8123 = Blessed System File is /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 8120 = Blessed System Folder is /Volumes/hfsp/efi/test finderinfo[1]: 8123 = Blessed System File is /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ ls /Volumes/hfsp/efi/test/*.efi /Volumes/hfsp/efi/test/boot.efi /Volumes/hfsp/efi/test/grub523.efi -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
My reply was delayed by network going down. On Mon, Apr 20, 2009 at 9:52 PM, Vladimir Serbinenko phco...@gmail.comwrote: The bootable cd can have both eltorito (bios) and grub2.efi I like the grub.efi CD. But what happens if you do something like: blessed folder - /test1 contains boot.efi blessed file - /test2/grub2.efi grub.efi wins. We have this - (not exactly as above ) /Volumes/hfsp/boot.efi /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 2 = Blessed System Folder is /Volumes/hfsp/ finderinfo[1]: 8256 = Blessed System File is /Volumes/hfsp/efi/test/grub523.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 2 = OS X blessed folder is /Volumes/hfsp/ 64-bit VSDB volume id: 0x0F87F7680B9C5211 Apple Option restart shows the EFI boot icon, this boots grub523.efi, Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Hi, I have been playing with grub gptsync, on apple intel mac with GUID partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI system part for macs. I am comparing with the gptsync utility from linux, or rEFIt gptsync, currently used for macs booting pc-bios bootloader. It is working to allow selection of GPT partions for MBR 2, 3, 4 but some of the numbers look wrong. I have not tried setting flags. grub gptsync is not handling MBR partition table 1 the same way as current linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR part1. GPT Partions are (512 byte sectors) Current GPT partition table: # Start LBA End LBA Type 1 40 409639 EFI System (FAT) 2 409640 2395367 Mac OS X HFS+ 32395368 4573255 Mac OS X HFS+ 44835400 7141399 Mac OS X HFS+ 57403544 9965767 Mac OS X HFS+ 6 10227912 13046359 Mac OS X HFS+ 7 13308504 15642623 Mac OS X HFS+ 8 15904768 15949783 Mac OS X HFS+ There seems to be agreement about start and end on MBR table partitions 2 3 4, using grub gptsync (hd0) 2 3 4. Other bytes differ (type, flags). This is after grub gptsync (hd0) 2 3 4 (MBR part1 was initially set by linux gptsync) p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb [sudo] password for pxw: 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f |..'@| 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a |-.(@...L| 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc |W...$.`;!...| 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa |Y,..c.H.I../#.U.| 0200 Then as seen in linux gptsync, Current MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 409640 2395367 83 Linux 32395368 4573255 83 Linux 44835400 7141399 83 Linux Status: MBR table must be updated. Proposed new MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 * 409640 2395367 af Mac OS X HFS+ 32395368 4573255 af Mac OS X HFS+ 44835400 7141399 af Mac OS X HFS+ May I update the MBR as printed above? [y/N] y Yes p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe |..'@| 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe |..(@...L| 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe |$.`;!...| 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa |..H.I../#.U.| 0200 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
There appears to be a small bug there. For example - gptsync (hd0) 4 2 3 will write data for GPT partition 4 2 3 to MBR partition table 2 3 4 but also GPT partition 1 to MBR partition 1 (which is actually what happens now for intel mac.) And similarly for other selections will write the next lower gpt partition number to MBR partition 1 slot. I don't think it is compatible with current MBR/GPT hybrid partitioning on intel macs for grub-pc booting. On Wed, Apr 22, 2009 at 1:10 AM, Vladimir Serbinenko phco...@gmail.comwrote: On Tue, Apr 21, 2009 at 1:29 PM, Peter Cros pxwp...@gmail.com wrote: Hi, I have been playing with grub gptsync, on apple intel mac with GUID partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI system part for macs. I am comparing with the gptsync utility from linux, or rEFIt gptsync, currently used for macs booting pc-bios bootloader. It is working to allow selection of GPT partions for MBR 2, 3, 4 but some of the numbers look wrong. I have not tried setting flags. grub gptsync is not handling MBR partition table 1 the same way as current linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR part1. I don't understand what you mean. I will not do any special treatment for EFI system partition. As far as I'm concerned it's just a partition. I don't think it's a problem since user can ask which partitions to put in MBR GPT Partions are (512 byte sectors) Current GPT partition table: # Start LBA End LBA Type 1 40 409639 EFI System (FAT) 2 409640 2395367 Mac OS X HFS+ 32395368 4573255 Mac OS X HFS+ 44835400 7141399 Mac OS X HFS+ 57403544 9965767 Mac OS X HFS+ 6 10227912 13046359 Mac OS X HFS+ 7 13308504 15642623 Mac OS X HFS+ 8 15904768 15949783 Mac OS X HFS+ There seems to be agreement about start and end on MBR table partitions 2 3 4, using grub gptsync (hd0) 2 3 4. Other bytes differ (type, flags). This is after grub gptsync (hd0) 2 3 4 (MBR part1 was initially set by linux gptsync) p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb [sudo] password for pxw: 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f |..'@| 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a |-.(@...L| 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc |W...$.`;!...| 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa |Y,..c.H.I../#.U.| 0200 Then as seen in linux gptsync, Current MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 409640 2395367 83 Linux 32395368 4573255 83 Linux 44835400 7141399 83 Linux Status: MBR table must be updated. Proposed new MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 * 409640 2395367 af Mac OS X HFS+ 32395368 4573255 af Mac OS X HFS+ 44835400 7141399 af Mac OS X HFS+ May I update the MBR as printed above? [y/N] y Yes Here there are 2 differences. First partition type for hfs+ isn't autodetected, I will fix this, just I thought it ws unnecessary AFAIK every OS which understands HFS+ understands GPT. The second thing is that none of partiion is active. Here you have just to tell which partition is active. You can have the same behavior as OSX gptsync with command gptsync hd0 2+0xaf 3-0xaf 4-0xaf Once I add hfs+ autodetect it will be enough to do gptsync hd0 2+ 3 4 p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe |..'@| 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe |..(@...L| 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe |$.`;!...| 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa |..H.I../#.U.| 0200 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 3:45 PM, Bean bean12...@gmail.com wrote: Hi, I've documented the usage of grub-dumpbios in wiki page: http://grub.enbug.org/TestingOnMacbook The commands can be placed there as well. I personally doesn't mind, but perhaps it would be easier for casual user to use a command instead of typing the dd's directly. Hi, It would be useful to have the commands engraved in the wiki, then it won't matter what happens to grub-dumpbios, although it was handy to have it. Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 10:25 PM, Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Forgot the most important question: does it help in any way to generate a suitable dump within grub itself? For the user - yes, it avoids the need to use a pc-bios boot to get the dump. Or if it improves efi loadbios support for some graphics 3d agp drivers, at present this is very limited for apple efi. (works for me with ATI fglrx driver on x86 kernel, but not for nvidia or x86_64). Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub2 compile with Apple's gcc
Hi, patches were applied with grub2 rev 2202, compiles and builds grub.efi in Mac OSX 10.5.6 , i686-apple-darwin9-gcc-4.0.1, with no errors, but fails to run grub.efi. ./configure --with-platform=efi --target=x86_64 ./grub-mkimage -d . -o grubosx.efi appleldr boot cat cmp chain configfile crc date echo ext2 fixvideo fat fs_uuid gpt gptsync halt help hexdump hfs hfsplus iso9660 linux loopback loadbios lspci ls minicmd memrw ntfs pc pci reboot reiserfs read scsi sleep search sh video videotest xfs rEFIt then gives - Starting grubosx.efi and hangs there (i.e. before the Welcome to GRUB). Attempt to compile macho2img.c gave error, but is this needed for x86_64? On Mon, May 11, 2009 at 2:46 AM, Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Hello. With this patch you can compile grub2 using Apple's gcc. Only partially tested. You need objconv available from http://www.agner.org/optimize/ licensed under GPL and additionally patched with attached patch Then you need to patch grub2 with attached patch. If you compile for i386-pcbefore you begin you need to compile execute: gcc -o macho2img util/macho2img.c -Iinclude Then just compile grub2 normally. I will look how to automatise the compilation of macho2img -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub2 compile with Apple's gcc
Also good for cross compile --target=i386, running grub32.efi on MacBook2,1. On Tue, May 12, 2009 at 1:23 PM, Peter Cros pxwp...@gmail.com wrote: All good now, with the addition of grub-mkimage.c prefix workaround and apple2.diff. (grub2 rev2202) (x86_64 grub.efi booting ubuntu904 2.6.28-amd64 on MBP4,1). -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 and fat efi files on latest Apples
Hi,
Thanks for the idea, here fat grub.efi tested ok on imac8,1 (64) and
MacBook2,1 (32), using working grub32.efi and grub64.efi with their
preloaded modules.
./fatglue.py grub2202f.efi grub2202-32.efi grub2202-64.efi
compile and fatglue were all done in OSX10.5.6.
Debian sid 2.6.29.1-amd64 boots for me on imac8,1 using
menuentry sid amd64 fbdev sda9 {
fakebios
root=hd0,9
linux /vmlinuz root=/dev/sda9 video=efifb noefi
initrd /initrd.img
}
On Thu, May 14, 2009 at 1:35 AM, James Jarvis james.jar...@ed.ac.uk wrote:
Newbie post but hopefully I will be providing some useful data rather than
merely questions...
I have been using the svn trunk over the last few days with some success
compiling 32 and 64 bit EFI grub and creating a dual architecture grub.efi
from the results that seems to work on hard disk on newer and older Apple
Intel Macs. I use the fatglue.py python script from refit to make the fat
grub.efi. Not sure if anyone else is doing anything similar...
I have observed that fat modules don't work - need to use grub-mkimage to
insert all the required modules.
Another interesting observation (not really grub but maybe worth comment)
is that using a Linux 2.6.29.2 kernel and initrd on the newer macs in efi
mode boot (uses framebuffer console) works up until the insertion of
modules. It appears that some modules do insert and other don't. The same
kernel and initrd booted in legacy mode (after a call to fakebios) boots
fine.
Finally, the reboot call from linux on the iMac 9,1 hangs - possibly an
issue with fakebios??? If the output of grub-dumpbios is any use let me
know...
Models tested (all intel)
macmini
iMac 4,1 requires ia32 or fat grub.efi
iMac 8,1 requires x86_64 or fat grub.efi
iMac 9,1 requires x86_64 or fat grub.efi
James
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Cros (pxw)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: echo and hello bug
May be of interest - This is the module subset I am using with fat grub efi rev 2202 for 64/32bit efi on Imac81, MacBookPro41, MacBook21. ( ./fatglue.py grub2202fat.efi grub2202-32.efi grub2202-64.efi ) I dont use hello, but echo works. appleldr boot cat cmp chain configfile crc date echo ext2 fixvideo fat fs_uuid gpt gptsync halt help hexdump hfs hfsplus iso9660 linux loopback loadbios lspci ls minicmd memrw ntfs pc pci reboot reiserfs read scsi sleep search sh video videotest xfs. On Mon, Jun 8, 2009 at 11:39 PM, James Jarvis james.jar...@ed.ac.uk wrote: Vladimir 'phcoder' Serbinenko wrote: On Mon, Jun 8, 2009 at 1:34 PM, James Jarvisjames.jar...@ed.ac.uk wrote: I have submitted a bug in to the bugzilla at https://savannah.gnu.org/bugs/?26744 in which hello just hangs. I have tried a few tests around this to see if I can get any output via hello from the command line (from menu pressing C) but I cannot. The problem also occurs if I use echo. Any suggestions on how I might try to fix this (I am happy to test it)? The fact that both hello and echo seem to exhibit the same problem suggests it is not the input as the former is set as a string in the code. What is your build environment? I build on Ubuntu 9.04 SMP x86_64 on the iMac 9,1 I tend to use a fat binary using - the dev is towards a grub image to work on both 32 and 64 bit macs however I have tested just as 64 bit and it has the same error. As the bug report says I compile and build for efi platform. In OSX the efi.tar.gz is unpacked to MacOSX root (hd0,1)/ and bless the (hd0,1)/efi/grub/grub.efi there. Menus work. Appleloader works. I have attached the script I use to build it. James James -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
Hi again, Could the hfspbless patch be updated and hopefully committted to provide the hfspbless module as standard in grub2. It is valuable to enable auto-booting grub.efi installation on Apple Intel Mac efi and also where Mac OSX/refit is not installed. Potentially for automated grub.efi installation on Apple. The old patch has not caught up with subsequent changes to hfsplus.c and requires editing to get it to work. On Sun, Apr 19, 2009 at 4:59 AM, Vladimir Serbinenko phco...@gmail.comwrote: Hello, due to request by ams I wrote this. It's an analog of bless command available under OSX rewritten using grub2 fs functions and according to apple specification of hfs+ on-disk format. This command only update the blessed folder on a partition it doesn't change which drive is used for booting. The later will be a separate command. Also you can choose which volume to boot from by holding option key. Syntax: hfspbless DIRECTORY It works only on HFS+ volumes. Also due to the lack of hardware I wasn't unable to test this in vivo ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting iso image having syslinux
Some comments about live iso booting and grub2 loopback - After grub boots the live iso kernel and initrd, they need to loop mount the iso again to access the live files. Otherwise the initrd would need rebuild, or some way found to pass the loop mount from grub. I have been trying some available live iso's (there are others out there). I am using grub.efi, not using syslinux.. These live isos do loop mount the iso, and run - ununtu, grml, slax. These don't - fedora, debian, gparted. In all cases, grub loopback mounting of the iso and booting the kernel and initrd works. On Fri, Aug 7, 2009 at 9:57 PM, J.Bakshi baksh...@gmail.com wrote: Are you using vga= ? I fixed a bug recently (in SVN) that may cause this behaviour. Then I have to reinstall grub from my sqeeeze box to the usb-stick again to see the effect. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting iso image having syslinux
It could be easier to use the partedmagic live iso, pmagic-4.3.iso, (kernel 2.6.30.1-pmagic), which does loop mount iso with 64 bit grub.efi loopback on Apple mac (It has gparted). On Sat, Aug 8, 2009 at 9:50 PM, J. Bakshi baksh...@gmail.com wrote: On Sat, 8 Aug 2009 12:34:12 +0200 Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: I don't know if it is a coincident but your timing to share these info is directly connected with my problem. I am presently trying to collect some live iso in my usb stick and like to call those by grub2. gparted is one of them. I have in mind to use gparted iso but you have already mentioned that it can't be. Is there any other work around within grub to cope with these type of iso ? It's not a question about grub but about initrd being or not being able to loopmount. Ask gparted live guys to add this feature to their scripts I'll do it. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Creating an (Apple) EFI bootable media
OSX bless works for me with grub.efi in any hfsplus partition using the form bless --folder /xyz --file /xyz/grub/grub.efi (if the file paths are correct - I use GUI and drag the file icon onto a terminal commandline) However it is not always necessary to bless. On Apple Mac, the UEFI spec will boot *.efi without needing to be blessed, and without refit, if it fits the naming convention in the UEFI spec. So a simple bootable package can be built. http://www.uefi.org/specs/ - EFI System Partition Subdirectory Registry UEFI Specification Version 2.3 3.4.1.1 Removable Media Boot Behavior - Table 9. UEFI Image Types If grub.efi is renamed to bootx64.efi or bootia32.efi and placed in fat32 or hfsplus tree /efi/boot, it will then be shown on the restart with Optiion key. However to get an automatic default boot, probably requires the bless form with the --setBoot option. For Apple Mac with 64 bit EFI - p...@im:~/test$ tree efi efi `-- boot |-- bootx64.efi |-- bootx64.icns `-- grub.cfg -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Macbook, Efi, Display mode
There is a grub.efi binary with the double buffering fix and menutest from Bean here on Ubuntuforms.org apple mac subforum thread grub2 EFI boot loader internal/external booting post #1054 http://ubuntuforums.org/showpost.php?p=8034856postcount=1054 On Sun, Oct 4, 2009 at 7:55 AM, Stefan Bienert bien...@zbh.uni-hamburg.dewrote: Hi again, sorry, my git-foo is not that good, can you help me getting into testing the demo from you menu branch? I already cloned a copy of your repo, but I do not know how to get into a particular branch, there. greetings, Stefan Hi, Oh, that could be the double buffer problem, perhaps you can try my latest graphic menu test demo in the menu branch. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
Demo auto scrolling runs OK on apple efi but some comments - Problem with different scaling between Text and Graphic mode on 1920x1200, text loses the bottom 7th widget selection possibility. I seem to expect an initial visible focussed panel indication, instead of having to hit N to see it. Perhaps that is irrelevant at this stage. Posted pictures on ubuntuforms to show Text versus Gfx. On Sun, Oct 4, 2009 at 3:27 PM, Bean bean12...@gmail.com wrote: On Sun, Oct 4, 2009 at 6:34 AM, Michal Suchanek hramr...@centrum.cz wrote: 2009/10/3 Bean bean12...@gmail.com: Hi, Update: Add auto scrolling support, view port would be adjusted automatically to show the current node. In the demo, there are five horizontal widgets, total length exceed that of the screen, using 'N' and 'P' to navigating between anchors, and you can see the hidden widget would scroll into view automatically, ESC to exit the demo. Hello, Do you have an update of the sample configuration for menu test? The old sample reports class not found. Hi, It's at: http://grub4dos.sourceforge.net/menu.zip Download it again and replace the files. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
I find that the 2 terminal configuration with hotkey switch can be very useful alternative in some situations (debugging ...) , particularly on 1920x1200 screen. Single screen popup can be default for normal use. On Wed, Oct 21, 2009 at 6:31 AM, Michal Suchanek hramr...@centrum.czwrote: 2009/10/20 Bean bean12...@gmail.com: menu_prev_anchor, you can assign these to other keys. The demo adds the two terminal example. Inside terminal, direction key and TAB are all used, so you need to assign another hotkey to switch between the two window. The demo uses f6: f6 = menu_next_anchor This is an interesting addition but I'm not sure where this would be used. Normally one terminal is enough so you can just open it fullscreen and close it when you want to do something else. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
I don't know what is the testing status for pc machines, but I have grub-install problem for platform pc on Apple with the current menu source. commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 Author: Bean bean12...@gmail.com Date: Wed Oct 21 01:11:27 2009 +0800 Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get this stopper in grub-install (after successful make make install). OS is ubuntu904 on imac81. p...@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force /dev/sda ./grub-install: 312: realpath: not found ( I got the same back from start of the menu tests with git branch master, the change to realpath problem, then I went to efi tests, no problems). I had no problem --with-platform=pc from the new Bazaar mirror bzr branch http://bzr.savannah.gnu.org/r/grub/ which compiles installs and boots grub-pc with no errors . p...@im:~/src/bzr/trunk$ bzr log -l 1 revno: 1768 committer: fzielcke timestamp: Wed 2009-10-21 12:22:05 + message: 2009-10-21 Felix Zielcke fziel...@z-51.de --- -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
I can use grub-mkrescue to create an El Torito image and burn CD which boots and can run menu. Is that what you mean, or is there a way to boot direct from iso? Thanks On Fri, Oct 23, 2009 at 6:31 PM, Bean bean12...@gmail.com wrote: On Fri, Oct 23, 2009 at 1:59 PM, Peter Cros pxwp...@gmail.com wrote: I don't know what is the testing status for pc machines, but I have grub-install problem for platform pc on Apple with the current menu source. commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 Author: Bean bean12...@gmail.com Date: Wed Oct 21 01:11:27 2009 +0800 Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get this stopper in grub-install (after successful make make install). OS is ubuntu904 on imac81. p...@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force /dev/sda ./grub-install: 312: realpath: not found ( I got the same back from start of the menu tests with git branch master, the change to realpath problem, then I went to efi tests, no problems). I had no problem --with-platform=pc from the new Bazaar mirror bzr branch http://bzr.savannah.gnu.org/r/grub/ which compiles installs and boots grub-pc with no errors . Hi, My menu patch haven't synced with latest svn yet, perhaps it's some bug fixed after my last sync. Anyway, I always create iso image when testing pc mode, so it's possible that there is issue in grub-install and I don't even noticed. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Sat, Oct 24, 2009 at 7:04 PM, Peter Cros pxwp...@gmail.com wrote: I can use grub-mkrescue to create an El Torito image and burn CD which boots and can run menu. Is that what you mean, or is there a way to boot direct from iso? Thanks Nevermind, multiboot /grub.img works, with some bugs in gfx for bios boot on apple. (font missing no text on gfx, textmode is ok). -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Any tutorial to configure grub menu interface ?
That is a very useful doc, a good read. Thanks. On Tue, Nov 3, 2009 at 4:15 AM, Bean Hi, I just write a document on configuration of the new menu system: https://help.ubuntu.com/community/Burg -- Bean My repository: https://launchpad.net/burg ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
