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
return
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:
Yoshinor
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
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 off
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
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 -= payl
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 b
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
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_pri
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-dev
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
>
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:
htt
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
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 th
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 th
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
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 c
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
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 f
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
20 matches
Mail list logo