Re: Boot delay when using grub.efi on Mac Mini
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
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: Boot delay when using grub.efi on Mac Mini
On 2009-03-14, Peter Cros pxwp...@gmail.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 - That's good to know. I guess I should have tried it rather assuming as true the posts about requiring a GPT partition. Of course that may be something tha varies by model or by firmware revision. --setBoot gives deafult fast boot to grub menu, but when booted that way, grub can only see its own disk (hd0) That's OK for what I'm doing. 2) MiniMyth kernel lacks support for EFI/GPT parition tables and SATA hard drives. The list of drivers for minimyth seems to include those used for sata on my macs, but you may have better info. I should have qualified my statement -- it doesn't include the AHCI SATA driver required for recent Mac Minis. -- Grant ___ 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
On 2009-03-13, Peter Cros pxwp...@gmail.com wrote: A brief read of the mininmyth docs suggests it can also run on a fat partition on the gpt hard disk. No, the minimyth kernel doesn't support EFT/GPT partitioned disks. It also doesn't support SATA hard drives. Currently, it doesn't even know the hard-drive is there. If it did, it wouldn't know what to do with it. 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. Right, but the MiniMyth kenel can only handle msdos parition tables, and Macs will only boot from GPT partioned disks. 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. Thanks. You need to read the Mac OSX bless manual closely to compare the options, and experiment. I've read that man page dozens of times. It's pretty vague. One thing that's confusing it talks a lot about the volume -- always in the singular. I can't figure out to what volume refers such that there is never more than one in a system. 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. At this point, there aren't any grub development issues. Grub works fine. The current issues are caused by: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. 2) MiniMyth kernel lacks support for EFI/GPT parition tables and SATA hard drives. I'm going to try rebuilding MiniMyth with GPT support so that I can GPT partition a USB flash drive in hopes of getting the Mac to boot from it. I'm also going to try adding AHCI SATA controller support to MiniMyth so that I can spin down the hard-drive. 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. That's sort of heading the wrong direction. My goal is not to have to touch the Mac hard-drive at all. So far, that's not been possible, but I'm getting closer. -- Grant Edwards grante Yow! We just joined the at civil hair patrol! 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
Have you tried booting from hfs+ on msdos? Grant Edwards wrote: On 2009-03-13, Peter Cros pxwp...@gmail.com wrote: A brief read of the mininmyth docs suggests it can also run on a fat partition on the gpt hard disk. No, the minimyth kernel doesn't support EFT/GPT partitioned disks. It also doesn't support SATA hard drives. Currently, it doesn't even know the hard-drive is there. If it did, it wouldn't know what to do with it. 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. Right, but the MiniMyth kenel can only handle msdos parition tables, and Macs will only boot from GPT partioned disks. 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. Thanks. You need to read the Mac OSX bless manual closely to compare the options, and experiment. I've read that man page dozens of times. It's pretty vague. One thing that's confusing it talks a lot about the volume -- always in the singular. I can't figure out to what volume refers such that there is never more than one in a system. 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. At this point, there aren't any grub development issues. Grub works fine. The current issues are caused by: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. 2) MiniMyth kernel lacks support for EFI/GPT parition tables and SATA hard drives. I'm going to try rebuilding MiniMyth with GPT support so that I can GPT partition a USB flash drive in hopes of getting the Mac to boot from it. I'm also going to try adding AHCI SATA controller support to MiniMyth so that I can spin down the hard-drive. 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. That's sort of heading the wrong direction. My goal is not to have to touch the Mac hard-drive at all. So far, that's not been possible, but I'm getting closer. -- 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-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. -- Grant Edwards grante Yow! Vote for ME -- I'm at well-tapered, half-cocked, visi.comill-conceived and TAX-DEFERRED! ___ 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
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
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
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
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: 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: 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
Boot delay when using grub.efi on Mac Mini
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.
I had previously attempted to use elilo (an old binary I
downloaded from somewhere), but it didn't seem to be able to
load the initrd correctly.
There do seem to be two problems -- I don't think either of
them are grub's fault, but I thought I ask just in case
somebody has seen either one before:
1) I blessed grub.efi using this command adapted from the Wiki page:
bash-3.2# bless --mount=/efi --verbose --file=/efi/grub/grub.efi
--setBoot
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 0x109320 [0xa08891a0]{type = mutable, count = 3,
capacity = 3, pairs = (
0 : CFString 0x18db0 [0xa08891a0]{contents = Auxiliary
Partitions} = CFArray 0x103a80 [0xa08891a0]{type = immutable, count = 0,
values = (
)}
2 : CFString 0x18da0 [0xa08891a0]{contents = Data
Partitions} = CFArray 0x109770 [0xa08891a0]{type = immutable, count = 1,
values = (
0 : CFString 0x109750 [0xa08891a0]{contents = disk0s1}
)}
3 : CFString 0x18dc0 [0xa08891a0]{contents = System
Partitions} = CFArray 0x104ff0 [0xa08891a0]{type = immutable, count = 1,
values = (
0 : CFString 0x109670 [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.
Now the machine boots into grub, but there's about a 30
second delay between the chime and when grub starts (it
was the same for elilo). If I have a USB flash drive
plugged in, I see the activity LED flash once every 2
seconds or so until grub starts.
If I hold down the option key on startup, there is no
delay and I immediately get the screen where I click on a
button underneath a picture of a hard-drive to boot.
Any ideas on how to eliminate the 30s delay?
2) With the linux kernel command line option video=vesafb, I
get a working console, framebuffer graphics don't work.
Without that option, I don't get a working console. It's
not a grub problem, but any pointers will be appreciated.
--
Grant Edwards grante Yow! Wow! Look!! A stray
at meatball!! Let's interview
visi.comit!
___
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-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
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
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) I'll try it. Why does one Wiki page say to use folder mode, and the other to use mount mode? Some more tests done at ubuntuforums.org http://ubuntuforums.org/showthread.php?t=995704 I've already spent quite a bit of time reading that thread. If there is any useful info in there, the odds of stumbling across it are awfully remote. There are 371 posts over about 1-1/2 years, and I've never been able to get the search facility to do anything at all useful. -- Grant ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
