Re: [PATCH] Preboot support
Yoshinori K. Okuji wrote:
- I don't understand how preboot_func and preboot_rest_func are different. At
least, not obvious. Can you elaborate on them?
preboot_rest_func is a function which should undo any action taken by
preboot_func. It's used if either loader aborts due to an error or
returns (which is possible on some platforms)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/ChangeLog b/ChangeLog
index dd28915..1b2bbda 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2009-04-06 Vladimir Serbinenko
+
+ Preboot hooks support
+
+ * commands/boot.c (struct grub_preboot_t): new declaration
+ (preboots_head): new variable
+ (preboots_tail): likewise
+ (grub_loader_register_preboot_hook): new function
+ (grub_loader_unregister_preboot_hook): likewise
+ (grub_loader_set): launch preboot hooks
+ * include/grub/loader.h (grub_loader_register_preboot_hook):
+ new declaration
+ (grub_loader_unregister_preboot_hook): likewise
+
2009-03-22 Vladimir Serbinenko
Move loader out of the kernel
diff --git a/commands/boot.c b/commands/boot.c
index 1cc98eb..b417798 100644
--- a/commands/boot.c
+++ b/commands/boot.c
@@ -22,12 +22,24 @@
#include
#include
#include
+#include
static grub_err_t (*grub_loader_boot_func) (void);
static grub_err_t (*grub_loader_unload_func) (void);
static int grub_loader_noreturn;
+struct grub_preboot_t
+{
+ grub_err_t (*preboot_func) (int);
+ grub_err_t (*preboot_rest_func) (void);
+ int prio;
+ struct grub_preboot_t *next;
+ struct grub_preboot_t *prev;
+};
+
static int grub_loader_loaded;
+static struct grub_preboot_t *preboots_head = 0,
+ *preboots_tail = 0;
int
grub_loader_is_loaded (void)
@@ -35,6 +47,68 @@ grub_loader_is_loaded (void)
return grub_loader_loaded;
}
+/* Register a preboot hook. */
+void *
+grub_loader_register_preboot_hook (grub_err_t (*preboot_func) (int noreturn),
+ grub_err_t (*preboot_rest_func) (void),
+ grub_loader_preboot_hook_prio_t prio)
+{
+ struct grub_preboot_t *cur, *new_preboot;
+
+ if (! preboot_func && ! preboot_rest_func)
+return 0;
+
+ new_preboot = (struct grub_preboot_t *)
+grub_malloc (sizeof (struct grub_preboot_t));
+ if (! new_preboot)
+{
+ grub_error (GRUB_ERR_OUT_OF_MEMORY, "hook not added");
+ return 0;
+}
+
+ new_preboot->preboot_func = preboot_func;
+ new_preboot->preboot_rest_func = preboot_rest_func;
+ new_preboot->prio = prio;
+
+ for (cur = preboots_head; cur && cur->prio > prio; cur = cur->next);
+
+ if (cur)
+{
+ new_preboot->next = cur;
+ new_preboot->prev = cur->prev;
+ cur->prev = new_preboot;
+}
+ else
+{
+ new_preboot->next = 0;
+ new_preboot->prev = preboots_tail;
+ preboots_tail = new_preboot;
+}
+ if (new_preboot->prev)
+new_preboot->prev->next = new_preboot;
+ else
+preboots_head = new_preboot;
+
+ return new_preboot;
+}
+
+void
+grub_loader_unregister_preboot_hook (void *hnd)
+{
+ struct grub_preboot_t *preb = hnd;
+
+ if (preb->next)
+preb->next->prev = preb->prev;
+ else
+preboots_tail = preb->prev;
+ if (preb->prev)
+preb->prev->next = preb->next;
+ else
+preboots_head = preb->next;
+
+ grub_free (preb);
+}
+
void
grub_loader_set (grub_err_t (*boot) (void),
grub_err_t (*unload) (void),
@@ -65,13 +139,34 @@ grub_loader_unset(void)
grub_err_t
grub_loader_boot (void)
{
+ grub_err_t err = GRUB_ERR_NONE;
+ struct grub_preboot_t *cur;
+
if (! grub_loader_loaded)
return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");
if (grub_loader_noreturn)
grub_machine_fini ();
-
- return (grub_loader_boot_func) ();
+
+ for (cur = preboots_head; cur; cur = cur->next)
+{
+ err = cur->preboot_func (grub_loader_noreturn);
+ if (err)
+ {
+ for (cur = cur->prev; cur; cur = cur->prev)
+ cur->preboot_rest_func ();
+ return err;
+ }
+}
+ err = (grub_loader_boot_func) ();
+
+ for (cur = preboots_tail; cur; cur = cur->prev)
+if (! err)
+ err = cur->preboot_rest_func ();
+else
+ cur->preboot_rest_func ();
+
+ return err;
}
/* boot */
diff --git a/include/grub/loader.h b/include/grub/loader.h
index 185d297..319f3c5 100644
--- a/include/grub/loader.h
+++ b/include/grub/loader.h
@@ -41,4 +41,26 @@ void grub_loader_unset (void);
depending on the setting by grub_loader_set. */
grub_err_t grub_loader_boot (void);
+/* The space between numbers is intentional for the simplicity of adding new
+ values even if external modules use them. */
+typedef enum {
+ /* A preboot hook which can use everything and turns nothing off. */
+ GRUB_LOADER_PREBOOT_HOOK_PRIO_NORMAL = 400,
+ /* A preboot hook which can't use disks and may stop disks. */
+ GRUB_LOADER_PREBOOT_HOOK_PRIO_DISK = 300,
+ /* A preboot hook which can't use disks or console and may sto
Re: [PATCH] Preboot support
The way it looks to me is that preboot_func is the function to be executed a preboot time, whereas preboot_rest_func is a cleanup function to be called to "restore" things to the pre-preboot_func state. Something like this anyway.. its not yet real clear to me either. phcoder wrote: Yoshinori K. Okuji wrote: - I don't understand how preboot_func and preboot_rest_func are different. At least, not obvious. Can you elaborate on them? preboot_rest_func is a function which should undo any action taken by preboot_func. It's used if either loader aborts due to an error or returns (which is possible on some platforms) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
I have your preboot hooks patch incorporated into grub-r2106 along with a suitably updated version of drivemap, which remains flawlessly working with 2nd-harddisk Windows XP boots (grub being installed on the 1st harddisk along with Linux). Had to make a few minor changes to the preboot hooks patch to get it to build in r2106. I have also incorporated your mmap services patch as well (again with minor mods to build in r2106). My question at this point, is how best to incorporate mmap services into drivemap. I see that in mmap/i386/pc/mmap.c there is some sort of support for int12 and int15 services. Should I incorporate the drivemap int13 handler here ? Looks relatively straightforward -- just insert the asm handler into mmap/i386/pc/mmap_helper.S and update mmap/i386/pc/mmap.c -- (except for how I place the mapped drives table), or, should I use the mmap.c code as a template for the drivemap int13 handler plus mapped drives table ? thanks for any help/suggestions, John phcoder wrote: I haven't yet looked in depth in drivemap patch but it has some problems. It uses preboot hook interface for which I proposed an update in my recent patch "preboot hooks". Also it doesn't update memorymap correctly. For this it should use my "mmap services" interface John Stanley wrote: Thanks Felix, Hurm.. Well, if anyone is interested, I have just made a couple of additional updates to the drivemap.path.8 code, and now with r2104 the "unaligned pointer" issue is gone, and it is working great on my systems. I can post the patch if you or anyone else is interested. John Felix Zielcke wrote: Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: Hi all, I was wondering what the current status of a grub2 port of the grub-0.97 "map" and "rootnoverify" commands is? I have found some work done to this end in the "drivemap.patch" work, but I find nothing more recent than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. Could anyone give me any pointers/direction on what might be happening here? Could it be that the "norootverify"-functionality of grub-legasy is lacking here? Or, perhaps, that the "--force" option is not being honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
Yes it is. Also it's better to use grub_mmap_iterate instead of basing the location on 0x413 value. How to do it look at mmap/i386/pc/mmap.c John Stanley wrote: I'd be happy to sign a copywrite statement, no problem -- how do I go about it ? Is this what you're referring to: /* BDA offset 0x13 contains the top of conventional memory, in kiB. */ grub_uint16_t *bpa_freekb = (grub_uint16_t*)0x0413; . . *bpa_freekb -= payload_sizekb; where payload_sizekb is the size of the drivemap int13 handler + its mapped drive table ? phcoder wrote: If you want your code to be incorporated you need to sign the copyright assignment. John Stanley wrote: I have also incorporated your mmap services patch as well (again with minor mods to build in r2106). My question at this point, is how best to incorporate mmap services into drivemap. I see that in mmap/i386/pc/mmap.c there is some sort of support for int12 and int15 services. Should I incorporate the drivemap int13 handler here ? Looks relatively straightforward -- just insert the asm handler into mmap/i386/pc/mmap_helper.S and update mmap/i386/pc/mmap.c -- (except for how I place the mapped drives table), or, should I use the mmap.c code as a template for the drivemap int13 handler plus mapped drives table ? Don't do it that way. It merges 2 unrelated modules. At some point drivermap does following *bpaMemInKb -= ...; But this isn't correct because mmap interrupts still list the memory used by drivemap as available. Use grub_mmap_register instead of it. thanks for any help/suggestions, John phcoder wrote: I haven't yet looked in depth in drivemap patch but it has some problems. It uses preboot hook interface for which I proposed an update in my recent patch "preboot hooks". Also it doesn't update memorymap correctly. For this it should use my "mmap services" interface John Stanley wrote: Thanks Felix, Hurm.. Well, if anyone is interested, I have just made a couple of additional updates to the drivemap.path.8 code, and now with r2104 the "unaligned pointer" issue is gone, and it is working great on my systems. I can post the patch if you or anyone else is interested. John Felix Zielcke wrote: Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: Hi all, I was wondering what the current status of a grub2 port of the grub-0.97 "map" and "rootnoverify" commands is? I have found some work done to this end in the "drivemap.patch" work, but I find nothing more recent than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. Could anyone give me any pointers/direction on what might be happening here? Could it be that the "norootverify"-functionality of grub-legasy is lacking here? Or, perhaps, that the "--force" option is not being honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
If you want your code to be incorporated you need to sign the copyright assignment. John Stanley wrote: I have also incorporated your mmap services patch as well (again with minor mods to build in r2106). My question at this point, is how best to incorporate mmap services into drivemap. I see that in mmap/i386/pc/mmap.c there is some sort of support for int12 and int15 services. Should I incorporate the drivemap int13 handler here ? Looks relatively straightforward -- just insert the asm handler into mmap/i386/pc/mmap_helper.S and update mmap/i386/pc/mmap.c -- (except for how I place the mapped drives table), or, should I use the mmap.c code as a template for the drivemap int13 handler plus mapped drives table ? Don't do it that way. It merges 2 unrelated modules. At some point drivermap does following *bpaMemInKb -= ...; But this isn't correct because mmap interrupts still list the memory used by drivemap as available. Use grub_mmap_register instead of it. thanks for any help/suggestions, John phcoder wrote: I haven't yet looked in depth in drivemap patch but it has some problems. It uses preboot hook interface for which I proposed an update in my recent patch "preboot hooks". Also it doesn't update memorymap correctly. For this it should use my "mmap services" interface John Stanley wrote: Thanks Felix, Hurm.. Well, if anyone is interested, I have just made a couple of additional updates to the drivemap.path.8 code, and now with r2104 the "unaligned pointer" issue is gone, and it is working great on my systems. I can post the patch if you or anyone else is interested. John Felix Zielcke wrote: Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: Hi all, I was wondering what the current status of a grub2 port of the grub-0.97 "map" and "rootnoverify" commands is? I have found some work done to this end in the "drivemap.patch" work, but I find nothing more recent than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. Could anyone give me any pointers/direction on what might be happening here? Could it be that the "norootverify"-functionality of grub-legasy is lacking here? Or, perhaps, that the "--force" option is not being honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
I'd be happy to sign a copywrite statement, no problem -- how do I go about it ? Is this what you're referring to: /* BDA offset 0x13 contains the top of conventional memory, in kiB. */ grub_uint16_t *bpa_freekb = (grub_uint16_t*)0x0413; . . *bpa_freekb -= payload_sizekb; where payload_sizekb is the size of the drivemap int13 handler + its mapped drive table ? phcoder wrote: If you want your code to be incorporated you need to sign the copyright assignment. John Stanley wrote: I have also incorporated your mmap services patch as well (again with minor mods to build in r2106). My question at this point, is how best to incorporate mmap services into drivemap. I see that in mmap/i386/pc/mmap.c there is some sort of support for int12 and int15 services. Should I incorporate the drivemap int13 handler here ? Looks relatively straightforward -- just insert the asm handler into mmap/i386/pc/mmap_helper.S and update mmap/i386/pc/mmap.c -- (except for how I place the mapped drives table), or, should I use the mmap.c code as a template for the drivemap int13 handler plus mapped drives table ? Don't do it that way. It merges 2 unrelated modules. At some point drivermap does following *bpaMemInKb -= ...; But this isn't correct because mmap interrupts still list the memory used by drivemap as available. Use grub_mmap_register instead of it. thanks for any help/suggestions, John phcoder wrote: I haven't yet looked in depth in drivemap patch but it has some problems. It uses preboot hook interface for which I proposed an update in my recent patch "preboot hooks". Also it doesn't update memorymap correctly. For this it should use my "mmap services" interface John Stanley wrote: Thanks Felix, Hurm.. Well, if anyone is interested, I have just made a couple of additional updates to the drivemap.path.8 code, and now with r2104 the "unaligned pointer" issue is gone, and it is working great on my systems. I can post the patch if you or anyone else is interested. John Felix Zielcke wrote: Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: Hi all, I was wondering what the current status of a grub2 port of the grub-0.97 "map" and "rootnoverify" commands is? I have found some work done to this end in the "drivemap.patch" work, but I find nothing more recent than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. Could anyone give me any pointers/direction on what might be happening here? Could it be that the "norootverify"-functionality of grub-legasy is lacking here? Or, perhaps, that the "--force" option is not being honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove BSD partition number from install_drive/grub_drive in grub-install
Hello Great, thanks. On Wed, Apr 15, 2009 at 7:40 AM, Joey Korkames wrote: > You can checkout the code via: > svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 > Then use the autocompile.sh script that was posted earlier to make builds of > grub2 or you can wait for the nightly autobuilder to be set-up and just > download its results (from wherever they will be announced). > > GRUB2 is not making frequent stable releases yet. > > -joey > > Chip Panarchy writes: > >> Awesome. >> >> BTW: How do these update to GRUB2 work, I mean to the patches, once >> proven automatically get integrated into GRUB2 (and released to the >> official website)? >> > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
Commited phcoder wrote: On the IRC Yoshinori K. Okuji agreed that this move can be useful in cases like lvm+raid and luks. Any further oppositions? phcoder wrote: I was thinking about something more finished like the possibility of handling multiple preboot and to undo the operations in case of failed or returned boot. Potentially it could be moved to a separate module but it results in a reverse dependency and somewhat ugly code Vesa Jääskeläinen wrote: phcoder wrote: This usage case isn't the main target case. If you embed the loader (which tend to be quite big) then you already have an overhead from loader module. Why are you so concerned with overhead of boot.mod? But on the other hand this forces all the people in other cases to have boot code in core.img. I want to add preboot hooks and don't want increment size of kernel. multiboot.mod currently increases the size by around 11KB. And my patch doesn't restrict you from putting loader in core.img in any way Even if you add the preboot hooks there, it should only cause size affect in couple of bytes for uncompressed image. Like in following "sketch": ... preboot_handler_address: dd 0 ... cmp [preboot_handler_address], 0 je no_preboot_handler call [preboot_handler_address] no_preboot_handler: ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: grub: Fix handling of long printf arguments on 64-bit.
commited
Pavel Roskin wrote:
On Mon, 2009-04-13 at 00:19 +0200, phcoder wrote:
I already understood what you meant in first mail. Sorry for not paying
attention to this detail. Here is my proposition. IT decreases the size
from 31224 to 31068 bytes. I tested it with following input
grub_printf ("Hello World: %d %ld %lld %x %lx %llx %u %lu %llu\n",
0x, 0x, 0xLL,
0x, 0x, 0xLL,
0x, 0x, 0xLL);
grub_printf ("Hello World: %d %ld %lld %x %lx %llx %u %lu %llu\n",
0x0fff, 0x0fff, 0x0fffLL,
0x0fff, 0x0fff, 0x0fffLL,
0x0fff, 0x0fff, 0x0fffLL);
Output was:
Hello World: -1 -1 -1 4294967295
4294967295 18446744073709551615
Hello World: 268435455 268435455 1152921504606846975 fff fff
fff 268435455 268435455 1152921504606846975
Thanks for the patch and for the test! You patch doesn't look as
pedantic as mine, but apparently the compiler can optimize you code
better. I have no objections to your patch.
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
truecrypt support in grub ?
Hello list, GRUB2 is a robust boot loader. Is it possible to have truecrypt encryption support dirctly in GRUB2 ? Then we can have truecrypt encrypted partition with linux installed and GRUB2 just decrypt it and load the kernel. Thanks ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: truecrypt support in grub ?
Hello If this is possible (and there isn't already an implementation of it) then I would also like this feature! :D Good suggestion! :P Panarchy On Wed, Apr 15, 2009 at 11:28 PM, J. Bakshi wrote: > Hello list, > > GRUB2 is a robust boot loader. Is it possible to have truecrypt encryption > support dirctly in GRUB2 ? Then we can have truecrypt encrypted partition > with linux installed and GRUB2 just decrypt it and load the kernel. > > Thanks > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot module in grub2 --with-platform=efi --target=i386
Hi, >From the wiki page you put up, you're obvious not familiar with grub2's efi support. x86_64-efi have been in grub2 for a long time, you just need to know how to build it, take a look at this page: http://grub.enbug.org/TestingOnMacbook Also, you can check out this post at ubuntu forum: http://ubuntuforums.org/showthread.php?t=995704 D4T have successfully booted both 32-bit and 64-bit linux with Xserver 1.1 and 1.2. BTW, please don't put anything you're not sure of to the wiki page, it's misleading for other users. On Wed, Apr 15, 2009 at 9:58 PM, Drew Rosen wrote: > We're interested, I've got 30 Xserves that will be paper weights pretty soon > if we don't get a 64 bit linux OS on them... rendering for 3d fx in movies. > > I'll try to start a http://grub.enbug.org/TestingOnXserve page shortly to > combine all the info we've gathered so far. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot module in grub2 --with-platform=efi --target=i386 - TestingOnXserve
Thanks Bean. Totally appreciate your help with this. I'm not familiar with the x86_64 support, and these notes were created 6 months ago, but I thought they would be a good place to start... Don't hesitate to remove anything you think is misleading. I'm going to try to update it with better info as soon as possible. Also, please be clear, we are not talking about Xserver. I'm trying to run 64 Bit Linux on an Apple MacIntel Xserve. The systems I have are 2 x 2.66 Dual-Core Intel Xeon. Thanks! On Apr 15, 2009, at 8:24 AM, Bean wrote: Hi, From the wiki page you put up, you're obvious not familiar with grub2's efi support. x86_64-efi have been in grub2 for a long time, you just need to know how to build it, take a look at this page: http://grub.enbug.org/TestingOnMacbook Also, you can check out this post at ubuntu forum: http://ubuntuforums.org/showthread.php?t=995704 D4T have successfully booted both 32-bit and 64-bit linux with Xserver 1.1 and 1.2. BTW, please don't put anything you're not sure of to the wiki page, it's misleading for other users. On Wed, Apr 15, 2009 at 9:58 PM, Drew Rosen wrote: We're interested, I've got 30 Xserves that will be paper weights pretty soon if we don't get a 64 bit linux OS on them... rendering for 3d fx in movies. I'll try to start a http://grub.enbug.org/TestingOnXserve page shortly to combine all the info we've gathered so far. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: truecrypt support in grub ?
Michael Gorven has already implemented LUKS support for grub2. Using truecrypt with linux partitions is a bad idea - this encryption isn't native to it in any way and also truecrypt is under GPL-incompatible licence which means it's unlikely to be incorporated to grub (you need to figure out the on-disk layout of truecrypt and then reimplement it from scratch (but you can reuse ciphers from luks implementation)). If all you want is boot windows installed on truecrypt partition then the best way is to chainload truecrypt booter. I haven't yet looked in it myself but it seems that truecrypt booter uses mbr gap too which conflicts with grub. However it can be workarounded by dumping contents of mbr gap created by truecrypt and replicating the action of tc-mbr (can't be difficult) J. Bakshi wrote: Hello list, GRUB2 is a robust boot loader. Is it possible to have truecrypt encryption support dirctly in GRUB2 ? Then we can have truecrypt encrypted partition with linux installed and GRUB2 just decrypt it and load the kernel. Thanks ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot module in grub2 --with-platform=efi --target=i386 - TestingOnXserve
Hi, On Thu, Apr 16, 2009 at 12:23 AM, Drew Rosen wrote: > Thanks Bean. Totally appreciate your help with this. > > I'm not familiar with the x86_64 support, and these notes were created 6 > months ago, but I thought they would be a good place to start... Don't > hesitate to remove anything you think is misleading. I'm going to try to > update it with better info as soon as possible. > Oh never mind, it would be nice if you can get it working, then there is another efi platform supported by grub2. > Also, please be clear, we are not talking about Xserver. I'm trying to run > 64 Bit Linux on an Apple MacIntel Xserve. > > The systems I have are 2 x 2.66 Dual-Core Intel Xeon. > I don't know they're different, but I guess the efi firmware is more or less the same. > Thanks! > > > > On Apr 15, 2009, at 8:24 AM, Bean wrote: > >> Hi, >> >> From the wiki page you put up, you're obvious not familiar with >> grub2's efi support. x86_64-efi have been in grub2 for a long time, >> you just need to know how to build it, take a look at this page: >> >> http://grub.enbug.org/TestingOnMacbook >> >> Also, you can check out this post at ubuntu forum: >> >> http://ubuntuforums.org/showthread.php?t=995704 >> >> D4T have successfully booted both 32-bit and 64-bit linux with Xserver >> 1.1 and 1.2. >> >> BTW, please don't put anything you're not sure of to the wiki page, >> it's misleading for other users. >> >> On Wed, Apr 15, 2009 at 9:58 PM, Drew Rosen wrote: >>> >>> We're interested, I've got 30 Xserves that will be paper weights pretty >>> soon >>> if we don't get a 64 bit linux OS on them... rendering for 3d fx in >>> movies. >>> >>> I'll try to start a http://grub.enbug.org/TestingOnXserve page shortly to >>> combine all the info we've gathered so far. >> >> -- >> Bean >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 svn2059
Andreas Born wrote: BandiPat schrieb: Thanks Andreas, I just figured that out as well when testing on another machine just now. If you still have the file I sent you for svn2059, would you mind testing it on your machine as well. I'm tempted to send you the svn2059 or 2065 to compile on your current machine, to see if it behaves differently than the one I built. Be prepared though, as I'm sure you'll need to re-install svn2031 back after 2059 fails to boot. Keep your LiveCD available to reboot! :-) I tested the svn2059-60.1 build on my current Zenwalk installation. It would boot here, but I have it installed to superblock of my ext3 partition, so that might be the difference. Therefore I installed grub2 to the MBR, but like that it would work too. But I noticed two other problems: * If I drop to console with 'c' from the menu and then reload the menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is unset and I can't boot. If I drop then back to console I can set 'prefix' properly to '(hd0,3)/boot/grub' and boot from console, but configfile won't work. * With the 'linux' loader as opposed to the 'linux16' loader, I would always get a verbose splash, although I force a silent one with 'splash=silent'. My assumption was that the kernel parameters are ignored at all, but passing a wrong root resulted in a error. So either only 'splash=silent' is ignored or its something completely different. I think the problem is related to the one described in "New linux loader doesn't like vga=1". Andreas ___ Don't know if anyone is still interested in this problem or not, but I believe I have found the problem, as I have svn2070 working now on all 4 of my machines. What I found. Upon testing on my main machine, I found during my investigations, that it didn't seem that the newer Grub2 was overwriting the info in the MBR. My drive had the system on hd0,1, but listing the root set at the rescue prompt showed hd0,2 for some reason, which was from a previous setup. I manually cleared out the MBR, installed the newer version, from svn2031 that had been working, then ran grub-install again. To my delight, it worked without problems, after rebooting! Since I normally get weekly svn files to test, I wondered if doing grub-install so often caused this breakdown in overwriting the MBR? I have tested this fix on 4 different machines now and after clearing out the MBR, grub-install works correctly. So my question to you guys is this: is this a bug in Grub2 that causes it not to overwrite the MBR with new info or something else? I also concur with Andreas above about the "vga" problem, which I've noticed you guys discussing often here. Presently if I use splash=silent vga=794, the splash will not show. I get the correct resolution set, but still see the scrolling text. From the emails I've read here, this problem still seems to be present in the latest svn? Is there something extra that ./configure needs now to make this work correctly? Thanks, Pat ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
r2074 broke ata module
Hi there, I tried to use the ata module today in combination with grub2's coreboot code, but found that it broke in r2074, specifically by this hunk: --- include/grub/pci.h (revision 2073) +++ include/grub/pci.h (working copy) @@ -36,8 +36,8 @@ #define GRUB_PCI_ADDR_IO_MASK ~0x03 typedef grub_uint32_t grub_pci_id_t; -typedef int (*grub_pci_iteratefunc_t) (int bus, int device, int func, - grub_pci_id_t pciid); +typedef int NESTED_FUNC_ATTR (*grub_pci_iteratefunc_t) + (int bus, int device, int func, grub_pci_id_t pciid); typedef grub_uint32_t grub_pci_address_t; grub_pci_address_t EXPORT_FUNC(grub_pci_make_address) (int bus, int device, Reverting that hunk fixes ata for me. The symptom of a broken ata module is that it does not see any ATA disks. I'm testing on qemu, and start qemu like this: qemu -m 1024 -serial stdio -L qemu-cbv2-grub2/ -hda path-to-image Up to r2073, that image shows up as ata0, from r2074 it's simply not detected. Thoughts? Thanks, Ward. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: r2074 broke ata module
On Wed, 2009-04-15 at 17:34 -0400, Ward Vandewege wrote:
> Hi there,
>
> I tried to use the ata module today in combination with grub2's coreboot
> code, but found that it broke in r2074, specifically by this hunk:
Actually, I was looking at the warnings, and it looks like the warnings
about grub_pci_iterate() are directly related to this problem.
This patch should help.
Index: disk/ata.c
===
--- disk/ata.c (revision 2120)
+++ disk/ata.c (working copy)
@@ -375,7 +375,7 @@
return 0;
}
-static int
+static int NESTED_FUNC_ATTR
grub_ata_pciinit (int bus, int device, int func,
grub_pci_id_t pciid __attribute__((unused)))
{
Index: bus/usb/ohci.c
===
--- bus/usb/ohci.c (revision 2120)
+++ bus/usb/ohci.c (working copy)
@@ -112,8 +112,9 @@
/* Iterate over all PCI devices. Determine if a device is an OHCI
controller. If this is the case, initialize it. */
-static int grub_ohci_pci_iter (int bus, int device, int func,
- grub_pci_id_t pciid __attribute__((unused)))
+static int NESTED_FUNC_ATTR
+grub_ohci_pci_iter (int bus, int device, int func,
+ grub_pci_id_t pciid __attribute__((unused)))
{
grub_uint32_t class;
grub_uint32_t subclass;
Index: bus/usb/uhci.c
===
--- bus/usb/uhci.c (revision 2120)
+++ bus/usb/uhci.c (working copy)
@@ -137,8 +137,9 @@
/* Iterate over all PCI devices. Determine if a device is an UHCI
controller. If this is the case, initialize it. */
-static int grub_uhci_pci_iter (int bus, int device, int func,
- grub_pci_id_t pciid __attribute__((unused)))
+static int NESTED_FUNC_ATTR
+grub_uhci_pci_iter (int bus, int device, int func,
+ grub_pci_id_t pciid __attribute__((unused)))
{
grub_uint32_t class;
grub_uint32_t subclass;
Index: commands/lspci.c
===
--- commands/lspci.c(revision 2120)
+++ commands/lspci.c(working copy)
@@ -114,7 +114,7 @@
return 0;
}
-static int
+static int NESTED_FUNC_ATTR
grub_lspci_iter (int bus, int dev, int func, grub_pci_id_t pciid)
{
grub_uint32_t class;
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Code quality
Hello! It seems to me that the code quality has decreased in the last weeks. In the same time, we have a growing number of compiler warnings. It looks like there is a relationship between the two. I'll appreciate if everybody who recently contributed to GRUB looks at the remaining warnings and fixes at least some of them. I don't mean hiding the warnings, e.g. adding casts where using different types would be more appropriate or initializing variables gcc claims to be uninitialized without making sure that gcc is indeed wrong. But if there is a good fix, it should be applied. That's the warnings for the default configuration when compiled on x86_64: kern/i386/pc/init.c: In function 'grub_machine_fini': kern/i386/pc/init.c:226: warning: implicit declaration of function 'grub_stop_floppy' loader/i386/linux.c: In function 'hook': loader/i386/linux.c:234: warning: cast to pointer from integer of different size loader/i386/linux.c: In function 'grub_linux_setup_video': loader/i386/linux.c:303: warning: assignment makes integer from pointer without a cast loader/i386/pc/multiboot2.c: In function 'grub_mb2_arch_boot': loader/i386/pc/multiboot2.c:76: warning: implicit declaration of function 'grub_multiboot2_real_boot' loader/multiboot_loader.c: In function 'grub_cmd_multiboot_loader': loader/multiboot_loader.c:159: warning: 'return' with no value, in function returning non-void loader/i386/multiboot.c: In function 'grub_multiboot': loader/i386/multiboot.c:324: warning: assignment makes integer from pointer without a cast disk/ata.c: In function 'grub_ata_initialize': disk/ata.c:471: warning: passing argument 1 of 'grub_pci_iterate' from incompatible pointer type bus/usb/usbtrans.c: In function 'grub_usb_control_msg': bus/usb/usbtrans.c:94: warning: comparison between signed and unsigned bus/usb/usbtrans.c:94: warning: signed and unsigned type in conditional expression commands/lspci.c: In function 'grub_cmd_lspci': commands/lspci.c:153: warning: passing argument 1 of 'grub_pci_iterate' from incompatible pointer type bus/usb/ohci.c: In function 'grub_ohci_inithw': bus/usb/ohci.c:205: warning: passing argument 1 of 'grub_pci_iterate' from incompatible pointer type bus/usb/ohci.c: In function 'grub_ohci_transaction': bus/usb/ohci.c:235: warning: format '%02x' expects type 'unsigned int', but argument 5 has type 'grub_ohci_td_t' bus/usb/ohci.c: In function 'grub_ohci_transfer': bus/usb/ohci.c:297: warning: format '%08x' expects type 'unsigned int', but argument 5 has type 'grub_ohci_td_t' bus/usb/uhci.c: In function 'grub_uhci_inithw': bus/usb/uhci.c:305: warning: passing argument 1 of 'grub_pci_iterate' from incompatible pointer type fs/i386/pc/pxe.c:259: warning: initialization from incompatible pointer type disk/raid6_recover.c: In function 'grub_raid6_recover': disk/raid6_recover.c:95: warning: 'err[0]' may be used uninitialized in this function disk/raid6_recover.c:95: warning: 'err[1]' may be used uninitialized in this function I'm especially concerned about "'return' with no value, in function returning non-void". That's a sure way to get unpredictable behavior. Also, more testing would be great. At least please test the functionality you changed recently. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] efiemu
Sounds like grub needs a git server (with /~user/stuff.git dirs) I'll see about testing it with some various gear. Thanks -joey phcoder writes: Hello here is rediff & update of my efiemu patch. Now it's patched on top of following patch chain: bootmove->preboot->mmap->acpi Now to use it do ([32|64] means 32 for 32-bit version, 64 for 64-bit version): efiemu_loadcore /grub/loadcore[32|64].o efiemu_pnvram [pnvram file if any] efiemu_prepare -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
