Re: [Patch] Enable libzfs detection on Linux

[Robert Millan]

Hi Zachary,

2011/9/14 Zachary Bedell :
> FWIW, my commit comment locally for this was:
>  * Adjusts autoconf logic to properly detect libzfs on Linux.
>  * Includes additional headers necessary for libspl.

Excuse me if I missed something, but weren't you holding the position
that libzfs ABI was too unstable and relying on it from external
programs was a bad idea?

Recently Debian has had severe problems in this area because of this.
C.f. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645305

Last month I sent a proof of concept patch that implements this idea
(in "getroot for ZFS without libzfs?" thread).  Did you see this part
of the thread?

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: getroot for ZFS without libzfs?

[Robert Millan]

2011/10/16 Robert Millan :
>> What is the device node list used for? To list devices that each need grub 
>> installed, or for something else?
>
> grub-probe internally needs access to the raw devices because it wants
> to use GRUB codepaths to obtain fs_uuid and such.

In other words: to use same ZFS codepaths directly on raw device as
they will be used when real GRUB boots.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: getroot for ZFS without libzfs?

[Robert Millan]

2011/10/15 Seth Goldberg :
> Hi again,
>
>  Also: can we please retain the libzfs usage for those platforms that 
> actually have it and that would rather use it?

What for?  libzfs is only needed for a single operation (determining
physical device list).  With my patch that operation is no longer
required.

> I can certainly understand the desire to eliminate it for platforms that 
> don't have or don't want to port it, but eliminating it from all platforms is 
> overkill.

It's not a portability problem.  It seems libzfs isn't really meant to
be used externally.  ABI changes without notice, there's no soname
update and no versioning information.  See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645305

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: getroot for ZFS without libzfs?

[Robert Millan]

2011/10/15 Seth Goldberg :
> Hi,
>
>  Have you tested this with phcoder's experimental zfs branch that has 
> mirroring support?

No.  I guess I might have duplicated some work; where's that branch?
I'll try to rebase my patch.

> What is the device node list used for? To list devices that each need grub 
> installed, or for something else?

grub-probe internally needs access to the raw devices because it wants
to use GRUB codepaths to obtain fs_uuid and such.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: getroot for ZFS without libzfs?

[Robert Millan]

Hi,

Please test / comment on proof-of-concept attached patch, it gets rid
of libzfs dependency in GRUB.

The approach is to implement a disk abstraction, like LVM does, but in
this case a very simple one (passthrough).  Then grub-probe et al can
obtain their information from this abstraction layer like they
currently do with LVM or mdRAID, but they don't need the device node
list anymore (since it's filled with a full scan, as with LVM).

-- 
Robert Millan
=== modified file 'configure.ac'
--- configure.ac	2011-08-19 20:49:48 +
+++ configure.ac	2011-10-15 16:42:10 +
@@ -916,18 +916,6 @@ AC_CHECK_LIB([lzma], [lzma_code],
 [Define to 1 if you have the LZMA library.])],)
 AC_SUBST([LIBLZMA])
 
-AC_CHECK_LIB([zfs], [libzfs_init],
- [LIBZFS="-lzfs"
-  AC_DEFINE([HAVE_LIBZFS], [1],
-[Define to 1 if you have the ZFS library.])],)
-AC_SUBST([LIBZFS])
-
-AC_CHECK_LIB([nvpair], [nvlist_print],
- [LIBNVPAIR="-lnvpair"
-  AC_DEFINE([HAVE_LIBNVPAIR], [1],
-[Define to 1 if you have the NVPAIR library.])],)
-AC_SUBST([LIBNVPAIR])
-
 LIBS=""
 
 pkglibrootdir='$(libdir)'/`echo $PACKAGE | sed "$program_transform_name"`

=== modified file 'grub-core/fs/zfs/zfs.c'
--- grub-core/fs/zfs/zfs.c	2011-06-23 22:31:29 +
+++ grub-core/fs/zfs/zfs.c	2011-10-15 16:42:10 +
@@ -53,6 +53,10 @@
 #include 
 #include 
 
+#ifdef GRUB_UTIL
+#include 
+#endif
+
 GRUB_MOD_LICENSE ("GPLv3+");
 
 #define	ZPOOL_PROP_BOOTFS		"bootfs"
@@ -2179,6 +2183,130 @@ zfs_uuid (grub_device_t device, char **u
   return GRUB_ERR_NONE;
 }
 
+struct grub_zfs_vdev
+{
+  const char *name;
+  struct grub_zfs_vdev *next;
+};
+
+struct grub_zfs_pool
+{
+  grub_uint64_t guid;
+  char *name;
+  struct grub_zfs_vdev *vdev_list;
+  struct grub_zfs_pool *next;
+};
+
+static struct grub_zfs_pool *zpool_list;
+
+static int
+zfs_scan_device (const char *name)
+{
+  grub_device_t device;
+  struct grub_zfs_data *data;
+  char *nvlist;
+  grub_uint64_t guid;
+  char *label;
+  struct grub_zfs_pool *zpool;
+  struct grub_zfs_vdev *vdev;
+
+#ifdef GRUB_UTIL
+  grub_util_info ("scanning %s for ZFS", name);
+#endif
+
+  device = grub_device_open (name);
+  if (! device)
+return 0;
+
+  data = zfs_mount (device);
+  if (! data)
+goto end1;
+
+  if (zfs_fetch_nvlist (data, &nvlist))
+goto end2;
+
+  if (! grub_zfs_nvlist_lookup_uint64 (nvlist, ZPOOL_CONFIG_POOL_GUID, &guid))
+goto end3;
+
+  label = grub_zfs_nvlist_lookup_string (nvlist, ZPOOL_CONFIG_POOL_NAME);
+  if (! label)
+goto end3;
+
+  vdev = grub_zalloc (sizeof (*vdev));
+  vdev->name = grub_strdup (name);
+
+  struct grub_zfs_pool *i;
+  for (i = zpool_list; i; i = i->next)
+{
+  if (guid == i->guid)
+	{
+	  /* This vdev belongs to an already-registered pool.  */
+	  vdev->next = i->vdev_list;
+	  i->vdev_list = vdev;
+	  return 0;
+	}
+}
+
+  /* Create a new ZFS pool with this vdev.  */
+  zpool = grub_zalloc (sizeof (*zpool));
+  zpool->guid = guid;
+  zpool->name = grub_xasprintf ("zfs/%s", label);
+  zpool->vdev_list = vdev;
+
+  /* Insert it to ZFS pool list.  */
+  zpool->next = zpool_list;
+  zpool_list = zpool;
+
+ end3:
+  grub_free (nvlist);
+ end2:
+  zfs_unmount (data);
+ end1:
+  grub_device_close (device);
+
+  return 0;
+}
+
+static int 
+grub_zpool_iterate (int (*hook) (const char *name),
+		grub_disk_pull_t pull __attribute__ ((unused)))
+{
+  struct grub_zfs_pool *i;
+  for (i = zpool_list; i; i = i->next)
+{
+  if (hook (i->name))
+	return 1;
+}
+
+  return 0;
+}
+
+static grub_err_t
+grub_zpool_open (const char *name, grub_disk_t disk)
+{
+  struct grub_zfs_pool *i;
+  for (i = zpool_list; i; i = i->next)
+{
+  if (! grub_strcmp (i->name, name))
+	{
+	  /* For now just pick the first vdev as lower layer.  */
+	  grub_disk_t lower = grub_disk_open (i->vdev_list->name);
+	  grub_memcpy (disk, lower, sizeof (*disk));
+	  return GRUB_ERR_NONE;
+	}
+}
+
+  return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "not a ZFS pool");
+}
+
+static struct grub_disk_dev grub_zpool_dev =
+  {
+.name = "zfs",
+.id = GRUB_DISK_DEVICE_ZFS_ID,
+.iterate = grub_zpool_iterate,
+.open = grub_zpool_open, 
+  };
+
 /*
  * zfs_open() locates a file in the rootpool by following the
  * MOS and places the dnode of the file in the memory address DNODE.
@@ -2556,6 +2684,9 @@ static struct grub_fs grub_zfs_fs = {
 
 GRUB_MOD_INIT (zfs)
 {
+  grub_device_iterate (&zfs_scan_device);
+  grub_disk_dev_register (&grub_zpool_dev);
+
   grub_fs_register (&grub_zfs_fs);
 #ifndef GRUB_UTIL
   my_mod = mod;
@@ -2564,5 +2695,9 @@ GRUB_MOD_INIT (zfs)
 
 GRUB_MOD_FINI (zfs)
 {
+  grub_disk_dev_unregister (&grub_zpool_dev);
+  zpool_list = NU

Re: getroot for ZFS without libzfs?

[Robert Millan]

2011/8/11 Zachary Bedell :
> The pool can be identified positively via the guid which is in the labels and 
> available via `zpool list -H -o guid `.

I see.  Thanks for the explanation.

> Is calling out to zpool as a helper kosher?  The -H flag to zpool pool is 
> basically Sun's idea of a public API in that it's intended to output only the 
> requested fields with no header information for automated parsing.

I think -H output looks sane enough (and more stable, so all the better).

> Definitely agree.  The fact that libzfs is specifically listed as private API 
> not intended for linking against also makes me wonder if the syslib exception 
> is a concern for that.

But SUN/Oracle has linked GRUB with libzfs. This is a good indication
that they trust this method to be safe (it's our copyright which would
be infringed by them, not theirs by us).

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: getroot for ZFS without libzfs?

[Robert Millan]

2011/8/9 Zachary Bedell :
> You'd need to look at all the raw devices to begin with and see which if any 
> has a ZFS label

Yes, but how do you know this is the label you wanted?  Consider the
case where there's more than one pool with this name.

>> The other API that is available to us is /dev/zfs.  But is that device
>> meant to be used directly?  How stable is this interface?
>
> /dev/zfs is probably less stable than libzfs

Then I wouldn't use /dev/zfs.  The less stable and standard is the ZFS
API GRUB uses, the more likely is that one can argue it doesn't fall
under the "system library" exception.

Directly accessing on-disk structures is entirely different, since a
data structure itself can't be copyrighted.

> My reasons for looking at other options were primarily GPL driven, but given 
> that's not an issue, it's probably moot for now.  It might be slightly more 
> elegant to use pure Grub code given that all of the underlying functionality 
> is there already,

I agree.  But I'm still concerned about the technical problems.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: getroot for ZFS without libzfs?

[Robert Millan]

Hi Zachary,

2011/8/8 Zachary Bedell :
> It appears that existing Grub code already links against libzfs for the 
> benefit of find_root_device_from_libzfs and other functions in getroot.c.  It 
> also appears that libzfs is not used outside this file.  That linkage 
> surprises me a bit as I would have expected GPL Grub linked against CDDL 
> libzfs to create a problem.

Not really.  This kind of use falls under the system library
exception, see section 1 of the GPL.

> Also libzfs is considered a private API and not intended to be linked 
>against, though admittedly what I propose (reading on-disk structures 
>directly) is arguably worse than accessing a private library.

I don't think you can figure out the disks corresponding to a zpool
just by reading disk structures.  You can guess, but only the kernel
knows for sure.

The other API that is available to us is /dev/zfs.  But is that device
meant to be used directly?  How stable is this interface?

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Loongson 2E boot failure

[Robert Millan]

2011/7/26 Colin Watson :
>> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
>> 8100-8200
>
> Sorry, I've not had to mess with this before.  Can you point me to what
> I'd need to change to hardcode a specific heap region?

Try replacing grub_machine_mmap_iterate() with something like:

grub_err_t
grub_machine_mmap_iterate (grub_memory_hook_t hook)
{
  hook (0x8100, 8200, GRUB_MEMORY_AVAILABLE);
  return GRUB_ERR_NONE;
}

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: FreeBSD relocator crash

[Robert Millan]

2011/2/9 Colin Watson :
> While working on Debian bug #612128 in a KVM instance, I found that any
> call to kfreebsd_module_elf seems to crash GRUB (1.99~rc1).  I
> reproduced this with both FreeBSD 7.2 + acpi.ko and FreeBSD 8.1 +
> ufs.ko.  This sequence of commands:
>
>  kfreebsd /boot/kfreebsd-8.1-1-686.gz
>  set debug=all
>  kfreebsd_module_elf /lib/modules/8.1-1-686/ufs.ko
>
> ... results in this sequence of debug messages just before hanging:

I suggest a regression search. The following combination is
widely tested and known to work:

- GRUB 1.98+20100804-14
- kfreebsd /boot/kfreebsd-8.1-1-amd64.gz
- kfreebsd_module_elf /lib/modules/8.1-1-amd64/opensolaris.ko
- kfreebsd_module_elf /lib/modules/8.1-1-amd64/zfs.ko

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub-extras legal and technical status (was Re: ZFS imported into GRUB)

[Robert Millan]

2010/12/15 Nathan Coulson :
> That would be me (http://nathancoulson.com/proj_grub2_915.shtml).
> Made a few years back, based upon the original 915resolution
> (According to LICENSE.txt from 915resolution, 915resolution is in the
> public domain).  Since KMS was added to the linux kernel, though, I
> have not done any maintenance on it (although it looks like some
> distributions have added onto this work).
>
> Oh, and just to clarify, I never licensed it under the GPL3.  I have a
> passing familiarity with the GPL and other licenses, but at the time I
> wrote this I was not sure how it should have been licensed (My only
> concern when it came to licensing is that I did not change much from
> 915resolution, and 915resolution was not my work).
>
> According to LICENSE.txt from 915resolution 0.5.3 package,
> http://915resolution.mango-lang.org/, 915resolution is in the Public
> Domain.

Hi Nathan,

First off, thanks for porting 915resolution to GRUB, I think it has
been useful to many users since then.

I believe the multiple license headers in 915resolution.c correctly
reflect the copyright status (or lack thereof) and license from the
changes made by each party.  Back in the day I took special care
to document them (but if you think I made a mistake, then please
let me know about it).

The COPYING file specifies license terms that can be applied
to the whole.  In this case it's accurate in saying that GPL
terms can be applied to the result.  This doesn't imply that you
licensed any code under GPL, only that your license terms
(or in this case, your lack of copyright assertion) are compatible
with the GPL.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS imported into GRUB

[Robert Millan]

2010/12/2 KESHAV P.R. :
> What about other grub-extras?

We have analyzed those on a case-by-case basis.  grub-extras
is a collection of 3rd party add-ons to GRUB.  These don't
necessarily need to be made part of GRUB, but they're
useful in certain situations and this is why the grub-extras
project provides them.

We don't think there are legal problems with the code in
grub-extras, but when it comes to official GRUB we follow
high standards when it comes to this matter.

Legal issues are often underestimated, but they're
dangerous.  One thing is to lose a feature, a different
one is leaving the GNU system without its bootloader.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

ZFS imported into GRUB

[Robert Millan]

Hi,

Following our new strategy with regard to Oracle code, we (GRUB
maintainers) have decided to grant an exception to our usual policy and
import ZFS code from grub-extras into official GRUB.

Our usual policy is to require copyright assignment for all new code, so
that FSF can use it to defend users' freedom in court.  If that's not
possible, at least a disclaimer asserting authorship (i.e. that no
copyright infringement has been committed).  The purpose of this, as
always, is ensuring that GRUB is a legally safe codebase.

The ZFS code that has been imported into GRUB derives from the
OpenSolaris version of GRUB Legacy.  On one hand, this code was released
to the public under the terms of the GNU GPL.  On the other, binary
releases of Solaris included this modified GRUB, and as a result
Oracle/Sun is bound by the GPL.

We believe that these two factors give us very strong reassurance that:

a) Oracle owns the copyright to this code
and
b) Oracle is licensing it under GPL

and therefore it is completely safe to use this in GRUB.

We're looking forward to this code import will foster collaboration on
ZFS support for GRUB.  Our understanding is that next version of
Solaris will ship with GRUB 2, and so we expect the whole OpenSolaris
ecosystem to do this move as well.  We encourage downstream distributors
to anticipate this by preparing their transition from the old, legacy
version of GRUB (0.97) which is no longer supported by GRUB developers.


Finally, a word about patents.  Software patents are terribly harmful to
free software, and to IT in general.  We believe they should be
abolished.  However, until that happens, we need to take measures to
protect our users.  We recognize it is practically impossible for end
users to archieve a situation where they're completely safe from patent
infringement (even if they pay so-called "patent taxes" to specific
companies).

However, we encourage our users to make careful choices when importing
technology that is designed in an in-door development model (rather
than in the community), because it's prone to be heavily patented.

This is the reason why, when we (the GNU project) developed the GPL, we
included certain provisions in it to ensure a patent holder can't
benefit from the freedoms we gave them and at the same time use patents
to undermine these freedoms for others.

Thanks to this, and due to the fact that Oracle is bound to the terms
of the GNU GPL when it comes to GRUB, we believe this renders patents
covering ZFS basically harmless to GRUB users.  If the patents
covering GRUB are held by Oracle, they can't use them against GRUB
users, and if they're held by other parties, the GPL provisions will
prevent Oracle from paying a tax only for themselves, so if they will
fight alongside the community instead of betraying it.

Let this serve as yet another example on why so-called "permissive"
licenses aren't always a guarantee that the code covered by them can be
used freely.  If you intend for your code to be free for all users,
always use the latest version of the GPL.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: future of grub commands setup and install ?

[Robert Millan]

2010/9/10, lode leroy :
> It may be easy to copy files onto the filesystem, but
> not-so-easy
> to create a working native grub.

What's hard about grub-install /dev/sda ?

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: future of grub commands setup and install ?

[Robert Millan]

2010/9/9, Treutwein Bernhard :
> according to the wiki the commands install & setup are "unecessary".
>
> I do consider setup (which itself uses install) as "desirable" at least.

GRUB lacks filesystem write support (intentionally).  Therefore, installing
GRUB from GRUB is not possible.  Given that setup command can only
perform part of this, it is unrealistic to pretend setup command is useful.
This is why it was removed.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

gazillon of double-free

[Robert Millan]

It seems we have a ton of double-free bugs in label() and
uuid() routines.

Take for example grub_ext2_label():

  data = grub_ext2_mount (disk);
  if (data)
*label = grub_strndup (data->sblock.volume_name, 14);
  else
*label = NULL;
  grub_free (data);

If grub_ext2_mount fails, data is not allocated but we free it anyway.

Or perhaps I'm missing something? (it's late here, I need some sleep)

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: LiveCD bootloader

[Robert Millan]

2010/9/8, Teresa e Junior :
> But due to some features I need (not the eyecandy), I noticed the CD
> only boots without gfx support (which is the most important for me).

You need to write a grub.cfg for that.  Check this one as an example
and adjust to your liking:

http://svn.debian.org/viewsvn/d-i/trunk/installer/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg?revision=64460&view=markup

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: LiveCD bootloader

[Robert Millan]

2010/9/8, Brendan Trotter :
> My apologies.
>
> It seems GRUB2 has improved a lot, and doesn't rely on the obsolete
> "standard video mode numbers" anymore. Except for problems caused by
> video modes that are supported by the video card but not supported by
> the monitor; it's mostly only a problem with Linux itself now.

Not with Linux either, just "set gfxpayload=keep" and GRUB will preserve
video mode when giving control to Linux.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bug#593467: grub-pc: add support for root ext2/xfs on GNU/kFreeBSD

[Robert Millan]

After discussing it with Vladimir I commited this.  I refactored module load
routine while at it, making code a bit more readable.

I tested it, but only with ZFS.  I also verified that loading ufs.ko when
it has been built into kernel doesn't lead to trouble (duplicate modules
are discarded).  Let me know if there were a problem with other filesystems.

-- 
Robert Millan
=== modified file 'ChangeLog'
--- ChangeLog	2010-08-19 23:15:23 +
+++ ChangeLog	2010-08-20 14:34:56 +
@@ -1,3 +1,13 @@
+2010-08-20  Robert Millan  
+
+	Make kFreeBSD code more generic to support ext2fs as root, ufs as
+	a separate module and maybe other interesting combinations.
+
+	* util/grub.d/10_kfreebsd.in (load_kfreebsd_module): New function.
+	(kfreebsd_entry): Use load_kfreebsd_module() to load modules.
+	(kfreebsd_entry): Add generic filesystem module load routine.
+	Map GRUB `ext2' to kFreeBSD `ext2fs'.
+
 2010-08-20  Colin Watson  
 
 	* commands/i386/pc/sendkey.c (keysym_table): Rename "numlock" to

=== modified file 'util/grub.d/10_kfreebsd.in'
--- util/grub.d/10_kfreebsd.in	2010-08-08 14:27:58 +
+++ util/grub.d/10_kfreebsd.in	2010-08-20 14:29:50 +
@@ -39,6 +39,31 @@ case "${GRUB_DISTRIBUTOR}" in
   ;;
 esac
 
+load_kfreebsd_module ()
+{
+  mod="$1"
+  allow_fail="$2"
+
+  if ! test -e "${module_dir}/${mod}.ko" ; then
+if [ "${allow_fail}" = "true" ] ; then
+  # Return silently
+  return
+else
+  # Print an error and fail.
+  ls "${module_dir}/${mod}.ko" > /dev/null
+fi
+  fi
+
+  if [ -z "${prepare_module_dir_cache}" ]; then
+prepare_module_dir_cache="$(prepare_grub_to_access_device $(grub-probe -t device "${module_dir}") | sed -e "s/^/\t/")"
+  fi
+
+  printf '%s\n' "${prepare_module_dir_cache}"
+  cat << EOF
+	kfreebsd_module_elf	${module_dir_rel}/${mod}.ko
+EOF
+}
+
 kfreebsd_entry ()
 {
   os="$1"
@@ -51,9 +76,6 @@ kfreebsd_entry ()
   if [ -z "${prepare_boot_cache}" ]; then
 prepare_boot_cache="$(prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/")"
   fi
-  if [ -z "${prepare_module_dir_cache}" ]; then
-prepare_module_dir_cache="$(prepare_grub_to_access_device $(grub-probe -t device "${module_dir}") | sed -e "s/^/\t/")"
-  fi
 
   printf '%s\n' "${prepare_boot_cache}"
   cat << EOF
@@ -67,26 +89,13 @@ EOF
 EOF
   fi
 
-  if test -e "${module_dir}/acpi.ko" ; then
-printf '%s\n' "${prepare_module_dir_cache}"
-cat << EOF
-	kfreebsd_module_elf	${module_dir_rel}/acpi.ko
-EOF
-  fi
+  load_kfreebsd_module acpi true
 
   case "${kfreebsd_fs}" in
 zfs)
-  for i in "${module_dir}/opensolaris.ko" "${module_dir}/zfs.ko" \
-  "${dirname}/zfs/zpool.cache" ; do
-ls "$i" > /dev/null
-  done
-
-  printf '%s\n' "${prepare_module_dir_cache}"
-  cat << EOF
-	kfreebsd_module_elf	${module_dir_rel}/opensolaris.ko
-	kfreebsd_module_elf	${module_dir_rel}/zfs.ko
-EOF
+  load_kfreebsd_module opensolaris false
 
+  ls "${dirname}/zfs/zpool.cache" > /dev/null
   printf '%s\n' "${prepare_boot_cache}"
   cat << EOF
 	kfreebsd_module		${rel_dirname}/zfs/zpool.cache type=/boot/zfs/zpool.cache
@@ -94,6 +103,8 @@ EOF
 ;;
   esac
 
+  load_kfreebsd_module ${kfreebsd_fs} false
+
   cat << EOF
 	set kFreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${kfreebsd_device}
 	set kFreeBSD.vfs.root.mountfrom.options=rw
@@ -121,8 +132,9 @@ while [ "x$list" != "x" ] ; do
   fi
 
   case ${GRUB_FS} in
-ufs1 | ufs2)kfreebsd_fs=ufs ;;
-*)  kfreebsd_fs=${GRUB_FS} ;;
+ufs1 | ufs2)	kfreebsd_fs=ufs ;;
+ext2)		kfreebsd_fs=ext2fs ;;
+*)			kfreebsd_fs=${GRUB_FS} ;;
   esac
 
   case ${GRUB_FS} in

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bug#593467: grub-pc: add support for root ext2/xfs on GNU/kFreeBSD

[Robert Millan]

2010/8/18, Colin Watson :
> On Wed, Aug 18, 2010 at 03:07:57PM +0200, Aurelien Jarno wrote:
>> Since GNU/kFreeBSD switch to grub as the default bootloader, it is
>> almost possible to use an ext2 or xfs root filesystem. While there
>> is not a lot of interest in doing that, the patch to do it is quite
>> small. Could you please apply it in the next upload?
>
> Sending upstream first.  Does this require copyright assignment?

I'd rather make it generic, something like this.  Does it work for you?

This has interesting side-effects, like for example it would be possible to
build UFS as a module.

-- 
Robert Millan
2010-08-20  Robert Millan  

	* util/grub.d/10_kfreebsd.in (kfreebsd_entry): Add generic module
	load routine.
	Map GRUB `ext2' to kFreeBSD `ext2fs'.

=== modified file 'util/grub.d/10_kfreebsd.in'
--- util/grub.d/10_kfreebsd.in	2010-08-08 14:27:58 +
+++ util/grub.d/10_kfreebsd.in	2010-08-19 21:54:59 +
@@ -92,6 +92,14 @@ EOF
 	kfreebsd_module		${rel_dirname}/zfs/zpool.cache type=/boot/zfs/zpool.cache
 EOF
 ;;
+*)
+  ls "${module_dir}/${kfreebsd_fs}.ko" > /dev/null
+
+  printf '%s\n' "${prepare_module_dir_cache}"
+  cat << EOF
+	kfreebsd_module_elf	${module_dir_rel}/${kfreebsd_fs}.ko
+EOF
+;;
   esac
 
   cat << EOF
@@ -121,8 +129,9 @@ while [ "x$list" != "x" ] ; do
   fi
 
   case ${GRUB_FS} in
-ufs1 | ufs2)kfreebsd_fs=ufs ;;
-*)  kfreebsd_fs=${GRUB_FS} ;;
+ufs1 | ufs2)	kfreebsd_fs=ufs ;;
+ext2)		kfreebsd_fs=ext2fs ;;
+*)			kfreebsd_fs=${GRUB_FS} ;;
   esac
 
   case ${GRUB_FS} in

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub-setup on ZFS (Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS)

[Robert Millan]

2010/8/16, Seth Goldberg :
>> Implicit approach only works for mirrored setup.  If you want to install
>> to all
>> members in a non-mirrored pool, you still need explicit approach, so I'd
>> only
>> implement implicit one if there's a clear benefit, such as the protection
>> offered by mirroring.  I would check if zfs.mod from grub-extras provides
>> this
>> protection before trying to answer this question.
>
>That's true -- right now, we only support root on an n-way mirrored pool.
> If support is expanded in the future, why wouldn't a similar
> grub_util_raid_getmembers() not work in an analagous way to the mirrored
> case?

Sorry, it would work.  I just didn't think of this possibility because I find it
confusing.

In a mirrored setup, grub-setup does what user expects (copiing core.img
to each disk).  In a non-mirrored array, user could think grub-setup will do
the analogous (interleaving core.img), but this wouldn't work, so what
you propose is to do something different which would work but is probably
not what user expects.

Not that this matters a lot (in the end user can boot), but I can't see any
advantage in providing two ways to do the same thing, specially when it
isn't obvious they are equivalent.

Also, in ZFS there isn't a single device name that identifies the whole pool
(as with mdraid), which would make the semantics even more confusing.

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add grub-mbchk utility to grub

[Robert Millan]

Btw I think this is not true anymore:

+  /* This is a GRUB-specific limitation.  */
+  if (mbh->load_addr < 0x10)
+   {
+ fprintf (stderr,
+  "%s: Cannot be loaded at less than 1MB by GRUB"
+  " (0x%x).\n",
+  filename, mbh->load_addr);
+ return 0;
+   }

-- 
Robert Millan

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add grub-mbchk utility to grub

[Robert Millan]

2010/8/10, Scott Moser :
> Hi all,
>I've been playing around with multiboot images, and found grub 0.97's
> 'mbchk' to be very useful.  Its really nice from a shell script or other
> to easily answer "is this file a multiboot image?".
>
>The attached patch basically copies mbchk.c from grub-0.97 to current
> bzr with minimal changes.
>Is that something that could be carried in grub2 ?

I think it would make more sense in multiboot itself (multiboot package
doesn't just include documentation, there's also sample C code and
such).

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub-setup on ZFS (Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS)

[Robert Millan]

I'd also point out that the device where grub-setup will embed
core.img is a minor issue here, since it's trivial to run grub-setup
multiple times.  The real problem is putting /boot/grub/ in a
mirrored filesystem so that either copy of core.img will be able
to access this directory from any of the disks.

Or if you're serious into this, from a combination of disks in a
non-mirror multi-device pool.

I think both goals require some work in zfs.mod.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

grub-setup on ZFS (Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS)

[Robert Millan]

2010/8/4, Seth Goldberg :
>> I don't think this is the appropiate place for this kind of sanity check.
>> Keep in mind "grub-probe -t device" has many purposes, and for some of
>> them
>> (e.g. determining the partmap) the ZFS status is irrelevant.
>
>Hmm.  I do see your point here, but then I'd ask how you plan to handle
> ensuring that all disks in a mirror are properly updated with boot/core.
> I think the proper thing would be either to have grub-probe output a set of
> devices, onto which grub-setup would iterate and install boot/core, or
> implement an abstraction that allows that to happen behind the scenes.  How
> does this work for lvm or other raids?

There are two approaches, one of them is simply to run grub-install for each
of the intended devices.  This is what Debian scripts do, and is independant
on the content in the partitions of those devices (lvm, raid, zfs, whatever).

The other is giving grub-setup special knowledge of the abstraction. We do
this for RAID1, see the code around:

util/i386/pc/grub-setup.c:  devicelist = grub_util_raid_getmembers
(dest_dev);

which allows user to e.g. "grub-install /dev/md0". Then the scripts
embed raid.mod
into core.img, and (in principle) after core.img has been loaded GRUB has RAID
mirroring protection to access /boot/grub/.

I suppose it's possible to do something similar for ZFS mirror layouts.

>The question is: should GRUB2's installation be implicit or explicit for
> all members of a mirrored root pool when grub-setup is invoked.

Implicit approach only works for mirrored setup.  If you want to install to all
members in a non-mirrored pool, you still need explicit approach, so I'd only
implement implicit one if there's a clear benefit, such as the protection
offered by mirroring.  I would check if zfs.mod from grub-extras provides this
protection before trying to answer this question.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] ZFS "(dev)/foo@/" pathnames

[Robert Millan]

Committed, with some adjustments.  I put the new code in misc.c instead
of getroot.c to prevent grub-mkrelpath (and others) from having to drag
a gazillon other files in.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

system-installed libzfs.h and libnvpair.h (Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS)

[Robert Millan]

2010/7/30, Robert Millan :
> Unfortunately there are availability problems with libzfs.h and libnvpair.h.
>  On
> FreeBSD they're not installed system-wide.  On OpenSolaris I can't see them
> installed either (although in this one I'm probably missing something).

I figured what's going on.  Original headers depend on a few
OpenSolaris-specific definitions.  It's mostly trivial stuff, but FreeBSD
developers opted for wrapping those headers around compatibility
glue instead of patching them, and as a result these headers aren't
usable outside their compatibility build environment.

I sent a report for  to OpenSolaris BTS:
https://defect.opensolaris.org/bz/show_bug.cgi?id=16697#c0

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] ZFS root in 10_kfreebsd.in

[Robert Millan]

This adds support for ZFS root in 10_kfreebsd.in.  It works with
current trunk if my grub-mkrelpath patch has been applied, and if
ZFS from grub-extras has been built into GRUB.
2010-07-31  Robert Millan  

	* util/grub.d/10_kfreebsd.in: Initialize ${kfreebsd_device} as the
	kFreeBSD device name, except on ZFS where the filesystem label is
	used.
	(kfreebsd_entry): On ZFS root, load `opensolaris.ko', `zfs.ko' and
	`/boot/zfs/zpool.cache'.
	Set mountfrom kernel variable using ${kfreebsd_device}.

=== modified file 'util/grub.d/10_kfreebsd.in'
--- util/grub.d/10_kfreebsd.in	2010-08-01 00:14:07 +
+++ util/grub.d/10_kfreebsd.in	2010-08-01 00:21:41 +
@@ -74,8 +74,27 @@ EOF
 EOF
   fi
 
+  case "${kfreebsd_fs}" in
+zfs)
+  test -e "${module_dir}/opensolaris.ko"
+  test -e "${module_dir}/zfs.ko"
+
+  printf '%s\n' "${prepare_module_dir_cache}"
+  cat << EOF
+	kfreebsd_module_elf	${module_dir_rel}/opensolaris.ko
+	kfreebsd_module_elf	${module_dir_rel}/zfs.ko
+EOF
+
+  printf '%s\n' "${prepare_boot_cache}"
+  cat << EOF
+	kfreebsd_module		${rel_dirname}/zfs/zpool.cache type=/boot/zfs/zpool.cache
+EOF
+;;
+  esac
+
+
   cat << EOF
-	set kFreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${GRUB_DEVICE}
+	set kFreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${kfreebsd_device}
 	set kFreeBSD.vfs.root.mountfrom.options=rw
 }
 EOF
@@ -105,6 +124,11 @@ while [ "x$list" != "x" ] ; do
 *)  kfreebsd_fs=${GRUB_FS} ;;
   esac
 
+  case ${GRUB_FS} in
+zfs)		kfreebsd_device=$(grub-probe -t label --device ${GRUB_DEVICE}) ;;
+*)			kfreebsd_device=${GRUB_DEVICE} ;;
+  esac
+
   version=`echo $basename | sed -e "s,^[^0-9]*-,,g;s/\.gz$//g"`
   alt_version=`echo $version | sed -e "s,\.old$,,g"`
 

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

2010/7/30, Seth Goldberg :
>
>   You need to ensure that the deivce given isn't degraded.  It's certainly
> possible to boot with a mirrored root with one device degraded.  If you
> choose
> that device for grub-setup, you may fail to write to it or you may succeed,
> but something else may prevent it from being accessible on boot.

I don't think this is the appropiate place for this kind of sanity
check.  Keep in
mind "grub-probe -t device" has many purposes, and for some of them (e.g.
determining the partmap) the ZFS status is irrelevant.

Another codepath (e.g. "grub-probe -t fs") includes this kind of functionality;
it verifies that the requested file will later be readable by GRUB (and IIRC
compares the result).  I think this kind of verification would be
suitable there,
but then, maybe the notion that GRUB can correctly read the file (regardless
on array degradation) is enough.

As for grub-setup, I haven't studied this use case, as I don't currently plan on
implementing it myself, at least not yet (I'm happy with filesystem-agnostic
grub-setup for now).

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

2010/7/30, Seth Goldberg :
>   Ah, ok.  As long as we try the system-installed libzfs.h first, I'm ok
> then.

We do now.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

2010/7/30, Seth Goldberg :
>I saw your commit of these changes.  Why are you delivering a libzfs.h
> and  libnvpair.h?
> I think GRUB should be using the headers that are installed on
> the systems [...]

Unfortunately there are availability problems with libzfs.h and libnvpair.h.  On
FreeBSD they're not installed system-wide.  On OpenSolaris I can't see them
installed either (although in this one I'm probably missing something).

I'm all for switching to system-wide headers, and I completely agree with the
benefits.  If the problem is FreeBSD-specific, I'll report it to
FreeBSD developers
and switch as soon as it is feasible.

Note: part of  is GRUB-specific though (a
declaration for global
libzfs variable handle).

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] ZFS "(dev)/foo@/" pathnames

[Robert Millan]

Same patch with a bit of cleanup, and ChangeLog entry.

2010/7/29, Robert Millan :
> This patch is a proof of concept for solving the ZFS "(dev)/foo@/"
> pathname problem at the lowest possible level: a small change in
> grub_make_system_path_relative_to_its_root() propagates into
> all the places in grub-install and grub-mkconfig that are affected
> by the problem.
>
> It factors some of the code in my previous patch, so that it can be
> reused to extract the zpool filesystem names.
>
> (It still needs some polish like adding function prototypes)
>
> Comments?
>
2010-07-30  Robert Millan  

	* conf/common.rmk (grub_mkrelpath_SOURCES): Add kern/emu/getroot.c
	kern/emu/hostdisk.c kern/err.c kern/misc.c kern/emu/mm.c kern/env.c
	kern/term.c kern/disk.c kern/partition.c.

	* include/grub/emu/misc.h (grub_find_mount_point_from_dir)
	(grub_find_zpool_from_mount_point): New function prototypes.

	* kern/emu/getroot.c (find_mount_point_from_dir): Rename to ...
	(grub_find_mount_point_from_dir): ... this.  Remove `static' attribute.
	(find_root_device_from_libzfs): Split code for finding zpool from
	mount point into ...
	(grub_find_zpool_from_mount_point): ... this.

	* kern/emu/misc.c (grub_make_system_path_relative_to_its_root): When
	requested path is part of a ZFS pool, use
	grub_find_zpool_from_mount_point() to detect its filesystem name,
	and generate a path with `/fsn...@path' syntax.

=== modified file 'conf/common.rmk'
--- conf/common.rmk	2010-07-06 18:27:55 +
+++ conf/common.rmk	2010-07-30 21:11:07 +
@@ -78,7 +78,9 @@ endif
 
 # For grub-mkrelpath.
 bin_UTILITIES += grub-mkrelpath
-grub_mkrelpath_SOURCES = gnulib/progname.c util/grub-mkrelpath.c util/misc.c kern/emu/misc.c
+grub_mkrelpath_SOURCES = gnulib/progname.c util/grub-mkrelpath.c util/misc.c kern/emu/misc.c \
+	kern/emu/getroot.c kern/emu/hostdisk.c kern/err.c kern/misc.c kern/emu/mm.c \
+	kern/env.c kern/term.c kern/disk.c kern/partition.c
 
 bin_UTILITIES += grub-bin2h
 grub_bin2h_SOURCES = gnulib/progname.c util/bin2h.c

=== modified file 'include/grub/emu/misc.h'
--- include/grub/emu/misc.h	2010-07-30 20:01:10 +
+++ include/grub/emu/misc.h	2010-07-30 21:11:07 +
@@ -44,7 +44,14 @@ extern const char *program_name;
 void grub_init_all (void);
 void grub_fini_all (void);
 
-char *grub_make_system_path_relative_to_its_root (const char *path) __attribute__ ((warn_unused_result));
+char *grub_find_mount_point_from_dir (const char *dir)
+  __attribute__ ((warn_unused_result));
+char *grub_find_zpool_from_mount_point (const char *mnt_point,
+	char **poolname, char **poolfs)
+  __attribute__ ((warn_unused_result));
+
+char *grub_make_system_path_relative_to_its_root (const char *path)
+  __attribute__ ((warn_unused_result));
 
 void * EXPORT_FUNC(xmalloc) (grub_size_t size) __attribute__ ((warn_unused_result));
 void * EXPORT_FUNC(xrealloc) (void *ptr, grub_size_t size) __attribute__ ((warn_unused_result));

=== modified file 'kern/emu/getroot.c'
--- kern/emu/getroot.c	2010-07-30 19:43:12 +
+++ kern/emu/getroot.c	2010-07-30 21:11:07 +
@@ -97,8 +97,8 @@ xgetcwd (void)
   return path;
 }
 
-static char *
-find_mount_point_from_dir (const char *dir)
+char *
+grub_find_mount_point_from_dir (const char *dir)
 {
   struct stat st;
   typeof (st.st_dev) fs;
@@ -236,16 +236,12 @@ find_root_device_from_mountinfo (const c
 #if defined(HAVE_LIBZFS) && defined(HAVE_LIBNVPAIR)
 
 /* ZFS has similar problems to those of btrfs (see above).  */
-static char *
-find_root_device_from_libzfs (const char *dir)
+void
+grub_find_zpool_from_mount_point (const char *mnt_point, char **poolname, char **poolfs)
 {
-  char *device = NULL;
-  char *poolname = NULL;
-  char *poolfs = NULL;
-  char *mnt_point;
   char *slash;
 
-  mnt_point = find_mount_point_from_dir (dir);
+  *poolname = *poolfs = NULL;
 
 #ifdef HAVE_GETFSSTAT
   {
@@ -264,7 +260,7 @@ find_root_device_from_libzfs (const char
   if (!strcmp (mnt[i].f_fstypename, "zfs")
 	  && !strcmp (mnt[i].f_mntonname, mnt_point))
 	{
-	  poolname = xstrdup (mnt[i].f_mntfromname);
+	  *poolname = xstrdup (mnt[i].f_mntfromname);
 	  break;
 	}
 
@@ -272,14 +268,33 @@ find_root_device_from_libzfs (const char
   }
 #endif
 
-  if (! poolname)
-return NULL;
+  if (! *poolname)
+return;
 
-  slash = strchr (poolname, '/');
+  slash = strchr (*poolname, '/');
   if (slash)
 {
   *slash = '\0';
-  poolfs = slash + 1;
+  *poolfs = xstrdup (slash + 1);
+}
+  else
+*poolfs = xstrdup ("");
+}
+
+static char *
+find_root_device_from_libzfs (const char *dir)
+{
+  char *device;
+  char *poolname;
+  char *poolfs;
+  char *mnt_point;
+
+  mnt_point = grub_find_mount_point_from_dir (dir);
+  grub_find_zpool_from_mount_point (mnt_point, &poolname, &poolfs);
+  if (! poolname)
+{
+  free (mnt_point);
+  retur

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

This patch adds OpenSolaris support as well, but unfortunately I can't
test it.  I will commit if someone (Seth?) can confirm it works.
=== modified file 'configure.ac'
--- configure.ac	2010-07-30 19:43:12 +
+++ configure.ac	2010-07-30 20:20:43 +
@@ -247,7 +247,7 @@ else
 fi
 
 # Check for functions.
-AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf getfsstat)
+AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf getfsstat getmntany)
 
 # For opendisk() and getrawpartition() on NetBSD.
 # Used in util/deviceiter.c and in util/hostdisk.c.

=== modified file 'kern/emu/getroot.c'
--- kern/emu/getroot.c	2010-07-30 19:43:12 +
+++ kern/emu/getroot.c	2010-07-30 20:24:05 +
@@ -52,6 +52,10 @@
 # include 
 #endif
 
+#ifdef HAVE_GETMNTANY
+# include 
+#endif
+
 #include 
 #include 
 #include 
@@ -247,7 +251,7 @@ find_root_device_from_libzfs (const char
 
   mnt_point = find_mount_point_from_dir (dir);
 
-#ifdef HAVE_GETFSSTAT
+#if defined(HAVE_GETFSSTAT)
   {
 int mnt_count = getfsstat (NULL, 0, MNT_WAIT);
 if (mnt_count == -1)
@@ -270,6 +274,24 @@ find_root_device_from_libzfs (const char
 
 free (mnt);
   }
+#elif defined(HAVE_GETMNTANY)
+  {
+FILE *mnttab = fopen ("/etc/mnttab", "r");
+struct mnttab mp;
+struct mnttab mpref =
+  {
+	.mnt_special = NULL,
+	.mnt_mountp = mnt_point,
+	.mnt_fstype = "zfs",
+	.mnt_mntopts = NULL,
+	.mnt_time = NULL,
+  };
+
+if (getmntany (mnttab, &mp, &mpref) == 0)
+  poolname = xstrdup (mp.mnt_special);
+
+fclose (mnttab);
+  }
 #endif
 
   if (! poolname)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

2010/7/30, Seth Goldberg :
> Don't forget to check the state of the device also.

Can you be more specific?  I notice a "state" integer variable associated
with the pool (none associated with the device), which has a zero-value in
my case (I assume this indicates no error).

What kind of errors can it indicate?  Should we care even?  Keep in mind
this routine is, given a pool that is known to be mounted, merely determining
its underlying devices, not asserting anything about its well-being.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

2010/7/29, Seth Goldberg :
>
>   This code will not handle a mirrored root pool.  See the Solaris
> implementation of vdev_get_physpaths() and zpool_get_config_physpath().

Thanks for the pointer.  I avoid reading libzfs source, but looking at the dump
from nvlist_print(), the problem seems obvious.  I'll adjust it to
support a second
layer.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] ZFS "(dev)/foo@/" pathnames

[Robert Millan]

This patch is a proof of concept for solving the ZFS "(dev)/foo@/"
pathname problem at the lowest possible level: a small change in
grub_make_system_path_relative_to_its_root() propagates into
all the places in grub-install and grub-mkconfig that are affected
by the problem.

It factors some of the code in my previous patch, so that it can be
reused to extract the zpool filesystem names.

(It still needs some polish like adding function prototypes)

Comments?
=== modified file 'conf/common.rmk'
--- conf/common.rmk	2010-07-06 18:27:55 +
+++ conf/common.rmk	2010-07-29 16:06:55 +
@@ -78,7 +78,9 @@
 
 # For grub-mkrelpath.
 bin_UTILITIES += grub-mkrelpath
-grub_mkrelpath_SOURCES = gnulib/progname.c util/grub-mkrelpath.c util/misc.c kern/emu/misc.c
+grub_mkrelpath_SOURCES = gnulib/progname.c util/grub-mkrelpath.c util/misc.c kern/emu/misc.c \
+	kern/emu/getroot.c kern/emu/hostdisk.c kern/err.c kern/misc.c kern/emu/mm.c \
+	kern/env.c kern/term.c kern/disk.c kern/partition.c
 
 bin_UTILITIES += grub-bin2h
 grub_bin2h_SOURCES = gnulib/progname.c util/bin2h.c

=== modified file 'kern/emu/getroot.c'
--- kern/emu/getroot.c	2010-07-29 15:49:20 +
+++ kern/emu/getroot.c	2010-07-29 16:15:27 +
@@ -97,7 +97,7 @@
   return path;
 }
 
-static char *
+char *
 find_mount_point_from_dir (const char *dir)
 {
   struct stat st;
@@ -236,16 +236,12 @@
 #if defined(HAVE_LIBZFS) && defined(HAVE_LIBNVPAIR)
 
 /* ZFS has similar problems to those of btrfs (see above).  */
-static char *
-find_root_device_from_libzfs (const char *dir)
+
+void
+find_zpool_from_mount_point (const char *mnt_point, char **poolname, char **poolfs)
 {
-  char *device;
-  char *poolname = NULL;
-  char *poolfs = NULL;
-  char *mnt_point;
   char *slash;
-
-  mnt_point = find_mount_point_from_dir (dir);
+  *poolname = *poolfs = NULL;
 
 #ifdef HAVE_GETFSSTAT
   {
@@ -264,7 +260,7 @@
   if (!strcmp (mnt[i].f_fstypename, "zfs")
 	  && !strcmp (mnt[i].f_mntonname, mnt_point))
 	{
-	  poolname = xstrdup (mnt[i].f_mntfromname);
+	  *poolname = xstrdup (mnt[i].f_mntfromname);
 	  break;
 	}
 
@@ -272,14 +268,33 @@
   }
 #endif
 
+  if (! *poolname)
+return;
+
+  slash = strchr (*poolname, '/');
+  if (slash)
+{
+  *slash = '\0';
+  *poolfs = xstrdup (slash + 1);
+}
+  else
+*poolfs = xstrdup ("");
+}
+
+static char *
+find_root_device_from_libzfs (const char *dir)
+{
+  char *device;
+  char *poolname;
+  char *poolfs;
+  char *mnt_point;
+
+  mnt_point = find_mount_point_from_dir (dir);
+  find_zpool_from_mount_point (mnt_point, &poolname, &poolfs);
   if (! poolname)
-return NULL;
-
-  slash = strchr (poolname, '/');
-  if (slash)
 {
-  *slash = '\0';
-  poolfs = slash + 1;
+  free (mnt_point);
+  return NULL;
 }
 
   {
@@ -300,6 +315,8 @@
   }
 
   free (poolname);
+  if (poolfs)
+free (poolfs);
 
   return device;
 }

=== modified file 'kern/emu/misc.c'
--- kern/emu/misc.c	2010-06-07 21:41:55 +
+++ kern/emu/misc.c	2010-07-29 16:14:02 +
@@ -225,16 +225,24 @@
 {
   struct stat st;
   char *p, *buf, *buf2, *buf3;
+  char *mnt_point, *poolname = NULL, *poolfs = NULL, *ret;
   uintptr_t offset = 0;
   dev_t num;
   size_t len;
 
   /* canonicalize.  */
   p = canonicalize_file_name (path);
-
   if (p == NULL)
 grub_util_error ("failed to get canonical path of %s", path);
 
+  /* For ZFS sub-pool filesystems, could be extended to others (btrfs?).  */
+  mnt_point = find_mount_point_from_dir (p);
+  if (mnt_point)
+{
+  find_zpool_from_mount_point (mnt_point, &poolname, &poolfs);
+  free (mnt_point);
+}
+
   len = strlen (p) + 1;
   buf = xstrdup (p);
   free (p);
@@ -313,7 +321,15 @@
   len--;
 }
 
-  return buf3;
+  if (poolfs)
+{
+  ret = xasprintf ("/%...@%s", poolfs, buf3);
+  free (buf3);
+}
+  else
+ret = buf3;
+
+  return ret;
 }
 
 #ifdef HAVE_DEVICE_MAPPER

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

New version, with a few bugfixes (find_mount_point_from_dir logic,
use heap allocation, support pools with multiple filesystems).
ChangeLog entry is the same.
=== modified file 'configure.ac'
--- configure.ac	2010-07-04 22:45:14 +
+++ configure.ac	2010-07-29 13:43:00 +
@@ -247,7 +247,7 @@
 fi
 
 # Check for functions.
-AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf)
+AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf getfsstat)
 
 # For grub-mkisofs
 AC_HEADER_MAJOR
@@ -806,6 +806,15 @@
[device_mapper_excuse="need devmapper library"])
 fi
 
+AC_CHECK_LIB([zfs], [libzfs_init],
+ [LDFLAGS="$LDFLAGS -lzfs"
+  AC_DEFINE([HAVE_LIBZFS], [1],
+[Define to 1 if you have the ZFS library.])],)
+AC_CHECK_LIB([nvpair], [nvlist_print],
+ [LDFLAGS="$LDFLAGS -lnvpair"
+  AC_DEFINE([HAVE_LIBNVPAIR], [1],
+[Define to 1 if you have the NVPAIR library.])],)
+
 AC_SUBST(ASFLAGS)
 
 # Output files.

=== added file 'include/grub/util/libnvpair.h'
--- include/grub/util/libnvpair.h	1970-01-01 00:00:00 +
+++ include/grub/util/libnvpair.h	2010-07-29 11:48:47 +
@@ -0,0 +1,31 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2010  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 .
+ */
+
+#ifndef GRUB_LIBNVPAIR_UTIL_HEADER
+#define GRUB_LIBNVPAIR_UTIL_HEADER 1
+
+#include 	/* FILE */
+
+typedef void nvlist_t;
+
+int nvlist_lookup_string (nvlist_t *, const char *, char **);
+int nvlist_lookup_nvlist (nvlist_t *, const char *, nvlist_t **);
+int nvlist_lookup_nvlist_array (nvlist_t *, const char *, nvlist_t ***, unsigned int *);
+void nvlist_print (FILE *, nvlist_t *);
+
+#endif

=== added file 'include/grub/util/libzfs.h'
--- include/grub/util/libzfs.h	1970-01-01 00:00:00 +
+++ include/grub/util/libzfs.h	2010-07-29 11:48:36 +
@@ -0,0 +1,39 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2010  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 .
+ */
+
+#ifndef GRUB_LIBZFS_UTIL_HEADER
+#define GRUB_LIBZFS_UTIL_HEADER 1
+
+#include 
+
+typedef void libzfs_handle_t;
+typedef void zpool_handle_t;
+
+extern libzfs_handle_t *libzfs_init ();
+extern void libzfs_fini (libzfs_handle_t *);
+
+extern zpool_handle_t *zpool_open (libzfs_handle_t *, const char *);
+extern void zpool_close (zpool_handle_t *);
+
+extern int zpool_get_physpath (zpool_handle_t *, const char *);
+
+extern nvlist_t *zpool_get_config (zpool_handle_t *, nvlist_t **);
+
+extern libzfs_handle_t *libzfs_handle;
+
+#endif

=== modified file 'include/grub/util/misc.h'
--- include/grub/util/misc.h	2010-04-27 15:25:12 +
+++ include/grub/util/misc.h	2010-07-29 10:34:03 +
@@ -59,5 +59,6 @@
 char *canonicalize_file_name (const char *path);
 
 void grub_util_init_nls (void);
+void grub_util_init_libzfs (void);
 
 #endif /* ! GRUB_UTIL_MISC_HEADER */

=== modified file 'kern/emu/getroot.c'
--- kern/emu/getroot.c	2010-07-20 22:09:45 +
+++ kern/emu/getroot.c	2010-07-29 15:30:35 +
@@ -20,11 +20,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +43,15 @@
 # include 
 #endif
 
+#if defined(HAVE_LIBZFS) && defined(HAVE_LIBNVPAIR)
+# include 
+# include 
+#endif
+
+#ifdef HAVE_GETFSSTAT
+# include 
+#endif
+
 #include 
 #include 
 #include 
@@ -86,6 +97,62 @@
   return path;
 }
 
+static char *
+find_mount_point_from_dir (const char *dir)
+{
+  struct stat st;
+  typeof (st.st_dev) fs;
+  char *prev, *next, *slash, *statdir;
+
+  if (stat (dir, &st) == -1)
+error (1, errno, "stat (%s)", dir);
+
+  fs = st.st_dev;
+
+  prev = xstrdup (dir);
+
+  while (1

[PATCH] Enable `grub-probe -t device' resolution on ZFS

[Robert Millan]

Please test / comment / etc.
2010-07-29  Robert Millan  

	Enable `grub-probe -t device' resolution on ZFS.

	* configure.ac: Check for getfsstat(), libzfs and libnvpair.
	* include/grub/util/libnvpair.h: New file.
	* include/grub/util/libzfs.h: New file.

	* kern/emu/getroot.c: Include `' and `'.
	[HAVE_LIBZFS && HAVE_LIBNVPAIR]: Include `' and
	`'.
	[HAVE_GETFSSTAT]: Include `'.

	(find_mount_point_from_dir): New static function.
	[HAVE_LIBZFS && HAVE_LIBNVPAIR] (find_root_device_from_libzfs): New
	function.
	[HAVE_LIBZFS && HAVE_LIBNVPAIR] (grub_guess_root_device): Use
	find_root_device_from_libzfs() before ressorting to find_root_device().

	* include/grub/util/misc.h (grub_util_init_libzfs): New function
	prototype.
	* util/misc.c: Include `'.
	(grub_util_init_libzfs): New function.
	[HAVE_LIBZFS] (libzfs_handle): New global variable.
	[HAVE_LIBZFS] (fini_libzfs): New static function.
	(grub_util_init_libzfs): New function.
	* util/grub-probe.c (main): Call grub_util_init_libzfs().

=== modified file 'configure.ac'
--- configure.ac	2010-07-04 22:45:14 +
+++ configure.ac	2010-07-29 13:43:00 +
@@ -247,7 +247,7 @@
 fi
 
 # Check for functions.
-AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf)
+AC_CHECK_FUNCS(posix_memalign memalign asprintf vasprintf getfsstat)
 
 # For grub-mkisofs
 AC_HEADER_MAJOR
@@ -806,6 +806,15 @@
[device_mapper_excuse="need devmapper library"])
 fi
 
+AC_CHECK_LIB([zfs], [libzfs_init],
+ [LDFLAGS="$LDFLAGS -lzfs"
+  AC_DEFINE([HAVE_LIBZFS], [1],
+[Define to 1 if you have the ZFS library.])],)
+AC_CHECK_LIB([nvpair], [nvlist_print],
+ [LDFLAGS="$LDFLAGS -lnvpair"
+  AC_DEFINE([HAVE_LIBNVPAIR], [1],
+[Define to 1 if you have the NVPAIR library.])],)
+
 AC_SUBST(ASFLAGS)
 
 # Output files.

=== added file 'include/grub/util/libnvpair.h'
--- include/grub/util/libnvpair.h	1970-01-01 00:00:00 +
+++ include/grub/util/libnvpair.h	2010-07-29 11:48:47 +
@@ -0,0 +1,31 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2010  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/>.
+ */
+
+#ifndef GRUB_LIBNVPAIR_UTIL_HEADER
+#define GRUB_LIBNVPAIR_UTIL_HEADER 1
+
+#include 	/* FILE */
+
+typedef void nvlist_t;
+
+int nvlist_lookup_string (nvlist_t *, const char *, char **);
+int nvlist_lookup_nvlist (nvlist_t *, const char *, nvlist_t **);
+int nvlist_lookup_nvlist_array (nvlist_t *, const char *, nvlist_t ***, unsigned int *);
+void nvlist_print (FILE *, nvlist_t *);
+
+#endif

=== added file 'include/grub/util/libzfs.h'
--- include/grub/util/libzfs.h	1970-01-01 00:00:00 +
+++ include/grub/util/libzfs.h	2010-07-29 11:48:36 +
@@ -0,0 +1,39 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2010  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/>.
+ */
+
+#ifndef GRUB_LIBZFS_UTIL_HEADER
+#define GRUB_LIBZFS_UTIL_HEADER 1
+
+#include 
+
+typedef void libzfs_handle_t;
+typedef void zpool_handle_t;
+
+extern libzfs_handle_t *libzfs_init ();
+extern void libzfs_fini (libzfs_handle_t *);
+
+extern zpool_handle_t *zpool_open (libzfs_handle_t *, const char *);
+extern void zpool_close (zpool_handle_t *);
+
+extern int zpool_get_physpath (zpool_handle_t *, const char *);
+
+extern nvlist_t *zpool_get_config (zpool_handle_t *, nvlist_t **);
+
+extern libzfs_handle_t *libzfs_handle;
+
+#endif

=== modified file 'include/grub/util/misc.h'
--- include/grub/util/misc.h	2010-04-27 15:25:12 +
+++ include/grub/util/misc.h	2010-07-29 10:34:03 +
@@ -59,

Re: libzfs

[Robert Millan]

2010/7/28, Tuco :
> I was already on this. I made some progress and have libzfs now,
> expect zpool/zfs to follow soon. Here is my patch if you want to build
> libzfs yourself:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=libzfs.diff;att=1;bug=590639

Very nice. Thanks.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS on Debian GNU/kFreeBSD

[Robert Millan]

2010/7/28, Vladimir 'φ-coder/phcoder' Serbinenko :
> I don't think that the design needs changes but I'm open to discussion.

My proposal seemed like an improvement in design, which I wanted to do before
dealing with grub-install/grub-mkconfig. But obviously I've missed some details,
and things aren't as nice as they appear at first.

So I'll move on to next step now. Thanks for the explanation :-)

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS on Debian GNU/kFreeBSD

[Robert Millan]

The problem I see with current zfs.mod is that it integrates with GRUB using
the "filesystem model", i.e. each pool has one
backend (the storage device) and one frontend (the filesystem).

But ZFS is different in both ends: each pool can use N storage devices
and provide M filesystems. In the current representation this yields
two problems
for GRUB:

 - zpools where more than one device is essential (i.e. not just
mirror like RAID1)
   aren't accessible.

 - To allow more more than one filesystem in a zpool, filesystems are
selected in
   a special manner, e.g.:
   (hd0)/@/
   (hd0)/foo@/
   This collides with an assumption consistently made by GRUB utilities
   and scripts: that you can construct a GRUB path by combining the result
   of make_path_relative_to_its_root() (known at install time) with the device
   that contains this filesystem (usually known at run time).

My impression is representing ZFS as a filesystem is doable, but not
the best fit.
ZFS is much more like what GRUB calls an "abstraction" (RAID or LVM). In fact
if you take LVM interface:

grub> ls
(hd0) (hd1)
grub> insmod lvm
grub> ls
(hd0) (hd1) (foo) (bar)

the only difference for ZFS is that (foo) and (bar) are provided directly as
filesystems (like pxe.mod does) instead of block devices for GRUB to probe.

So my intention is to readjust zfs.mod to follow this interface. Aside
from enabling
multi-device pools, this will also make it much easier to support ZFS
in the install
utilities and scripts later.

Comments / objections / suggestions?

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS on Debian GNU/kFreeBSD

[Robert Millan]

2010/7/21 Tuco :
> Is this a known problem? Should I investigate? Can you give some guideline?

If you want to help, you could have a look at porting libzfs over to
GNU/kFreeBSD.
It's likely that GRUB will need it, and in either case the Debian
folks definitely will.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS on Debian GNU/kFreeBSD

[Robert Millan]

2010/7/22 Seth Goldberg 
>> I guess the API exported by libzfs can serve for this?  But first, I
>> have some concern about zfs.mod, I'll write a detailed mail about that
>> later.
>
>  That's how I'm implementing it, though libzfs is technically an uncommitted 
> interface.

What are you currently implementing? I just want to make sure I don't
duplicate existing work.

>> Uhm this sounds wrong, grub-setup isn't meant to handle filesystems
>> (it does something like you describe for RAID1, but only because it
>> can rely on the storage backend being 1:1).
>
>  [...] To be truly fault-tolerant, if we're booting from a zfs pool, there 
> must be an embedded config file that searches for a (non-faulted) root device 
> from the pool's mirrors as well.  Separate invocations for each device in the 
> root pool mirror are fine, though.

Ah, I understand you now. You want to take advantage of ZFS' fault-tollerancy
for boot blocks. I'm not sure this would make sense, because we have to give
up at some point (e.g. boot.img can't benefit from this), so we're just moving
the line. In any case, I just want the basic functionality to work and it's not
currently in my plan to implement this (sorry ;-)).

>  BTW, I've run into a similar issue (comparing major/minors) in updating 
> grub-probe to deal with zfs -- grub_make_system_path_relative_to_its_root() 
> compares st_dev with the st_dev's of each path component.  This won't work on 
> ZFS either because GRUB files are stored in the top-level filesystem and 
> because the root filesystem (for the purposes of GRUB2's $root) is a 
> different filesystem than the top-level filesystem.  GRUB2 was never designed 
> to deal with this kind of disparity (even at the RAID level).

Can you map st_dev to zpool name (and later to zpool devices) using libzfs?

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS on Debian GNU/kFreeBSD

[Robert Millan]

Hi,

This has been on my radar for a while now, I'll have a look at it
(today I start my vacation and have some spare time (but don't hold
your breath...)).

2010/7/21, Seth Goldberg :
> The main problem is that the st_dev that you'll get from a call to stat() of
> a file on a ZFS filesystem won't match the major/minor of any device in /dev
> (at least on Solaris).  You have to look deeper to figure out the pool name,
> then query the pool to figure out its devices.

I guess the API exported by libzfs can serve for this?  But first, I
have some concern about zfs.mod, I'll write a detailed mail about that
later.

> And if you're REALLY good,
> you'd invoke grub-setup for each member of a root pool mirror :).

Uhm this sounds wrong, grub-setup isn't meant to handle filesystems
(it does something like you describe for RAID1, but only because it
can rely on the storage backend being 1:1).

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub2 and hybrid MBR booting

[Robert Millan]

2010/7/3, Vladimir 'φ-coder/phcoder' Serbinenko :
> Using GUID in GPT to locate the embedded zone would be good but it has
> nothing to do with this standard. Robert made some work in this
> direction but never finished (he wrote MBR but not some required changes
> to diskboot.img) and nobody picked up his work.

If you refer to my "GPT MBR", it was mostly a proof of concept.  I
didn't really have plans for it.  I tend to think setting things up at
install time is more suitable than doing a search every time (and 440
bytes don't give a lot of flexibility...).

Also, HPA persuaded me that since he was going to work on standarising
his handover protocol, and my "GPT MBR" experiment overlapped with it,
I would obselete it to avoid conflict.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

hybrid DOS/GPT and BIOS Boot Partition

[Robert Millan]

Hi,

Sorry for breaking the thread, but I just stepped in because I
participated in the standarisation of the BIOS Boot Partition
mechanism, and in early discussions about this hybrid DOS/GPT protocol
which led to the standard being discussed, and I want to clarify
something.

GRUB implements the BIOS Boot Partition, and SYSLINUX implements the
hybrid DOS/GPT protocol [1].  It is too easy to get the impression
that both protocols are somehow overlapping, or that they are
different ways to solve the same problem. This is NOT TRUE.  They're
actually two solutions for two very different problems.

The first problem is, if we have more than one OS, how do we select
which one to boot?

GRUB implements the obvious solution (ask the user!).  But in the old
days, MSDOS implemented an awkward scheme [2], designed with
proprietary boot protocols in mind: multiple bootloaders can be
installed; each bootloader can "chainload" another bootloader, so that
even if the boot protocols are secret, it is possible to install more
than one OS in the same PC.  I believe current MBR used with SYSLINUX
goes a step further and allows user to select an entry, but still with
the constraints of 440 bytes, the user interface becomes very
unfriendly and limited.

Note that GRUB implements part of this "chainload" mechanism as well,
for the sake of compatibility with Microsoft Windows.  It ignores the
"bootable flag", and allows user to chainload to a partition using
this protocol, on request.  With GPT, there's currently no point in
implementing it, since Windows doesn't (yet?) follow this scheme [3].

The second problem is, 440 bytes is such a small space, can we do
everything we want with it?  Or can we have a bigger MBR?  Can we
increase the amount of unmanaged code?

With MSDOS labels, GRUB solved this by using the post-MBR gap as an
extension of the MBR. The idea is that this area is unmanaged, as in,
whoever owns the MBR also takes ownership of those sectors, and
there's no mechanism to have more than one such area (nor any need for
such mechanism).  SYSLINUX solved this by relying on poor, limited MBR
as described earlier.

When it comes to GPT, GRUB solved this by using a new instance of the
same unmanaged extension of the MBR: the BIOS Boot Partition.  It's
effectively the same thing, except that with it being a partition,
people tend to think it somehow plays a role in the MSDOS partition
handover protocol, and mix things up.

As described earlier in this list, SYSLINUX "solved" this problem by
implementing a poor, limited MBR which skips parts of the GPT spec
(CRC verification IIRC) in order to squeeze their code in 440 bytes.
There's NO NEED to restrict for this kind of constraint.  I would
advice SYSLINUX developers to take advantage of the BIOS Boot
Partition in order to fit whole GPT parser.

I think this makes clear that both protocols aren't exclusive to each
other, it just happens that they solve different problems, with GRUB
and SYSLINUX only interested in one of each, and already having a
solution (or simply not caring) about the other.

[1] I refer to it in generic terms, because the implementation in
SYSLINUX pre-dates the standard; based on my previous discussion with
HPA, I believe he's been involved in the development of this standard,
and the result is modeled after his implementation.

[2] Partitions have a so-called "bootable flag". MBR probes for
bootable flags and automatically selects a partition based on them.

[3] Apparently, Microsoft drank the EFI kool-aid and still hasn't
figured out that one can actually boot from a GPT label on a PC/BIOS
system.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

freeze announcement

[Robert Millan]

Hi,

trunk repository is now frozen in preparation for GRUB 1.98, which will be
released soon, most likely this month.

I leave Vladimir in charge of this freeze process.  Please ask him for
approval when in doubt.

-- 
Robert Millan

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


signature.asc
Description: Digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: PlayStation 3 liberated

[Robert Millan]

On Thu, Jan 28, 2010 at 03:25:49PM -0500, Gregg C Levine wrote:
> Hello!
> Not quite correct.
> The PS3 runs the Cell processor, who is a descendant of the PowerPC.

In a quite similar sense as modern x86 CPUs are descendants of the Intel 80386.
You can run standard PowerPC machine code on this Cell.

> Robert where did you find this bit of news?

IRC.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: PlayStation 3 liberated

[Robert Millan]

On Thu, Jan 28, 2010 at 09:39:59PM +0100, Christian Auby wrote:
> Running Linux on PS3 was easy already at launch, as the central CPU is a
> standard PowerPC and "other OS" was officially supported.

That's not the PS3, it's a restricted environment.

> The issue isn't as much as getting Grub to work, but finding an exploit
> that works without hardware interaction.

Well that would be very interesing indeed, but in GRUB project we're generally
concerned about improving GRUB...

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot2] Tagged multiboot2 header

[Robert Millan]

On Thu, Jan 21, 2010 at 12:49:55AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> +...@node Header tags
> +...@subsection General tag structure
> +Tags constitutes a buffer of structures immediately following each other.
> +Every structure has following format:
> +
> +...@example
> +...@group
> ++---+
> +0   | type  |
> +4   | size  |
> +8-11| optional  |
> ++---+
> +...@end group
> +...@end example

This looks fine.  Please go ahead with the proposed new layout.

As for the addition of new fields for architecture / endianess, I wonder
if it makes sense to continue supporting aout-kludge in Multiboot 2.  It
seems that all of the projects interested in Multiboot use ELF natively
themselves and shouldn't have trouble with it, whereas projects that don't
use ELF are almost invariably proprietary OS and never showed any interest
in Multiboot.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

PlayStation 3 liberated

[Robert Millan]

Maybe you heard the recent news that the handcuffware in Sony PS3 has been
recently broken:

  http://geohotps3.blogspot.com/2010/01/heres-your-silver-platter.html

This is somewhat relevant to GRUB:  It is now possible to port free operating
systems to the PS3, but they will need a bootloader.  And GRUB already has
two key pieces:

  - PowerPC support on other platforms

  - Operation mode that starts GRUB as a userland process (grub-emu)

With the PS3 exploit, it is possible to get full access to physical memory.  My
understanding of PowerPC architecture is very limited, but I believe this would
allow grub-emu to:

  - Rise privilege level

  - Disable interrupts

  - Setup 1:1 MMU map

Thereby obtaining full control of the hardware.

I think it would be feasible to make a GSoC project for this, or at least the
beginning of it.  Let me know if you'd like to be a mentor this summer.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

PXE directory listing incorrectly reported as "success"

[Robert Millan]

Hi,

It appears that directory listing isn't supported by TFTP protocol (so
says our wiki).

Our pxe.c implements grub_pxefs_dir() as a dummy stub that returns
GRUB_ERR_NONE.  This is obviously wrong, as it prevents the user from
noticing that there was a problem, and silently reports an "empty"
directory.  Instead, it should call grub_error ().

Unfortunately, kern/fs.c relies on grub_pxefs_dir() returning
GRUB_ERR_NONE in order to consider probing to be succesful.  If pxe
returned an error, it wouldn't be considered a valid filesystem by
the kernel.

So I'm wondering, what would be a good solution to this?  We could add
a proper probe() function and switch all filesystems to it, but only
for the benefit of pxe it seems a bit overkill.

Does someone have a better idea?

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: On gratuitous modularization

[Robert Millan]

On Mon, Jan 25, 2010 at 09:13:11PM +0100, Christian Franke wrote:
>
> The module ata_pthru.mod exists only to keep ata.mod small, see:
> http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00091.html

I see.  Thanks for pointing this out.

> Keeping the ata.mod specific pass-through function separate from  
> hdparm.mod was intentional. Merging this function into hdparm.mod would  
> only make sense if ata.mod will the only ATA access module with  
> pass-through functionality in the future.

Note that linking ata_pthru.c into hdparm.mod doesn't prevent this code from
being linked into other modules if/when the need arises.

But right now, it's only used by hdparm.  I see little justification in
having a separate module in this situation.  I'm inclined to merge it.

> BTW: I agree that using a global function pointer  
> 'grub_disk_ata_pass_through' is a hack. A cleaner design would be  
> possible with a grub_disk_dev.ioctl(.) call.

The problem I see with 'grub_disk_ata_pass_through' is that it shouldn't be
in kernel.  The interface itself is less relevant IMO.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Changes in GRUB help

[Robert Millan]

On Sun, Jan 24, 2010 at 11:15:11PM +0530, KESHAV P.R. wrote:
> * Add support for Fedora's initramfs (semi-patch attached) - name like
> initramfs-2.6.31.9-174.fc12.x86_64.img .

Your patch looks like it ought to work;  have you tested it?

> Please document grub-extras in grub.enbug.org website.

You can do that if you lile; it's a wiki.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

On gratuitous modularization

[Robert Millan]

Please be careful when adding modules.  I see that too often new modules
are added without any real need to host this code separately.

There are many examples where this happened.  I just noticed:

commands/hdparm.c:  struct grub_disk_ata_pass_through_parms apt;
commands/hdparm.c:  if (grub_disk_ata_pass_through (disk, &apt))
commands/hdparm.c:  struct grub_disk_ata_pass_through_parms apt;
commands/hdparm.c:  if (grub_disk_ata_pass_through (disk, &apt))
commands/hdparm.c:  struct grub_disk_ata_pass_through_parms apt;
commands/hdparm.c:  if (grub_disk_ata_pass_through (disk, &apt))
commands/hdparm.c:  if (! grub_disk_ata_pass_through)
disk/ata_pthru.c:  struct grub_disk_ata_pass_through_parms 
*parms)
disk/ata_pthru.c:  grub_disk_ata_pass_through = grub_ata_pass_through;
disk/ata_pthru.c:  if (grub_disk_ata_pass_through == grub_ata_pass_through)
disk/ata_pthru.c:grub_disk_ata_pass_through = NULL;
include/grub/disk.h:struct grub_disk_ata_pass_through_parms
include/grub/disk.h:extern grub_err_t (* 
EXPORT_VAR(grub_disk_ata_pass_through)) (grub_disk_t,
include/grub/disk.h:   struct grub_disk_ata_pass_through_parms *);
kern/disk.c:grub_err_t (* grub_disk_ata_pass_through) (grub_disk_t,
kern/disk.c:struct grub_disk_ata_pass_through_parms *);

this seems unnecessary.  ata_pthru is very small.  If it's only used by hdparm,
why not just merge it?  This also avoids the additional code in kernel.

A similar example is aout.mod, which is just a helper for loaders of *BSD
kernels.

Please also see Okuji's article on this subject:

  http://grub.enbug.org/OnSplittingModules

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] [RESEND] GRUB script lexer rewrite using flex

[Robert Millan]

On Sat, Jan 23, 2010 at 10:39:47AM +0530, BVK Chaitanya wrote:
> Attached is the updated patch with changes as per review comments (by
> phcoder).  With these changes sh.mod file size is reduced from 38K to
> 28K :-)

Very nice!  But I thought the flex-based rewrite would involve some size
increase.  Has this changed, or I'm missing something?

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] make 'sleep --interruptible 0' interruptible

[Robert Millan]

On Wed, Jan 20, 2010 at 10:50:25PM +0100, Szymon Janc wrote:
> 
> > On the PC architecture, you can't check for Escape without having some
> > kind of delay.  Only modifier keys can be checked instantaneously.
> > 
> > http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/annot
> > ate/head%3A/debian/patches/951_sleep_shift.diff has an alternative patch
> >  which may be helpful, and links to previous discussions.
> 
> Hmm now I see that this trivial case is no so trivial at all. Yet it would be 
> nice to have unified sollution for GRUB_HIDDEN_TIMEOUT.
> 
> Maybe extra command especially for user interactivity? It would combine 
> functionality of sleep and keystatus without need to worry about restrictions 
> mentioned in previous discussion.
> I know that this is somewhat redundant but it looks like it would be very 
> hard 
> for 'clean' solution.

We're going to migrate to hardware drivers (at_keyboard / usb_keyboard) in the
near future.  I guess this resolves the stated problem, so I wouldn't invest a
lot of effort in finding other solutions to it.

If you want to help with polishing at_keyboard, usb_keyboard and the USB stack,
that'd be most welcome.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] nested partitions

[Robert Millan]

On Mon, Jan 25, 2010 at 08:31:35AM +0100, Robert Millan wrote:
> When you hide complexity from the user, the user doesn't generally care or
> want to understand what this involves.  When we accept "(hd0,1)" from the
> user, it implies we know what's the partition label in hd0, but reality is
> that we're just guessing.  User, however, will expect things to "just work",
> and if they fail will blame it on GRUB.  This is what I refer to when I
> speak of burden.

Btw, I forgot to mention that initially GRUB took a very different approach:
labels were considered arch-specific, so on i386-pc you only had msdos labels,
on powerpc-ieee1275 you only had apple labels, etc.  With this approach, the
probing problem doesn't exist.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot2] Tagged multiboot2 header

[Robert Millan]

On Thu, Jan 21, 2010 at 12:49:55AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> +...@item architecture
> +The field @samp{architecture} specifies the Central Processing Unit
> +Instruction Set Architecture. Since @samp{magic} isn't a palindrome
> +it already specifies the endianness ISAs differing only in endianness
> +recieve the same ID. @samp{0} means 32-bit (protected) mode of i386.

ELF specifies architecture and endianess; can we use that?

We already rely on ELF header for other things, but they have counterparts
in aout-kludge fields.  So I guess this opens the question on whether we want
to continue supporting aout-kludge for Multiboot 2 or ditch it entirely.

Thoughts?

Btw, would be better if the addition of tagged fields itself would be separate
from other things.  It speeds up the process and helps understanding the
changes (both now and afterwards when looking at Bazaar history).

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Multiboot video support

[Robert Millan]

On Mon, Jan 25, 2010 at 12:29:41AM +0100, Michal Suchanek wrote:
> 2010/1/24 Vladimir 'φ-coder/phcoder' Serbinenko :
> > There is a big difference between orientation and the rest of fields:
> > orientation is configuration variable whereas other fields are a
> > hardware information. [...]
> 
> Unlike font, background image or logos the orientation of the screen
> is hardware property.

I think nobody wants font, background image or logos to be part of the
transferred data, as it's clearly overkill.

As for orientation of a screen, I don't know if you'd call this hardware
information, but if a screen is physically rotated, it's clearly not
software.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] nested partitions

[Robert Millan]

On Sun, Jan 24, 2010 at 06:38:40PM -0600, Bruce Dubbs wrote:
> I like this idea, but wonder if it would be useful to have something  
> like (grub drive, partition type, filesystem type) for each partition to  
> consider.  For example:
>
> (hd0,gpt1,ext2)

Filesystems have essentially the same problem, but collision is much less
likely, and "nested filesystems" are already handled like an oddity (via
loop command) for which responsibility is left to the user.

>> With this approach, the burden is no longer in GRUB.  Then I don't care
>> how weird disk layouts can become, because GRUB doesn't have to probe
>> them.  We can even support things like this if it makes users happy:
>>
>>   (hd0,bsd2,msdos1,sun1,apple4,msdos1)
>
> Can you translate that.  I don't understand.

When you hide complexity from the user, the user doesn't generally care or
want to understand what this involves.  When we accept "(hd0,1)" from the
user, it implies we know what's the partition label in hd0, but reality is
that we're just guessing.  User, however, will expect things to "just work",
and if they fail will blame it on GRUB.  This is what I refer to when I
speak of burden.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] nested partitions

[Robert Millan]

On Sun, Jan 24, 2010 at 10:20:49PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> > With this approach, the burden is no longer in GRUB.  Then I don't care
> > how weird disk layouts can become, because GRUB doesn't have to probe
> > them.  
> We still have to for partition_iterate.

partition_iterate itself is no problem.  I mean, even probing itself isn't,
as long as we don't promise that any of it actually works.  Accessing unknown
partition label as "hd0,1" implies we know the label type via probing;  other
facilities that use probing don't necessarily imply that.  For example, GRUB
could do:

  grub> ls (hd0)
  Possible msdos label: 1 2 3
  Possible gpt label: 1 2

etc.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub payload fails on coreboot

[Robert Millan]

On Fri, Jan 22, 2010 at 04:39:47PM +0100, Andreas B. Mundt wrote:
> Hi,
> 
> Vladimir 'Ï-coder/phcoder' Serbinenko wrote:
> 
> > Is your coreboot compiled with multiboot support?
> 
> I guess so, from the serial log:
> 
> ACPI: done.
> ACPI tables: 4677 bytes.
> 
> Multiboot Information structure has been written.
> ^
> Adding CBMEM entry as no. 5
> Writing high table forward entry at 0x0500
> Wrote coreboot table at: 0500 - 0518  checksum 5fde
> New low_table_end: 0x0518
> Now going to write high coreboot table at 0xbfffe000
> rom_table_end = 0xbfffe000

Did you try with testing coreboot+GRUB on qemu?

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: comment about grub_error, capitalisation and one commit

[Robert Millan]

On Wed, Jan 20, 2010 at 11:37:38PM +, Carles Pina i Estany wrote:
> a) if someone has a better idea to avoid this mistake again than paying
> attention I can implement.
> b) Robert: I reverse it, fine?

I just removed capitalization of error strings in the whole file.  A
generic check would be nice.  If you'd like to implement it, I think it
should be possible to verify this entirely in build time.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] nested partitions

[Robert Millan]

On Fri, Jan 22, 2010 at 10:43:09AM -0800, Seth Goldberg wrote:
>
>   The UEFI specification specifies support for nested MSDOS labels (MSDOS 
> labels that include partitions in which another MSDOS partition table can 
> be nested).  This is not talking just about extended partitions, but  
> about the ability to arbitrarily nest MSDOS partition tables.  I can't 
> point you to a specific implementation that uses that functionality, but 
> the fact that it's specified should be enough to allow us to be flexible 
> here.  Why limit the nesting if architecturally it's not a problem to 
> support (as Vladimir's existing implementation already supports arbitrary 
> nesting).

Note that it is very easy for Intel to specify and implement that: in their
world there's only one partition label type (plus another one which is
backward compatible with the first).

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] nested partitions

[Robert Millan]

On Fri, Jan 22, 2010 at 07:03:21PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> > This can be done by extending "has_partitions" to be set to "yes" in those
> > specific partition types.  The implementation should be the least intrusive
> > possible, taking into account that this kind of situations are an oddity
> > rather than the norm.
> >
> >   
> Partition types are easily screwed. Why not just check for the presence
> of the label?

I have a feeling I already explained this somewhere.  Doesn't seem to be in
this thread, maybe on IRC?  Anyway, it won't hurt to ellaborate on it...

First of all, the whole label type proliferation problem is inherently
impossible to resolve by technical means.  Labels overlap each other,
they can coexist without any garantee that the user expects them to be
there at all or include meaningful data.

You *can't* reliably check for any partition label.  Partitions include a
set of arbitrary data.  Sometimes they will match one of the probes,
sometimes more than one.  GRUB has no way of determining if any of those
matches is correct, because only the *user* knows that.

This is a problem we already have, but it is bearable because worst case is
detecting a label where there isn't supposed to be one, or detecting a label
type different than the one user expected.  With this proposal, two things
happen:

  - has_partitions stops being useful.  When in top level, it's relatively
easy to make assumptions about the existance of partitions.  If it is
a hard disk, chances are it'll be partitioned;  If it's a CDROM, chances
are it isn't (this is an unreliable check, but its purpose is to paliate
the effect of using another unreliable check, so overall it's a gain).

  - False positives can be repeated ad nauseam.  It can even be exploited to
force GRUB into reading several GiBs of data, effectively DoSing it.

If you look around, all approaches at dealing with this imply appliing enough
limit to keep it sane.  For example, they limit the number of label types, the
recursion depth, etc.

If we're going to support *all* possible combinations, I'd rather revisit
and solve our detection problem first.  Not by actually making detection
reliable (that's impossible), but by stop pretending GRUB can hide this mess
from the user.  When GRUB performs guesswork, sooner or later it'll get it
wrong anyway, and the fact that it was guessing creates a false expectation
that it somehow knows the correct result.  Users end up blaming GRUB for that.

So instead of supporting things like:

  (hd0,1)
  (hd0,2)

  (ambigous; what does this mean in an hybrid MSDOS/GPT ?  What about other
  hybrid schemes?  GRUB can't tell!)

... we could support:

  (hd0,msdos1)
  (hd0,gpt1)
  (hd0,msdos2)
  (hd0,gpt2)

whose meaning is pretty clear.  Then the user can nest as much as they like,
but they will also have to deal with the problem of identifiing the labels.

Minix: (hd0,msdos1,msdos1)

Solaris: (hd0,msdos2,sun1)

*BSD: (hd0,msdos3,bsd1)

With this approach, the burden is no longer in GRUB.  Then I don't care
how weird disk layouts can become, because GRUB doesn't have to probe
them.  We can even support things like this if it makes users happy:

  (hd0,bsd2,msdos1,sun1,apple4,msdos1)

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Multiboot video support

[Robert Millan]

On Wed, Jan 20, 2010 at 12:43:38PM +0100, Michal Suchanek wrote:
> Shouldn't the structure also include the framebuffer orientation?
> 
> If framebuffer transform support is included in grub it would be good
> to pass the orientation the user specified for grub graphics output to
> the OS so that the OS console output is displayed the same way
> automatically.

Makes sense.  Can you draft a proposal?

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Announcing GRUB 1.97.2

[Robert Millan]

On Sun, Jan 24, 2010 at 07:36:51PM +0100, Robert Millan wrote:
>   - A number of header declarations had their copyright/license headers
> missing.  They had been imported in GRUB Legacy many years ago, and
> recently found their way into the 1.97 release.

The files in question were imported by Bean in early 2008.  He apparently
relied on the existing license header being correct and replaced it with
GPLv3 one.  It's not his fault that it wasn't, but he should have notified it.

Please remember to always check with the maintainers [1] before importing code
from GRUB Legacy (or any other source).

[1] Well, that'd be with me, since Pavel resigned and Marco and Okuji are not
    active anymore...

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Announcing GRUB 1.97.2

[Robert Millan]

Hi,

GNU GRUB version 1.97.2 has been released.

GRUB, also known as the GRand Unified Bootloader, is a modular, portable
bootloader that supports a number of platforms, including standard BIOS-based
PCs, IEEE-1275 platforms (such as the OLPC and some PowerPC/Sparc64 hardware)
and coreboot, the free (as in freedom) pre-boot initialization framework.

  <http://www.gnu.org/software/grub/>

This is a bug-fix release for a number of problems (excerpt from NEWS file
is attached) that were found after GRUB 1.97.1 was released.

Most importantly, it fixes two problems with header files of BSD origin:

  - A number of header declarations had their copyright/license headers
missing.  They had been imported in GRUB Legacy many years ago, and
recently found their way into the 1.97 release.  Vladimir Serbinenko
spotted this problem and fixed it by tracking down the header origin
and adding the missing copyright and license.

  - In one of those cases (the bootinfo structure, used for booting the kernel
of FreeBSD), the original license was the unrevised BSD license with
advertisement clause [*], which made it impossible for 3rd parties to
comply with GPL requirements and legally distribute GRUB.  Again,
Vladimir fixed this by rewriting the bootinfo struct declaration.

[*] http://www.gnu.org/philosophy/bsd.html

We apologize for the inconvenience; the GRUB project is very strict with
license verification, even more with GRUB 2 than with GRUB Legacy, but in
this case the problem was introduced very early in GRUB Legacy history.

To the best of our knowledge, all issues are resolved now, but if you were to
find any other problem, please don't hesitate to contact grub-devel or mail
me directly about it.

A source tarball for the new release can be found at:

  http://alpha.gnu.org/gnu/grub/grub-1.97.2.tar.gz

and its GPG detached signature [*]:

  http://alpha.gnu.org/gnu/grub/grub-1.97.2.tar.gz.sig

[*] You can use either of the above signature file to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify grub-1.97.2.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys DEA2C38E

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.61
  Ruby 1.8.7

GCC 4.4 is the recommended version for building it, although any version
starting with 4.1.3 is supported in this release.

-- 
Robert Millan

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

* Fix a few 4 GiB limits.

* Fix license problems with a few BSD headers.

* Lots of misc bugfixes.


signature.asc
Description: Digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] nested partitions

[Robert Millan]

I haven't checked the specific details, but I think this approach is fine IF
we only recurse for partition types where this makes sense.  This includes:

  - BSD partition types inside MSDOS labels
  - Solaris partition type inside MSDOS labels

This can be done by extending "has_partitions" to be set to "yes" in those
specific partition types.  The implementation should be the least intrusive
possible, taking into account that this kind of situations are an oddity
rather than the norm.

As for the other situations, the more I think about this, the more convinced
I am that this whole "partition nesting" concept is a broken mess.  I think I
already explained why in this list, but I can rehash the reasons if anyone's
interested.  I don't want to compromise on such part of GRUB core for the sake
of supporting this kind of layouts.

The only reason I'm open to implementing these two cases [1] is that they seem
to be inmensely popular among *BSD systems and Solaris derivatives.

As for *BSD and Solaris who read this, my advice is to step away, ditch the
whole MSDOS label burden and just settle on a clean label without the limits
DOS ones have.  If you strive for compatibility, GPT is a good choice IMO (and
the rest of the free world seems to be moving in this direction thanks to 2 TiB
limit).

[1] I know the first one is already implemented, but your approach makes it
less ad-hoc and splits code off part_msdos.mod, which is an improvement.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] gfxmenu relative path in "file" component of images

[Robert Millan]

This makes it possible to use relative paths in the "file" component of
gfxmenu images.  I've tested that it works, but I'd appreciate if someone
more familiar with gfxmenu can review it.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi
=== modified file 'gfxmenu/gui_image.c'
--- gfxmenu/gui_image.c	2009-12-29 16:31:02 +
+++ gfxmenu/gui_image.c	2010-01-20 21:18:38 +
@@ -207,9 +207,25 @@ load_image (grub_gui_image_t self, const
 static grub_err_t
 image_set_property (void *vself, const char *name, const char *value)
 {
+  static const char *theme_dir = NULL;
   grub_gui_image_t self = vself;
-  if (grub_strcmp (name, "file") == 0)
-return load_image (self, value);
+  if (grub_strcmp (name, "theme_dir") == 0)
+{
+  theme_dir = value;
+}
+  else if (grub_strcmp (name, "file") == 0)
+{
+  char *absvalue;
+
+  /* Resolve to an absolute path.  */
+  if (! theme_dir)
+	return grub_error (GRUB_ERR_BAD_ARGUMENT, "unspecified theme_dir");
+  absvalue = grub_resolve_relative_path (theme_dir, value);
+  if (! absvalue)
+	return grub_errno;
+
+  return load_image (self, absvalue);
+}
   else if (grub_strcmp (name, "id") == 0)
 {
   grub_free (self->id);

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot] command-line format

[Robert Millan]

On Sun, Jan 17, 2010 at 01:39:48PM -0600, richardvo...@gmail.com wrote:
> 
> I think a bootloader with "universal" in its name should be doing
> everything possible to avoid this.  If I want to multiboot between
> Linux, NetBSD, OpenSolaris, and OpenBSD, do I load my MBR with the BSD
> fork of GRUB, the Linux fork of GRUB, or the Solaris fork of GRUB?

It doesn't matter, because whichever version of GRUB you use should
generate a grub.cfg that uses multiboot command with appropiate
parameters.

> I think that defaulting the first parameter to the value used by what,
> 90% of kernels, but providing a way to override it (I like the
> variable idea) will be the least surprising for users.  The path is
> filesystem-relative anyway, so GRUB isn't required to know how the
> kernel names its devices, nor do changes to grub device addressing
> change the parameter passed.

Filesystem-relative paths still reflect GRUB's view and aren't really a good
solution for system tools (which deals with absolute paths and mount points
instead).  And even then, there are details like weird characters, slashes,
case sensitivity, etc which might differ.

If you still want GRUB's point of view, you can simply replace:

GRUB_PATH=$(make_system_path_relative_to_its_root ${SYSTEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH}"

with:

GRUB_PATH=$(make_system_path_relative_to_its_root ${SYSTEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH} ${GRUB_PATH}"

in your mkconfig script.  But it is much more straightforward to simply do:

GRUB_PATH=$(make_system_path_relative_to_its_root ${SYSTEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH}    ${SYSTEM_PATH}"

Then your system tools obtain a path that makes sense to them.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Build error: "ENABLE_NLS" is not defined

[Robert Millan]

On Wed, Jan 13, 2010 at 02:02:22AM +0100, Grégoire Sutre wrote:
> richardvo...@gmail.com wrote:
>
>>> Another option would be to replace #if ENABLE_NLS by #if defined(ENABLE_NLS)
>>> && ENABLE_NLS.
>>
>> I know the C compiler short-circuits &&, if the preprocessor does also
>> then this looks like the best solution.  If not, then nested #if.
>
> Yes the preprocessor also short-circuits (I tested a small example to be  
> sure, with gcc 4.1 and gcc 4.4).  So the automatic replacement command  
> becomes:
>
> find . -name '*.[ch]' -exec sed -i -e 's, ENABLE_NLS,  
> (defined(ENABLE_NLS) \&\& ENABLE_NLS),g' '{}' ';'

This affects gnulib/error.c and gnulib/gettext.h which would be much better
not to change, as they're being imported semi-automatically.

Perhaps you could solve this at its source?  (i.e. by defining ENABLE_NLS to
0 when gettext is unavailable).

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add 2 more E820 to ACPI specification

[Robert Millan]

On Wed, Jan 20, 2010 at 12:17:26AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> Robert Millan wrote:
> > On Fri, Jan 15, 2010 at 06:18:43PM +0100, Vladimir 'φ-coder/phcoder' 
> > Serbinenko wrote:
> >   
> >> Hello. This defines 2 more types for mmap_type in a way to match E820
> >> values. As grub legacy and grub2 both just pass E820 values through it
> >> shouldn't be any problem.
> >> 
> >
> > Note that although Multiboot's memory map format is modelled after e820,
> > it is defined by us, not by BIOS vendors.
> >
> >   
> Yes, but this information is needed and I prefer to provide it in
> grub-legacy-compatible way.
> >> -value of 1 indicates available @sc{ram}, and all other values currently
> >> +value of 1 indicates available @sc{ram}, value of 3 indicates usable 
> >> memory
> >> +holding ACPI information,
> >> 
> >
> > I'm concerned about increasing the amount of arch-specific references; what 
> > do
> > Multiboot kernels that use ACPI currently do?
> >
> >   
> According to a post by Bernard Trotter many of them rely on multiboot
> loader passing e820 through

I just checked GRUB Legacy;  it seems that it is passing through the whole
thing.  I think this was a mistake, but it's too late to fix it now.

Feel free to commit this.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: keyboard layout patches

[Robert Millan]

On Mon, Jan 18, 2010 at 08:04:35PM +, Carles Pina i Estany wrote:
> On Jan/18/2010, Vladimir '??-coder/phcoder' Serbinenko wrote:
> 
> > +  grub_util_write_image ("GRUBLAY", 7, fp);
> > +  grub_util_write_image ((char *) &version, 4, fp);
> > 
> > should be macroified and put somewhere in a header instead of duplicating
> 
> I agree. Any reason that I don't see that in util/grub-mkfont.c:
> 
>   grub_util_write_image ("FILE", 4, file);
>   grub_util_write_image ("PFF2", 4, file);
> 
> and then in font/font.c:
> 
>   static const char section_names_file[4] = { 'F', 'I', 'L', 'E' };
>   static const char pff2_magic[4] = { 'P', 'F', 'F', '2' };
> 
> ?
> 
> If should be in a macro (as I think so) I will fix after finishing other
> things.

Yeah it should.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: keyboard layout patches

[Robert Millan]

On Mon, Jan 18, 2010 at 07:25:37PM +, Carles Pina i Estany wrote:
> > Also keyboard_layouts is pretty small. Perhaps we can just make
> > *_keyboard depend on it and put US keyboard into it as default and shave
> > some complexity this way
> 
> How it would work in rescue mode and at_keyboard? I mean, extreme cases
> that Grub for some reason could not reach the keyboard layout file.

What's the total size we're talking about?

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: keyboard layout patches

[Robert Millan]

On Mon, Jan 18, 2010 at 02:53:36PM +0100, Carles Pina i Estany wrote:
> > Can you think of a way to restoring keyboard map to English?
> 
> unloading the module restores the original keyboard (so, English one). I save
> the original one when the module is loaded.

Don't confuse keyboard layouts with languages!  You probably meant US
keyboard.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] switch from sprintf to asprintf and snprintf

[Robert Millan]

On Tue, Jan 19, 2010 at 10:56:48PM +, Colin Watson wrote:
> On Tue, Jan 19, 2010 at 11:29:14PM +0100, Robert Millan wrote:
> > On Sun, Jan 17, 2010 at 01:02:55PM +0100, Vladimir 'φ-coder/phcoder' 
> > Serbinenko wrote:
> > > Robert Millan wrote:
> > > > On Fri, Jan 01, 2010 at 09:32:24AM +, Colin Watson wrote:
> > > >> On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir 'φ-coder/phcoder' 
> > > >> Serbinenko wrote:
> > > >>> +char *EXPORT_FUNC(grub_asprintf) (const char *fmt, ...)
> > > >>> + __attribute__ ((format (printf, 1, 2)));
> > > >>
> > > >> It's very confusing that you've made grub_asprintf have a dramatically
> > > >> different interface from asprintf. Perhaps you could call this
> > > >> grub_xasprintf instead?
> > > >
> > > > Is it feasible to implement the same interface as asprintf instead?
> > > 
> > > it's feasible but the only advantage it gives is the return value nobody
> > > uses anyway
> > 
> > What about consistency with what programmers expect?
> > 
> > If you don't want the return value, you can just discard it.
> 
> asprintf is not really an advantageous interface to emulate.  It
> requires tedious manual error handling and hardly anyone gets it right
> (GRUB didn't get it right across the board, before I converted it to
> xasprintf!), not to mention that error_code = function (&string, ...) is
> unpleasant to start with.  xasprintf is a much nicer interface; simply
> returning the string is what most programmers *actually* expect unless
> they've already bent their brains around asprintf.

Meh, I guess I'm one of those programmers who bent their brains.

Ok, feel free to go with proposed interface as grub_xasprintf().

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] [RESEND] GRUB script lexer rewrite using flex

[Robert Millan]

On Mon, Jan 18, 2010 at 09:15:49PM +0530, BVK Chaitanya wrote:
> Hi,
> 
> 
> 
> Attached patch is the rewritten GRUB script lexer using flex lexical
> analyzer generator script, along with some unit tests.

This can go to experimental if Vladimir finds it suitable; however, note
that in principle it shouldn't go in trunk untill after next release (1.98).

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bazaar workflow for GRUB

[Robert Millan]

On Tue, Jan 19, 2010 at 09:51:21AM +0530, BVK Chaitanya wrote:
> 
> I haven't seen anybody sending "bzr send" patches in the ML, so I
> didn't want to introduce something new.

Please don't let this stop you if you think "bzr send" is useful.  Most
of us are relatively new to Bazaar, so we might be just missing it.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Some tests using unit-testing-framework

[Robert Millan]

On Fri, Jan 15, 2010 at 09:42:29AM +0530, BVK Chaitanya wrote:
> An updated patch for the same is attached.  Its been updated to the
> latest trunk (with unit-testing-framework).

New files (except trivial ones like tests/grub_script_echo_keywords.in)
should have the GRUB GPLv3+ copyright/license header.

Btw, feel free to commit this and also add new tests directly into trunk,
as long as they can run succesfuly in any sane build environment.

Thanks

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add 2 more E820 to ACPI specification

[Robert Millan]

On Fri, Jan 15, 2010 at 06:18:43PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> Hello. This defines 2 more types for mmap_type in a way to match E820
> values. As grub legacy and grub2 both just pass E820 values through it
> shouldn't be any problem.

Note that although Multiboot's memory map format is modelled after e820,
it is defined by us, not by BIOS vendors.

> -value of 1 indicates available @sc{ram}, and all other values currently
> +value of 1 indicates available @sc{ram}, value of 3 indicates usable memory
> +holding ACPI information,

I'm concerned about increasing the amount of arch-specific references; what do
Multiboot kernels that use ACPI currently do?

> value of 4 indicates reserved memory which needs to
> +be preserved on hibernation and all other values currently
>  indicated a reserved area.

What's the difference between this reserved memory and a reserved area?

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot] abstractmbi, modules

[Robert Millan]

On Thu, Jan 14, 2010 at 08:01:21PM +0100, Grégoire Sutre wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> It's known problem: xen makes inappropriate assumptions about mbi placement
>
> I'm wondering why it works with the NetBSD boot-loader.  What are these  
> assumptions?

Loader in GRUB 2 tends to put MBI and associated structures right after
payload code (unlike GRUB Legacy which uses a fixed location below 1 MiB).

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Multiboot video support

[Robert Millan]

On Fri, Jan 15, 2010 at 04:44:50PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> Vladimir 'phi-coder/phcoder' Serbinenko wrote:
> > Added EGA text support
> >   
> Non-VBE parts reviewed and comitted. Resending VBE parts.

This is vetoed (in both trunk and experimental) unless someone provides a
very good reason to provide it.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bazaar workflow for GRUB

[Robert Millan]

On Mon, Jan 18, 2010 at 12:48:56PM -0800, Colin D Bennett wrote:
> 
> I mainly afraid of trunk checkouts because it tempts people to
> actually make code changes directly in the checkout,

I think this is fine for small changes.  Bigger efforts can easily use a
branch (either local or published) and then merge it into trunk.

We had worse problems with the situation Colin Watson described.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: EFI boot problem with MBP 5,4

[Robert Millan]

On Tue, Jan 19, 2010 at 12:37:57PM +, Daire Byrne wrote:
> Is this just a kernel bug that I should report or can grub work around
> this? It seems to be a unique incomparability with the EFI firmware in
> the latest MBP because grub-efi can boot kernels with this patch on
> earlier macbooks (e.g. MBP4,1).

Given this note in commit log:

> [...]  This is somewhat hacky, but it
> appears to be the only way to do this that does not break some some
> set of existing bootloaders.

I think you should report it to them.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] switch from sprintf to asprintf and snprintf

[Robert Millan]

On Sun, Jan 17, 2010 at 01:02:55PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> Robert Millan wrote:
> > On Fri, Jan 01, 2010 at 09:32:24AM +, Colin Watson wrote:
> >   
> >> On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir 'φ-coder/phcoder' 
> >> Serbinenko wrote:
> >> 
> >>> +char *EXPORT_FUNC(grub_asprintf) (const char *fmt, ...)
> >>> + __attribute__ ((format (printf, 1, 2)));
> >>>   
> >> It's very confusing that you've made grub_asprintf have a dramatically
> >> different interface from asprintf. Perhaps you could call this
> >> grub_xasprintf instead?
> >> 
> >
> > Is it feasible to implement the same interface as asprintf instead?
> >
> >   
> it's feasible but the only advantage it gives is the return value nobody
> uses anyway

What about consistency with what programmers expect?

If you don't want the return value, you can just discard it.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: RFC: Support Linux command line variants in grub-mkconfig

[Robert Millan]

On Mon, Jan 18, 2010 at 09:03:53PM +, Martin Orr wrote:
> I would like to be able to choose between alternative Linux command  
> lines in my GRUB menu (specifically, I want a "selinux=0" option, but I  
> can imagine that people might want other things).  I could add an extra  
> script to /etc/grub.d to do this, but then I have to copy the logic in  
> 10_linux to detect what kernel versions are available, and they do not  
> appear in the correct place in the menu.  It would be simpler if you  
> could specify variant command lines in /etc/default/grub and have them  
> handled automatically in 10_linux.
>
> The attached patch allows (for example) the following configuration in  
> /etc/default/grub:
> GRUB_LINUX_VARIANTS="noselinux kms"
>
> GRUB_CMDLINE_LINUX_noselinux="selinux=0"
> GRUB_LABEL_LINUX_noselinux="SELinux disabled"
>
> GRUB_CMDLINE_LINUX_kms="i915.modesetting=1"
> GRUB_LABEL_LINUX_kms="KMS enabled"
>
> This patch is only intended as a demonstration: various details of the  
> implementation still need to be sorted out, such as  
> internationalization.  Suggestions of wildly different  
> approaches/configuration interfaces are welcome.

I think this is growing severely overengineered.  It is already more
complex than it needs to be.

The scripts in /etc/grub.d *are* config files.  There's no reason you
can't edit them to suit your needs.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: IA64 port

[Robert Millan]

On Wed, Jan 30, 2008 at 06:48:11AM +0100, Tristan Gingold wrote:
> On Tue, Jan 29, 2008 at 03:46:50PM +0100, Marco Gerards wrote:
> > If you send in a new patch that addresses Robert's concerns +
> > Changelog entry, I will go over it ASAP :-).  Giving the same comments
> > as Robert does seems like a waste of time for everyone.  Is this ok
> > for you?
> 
> Here is the IA64 port patch.  I will send separately the FAT patch (optionnal)
> and I will mail my proposal to merge the both efi tools.

Hi!

I put your patch in /branches/ia64/ in our Bazaar repository and resynced it
with latest trunk, then fixed a ton of trivial build problems.

Unfortunately I can't test it.  If you can test it and confirm it works, we
could consider it for merging into experimental branch.  Although we'd need
to figure out what we do about missing loadable module support.

(btw FAT fixes were merged separately)

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot] command-line format

[Robert Millan]

On Sun, Jan 17, 2010 at 07:02:16PM +0100, Grégoire Sutre wrote:
> However, my first post in this thread was more about the multiboot  
> specification itself.  In light of your explanations, I would re-phrase  
> my suggestion as follows: in the multiboot specification, require that  
> the first argument of the MB command-line be a path to the booted file  
> *in a notation that is specific to the booted kernel*.  Or, if this is  
> too constraining or too confusing, simply ask that the first argument is  
> an informative string that does not contain kernel options (i.e. it can  
> safely be skipped).  This way, the specification would be closer to the  
> reference implementation (GRUB Legacy), and, more importantly, to what  
> multiboot-compliant kernels already *assume* about the format of the  
> command-line (NetBSD, OpenSolaris, Xen, others?).

I really don't think this is something that should be *mandated* by the spec,
specially not for legacy compatibility reasons.

Also, how is a bootloader supposed to know about a notation specific to the
booted kernel?  GRUB doesn't have the slightest clue how kernels name their
devices, and it shouldn't; OTOH the environment who generated grub.cfg knows
all the details.

But we could add a note saying that even if it's not required, the behaviour
of using first parameter this way is widespread.

> For GRUB 2, this could be implemented by a multiboot command that, by  
> default, behaves as GRUB Legacy, but also offers a way to modify the  
> implicit first argument of the multiboot command-line.  Something like:
>
> multiboot $path[;$ospath] ...
>
> (a) $path is the GRUB path to the booted file.
> (b) $ospath is the path that shall be passed to the booted file.
>
> By default, if there is no ';' in the first argument, $ospath is set to  
> the value that GRUB Legacy would have used.  Maybe a GRUB shell variable  
> `multiboot_ospath' would be better than this ';' marker.

I'm sorry, but I don't think this kind of UI complexity benefits users.

Also, I firmly believe that we shouldn't be satisfied with flawed solutions
just because they're part of our legacy baggage.  We can do better than this
because Free Software is more flexible and more powerful.  For example, NetBSD
can distribute its own version of GRUB and patch it, and coordinate an
interface change between GRUB and its kernel, etc.

We're not like BIOS vendors + Microsoft which are stuck with 40-year-old
crappy interfaces because neither of them has the flexibility to change each
others' implementation.  It would almost be funny if it wasn't because they
managed to put their i8086-encumbered legacy in every modern machine around
the world.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot] command-line format

[Robert Millan]

On Thu, Jan 14, 2010 at 05:53:25PM +0100, Grégoire Sutre wrote:
>
> As mentioned in a previous thread, I had some problems getting multiboot  
> options recognized by the NetBSD kernel, and this was actually due to  
> the fact that GRUB Legacy implicitly passes the booted file as first  
> argument whereas GRUB 2 doesn't [1].
>
> I started a thread on NetBSD's port-i386 mailing list [2] on the format  
> of the multiboot command-line, and the discussion moved towards the  
> change in GRUB regarding the first argument (booted kernel in GRUB  
> Legacy, removed in GRUB 2).  I ended up doing tests with Xen, which is  
> also multiboot-compliant, and Xen also skips the first argument in its  
> command-line parsing code (well, it's a bit more complex, see [3] for  
> details if you're interested).
>
> In the end, it may be the case that most multiboot-compliant kernels out  
> there still assume that the first argument is the booted file name, and  
> skip it without even looking at it.  Do you know of any kernel that does  
> not make this assumption?

Hi Grégoire,

This might sound contradictory to you, but we did this change precisely with
those kernels in mind.  We didn't do this just because we're pedantic when
reading the spec!  Our goal was to improve support for these situations.  I
will explain this:

GRUB Legacy used to pass this information implicitly as you point out.  As a
result, most of these kernels just skip the first parameter, but there are
also a few (like the kernel of OpenSolaris) which make use of the information
in it (to find some other files I think).

The problem we found is that because the file path parameter was implicit,
user was unable to modify it.  As a result, it became impossible to e.g.
load kernel of OpenSolaris from one device/path and its associated files
from somewhere else.  We wanted to provide the best user experience on
those platforms (Multiboot is our primary target, it's the boot protocol of
the GNU system and is much more important for GRUB than Linux loaders),
and this limitation was deemed unacceptable.

With this change, we provided more flexibility.  If users want to retain
the old protocol, they can still do this.  For example if a kernel just
ignores first parameter:

  multiboot /kernel unused foo bar

Or if it really wants to know the pathname:

  multiboot /kernel /kernel foo bar

One might think that this is an unnecessary burden, but the fact is that
users generally don't need to type any of this by hand (or even edit grub.cfg
by hand).  We provide the grub-mkconfig utility which is extensible and can
support this for a variety of different kernels.  So when someone writes a
script snippet for kernel of NetBSD or kernel of OpenSolaris (e.g.
10_knetbsd.in and 10_kopensolaris.in), they can make GRUB add a dummy
parameter for the kernel to skip (NetBSD's) or a file path for the kernel
to rely on (OpenSolaris').

P.S: please forward this message to the relevant NetBSD mailing list(s) if
you think this is appropiate.  TIA

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Multiboot video in GRUB (Re: [RFC] Multiboot ammendment: non-VBE video)

[Robert Millan]

On Sat, Jan 02, 2010 at 07:26:08PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> === added file 'ChangeLog.efiboot'
> --- ChangeLog.efiboot 1970-01-01 00:00:00 +
> +++ ChangeLog.efiboot 2010-01-02 01:48:33 +
> @@ -0,0 +1,19 @@
> +2009-11-28  Vladimir Serbinenko  
> +
> + Multiboot support on i386-efi.
> +
> + * conf/i386-efi.rmk (pkglib_MODULES): Add multiboot.mod.
> + (multiboot_mod_SOURCES): New variable.
> + (multiboot_mod_CFLAGS): Likewise.
> + (multiboot_mod_LDFLAGS): Likewise.
> + (multiboot_mod_ASFLAGS): Likewise.
> + * include/grub/i386/multiboot.h (grub_multiboot_real_boot): Explicitly
> + declare as regparm (3).
> + (grub_multiboot2_real_boot): Likewise.
> + (grub_multiboot_boot): Finish boot services.
> + (grub_fill_multiboot_mmap): Explicitly parse memory map types.
> + (grub_multiboot): Declare as noreturn to avoid finishing console.
> + * loader/multiboot_loader.c (grub_cmd_multiboot_loader): Enable
> + multiboot1 on i386-efi and disable multiboot2 on this platform.
> + (grub_cmd_module_loader): Likewise.

Could the EFI parts be split into a separate patch?  I definitely want both
things, but they're separate changes, would be good to have the additional
granularity if possible.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] Multiboot ammendment: non-VBE video

[Robert Millan]

Hi,

I committed your last patch with some minor stylistic adjustments, plus
your changes to the example kernel.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Invalid symbol table on NetBSD boot

[Robert Millan]

On Fri, Jan 08, 2010 at 01:44:25AM +0100, Grégoire Sutre wrote:
> Robert Millan wrote:
>
>> I suggest you test if GRUB Legacy's Multiboot loader supports this
>> properly, as the code I used derives from that.
>
> Yes, the problem disappears with GRUB Legacy's multiboot.  Moreover, I  
> noticed another issue: the command line is stripped (first word missing)  
> with GRUB 2's multiboot. Here are the logs.  After setting the root  
> variable appropriately, I get:
>
> --- With GRUB Legacy ---
> grub> kernel /netbsd.generic -z root=wd0a
> [...]
> --- With GRUB 2 ---
> grub> multiboot /netbsd.generic -z root=wd0a

There was an intentional backward-incompatible (but still compatible with
the specification) change.  The equivalent command on GRUB 2 would be:

grub> multiboot /netbsd.generic /netbsd.generic -z root=wd0a

First argument is the file being open;  in GRUB Legacy it's implicitly also
the first arg passed to payload, which is less flexible than letting user
specify it.  It doesn't have to be the filename at all, and usually the
payload doesn't need this information.

I'm not sure if this explains your missing word problem, but it sounds like
it could be related.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB update problems

[Robert Millan]

On Fri, Jan 08, 2010 at 10:39:38AM -0500, Henry W. Peters wrote:
> Ok, not getting any response here, probably means either:
>
> 1.) This is not the correct forum for someone NOT knowledgeable in the  
> inner workings of GRUB2,
>
> 2.) & or no one give a flying fig if someone has a serious problem  
> involving GRUB (1 or 2).
>
> Would someone be so kind as to explain... & perhaps, if necessary,  
> direct me to a forum that might actually be able to help me problem  
> solve here?

In principle, the right list for obtaining help with GRUB would be
help-grub.

But in practice, I'm not sure if there will be people there who can
provide user assistance.  Therefore user questions are tollerated in
grub-devel.

I'd really like to make help-grub the user support forum, but since I don't
have more time to volunteer myself, I'm not sure how to make this happen.

FWIW, if anyone who reads this is willing to help the GRUB project by
watching help-grub and helping with user requests there, he/she's more
than welcome to do that.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Search hinting support

[Robert Millan]

On Mon, Dec 28, 2009 at 02:04:18PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> -"NAME [VARIABLE]",
> +"NAME [VARIABLE] [HINTS]",

I think this can be done without an additional interface: root variable
already has the desired information.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 1.98 available in debian lenny, How to get fancy terminal ?

[Robert Millan]

On Thu, Jan 07, 2010 at 02:38:24PM -0800, Colin D Bennett wrote:
> 
> When you say “existing fonts” do you mean there is a font other than
> unifont?

Not that we currently provide.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 1.98 available in debian lenny, How to get fancy terminal ?

[Robert Millan]

On Thu, Jan 07, 2010 at 07:59:57PM +0530, J. Bakshi wrote:
> Hello everyone,
> 
> I am happy to see the availability of grub 1.98

That's very unlikely.  I don't recall having released 1.98 yet ;-)

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 1.98 available in debian lenny, How to get fancy terminal ?

[Robert Millan]

On Thu, Jan 07, 2010 at 08:33:24AM -0800, Colin D Bennett wrote:
> 
> BTW, the theme document is also on the wiki at
> <http://grub.enbug.org/ThemeFormat>.
> 
> I am about to build GRUB for testing again, from the experimental
> branch, and I can migrate my example themes to the new format.  It
> looks from the source like the changes are mostly related to allowing
> proportional position/size specifications.

Hi Colin,

More important than the format, is that we need a basic theme that only
depends on the fonts we currently provided.  Of course, this can be improved
as long as the new fonts are free (patches against the build system welcome),
but for now we only build single-size unifont.

(Aside from that, adding new fonts would introduce a delay for distributors
as they need to add new packages, get them approved, etc.  So in the interest
in bringing gfxmenu to mainstream as soon as possible, I would _strongly_
recommend to use the existing fonts for now)

Also, if you'd like to make an official GRUB theme with GNU-based image set,
you're more than welcome.

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: error message

[Robert Millan]

On Wed, Jan 06, 2010 at 11:23:11PM +, Carles Pina i Estany wrote:
> 
> (any problem to use the gcc macros to know the filename/line number? I
> remember something and I cannot find it now)

__FILE__ yields a significant code size increase.  We have an outstanding
problem with this.  See:

  https://savannah.gnu.org/task/?10024

-- 
Robert Millan

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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel