All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Fallback to scanning OF tree if no devaliases
Date: Sun, 01 Aug 2010 16:48:04 +0200	[thread overview]
Message-ID: <4C558924.2040201@gmail.com> (raw)
In-Reply-To: <4C511DF0.3080306@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

As I already told on IRC such a behaviour isn't of a good design. A
simple example is when one add a devalias and then all other disks
disappear. Moreover in experimental branch I have a solution for such a
problem: we scan all the devices and then show only the simpliest form.
That code just needs some testing. Could you do that? I'm sorry for not
having been available for last few days and this resulted in a mountain
of useless work by Doug and Lennart. I assume that the rest of this
thread is a discussion of this issue and is moot given the code which is
already in experimental. If it's not a case please start a new thread
per issue
On 07/29/2010 08:21 AM, Doug Nazar wrote:
>  Lennart, try giving this patch a whirl. In the case after we scan the
> aliases list and we haven't found any block devices it will now try to
> scan the entire tree. It kinda worked under OpenBios although I ran
> into another bug where it can't open a device path that it gave me for
> the pci ide controller. It found the other 2 drives fine.
>
> I think this maintains the correct balance of using short pretty names
> if available but working if they are not available.
>
> There is a case where it will mess up however. If you only specify an
> alias for one device but need another device to build a raid or lvm it
> will fail. Although, thinking about it, this already would happen.
>
> As always, you can specify the either path manually.
>
> Doug
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

  parent reply	other threads:[~2010-08-01 16:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29  6:21 Fallback to scanning OF tree if no devaliases Doug Nazar
2010-07-29 15:36 ` Lennart Sorensen
2010-07-29 15:57   ` Doug Nazar
2010-07-29 16:52     ` David Miller
2010-07-29 16:59       ` Lennart Sorensen
2010-07-29 17:28         ` David Miller
2010-07-29 16:57     ` Lennart Sorensen
2010-07-29 17:08   ` Doug Nazar
2010-07-29 17:37     ` Lennart Sorensen
2010-07-29 19:11       ` Doug Nazar
2010-08-01 14:48 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-08-09 15:41   ` Lennart Sorensen
2010-08-09 16:09     ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-08-09 17:01       ` Lennart Sorensen

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=4C558924.2040201@gmail.com \
    --to=phcoder@gmail.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.