All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] Dynamic device.map
@ 2009-12-07 14:28 Colin Watson
  2009-12-07 17:25 ` Colin Watson
  0 siblings, 1 reply; 20+ messages in thread
From: Colin Watson @ 2009-12-07 14:28 UTC (permalink / raw)
  To: grub-devel

As Robert said recently, we're trying to get rid of our reliance on
device.map. Right now, it is still necessary to at least have entries in
device.map for any disks you wish to use with GRUB, although they don't
have to be particularly sensible; any bidirectional mapping will do (at
least as long as the 'search' command works).

I'd like to make it possible to run with no device.map at all, since
that makes it possible to plug in new disks without having to
reconfigure GRUB. Here's a draft patch to do this. I haven't supplied a
ChangeLog entry yet since it isn't suitable for commit yet, as noted in
TODO comments, but I'd welcome comments on the approach here.

This does slow down (e.g.) grub-probe a little: on my laptop with a
single hard disk, the median time for three runs of './grub-probe
--target=drive /' is 0.09 seconds, while the median time for three runs
of './grub-probe --target=drive -m /boot/grub/device.map.invalid /' is
0.18 seconds. I expect it would be worse on machines with many disks.
For the most part, I doubt this is a significant problem (certainly not
in e.g. grub-setup), but it will probably make a difference in scripts
that call grub-probe many times, such as grub-mkconfig. I suggest that
those should check whether the default device.map exists, and, if not,
send the output of grub-mkdevicemap to a temporary file and use that as
an ephemeral device.map cache.

=== modified file 'conf/any-emu.rmk'
--- conf/any-emu.rmk	2009-11-26 00:08:42 +0000
+++ conf/any-emu.rmk	2009-12-07 13:31:59 +0000
@@ -40,7 +40,7 @@ grub_emu_SOURCES = commands/minicmd.c co
 	fs/befs.c fs/befs_be.c fs/tar.c					\
 	\
 	util/console.c util/hostfs.c util/grub-emu.c util/misc.c	\
-	util/hostdisk.c util/getroot.c					\
+	util/hostdisk.c util/getroot.c util/deviceiter.c		\
 	\
 	disk/raid.c disk/raid5_recover.c disk/raid6_recover.c		\
 	disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c		\

=== modified file 'conf/common.rmk'
--- conf/common.rmk	2009-11-25 23:10:02 +0000
+++ conf/common.rmk	2009-12-07 13:32:14 +0000
@@ -17,6 +17,7 @@ sbin_UTILITIES += grub-probe
 util/grub-probe.c_DEPENDENCIES = grub_probe_init.h
 grub_probe_SOURCES = gnulib/progname.c util/grub-probe.c	\
 	util/hostdisk.c	util/misc.c util/getroot.c		\
+	util/deviceiter.c					\
 	kern/device.c kern/disk.c kern/err.c kern/misc.c	\
 	kern/parser.c kern/partition.c kern/file.c		\
 	\

=== modified file 'conf/i386-pc.rmk'
--- conf/i386-pc.rmk	2009-11-25 23:10:02 +0000
+++ conf/i386-pc.rmk	2009-12-07 13:32:32 +0000
@@ -93,6 +93,7 @@ util/i386/pc/grub-mkimage.c_DEPENDENCIES
 util/i386/pc/grub-setup.c_DEPENDENCIES = grub_setup_init.h
 grub_setup_SOURCES = gnulib/progname.c \
 	util/i386/pc/grub-setup.c util/hostdisk.c	\
+	util/deviceiter.c					\
 	util/misc.c util/getroot.c kern/device.c kern/disk.c	\
 	kern/err.c kern/misc.c kern/parser.c kern/partition.c	\
 	kern/file.c kern/fs.c kern/env.c fs/fshelp.c		\

=== modified file 'conf/sparc64-ieee1275.rmk'
--- conf/sparc64-ieee1275.rmk	2009-12-03 11:18:56 +0000
+++ conf/sparc64-ieee1275.rmk	2009-12-07 13:32:43 +0000
@@ -68,6 +68,7 @@ grub_mkimage_SOURCES = util/sparc64/ieee
 # For grub-setup.
 util/sparc64/ieee1275/grub-setup.c_DEPENDENCIES = grub_setup_init.h
 grub_setup_SOURCES = util/sparc64/ieee1275/grub-setup.c util/hostdisk.c	\
+	util/deviceiter.c					\
 	util/misc.c util/getroot.c kern/device.c kern/disk.c	\
 	kern/err.c kern/misc.c kern/parser.c kern/partition.c	\
 	kern/file.c kern/fs.c kern/env.c fs/fshelp.c		\

=== modified file 'util/hostdisk.c'
--- util/hostdisk.c	2009-11-23 20:30:56 +0000
+++ util/hostdisk.c	2009-12-07 14:14:53 +0000
@@ -23,6 +23,7 @@
 #include <grub/types.h>
 #include <grub/err.h>
 #include <grub/util/misc.h>
+#include <grub/util/deviceiter.h>
 #include <grub/util/hostdisk.h>
 #include <grub/misc.h>
 #include <grub/i18n.h>
@@ -551,6 +552,59 @@ static struct grub_disk_dev grub_util_bi
   };
 
 static void
+make_dynamic_device_map (void)
+{
+  auto int NESTED_FUNC_ATTR process_device (const char *name, int is_floppy);
+
+  int NESTED_FUNC_ATTR process_device (const char *name, int is_floppy)
+  {
+    int num_fd = 0;
+    int num_hd = 0;
+    int drive;
+    struct stat st;
+
+    drive = find_free_slot ();
+    if (drive < 0)
+      grub_util_error ("%s: Map table size exceeded", name);
+
+    /* TODO duplication from read_device_map */
+#ifdef __MINGW32__
+    (void) st;
+    if (grub_util_get_disk_size (name) == -1LL)
+#else
+    if (stat (name, &st) == -1)
+#endif
+      {
+	grub_util_info ("Cannot stat `%s', skipping", name);
+	return 0;
+      }
+
+    /* TODO abstract via something like grub_util_emit_devicemap_entry? */
+    if (is_floppy)
+      asprintf (&map[drive].drive, "fd%d", num_fd++);
+    else
+      asprintf (&map[drive].drive, "hd%d", num_hd++);
+
+    /* TODO duplication from read_device_map */
+#ifdef __linux__
+    /* On Linux, the devfs uses symbolic links horribly, and that
+       confuses the interface very much, so use realpath to expand
+       symbolic links.  */
+    map[drive].device = xmalloc (PATH_MAX);
+    if (! realpath (name, map[drive].device))
+      grub_util_error ("Cannot get the real path of `%s'", name);
+#else
+    map[drive].device = xstrdup (name);
+#endif
+
+    return 0;
+  }
+
+  /* TODO implement --no-floppy properly */
+  grub_util_iterate_devices (process_device, 0);
+}
+
+static void
 read_device_map (const char *dev_map)
 {
   FILE *fp;
@@ -568,6 +622,7 @@ read_device_map (const char *dev_map)
   if (! fp)
     {
       grub_util_info (_("Cannot open `%s'"), dev_map);
+      make_dynamic_device_map ();
       return;
     }
 

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-07 14:28 [RFC] Dynamic device.map Colin Watson
@ 2009-12-07 17:25 ` Colin Watson
  2009-12-09 21:49   ` Robert Millan
  0 siblings, 1 reply; 20+ messages in thread
From: Colin Watson @ 2009-12-07 17:25 UTC (permalink / raw)
  To: grub-devel

On Mon, Dec 07, 2009 at 02:28:06PM +0000, Colin Watson wrote:
> As Robert said recently, we're trying to get rid of our reliance on
> device.map. Right now, it is still necessary to at least have entries in
> device.map for any disks you wish to use with GRUB, although they don't
> have to be particularly sensible; any bidirectional mapping will do (at
> least as long as the 'search' command works).
> 
> I'd like to make it possible to run with no device.map at all, since
> that makes it possible to plug in new disks without having to
> reconfigure GRUB. Here's a draft patch to do this. I haven't supplied a
> ChangeLog entry yet since it isn't suitable for commit yet, as noted in
> TODO comments, but I'd welcome comments on the approach here.

Ah, I hadn't noticed r1870, sorry. Am I right in believing that my patch
is obsolete, then?

-- 
Colin Watson                                       [cjwatson@ubuntu.com]



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-07 17:25 ` Colin Watson
@ 2009-12-09 21:49   ` Robert Millan
  2009-12-09 23:04     ` Colin Watson
  0 siblings, 1 reply; 20+ messages in thread
From: Robert Millan @ 2009-12-09 21:49 UTC (permalink / raw)
  To: The development of GNU GRUB

On Mon, Dec 07, 2009 at 05:25:22PM +0000, Colin Watson wrote:
> On Mon, Dec 07, 2009 at 02:28:06PM +0000, Colin Watson wrote:
> > As Robert said recently, we're trying to get rid of our reliance on
> > device.map. Right now, it is still necessary to at least have entries in
> > device.map for any disks you wish to use with GRUB, although they don't
> > have to be particularly sensible; any bidirectional mapping will do (at
> > least as long as the 'search' command works).
> > 
> > I'd like to make it possible to run with no device.map at all, since
> > that makes it possible to plug in new disks without having to
> > reconfigure GRUB. Here's a draft patch to do this. I haven't supplied a
> > ChangeLog entry yet since it isn't suitable for commit yet, as noted in
> > TODO comments, but I'd welcome comments on the approach here.
> 
> Ah, I hadn't noticed r1870, sorry. Am I right in believing that my patch
> is obsolete, then?

I'm not completely sure, but it seems so.  Sorry about that :-(

Anyhow, if you find more issues with systems that have no device.map, help
is welcome fixing those of course.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-09 21:49   ` Robert Millan
@ 2009-12-09 23:04     ` Colin Watson
  2009-12-10  0:55       ` Robert Millan
  0 siblings, 1 reply; 20+ messages in thread
From: Colin Watson @ 2009-12-09 23:04 UTC (permalink / raw)
  To: The development of GNU GRUB

On Wed, Dec 09, 2009 at 10:49:15PM +0100, Robert Millan wrote:
> On Mon, Dec 07, 2009 at 05:25:22PM +0000, Colin Watson wrote:
> > Ah, I hadn't noticed r1870, sorry. Am I right in believing that my patch
> > is obsolete, then?
> 
> I'm not completely sure, but it seems so.  Sorry about that :-(

Don't apologise for doing something before I got round to it! :-)

> Anyhow, if you find more issues with systems that have no device.map, help
> is welcome fixing those of course.

I'm trying to figure out how to make Debian's grub-installer operate
without a device.map; it has various legacy bits and pieces that need
conversion, and I'm working on these.

Along the way, though, I noticed that grub-install still unconditionally
creates a device.map. This seems likely to become confusing if devices
are changing around a lot, since it's never updated. I'd like to get to
the point where it doesn't do this by default. How about we add support
for an option to disable this, and make grub-installer and the Debian
maintainer scripts pass it once they're ready? Some time later, we can
flip the default value.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-09 23:04     ` Colin Watson
@ 2009-12-10  0:55       ` Robert Millan
  2009-12-10  8:12         ` Colin Watson
  2009-12-10 10:12         ` Felix Zielcke
  0 siblings, 2 replies; 20+ messages in thread
From: Robert Millan @ 2009-12-10  0:55 UTC (permalink / raw)
  To: The development of GNU GRUB

On Wed, Dec 09, 2009 at 11:04:43PM +0000, Colin Watson wrote:
> 
> I'm trying to figure out how to make Debian's grub-installer operate
> without a device.map; it has various legacy bits and pieces that need
> conversion, and I'm working on these.
> 
> Along the way, though, I noticed that grub-install still unconditionally
> creates a device.map. This seems likely to become confusing if devices
> are changing around a lot, since it's never updated. I'd like to get to
> the point where it doesn't do this by default. How about we add support
> for an option to disable this, and make grub-installer and the Debian
> maintainer scripts pass it once they're ready? Some time later, we can
> flip the default value.

Why is this option necessary?  If we removed automated generation of
device.map, user can still call grub-mkdevicemap manually.

But first we'd need to figure out what we do with the "set root=xxx"
backward compatibility hack.  Has it been a while long enough that
we can remove support for GRUB installs that didn't come with UUID
support?

If we don't do anything on grub-mkconfig side and remove device.map, we'll
end up with things like "set root=(/dev/sda1)" which is not just useless
but also utterly confusing.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-10  0:55       ` Robert Millan
@ 2009-12-10  8:12         ` Colin Watson
  2009-12-24 21:18           ` Robert Millan
  2009-12-10 10:12         ` Felix Zielcke
  1 sibling, 1 reply; 20+ messages in thread
From: Colin Watson @ 2009-12-10  8:12 UTC (permalink / raw)
  To: The development of GNU GRUB

On Thu, Dec 10, 2009 at 01:55:27AM +0100, Robert Millan wrote:
> On Wed, Dec 09, 2009 at 11:04:43PM +0000, Colin Watson wrote:
> > I'm trying to figure out how to make Debian's grub-installer operate
> > without a device.map; it has various legacy bits and pieces that need
> > conversion, and I'm working on these.
> > 
> > Along the way, though, I noticed that grub-install still unconditionally
> > creates a device.map. This seems likely to become confusing if devices
> > are changing around a lot, since it's never updated. I'd like to get to
> > the point where it doesn't do this by default. How about we add support
> > for an option to disable this, and make grub-installer and the Debian
> > maintainer scripts pass it once they're ready? Some time later, we can
> > flip the default value.
> 
> Why is this option necessary?  If we removed automated generation of
> device.map, user can still call grub-mkdevicemap manually.

Certainly, but I would like to be able to deliver a system that does not
generate a device.map by default.

> But first we'd need to figure out what we do with the "set root=xxx"
> backward compatibility hack.  Has it been a while long enough that
> we can remove support for GRUB installs that didn't come with UUID
> support?
> 
> If we don't do anything on grub-mkconfig side and remove device.map, we'll
> end up with things like "set root=(/dev/sda1)" which is not just useless
> but also utterly confusing.

No, I don't think we will. grub-probe is perfectly capable of mapping
/dev/sda1 to (hd0,1) even without device.map; it's just that that
mapping will be solely dependent on device iteration order at the time
you run grub-mkconfig. (As opposed to whatever device iteration order
happened to be the first time you installed GRUB, for the
nearly-everyone who never edited device.map by hand ...)

-- 
Colin Watson                                       [cjwatson@ubuntu.com]



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-10  0:55       ` Robert Millan
  2009-12-10  8:12         ` Colin Watson
@ 2009-12-10 10:12         ` Felix Zielcke
  2009-12-24 21:17           ` Robert Millan
  1 sibling, 1 reply; 20+ messages in thread
From: Felix Zielcke @ 2009-12-10 10:12 UTC (permalink / raw)
  To: The development of GNU GRUB

Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan:
> But first we'd need to figure out what we do with the "set root=xxx"
> backward compatibility hack.  Has it been a while long enough that
> we can remove support for GRUB installs that didn't come with UUID
> support? 

Well we still have Arthur Marsh' bug open that search --fs-uuid fails
with right UUID even though ls (hdx,y) shows it.

https://savannah.gnu.org/bugs/?26834
Also on Debian BTS and Launchpad.

The good thing though is that only a grub_errno = GRUB_ERR_NONE; needs
to be commited to have this fixed.
Unfortunately he attached the full kern/device.c to the report not the
patch Vladimir made for him.

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-10 10:12         ` Felix Zielcke
@ 2009-12-24 21:17           ` Robert Millan
  2009-12-25 17:02             ` Felix Zielcke
  0 siblings, 1 reply; 20+ messages in thread
From: Robert Millan @ 2009-12-24 21:17 UTC (permalink / raw)
  To: The development of GNU GRUB

On Thu, Dec 10, 2009 at 11:12:58AM +0100, Felix Zielcke wrote:
> Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan:
> > But first we'd need to figure out what we do with the "set root=xxx"
> > backward compatibility hack.  Has it been a while long enough that
> > we can remove support for GRUB installs that didn't come with UUID
> > support? 
> 
> Well we still have Arthur Marsh' bug open that search --fs-uuid fails
> with right UUID even though ls (hdx,y) shows it.

Uhm ISTR Vladimir fixed this one.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-10  8:12         ` Colin Watson
@ 2009-12-24 21:18           ` Robert Millan
  2009-12-26 13:25             ` Robert Millan
  0 siblings, 1 reply; 20+ messages in thread
From: Robert Millan @ 2009-12-24 21:18 UTC (permalink / raw)
  To: The development of GNU GRUB

On Thu, Dec 10, 2009 at 08:12:52AM +0000, Colin Watson wrote:
> On Thu, Dec 10, 2009 at 01:55:27AM +0100, Robert Millan wrote:
> > On Wed, Dec 09, 2009 at 11:04:43PM +0000, Colin Watson wrote:
> > > I'm trying to figure out how to make Debian's grub-installer operate
> > > without a device.map; it has various legacy bits and pieces that need
> > > conversion, and I'm working on these.
> > > 
> > > Along the way, though, I noticed that grub-install still unconditionally
> > > creates a device.map. This seems likely to become confusing if devices
> > > are changing around a lot, since it's never updated. I'd like to get to
> > > the point where it doesn't do this by default. How about we add support
> > > for an option to disable this, and make grub-installer and the Debian
> > > maintainer scripts pass it once they're ready? Some time later, we can
> > > flip the default value.
> > 
> > Why is this option necessary?  If we removed automated generation of
> > device.map, user can still call grub-mkdevicemap manually.
> 
> Certainly, but I would like to be able to deliver a system that does not
> generate a device.map by default.

We don't need a new option for that.  We'd just not generate device.map at
all, and provide grub-mkdevicemap for users who want to mess with it.

> No, I don't think we will. grub-probe is perfectly capable of mapping
> /dev/sda1 to (hd0,1) even without device.map;

I wasn't very fond of this because it's BIOS-specific.  But I guess we can
live with it.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-24 21:17           ` Robert Millan
@ 2009-12-25 17:02             ` Felix Zielcke
  0 siblings, 0 replies; 20+ messages in thread
From: Felix Zielcke @ 2009-12-25 17:02 UTC (permalink / raw)
  To: The development of GNU GRUB

Am Donnerstag, den 24.12.2009, 22:17 +0100 schrieb Robert Millan:
> On Thu, Dec 10, 2009 at 11:12:58AM +0100, Felix Zielcke wrote:
> > Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan:
> > > But first we'd need to figure out what we do with the "set
> root=xxx"
> > > backward compatibility hack.  Has it been a while long enough that
> > > we can remove support for GRUB installs that didn't come with UUID
> > > support? 
> > 
> > Well we still have Arthur Marsh' bug open that search --fs-uuid
> fails
> > with right UUID even though ls (hdx,y) shows it.
> 
> Uhm ISTR Vladimir fixed this one.

Yes in the meanwhile he commited the fix.

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-24 21:18           ` Robert Millan
@ 2009-12-26 13:25             ` Robert Millan
  2009-12-26 21:37               ` David Miller
  2010-01-06 16:00               ` Colin Watson
  0 siblings, 2 replies; 20+ messages in thread
From: Robert Millan @ 2009-12-26 13:25 UTC (permalink / raw)
  To: The development of GNU GRUB

On Thu, Dec 24, 2009 at 10:18:27PM +0100, Robert Millan wrote:
> > No, I don't think we will. grub-probe is perfectly capable of mapping
> > /dev/sda1 to (hd0,1) even without device.map;
> 
> I wasn't very fond of this because it's BIOS-specific.  But I guess we can
> live with it.

On second thought, I'm really not convinced we need this kind of logic.  It
seems a lot like a workaround.

Just leave it with (/dev/foo).  If you remove device.map generation from
grub-install, you can remove the backward compatibility hack while at it.
Then we rely only on UUIDs.

In the future, we can rely on the initial value of $root as well, but this
would require some rework (disk / partition split).

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-26 13:25             ` Robert Millan
@ 2009-12-26 21:37               ` David Miller
  2009-12-26 22:01                 ` Robert Millan
  2010-01-06 16:00               ` Colin Watson
  1 sibling, 1 reply; 20+ messages in thread
From: David Miller @ 2009-12-26 21:37 UTC (permalink / raw)
  To: grub-devel, rmh

From: Robert Millan <rmh@aybabtu.com>
Date: Sat, 26 Dec 2009 14:25:51 +0100

> Then we rely only on UUIDs.

This is exactly what I suggested we should avoid.

On OpenFirmware we scan every device alias, %80 of them point to
non-existing devices.  The aliases are just an enumeration of
the set of devices that could be behind a controller, not what
has actually been detected by the firmware or anything like
that.

So every scan for a UUID can eat up an enormous amount of time,
poking devices that simply are not there.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-26 21:37               ` David Miller
@ 2009-12-26 22:01                 ` Robert Millan
  0 siblings, 0 replies; 20+ messages in thread
From: Robert Millan @ 2009-12-26 22:01 UTC (permalink / raw)
  To: David Miller; +Cc: grub-devel

On Sat, Dec 26, 2009 at 01:37:14PM -0800, David Miller wrote:
> From: Robert Millan <rmh@aybabtu.com>
> Date: Sat, 26 Dec 2009 14:25:51 +0100
> 
> > Then we rely only on UUIDs.
> 
> This is exactly what I suggested we should avoid.
> 
> On OpenFirmware we scan every device alias, %80 of them point to
> non-existing devices.  The aliases are just an enumeration of
> the set of devices that could be behind a controller, not what
> has actually been detected by the firmware or anything like
> that.
> 
> So every scan for a UUID can eat up an enormous amount of time,
> poking devices that simply are not there.

I understand.  It's not a good idea to use UUIDs exclussively even
outside the context of OpenFirmware.  This is why I also said:

> In the future, we can rely on the initial value of $root as well, but this
> would require some rework (disk / partition split).

I'm fine with delaying removal of devices.map untill this replacement
is ready.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2009-12-26 13:25             ` Robert Millan
  2009-12-26 21:37               ` David Miller
@ 2010-01-06 16:00               ` Colin Watson
  2010-01-07 21:30                 ` Robert Millan
  1 sibling, 1 reply; 20+ messages in thread
From: Colin Watson @ 2010-01-06 16:00 UTC (permalink / raw)
  To: grub-devel

On Sat, Dec 26, 2009 at 02:25:51PM +0100, Robert Millan wrote:
> On Thu, Dec 24, 2009 at 10:18:27PM +0100, Robert Millan wrote:
> > Colin Watson wrote:
> > > No, I don't think we will. grub-probe is perfectly capable of mapping
> > > /dev/sda1 to (hd0,1) even without device.map;
> > 
> > I wasn't very fond of this because it's BIOS-specific.  But I guess we can
> > live with it.
> 
> On second thought, I'm really not convinced we need this kind of logic.  It
> seems a lot like a workaround.
> 
> Just leave it with (/dev/foo).

You mean literally with the parentheses? I don't understand, since /dev/
names will be unintelligible to GRUB when running outside an operating
system.

> If you remove device.map generation from grub-install, you can remove
> the backward compatibility hack while at it.

Which backward compatibility hack?

> In the future, we can rely on the initial value of $root as well, but this
> would require some rework (disk / partition split).

Would you mind elaborating on this? I would like to get this sorted out
and am willing to work on it.

Sorry to be stupid,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2010-01-06 16:00               ` Colin Watson
@ 2010-01-07 21:30                 ` Robert Millan
  2010-01-07 22:18                   ` Bruce Dubbs
  0 siblings, 1 reply; 20+ messages in thread
From: Robert Millan @ 2010-01-07 21:30 UTC (permalink / raw)
  To: The development of GNU GRUB

On Wed, Jan 06, 2010 at 04:00:23PM +0000, Colin Watson wrote:
> > Just leave it with (/dev/foo).
> 
> You mean literally with the parentheses? I don't understand, since /dev/
> names will be unintelligible to GRUB when running outside an operating
> system.

Yes.  This just means we'd have "set root=(/dev/foo)" statements in grub.cfg,
but those are just meant as a backward compatibility hack for pre-UUID GRUB
installs.

Which I guess addresses your next question:

> > If you remove device.map generation from grub-install, you can remove
> > the backward compatibility hack while at it.
> 
> Which backward compatibility hack?

:-)

However, notice that after David Miller's remark about Sparc support, it's
probably better to:

  - Keep the backward compatibility hack.

  - Not remove device.map on Sparc yet (untill a better solution is available)

> > In the future, we can rely on the initial value of $root as well, but this
> > would require some rework (disk / partition split).
> 
> Would you mind elaborating on this? I would like to get this sorted out
> and am willing to work on it.

Uhm actually I'm not completely sure this would work, as multi-disk setups
have multiple values for initial $root.

Better just ignore this part ;-)

> Sorry to be stupid,

Not at all!

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2010-01-07 21:30                 ` Robert Millan
@ 2010-01-07 22:18                   ` Bruce Dubbs
  2010-01-07 22:33                     ` Colin Watson
  0 siblings, 1 reply; 20+ messages in thread
From: Bruce Dubbs @ 2010-01-07 22:18 UTC (permalink / raw)
  To: The development of GNU GRUB

Robert Millan wrote:
> On Wed, Jan 06, 2010 at 04:00:23PM +0000, Colin Watson wrote:
>>> Just leave it with (/dev/foo).
>> You mean literally with the parentheses? I don't understand, since /dev/
>> names will be unintelligible to GRUB when running outside an operating
>> system.
> 
> Yes.  This just means we'd have "set root=(/dev/foo)" statements in grub.cfg,
> but those are just meant as a backward compatibility hack for pre-UUID GRUB
> installs.

Are you are implying that UUID will be the only way?  I don't use 
initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo).
AFAIK initrd is the only way to load with UUIDs.

   -- Bruce



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2010-01-07 22:18                   ` Bruce Dubbs
@ 2010-01-07 22:33                     ` Colin Watson
  2010-01-08  5:27                       ` Bruce Dubbs
  0 siblings, 1 reply; 20+ messages in thread
From: Colin Watson @ 2010-01-07 22:33 UTC (permalink / raw)
  To: grub-devel

On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote:
> Robert Millan wrote:
>> On Wed, Jan 06, 2010 at 04:00:23PM +0000, Colin Watson wrote:
>>>> Just leave it with (/dev/foo).
>>> You mean literally with the parentheses? I don't understand, since /dev/
>>> names will be unintelligible to GRUB when running outside an operating
>>> system.
>>
>> Yes.  This just means we'd have "set root=(/dev/foo)" statements in grub.cfg,
>> but those are just meant as a backward compatibility hack for pre-UUID GRUB
>> installs.
>
> Are you are implying that UUID will be the only way?  I don't use  
> initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo).
> AFAIK initrd is the only way to load with UUIDs.

I think you're mixing up two different things. There are two 'root'
variables involved:

  1) GRUB's 'root' variable, its base for filesystem operations
  2) The root= parameter passed to the Linux kernel, which identifies
     the desired root filesystem

Robert is talking about 1), but whether you use an initrd/initramfs is
only relevant to 2).

-- 
Colin Watson                                       [cjwatson@ubuntu.com]



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2010-01-07 22:33                     ` Colin Watson
@ 2010-01-08  5:27                       ` Bruce Dubbs
  2010-01-08 10:02                         ` Felix Zielcke
  0 siblings, 1 reply; 20+ messages in thread
From: Bruce Dubbs @ 2010-01-08  5:27 UTC (permalink / raw)
  To: The development of GNU GRUB

Colin Watson wrote:
> On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote:
>> Robert Millan wrote:
>>> On Wed, Jan 06, 2010 at 04:00:23PM +0000, Colin Watson wrote:
>>>>> Just leave it with (/dev/foo).
>>>> You mean literally with the parentheses? I don't understand, since /dev/
>>>> names will be unintelligible to GRUB when running outside an operating
>>>> system.
>>> Yes.  This just means we'd have "set root=(/dev/foo)" statements in grub.cfg,
>>> but those are just meant as a backward compatibility hack for pre-UUID GRUB
>>> installs.
>> Are you are implying that UUID will be the only way?  I don't use  
>> initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo).
>> AFAIK initrd is the only way to load with UUIDs.
> 
> I think you're mixing up two different things. There are two 'root'
> variables involved:
> 
>   1) GRUB's 'root' variable, its base for filesystem operations
>   2) The root= parameter passed to the Linux kernel, which identifies
>      the desired root filesystem
> 
> Robert is talking about 1), but whether you use an initrd/initramfs is
> only relevant to 2).

OK, I didn't realize set root was capable of using UUIDs.  I did know 
that the two root entries were different.  I got that mixed up with the 
search command combined with the root=UUID=... which I think needs initrd.

Do I have it right now?

Should 'set root' be renamed to 'set grubroot'?  I think something like 
that would prevent some confusion.

   -- Bruce






^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2010-01-08  5:27                       ` Bruce Dubbs
@ 2010-01-08 10:02                         ` Felix Zielcke
  2010-01-08 16:36                           ` Bruce Dubbs
  0 siblings, 1 reply; 20+ messages in thread
From: Felix Zielcke @ 2010-01-08 10:02 UTC (permalink / raw)
  To: The development of GNU GRUB

Am Donnerstag, den 07.01.2010, 23:27 -0600 schrieb Bruce Dubbs:
> Colin Watson wrote:
> > On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote:
> >> Robert Millan wrote:
> >>> On Wed, Jan 06, 2010 at 04:00:23PM +0000, Colin Watson wrote:
> >>>>> Just leave it with (/dev/foo).
> >>>> You mean literally with the parentheses? I don't understand,
> since /dev/
> >>>> names will be unintelligible to GRUB when running outside an
> operating
> >>>> system.
> >>> Yes.  This just means we'd have "set root=(/dev/foo)" statements
> in grub.cfg,
> >>> but those are just meant as a backward compatibility hack for
> pre-UUID GRUB
> >>> installs.
> >> Are you are implying that UUID will be the only way?  I don't use  
> >> initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo).
> >> AFAIK initrd is the only way to load with UUIDs.
> > 
> > I think you're mixing up two different things. There are two 'root'
> > variables involved:
> > 
> >   1) GRUB's 'root' variable, its base for filesystem operations
> >   2) The root= parameter passed to the Linux kernel, which
> identifies
> >      the desired root filesystem
> > 
> > Robert is talking about 1), but whether you use an initrd/initramfs
> is
> > only relevant to 2).
> 
> OK, I didn't realize set root was capable of using UUIDs.  I did know 
> that the two root entries were different.  I got that mixed up with
> the 
> search command combined with the root=UUID=... which I think needs
> initrd.
> 
> Do I have it right now?

set root only supports plain GRUB devices.
search --set sets $root (for GRUB, not for Linux) to the first device
found with that UUID, LABEL or file. Depending on the other argument to
search command.

> Should 'set root' be renamed to 'set grubroot'?  I think something
> like 
> that would prevent some confusion.
> 
>    -- Bruce

I don't get why there's a confusion at all.
It should be clear that the value specified with the linux command is
for it and not for GRUB.

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [RFC] Dynamic device.map
  2010-01-08 10:02                         ` Felix Zielcke
@ 2010-01-08 16:36                           ` Bruce Dubbs
  0 siblings, 0 replies; 20+ messages in thread
From: Bruce Dubbs @ 2010-01-08 16:36 UTC (permalink / raw)
  To: The development of GNU GRUB

Felix Zielcke wrote:
> Am Donnerstag, den 07.01.2010, 23:27 -0600 schrieb Bruce Dubbs:

>> OK, I didn't realize set root was capable of using UUIDs.  I did know 
>> that the two root entries were different.  I got that mixed up with
>> the 
>> search command combined with the root=UUID=... which I think needs
>> initrd.
>>
>> Do I have it right now?
> 
> set root only supports plain GRUB devices.
> search --set sets $root (for GRUB, not for Linux) to the first device
> found with that UUID, LABEL or file. Depending on the other argument to
> search command.
> 
>> Should 'set root' be renamed to 'set grubroot'?  I think something
>> like that would prevent some confusion.

> I don't get why there's a confusion at all.
> It should be clear that the value specified with the linux command is
> for it and not for GRUB.

It's not confusing if you've been around GRUB for a while, but it is 
confusing for new users.  The term 'root' is overloaded and only 
distinguished by context.  The two contexts do have similar meanings so 
the differences are really fairly subtle.

   -- Bruce




^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2010-01-08 16:36 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-07 14:28 [RFC] Dynamic device.map Colin Watson
2009-12-07 17:25 ` Colin Watson
2009-12-09 21:49   ` Robert Millan
2009-12-09 23:04     ` Colin Watson
2009-12-10  0:55       ` Robert Millan
2009-12-10  8:12         ` Colin Watson
2009-12-24 21:18           ` Robert Millan
2009-12-26 13:25             ` Robert Millan
2009-12-26 21:37               ` David Miller
2009-12-26 22:01                 ` Robert Millan
2010-01-06 16:00               ` Colin Watson
2010-01-07 21:30                 ` Robert Millan
2010-01-07 22:18                   ` Bruce Dubbs
2010-01-07 22:33                     ` Colin Watson
2010-01-08  5:27                       ` Bruce Dubbs
2010-01-08 10:02                         ` Felix Zielcke
2010-01-08 16:36                           ` Bruce Dubbs
2009-12-10 10:12         ` Felix Zielcke
2009-12-24 21:17           ` Robert Millan
2009-12-25 17:02             ` Felix Zielcke

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.