All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Edwards <grante@visi.com>
To: grub-devel@gnu.org
Subject: Re: Boot delay when using grub.efi on Mac Mini
Date: Wed, 11 Mar 2009 22:48:54 +0000 (UTC)	[thread overview]
Message-ID: <gp9f4m$f30$2@ger.gmane.org> (raw)
In-Reply-To: 49B83321.9070006@gmail.com

On 2009-03-11, phcoder <phcoder@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            




  reply	other threads:[~2009-03-11 22:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-10 23:36 Boot delay when using grub.efi on Mac Mini Grant Edwards
2009-03-10 23:48 ` Grant Edwards
2009-03-11  1:58   ` Peter Cros
2009-03-11  2:54     ` Grant Edwards
2009-03-11 15:06     ` Grant Edwards
2009-03-11 15:15       ` phcoder
2009-03-11 21:43         ` Grant Edwards
2009-03-11 21:54           ` phcoder
2009-03-11 22:48             ` Grant Edwards [this message]
2009-03-11 22:12       ` Grant Edwards
2009-03-11 22:41         ` Grant Edwards
2009-03-11 22:42           ` phcoder
2009-03-11 22:51             ` Grant Edwards
2009-03-12  2:17               ` Peter Cros
2009-03-12 14:37                 ` Grant Edwards
2009-03-13 10:59                   ` Peter Cros
2009-03-13 14:26                     ` Grant Edwards
2009-03-13 15:39                       ` phcoder
2009-03-13 16:19                         ` Grant Edwards
2009-03-13 17:20                           ` phcoder
2009-03-14  1:56                             ` Peter Cros
2009-03-14  5:57                       ` Peter Cros
2009-03-14 15:07                         ` Grant Edwards
2009-03-21 21:30                         ` Grant Edwards
2009-03-22  3:56                           ` Peter Cros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='gp9f4m$f30$2@ger.gmane.org' \
    --to=grante@visi.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.