From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Next release?
Date: Sat, 19 Jul 2008 22:16:23 +0200 [thread overview]
Message-ID: <200807192216.23882.okuji@enbug.org> (raw)
In-Reply-To: <20080719150624.GD23778@thorin>
On Saturday 19 July 2008 17:06:24 Robert Millan wrote:
> On Wed, Jul 16, 2008 at 01:32:18AM +0200, Yoshinori K. Okuji wrote:
> > On Wednesday 16 July 2008 01:21:57 Pavel Roskin wrote:
> > > On Wed, 2008-07-16 at 01:15 +0200, Yoshinori K. Okuji wrote:
> > > > OK. Then how do you install GRUB into (hd1) in a development machine,
> > > > which is (hd0) in a booting machine? When GRUB may not correctly
> > > > determine BIOS drives, do you want to just give up?
> > >
> > > The boot drive can be determined at boot.
> > >
> > > Granted, there are buggy BIOSes, but we handle it already. All we need
> > > is to encode into the bootloader that it was installed on a hard drive
> > > (actually, not on a floppy, real or emulated), and the bootloader would
> > > use 0x80 rather than the value from BIOS.
> > >
> > > We don't need specific drive numbers like 0x81. We need one bit of
> > > information, and we can figure it out at the install time.
> >
> > 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.
>
> Which cases are there that can't be fixed by using UUIDs?
In any case where UUIDs are not used.
I am totally against ripping off device.map. Pavel's idea is too idealistic,
and that regresses the flexibility.
Regards,
Okuji
next prev parent reply other threads:[~2008-07-19 20:16 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
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 [this message]
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=200807192216.23882.okuji@enbug.org \
--to=okuji@enbug.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.