Re: Faulty BIOS or GRUB issue (USB Stick won't boot)
Daniel Mierswa wrote: On 30.09.2009 08:20, Vladimir 'phcoder' Serbinenko wrote: [...] A workaround could be following: losetup /dev/loop0 /dev/sdb1 Why do I need to create a loop device for the first partition? To simulate brain damage of your BIOS grub-install --root-directory=/mnt/usb /dev/loop0 This will give a GRUB error, saying that there's no matching device for /dev/loop0 in my device.map. After removing the device.map and by letting GRUB create it automatically, I get Invalid device `/dev/loop0'. echo '(hd0) /dev/loop0' /boot/grub/device.map Don't forget to apply fezie's bugfix for root-directory Yeah this is already applied since I tried to install it into the primary partition via --root-directory=/mnt/mount /dev/sdb1. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 7:21 AM, Michal Suchanek hramr...@centrum.cz wrote:
It is not. A label can have focus (the whole icon+text widget) but panel
cannot.
It will be impossible to make both focused at once without special trickery.
Hi,
It's possible to make both focused, actually my next demo would be to
illustrate the menu interaction. The basic unit is panel, we can add
input or select property to panel so that it can have input focus
or can be selected, something like this:
panel {
direction = vertical
space = 10/1
input = 1
panel {
direction = horizontal
space = 10/1
command =
image {
image = /menu/ubuntu.png
}
text {
text = Ubuntu
color = yellow:light-green
}
}
panel {
direction = horizontal
space = 10/1
command =
image {
image = /menu/debian.png
}
text {
text = Debian
color = yellow:light-green
}
}
panel {
direction = horizontal
space = 10/1
command =
image {
image = /menu/gentoo.png
}
text {
text = Gentoo
color = yellow:light-green
}
}
}
This sounds good. It gives more flexibility in designing the active items.
There are two level interaction, input is used to indicate window,
Cannot this be inferred automatically?
That is any panel that contains command items is a window.
we use tab key to switch between different window. command is used
to indicate item, each window can have multiple items, we use up or
down key to navigate between items. The command property also contains
the command to execute when the item is clicked.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Faulty BIOS or GRUB issue (USB Stick won't boot)
2009/9/30 Daniel Mierswa impu...@impulze.org: On 30.09.2009 10:26, James Courtier-Dutton wrote: Can you do a fdisk -u -l /dev/sdb But of course. Disk /dev/usb1: 1041 MB, 1041961984 bytes 33 heads, 61 sectors/track, 1010 cylinders, total 2035082 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System From that, you do not appear to have a partition table, therefore you will not have an embedded area at all, and so grub will not install. usb sticks can be formatted in two ways. 1) with a partition sector and partitions like a Hard Disk. (embedded area exists) 2) with no partition sector and no partitions like a Floppy Disk. (no embedded area exists) You will probably have to add partitions to your flash disk so that grub can be installed on it. WARNING: Changing partitions will wipe all the usb stick contents and possibly your Hard Disk contents (if you mistype the device name) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek hramr...@centrum.cz wrote:
Cannot this be inferred automatically?
That is any panel that contains command items is a window.
Hi,
Sometimes panel can be used to ground some widgets together, for
example, a dialog may look like this:
panel
{
direction = vertical
input = 1
panel
{
direction = horizontal
text { text=username}
edit {}
}
panel
{
direction = horizontal
text { text=password}
edit {}
}
}
In this case, the outer panel should be a single window, and the edits
are items. The inner panel is only used for layout, we don't want them
to receive input focus.
--
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
Re: [GITGRUB] New menu interface (implementation)
Hi,
Update:
New properties for the layout manager:
The previous version uses the simplified align and space property, but
this is not enough for complete control, now it goes back to the
previous four property valign, halign, vspace and hspace.
Add extend property, if the children have different width/height, the
menu looks a little awkward. When extend property is set, the
width/height of children is the maximum value.
Add min_width/max_width/min_height/max_height, it's used to limit the
width/height calculated from children widgets. Width/Height set
directly using property is not affected by these.
When some of the margin property are not set, it's position is
controlled by the parent alignment properties, for example, we can
generate a OSX like dock with something like this:
screen {
halign = center
panel {
background = ,,blue,#32:,,green,#32
direction = left_to_right
margin_bottom = 0
hspace = 10/0
vspace = 10/0
image {
image = /menu/ubuntu.png
}
image {
image = /menu/debian.png
}
image {
image = /menu/gentoo.png
}
}
}
As panel only sets margin_bottom, it's x coordination can be set by screen.
Now support four direction: left_to_right, right_to_left,
top_to_bottom and bottom_to_top.
The layout control function is moved from coreui.c to widget.c, now
all container widget would inherit the layout manager automatically.
--
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
Re: [GITGRUB] New menu interface (implementation)
Hi, BTW, I've fixed a small problem as indicated bty pxwpxw from ubuntu forum. Previously to test Colin's patch, I enable double buffer support for EFI, but now it's not needed anymore. The latest menu branch disable double buffer for EFI. The demo should be working on EFI now, I add menu_efi.cfg in the resource file: http://grub4dos.sourceforge.net/menu.zip The following modules should be added when generating grub.efi: coreui loadcfg menutest gfxmenu textmenu -- 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
Re: [GITGRUB] New menu interface (implementation)
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek hramr...@centrum.cz wrote:
Cannot this be inferred automatically?
That is any panel that contains command items is a window.
Hi,
Sometimes panel can be used to ground some widgets together, for
example, a dialog may look like this:
panel
{
direction = vertical
input = 1
panel
{
direction = horizontal
text { text=username}
edit {}
}
panel
{
direction = horizontal
text { text=password}
edit {}
}
}
In this case, the outer panel should be a single window, and the edits
are items. The inner panel is only used for layout, we don't want them
to receive input focus.
Since the panel only contains one active item ( the edit ) this should
still work.
I recall writing about this here already.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Faulty BIOS or GRUB issue (USB Stick won't boot)
On 01.10.2009 10:49, James Courtier-Dutton wrote: From that, you do not appear to have a partition table, therefore you will not have an embedded area at all, and so grub will not install. I'm sorry to cause confusion like that, but I erased the partition table (and the MBR for that matter) to show you how the BIOS detects the stick geometry. usb sticks can be formatted in two ways. 1) with a partition sector and partitions like a Hard Disk. (embedded area exists) 2) with no partition sector and no partitions like a Floppy Disk. (no embedded area exists) Yes, the layout which was tried looks like the below (1), I did not give (2) a shot yet, since this would force me to have a disk layout that seems utterly pointless for this matter (I think). Disk /dev/usb: 1042 MB, 1042284544 bytes 33 heads, 61 sectors/track, 1011 cylinders Units = cylinders of 2013 * 512 = 1030656 bytes Disk identifier: 0x7867a96c Device Boot Start End Blocks Id System /dev/usb1 * 11011 1017541 83 Linux Sorry again for the confusion. phcoder might be on to something though, please also see his recent mail in this thread. -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Faulty BIOS or GRUB issue (USB Stick won't boot)
On 01.10.2009 10:22, Vladimir 'phcoder' Serbinenko wrote: To simulate brain damage of your BIOS *shrug* I wonder how you can manage to simulate _that_ severe damage. echo '(hd0) /dev/loop0' /boot/grub/device.map D'oh, didn't think of hardcoding it, I thought GRUB detects it properly. However, phcoder, there were some crackheads back in January taking some time with that matter and I tried almost every hack discussed on the net. And out of nothing comes you, applying yet another hack and it just seems to work. You're a true hero. :D However when doing ls (hd0) in the GRUB rescue shell that fires up, I'm getting Partition table. I guess this is part of the hack? Is it possible to apply this workaround in the codebase so that others with that broken BIOS (remember I have another MBR file of a guy who reported identical behaviour) or is this something that should be left to people with broken BIOS? All in all, thank you very much, now that I have a rescue shell, I can start playing. -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek hramr...@centrum.cz wrote:
Cannot this be inferred automatically?
That is any panel that contains command items is a window.
Hi,
Sometimes panel can be used to ground some widgets together, for
example, a dialog may look like this:
panel
{
direction = vertical
input = 1
panel
{
direction = horizontal
text { text=username}
edit {}
}
panel
{
direction = horizontal
text { text=password}
edit {}
}
}
In this case, the outer panel should be a single window, and the edits
are items. The inner panel is only used for layout, we don't want them
to receive input focus.
Since the panel only contains one active item ( the edit ) this should
still work.
I recall writing about this here already.
Hi,
It'd be ok if we only have one level input items, but I plans to add
two two level interaction, first is window, second is item, TAB switch
different window, while UP/DOWN switch different items. In this setup,
we need to mark the panel that acted as window.
--
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
Re: [GITGRUB] New menu interface (implementation)
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek hramr...@centrum.cz wrote:
Cannot this be inferred automatically?
That is any panel that contains command items is a window.
Hi,
Sometimes panel can be used to ground some widgets together, for
example, a dialog may look like this:
panel
{
ádirection = vertical
áinput = 1
ápanel
á{
á ádirection = horizontal
á átext { text=username}
á áedit {}
á}
ápanel
á{
á ádirection = horizontal
á átext { text=password}
á áedit {}
á}
}
In this case, the outer panel should be a single window, and the edits
are items. The inner panel is only used for layout, we don't want them
to receive input focus.
Since the panel only contains one active item ( the edit ) this should
still work.
I recall writing about this here already.
Hi,
It'd be ok if we only have one level input items, but I plans to add
two two level interaction, first is window, second is item, TAB switch
different window, while UP/DOWN switch different items. In this setup,
we need to mark the panel that acted as window.
Yes, there's no problem inferring the interaction from the widget tree.
Widgets that don't do anything don't get focus, they are ignored for
purpose of determining focus.
An active item like edit or panel with command is an atomic widget for
focus. A panel that contains exactly one atomic widget is also atomic.
A panel that contains multiple atomic items (or alternatively in which
atomic item is focused) acts on directional keys by switching focus to
next item - this seems what window = 1 does.
A panel that contains multiple panels that can focus but are not
atomic handles (Shift +)TAB by switching to the (previous) next
contained panel. In case the focused panel is its (first) last
focusable item it passes the key to the upper panel.
As an extension the panel direction can be taken into account, and
panels can be seen as atomic in both directions (atomic) atomic in
vertical direction (horizontal panel containing atomic widgets), ...
This can work completely automagically without user setup and thus can
eliminate errors in the setup.
It perhaps might be useful to override the default in some cases but
this should work for any menu I would want to put together.
Thanks
Michal
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Creating an (Apple) EFI bootable media
Hello Is there a way to reproducibly create Grub bootable media (CD, USB stick) that can be used with Apple efi? I tried some ways of blessing the boot loader which I found on the net but none works. Also the default core image probably lacks some essential parts. I managed to load it as rEFIt shell command by placing it in the tools directory but it complained about prefix not being defined and I seemingly had no commands - the help command was not available, and pressing tab did not show anything. For some reason I cannot boot rEFIt from external media either but I can bless rEIFt on the built-in HDD. I don't know what the Apple bless commnad is supposed to do so I have no idea if whatever it did was correct. I suspect different arguments than those advised on the various web pages are needed when blessing a boot loader on an external medium (as opposed to the root volume). Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Thu, Oct 1, 2009 at 10:53 PM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 8:44 PM, Michal Suchanek hramr...@centrum.cz wrote:
2009/10/1 Bean bean12...@gmail.com:
On Thu, Oct 1, 2009 at 4:41 PM, Michal Suchanek hramr...@centrum.cz
wrote:
Cannot this be inferred automatically?
That is any panel that contains command items is a window.
Hi,
Sometimes panel can be used to ground some widgets together, for
example, a dialog may look like this:
panel
{
ádirection = vertical
áinput = 1
ápanel
á{
á ádirection = horizontal
á átext { text=username}
á áedit {}
á}
ápanel
á{
á ádirection = horizontal
á átext { text=password}
á áedit {}
á}
}
In this case, the outer panel should be a single window, and the edits
are items. The inner panel is only used for layout, we don't want them
to receive input focus.
Since the panel only contains one active item ( the edit ) this should
still work.
I recall writing about this here already.
Hi,
It'd be ok if we only have one level input items, but I plans to add
two two level interaction, first is window, second is item, TAB switch
different window, while UP/DOWN switch different items. In this setup,
we need to mark the panel that acted as window.
Yes, there's no problem inferring the interaction from the widget tree.
Widgets that don't do anything don't get focus, they are ignored for
purpose of determining focus.
An active item like edit or panel with command is an atomic widget for
focus. A panel that contains exactly one atomic widget is also atomic.
A panel that contains multiple atomic items (or alternatively in which
atomic item is focused) acts on directional keys by switching focus to
next item - this seems what window = 1 does.
A panel that contains multiple panels that can focus but are not
atomic handles (Shift +)TAB by switching to the (previous) next
contained panel. In case the focused panel is its (first) last
focusable item it passes the key to the upper panel.
As an extension the panel direction can be taken into account, and
panels can be seen as atomic in both directions (atomic) atomic in
vertical direction (horizontal panel containing atomic widgets), ...
This can work completely automagically without user setup and thus can
eliminate errors in the setup.
It perhaps might be useful to override the default in some cases but
this should work for any menu I would want to put together.
Hi,
The window = 1 is used to group some input items together, for example:
screen {
panel { # A
window = 1
panel { } #A1
panel { } #A2
}
panel { # B
window = 1
panel { } #B1
panel { } #B2
}
}
This define two menus, each with two items. Each menu remember its
current selection, for example, if panel A select a language, panel B
select theme, both can have current selection at the same time. You
can walk from A to B as they represent two different things.
--
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
Re: [PATCH] Create environment block safely
On Wed, Sep 30, 2009 at 11:54:30PM +0100, Colin Watson wrote: If grub-editenv create is interrupted, it's theoretically possible for it to create an incomplete block that future grub-editenv calls won't recognise. It would be better for it to atomically create either a complete block or nothing. Any objections? 2009-09-30 Colin Watson cjwat...@ubuntu.com * util/grub-editenv.c (create_envblk_file): Write new block with a .new suffix and then rename it into place, to ensure atomic creation. I've gone ahead and committed this, since it's straightforward enough. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Creating an (Apple) EFI bootable media
2009/10/1 Bean bean12...@gmail.com: On Thu, Oct 1, 2009 at 11:17 PM, Michal Suchanek hramr...@centrum.cz wrote: Hello Is there a way to reproducibly create Grub bootable media (CD, USB stick) that can be used with Apple efi? I tried some ways of blessing the boot loader which I found on the net but none works. Hi, You should format it as GPT, MBR may not work. The fs of choice is hfsplus, although I heard someone have successful boot with FAT. To bless the disk, use something like this: (only available for hfsplus) sudo bless --folder=/Volumes/USBDISK --file=/Volumes/USBDISK/efi/grub/grub.efi That's what I use and what can be found on varoius forums and wikis. It works neither with rEFIt nor grub for me. Perhaps I am not using the = character, I should check that but bless does not report any error and it actually changes the information (there is another bless option to show the state). bless writes the location of boot file to the hfsplus header. bless doesn't work on FAT. At startup, you need to press the Option key to show startup disk, and select the usb disk. The disk does not show in the options offered by the firmware. The following command writes the boot device to nvram so that it's used by default: sudo bless --folder=/Volumes/USBDISK --file=/Volumes/USBDISK/efi/grub/grub.efi --setBoot As I understand it this is not required for hfsplus, only for fat which cannot be blessed permanently. It makes no difference either way. Also the default core image probably lacks some essential parts. I managed to load it as rEFIt shell command by placing it in the tools directory but it complained about prefix not being defined and I seemingly had no commands - the help command was not available, and pressing tab did not show anything. You can add the command to the generated EFI image with grub-mkimage, here are the list of modules I usually use: ./grub-mkimage -d . -o grub64.efi minicmd part_gpt part_msdos part_apple fat ext2 hfsplus hfs ntfs reiserfs xfs iso9660 udf ls search loopback linux chain reboot halt appleldr help configfile hexdump loadbios memrw fixvideo crc sh video efi_fb gfxterm font png coreui loadcfg menutest gfxmenu textmenu Hmm, I'm probably missing the shell or something. Can't the installation pre-create an efi image that contains most options? AFAIK the size of the image is not of much concern on efi so creating a mostly complete image would simplify things. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Creating an (Apple) EFI bootable media
On Fri, Oct 2, 2009 at 2:29 AM, Michal Suchanek hramr...@centrum.cz wrote: 2009/10/1 Bean bean12...@gmail.com: On Thu, Oct 1, 2009 at 11:17 PM, Michal Suchanek hramr...@centrum.cz wrote: Hello Is there a way to reproducibly create Grub bootable media (CD, USB stick) that can be used with Apple efi? I tried some ways of blessing the boot loader which I found on the net but none works. Hi, You should format it as GPT, MBR may not work. The fs of choice is hfsplus, although I heard someone have successful boot with FAT. To bless the disk, use something like this: (only available for hfsplus) sudo bless --folder=/Volumes/USBDISK --file=/Volumes/USBDISK/efi/grub/grub.efi That's what I use and what can be found on varoius forums and wikis. It works neither with rEFIt nor grub for me. Perhaps I am not using the = character, I should check that but bless does not report any error and it actually changes the information (there is another bless option to show the state). bless writes the location of boot file to the hfsplus header. bless doesn't work on FAT. At startup, you need to press the Option key to show startup disk, and select the usb disk. The disk does not show in the options offered by the firmware. Hi, Oh, perhaps some model doesn't support the usb boot method. The following command writes the boot device to nvram so that it's used by default: sudo bless --folder=/Volumes/USBDISK --file=/Volumes/USBDISK/efi/grub/grub.efi --setBoot As I understand it this is not required for hfsplus, only for fat which cannot be blessed permanently. It makes no difference either way. Each partition has a default boot file, but the default boot device is stored in the nvram. --setBoot sets this value. This is the same as selecting the boot device from Startup Disk. Although if firmware can't boot from usb, setting this would have any effects. Also the default core image probably lacks some essential parts. I managed to load it as rEFIt shell command by placing it in the tools directory but it complained about prefix not being defined and I seemingly had no commands - the help command was not available, and pressing tab did not show anything. You can add the command to the generated EFI image with grub-mkimage, here are the list of modules I usually use: ./grub-mkimage -d . -o grub64.efi minicmd part_gpt part_msdos part_apple fat ext2 hfsplus hfs ntfs reiserfs xfs iso9660 udf ls search loopback linux chain reboot halt appleldr help configfile hexdump loadbios memrw fixvideo crc sh video efi_fb gfxterm font png coreui loadcfg menutest gfxmenu textmenu Hmm, I'm probably missing the shell or something. Can't the installation pre-create an efi image that contains most options? AFAIK the size of the image is not of much concern on efi so creating a mostly complete image would simplify things. The above list contain most of the things I need, although you can use *.mod to include all modules, but I think some have unresolved symbol issue and you can get an error. -- 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
grub_prefix seems wrong for separate /boot partition
Hello Not sure if I've come to the right place, but here is my story: Yesterday, my package manager (deb on testing) decided that the time has come to switch to grub 1.97~beta3. Well, afterwards my system did not boot anymore, it was stuck in the grub shell, no menu or anything. It works again now and I quiet like the new grub shell (well, scrolling was horribly slow). Anyway, my /boot-directory is on its own partition, which is only mounted if I need to change something there. Now, one of the problems why the update did not work was that I forgot to mount /boot and grub could not find the kernels (my fault). After I've learned how to boot my system again and mounted /boot, grub found the kernels. However, grub_prefix seems to be wrong, pointing to /boot/grub instead of just /grub. I did not find a better way to fix it than changing the variable in grub-install. After changing grub_prefix to /grub and rerunning grub-install /dev/hda, everything is fine now. Maybe grub_prefix should be setable on the command line of grub-install? Or some other bad mistake on my part because of scoping the amount of documentation I read using google? Christoph ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Create environment block safely
On Wed, Sep 30, 2009 at 5:54 PM, Colin Watson cjwat...@ubuntu.com wrote: If grub-editenv create is interrupted, it's theoretically possible for it to create an incomplete block that future grub-editenv calls won't recognise. It would be better for it to atomically create either a complete block or nothing. Any objections? Be aware that this may lose security settings. Write-in-place is also different wrt hard links, but it would be pretty odd for that file to have additional hard links. You might also need to check for the alternate name, in case the operation failed after writing the new content and unlinking the old file, but before renaming the new file. ___ 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
