[PATCH] Scan root device dynamically at startup

[PATCH] Scan root device dynamically at startup

[Bean]

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

Hi,

For normal boot, the root device is passed to core.img in preloader.
However, if we load grub2 using linux header, there is no way to know
the root device. This patch add a new module findroot that can be used
to scan the root directory at startup.

One important usage is to create a grub2 boot file for vista boot loader:

mkimage -o g2ntfs.img pc ntfs biosdisk findroot
cat lnxboot.img g2ntfs.img > g2ntfs.mbr

The result g2ntfs.mbr is within 32K, which can be loaded by vista in
one pass, no need to use the g2ldr.mbr anymore. The findroot modules
ensure that prefix is set properly before switching to normal mode.

If findroot is not used to create core.img, the original booting method remains.

-- 
Bean

[-- Attachment #2: findroot.diff --]
[-- Type: text/plain, Size: 3867 bytes --]

diff --git a/conf/i386-pc.rmk b/conf/i386-pc.rmk
index 37a9f5b..89ad861 100644
--- a/conf/i386-pc.rmk
+++ b/conf/i386-pc.rmk
@@ -155,7 +155,7 @@ pkglib_MODULES = biosdisk.mod _chain.mod _linux.mod linux.mod normal.mod \
 	vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
 	videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod	\
 	ata.mod vga.mod memdisk.mod jpeg.mod png.mod pci.mod lspci.mod \
-	aout.mod _bsd.mod bsd.mod
+	aout.mod _bsd.mod bsd.mod findroot.mod
 
 # For biosdisk.mod.
 biosdisk_mod_SOURCES = disk/i386/pc/biosdisk.c
@@ -322,4 +322,9 @@ bsd_mod_SOURCES = loader/i386/bsd_normal.c
 bsd_mod_CFLAGS = $(COMMON_CFLAGS)
 bsd_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For findroot.mod.
+findroot_mod_SOURCES = kern/findroot.c
+findroot_mod_CFLAGS = $(COMMON_CFLAGS)
+findroot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 include $(srcdir)/conf/common.mk
diff --git a/include/grub/i386/pc/kernel.h b/include/grub/i386/pc/kernel.h
index 43a8d5b..c35b8d4 100644
--- a/include/grub/i386/pc/kernel.h
+++ b/include/grub/i386/pc/kernel.h
@@ -68,7 +68,7 @@ extern grub_int32_t grub_memdisk_image_size;
 
 /* The prefix which points to the directory where GRUB modules and its
    configuration file are located.  */
-extern char grub_prefix[];
+extern char EXPORT_VAR(grub_prefix) [];
 
 /* The boot BIOS drive number.  */
 extern grub_int32_t EXPORT_VAR(grub_boot_drive);
diff --git a/kern/findroot.c b/kern/findroot.c
new file mode 100755
index 0000000..6a6cc69
--- /dev/null
+++ b/kern/findroot.c
@@ -0,0 +1,77 @@
+/* findroot.c - search for root device */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/types.h>
+#include <grub/misc.h>
+#include <grub/mm.h>
+#include <grub/err.h>
+#include <grub/dl.h>
+#include <grub/device.h>
+#include <grub/file.h>
+#include <grub/env.h>
+#include <grub/machine/kernel.h>
+
+#define KERNEL_FILE	"/normal.mod"
+
+static void
+find_root (void)
+{
+  char *buf = 0;
+  auto int iterate_device (const char *name);
+
+  int iterate_device (const char *name)
+    {
+      grub_size_t len;
+      char *p;
+      grub_file_t file;
+
+      len = grub_strlen (name) + 2 + grub_strlen (grub_prefix) +
+            sizeof (KERNEL_FILE);
+
+      p = grub_realloc (buf, len);
+      if (! p)
+	return 1;
+
+      buf = p;
+      grub_sprintf (buf, "(%s)%s" KERNEL_FILE, name, grub_prefix);
+
+      file = grub_file_open (buf);
+      if (file)
+	{
+          buf[grub_strlen (name) + 2 + grub_strlen (grub_prefix)] = 0;
+          grub_env_set ("prefix", buf);
+
+          grub_file_close (file);
+
+          return 1;
+	}
+
+      grub_errno = GRUB_ERR_NONE;
+      return 0;
+    }
+
+  grub_device_iterate (iterate_device);
+
+  grub_free (buf);
+}
+
+GRUB_MOD_INIT(findroot)
+{
+  find_root ();
+}
diff --git a/kern/main.c b/kern/main.c
index 09de03a..a7e1e4f 100644
--- a/kern/main.c
+++ b/kern/main.c
@@ -124,7 +124,9 @@ grub_main (void)
 
   /* It is better to set the root device as soon as possible,
      for convenience.  */
-  grub_machine_set_prefix ();
+  if (! grub_env_get ("prefix"))
+    grub_machine_set_prefix ();
+
   grub_set_root_dev ();
 
   /* Load the normal mode module.  */

Re: [PATCH] Scan root device dynamically at startup

[Robert Millan]

On Tue, May 20, 2008 at 06:22:25PM +0800, Bean wrote:
> Hi,
> 
> For normal boot, the root device is passed to core.img in preloader.
> However, if we load grub2 using linux header, there is no way to know
> the root device. This patch add a new module findroot that can be used
> to scan the root directory at startup.
> 
> One important usage is to create a grub2 boot file for vista boot loader:
> 
> mkimage -o g2ntfs.img pc ntfs biosdisk findroot
> cat lnxboot.img g2ntfs.img > g2ntfs.mbr
> 
> The result g2ntfs.mbr is within 32K, which can be loaded by vista in
> one pass, no need to use the g2ldr.mbr anymore. The findroot modules
> ensure that prefix is set properly before switching to normal mode.
> 
> If findroot is not used to create core.img, the original booting method remains.

The module is called findroot, but it initialises $prefix rather than $root.
Shouldn't it be findprefix or so?

Also, what this module is doing looks very similar to "search --set".  Did
you check if search command can be used for what you want?  (or otherwise
adapted)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Scan root device dynamically at startup

[Bean]

On Wed, May 28, 2008 at 9:54 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, May 20, 2008 at 06:22:25PM +0800, Bean wrote:
>> Hi,
>>
>> For normal boot, the root device is passed to core.img in preloader.
>> However, if we load grub2 using linux header, there is no way to know
>> the root device. This patch add a new module findroot that can be used
>> to scan the root directory at startup.
>>
>> One important usage is to create a grub2 boot file for vista boot loader:
>>
>> mkimage -o g2ntfs.img pc ntfs biosdisk findroot
>> cat lnxboot.img g2ntfs.img > g2ntfs.mbr
>>
>> The result g2ntfs.mbr is within 32K, which can be loaded by vista in
>> one pass, no need to use the g2ldr.mbr anymore. The findroot modules
>> ensure that prefix is set properly before switching to normal mode.
>>
>> If findroot is not used to create core.img, the original booting method remains.
>
> The module is called findroot, but it initialises $prefix rather than $root.
> Shouldn't it be findprefix or so?
>

In function grub_set_root_dev (main.c), it uses prefix to calculated
root, so setting prefix is sufficient.

About the name, well, findprefix works for me too.

> Also, what this module is doing looks very similar to "search --set".  Did
> you check if search command can be used for what you want?  (or otherwise
> adapted)

The findroot module is used to locate normal.mod. But search is a
command, it can only be used after normal.mod has been loaded.

-- 
Bean

Re: [PATCH] Scan root device dynamically at startup

[Robert Millan]

On Wed, May 28, 2008 at 10:53:07PM +0800, Bean wrote:
> 
> In function grub_set_root_dev (main.c), it uses prefix to calculated
> root, so setting prefix is sufficient.
> 
> About the name, well, findprefix works for me too.
> 
> > Also, what this module is doing looks very similar to "search --set".  Did
> > you check if search command can be used for what you want?  (or otherwise
> > adapted)
> 
> The findroot module is used to locate normal.mod. But search is a
> command, it can only be used after normal.mod has been loaded.

I've been thinking a bit more about this, and my impression is that it the
approach is quite ad-hoc.  For example, some similar problems that this
solution wouldn't solve, but that a very similar solution would:

 a- normal.mod was built into grub.elf (perhaps because the firmware can load
    big files).  Then the problem is finding grub.cfg instead of normal.mod.

 b- User has a disk liing around which happens to have a normal.mod from
    an earlier version of grub (let's assume different ABI).  Turns out this
    disk is used for something else and can't be supressed.  A solution could
    be to use UUIDs for the search, but that can't always work since we need
    a "smart" install process that can probe for them (unlike in the situation
    you described -- I can't imagine doing fancy stuff in bare-bones Vista).

 c- Search for normal.mod was ok, but then this particular port of grub can't
    accept the prefix variable from your module, because it already got this
    variable from the firmware (OFW does this).  And the variable from firmware
    happens to be completely unusable.

I think a solution that would fit well here is to use memdisk to embed a
grub.cfg.  Then in each situation we could have a different grub.cfg script
that finds appropiate prefix using the search command.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Scan root device dynamically at startup

[Bean]

On Thu, May 29, 2008 at 5:58 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Wed, May 28, 2008 at 10:53:07PM +0800, Bean wrote:
>>
>> In function grub_set_root_dev (main.c), it uses prefix to calculated
>> root, so setting prefix is sufficient.
>>
>> About the name, well, findprefix works for me too.
>>
>> > Also, what this module is doing looks very similar to "search --set".  Did
>> > you check if search command can be used for what you want?  (or otherwise
>> > adapted)
>>
>> The findroot module is used to locate normal.mod. But search is a
>> command, it can only be used after normal.mod has been loaded.
>
> I've been thinking a bit more about this, and my impression is that it the
> approach is quite ad-hoc.  For example, some similar problems that this
> solution wouldn't solve, but that a very similar solution would:
>
>  a- normal.mod was built into grub.elf (perhaps because the firmware can load
>    big files).  Then the problem is finding grub.cfg instead of normal.mod.

If the firmware support large image file, then it's no problem. For
image ~ 64K, we can include normal and some basic command. But for
image ~ 32K (like vista boot loader), it can only contain kernel and
one of the file system driver.

>
>  b- User has a disk liing around which happens to have a normal.mod from
>    an earlier version of grub (let's assume different ABI).  Turns out this
>    disk is used for something else and can't be supressed.  A solution could
>    be to use UUIDs for the search, but that can't always work since we need
>    a "smart" install process that can probe for them (unlike in the situation
>    you described -- I can't imagine doing fancy stuff in bare-bones Vista).
>

I think this is the most convenient way of installing grub2 in vista.
User don't need any customization. They just add the entry and copy
/boot/grub to any supported partition. Besides, our driver currently
don't support UUID, and some partition doesn't have UUID (like FAT).

>  c- Search for normal.mod was ok, but then this particular port of grub can't
>    accept the prefix variable from your module, because it already got this
>    variable from the firmware (OFW does this).  And the variable from firmware
>    happens to be completely unusable.

The module initialization code is run in grub_load_modules (), It's
before the platform code  grub_machine_set_prefix (). If findroot has
find the prefix, it won't use the firmware value anymore.

> I think a solution that would fit well here is to use memdisk to embed a
> grub.cfg.  Then in each situation we could have a different grub.cfg script
> that finds appropiate prefix using the search command.

memdisk is not so useful in such situation. grub.cfg need normal.mod
for its script engine. So we need to embed normal.mod. and at least
search.mod. Such image is well above 32K limit.

-- 
Bean

Re: [PATCH] Scan root device dynamically at startup

[Tomáš Ebenlendr]

Dne 29 Květen 2008, 12:46, Bean napsal(a):

> I think this is the most convenient way of installing grub2 in vista.
> User don't need any customization. They just add the entry and copy
> /boot/grub to any supported partition. Besides, our driver currently
> don't support UUID, and some partition doesn't have UUID (like FAT).
>

Every FAT has serial number, generated when first formating of partition,
it is only 4 bytes, so it is not as unique as UUID but it suffices.

Other filesystems often have similar identifiers.

-- 
Tomas Ebenlendr
                            http://drak.ucw.cz/~ebik

Re: [PATCH] Scan root device dynamically at startup

[Robert Millan]

On Thu, May 29, 2008 at 02:05:59PM +0200, Tomáš Ebenlendr wrote:
> 
> Dne 29 Květen 2008, 12:46, Bean napsal(a):
> 
> > I think this is the most convenient way of installing grub2 in vista.
> > User don't need any customization. They just add the entry and copy
> > /boot/grub to any supported partition. Besides, our driver currently
> > don't support UUID, and some partition doesn't have UUID (like FAT).
> >
> 
> Every FAT has serial number, generated when first formating of partition,
> it is only 4 bytes, so it is not as unique as UUID but it suffices.
> 
> Other filesystems often have similar identifiers.

My point is not about FAT; that's just an example.  What I mean is we can't
always rely on UUID being usable;  and in Bean's use case it isn't.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Scan root device dynamically at startup

[Robert Millan]

On Thu, May 29, 2008 at 02:05:59PM +0200, Tomáš Ebenlendr wrote:
> 
> Every FAT has serial number, generated when first formating of partition,
> it is only 4 bytes, so it is not as unique as UUID but it suffices.
> 
> Other filesystems often have similar identifiers.

Now that we have a framework for filesystem UUIDs, it should be simple to
support FAT serial numbers like it is done in the ext2 driver.

If you're familiar with FAT, would you like to help us on this?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Scan root device dynamically at startup

[Bean]

On Fri, May 30, 2008 at 9:29 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Thu, May 29, 2008 at 02:05:59PM +0200, Tomáš Ebenlendr wrote:
>>
>> Every FAT has serial number, generated when first formating of partition,
>> it is only 4 bytes, so it is not as unique as UUID but it suffices.
>>
>> Other filesystems often have similar identifiers.
>
> Now that we have a framework for filesystem UUIDs, it should be simple to
> support FAT serial numbers like it is done in the ext2 driver.
>
> If you're familiar with FAT, would you like to help us on this?

Well, the FAT signature is the unsigned long value after the extended
boot signature 0x29, I can add it later.

-- 
Bean

Re: [PATCH] Scan root device dynamically at startup

[Robert Millan]

On Thu, May 29, 2008 at 06:46:25PM +0800, Bean wrote:
> >
> > I've been thinking a bit more about this, and my impression is that it the
> > approach is quite ad-hoc.  For example, some similar problems that this
> > solution wouldn't solve, but that a very similar solution would:
> >
> >  a- normal.mod was built into grub.elf (perhaps because the firmware can load
> >    big files).  Then the problem is finding grub.cfg instead of normal.mod.
> 
> If the firmware support large image file, then it's no problem. For
> image ~ 64K, we can include normal and some basic command. But for
> image ~ 32K (like vista boot loader), it can only contain kernel and
> one of the file system driver.

Yes.  But then, how do you find grub.cfg?  The grub.cfg that is generated by
update-grub can't be part of grub.elf, and you need a way to find it.

Your proposed hack would work for that, simply by replacing "normal.mod" with
"grub.cfg".

> >  b- User has a disk liing around which happens to have a normal.mod from
> >    an earlier version of grub (let's assume different ABI).  Turns out this
> >    disk is used for something else and can't be supressed.  A solution could
> >    be to use UUIDs for the search, but that can't always work since we need
> >    a "smart" install process that can probe for them (unlike in the situation
> >    you described -- I can't imagine doing fancy stuff in bare-bones Vista).
> >
> 
> I think this is the most convenient way of installing grub2 in vista.
> [...]

It probably is;  what I'm describing is another situation in which the most
convenient way is almost like that but not quite.  Then we would need another
module for that, which is a mess.  That's why I think a generic solution would
be best, if possible.

> >  c- Search for normal.mod was ok, but then this particular port of grub can't
> >    accept the prefix variable from your module, because it already got this
> >    variable from the firmware (OFW does this).  And the variable from firmware
> >    happens to be completely unusable.
> 
> The module initialization code is run in grub_load_modules (), It's
> before the platform code  grub_machine_set_prefix (). If findroot has
> find the prefix, it won't use the firmware value anymore.

But it is run after grub_machine_init(), and it is permissible that
grub_machine_init() already sets the prefix (ieee1275 does that).

Maybe your proposed module should override this setting, then?

> > I think a solution that would fit well here is to use memdisk to embed a
> > grub.cfg.  Then in each situation we could have a different grub.cfg script
> > that finds appropiate prefix using the search command.
> 
> memdisk is not so useful in such situation. grub.cfg need normal.mod
> for its script engine. So we need to embed normal.mod. and at least
> search.mod. Such image is well above 32K limit.

That's unfortunate... do you think this approach could be extended/modified
somehow to address the other situations?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)