Re: [PATCH] simplify grub_raid_array
At Wed, 6 Feb 2008 17:45:07 +0100,
Robert Millan wrote:
> Unless I missed something, it seems that grub_raid_array contains redundant
> information (`name' is already present via `disk->name'). I propose to
> simplify it this way.
No idea why, I don't have the time to look at the actual code, but
> @@ -410,7 +410,7 @@ grub_raid_scan_device (const char *name)
> return 0;
> }
>
> - if (array->device[sb.this_disk.number].name != 0)
> + if (array->device[sb.this_disk.number]->name != 0)
> {
> /* We found multiple devices with the same number. Again,
>this shouldn't happen.*/
looks suspicious to me. Is that really doing what it is meant to do?
Regards,
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] simplify grub_raid_array
At Wed, 6 Feb 2008 23:59:54 +0100,
Robert Millan wrote:
>
> On Wed, Feb 06, 2008 at 11:43:39PM +0100, Jeroen Dekkers wrote:
> > At Wed, 6 Feb 2008 17:45:07 +0100,
> > Robert Millan wrote:
> > > Unless I missed something, it seems that grub_raid_array contains
> > > redundant
> > > information (`name' is already present via `disk->name'). I propose to
> > > simplify it this way.
> >
> > No idea why, I don't have the time to look at the actual code, but
> >
> > > @@ -410,7 +410,7 @@ grub_raid_scan_device (const char *name)
> > > return 0;
> > > }
> > >
> > > - if (array->device[sb.this_disk.number].name != 0)
> > > + if (array->device[sb.this_disk.number]->name != 0)
> > > {
> > > /* We found multiple devices with the same number. Again,
> > >this shouldn't happen.*/
> >
> > looks suspicious to me. Is that really doing what it is meant to do?
>
> Yes.
No, it doesn't. The meaning of the check .name != 0 is whether a
device with that number already exists in the array. If .name is 0, it
doesn't exist yet, because else it would've been assigned
something. What you're now doing is wrong because if there isn't a
device in the array then array->device[sb.this_disk.number] is 0. I
guess the only reason this actually works is because the first page of
memory (the one at address 0) happens to be zero by luck.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Give an error if curses isn't found
At Sun, 7 May 2006 16:06:10 +0200, Étienne Bersac wrote: > > Okey, > > It seems that i needed to re run ../configure an recompile the > project after installing libncurses5-dev . That would be great if ./ > configure check for ncurses headers. We already check for it, but we just continue when we don't find it. Configure should abort when it doesn't find curses however. This patch gives you an error message when the curses library isn't found. Jeroen Dekkers 2006-05-14 Jeroen Dekkers <[EMAIL PROTECTED]> * configure.ac: Display an error when the curses library isn't found. Index: configure.ac === RCS file: /cvsroot/grub/grub2/configure.ac,v retrieving revision 1.27 diff -u -p -r1.27 configure.ac --- configure.ac9 May 2006 00:05:49 - 1.27 +++ configure.ac14 May 2006 14:24:34 - @@ -187,7 +187,8 @@ fi # Check for curses. AC_CHECK_LIB(ncurses, wgetch, [LIBCURSES="-lncurses"], - [AC_CHECK_LIB(curses, wgetch, [LIBCURSES="-lcurses"])]) + AC_CHECK_LIB(curses, wgetch, [LIBCURSES="-lcurses"], +AC_MSG_ERROR([curses library not found]))) AC_SUBST(LIBCURSES) # Check for headers. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Fix for configure on x86_64 (Was: Re: [patch] Fix for building correct code on i386-pc (CVS-HEAD))
At Wed, 31 May 2006 02:31:49 +0200, Yoshinori K. Okuji wrote: > > On Wednesday 31 May 2006 00:00, Hollis Blanchard wrote: > > On Tue, 2006-05-30 at 22:59 -0500, Harley D. Eades III wrote: > > > http://lists.gnu.org/archive/html/grub-devel/2006-05/msg00106.html > > > > "host" and "target" are unclear to me here. For example, grub-emu would > > be compiled for the "host", but grub itself would be for the "target"? > > When would you ever want to build things differently like that? > > This is one of the requested features for GRUB. In GRUB Legacy, some group > developed GRUB on Sparc, but for PC by cross-compiling (actually, this was > Alcatel). It is a good thing that you can install GRUB for an architecture on > another. It's actually a necessary feature for GRUB on amd64. On amd64 you have 64-bit executables but GRUB will run in 32-bit mode. When trying to compile on amd64 I already ran into some problems related to that. First of all on amd64 all binaries are run in 64-bit mode, so the host CFLAGS variable shouldn't have -m32. Secondly LIBS is for the host only and shouldn't be defined when running target tests. As last we set CFLAGS, CC, etc. to the TARGET_*, then we run some checks and change the TARGET_* flags without updating CC, CFLAGS, etc to the new version. The attached patch should fix those problems. I've tested it on i386-pc and x86_64. 2006-05-31 Jeroen Dekkers <[EMAIL PROTECTED]> * configure.ac: Don't set host_m32 for x86_64. Also reset LIBS for the target-specific tests. Make sure that we also have the up-to-date target variables for those tests. Index: configure.ac === RCS file: /cvsroot/grub/grub2/configure.ac,v retrieving revision 1.29 diff -u -p -r1.29 configure.ac --- configure.ac30 May 2006 00:32:29 - 1.29 +++ configure.ac31 May 2006 19:51:10 - @@ -41,7 +41,6 @@ AC_CANONICAL_HOST AC_CANONICAL_TARGET case "$host_cpu" in - x86_64) host_m32=1 ;; powerpc64) host_m32=1 ;; esac @@ -186,10 +185,12 @@ tmp_CC="$CC" tmp_CFLAGS="$CFLAGS" tmp_LDFLAGS="$LDFLAGS" tmp_CPPFLAGS="$CPPFLAGS" +tmp_LIBS="$LIBS" CC="$TARGET_CC" CFLAGS="$TARGET_CFLAGS" CPPFLAGS="$TARGET_CPPFLAGS" LDFLAGS="$TARGET_LDFLAGS" +LIBS="" if test "x$TARGET_CFLAGS" = x; then # debug flags. @@ -232,6 +233,12 @@ AC_SUBST(TARGET_CFLAGS) AC_SUBST(TARGET_CPPFLAGS) AC_SUBST(TARGET_LDFLAGS) +# Set them to their new values for the tests below. +CC="$TARGET_CC" +CFLAGS="$TARGET_CFLAGS" +CPPFLAGS="$TARGET_CPPFLAGS" +LDFLAGS="$TARGET_LDFLAGS" + # Defined in aclocal.m4. grub_PROG_OBJCOPY_ABSOLUTE grub_ASM_USCORE @@ -252,6 +259,7 @@ CC="$tmp_CC" CFLAGS="$tmp_CFLAGS" CPPFLAGS="$tmp_CPPFLAGS" LDFLAGS="$tmp_LDFLAGS" +LIBS="$tmp_LIBS" # Check for options. AC_ARG_ENABLE([mm-debug], ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Another fix for x86_64
At Thu, 1 Jun 2006 17:39:13 +0200,
Yoshinori K. Okuji wrote:
>
> On Wednesday 31 May 2006 23:00, Jeroen Dekkers wrote:
> > It's actually a necessary feature for GRUB on amd64. On amd64 you have
> > 64-bit executables but GRUB will run in 32-bit mode.
> >
> > When trying to compile on amd64 I already ran into some problems
> > related to that. First of all on amd64 all binaries are run in 64-bit
> > mode, so the host CFLAGS variable shouldn't have -m32. Secondly LIBS
> > is for the host only and shouldn't be defined when running target
> > tests. As last we set CFLAGS, CC, etc. to the TARGET_*, then we run
> > some checks and change the TARGET_* flags without updating CC, CFLAGS,
> > etc to the new version.
> >
> > The attached patch should fix those problems. I've tested it on i386-pc
> > and x86_64.
>
> It looks good. Please check it in.
Now I actually booted GRUB 2 in qemu, I found another bug. :-) We are
still using grub_host_* types in grub/kernel.h, but the types of those
changed. We should use grub_target_* types there. As I didn't see any
other use of grub_host_* types, I just renamed those to grub_target_*
and changed the #ifdef. See the patch below.
Jeroen Dekkers
2006-06-07 Jeroen Dekkers <[EMAIL PROTECTED]>
* include/grub/types.h (grub_host_addr_t): Rename to
grub_target_addr_t.
(grub_host_off_t): Rename to grub_target_off_t.
(grub_host_size_t): Rename to grub_target_size_t.
(grub_host_ssize_t): Rename to grub_target_ssize_t.
Refer to GRUB_TARGET_SIZEOF_VOID_P to define those variables.
* include/grub/kernel.h (struct grub_module_header): Change type
of OFFSET to grub_target_off_t and type of SIZE to grub_target_size_t.
(grub_module_info): Likewise.
Index: include/grub/kernel.h
===
RCS file: /cvsroot/grub/grub2/include/grub/kernel.h,v
retrieving revision 1.8
diff -u -p -r1.8 kernel.h
--- include/grub/kernel.h 25 Apr 2006 20:08:31 - 1.8
+++ include/grub/kernel.h 7 Jun 2006 11:12:39 -
@@ -26,9 +26,9 @@
struct grub_module_header
{
/* The offset of object code. */
- grub_host_off_t offset;
+ grub_target_off_t offset;
/* The size of object code plus this header. */
- grub_host_size_t size;
+ grub_target_size_t size;
};
/* "gmim" (GRUB Module Info Magic). */
@@ -39,9 +39,9 @@ struct grub_module_info
/* Magic number so we know we have modules present. */
grub_uint32_t magic;
/* The offset of the modules. */
- grub_host_off_t offset;
+ grub_target_off_t offset;
/* The size of all modules plus this header. */
- grub_host_size_t size;
+ grub_target_size_t size;
};
extern grub_addr_t grub_arch_modules_addr (void);
Index: include/grub/types.h
===
RCS file: /cvsroot/grub/grub2/include/grub/types.h,v
retrieving revision 1.9
diff -u -p -r1.9 types.h
--- include/grub/types.h4 Jun 2006 15:56:54 - 1.9
+++ include/grub/types.h7 Jun 2006 11:12:39 -
@@ -69,16 +69,16 @@ typedef unsigned long long grub_uint64_t
#endif
/* Misc types. */
-#if SIZEOF_VOID_P == 8
-typedef grub_uint64_t grub_host_addr_t;
-typedef grub_uint64_t grub_host_off_t;
-typedef grub_uint64_t grub_host_size_t;
-typedef grub_int64_t grub_host_ssize_t;
+#if GRUB_TARGET_SIZEOF_VOID_P == 8
+typedef grub_uint64_t grub_target_addr_t;
+typedef grub_uint64_t grub_target_off_t;
+typedef grub_uint64_t grub_target_size_t;
+typedef grub_int64_t grub_target_ssize_t;
#else
-typedef grub_uint32_t grub_host_addr_t;
-typedef grub_uint32_t grub_host_off_t;
-typedef grub_uint32_t grub_host_size_t;
-typedef grub_int32_t grub_host_ssize_t;
+typedef grub_uint32_t grub_target_addr_t;
+typedef grub_uint32_t grub_target_off_t;
+typedef grub_uint32_t grub_target_size_t;
+typedef grub_int32_t grub_target_ssize_t;
#endif
#if GRUB_CPU_SIZEOF_VOID_P == 8
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Patch for successful compilation on FreeBSD Release-6.1
On Sun, Jun 11, 2006 at 10:28:44AM -0500, Harley D. Eades III wrote: > Hello, I managed to work up a small patch for grub2. She makes it > possible to build grub2 on FreeBSD Release-6.1. There is one thing > I am not sure on. In configure.ac I had to move the lines which > restore the compiler flags above the checks for _start etc..see the > patch. I would like as much feedback as possible. Thanks. :) The problem with the compiler flags should have been fixed with this change: 2006-05-31 Jeroen Dekkers <[EMAIL PROTECTED]> * configure.ac: Don't set host_m32 for x86_64. Also reset LIBS for the target-specific tests. Make sure that we also have the up-to-date target variables for those tests. If I read your patch correctly you haven't updated to recent CVS yet. Can you try whether this fix also works for you? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Branch for my Google SOC RAID and LVM work
Hi all,
I just created a CVS branch ("google-soc2006") withthe work I've done
so far for my Google SoC project. I currently have support for reading
RAID0, RAID1 and RAID5 arrays (the most common ones) finished. The
init function of the module currently scans all devices for a RAID
superblock. This won't work when modules containing devices are added
after the RAID module is loaded, but as far as I know GRUB should
already know about all devices when the RAID module is loaded, so this
shouldn't be a problem. The code also supports reading from degraded
RAID arrays, it is be able to read things when the RAID1 array has
only one disk and when the RAID5 array is missing one disk.
The current code has some loose ends, those all marked with
FIXMEs. First of all GRUB should probably also support less common
RAID levels like RAID4, RAID6, RAID10 en linear mode. Secondly the
RAID0 code currently assumes that all members of the array have the
same size, but this doesn't have to be the case.
Another issue is that since Linux 2.6 supports a new superblock layout
which I've not implemented yet. Currently mdadm still creates old
superblocks by default, so this shouldn't cause big problems at the
moment. Linux 2.6 also added support for partitions on RAID arrays,
this isn't implemented either. The last important issue is that RAID5
support different layouts for the parity, I've only implemented the
default layout so far.
Because this a Google SoC project, it has to be 100% my own work. So
don't send me patches, I can't really do anything with them at this
moment. If you try out the code and find problems, please report them
and I'll fix them myself.
The next thing I'm going to work on is adding support for RAID devices
in grub-setup. It should automatically detect whether /boot is on a
RAID device and set everything up accordingly when this is the case.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: still configure troubles
At Thu, 22 Jun 2006 05:22:09 + (UTC), Neville Chandler wrote: > > > The LZO library is installed, yet GRUB fails to configure. > > $ rpm -qa | grep lzo > lzo-2.02-12 > lzo-1.08-107 You also need to install the development libraries, those should be in the lzo-devel RPM. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Set size of partition correctly in grub_disk_open()
Hi,
When we open a partition grub_disk_open() sets disk->total_sectors to
the size of the disk, not the size of the partition. We also don't
check whether we grub_partition_probe() actually finds a
partition. See the patch below.
Jeroen Dekkers
2006-07-05 Jeroen Dekkers <[EMAIL PROTECTED]>
* kern/disk.c (grub_disk_open): Check whether
grub_partition_probe() finds a partition. Set disk->total_sectors
to the size of the partition if we open a partition.
Index: kern/disk.c
===
RCS file: /cvsroot/grub/grub2/kern/disk.c,v
retrieving revision 1.13
diff -u -p -r1.13 disk.c
--- kern/disk.c 4 Jun 2006 15:56:54 - 1.13
+++ kern/disk.c 5 Jul 2006 20:51:18 -
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2002,2003,2004 Free Software Foundation, Inc.
+ * Copyright (C) 2002,2003,2004,2006 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
@@ -265,7 +265,16 @@ grub_disk_open (const char *name)
disk->dev = dev;
if (p)
-disk->partition = grub_partition_probe (disk, p + 1);
+{
+ disk->partition = grub_partition_probe (disk, p + 1);
+ if (! disk->partition)
+ {
+ grub_error (GRUB_ERR_UNKNOWN_DEVICE, "no such partition");
+ goto fail;
+ }
+
+ disk->total_sectors = grub_partition_get_len (disk->partition);
+}
/* The cache will be invalidated about 2 seconds after a device was
closed. */
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Set size of partition correctly in grub_disk_open()
At Sat, 8 Jul 2006 18:07:44 +0200, Yoshinori K. Okuji wrote: > > Hi Jeroen, > > On Wednesday 05 July 2006 22:54, Jeroen Dekkers wrote: > > + > > + disk->total_sectors = grub_partition_get_len (disk->partition); > > +} > > But I don't agree with this part. The member "total_sectors" must describe > the > size of the whole disk but not of the partition. This is because GRUB > accesses partitions through the disk interface. When accessing a partition, > GRUB tweaks offsets by the start sector of the partition. If not, it is > another bug. grub_disk_check_range() increases the sector read so sector 0 is the first sector of the partition. So if you open a partition, you will have to read from 0 until the length of the partition, and that will give you the partition. Now I'm reading the code again I see that the "out of disk" check needs to be adapted to this change too. But it's a little bit illogical that the size you get from the same disk structure isn't the size of the partition, but the size of something else. It's also not really useful: if you're opening a partition, your are interested in the size of the partition most of the time, not the size of the disk the partition is on. The AFFS code already assumes that the total_sectors is the size of the partition and the blocklist code does that too, if you want to allow to read a blocklist from a partition. Not having total_sectors the size of the partition also makes it impossible to write generic code for both disks and partitions. Everytime you want to get the size of a device, you've to check whether the device is a disk or a partition. This will enlarge the code unnecessary. So I don't really see why total_sectors should be the size of the disk the partition is on instead of the size of the partition. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Set size of partition correctly in grub_disk_open()
At Sat, 8 Jul 2006 23:10:56 +0200,
Yoshinori K. Okuji wrote:
>
> On Saturday 08 July 2006 22:39, Jeroen Dekkers wrote:
> > But it's a little bit illogical that the size you get from the same
> > disk structure isn't the size of the partition, but the size of
> > something else.
>
> It is not illogical from my point of view. The disk structure should describe
> the information on a disk but not on a partition. Your way looks illogical to
> me.
The illogical thing for me is: You ask to open a partition, you get
back a structure that has half the properties of the partition, and
the other half has the properties of the disk the partition is on.
For me the grub_disk_* seem to just be an abstract interface to either
open a disk or a partition. This just worked all fine, except that
total_sectors that doesn't match what grub_disk_read() does.
> > It's also not really useful: if you're opening a
> > partition, your are interested in the size of the partition most of
> > the time, not the size of the disk the partition is on.
>
> No. When you open something, you usually have no interest in the size.
Yes, but those unusual places that do have interest in it want to know
the size of the partition and not the size of the disk that contains
the partition.
> > The AFFS code
> > already assumes that the total_sectors is the size of the partition
> > and the blocklist code does that too, if you want to allow to read a
> > blocklist from a partition.
>
> blocklist does not. I fixed this bug some weeks ago.
grub_fs_blocklist_open() has the following:
if (disk->total_sectors < blocks[i].offset + blocks[i].length)
{
grub_error (GRUB_ERR_BAD_FILENAME, "beyond the total sectors");
goto fail;
}
Given that disk->total_sectors is the number of sectors and disk can
be a partition, this check will allow to read after the end of the
partition.
> I don't remember about AFFS. I haven't proofread the code carefully.
AFAICS it calculates the position of the root block wrong, by assuming
that disk->total_sectors is the size of the partition it's reading.
> > Not having total_sectors the size of the partition also makes it
> > impossible to write generic code for both disks and
> > partitions. Everytime you want to get the size of a device, you've to
> > check whether the device is a disk or a partition. This will enlarge
> > the code unnecessary.
>
> Tell me why you need to know the size. The range check is automatically done
> by the disk interface, so you won't have to deal with such a check in the
> filesystem code.
The RAID superblock is located at 64KiB before the end of the device,
which can either be a partition or a whole disk. (For AFFS it seems
that the root block is located in the middle of the partition)
> > So I don't really see why total_sectors should be the size of the disk
> > the partition is on instead of the size of the partition.
>
> Because the disk structure is for disks, and the partition structure is for
> partitions. Overwriting total_sectors in a disk means that you only lose
> information. If your concern is only the conditional that checks if a disk
> contains a partition or not, you can write a functional such as
> grub_device_get_size.
So why do I get a disk structure when I want to open a partition, and
not a partition structure, if disk structures aren't for partitions?
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Set size of partition correctly in grub_disk_open()
At Sun, 9 Jul 2006 03:11:33 +0200,
Yoshinori K. Okuji wrote:
> > > No. When you open something, you usually have no interest in the size.
> >
> > Yes, but those unusual places that do have interest in it want to know
> > the size of the partition and not the size of the disk that contains
> > the partition.
>
> It depends on a case. I sometimes wanted to know disk information even when
> opening a partition, but I don't remember which case exactly. I must take a
> look at the code.
I don't see anything like that in the code when I grep for
total_sectors. The only code that is using total_sectors as the size
of the disk is the grub_disk_check_range(), but that function is also
interested in whether the offset/size fits in the partition when
reading from a partition. If total_sectors was the size of the
partition, the two ifs in grub_disk_check_range() could be merged to
just one if for both cases.
> > > blocklist does not. I fixed this bug some weeks ago.
> >
> > grub_fs_blocklist_open() has the following:
> >
> > if (disk->total_sectors < blocks[i].offset + blocks[i].length)
> > {
> > grub_error (GRUB_ERR_BAD_FILENAME, "beyond the total sectors");
> > goto fail;
> > }
>
> Ah, you meant the blocklist _filesystem_. I misunderstood that you meant the
> blocklist _command_. Yes, you are right. This is a bug. I haven't tested the
> blocklist filesystem with a partition, so I didn't know this bug. I will fix
> it later.
>
> > > I don't remember about AFFS. I haven't proofread the code carefully.
> >
> > AFAICS it calculates the position of the root block wrong, by assuming
> > that disk->total_sectors is the size of the partition it's reading.
>
> I see. It is definitely a bug. I must fix it.
Well, both users of total_sectors are assuming the semantics I'm
proposing, which only reinforces my point that it's the more logical
thing to do.
> > So why do I get a disk structure when I want to open a partition, and
> > not a partition structure, if disk structures aren't for partitions?
>
> You get *both*. I assume that the question is the hierarchy. The current
> design is based on this concept:
>
> device -> disk -> partition
> \
>-> net -> protocol
>
> I did want to abstract all kinds of devices as just devices, whenever
> possible. And the real character of a given device is described as attributes
> to the device (here, "disk" and "net"). In this organization, it is natural
> to have "partition" under "disk". If this order is reverse, it is very
> strange to me, because "partition" does not exist without "disk", as the
> purpose of "partition" is to partition a disk. Am I wrong?
We have both have disks and partitions. As a user of the interface, it
seems useful to me that you can just do a grub_disk_open() (or
grub_device_open(), but that just opens a disk at the moment and
you've to get device->disk and fiddle with that, so it isn't really
different) and get an object back. On that object you can then do a
read, write, get the size, etc. You don't have to care whether that
object is actually a partition or a disk, the code abstracts that
away.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Set size of partition correctly in grub_disk_open()
At Sun, 9 Jul 2006 15:29:17 +0200, Yoshinori K. Okuji wrote: > > On Sunday 09 July 2006 14:01, Jeroen Dekkers wrote: > > I don't see anything like that in the code when I grep for > > total_sectors. The only code that is using total_sectors as the size > > of the disk is the grub_disk_check_range(), but that function is also > > interested in whether the offset/size fits in the partition when > > reading from a partition. If total_sectors was the size of the > > partition, the two ifs in grub_disk_check_range() could be merged to > > just one if for both cases. > > Probably the idea was only in my mind. There are so many things that are not > implemented yet! > > > Well, both users of total_sectors are assuming the semantics I'm > > proposing, which only reinforces my point that it's the more logical > > thing to do. > > No. I don't think we can agree on this, since you don't see my point. > > GRUB is based on an object-oriented design. In object-oriented programming, > how attributes are stored is an implementation detail, so attributes should > not be accessed directly from the outside. On the other hand, it is sometimes > more convenient or just faster to access attributes directly. In this sense, > the current code in GRUB is a mixture. > > However, my wish is to enforce the object-oriented paradigm as much as > possible. What should the disk structure store as information? Of course, > about the disk itself. What should the partition structure as information? Of > course, about the partition itself. What should total_sectors store? Of > course, about the disk, since it is a part of the disk structure. Is it > inconvenient? Then, define an accessor appropriately. > > Your proposal simply breaks the rule of object-encapsulation in > object-oriented programming, so I never agree with you about this. Well, if you consider the total_sectors a private variable, and you want to have accessor functions for accessing it, then I can understand your point a bit, but such things will make the kernel bigger and I thought it was a goal to keep it as small as possible... I was however thinking about total_sectors as a public variable that gives the size of the device being opened. I don't really think a partition is an attribute of a disk (all the partitions might be an attribute of the disk, but just not a random one). I think it makes more sense to consider a partition an object of the same class as a disk, given that they have the same semantics. We might have to refactor this code for LVM too, if we consider LVM to be an advanced partition table. I haven't really looked into implementing LVM yet, but it's more like a partition table than a disk. It might make sense to allow people to access it using (volumegroup, volumename) syntax, like (hardisk, partitionnumber). You can't just add offsets in grub_disk_check_range like you can with DOS partitions however. But maybe implementing LVM by adding a new kind of disk device might be better. Anyway, do you want me to write a grub_disk_get_size() function? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Autoconf
At Wed, 12 Jul 2006 23:33:15 +0200, Yoshinori K. Okuji wrote: > > On Wednesday 12 July 2006 23:10, Marco Gerards wrote: > > Either I missed some commit and the instructions how to build on the > > AMD64. > > Ah, you have a good machine... > > > Below I included the config.log output. As you can see it > > tries to compile the test for the target machine and it uses glibc. I > > think we have to disable the use of glibc for these autoconf tests. > > But I am asking to make sure I am not wasting a lot of time by doing > > the wrong thing. > > I think so. I guess Jeroen simply has installed 32-bit libraries, right? Yes, and even if you compile the tests with -nostdlib it will search for -lc, I don't really think there is way to run the tests without libc. But I don't really see this as a big problem. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Support for RAID in grub-setup
Hi all, I'm a bit behind the schedule I created for SoC (I had some unplanned things happening the last 2 weeks), but I've just committed the RAID support for grub-setup and I'm going to work on LVM support very soon. Grub-setup will ask Linux for the members of the RAID array that is given as destination device. It will then install on the MBRs of those devices and embed core.img after MBR. If it can't embed the core image it will fail, I'm not sure whether we should support reading core.img from a RAID array... I let grub-setup put the RAID device directly into the prefix and put -2 in grub_install_dos_part. I've modified make_install_device() in init.c to leave the prefix alone when grub_install_dos_part is -2. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for RAID in grub-setup
At Fri, 28 Jul 2006 00:20:42 +0200, Yoshinori K. Okuji wrote: > > On Monday 24 July 2006 15:36, Jeroen Dekkers wrote: > > Grub-setup will ask Linux for the members of the RAID array that is > > given as destination device. It will then install on the MBRs of those > > devices and embed core.img after MBR. If it can't embed the core image > > it will fail, I'm not sure whether we should support reading core.img > > from a RAID array... > > Personally, I like to see that every part can be read from a RAID device, but > maybe not so important in reality It would be possible to calculate how to write the image to the file so it ends up being a consecutive image on the physical disk. But I think it's not worth the trouble, especially given that we can always embed the kernel if we keep the size below the 31k. > > I let grub-setup put the RAID device directly into the prefix and put > > -2 in grub_install_dos_part. I've modified make_install_device() in > > init.c to leave the prefix alone when grub_install_dos_part is -2. > > So, if my understanding is correct, core.img is read from a single disk, but > the rest is handled in a RAID device, right? Yes, core.img is embedded after the MBR on the specific disk. If you can boot from a disk, it's a pretty safe to assume thatt you can also read core.img for the same disk. Core.img includes the RAID module and that is used to read everything else it needs. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for RAID in grub-setup
At Sat, 29 Jul 2006 13:21:47 +0200, Yoshinori K. Okuji wrote: > > On Friday 28 July 2006 01:13, Jeroen Dekkers wrote: > > It would be possible to calculate how to write the image to the file > > so it ends up being a consecutive image on the physical disk. But I > > think it's not worth the trouble, especially given that we can always > > embed the kernel if we keep the size below the 31k. > > It would depend on the user... AFAIK, some stupid Windows software wants to > use that region for something else. I think the number of people who use RAID and such stupid Windows software on the same hard disk is pretty small. :-) This is probably different for LVM. But AFAIK we are currently always overwriting the region and booting will fail if the stupid Windows software overwrites that region. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Support for reading LVM volumes
Hi all, I've just commited the code for reading LVM volumes. The only issue that I know of is that it currently doesn't support reading snapshot volumes. All the normal LVM volumes (striped and linear) are supported however. I'm going to work on adding support for LVM to grub-setup now. That's the last remaining thing in my SoC project. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
At Sun, 13 Aug 2006 11:49:06 -0500, Hollis Blanchard wrote: > > What will happen to the google-soc2006 CVS branch when you're done? It should be merged into the mainline. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
At Sun, 13 Aug 2006 14:51:40 -0500, Hollis Blanchard wrote: > > On Sun, 2006-08-13 at 20:23 +0200, Jeroen Dekkers wrote: > > At Sun, 13 Aug 2006 11:49:06 -0500, > > Hollis Blanchard wrote: > > > > > > What will happen to the google-soc2006 CVS branch when you're done? > > > > It should be merged into the mainline. > > Well, of course. :) My question wasn't "what _should_ happen?" but > rather "what _will_ happen?". > > Who is going to do this? Does this fall outside the scope of your SoC > project? I understand that branches in CVS are extremely cumbersome, so > will this be a difficult process? You don't have to really merge the branch in CVS. You can just call diff on both branches and apply the patch on the mainline. Of course this isn't the most beautiful way, but it works... I also think we should switch to a better VCS. I'm actually using bzr myself. If anyone is interested, I've published my SoC branch and the CVS on my homepage: http://dekkers.cx/bzr/grub2 http://dekkers.cx/bzr/grub2-cvs My preference is bzr, but almost everything is better than cvs. I would happily use svn, mercurial or darcs for example. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
At Sun, 13 Aug 2006 17:13:55 +0200, Jeroen Dekkers wrote: > I'm going to work on adding support for LVM to grub-setup now. That's > the last remaining thing in my SoC project. This is done now. This means I've finished all the things for my SoC project. What I've written is a raid module that is able to read RAID arrays and LVM module that can read LVM volumes, so GRUB is able to read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has code that detects that the GRUB root is on a LVM or RAID device and will embed GRUB after the MBR. It will set the prefix so that the GRUB kernel can find the rest of the modules and configuration files. Any comments, bug reports, etc. are welcome. :-) Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
At Tue, 15 Aug 2006 14:48:41 +0200, Yoshinori K. Okuji wrote: > > On Tuesday 15 August 2006 13:30, Jeroen Dekkers wrote: > > > I'm going to work on adding support for LVM to grub-setup now. That's > > > the last remaining thing in my SoC project. > > > > This is done now. This means I've finished all the things for my SoC > > project. What I've written is a raid module that is able to read RAID > > arrays and LVM module that can read LVM volumes, so GRUB is able to > > read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has > > code that detects that the GRUB root is on a LVM or RAID device and > > will embed GRUB after the MBR. It will set the prefix so that the GRUB > > kernel can find the rest of the modules and configuration files. > > > > Any comments, bug reports, etc. are welcome. :-) > > You are marvelous! It was very painful for me to filter out applicants for > SoC, but you got rid of my pain of sin. :) Thanks. :-) > I think the rest is technical documentation. Could you summerize how it works > in brief? You can use the wiki or whatever else as you wish. http://grub.enbug.org/LVMandRAID I've linked it from the FrontPage. Feel free to ask question or to modify the page to add things if I forgot anything. > BTW, are you planning to write an article about your work (e.g. osnews.com, > free software magazine, etc.)? Not really, I'm afraid there isn't really that much exciting to tell. Maybe I will write down my knowledge about the RAID and LVM disk structures, because currently the only documentation is the source code. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: NF4 and GRUB 0.97 not working - err 16, 18, 25
At Mon, 28 Aug 2006 11:05:03 +0300 (EEST), Jan Wagner wrote: > > Hi, > > got an odd problem, GRUB 0.95 and 0.97 mysteriously refuse to boot beyond > stage 1.5 on an nForce4 chipsetted mobo (Asus A8N-SLI Deluxe). > > I've tried several parallel ATA disks (40GB, 120GB, 250GB), and also > using a /boot partition at the start of the disk instead of just a single > / plus swap, but to no avail. > > When I move the exactly same test disks created on the A8N-SLI PC to > different PCs (tried 2), they boot just perfect on those, with GRUB menu > and all. > > Even when installing Fedora Core 5 or Debian 3.1 on the A8N-SLI PC, the > entire setup process completes fine, but upon reboot grub gives > alternatively errors 16, 18 or 25. > > Wiping the beginning of the disk with dd if=/dev/zero for a few blocks, > then reinstalling e.g. FC5, the problem still persists. > > So on the A8N-SLI Deluxe apparently no matter what, GRUB gets stuck on > stage 1.5, no menu. > > Any ideas? > > I already did update-grub, grub-install /dev/hda --recheck, after > booting with a recovery CD and chrooting to /dev/hda. Grub appears to > install itself just fine, but booting still gives those errors. > > Any thoughts on what to try next? > > Some grub info (though I'm not sure if this is GRUB config issue since the > same disk will boot to grub menu properly on a different PC...): > > -- > /boot/grub$ cat device.map > (fd0) /dev/fd0 > (hd0) /dev/hda > (hd1) /dev/sda > (hd2) /dev/sdb > (hd3) /dev/sdc > (hd4) /dev/sdd I've got the same motherbord and I don't have problems with it. I have only SATA disks however. Are you sure the BIOS actually boots hda and not sda? And that the above mapping is correct? It might be possible that sda is hd0 and hda is hd4. An easy way to find is to remove the SATA disks and see whether it works. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: LVM and RAID merged
At Sat, 14 Oct 2006 17:36:19 +0200, Yoshinori K. Okuji wrote: > > So I've merged the result by Jeroen into the main trunk. Please check it out, > if you are interested. > > BTW we haven't released a new version for a while. Thus I'd like to make one > tomorrow. Does anybody have an objection? I think LVM and RAID support is > good enough to announce a new version. Thanks for the merge. I don't have time to hack on it at the moment, but the LVM and RAID module don't have debugging printfs in it. So this will make it hard to debug problems that people might have with it. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: LVM and RAID merged
At Sat, 14 Oct 2006 21:08:05 +0200, Robert Millan wrote: > > On Sat, Oct 14, 2006 at 05:36:19PM +0200, Yoshinori K. Okuji wrote: > > So I've merged the result by Jeroen into the main trunk. Please check it > > out, > > if you are interested. > > > > BTW we haven't released a new version for a while. Thus I'd like to make > > one > > tomorrow. Does anybody have an objection? I think LVM and RAID support is > > good enough to announce a new version. > > I've noticed this: > > ./grub2/util/i386/pc/getroot.c: if (!strncmp (os_dev, "/dev/md", 7) || > !strncmp (os_dev, "/dev/.static/dev/md", 19)) > > I think checking for /dev/.static is no longer needed because of: > > 2006-09-14 Robert Millan <[EMAIL PROTECTED]> > [...] > * util/i386/pc/getroot.c: Don't recurse into dotdirs (e.g. ".static"). > > Anyone can confirm that? I don't have a RAID system for testing here. That's correct, you can remove the second check. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 1.95 is released
At Sun, 15 Oct 2006 17:31:04 +0200, Stefan Reinauer wrote: > > * Yoshinori K. Okuji <[EMAIL PROTECTED]> [061015 16:51]: > > * Number partitions from 1 instead of 0. For instance, the first > > partition of "hd0" is now "hd0,1" but not "hd0,0". > > Hm. What's the reason for being inconsistent here? > > If changing the partition naming scheme, I would have thought it'd > become hd1,1. But why is the first disk 0 and the first partition 1? IIRC the BSDs, Solaris and GNU/Hurd start counting with 0 for their disks, it might make sense to be consistent with those operating systems. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] for LVM VL-names
At Sat, 21 Oct 2006 14:39:22 +0200, Michael Guntsche wrote: > This little patch, fixes the problem of grub-emu not displaying the > right logical volume names. Doh! Thanks for the patch, I've committed it. Can you also write ChangeLog entry next time? You can read at http://www.gnu.org/prep/standards/standards.html#Change-Logs how that should be done. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: __unused
At Fri, 03 Nov 2006 14:45:52 -0600, Hollis Blanchard wrote: > > On Wed, 2006-11-01 at 13:48 +0100, Johan Rydberg wrote: > > Hollis Blanchard <[EMAIL PROTECTED]> writes: > > > > > --- grub2-cvs.orig/include/grub/types.h 2006-10-31 19:06:47.0 > > > -0600 > > > +++ grub2-cvs/include/grub/types.h2006-10-31 19:06:58.0 > > > -0600 > > > @@ -23,6 +23,8 @@ > > > #include > > > #include > > > > > > +#define __unused __attribute__ ((unused)) > > > + > > > > First when I saw this it made me wanna comment on it, and tell you > > that defines should all be in uppercase. But then I poked through the > > code, and saw the usage of it, and it looked quite nice, with the > > exception of the __-prefix. There are a lot of "common" words that > > are keywords in C; inline, const and auto for example. Maybe we > > should make "unused" a reserved keyword in GRUB? That would allow > > us to write code like; > > I left it as "__unused" for now, to match Linux's usage. (We can change > it later if needed.) We need another name, the __unused name is used in stat.h for an unused member in struct stat. Grub-setup gives the following compiler error: gcc -Iutil/i386/pc -I/home/jeroen/cvs/grub2/util/i386/pc -I. -Iinclude -I/home/jeroen/cvs/grub2/include -Wall -W -DGRUB_LIBDIR=\"/usr/local/lib/grub/i386-pc\" -g -O2 -DGRUB_UTIL=1 -MD -c -o grub_setup-util_i386_pc_grub_setup.o /home/jeroen/cvs/grub2/util/i386/pc/grub-setup.c In file included from /usr/include/sys/stat.h:105, from /home/jeroen/cvs/grub2/util/i386/pc/grub-setup.c:43: /usr/include/bits/stat.h:103: error: expected identifier or ‘(’ before ‘[’ token /usr/include/bits/stat.h:164: error: expected identifier or ‘(’ before ‘[’ token make: *** [grub_setup-util_i386_pc_grub_setup.o] Error 1 Any ideas for a new name for the define? Something like "grub_unused"? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: __unused
At Thu, 09 Nov 2006 16:31:58 +0100, Johan Rydberg wrote: > > Jeroen Dekkers <[EMAIL PROTECTED]> writes: > > > Any ideas for a new name for the define? Something like "grub_unused"? > > "UNUSED" ? After a small discussion with Hollis on IRC I changed it to "UNUSED". Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
At Sat, 25 Nov 2006 03:56:50 +0100, Yoshinori K. Okuji wrote: > > On Wednesday 15 November 2006 23:48, Hollis Blanchard wrote: > > > > An exception is exactly what I am proposing. What is your objection? > > > > > > The GNU Project endorses the use of GPL to promote freedom. Don't forget > > > that GRUB is a part of GNU. > > There is plenty of precedent here. So I still see nothing wrong with > > putting a header file, which describes an interface, under a non-GPL > > license. > > Because GRUB is not a library. The spec is available independently, so you > can > write your own header easily. Nothing prevents you from doing this. Nothing prevents you from writing a C library - the POSIX and C standards are available independently. Yet the C library is under LGPL. Also nothing prevents you from writing an ogg vorbis implementation, but the FSF advocated the BSD license for ogg vorbis however. What RMS said is that the GPL isn't an end itself. I agree with that, and I think the BSD license is more suitable for the multiboot header files and/or multiboot example kernel than the GPL. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Tue, Nov 28, 2006 at 08:11:37AM +0100, Yoshinori K. Okuji wrote: > On Sunday 26 November 2006 23:50, Jeroen Dekkers wrote: > > Nothing prevents you from writing a C library - the POSIX and C > > standards are available independently. Yet the C library is under > > LGPL. Also nothing prevents you from writing an ogg vorbis > > implementation, but the FSF advocated the BSD license for ogg vorbis > > however. > > > > What RMS said is that the GPL isn't an end itself. I agree with that, > > and I think the BSD license is more suitable for the multiboot header > > files and/or multiboot example kernel than the GPL. > > You are right at the point that we adopt weaker licenses by compromise from > time to time. But you completely miss the point that code in GRUB is not > meant to be used for other projects. So we have no reason to compromise in > GRUB. You completely miss the point that we want to have header files and example code that can be used by other projects to implement multiboot. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Tue, Nov 28, 2006 at 08:08:46AM +0100, Yoshinori K. Okuji wrote: > On Sunday 26 November 2006 11:18, Tomáš Ebenlendr wrote: > > What about having > > "Multiboot's" header as a part of "Multiboot project". > > Multiboot Specification is not a part of GRUB in any sense. It is discussed > in > this list, only because that is the most realistic at the moment, as all > Multiboot developers are GRUB developers, too, AFAIK. Not part of GRUB in any sense? It was developed by GRUB developers, has always been living in the GRUB repository, the official GRUB tarball includes it and AFAIK GRUB is the only bootloader to implement it. Saying that multiboot isn't part of GRUB doesn't really make any sense to me. It could as well have been named "GRUB boot protocol" and nobody would consider that strange. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
At Tue, 28 Nov 2006 12:25:49 +0100, Yoshinori K. Okuji wrote: > > But now it might be better to change my mind, since even _you_ misunderstand > it. If you don't get it, how many people would understand? If you consider it a separate project, it's probably better to make it a real separate project. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Google Summer of Code 2007
At Tue, 6 Mar 2007 18:07:16 +0100, Thomas Schwinge wrote: > Hello! > > On Tue, Mar 06, 2007 at 11:44:21AM +0100, Johan Rydberg wrote: > > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > > As you may know, Google Summer of Code 2007 is about starting: > > > > Are we suggesting any tasks that could be done by the student(s)? > > That's how it is supposed to work, yes. The mentoring organization (GNU) > will publish a list of tasks it has mentors for. From that list the > students then can select. This list of tasks is made up from the input > that the individual GNU (sub)projects provide. And their maintainers, in > turn, can get ideas for tasks either from having them already in their > minds or from students that say: ``Hey, if you put up such a task, then > I'm going to apply for it.'' > > So, if you have ideas for tasks and could imagine mentoring them, then > speak up. I think most tasks of http://www.gnu.org/software/grub/grub-soc.html still need to be done, so we could use that list to start from. I won't be participating in SoC this year because my boss has enough work for me during the summer, but I'm afraid that I won't have time to mentor either. So I would prefer if somebody else who is more sure about his available time is going to be the mentor. I could be the backup mentor however. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Google Summer of Code 2007
At Tue, 06 Mar 2007 22:49:31 +0100, Jeroen Dekkers wrote: > I won't be participating in SoC this year because my boss has enough > work for me during the summer, but I'm afraid that I won't have time > to mentor either. So I would prefer if somebody else who is more sure > about his available time is going to be the mentor. I could be the > backup mentor however. Given that nobody answered and I thought about it again, it should be possible for me to be a mentor this year. Is there anyone who could be a backup mentor? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Google Summer of Code 2007
At Mon, 12 Mar 2007 18:45:33 +0100, Yoshinori K. Okuji wrote: > > On Saturday 10 March 2007 22:38, Jeroen Dekkers wrote: > > Given that nobody answered and I thought about it again, it should be > > possible for me to be a mentor this year. Is there anyone who could be > > a backup mentor? > > Yeah, it is a good idea for you to be a mentor. Thank you for this proposal. > > As I know that a backup mentor has nothing to do in reality, I can do it. It > is just a title AFAIK. Well I can always be hit by a bus or anything like that. But I hope it won't be necessary. We should come up with a idea list today, because tomorrow Google will begin accepting applications. I think we should just start with http://www.gnu.org/software/grub/grub-soc.html and remove the project I did last summer. I think all the other tasks still need to be done. New ideas are welcome too of course. Personally I think one of the important things we have to do is making GRUB2 a suitable replacement for GRUB Legacy. This means implementing all the features from GRUB Legacy that GRUB2 doesn't have yet, making sure that the installer and other tools are all in a good state, etc. It's a bit difficult to make a task out of that, but IMHO it's time that GRUB2 gets ready for production use. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Google Summer of Code 2007
At Tue, 13 Mar 2007 17:44:21 +0100, Yoshinori K. Okuji wrote: > > On Tuesday 13 March 2007 13:38, Jeroen Dekkers wrote: > > We should come up with a idea list today, because tomorrow Google will > > begin accepting applications. I think we should just start with > > http://www.gnu.org/software/grub/grub-soc.html and remove the project > > I did last summer. I think all the other tasks still need to be > > done. New ideas are welcome too of course. > > I agree. And this needs to be informed to the gnu's list, because what Google > will see is the GNU's list but not ours. > > http://www.gnu.org/software/soc-projects/ideas.html I can't update the website as long as savannah is down... :-( > > Personally I think one of the important things we have to do is making > > GRUB2 a suitable replacement for GRUB Legacy. This means implementing > > all the features from GRUB Legacy that GRUB2 doesn't have yet, making > > sure that the installer and other tools are all in a good state, > > etc. It's a bit difficult to make a task out of that, but IMHO it's > > time that GRUB2 gets ready for production use. > > I fully agree, but I am afraid that this kind of task should be done by > long-term contributors rather than newcomers, and SoC is not very suitable. > > The term of SoC is really short. IMO, it is long enough to implement some > clear, straightforward and visible feature, but not for vague, complicated > and tiresome work. I agree, but we could give proposals for implementing features that work towards this goal a higher priority than those that don't. E.g. giving CDROM support and the fancy menu interface a higher priority, because that are two things GRUB Legacy already has (in most major distributions at least). And certainly without the fancy menu the major distributions aren't going to switch to GRUB2. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Question about the GNU Grub ideas
At Wed, 21 Mar 2007 14:58:54 -0800, xiongyi wrote: > I am a potential student applicant for the "Google-summer -of -code" > program. And I am strongly interested in the GNU Grub project, especially > for the porting grubs to the EFI-based PC platform idea. But there are few > messages or information about EFI porting for grub2. So I have some > questions about this idea. I don't have any experience with EFI, but as far as I know GRUB2 already boots on intel macs and other EFI-based x86 machines. Although it probably still needs a lot of work, that isn't going to be enough for a Summer of Code project. > 1.Though the source codes of current grub2 have some features about > EFI, I feel that the building for EFI platform support of grub2 is based on > an EFI implementation. That means we need an EFI implementation to build the > source code for EFI of grub2. For example, the building for the elilo is > based on the gnu-efi project. Is that right? Or whether the current grub2 > includes an EFI implementation, similar to the gnu-efi project. No, the grub EFI implementation is stand-alone, it doesn't need any external project. > 2.The goal of grub2 for efi support is the same as the one of elilo, > namely an efi OS Loader (also an efi application, for example elilo.efi file > in the elilo project). Is that right? Yes, the purpose is to load GRUB on EFI hardware so that GRUB can do all the things it normally does when you load it from standard x86 BIOS. > 3.There is a real EFI platform in my lab, but I will graduate and > leave that lab in this June. Accordingly, I have some considerations about > the development platform and environment. If the efi feature of grub2 is > only an efi OS loader, whether the EDK open source project can serve as the > development and debug platform. My experience is that while you can develop and test on such things, real hardware has subtle differences most of the time and you always need hardware to test whether it really works. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Question about the GNU Grub ideas
At Fri, 23 Mar 2007 00:44:16 +0100, Yoshinori K. Okuji wrote: > > On Thursday 22 March 2007 23:49, Jeroen Dekkers wrote: > > > I am a potential student applicant for the "Google-summer -of -code" > > > program. And I am strongly interested in the GNU Grub project, especially > > > for the porting grubs to the EFI-based PC platform idea. But there are > > > few messages or information about EFI porting for grub2. So I have some > > > questions about this idea. > > > > I don't have any experience with EFI, but as far as I know GRUB2 > > already boots on intel macs and other EFI-based x86 machines. Although > > it probably still needs a lot of work, that isn't going to be enough > > for a Summer of Code project. > > Why not enough? EFI has a significant amount of share in the market, and I > see > nothing bad with working on EFI stuff. > > I have already written the status in the wiki: > > http://grub.enbug.org/TestingOnEFI > > In addition, we need Multiboot support on EFI as well. The question is whether it's possible to formulate a project big enough for Summer of Code and that also has clear goals, given that the basic implementation of the port is already done? But I don't know anything about EFI, so if you say that's possible than it's okay with me. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Please regenerate autogenerated files
Hi, I just saw that some people aren't regenerating autogenerated files in CVS. If you make changes to configure.ac or conf/*.rmk, please run autogen.sh and also commit the generated files. Thanks, Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: double free() with grub-probe
At Wed, 16 May 2007 22:01:01 +0200, Robert Millan wrote: > > We got this bug report from Debian BTS. It seems to be related to LVM. > > The argc address in last line looks very suspicious; stack corruption? It's possible, but it can also be a compiler optimalisation that confuses gdb. > > Program received signal SIGABRT, Aborted. > > 0xe410 in __kernel_vsyscall () > > (gdb) bt > > #0 0xe410 in __kernel_vsyscall () > > #1 0xb7dfcd60 in raise () from /lib/i686/cmov/libc.so.6 > > #2 0xb7dfe5b1 in abort () from /lib/i686/cmov/libc.so.6 > > #3 0xb7e3308b in __libc_message () from /lib/i686/cmov/libc.so.6 > > #4 0xb7e3aeed in _int_free () from /lib/i686/cmov/libc.so.6 > > #5 0xb7e3e530 in free () from /lib/i686/cmov/libc.so.6 > > #6 0x0804bc8f in grub_disk_read (disk=0x8064078, sector=4000189, offset=0, > > size=194560, buf=0xb7da2008 "") > > at kern/disk.c:480 That's the free of tmp_buf, but I just looked at the code and as far as I can see the only place where tmp_buf can get freed is at that place. So I'm a bit puzzled how a double free() can happen there. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: double free() with grub-probe
At Wed, 16 May 2007 22:38:25 +0200, Florian Kriener wrote: > > On Wednesday 16 May 2007 22:29:17 Jeroen Dekkers wrote: > > At Wed, 16 May 2007 22:01:01 +0200, > > > > Robert Millan wrote: > > > We got this bug report from Debian BTS. It seems to be related to LVM. > > > > > > The argc address in last line looks very suspicious; stack corruption? > > > > It's possible, but it can also be a compiler optimalisation that > > confuses gdb. > > No, it's not that, I get that error with the standard debian package > (grub-pc), with a self-compiled version (using debian sources), in gdb and > (just tested it) even when compiled with empty CCFLAGS. If it's stack corruption, I guess gcc's stack protection should detect that. Can you try to recompile with -fstack-protector-all? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: double free() with grub-probe
At Thu, 17 May 2007 11:58:54 +0200,
Marco Gerards wrote:
> Hi Robert,
>
> > We got this bug report from Debian BTS. It seems to be related to LVM.
> >
> > The argc address in last line looks very suspicious; stack corruption?
>
> Can you try valgrind? The older valgrinds didn't work with GRUB 2,
> but the newer ones do.
I could reproduce this on one of my machines and ran it through
valgrind. I've just committed a fix to the grub2 CVS repository (as
well as another memory bug valgrind spotted). A copy of the patch is
below.
Jeroen Dekkers
Index: kern/disk.c
===
RCS file: /cvsroot/grub/grub2/kern/disk.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -p -r1.17 -r1.18
--- kern/disk.c 10 Nov 2006 23:31:55 - 1.17
+++ kern/disk.c 17 May 2007 19:03:42 - 1.18
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2002,2003,2004,2006 Free Software Foundation, Inc.
+ * Copyright (C) 2002,2003,2004,2006,2007 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
@@ -414,6 +414,8 @@ grub_disk_read (grub_disk_t disk, grub_d
num = ((size + GRUB_DISK_SECTOR_SIZE - 1)
>> GRUB_DISK_SECTOR_BITS);
+
+ tmp_buf = grub_realloc (tmp_buf, num << GRUB_DISK_SECTOR_BITS);
if ((disk->dev->read) (disk, sector, num, tmp_buf))
{
grub_error_push ();
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#381150: still not able to handle partitionable arrays
At Mon, 7 May 2007 22:00:50 +0200, Robert Millan wrote: > > On Mon, May 07, 2007 at 09:03:48PM +0200, Yoshinori K. Okuji wrote: > > On Saturday 05 May 2007 01:29, Robert Millan wrote: > > > It seems there are problems with accessing software RAID in devices with > > > pathnames like /dev/md_d0p1 > > > > Is there any specification about device names on Linux? I have been seeing > > Linux adding more and more new inconsistent device names for years, and it > > seems to be no end in this game. The best part is actually that it's not the only name, from the mdadm manpage: """ The standard names for non-partitioned arrays (the only sort of md array available in 2.4 and earlier) either of /dev/mdNN /dev/md/NN where NN is a number. The standard names for partitionable arrays (as available from 2.6 onwards) is one of /dev/md/dNN /dev/md_dNN Partition numbers should be indicated by added "pMM" to these, thus "/dev/md/d1p2". """ > Not that I know of. But a few days ago I was toying with the idea that grub > could theoreticaly become device path agnostic. Maybe this doesn't apply to > specific things like software RAID / LVM, but for most weird devices it's > probably feasible. I've been thinking about that too, because the current way seems a bit fragile. But then you're looking up the device major and minor number for partionable RAID arrays and you see that it's in the "LOCAL/EXPERIMENTAL USE" range. Not very useful either... Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#381150: still not able to handle partitionable arrays
At Sat, 5 May 2007 01:29:07 +0200, Robert Millan wrote: > It seems there are problems with accessing software RAID in devices with > pathnames like /dev/md_d0p1 > > On Sat, Jan 06, 2007 at 05:59:16PM +0100, martin f krafft wrote: > > > > grub2 1.95-2 still does not support partitionable arrays: > > > > [...] > > > > debian# grub-probe -v /boot > > grub-probe: info: changing current directory to /dev > > grub-probe: info: changing current directory to i2o > > grub-probe: info: changing current directory to ataraid > > grub-probe: info: changing current directory to shm > > grub-probe: info: changing current directory to network > > grub-probe: info: changing current directory to input > > grub-probe: info: changing current directory to cciss > > grub-probe: info: changing current directory to mapper > > grub-probe: info: changing current directory to ida > > grub-probe: info: changing current directory to rd > > grub-probe: info: changing current directory to pts > > cannot find a GRUB drive for md_d0p1. My latest commit to GRUB2 CVS should fix this. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#381150: still not able to handle partitionable arrays
At Fri, 18 May 2007 09:34:53 +0200,
Michael Guntsche wrote:
> This also seems to fix the detection for LVM devices. grub-probe -t
> {drive,device} works now, partmap on the other hand still fails.
That was actually a different fix that I committed on the 16th.
>
> grub-probe: info: changing current directory to /dev/mapper
> grub-probe: info: opening fatoftheland-main
> grub-probe: error: Cannot detect partition map for fatoftheland-main
>
> For now I install everything manually but maybe this can be fixed as
> well.
This is actually the same problem as with software RAID, currently
grub-probe doesn't have a way to get the underlying device and lookup
the partition map. Maybe I've time to look into this later today, but
I've first some other things to do.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: double free() with grub-probe
At Fri, 18 May 2007 20:36:40 +0200, Yoshinori K. Okuji wrote: > > On Thursday 17 May 2007 21:19, Jeroen Dekkers wrote: > > I could reproduce this on one of my machines and ran it through > > valgrind. I've just committed a fix to the grub2 CVS repository (as > > well as another memory bug valgrind spotted). A copy of the patch is > > below. > > Thank you for your fix. Just a small thing, but isn't it better to check the > return value from grub_realloc? Oops... fixed it. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID
At Sat, 19 May 2007 15:13:58 +0100, Sam Morris wrote: > In addition, it would be nice if the 'out of disk' error could be > deferred until grub actually tries to read a block that is out of range, > as grub-legacy does The problem is that it actually tries to do that, because the RAID superblock is located at the end of the partition. > (even through it doesn't 'see' the RAID partition as > such, I can still boot from it without complaint). That's probably because you have RAID1. The only difference between a RAID and a non-RAID is that there is a RAID superblock at the end, you can just mount a RAID1 partition as normal. This is how grub legacy was always able to boot from RAID1 partitions. This won't work with RAID0 or RAID5 however. > I wonder if d-i warns the user that they may be creating an unbootable > system if the partition that contains /boot does not exist wholly within > the first 7.8 GiB/128 GiB/128 PiB (depending on the addressing mode in > use) of the disk? :) I think that 7.8GiB limit has been gone for a long time now, I don't think there will be a lot of installations on such machines. My guess is that the 128 GiB limit is still a problem. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID
At Mon, 21 May 2007 13:23:38 +0100,
Sam Morris wrote:
>
> On Mon, 2007-05-21 at 13:08 +0200, Jeroen Dekkers wrote:
> > At Sat, 19 May 2007 15:13:58 +0100,
> > Sam Morris wrote:
> > > In addition, it would be nice if the 'out of disk' error could be
> > > deferred until grub actually tries to read a block that is out of range,
> > > as grub-legacy does
> >
> > The problem is that it actually tries to do that, because the RAID
> > superblock is located at the end of the partition.
>
> Oh, good point. My only remaining point of confusion is how I am able to
> access the (md0) device fine from within grub, since it can't read the
> superblocks. Does it just assume that any pc partitions of type 0xfd
> with unreadable superblocks are part of a RAID 1 array, or is it
> possible that something else is going on?
>
> My array is made up of partitions on two disks; the first is the primary
> master on the motherboard's ATA controller, and the second is on a
> Promise PCI card.
>
> Now, AFAIK the promise card cannot do 48-bit LBA addressing without a
> bios flash that I never applied. But is it possible that my
> motherboard's controller is able to do 48-bit addressing?
>
> If this were the case it would explain how grub is able to access an
> (md0) device (via the fully-readable (hd0,2) device), and also where the
> 'out of disk' error comes from (from trying to read the superblock of
> (hd3,2)).
>
> If this is the case, it would be nice if the raid module would only
> throw a warning if some of the component devices could not be added to a
> RAID1 array.
I think the handling of errors/warnings in GRUB2 can probably be
improved, but it shouldn't give an error in this case. See the code in
raid.c line 344. Can you test whether this patch makes the error go away?
Index: disk/raid.c
===
RCS file: /cvsroot/grub/grub2/disk/raid.c,v
retrieving revision 1.3
diff -u -p -r1.3 raid.c
--- disk/raid.c 17 May 2007 23:23:03 - 1.3
+++ disk/raid.c 21 May 2007 13:10:25 -
@@ -344,7 +344,10 @@ grub_raid_scan_device (const char *name)
err = grub_disk_read (disk, sector, 0, GRUB_RAID_SB_BYTES, (char *) &sb);
grub_disk_close (disk);
if (err)
-return 0;
+{
+ grub_errno = GRUB_ERR_NONE;
+ return 0;
+ }
/* Look whether there is a RAID superblock. */
if (sb.md_magic != GRUB_RAID_SB_MAGIC)
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Moving to another SCM
At Tue, 22 May 2007 20:52:58 +0200, Robert Millan wrote: > > On Mon, May 21, 2007 at 03:38:47PM -0300, Otavio Salvador wrote: > > Hello, > > > > I'd like to ask if GRUB is planning to move to another SCM? > > > > I've been using GIT for a while and it looks great for the kinda of > > work done at GRUB since there're a lot of people working together and > > sometimes a feature need some time to get mature enough to be merged > > in and this fits very well how GIT is used. > > > > There's any plans for it? What's the options that current developers > > have in mind? > > I'm not very familiar with GIT, although my understanding is that it has > advantages related to branching and also a nice regression test feature. > > Also, for distributors for Debian, it seems to be useful since the Debian > package can be considered a branch from official GRUB in the SCM itself. > > Anyway, I find CVS very awkward to work with. I tend to agree with Otavio > that a change would be a good thing (be it to git, svn...). You get used to it over the years. :-) But we should switch to something else yes. The savannah admins are working on supporting svn and git: https://savannah.gnu.org/maintenance/WhenSvN and https://savannah.gnu.org/maintenance/Git It will depend on when savannah starts offering it when we can switch. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: installing on x86_64
At Sat, 26 May 2007 18:14:23 -0500, Jerone Young wrote: > > Are you sure you did this on an x86-64 install. Current CVS still > suffers from the not being able to properly compile on x86-64 systems. It compiles fine here... are you sure your compiler can generate 32-bit code? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: installing on x86_64
At Sat, 26 May 2007 19:44:09 -0500,
Jerone Young wrote:
>
> Really..exactly waht distro and gcc version are you using. There is
> still lack for _start with compiling 32-bit binaries using gcc x86-64.
> I'm currently been testing on Fedora Core 7 beta and I see the problem
> consistently (though I do need to update it some). Others have
> reported the problem in the past also. What I do need to know is how
> you are successfully compiling it . Is your gcc version less then 4.x
> ?
I'm using Debian, both gcc 4.1 and 4.2 works. Missing _start means
that your compiler can't generate 32-bit programs. Test this first by
compiling a simple test program (e.g. "int main (){return 0;}") using
-m32. That probably doesn't result in a working executable either.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: linux headers
At Mon, 4 Jun 2007 18:59:30 +0200, Robert Millan wrote: > > > How is it that util/biosdisk.c makes effort to avoid including Linux headers > and defines Linux ioctl macros on its own? > > This adds an extra maintainance burden, so I guess there must be a reason to > do > it, but can't think of one.. It only defines it when it isn't defined yet. It seems to be taken from GRUB Legacy's lib/device.c and probably comes from a time those things weren't always defined. The checks for glibc also don't seem that useful to me. It needs a cleanup. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GSoC: CD-ROM booting options
At Mon, 04 Jun 2007 17:10:53 +0200, Marco Gerards wrote: > > "Alex Roman" <[EMAIL PROTECTED]> writes: > > > Personally, I think both are important to support, but I want to see > > what the majority of developers and users think we should support. > > Just focus on one thing first. I think booting from a BIOS that > supports CDROMs already won't be too hard. I think booting installation and live CDs directly from the BIOS will be the most used way to boot a CD, so I guess support for that is the most important. And it indeed shouldn't be that hard. Jeroen dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: a pair of things I found when debugging..
At Mon, 4 Jun 2007 21:03:11 +0200,
Robert Millan wrote:
>
> On Mon, Jun 04, 2007 at 09:00:21PM +0200, Robert Millan wrote:
> > - struct grub_pc_partition *pcdata = 0;
> > + struct grub_pc_partition *pcdata = NULL;
> >
> >[...]
> >
> > - char *drive_name = 0;
> > + char *drive_name = NULL;
>
> I generaly find that NULL makes it clearer for pointers, do you have a
> preference for 0 on these?
I agree.
> > @@ -816,8 +816,7 @@
> > if (dos_part < 0)
> >{
> > grub_disk_close (disk);
> > - grub_error (GRUB_ERR_BAD_DEVICE,
> > - "cannot find the partition of `%s'", os_dev);
> > + grub_util_error ("cannot find the partition of `%s'", os_dev);
> > return 0;
>
> Not sure what I'm missing, but these grub_error calls seem to be pretty
> useless. This one in particular was the culprit to one of the powerpc
> problems I just fixed, and I had to replace it with grub_util_error() to find
> out.
Yes, as I already wrote in relation to the RAID thing, handling of
errors and warnings need some care.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
At Sun, 3 Jun 2007 23:37:25 +0200, Robert Millan wrote: > Here's another report with issues about LVM. I notice the device name is > different than previous ones (note: device.map only has /dev/sda). The problem seems to be that grub-install is probing for things outside of /boot. GRUB shouldn't use anything outside of /boot to start. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
At Mon, 4 Jun 2007 22:30:12 +0200, Robert Millan wrote: > > On Mon, Jun 04, 2007 at 10:11:30PM +0200, Jeroen Dekkers wrote: > > At Sun, 3 Jun 2007 23:37:25 +0200, > > Robert Millan wrote: > > > Here's another report with issues about LVM. I notice the device name is > > > different than previous ones (note: device.map only has /dev/sda). > > > > The problem seems to be that grub-install is probing for things > > outside of /boot. GRUB shouldn't use anything outside of /boot to > > start. > > update-grub calls grub-probe a few times, in different places. Some of them > could be avoided, but at least these appear to be necessary: > > # Device containing our userland. Typicaly used for root= parameter. > GRUB_DEVICE="`grub-probe --target=device /`" > > # Filesystem for the device containing our userland. Used for stuff like > # choosing Hurd filesystem module. > GRUB_FS="`grub-probe --target=fs /`" > > See also 00_header.in for code that might scan /usr/share/ in search of > unifont. If e.g. /usr is a separate partition, grub needs to know that > somehow to load the font later. GRUB shouldn't load anything from any other partition than /boot. The whole reason that we have /boot partitions is that it might be possible that the rest isn't readable by GRUB. The reason we have grub-probe is to find out which modules need to be in core.img. You're currently using grub-probe for other things and that isn't always going to work. Grub-probe won't be able to parse encrypted LVM volumes for example, and thus grub-probe --target=fs / is never going to work if your / is encrypted. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: QEMU and ElTorito and EDD 3
At Wed, 13 Jun 2007 16:28:42 +0200,
Robert Millan wrote:
>
> On Wed, Jun 13, 2007 at 08:33:02AM -0400, Alex Roman wrote:
> > I've been messing around with int 13h calls and it seems that the QEMU
> > BIOS supports EDD 3 extensions.
> >
> > However, it does not support ElTorito extensions... I called the 4D
> > function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
> > "nice" informative message:
> > "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)
> >
> > ... which I will (report, that is) :)
> >
> > But I thought I'd share the find first.. Looks like I'm going to have
> > to use either a different emulator (vmware&co.) or a real PC... What
> > do you folks suggest?
>
> I was about to suggest bochs, but then found:
>
> ./bochs-2.3/bios/rombios.c: BX_PANIC("Int13 eltorito call with
> AX=%04x. Please report\n",AX);
>
> You could also try with virtualbox, which is (non-copyleft) free software. It
> doesn't work on x86_64 hosts though.
Aren't they also using the bochs BIOS?
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: 64 Bit Support?
At Sun, 17 Jun 2007 17:11:44 -0600, David Broadfoot wrote: > I am wondering if there is plans for Grub 2 to be able to be compiled > and run in a 64 bit enviroment. I am a part of the Cross-LFS Dev. team, > and Under the pure 64 bit system, we have to use a 32 static version of > grub compiled on a 32 computer in order to get it to boot, or use > *Cough* lilo. > > Thanks for your time It already works. You need to have a compiler that can generate 32-bit code however, because the boot part of GRUB needs to be in 32-bit. We currently also have a build dependency on 32-bit libc and liblzo. I'm using a pure 64-bit Debian system with 32-bit libc and liblzo packages installed and that works fine. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: 64 Bit Support?
At Sun, 17 Jun 2007 11:37:15 +0200, Stefan Reinauer wrote: > > * Robert Millan <[EMAIL PROTECTED]> [070617 11:26]: > > On Sun, Jun 17, 2007 at 02:16:41AM +0200, Jeroen Dekkers wrote: > > > At Sun, 17 Jun 2007 17:11:44 -0600, > > > David Broadfoot wrote: > > > > I am wondering if there is plans for Grub 2 to be able to be compiled > > > > and run in a 64 bit enviroment. I am a part of the Cross-LFS Dev. team, > > > > and Under the pure 64 bit system, we have to use a 32 static version of > > > > grub compiled on a 32 computer in order to get it to boot, or use > > > > *Cough* lilo. > > > > > > > > Thanks for your time > > Interesting would also be to boot pure 64bit kernels. I think some of > the BSDs have their bootloader switch to 64bit long mode, so the kernel > does not have to dot this anymore. Maybe grub could do the same thing. To enable long mode you have to enable paging and I don't think the bootloader should be doing things like that. I also don't see any problems with the OS enabling long mode. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: 64 Bit Support?
At Sun, 17 Jun 2007 12:29:43 -0700, Andrei E. Warkentin wrote: > Heh, UEFI x64 runs in long mode, and it has no problems doing things > like that. To linearly map the first 4GB you need a whole of 24KB > worth of page tables (using 2m pages). And the code to enter long > mode directly from RM is pretty trivial. RM->16PM->LM. But UEFI doesn't need to be booted by a BIOS. We actually want to install the GRUB2 core into the gap that exists between the partition table and the first partition that usually starts on the second head. This gap is 62 sectors, or 31KB. Just a bit more than your page tables. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: update-grub on LVM
At Sat, 23 Jun 2007 10:10:11 +0200, Robert Millan wrote: > This seems a bit strange: > > [EMAIL PROTECTED]:~$ sudo grub-probe -t drive / > (orthanc-root) > [EMAIL PROTECTED]:~$ grep " / " /proc/mounts > rootfs / rootfs rw 0 0 > /dev/mapper/orthanc-root / ext3 rw,data=ordered 0 0 > > Is it the intended? It (partly) breaks update-grub. Makes it think that / is > accessible and adds unifont stuff, etc. But / is accessible, right? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPL version 3
At Wed, 4 Jul 2007 21:40:15 +0200, Yoshinori K. Okuji wrote: > So I bet that GRUB Legacy should remain under GPLv2. But this can cause some > problem potentially. Let's say, we find the same bug both in GRUB Legacy and > in GRUB 2. In the current trend, the bug would be fixed in GRUB 2 sooner. But > this fix may not be backported to GRUB Legacy as it is, once GRUB 2 migrates > to GPLv3, because of the license incompatibility. Thus this means that the > maintenance of GRUB Legacy would be harder. Are you sure about this? Given that we've assigned copyright to the FSF, the FSF can decide under which free software license to license that code. So I don't really see why we can't release the same code under GPLv2 or later in GRUB Legacy and under GPLv3 or later in GRUB2. On the other hand, there have been 4 changelog entries for GRUB Legacy in the past year, so we shouldn't really make a big deal out of this. So IMO we should just go for GPLv3. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPL version 3
At Thu, 5 Jul 2007 01:06:50 +0200, Stefan Reinauer wrote: > > * Jeroen Dekkers <[EMAIL PROTECTED]> [070704 23:10]: > > Are you sure about this? Given that we've assigned copyright to the > > FSF, the FSF can decide under which free software license to license > > that code. So I don't really see why we can't release the same code > > under GPLv2 or later in GRUB Legacy and under GPLv3 or later in GRUB2. > > Oh the "v2 or later" and "v3 or later" clauses are more than critical > from a lawyers view. How can you have a contract partner and the FSF > decide upon the license / contract that applies on your code without > that contract existing yet. If, at some point in the future the FSF > would decide to add a clause to GPLv4 "The author of this software pays > a monthly fee of US$100 to the FSF" and the user of this software > decides to apply GPLv4 to the software because the author allowed it, > you would have to pay. The GPL is clearly designed to be a license that > protects the _user_ not the _author_ of a given piece of software. > No, of course I do not believe that the FSF will ever do something like > the above. But law is not about beliefs. But there are two reasons the FSF can't do that. The first is that the GPL says that future versions will be in the same spirit. Having a monthly fee makes the software non-free, which is certainly not in the same spirit. The second problem is that if the FSF would release the software under a non-free license, they would violate the copyright assignment contract, because they agreed to keep the software free there. So I don't think this is really a big problem. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Timed wait/sleep
At Sun, 22 Jul 2007 17:38:14 -0400, Alex Roman wrote: > > Sorry, what do you mean by busy waiting? Busy waiting is looping while checking whether a condition changed. E.g. while(condition_is_true()); It would be nicer to let the processor sleep for a while. I'm not sure whether we can actually do that easily in GRUB however... Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using GRUB2 for booting from CD
At Mon, 13 Aug 2007 20:40:27 -0400, Alex Roman wrote: > > OK, I've done the following in grub-emu... > > I have a map file that looks like this: > (fd0) floppy.img > (cd0) grub2-iso.iso > > grub2-iso.iso is an iso I generate using genisoimage (mkisofs). I can > mount it just fine. > > floppy.img is a floppy image I generate... It contains grub, basically > and a few modules. > > I run grub-emu -d grub2 -m mapfile -r fd0 > > grub2 is my build directory. > > I tried ls (cd0)/ but that did not work. The iso9660_mount function is > saying that it couldn't read the superblock. > > Then I saw on your (Marco) blog about the loopback command. So I tried > it as follows: > > loopback cd1 (host)/path/to/grub2-iso.iso > > Now, ls (cd1)/ goes a bit further, it can read the superblock, but it > says it couldn't find the magic "CD001". I printed the data it reads > from the ISO and it's all 0's... > > > Am I doing anything wrong from what you can see here? I'd like to know > if it's something I'm doing wrong in my procedure or in my code... Read what's in the file directly and compare it to what grub-emu reads. If it reads something different than that's a bug in the grub-emu or loopback code. Also don't forget about the possiblity that qemu might be buggy, especially if you're using bios functions that aren't really used that much. Testing on real hardware is really necessary sometimes. And whether your code is wrong or not is very difficult to tell if you don't post your code... Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Using GRUB2 for booting from CD
At Wed, 15 Aug 2007 09:54:58 -0400, Alex Roman wrote: > > On 15/08/07, Jeroen Dekkers <[EMAIL PROTECTED]> wrote: > > Also don't forget about the possiblity that qemu might be buggy, > > especially if you're using bios functions that aren't really used that > > much. Testing on real hardware is really necessary sometimes. > > Yes, I've gotten it to work farther along... It starts querying the > CD-ROM device for information... The problem right now is that the > c/h/s values that bochs/qemu returns when doing a diskinfo int13 > extension check are all 0x... Same code on VMWare doesn't work > because it seems that VMWare doesn't support that EDD extensions on > their CD-ROM drive :(... I'll try it on my main PC today and let you > know. Why are you using CHS and not LBA? Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
At Sat, 22 Dec 2007 09:28:28 +0100, Yoshinori K. Okuji wrote: > > On Tuesday 18 December 2007 13:05, Otavio Salvador wrote: > > Personally I don't like bazaar due performance problem. It's really > > slow for big projects (it wouldn't be a big problem since GRUB is a > > small one) and it changes its data format too ofthen. > > Hmm, I thought they have fixed the performance issues already? About the data > format, I have no idea. jbailey, do you have any comment? ;) I've used bzr when working on my summer of code project 1.5 years ago and didn't have any issues with performance. And this was before they did all the performance improvements. Maybe with big source trees like Linux it's still too slow, but for GRUB this is really no problem. The changes in data format shouldn't really be any problem in practice, because newer versions can still read the older disk format and the network protocol doesn't change most of the time. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] split realmode and loader routines out of startup.S
At Tue, 16 Oct 2007 23:09:07 +0200, Robert Millan wrote: > This patch splits realmode and loader routines out of startup.S. The idea > is that the LinuxBIOS port can be adapted to share more code with the rest > of GRUB instead of duplicating it. > > This is quite critical stuff, so even if the change seems trivial I'd suggest > being careful, since I don't trust myself too much. Of course, I've tested > that it can still boot Linux and Multiboot (on qemu only). Perhaps testing > on real hardware would be appropiate (but I don't have this handy atm). > * kern/i386/pc/startup.S (protstack): Moved to ... > * kern/i386/realmode.S (protstack): ... here. > * kern/i386/pc/startup.S (gdt): Moved to ... > * kern/i386/realmode.S (gdt): ... here. > * kern/i386/pc/startup.S (prot_to_real): Moved to ... > * kern/i386/realmode.S (prot_to_real): ... here. > > * kern/i386/pc/startup.S: Include `kern/i386/loader.S' and > `kern/i386/realmode.S'. Why did you move prot_to_real to realmode.S, but not real_to_prot? That seems a bit strange to me... Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] allow user-configurable menucolor
At Thu, 3 Jan 2008 16:35:33 +0100, Robert Millan wrote: > diff -x '*~' -x '*.mk' -Nurp grub2/include/grub/normal.h > grub2.color/include/grub/normal.h > --- grub2/include/grub/normal.h 2007-07-22 01:32:22.0 +0200 > +++ grub2.color/include/grub/normal.h 2008-01-03 16:12:53.0 +0100 > @@ -1,7 +1,7 @@ > /* normal.h - prototypes for the normal mode */ > /* > * GRUB -- GRand Unified Bootloader > - * Copyright (C) 2002,2003,2005,2006,2007 Free Software Foundation, Inc. > + * Copyright (C) 2002,2003,2005,2006,2007,2008 Free Software Foundation, > Inc. > * > * GRUB is free software: you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > @@ -154,6 +154,9 @@ grub_err_t grub_normal_print_device_info > grub_err_t grub_normal_menu_addentry (const char *title, > struct grub_script *script, > const char *sourcecode); > +char *grub_env_write_color_normal (struct grub_env_var *var, const char > *val); > +char *grub_env_write_color_highlight (struct grub_env_var *var, const char > *val); > +void grub_wait_after_message (void); You should actually also include grub/env.h if you use struct grub_env_var in the prototypes. I've fixed that in CVS. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] allow user-configurable menucolor
At Sun, 6 Jan 2008 00:42:40 +0100, Robert Millan wrote: > > On Sat, Jan 05, 2008 at 10:45:46PM +0100, Jeroen Dekkers wrote: > > You should actually also include grub/env.h if you use struct > > grub_env_var in the prototypes. > > Uhm, I included it in normal/color.c to satisfy the dependencies: > > normal/color.c:#include > normal/color.c:grub_env_write_color_normal (struct grub_env_var *var > __attribute__ ((unused)), > normal/color.c:grub_env_write_color_highlight (struct grub_env_var *var > __attribute__ ((unused)), > > but your idea seems better. I suppose we can remove it from there now? Yes, but normal.h is included by lots of other files that don't always include env.h before they include normal.h. > Btw, nice to see you around here. Do you have any news about the CD-ROM > GSoC ? I looked at the tarball from google.com, but CD access seems > unfinished (I couldn't access the CD neither in qemu nor in real hw). It should work, but I didn't have the time to test it at the end of the summer. I guess you can simply mail Alex if you have any questions... Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
