Re: [Bugfix] Characters disappearing in gfxterm
Vesa Jääskeläinen wrote: phcoder wrote: Hello. I've run into the bug that when editing menu entry in gfxterm characters disappear after cursor moves away from its position. Here is bugfix I don't think this is a clean fix: Index: term/gfxterm.c === --- term/gfxterm.c (revision 1974) +++ term/gfxterm.c (working copy) @@ -744,6 +744,8 @@ /* Render cursor to text layer. */ grub_video_set_active_render_target (text_layer); grub_video_fill_rect (color, x, y, width, height); + if (! show) +write_char (); grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY); /* Mark cursor to be redrawn. */ It is not designed to work in there. I think modifying this needs logical level approach and not ad hoc fix. = Has there been any further work done on the disappearing characters in gfxterm? I know you guys had looked at it, but the last word was it was not fixed yet. I understand it's not a priority, but a fix would help in me getting the devs for Zenwalk to approve it's use in the next release version. Also, do you intend to release another stable version soon? As I watch the progress of Grub2, I continue to see a good program get even better, so using svn is fine for me! You've added so much since the 1.96 release though, it just seems another stable release is past due. Continue the great work you're doing though, as good software never truly gets finished! Thanks, Pat -- ---Zenwalk v6.0--Linux 2.6.28--- Registered Linux User #225206 Ever tried Zen computing? http://www.zenwalk.org ___ 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 2009-03-11, Peter Cros pxwp...@gmail.com wrote: Hi, Try the other instructions for MacBook http://grub.enbug.org/TestingOnMacbook ( recentlu updated ) including bless --folder --file --setBoot (not --mount) When I do that, it still goes through 15 of the 2-second time-wasting operations, then it boots directly into OS-X. I was under the impression that the --folder version only worked if grub was installed in the default HFS filesystem. Changing back to the --mount version of the bless command results in the same 30-second delay, but at least it loads grub.efi. -- Grant Edwards grante Yow! LBJ, LBJ, how many at JOKES did you tell today??! visi.com ___ 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
Grant Edwards wrote: On 2009-03-11, Peter Cros pxwp...@gmail.com wrote: Hi, Try the other instructions for MacBook http://grub.enbug.org/TestingOnMacbook ( recentlu updated ) including bless --folder --file --setBoot (not --mount) When I do that, it still goes through 15 of the 2-second time-wasting operations, then it boots directly into OS-X. I was under the impression that the --folder version only worked if grub was installed in the default HFS filesystem. Changing back to the --mount version of the bless command results in the same 30-second delay, but at least it loads grub.efi. Can you post bless -info Volume and nvram -p in different cases? -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] badram filtering
Hello. I'm now writing the code to make multiboot and bsd work on EFI based on my grub_machine_memory_iterate for EFI. MY code will be the same for all i386 branches. It's quite complete except that I had no time yet to test it. I'l submit once it works I was thinking and found another utility for badram: BIOS hooks. They are actually allocating take some memory and then removing it from mmap. If bios mmap hook and kernels get their mmap from the same source we can ensure that bios hooks won't be overwritten by the kernel independently how it acquired memory map. So I think badram patch should be extended to allow arbitrary additions to mmap. P.S. sorry if this e-mail isn't clear enough I've just had a long day of studies phcoder wrote: 2) when badram variable is set corresponding memory chunks should be removed from memory manager 3) add a method to specify badram in init.c so that grub2 itself has no risk of using any of this memory. I propose to embed initial environment in core.img. Then prefix and root can be changed to use this mechanism. It would also be able to override this initial environment through multiboot command line when grub2 is loaded by multiboot loader Robert Millan wrote: Hi, This patch implements badram filtering in GRUB. It's the same idea as in http://rick.vanrein.org/linux/badram/ but applied to GRUB. The badram module sits between loaders (or other users like lsmmap) and filters the mmap entries, but only when user previously set the badram variable (whose syntax is the same as the one in badram patch for Linux). NOTE this won't affect loadees that get the memory map from BIOS instead of from GRUB. This means it currently works for Multiboot and for the new/experimental Linux loader. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Bugfix] Hang on new mac laptops
Hello this issue still persists and unfortunately usb keyboard didn't fix the issue. Perhaps we should commit this as at least temporary solution for the problem? phcoder wrote: Fixed Pavel Roskin wrote: On Tue, 2009-02-03 at 22:30 +0100, phcoder wrote: - status = efi_call_3 (b-wait_for_event, 1, (i-wait_for_key), index); + /* status = efi_call_3 (b-wait_for_event, 1, (i-wait_for_key), index); if (status != GRUB_EFI_SUCCESS) -return -1; +return -1;*/ + grub_millisleep (10); Please don't leave commented out code. If you want a comment to be there, you can write something. If you want to preserve the file history, Subversion does it already. -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Use hfs case ordering - another try
On Mon, Mar 09, 2009 at 01:37:14PM -0400, Pavel Roskin wrote: Hello! It's a shame the discussion about hfs got nowhere. I've made another patch. I didn't look at the Linux hfs sources or at any previous patches. I took the case ordering table from hfsutils 3.2.6, which is licensed under GPL v2 or newer. Then I ran the table through a simple program to make it more readable (attached for reference). The values in the table have been normalized to avoid gaps. Values for equal characters are initialized on the same line for readability. ChangeLog: * fs/hfs.c (grub_hfs_strncasecmp): New function. (grub_hfs_cmp_catkeys): Use HFS specific string comparison. Seems good to me. Thanks Pavel. -- 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
Re: [Bugfix] Characters disappearing in gfxterm
On Wed, Mar 11, 2009 at 10:36:40AM -0400, BandiPat wrote: Has there been any further work done on the disappearing characters in gfxterm? I know you guys had looked at it, but the last word was it was not fixed yet. I understand it's not a priority, but a fix would help in me getting the devs for Zenwalk to approve it's use in the next release version. Also, do you intend to release another stable version soon? As I watch the progress of Grub2, I continue to see a good program get even better, so using svn is fine for me! You've added so much since the 1.96 release though, it just seems another stable release is past due. Continue the great work you're doing though, as good software never truly gets finished! Perhaps you could help by doing a regression check and telling us which commit introduced this problem? (there's a svn-bisect program in subversion-tools you can use) -- 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
Re: ELF bugfixes
On Mon, Mar 02, 2009 at 01:35:06AM +0100, phcoder wrote:
+ * include/grub/elf.h: added missing attributes
This should be a bit more descriptive.
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ if (lowest_segment == -1
+ || phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
Why?
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_paddr;
Are you sure about this? IIRC e_entry is in the virtual address space. I
think we had some trouble with this (with NetBSD?), which lead to the current
use of p_vaddr in this line.
--
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
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-11, phcoder phco...@gmail.com wrote:
http://grub.enbug.org/TestingOnMacbook ( recentlu updated )
including bless --folder --file --setBoot
(not --mount)
When I do that, it still goes through 15 of the 2-second
time-wasting operations, then it boots directly into OS-X.
[...]
Can you post bless -info Volume and nvram -p in different cases?
I wasn't sure what Volume meant. I included output for both
/efi (the mountpoint for the FAT32 filesystems where grub.efi
is located), and for /Volumes.
Here you go...
+ bless --folder=/efi/grub --file=/efi/grub/grub.efi --setBoot --verbose
EFI found at IODeviceTree:/efi
Mount point for /efi/grub is /efi
Common mount point of '/efi/grub' and '' is /efi
No BootX creation requested
No boot.efi creation requested
GPT detected
Booter partition required at index 2
System partition found
Returning booter information dictionary:
CFDictionary 0x109310 [0xa08891a0]{type = mutable, count = 3, capacity = 3,
pairs = (
0 : CFString 0x18db0 [0xa08891a0]{contents = Auxiliary Partitions}
= CFArray 0x103a70 [0xa08891a0]{type = immutable, count = 0, values = (
)}
2 : CFString 0x18da0 [0xa08891a0]{contents = Data Partitions} =
CFArray 0x109760 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109740 [0xa08891a0]{contents = disk0s1}
)}
3 : CFString 0x18dc0 [0xa08891a0]{contents = System Partitions} =
CFArray 0x104fe0 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109660 [0xa08891a0]{contents = disk0s1}
)}
)}
Path to mountpoint given: /efi
IOMedia disk0s1 has UUID CD08BC7E-4A45-4814-A27A-7FA6D02A2F3A
Setting EFI NVRAM:
efi-boot-device='arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dict/array'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-file'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-mkext'
NVRAM variable boot-args not set.
+ bless --info /efi
+ bless --info /Volumes
finderinfo[0]:116 = Blessed System Folder is /System/Library/CoreServices
finderinfo[1]: 524200 = 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]:116 = OS X blessed folder is /System/Library/CoreServices
64-bit VSDB volume id: 0x21144BD3838779F5
+ nvram -p
SystemAudioVolume s
efi-boot-device-data
%02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%02%00%00%00%00%00%04%01*%00%01%00%00%00(%00%00%00%00%00%00%00...@%06%00%00%00%00%00~%bc%08%cdej%14h%a2z%7f%a6%d0*/:%02%02%7f%ff%04%00
platform-uuid %00%00%00%00%00%00%10%00%80%00%00%1f%f3FC%d0
efi-boot-device
arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dict/array
+ bless --mount=/efi --file=/efi/grub/grub.efi --setBoot --verbose
EFI found at IODeviceTree:/efi
Mount point for /efi is /efi
Mount point is '/efi'
No BootX creation requested
No boot.efi creation requested
GPT detected
Booter partition required at index 2
System partition found
Returning booter information dictionary:
CFDictionary 0x109310 [0xa08891a0]{type = mutable, count = 3, capacity = 3,
pairs = (
0 : CFString 0x18db0 [0xa08891a0]{contents = Auxiliary Partitions}
= CFArray 0x103a70 [0xa08891a0]{type = immutable, count = 0, values = (
)}
2 : CFString 0x18da0 [0xa08891a0]{contents = Data Partitions} =
CFArray 0x109760 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109740 [0xa08891a0]{contents = disk0s1}
)}
3 : CFString 0x18dc0 [0xa08891a0]{contents = System Partitions} =
CFArray 0x104fe0 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109660 [0xa08891a0]{contents = disk0s1}
)}
)}
Relative path of /efi/grub/grub.efi is \grub\grub.efi
IOMedia disk0s1 has UUID CD08BC7E-4A45-4814-A27A-7FA6D02A2F3A
Setting EFI NVRAM:
efi-boot-device='arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dictdictkeyIOEFIDevicePathType/keystringMediaFilePath/stringkeyPath/keystring\grub\grub.efi/string/dict/array'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-file'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-mkext'
NVRAM variable boot-args not set.
+ bless --info /efi
+ bless --info /Volumes
finderinfo[0]:116 = Blessed System Folder is /System/Library/CoreServices
finderinfo[1]: 524200 = Blessed System File is
/System/Library/CoreServices/boot.efi
finderinfo[2]: 0 = Open-folder
Re: Boot delay when using grub.efi on Mac Mini
Looks like for some reason your bless command tries to announce efi
partition by uuid. I'm not sure where this uuid comes from, perhaps it's
uuid from gpt but I would suspect that EFI has troubles finding your
partition because of this try:
1) you could bless manually by writing corresponding data to nvram
2) you could try on HFS+
Grant Edwards wrote:
On 2009-03-11, phcoder phco...@gmail.com wrote:
http://grub.enbug.org/TestingOnMacbook ( recentlu updated )
including bless --folder --file --setBoot
(not --mount)
When I do that, it still goes through 15 of the 2-second
time-wasting operations, then it boots directly into OS-X.
[...]
Can you post bless -info Volume and nvram -p in different cases?
I wasn't sure what Volume meant. I included output for both
/efi (the mountpoint for the FAT32 filesystems where grub.efi
is located), and for /Volumes.
Here you go...
+ bless --folder=/efi/grub --file=/efi/grub/grub.efi --setBoot --verbose
EFI found at IODeviceTree:/efi
Mount point for /efi/grub is /efi
Common mount point of '/efi/grub' and '' is /efi
No BootX creation requested
No boot.efi creation requested
GPT detected
Booter partition required at index 2
System partition found
Returning booter information dictionary:
CFDictionary 0x109310 [0xa08891a0]{type = mutable, count = 3, capacity = 3,
pairs = (
0 : CFString 0x18db0 [0xa08891a0]{contents = Auxiliary Partitions} =
CFArray 0x103a70 [0xa08891a0]{type = immutable, count = 0, values = (
)}
2 : CFString 0x18da0 [0xa08891a0]{contents = Data Partitions} =
CFArray 0x109760 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109740 [0xa08891a0]{contents = disk0s1}
)}
3 : CFString 0x18dc0 [0xa08891a0]{contents = System Partitions} =
CFArray 0x104fe0 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109660 [0xa08891a0]{contents = disk0s1}
)}
)}
Path to mountpoint given: /efi
IOMedia disk0s1 has UUID CD08BC7E-4A45-4814-A27A-7FA6D02A2F3A
Setting EFI NVRAM:
efi-boot-device='arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dict/array'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-file'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-mkext'
NVRAM variable boot-args not set.
+ bless --info /efi
+ bless --info /Volumes
finderinfo[0]:116 = Blessed System Folder is /System/Library/CoreServices
finderinfo[1]: 524200 = 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]:116 = OS X blessed folder is /System/Library/CoreServices
64-bit VSDB volume id: 0x21144BD3838779F5
+ nvram -p
SystemAudioVolume s
efi-boot-device-data
%02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%02%00%00%00%00%00%04%01*%00%01%00%00%00(%00%00%00%00%00%00%00...@%06%00%00%00%00%00~%bc%08%cdej%14h%a2z%7f%a6%d0*/:%02%02%7f%ff%04%00
platform-uuid %00%00%00%00%00%00%10%00%80%00%00%1f%f3FC%d0
efi-boot-device
arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dict/array
+ bless --mount=/efi --file=/efi/grub/grub.efi --setBoot --verbose
EFI found at IODeviceTree:/efi
Mount point for /efi is /efi
Mount point is '/efi'
No BootX creation requested
No boot.efi creation requested
GPT detected
Booter partition required at index 2
System partition found
Returning booter information dictionary:
CFDictionary 0x109310 [0xa08891a0]{type = mutable, count = 3, capacity = 3,
pairs = (
0 : CFString 0x18db0 [0xa08891a0]{contents = Auxiliary Partitions} =
CFArray 0x103a70 [0xa08891a0]{type = immutable, count = 0, values = (
)}
2 : CFString 0x18da0 [0xa08891a0]{contents = Data Partitions} =
CFArray 0x109760 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109740 [0xa08891a0]{contents = disk0s1}
)}
3 : CFString 0x18dc0 [0xa08891a0]{contents = System Partitions} =
CFArray 0x104fe0 [0xa08891a0]{type = immutable, count = 1, values = (
0 : CFString 0x109660 [0xa08891a0]{contents = disk0s1}
)}
)}
Relative path of /efi/grub/grub.efi is \grub\grub.efi
IOMedia disk0s1 has UUID CD08BC7E-4A45-4814-A27A-7FA6D02A2F3A
Setting EFI NVRAM:
efi-boot-device='arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dictdictkeyIOEFIDevicePathType/keystringMediaFilePath/stringkeyPath/keystring\grub\grub.efi/string/dict/array'
Setting EFI NVRAM:
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-11, Grant Edwards gra...@visi.com wrote: On 2009-03-11, Peter Cros pxwp...@gmail.com wrote: Hi, Try the other instructions for MacBook http://grub.enbug.org/TestingOnMacbook ( recentlu updated ) including bless --folder --file --setBoot (not --mount) When I do that, it still goes through 15 of the 2-second time-wasting operations, then it boots directly into OS-X. I was under the impression that the --folder version only worked if grub was installed in the default HFS filesystem. Changing back to the --mount version of the bless command results in the same 30-second delay, but at least it loads grub.efi. Moving grub from the EFI FAT32 partition to the HFS+ partition eliminates the 30-second delay. In this case the status looks like this: bash-3.2# bless -info /Volumes finderinfo[0]: 660564 = Blessed System Folder is /Users/grante/grub finderinfo[1]: 660651 = Blessed System File is /Users/grante/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]: 660564 = OS X blessed folder is /Users/grante/grub 64-bit VSDB volume id: 0x21144BD3838779F5 bash-3.2# nvram -p SystemAudioVolume s efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%02%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00`%b8f%09%00%00%00%00w%9b?%8b%d0%b7...@%8fo%c7-%0d%eb%0d%02%02%7f%ff%04%00 platform-uuid %00%00%00%00%00%00%10%00%80%00%00%1f%f3FC%d0 efi-boot-device arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystring8B3F9B77-B7D0-4000-8F6F-C72D0DEB3E0D/string/dict/dictkeyBLLastBSDName/keystringdisk0s2/string/dict/array%00 -- Grant Edwards grante Yow! Should I get locked at in the PRINCICAL'S visi.comOFFICE today -- or have a VASECTOMY?? ___ 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 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. -- Grant Edwards grante Yow! With YOU, I can be at MYSELF ... We don't NEED visi.comDan Rather ... ___ 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
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 -- Regards Vladimir 'phcoder' Serbinenko ___ 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 2009-03-11, phcoder phco...@gmail.com wrote: Looks like for some reason your bless command tries to announce efi partition by uuid. I'm not sure where this uuid comes from, perhaps it's uuid from gpt but I would suspect that EFI has troubles finding your partition because of this try: 1) you could bless manually by writing corresponding data to nvram 2) you could try on HFS+ I may try using bless --device to see if that works any differently. What seems particular weird to me is that after doing 15 tries of something, the firmware does find grub.efi and starts it just fine. It's like it _finds_ it, but isn't particularly happy about it. So, it goes off an tries something else 15 times. When that doesn't work, it goes ahead and boots grub.efi. I've checked, and it's not sending any network packets during that 30 seconds. Something via the network is the only thing I can think of that would be worth re-trying. I can't figure out what it might be trying that a) is failing, and b) somebody thought might succeed if it was just re-tried another 14 times over a period of 30 seconds. If a particular sector on a disk or a file doesn't contain what you're looking for, reading it 14 more times isn't going to help... :/ -- Grant Edwards grante Yow! The Korean War must at have been fun. visi.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Search command.
On Wed, 2009-03-11 at 00:04 -0400, Pavel Roskin wrote:
On Wed, 2009-03-11 at 13:34 +1300, Centurion Computer Technology (2005)
Ltd wrote:
Hi,
I am playing with the search command in grub2 from debian experimental
and have noticed some oddness
The search command currently returns the device as hdX,X rather than
(hdX,X). This means that the variable created using -s can't be used as
a replacement for the device string.
Actually, you can assign it to the root variable and use relative path.
You don't need parentheses in the root variable.
For Example I'd like to be able to
do this:
# Set our root device
search -f /grub/grub.cfg -s root
# Set our prefix
set prefix=${root}/grub/ # I think broken variable handling means this
doesn't work.
True. Variable expansion is broken. But you can use
set prefix=/grub/
but this means as soon as root is set to the new device, that we can't
load anymore modules which breaks chainloader, linux, intrd, boot etc
and it appears preloading boot doesn't work anyway, as it tries to find
it. This problem doesn't occur if I manually set prefix=(hdX,X)/grub
That would allow you to load more modules as long as $root is
unchanged.
menuentry My Linux OS {
search -s LINUX_ROOT -u ----
set root=$LINUX_ROOT
This is broken for the same reason. But this would work:
search -s root -u ----
Nope, as above, because we cannot set Prefix to include the device
programmatically, as soon as you've changed your root, you can no longer
load modules or use commands.
--
Daniel Reurich
Centurion Computer Technology (2005) Limited.
Ph: 021 797 722
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Search command.
On Thu, 2009-03-12 at 12:52 +1300, Centurion Computer Technology (2005)
Ltd wrote:
On Wed, 2009-03-11 at 00:04 -0400, Pavel Roskin wrote:
On Wed, 2009-03-11 at 13:34 +1300, Centurion Computer Technology (2005)
Ltd wrote:
Hi,
I am playing with the search command in grub2 from debian experimental
and have noticed some oddness
The search command currently returns the device as hdX,X rather than
(hdX,X). This means that the variable created using -s can't be used as
a replacement for the device string.
Actually, you can assign it to the root variable and use relative path.
You don't need parentheses in the root variable.
For Example I'd like to be able to
do this:
# Set our root device
search -f /grub/grub.cfg -s root
# Set our prefix
set prefix=${root}/grub/ # I think broken variable handling means this
doesn't work.
True. Variable expansion is broken. But you can use
set prefix=/grub/
but this means as soon as root is set to the new device, that we can't
load anymore modules which breaks chainloader, linux, intrd, boot etc
and it appears preloading boot doesn't work anyway, as it tries to find
it. This problem doesn't occur if I manually set prefix=(hdX,X)/grub
That would allow you to load more modules as long as $root is
unchanged.
menuentry My Linux OS {
search -s LINUX_ROOT -u ----
set root=$LINUX_ROOT
This is broken for the same reason. But this would work:
search -s root -u ----
Nope, as above, because we cannot set Prefix to include the device
programmatically, as soon as you've changed your root, you can no longer
load modules or use commands.
An easy fix would be for search to return the device with parentheses
This would solve most of the problems, and allow for:
search -s OSdevice -u ----
chainloader ${OSdevice}+1
--
Daniel Reurich
Centurion Computer Technology (2005) Limited.
Ph: 021 797 722
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Search command.
Centurion Computer Technology (2005) Ltd wrote:
On Thu, 2009-03-12 at 12:52 +1300, Centurion Computer Technology (2005)
Ltd wrote:
On Wed, 2009-03-11 at 00:04 -0400, Pavel Roskin wrote:
On Wed, 2009-03-11 at 13:34 +1300, Centurion Computer Technology (2005)
Ltd wrote:
Hi,
I am playing with the search command in grub2 from debian experimental
and have noticed some oddness
The search command currently returns the device as hdX,X rather than
(hdX,X). This means that the variable created using -s can't be used as
a replacement for the device string.
Actually, you can assign it to the root variable and use relative path.
You don't need parentheses in the root variable.
For Example I'd like to be able to
do this:
# Set our root device
search -f /grub/grub.cfg -s root
# Set our prefix
set prefix=${root}/grub/ # I think broken variable handling means this
doesn't work.
True. Variable expansion is broken. But you can use
set prefix=/grub/
but this means as soon as root is set to the new device, that we can't
load anymore modules which breaks chainloader, linux, intrd, boot etc
and it appears preloading boot doesn't work anyway, as it tries to find
it. This problem doesn't occur if I manually set prefix=(hdX,X)/grub
That would allow you to load more modules as long as $root is
unchanged.
menuentry My Linux OS {
search -s LINUX_ROOT -u ----
set root=$LINUX_ROOT
This is broken for the same reason. But this would work:
search -s root -u ----
Nope, as above, because we cannot set Prefix to include the device
programmatically, as soon as you've changed your root, you can no longer
load modules or use commands.
An easy fix would be for search to return the device with parentheses
This would solve most of the problems, and allow for:
search -s OSdevice -u ----
chainloader ${OSdevice}+1
search -s OSdevice -u ----
chainloader (${OSdevice})+1
--
Regards
Vladimir 'phcoder' Serbinenko
___
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: Search command.
An easy fix would be for search to return the device with parentheses
This would solve most of the problems, and allow for:
search -s OSdevice -u ----
chainloader ${OSdevice}+1
search -s OSdevice -u ----
chainloader (${OSdevice})+1
It doesn't currently do parameter expansion so it parses as far as the
( and stops
--
Daniel Reurich
Centurion Computer Technology (2005) Limited.
Ph: 021 797 722
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Search command.
Quoting Centurion Computer Technology (2005) Ltd dan...@centurion.net.nz: Nope, as above, because we cannot set Prefix to include the device programmatically, as soon as you've changed your root, you can no longer load modules or use commands. You can preload all the modules you need with insmod in the common section. Then you don't need to worry about the prefix anymore. The memory will be freed once the OS starts loading. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
