All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Next release?
Date: Tue, 15 Jul 2008 19:52:15 -0400	[thread overview]
Message-ID: <1216165935.9604.26.camel@dv> (raw)
In-Reply-To: <200807160132.18470.okuji@enbug.org>

On Wed, 2008-07-16 at 01:32 +0200, Yoshinori K. Okuji wrote:

> If a boot drive is the same as a root drive, you are right. Otherwise we need 
> to do so.
>
> I think we have seen tons of examples with GRUB Legacy which may not be solved 
> automatically in all cases. If one digs into the archive of bug-grub, I guess 
> several cases would be found easily. With GRUB 2, we can avoid embedding BIOS 
> drive numbers in many cases, using UUIDs or labels or files. But this does 
> not always work, so I am afraid that we need to support device.map, even if 
> it is an evil necessity.

That's a very advanced setup.  I actually cannot imagine why anyone
would use different boot and root drives.  Well, maybe the boot drive
has no partitions that GRUB or the host OS can access?  It's getting
less likely these days.  Or maybe the boot drive is too small for GRUB?
Anything bigger than a 360K floppy should be able to hold all GRUB
modules.  Or maybe the boot drive is too slow?  It's hard for me to
imagine a system that has hard drives but boots only from a floppy.

And let's not forget that dual drive installs are twice as prone to
failure.  Either drive failure makes the system unbootable.

Now, suppose that we still want to support dual drive installs.  We
should make sure is that it doesn't happen by accident.  Then it's a
fair game to ask the user for an extra option to enable a 
dual drive install, and that option could be the drive number.

Dual drive installs are also highly unportable, which means that UUIDs,
labels and file search should be sufficient in most cases.

-- 
Regards,
Pavel Roskin



  reply	other threads:[~2008-07-15 23:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-14 13:03 Next release? Pavel Roskin
2008-07-14 16:55 ` Christian Franke
2008-07-14 20:27   ` Pavel Roskin
2008-07-15  5:40     ` Christian Franke
2008-07-20 21:10     ` Christian Franke
2008-07-15 13:49   ` Robert Millan
2008-07-15 15:07     ` Patrick Georgi
2008-07-15 18:39       ` Christian Franke
2008-07-15 18:32     ` Christian Franke
2008-07-15 21:04 ` Yoshinori K. Okuji
2008-07-15 22:31   ` Pavel Roskin
2008-07-15 23:15     ` Yoshinori K. Okuji
2008-07-15 23:21       ` Pavel Roskin
2008-07-15 23:32         ` Yoshinori K. Okuji
2008-07-15 23:52           ` Pavel Roskin [this message]
2008-07-16 14:11             ` Colin D Bennett
2008-07-16 14:17               ` Javier Martín
2008-07-16 16:17                 ` Pavel Roskin
2008-07-16 16:28                   ` Javier Martín
2008-07-16 16:08               ` Pavel Roskin
2008-07-19 15:14                 ` device.map (Re: Next release?) Robert Millan
2008-07-21 21:26                   ` Pavel Roskin
2008-07-22 21:36                     ` Robert Millan
2008-07-22 21:57                       ` Pavel Roskin
2008-07-22 22:08                         ` Robert Millan
2008-07-22 22:46                           ` Pavel Roskin
2008-07-19 15:06           ` Next release? Robert Millan
2008-07-19 20:16             ` Yoshinori K. Okuji
2008-07-19 20:59               ` Robert Millan
2008-07-21 20:48               ` Pavel Roskin
2008-07-22 21:37                 ` Robert Millan
2008-07-22 22:01                   ` Pavel Roskin
2008-07-22 22:09                     ` Robert Millan
2008-07-22 22:41                       ` Pavel Roskin
2008-07-24 17:02 ` Marco Gerards
2008-07-24 17:18   ` Pavel Roskin
2008-07-24 21:47     ` Christian Franke
  -- strict thread matches above, loose matches on Subject: below --
2008-07-16  0:22 chaac

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=1216165935.9604.26.camel@dv \
    --to=proski@gnu.org \
    --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.