Re: [PATCH] x86_64 EFI support for grub2
Hi, Ok, I can basically make everything else work, even chainloading OS X, but it just don't boot Linux. Kernel and initrd loads properly, but it hangs when boot. I start to wonder if this is the kernel's fault. I apply the patches from mactel-linux.org, not working either. And elilo also fails to load linux. Anyone has success booting linux kernel using the new 64-bit Mac Intel EFI ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
how do you apply this patch? With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
any more infos needed?
-Isaac
Bean wrote:
Hi,
I figure it out now, there is some problem with the initrd allocation
algorithm, the following patch should fix it:
diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..8d0e0c2 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +604,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
lh = (struct linux_kernel_header *) real_mode_mem;
- addr_max = grub_cpu_to_le32 (lh-initrd_addr_max);
+ addr_max = (grub_cpu_to_le32 (lh-initrd_addr_max) 10);
if (linux_mem_size != 0 linux_mem_size addr_max)
addr_max = linux_mem_size;
@@ -612,7 +615,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
addr_max -= 0x1;
/* Usually, the compression ratio is about 50%. */
- addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12);
+ addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12)
+ + page_align (size);
/* Find the highest address to put the initrd. */
mmap_size = find_mmap_size ();
@@ -625,8 +629,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
{
if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
- desc-physical_start = addr_min
- desc-physical_start + size addr_max
desc-num_pages = initrd_pages)
{
grub_efi_physical_address_t physical_end;
@@ -635,6 +637,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
if (physical_end addr_max)
physical_end = addr_max;
+ if (physical_end addr_min)
+continue;
+
if (physical_end addr)
addr = physical_end - page_align (size);
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
[EMAIL PROTECTED] wrote:
how do you apply this patch? With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
any more infos needed?
There maybe some code mixups, try this one:
BTW, are you using a customized kernel ? Some people reports that efi
booting don't work. They have 32-bit firmware just like yours, but
hangs even without the initrd.
diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..5ace7c0 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +601,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
lh = (struct linux_kernel_header *) real_mode_mem;
- addr_max = grub_cpu_to_le32 (lh-initrd_addr_max);
+ addr_max = (grub_cpu_to_le32 (lh-initrd_addr_max) 10);
if (linux_mem_size != 0 linux_mem_size addr_max)
addr_max = linux_mem_size;
@@ -612,7 +612,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
addr_max -= 0x1;
/* Usually, the compression ratio is about 50%. */
- addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12);
+ addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12)
+ + page_align (size);
/* Find the highest address to put the initrd. */
mmap_size = find_mmap_size ();
@@ -625,8 +626,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
{
if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
- desc-physical_start = addr_min
- desc-physical_start + size addr_max
desc-num_pages = initrd_pages)
{
grub_efi_physical_address_t physical_end;
@@ -635,6 +634,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
if (physical_end addr_max)
physical_end = addr_max;
+ if (physical_end addr_min)
+continue;
+
if (physical_end addr)
addr = physical_end - page_align (size);
}
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Bean wrote:
On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
[EMAIL PROTECTED] wrote:
how do you apply this patch? With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
any more infos needed?
There maybe some code mixups, try this one:
nope, against latest CVS:
patch -p1 ../grubinitrd2.patch
patching file loader/i386/efi/linux.c
Hunk #1 FAILED at 601.
Hunk #2 FAILED at 612.
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
BTW, are you using a customized kernel ? Some people reports that efi
booting don't work. They have 32-bit firmware just like yours, but
hangs even without the initrd.
Well, I'll see what happens. (Ubuntu kernel is very customized by the
Ubuntu devs.) I have a theory that the console display doesn't work so
I need to get feedback some other way (X? Sound? File modification?
Visibility on network (plug into ethernet first)?) to see if linux has
booted. Also once I have got this patch tried, I'll try adding your
other patch(es) for x86-64 and see if a 64-bit EFI image makes any
difference (although I doubt it will work any *better*, and possibly
worse. but who knows.)
Does grub2 multiboot-ing itself, work yet? (just so we could test that
too under EFI)
diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..5ace7c0 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +601,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
lh = (struct linux_kernel_header *) real_mode_mem;
- addr_max = grub_cpu_to_le32 (lh-initrd_addr_max);
+ addr_max = (grub_cpu_to_le32 (lh-initrd_addr_max) 10);
if (linux_mem_size != 0 linux_mem_size addr_max)
addr_max = linux_mem_size;
@@ -612,7 +612,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
addr_max -= 0x1;
/* Usually, the compression ratio is about 50%. */
- addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12);
+ addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12)
+ + page_align (size);
/* Find the highest address to put the initrd. */
mmap_size = find_mmap_size ();
@@ -625,8 +626,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
{
if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
- desc-physical_start = addr_min
- desc-physical_start + size addr_max
desc-num_pages = initrd_pages)
{
grub_efi_physical_address_t physical_end;
@@ -635,6 +634,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
if (physical_end addr_max)
physical_end = addr_max;
+ if (physical_end addr_min)
+continue;
+
if (physical_end addr)
addr = physical_end - page_align (size);
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
On Wed, Jun 4, 2008 at 7:27 PM, Isaac Dupree
[EMAIL PROTECTED] wrote:
Bean wrote:
On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
[EMAIL PROTECTED] wrote:
how do you apply this patch? With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
any more infos needed?
There maybe some code mixups, try this one:
nope, against latest CVS:
patch -p1 ../grubinitrd2.patch
patching file loader/i386/efi/linux.c
Hunk #1 FAILED at 601.
Hunk #2 FAILED at 612.
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
Use -l option in patch to ignore space. If it still not work, you can
make the changes manually, it's quite simple:
1)
lh = (struct linux_kernel_header *) real_mode_mem;
- addr_max = grub_cpu_to_le32 (lh-initrd_addr_max);
if (linux_mem_size != 0 linux_mem_size addr_max)
addr_max = linux_mem_size;
change the line to addr_max = (grub_cpu_to_le32 (lh-initrd_addr_max) 10);
2)
addr_max -= 0x1;
/* Usually, the compression ratio is about 50%. */
- addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12);
/* Find the highest address to put the initrd. */
mmap_size = find_mmap_size ();
change the line to
addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) 12)
+ page_align (size);
3)
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
{
if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
- desc-physical_start = addr_min
- desc-physical_start + size addr_max
desc-num_pages = initrd_pages)
{
grub_efi_physical_address_t physical_end;
Remove two lines.
4)
if (physical_end addr_max)
physical_end = addr_max;
+ if (physical_end addr_min)
+continue;
+
if (physical_end addr)
addr = physical_end - page_align (size);
}
Add three lines
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] register dummy drive
On Tue, Jun 03, 2008 at 06:03:51PM -0400, Pavel Roskin wrote: This patch solves the problem by spliting device/drive map[] entry registration into a separate function, and using that from grub-probe.c to register a dummy drive that will last during the current execution. Part of what makes grub-probe interesting is that it shares a lot of code with the freestanding GRUB you will run later, so when it is used during grub-install update-grub, it is very useful to catch possible problems. I think hostfs would defeat that purpose. Well, then we probably don't want to ignore any errors. When do you have the situation that the drive cannot be resolved? For example, when the next version of Linux decides to rename all devices (it tends to do that often) and suddenly none of them match any device.map entry. The thing is, for what we're trying to do (-t fs, -t fs_uuid, -t partmap) we don't care how will GRUB identify those devices when it's running on the BIOS, so just any string that uniquely identifies them will be enough so we can run our filesystem / partmap probes. My concern is that introducing a dummy object for non-testing purposes could indicate bad code quality. It got a bit stuck anyway; see my other mail about -t partmap not working with this method. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What good is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] rename a few functions in util/biosdisk.c
Committed.
On Mon, Jun 02, 2008 at 03:28:11PM +0200, Robert Millan wrote:
This patch renames a few functions in util/biosdisk.c. Currently, by looking
at get_drive(), find_drive(), get_os_disk() function names it is very
difficult
to figure out what's going on. They're even misleading in fact. I propose
the more descriptive names find_grub_drive(), find_system_device() and
convert_system_partition_to_system_disk().
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What good is a phone call… if you are unable to speak?
(as seen on /.)
diff -x configure -x config.h.in -x CVS -x '*~' -x '*.mk' -urp
../grub2/util/biosdisk.c ./util/biosdisk.c
--- ../grub2/util/biosdisk.c 2008-05-31 11:42:33.0 +0200
+++ ./util/biosdisk.c 2008-06-02 15:13:09.0 +0200
@@ -110,7 +110,7 @@ have_devfs (void)
#endif /* __linux__ */
static int
-get_drive (const char *name)
+find_grub_drive (const char *name)
{
unsigned int i;
@@ -148,7 +148,7 @@ grub_util_biosdisk_open (const char *nam
int drive;
struct stat st;
- drive = get_drive (name);
+ drive = find_grub_drive (name);
if (drive 0)
return grub_error (GRUB_ERR_BAD_DEVICE,
no mapping exists for `%s', name);
@@ -503,7 +503,7 @@ read_device_map (const char *dev_map)
p++;
/* Find a free slot. */
- drive = get_drive (NULL);
+ drive = find_grub_drive (NULL);
if (drive 0)
show_error (Map table size exceeded);
@@ -593,7 +593,7 @@ make_device_name (int drive, int dos_par
}
static char *
-get_os_disk (const char *os_dev)
+convert_system_partition_to_system_disk (const char *os_dev)
{
#if defined(__linux__)
char *path = xmalloc (PATH_MAX);
@@ -696,18 +696,18 @@ get_os_disk (const char *os_dev)
return path;
#else
-# warning The function `get_os_disk' might not work on your OS correctly.
+# warning The function `convert_system_partition_to_system_disk' might not
work on your OS correctly.
return xstrdup (os_dev);
#endif
}
static int
-find_drive (const char *os_dev)
+find_system_device (const char *os_dev)
{
int i;
char *os_disk;
- os_disk = get_os_disk (os_dev);
+ os_disk = convert_system_partition_to_system_disk (os_dev);
if (! os_disk)
return -1;
@@ -734,7 +734,7 @@ grub_util_biosdisk_get_grub_dev (const c
return 0;
}
- drive = find_drive (os_dev);
+ drive = find_system_device (os_dev);
if (drive 0)
{
grub_error (GRUB_ERR_BAD_DEVICE,
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What good is a phone call… if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Floating point usage
Hello! I tried to compile the current grub on Fedora 9 for PowerPC, but it failed due to floating point usage in ls. Sorry, I don't have the exact message handy. Anyway, there are several references to float and double in the code, and I think it's wrong. GRUB should be able to work on systems with no floating point support and on systems where the floating point device needs to be activated. Even Linux kernel avoids using floating point. If everyone is fine, I'll try to remove all floating point stuff from the code. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] register dummy drive
On Wed, 2008-06-04 at 14:07 +0200, Robert Millan wrote: On Tue, Jun 03, 2008 at 06:03:51PM -0400, Pavel Roskin wrote: This patch solves the problem by spliting device/drive map[] entry registration into a separate function, and using that from grub-probe.c to register a dummy drive that will last during the current execution. Part of what makes grub-probe interesting is that it shares a lot of code with the freestanding GRUB you will run later, so when it is used during grub-install update-grub, it is very useful to catch possible problems. I think hostfs would defeat that purpose. Well, then we probably don't want to ignore any errors. When do you have the situation that the drive cannot be resolved? For example, when the next version of Linux decides to rename all devices (it tends to do that often) and suddenly none of them match any device.map entry. The thing is, for what we're trying to do (-t fs, -t fs_uuid, -t partmap) we don't care how will GRUB identify those devices when it's running on the BIOS, so just any string that uniquely identifies them will be enough so we can run our filesystem / partmap probes. OK, then the dummy drive is not really dummy. Those in device.map are dummy :-) I'm basically fine with anything that gets rid on device.map at least for single-drive installs. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
regression in fs/ext2.c
The following commit: 2008-05-20 Bean [EMAIL PROTECTED] introduced a regression in fs/ext2.c. The effect is that when attempting to access an ext2 filesystem from grub-emu (and AFAICT only from grub-emu), it will spend a lot of time (a minute or so) in a loop that calls lseek() repeatedly (with increasingly higher offsets). I'm sorry, I spent a while looking into this, but haven't been able to find the source of the problem. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What good is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: regression in fs/ext2.c
On Thu, 2008-06-05 at 00:12 +0200, Robert Millan wrote: The following commit: 2008-05-20 Bean [EMAIL PROTECTED] introduced a regression in fs/ext2.c. The effect is that when attempting to access an ext2 filesystem from grub-emu (and AFAICT only from grub-emu), it will spend a lot of time (a minute or so) in a loop that calls lseek() repeatedly (with increasingly higher offsets). I'm sorry, I spent a while looking into this, but haven't been able to find the source of the problem. Actually I noticed that grub won't work in qemu anymore. I would normally do this: qemu -hda /dev/sda and that would show the menu. Sometimes the menu would be old, but running grub-install /dev/sda would synchronize the cache. In the recent days, grub would simply hang or report out of partition. I was installing Fedora 9 around that time, so I blamed it on qemu changes. But now I did a bisect in git, and sure enough, it pointed exactly to that change from May 20. It looks like grub has problems accessing mounted filesystem. That's a problem because the OS can reboot suddenly, leaving the filesystem in a state that grub cannot grok. I'm using ext3 everywhere, so I suspect that the problem may have to do with the journal support implemented in that commit. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] missleading function name
IMHO the name of this function is highly misleading. It makes one think
it just checks something, but it actually modifies our variables. I think
adjust would fit better than check.
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What good is a phone call… if you are unable to speak?
(as seen on /.)
diff -x ChangeLog -x configure -x config.h.in -x CVS -x '*~' -x '*.mk' -urp ../grub2/kern/disk.c ./kern/disk.c
--- ../grub2/kern/disk.c 2008-02-08 13:22:51.0 +0100
+++ ./kern/disk.c 2008-06-04 16:15:24.0 +0200
@@ -323,7 +323,7 @@ grub_disk_close (grub_disk_t disk)
}
static grub_err_t
-grub_disk_check_range (grub_disk_t disk, grub_disk_addr_t *sector,
+grub_disk_adjust_range (grub_disk_t disk, grub_disk_addr_t *sector,
grub_off_t *offset, grub_size_t size)
{
*sector += *offset GRUB_DISK_SECTOR_BITS;
@@ -364,7 +364,7 @@ grub_disk_read (grub_disk_t disk, grub_d
grub_dprintf (disk, Reading `%s'...\n, disk-name);
/* First of all, check if the region is within the disk. */
- if (grub_disk_check_range (disk, sector, offset, size) != GRUB_ERR_NONE)
+ if (grub_disk_adjust_range (disk, sector, offset, size) != GRUB_ERR_NONE)
{
grub_error_push ();
grub_dprintf (disk, Read out of range: sector 0x%llx (%s).\n,
@@ -502,7 +502,7 @@ grub_disk_write (grub_disk_t disk, grub_
grub_dprintf (disk, Writing `%s'...\n, disk-name);
- if (grub_disk_check_range (disk, sector, offset, size) != GRUB_ERR_NONE)
+ if (grub_disk_adjust_range (disk, sector, offset, size) != GRUB_ERR_NONE)
return -1;
real_offset = offset;
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] biosdisk / open_device() messing up offsets
It seems that open_device() in biosdisk is messing up offsets when accessing partitions. For example if you try: grub hexdump (hd0,1) in grub-emu, you'll get a message saying lseek failed. The problem is that it substracts to the sector offset, so all accesses get to wrong data and accessing sector 0 results in underflow. I would think those lines (see patch) are plainly wrong, but they appear to be very old, and it is strange that this wasn't noticed earlier. Maybe we have changed behaviour around partition/disk offsets, causing this breakage without noticing? -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What good is a phone call… if you are unable to speak? (as seen on /.) diff -x ChangeLog -x configure -x config.h.in -x CVS -x '*~' -x '*.mk' -urp ../grub2/util/biosdisk.c ./util/biosdisk.c --- ../grub2/util/biosdisk.c 2008-06-04 16:00:30.0 +0200 +++ ./util/biosdisk.c 2008-06-05 01:17:00.0 +0200 @@ -298,9 +298,6 @@ open_device (const grub_disk_t disk, gru /* Make the buffer cache consistent with the physical disk. */ ioctl (fd, BLKFLSBUF, 0); - -if (is_partition) - sector -= disk-partition-start; } #else /* ! __linux__ */ fd = open (map[disk-id].device, flags); ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: regression in fs/ext2.c
On Thu, Jun 5, 2008 at 6:38 AM, Pavel Roskin [EMAIL PROTECTED] wrote: On Thu, 2008-06-05 at 00:12 +0200, Robert Millan wrote: The following commit: 2008-05-20 Bean [EMAIL PROTECTED] introduced a regression in fs/ext2.c. The effect is that when attempting to access an ext2 filesystem from grub-emu (and AFAICT only from grub-emu), it will spend a lot of time (a minute or so) in a loop that calls lseek() repeatedly (with increasingly higher offsets). I'm sorry, I spent a while looking into this, but haven't been able to find the source of the problem. Actually I noticed that grub won't work in qemu anymore. I would normally do this: qemu -hda /dev/sda and that would show the menu. Sometimes the menu would be old, but running grub-install /dev/sda would synchronize the cache. In the recent days, grub would simply hang or report out of partition. I was installing Fedora 9 around that time, so I blamed it on qemu changes. But now I did a bisect in git, and sure enough, it pointed exactly to that change from May 20. It looks like grub has problems accessing mounted filesystem. That's a problem because the OS can reboot suddenly, leaving the filesystem in a state that grub cannot grok. I'm using ext3 everywhere, so I suspect that the problem may have to do with the journal support implemented in that commit. Hi, I believe it's the new journal support for ext2 that cause the problem. Can you create a small disk image for me to test ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
