Re: [PATCH] Bug fix for ext2.c
Committed. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] patch to compile grub2 in msys/mingw environment
Committed. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Unify rescue and normal commands
Committed. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Google Summer of Code 2009
Hi all, I would like to know if anybody wants to be a mentor in this year for Google SoC. If none, I must tell Karl (the coordinator of the GNU participation to SoC) to get rid of the link to GRUB. Otherwise, I would like to help the preparation of ideas. In order to make a good list, one or more mentors are required for such a discussion, because mentors might not be able to support all kinds of ideas, so a list of ideas must be tweaked, based on their interest and skills. For convenience, I will be on the IRC channel for some hours today. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] New frame buffer detection algorithm and loadrom command for efi platform
Hi, This patch improves the frame buffer detection algorithm. It uses pci to find the video memory base, then scan it for frame buffer. It also add a loadrom command which can be used to enable accel graphic driver. The idea is that you can grab the video bios dump, and optionally the IVT from pc mode, then load them in efi. To grab bios dump: sudo dd if=/dev/mem of=bios.bin bs=65536 skip=12 count=1 You can also include the system bios by changing the count to 4. To grab IVT dump: sudo dd if=/dev/mem of=ivt.bin bs=1024 count=1 Then, to load them in grub-efi (ivt.bin is optionally): loadrom /bios.bin /ivt.bin Here are some of the findings concerning different video cards: Old 32-bit efi model, intel card: Works with intel driver, no need to load vbios or ivt. New 64-bit efi model, intel card: Works with intel driver, needs to load vbios. New 64-bit efi model, nvidia card: Works with nvidia driver, no needs to load vbios or ivt. However, the backlight value is set too low so desktop is barely visible. You need to use a small tool to adjust backlight. The nv driver doesn't work. New 64-bit efi model, ati radeon card: Works with fglrx driver, needs to load vbios and ivt. The radeonhd driver doesn't work. -- Bean loadrom.diff Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New frame buffer detection algorithm and loadrom command for efi platform
nice ... will try to test this asap. 2009/3/21 Bean bean12...@gmail.com: Hi, This patch improves the frame buffer detection algorithm. It uses pci to find the video memory base, then scan it for frame buffer. It also add a loadrom command which can be used to enable accel graphic driver. The idea is that you can grab the video bios dump, and optionally the IVT from pc mode, then load them in efi. To grab bios dump: sudo dd if=/dev/mem of=bios.bin bs=65536 skip=12 count=1 You can also include the system bios by changing the count to 4. To grab IVT dump: sudo dd if=/dev/mem of=ivt.bin bs=1024 count=1 Then, to load them in grub-efi (ivt.bin is optionally): loadrom /bios.bin /ivt.bin Here are some of the findings concerning different video cards: Old 32-bit efi model, intel card: Works with intel driver, no need to load vbios or ivt. New 64-bit efi model, intel card: Works with intel driver, needs to load vbios. New 64-bit efi model, nvidia card: Works with nvidia driver, no needs to load vbios or ivt. However, the backlight value is set too low so desktop is barely visible. You need to use a small tool to adjust backlight. The nv driver doesn't work. New 64-bit efi model, ati radeon card: Works with fglrx driver, needs to load vbios and ivt. The radeonhd driver doesn't work. -- 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
grub-mkimage
I am getting an error from grub-mkimage. The error is: grub-mkimage: error: diskboot.img is not one sector size Does anyone know how I can get this fixed? I am a newbee with grub internals, and I don't have a clue as to ho to size the progam. Thanks, Gary Meerschaert ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Google Summer of Code 2009
On Sat, Mar 21, 2009 at 5:41 PM, Yoshinori K. Okuji ok...@enbug.org wrote: Hi all, I would like to know if anybody wants to be a mentor in this year for Google SoC. If none, I must tell Karl (the coordinator of the GNU participation to SoC) to get rid of the link to GRUB. Otherwise, I would like to help the preparation of ideas. In order to make a good list, one or more mentors are required for such a discussion, because mentors might not be able to support all kinds of ideas, so a list of ideas must be tweaked, based on their interest and skills. For convenience, I will be on the IRC channel for some hours today. Hi, I'd like to be a mentor if it's not occupied already. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New frame buffer detection algorithm and loadrom command for efi platform
On Sat, Mar 21, 2009 at 11:49 PM, step21 f...@terrorpop.de wrote: nice ... will try to test this asap. Hi, Oh btw, there is still problem concerning the nvidia card, intel and ati cards should be all right. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote: Robert Millan wrote: On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote: - grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr; + for (i = 0; i ehdr-e_phnum; i++) +if (phdr(i)-p_vaddr = ehdr-e_entry + phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry) + grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr) + + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr); You need to handle the case in which grub_multiboot_payload_entry_offset is left uninitialized (it needs to be initialized each time the multiboot command is run, not just when the module is loaded). module? actually it's when loading image. Perhaps you mean that additional error check is necessary I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't clear. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: new Linux loader (Re: [PATCH] linux/gfxterm integration)
On Wed, Mar 18, 2009 at 02:09:11PM +0100, phcoder wrote: IMO linux16 for pc/linux.c would better reflect the difference with normal 'linux' command. I'm fine with that. Does anyone object to the proposed rename? Note this implies the new Linux loader becomes the default in grub-mkconfig setup (it is already but only with coreboot). -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] patch to compile grub2 in msys/mingw environment
On Wed, Mar 18, 2009 at 09:43:33PM +0800, Bean wrote: The header file windows.h is included after grub_millisleep, so Sleep is not defined yet, perhaps it'd be better to move #include windows.h to the beginning of file. Agreed. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
Robert Millan wrote: On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote: Robert Millan wrote: On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote: - grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr; + for (i = 0; i ehdr-e_phnum; i++) +if (phdr(i)-p_vaddr = ehdr-e_entry + phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry) + grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr) + + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr); You need to handle the case in which grub_multiboot_payload_entry_offset is left uninitialized (it needs to be initialized each time the multiboot command is run, not just when the module is loaded). module? actually it's when loading image. Perhaps you mean that additional error check is necessary I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't clear. With this error check if grub_multiboot_payload_entry_offset it can happen only if no image is loaded. And actually grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load So I don't really understand the problem -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New frame buffer detection algorithm and loadrom command for efi platform
On Sat, Mar 21, 2009 at 06:38:12PM +0800, Bean wrote: Hi, This patch improves the frame buffer detection algorithm. It uses pci to find the video memory base, then scan it for frame buffer. With this detection code getting increasingly more sophisticated, wouldn't this be a good time to make it a video backend? (i.e. video/efi.c) Even if it won't be complete enough for gfxterm yet, it's much better than doing it in i386/efi/linux.c IMHO. The code to obtain framebuffer address from video backends is pretty simple. It's already in i386/linux.c and could be easily integrated into i386/efi/linux.c. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote: Robert Millan wrote: On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote: Robert Millan wrote: On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote: - grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr; + for (i = 0; i ehdr-e_phnum; i++) +if (phdr(i)-p_vaddr = ehdr-e_entry + phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry) + grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr) + + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr); You need to handle the case in which grub_multiboot_payload_entry_offset is left uninitialized (it needs to be initialized each time the multiboot command is run, not just when the module is loaded). module? actually it's when loading image. Perhaps you mean that additional error check is necessary I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't clear. With this error check if grub_multiboot_payload_entry_offset it can happen only if no image is loaded. And actually grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load So I don't really understand the problem You can't rely on grub_multiboot_payload_entry_offset being set to 0, because any subsequent call of multiboot /something has the potential to override this. You must not assume the multiboot command is only going to be run once. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
Robert Millan wrote: On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote: Robert Millan wrote: On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote: Robert Millan wrote: On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote: - grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr; + for (i = 0; i ehdr-e_phnum; i++) +if (phdr(i)-p_vaddr = ehdr-e_entry + phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry) + grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr) + + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr); You need to handle the case in which grub_multiboot_payload_entry_offset is left uninitialized (it needs to be initialized each time the multiboot command is run, not just when the module is loaded). module? actually it's when loading image. Perhaps you mean that additional error check is necessary I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't clear. With this error check if grub_multiboot_payload_entry_offset it can happen only if no image is loaded. And actually grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load So I don't really understand the problem You can't rely on grub_multiboot_payload_entry_offset being set to 0, because any subsequent call of multiboot /something has the potential to override this. You must not assume the multiboot command is only going to be run once. No but it always corresponds to the current image. It's set either in multiboot.c or in grub_multiboot_load_elf -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] 5/5 Graphical menu (gfxmenu)
Colin D Bennett wrote:
This long-awaited patch adds graphical menu support to GRUB 2. It is
largely the result of my work during the Google Summer of Code 2008.
The graphical menu system supports image-based themes, of which I have
created several sample themes[1].
There are still a few important things that need to be done on gfxmenu
before it is completely ready for end-users (off the top of my head):
- Need a good way to switch themes at runtime. I want to add a popup
menu that lists the available themes and lets the user choose one.
(Currently the keys 1, 2, 3, and 4 are hardcoded to switch between my
sample themes...)
Switching themes on runtime is not a priority. It is a nice to have
feature thou... but we can wait a bit with that.
- gfxmenu interacts badly with gfxterm. Running commands from the
terminal withing gfxmenu that switch the video mode
('videotest basic', for instance) cause a crash when the command
returns. I think this has something to do with the interaction of
video mode-switching and the GRUB output terminal.
I think we can live with some oddities so I would propose that we get
some version in. In fact it will make fixing bugs a bit more robust as
others can also contribute...
So whats the status of your actions. I think some of the patches were
already approved with some minor changes...
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-14, Peter Cros pxwp...@gmail.com wrote: On Sat, Mar 14, 2009 at 1:26 AM, Grant Edwards gra...@visi.com wrote: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. I got curious and rechecked this - Here is grub.efi booting from usb msdos drive with hfsplus partition - When I try that, I get one of two things: 1) When it boots directly into grub, grub can only see hd0 (which appears to be the USB drive), but it can't see any of the paritions on hd0. Needless to say, it can't find it's config file. 2) Holding down the Option key and selecting grub allows it to see both disks -- it can see partitions on the GPT-partitioned hard drive but not on the MS-DOS partitioned USB drive. I can manually load a config-file from the hard drive, none of the menu entries work -- I see stuff like error: unknown command `initrd' or error: unkown command `search' Here's the info on the USB drive: bash-3.2# diskutil list /dev/disk1 /dev/disk1 #: TYPE NAMESIZE IDENTIFIER 0: FDisk_partition_scheme*3.7 Gi disk1 1: DOS_FAT_32 minimyth1.9 Gi disk1s1 2: Apple_HFS mmhfs 1.9 Gi disk1s2 bash-3.2# bless --info /Volumes/mmhfs finderinfo[0]: 2 = Blessed System Folder is /Volumes/mmhfs/ finderinfo[1]:120 = Blessed System File is /Volumes/mmhfs/efi/grub/grub.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 2 = OS X blessed folder is /Volumes/mmhfs/ 64-bit VSDB volume id: 0xA3FBF66150DE9BB1 --setBoot gives deafult fast boot to grub menu, but when booted that way, grub can only see its own disk (hd0) Same here, and it can't see any of the partitions on that disk. End result: still no luck booting from USB drive, just a larger variety of failure modes. -- Grant ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
On Sat, Mar 21, 2009 at 07:05:23PM +0100, phcoder wrote: Robert Millan wrote: On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote: Robert Millan wrote: On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote: Robert Millan wrote: On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote: - grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr; + for (i = 0; i ehdr-e_phnum; i++) +if (phdr(i)-p_vaddr = ehdr-e_entry + phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry) + grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr) + + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr); You need to handle the case in which grub_multiboot_payload_entry_offset is left uninitialized (it needs to be initialized each time the multiboot command is run, not just when the module is loaded). module? actually it's when loading image. Perhaps you mean that additional error check is necessary I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't clear. With this error check if grub_multiboot_payload_entry_offset it can happen only if no image is loaded. And actually grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load So I don't really understand the problem You can't rely on grub_multiboot_payload_entry_offset being set to 0, because any subsequent call of multiboot /something has the potential to override this. You must not assume the multiboot command is only going to be run once. No but it always corresponds to the current image. It's set either in multiboot.c or in grub_multiboot_load_elf It is now, but your code makes this conditional. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
Robert Millan wrote:
On Sat, Mar 21, 2009 at 07:05:23PM +0100, phcoder wrote:
Robert Millan wrote:
On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote:
Robert Millan wrote:
On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote:
Robert Millan wrote:
On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote:
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ for (i = 0; i ehdr-e_phnum; i++)
+if (phdr(i)-p_vaddr = ehdr-e_entry +
phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry)
+ grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr)
+ + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr);
You need to handle the case in which grub_multiboot_payload_entry_offset is left
uninitialized (it needs to be initialized each time the multiboot command is
run, not just when the module is loaded).
module? actually it's when loading image. Perhaps you mean that
additional error check is necessary
I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't clear.
With this error check if grub_multiboot_payload_entry_offset it can
happen only if no image is loaded. And actually
grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load
So I don't really understand the problem
You can't rely on grub_multiboot_payload_entry_offset being set to 0, because
any subsequent call of multiboot /something has the potential to override
this. You must not assume the multiboot command is only going to be run once.
No but it always corresponds to the current image. It's set either in
multiboot.c or in grub_multiboot_load_elf
It is now, but your code makes this conditional.
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/loader/i386/multiboot_elfxx.c b/loader/i386/multiboot_elfxx.c
index 801800c..ce9e4fe 100644
--- a/loader/i386/multiboot_elfxx.c
+++ b/loader/i386/multiboot_elfxx.c
@@ -49,7 +49,7 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, void *buffer)
{
Elf_Ehdr *ehdr = (Elf_Ehdr *) buffer;
char *phdr_base;
- int lowest_segment = 0, highest_segment = 0;
+ int lowest_segment = -1, highest_segment = -1;
int i;
if (ehdr-e_ident[EI_CLASS] != ELFCLASSXX)
@@ -83,11 +83,18 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, void *buffer)
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ /* Beware that segment 0 isn't necessarily loadable */
+ if (lowest_segment == -1
+ || phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
+
+ if (lowest_segment == -1)
+return grub_error (GRUB_ERR_BAD_OS, ELF contains no loadable segments);
+
code_size = (phdr(highest_segment)-p_paddr + phdr(highest_segment)-p_memsz) - phdr(lowest_segment)-p_paddr;
grub_multiboot_payload_dest = phdr(lowest_segment)-p_paddr;
@@ -105,8 +112,8 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, void *buffer)
{
char *load_this_module_at = (char *) (grub_multiboot_payload_orig + (long) (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr));
- grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx, memsz=0x%lx\n,
- i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz);
+ grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx, memsz=0x%lx, vaddr=0x%lx\n,
+ i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz, (long) phdr(i)-p_vaddr);
if (grub_file_seek (file, (grub_off_t) phdr(i)-p_offset)
== (grub_off_t) -1)
@@ -124,7 +131,17 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, void *buffer)
}
}
- grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr;
+ for (i = 0; i ehdr-e_phnum; i++)
+if (phdr(i)-p_vaddr = ehdr-e_entry
+ phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry)
+ {
+ grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr)
+ + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr);
+ break;
+ }
+
+ if (i == ehdr-e_phnum)
+return grub_error (GRUB_ERR_BAD_OS, entry point isn't in a segment);
#undef phdr
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Move multiboot helpers out of the kernel
Robert Millan wrote:
On Sat, Mar 14, 2009 at 06:52:55PM +0100, phcoder wrote:
Robert Millan wrote:
On Sat, Mar 14, 2009 at 12:35:09AM +0100, phcoder wrote:
Index: conf/i386-ieee1275.rmk
===
--- conf/i386-ieee1275.rmk (revision 2030)
+++ conf/i386-ieee1275.rmk (working copy)
@@ -126,10 +126,12 @@
# For _multiboot.mod.
_multiboot_mod_SOURCES = loader/ieee1275/multiboot2.c \
+loader/i386/multiboot_helper.S \
multiboot_helper.S is not being used on i386-ieee1275 AFAICT
How can it be if multiboot.c is the same for pc and ieee1275?
$ grep multiboot.c conf/*.rmk
conf/i386-coreboot.rmk:_multiboot_mod_SOURCES = loader/i386/multiboot.c \
conf/i386-pc.rmk:_multiboot_mod_SOURCES = loader/i386/multiboot.c \
void
grub_mb2_arch_boot (grub_addr_t entry_addr, void *tags)
{
#if defined(__powerpc__)
kernel_entry_t entry = (kernel_entry_t) entry_addr;
entry (MULTIBOOT2_BOOTLOADER_MAGIC, tags, grub_ieee1275_entry_fn, 0, 0);
#elif defined(__i386__)
grub_multiboot2_real_boot (entry_addr, tags);
#else
#error
#endif
}
As you see it uses grub_multiboot2_real_boot
grub_dl_unload_all() just disappeared. Is this intentional? I
tend to agree that grub_dl_unload_all() is a waste of time, but
this should be discussed separately.
It is intentional because multiboot_real_boot is now in a module so we
can't unload it
Ok then, I'm fine with disabling the unload. What does everybody else
think?
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
On Sat, Mar 21, 2009 at 11:03:12PM +0100, Robert Millan wrote: No but it always corresponds to the current image. It's set either in multiboot.c or in grub_multiboot_load_elf It is now, but your code makes this conditional. My bad. This' been clarified on IRC. Sometimes I read code too quickly... -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
Committed.
On Sat, Mar 21, 2009 at 11:49:18PM +0100, phcoder wrote:
Robert Millan wrote:
On Sat, Mar 21, 2009 at 07:05:23PM +0100, phcoder wrote:
Robert Millan wrote:
On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote:
Robert Millan wrote:
On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote:
Robert Millan wrote:
On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote:
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ for (i = 0; i ehdr-e_phnum; i++)
+if (phdr(i)-p_vaddr = ehdr-e_entry +
phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry)
+ grub_multiboot_payload_entry_offset = (ehdr-e_entry -
phdr(i)-p_vaddr)
+ + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr);
You need to handle the case in which
grub_multiboot_payload_entry_offset is left
uninitialized (it needs to be initialized each time the multiboot
command is
run, not just when the module is loaded).
module? actually it's when loading image. Perhaps you mean
that additional error check is necessary
I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't
clear.
With this error check if grub_multiboot_payload_entry_offset it
can happen only if no image is loaded. And actually
grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod
load
So I don't really understand the problem
You can't rely on grub_multiboot_payload_entry_offset being set to 0,
because
any subsequent call of multiboot /something has the potential to override
this. You must not assume the multiboot command is only going to be run
once.
No but it always corresponds to the current image. It's set either in
multiboot.c or in grub_multiboot_load_elf
It is now, but your code makes this conditional.
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/loader/i386/multiboot_elfxx.c b/loader/i386/multiboot_elfxx.c
index 801800c..ce9e4fe 100644
--- a/loader/i386/multiboot_elfxx.c
+++ b/loader/i386/multiboot_elfxx.c
@@ -49,7 +49,7 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, void
*buffer)
{
Elf_Ehdr *ehdr = (Elf_Ehdr *) buffer;
char *phdr_base;
- int lowest_segment = 0, highest_segment = 0;
+ int lowest_segment = -1, highest_segment = -1;
int i;
if (ehdr-e_ident[EI_CLASS] != ELFCLASSXX)
@@ -83,11 +83,18 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file,
void *buffer)
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ /* Beware that segment 0 isn't necessarily loadable */
+ if (lowest_segment == -1
+ || phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
+
+ if (lowest_segment == -1)
+return grub_error (GRUB_ERR_BAD_OS, ELF contains no loadable segments);
+
code_size = (phdr(highest_segment)-p_paddr +
phdr(highest_segment)-p_memsz) - phdr(lowest_segment)-p_paddr;
grub_multiboot_payload_dest = phdr(lowest_segment)-p_paddr;
@@ -105,8 +112,8 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file,
void *buffer)
{
char *load_this_module_at = (char *) (grub_multiboot_payload_orig +
(long) (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr));
- grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx,
memsz=0x%lx\n,
- i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz);
+ grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx,
memsz=0x%lx, vaddr=0x%lx\n,
+ i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz,
(long) phdr(i)-p_vaddr);
if (grub_file_seek (file, (grub_off_t) phdr(i)-p_offset)
== (grub_off_t) -1)
@@ -124,7 +131,17 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file,
void *buffer)
}
}
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ for (i = 0; i ehdr-e_phnum; i++)
+if (phdr(i)-p_vaddr = ehdr-e_entry
+ phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry)
+ {
+ grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr)
+ + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr);
+ break;
+ }
+
+ if (i == ehdr-e_phnum)
+return grub_error (GRUB_ERR_BAD_OS, entry point isn't in a segment);
#undef phdr
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at
Re: [Patch] Move multiboot helpers out of the kernel
Is this the last patch? I rechecked this thread, but might have missed something. On Sat, Mar 14, 2009 at 12:35:09AM +0100, phcoder wrote: Rediffed 2009-03-14 Vladimir Serbinenko phco...@gmail.com Move multiboot helper out of kernel * conf/i386-pc.rmk: Add loader/i386/multiboot_helper.S to _multiboot.mod This should be like: * conf/i386-pc.rmk (_multiboot_mod_SOURCES): Add `loader/i386/multiboot_helper.S'. Also, the addition of _multiboot_mod_ASFLAGS isn't mentioned. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Move multiboot helpers out of the kernel
Fixed. I temporarily left grub_stop_floppy in linux code. 2009-03-22 Vladimir Serbinenko phco...@gmail.com Move multiboot helper out of kernel * conf/i386-pc.rmk (multiboot_mod_SOURCES): Add loader/i386/multiboot_helper.S * conf/i386-coreboot.rmk: Likewise * conf/i386-ieee1275.rmk: Likewise * kern/i386/loader.S: Move multiboot helpers from here... * loader/i386/multiboot_helper.S: ...moved here * include/grub/i386/loader.h: Move declarations of multiboot helpers from here... * include/grub/i386/multiboot.h: ...moved here * loader/i386/multiboot.c: Added include of grub/cpu/multiboot.h Robert Millan wrote: Is this the last patch? I rechecked this thread, but might have missed something. On Sat, Mar 14, 2009 at 12:35:09AM +0100, phcoder wrote: Rediffed 2009-03-14 Vladimir Serbinenko phco...@gmail.com Move multiboot helper out of kernel * conf/i386-pc.rmk: Add loader/i386/multiboot_helper.S to _multiboot.mod This should be like: * conf/i386-pc.rmk (_multiboot_mod_SOURCES): Add `loader/i386/multiboot_helper.S'. Also, the addition of _multiboot_mod_ASFLAGS isn't mentioned. -- Regards Vladimir 'phcoder' Serbinenko diff --git a/conf/i386-coreboot.rmk b/conf/i386-coreboot.rmk index 0b4f216..53595de 100644 --- a/conf/i386-coreboot.rmk +++ b/conf/i386-coreboot.rmk @@ -145,11 +145,13 @@ serial_mod_LDFLAGS = $(COMMON_LDFLAGS) # For multiboot.mod. multiboot_mod_SOURCES = loader/i386/multiboot.c \ + loader/i386/multiboot_helper.S \ loader/i386/pc/multiboot2.c \ loader/multiboot2.c \ loader/multiboot_loader.c multiboot_mod_CFLAGS = $(COMMON_CFLAGS) multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) # For aout.mod. aout_mod_SOURCES = loader/aout.c diff --git a/conf/i386-ieee1275.rmk b/conf/i386-ieee1275.rmk index dbcbb4a..a84b5aa 100644 --- a/conf/i386-ieee1275.rmk +++ b/conf/i386-ieee1275.rmk @@ -127,10 +127,12 @@ normal_mod_LDFLAGS = $(COMMON_LDFLAGS) # For multiboot.mod. multiboot_mod_SOURCES = loader/ieee1275/multiboot2.c \ + loader/i386/multiboot_helper.S \ loader/multiboot2.c \ loader/multiboot_loader.c multiboot_mod_CFLAGS = $(COMMON_CFLAGS) multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) # For aout.mod. aout_mod_SOURCES = loader/aout.c diff --git a/conf/i386-pc.rmk b/conf/i386-pc.rmk index cc845ed..60d5182 100644 --- a/conf/i386-pc.rmk +++ b/conf/i386-pc.rmk @@ -228,11 +228,13 @@ serial_mod_LDFLAGS = $(COMMON_LDFLAGS) # For multiboot.mod. multiboot_mod_SOURCES = loader/i386/multiboot.c \ + loader/i386/multiboot_helper.S \ loader/i386/pc/multiboot2.c \ loader/multiboot2.c \ loader/multiboot_loader.c multiboot_mod_CFLAGS = $(COMMON_CFLAGS) multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) # For vbe.mod. vbe_mod_SOURCES = video/i386/pc/vbe.c video/i386/pc/vbeblit.c \ diff --git a/include/grub/i386/loader.h b/include/grub/i386/loader.h index df8b4e3..3052030 100644 --- a/include/grub/i386/loader.h +++ b/include/grub/i386/loader.h @@ -1,6 +1,6 @@ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2002,2003,2004,2007,2008 Free Software Foundation, Inc. + * Copyright (C) 2002,2003,2004,2007,2008,2009 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 @@ -22,7 +22,6 @@ #include grub/types.h #include grub/err.h #include grub/symbol.h -#include grub/multiboot.h extern grub_uint32_t EXPORT_VAR(grub_linux_prot_size); extern char *EXPORT_VAR(grub_linux_tmp_addr); @@ -33,26 +32,7 @@ extern grub_size_t EXPORT_VAR(grub_os_area_size); grub_err_t EXPORT_FUNC(grub_linux_boot) (void); -/* The asm part of the multiboot loader. */ -void EXPORT_FUNC(grub_multiboot_real_boot) (grub_addr_t entry, - struct grub_multiboot_info *mbi) - __attribute__ ((noreturn)); -void EXPORT_FUNC(grub_multiboot2_real_boot) (grub_addr_t entry, - struct grub_multiboot_info *mbi) - __attribute__ ((noreturn)); void EXPORT_FUNC(grub_unix_real_boot) (grub_addr_t entry, ...) __attribute__ ((cdecl,noreturn)); -extern grub_addr_t EXPORT_VAR(grub_multiboot_payload_orig); -extern grub_addr_t EXPORT_VAR(grub_multiboot_payload_dest); -extern grub_size_t EXPORT_VAR(grub_multiboot_payload_size); -extern grub_uint32_t EXPORT_VAR(grub_multiboot_payload_entry_offset); - -extern grub_uint8_t EXPORT_VAR(grub_multiboot_forward_relocator); -extern grub_uint8_t EXPORT_VAR(grub_multiboot_forward_relocator_end); -extern grub_uint8_t EXPORT_VAR(grub_multiboot_backward_relocator); -extern grub_uint8_t EXPORT_VAR(grub_multiboot_backward_relocator_end); -
Re: GRUB device names wrt. ieee1275
Device name in boot block will anyway be written in it's complete raw OFW form, no matter how the rest of the grub2 accessing the disks. Using UUIDs in this place would be nice. On IRC you said that we have 120 bytes for the name. UUID is 16 or 32 bytes depending on FS. Is it possible to fit something like read first sector of every disk, compare data at given offset? I don't agree that all devices should be accessed exclusively by UUID. It makes things difficult to maintain because of internal naming. IMO quoting and escaping offers the best universal solution. I don't see why sth like (/p...@1e\,60/p...@0/p...@9/p...@0/s...@1/d...@0,1) is a problem. Anyway you don't type such a thing manually and probably use tab-completition instead David Miller wrote: From: David Miller da...@davemloft.net Date: Wed, 18 Mar 2009 13:55:22 -0700 (PDT) From: Robert Millan r...@aybabtu.com Date: Wed, 18 Mar 2009 11:18:46 +0100 On Sun, Mar 15, 2009 at 03:41:16PM -0700, David Miller wrote: From: Robert Millan r...@aybabtu.com Date: Sun, 15 Mar 2009 16:45:31 +0100 It's not an absolute must that device names are unique. You can still identify partitions by their filesystem UUID or label, and in fact this is what our default scripts (grub-mkconfig) do anyway. Things like UUID and labels are not an option for the 512-byte boot block where I have to know the exact OBP path of the boot device, and this is what the GRUB kernel fetches from the 'bootpath' environment variable to compose the root device and path. What 512-byte boot block? The one I add in my sparc64 support changes. Included here for reference: BTW, I explained exactly how this 512 byte boot block works, in extreme detail, when I first posted my grub sparc64 patches. I am including it here _again_, please read it, it's informative, I promise, and I didn't post it the first time for my health! Thanks! The first task is to get the first stage boot block going. There are two choices on how to do this. When you type boot for a block device, the firmware loads 7.5K starting at the second 512-byte block. If this block device is the third partition (the all disk partition in the Sun disk label) this bootblock starts after the disk label. Under Linux we really can only use 512 bytes of that boot block area, because it's possible for the filesystem superblock to show up as early as the very next 512 byte block. The firmware lets you put in the block some sparc executable image (tried by the firmware as 64-bit ELF, then 32-bit ELF, and finally as A.OUT) or tokenized forth. Since 1) we only have 512 bytes and 2) there are no fully GPL'd forth tokenizer implementations (the openbios folks use something that is BSD and MIT licensed) we'll need to go the sparc image route. The task of this 512 byte sequence of code is to load the next stage of the bootloader. For GRUB I've choosen a multi-tiered scheme similar to how the x86 stuff works. The first stage bootloader loads a single block from the disk and jumps to it. This block we load is actually a header block of the main boot loader binary, a second stage loader, which loads the rest of the image. This first stage loader therefore needs a few parameters. It needs to know the OF device path where the second stage header block resides. It needs to know the block to read, and finally it needs to know where to load that block and thus where to jump to it for execution. We'd also like to print some status messages to the screen while this happens and have at least some minimal error handling. Not a small feat in 512 bytes. We put everything in the text section, and the first thing we do is jump over our embedded data bits: .text .align 4 .globl _start _start: /* OF CIF entry point arrives in %o4 */ pic_base: callboot_continue mov%o4, CIF_REG The CIF is the client interface to openfirmware. Calls are made by initializing an array of cells (64-bits on sparc64) in memory which describe the call to be made, the input arguments, and the return values (if any). This value provided in %o4 is the OF entry point we jump to when making calls. The only register argument goes in %o0 and is the base of the aforementioned array of cells. The offsets into the bits coming up are defined in a GRUB boot.h header file so that tools can patch in values during bootblock installation. . = _start + GRUB_BOOT_MACHINE_VER_MAJ boot_version: .byte GRUB_BOOT_VERSION_MAJOR, GRUB_BOOT_VERSION_MINOR boot_path: . = _start + GRUB_BOOT_MACHINE_KERNEL_ADDRESS kernel_sector: .xword 2 kernel_address: .word GRUB_BOOT_MACHINE_KERNEL_ADDR The boot_version is just a version blob that various tools and sub-bootloaders could validate for compatibility if they wanted to. It is unused currently. The boot_path will be filled in by the boot block installation tools with the boot device OF path. kernel_sector
Re: GRUB device names wrt. ieee1275
phcoder wrote: Device name in boot block will anyway be written in it's complete raw OFW form, no matter how the rest of the grub2 accessing the disks. Using UUIDs in this place would be nice. On IRC you said that we have 120 bytes for the name. UUID is 16 or 32 bytes depending on FS. Is it possible to fit something like read first sector of every disk, compare data at given offset? Could we use label checksum for finding right disk? I don't agree that all devices should be accessed exclusively by UUID. It makes things difficult to maintain because of internal naming. IMO quoting and escaping offers the best universal solution. I don't see why sth like (/p...@1e\,60/p...@0/p...@9/p...@0/s...@1/d...@0,1) is a problem. Anyway you don't type such a thing manually and probably use tab-completition instead David Miller wrote: From: David Miller da...@davemloft.net Date: Wed, 18 Mar 2009 13:55:22 -0700 (PDT) From: Robert Millan r...@aybabtu.com Date: Wed, 18 Mar 2009 11:18:46 +0100 On Sun, Mar 15, 2009 at 03:41:16PM -0700, David Miller wrote: From: Robert Millan r...@aybabtu.com Date: Sun, 15 Mar 2009 16:45:31 +0100 It's not an absolute must that device names are unique. You can still identify partitions by their filesystem UUID or label, and in fact this is what our default scripts (grub-mkconfig) do anyway. Things like UUID and labels are not an option for the 512-byte boot block where I have to know the exact OBP path of the boot device, and this is what the GRUB kernel fetches from the 'bootpath' environment variable to compose the root device and path. What 512-byte boot block? The one I add in my sparc64 support changes. Included here for reference: BTW, I explained exactly how this 512 byte boot block works, in extreme detail, when I first posted my grub sparc64 patches. I am including it here _again_, please read it, it's informative, I promise, and I didn't post it the first time for my health! Thanks! The first task is to get the first stage boot block going. There are two choices on how to do this. When you type boot for a block device, the firmware loads 7.5K starting at the second 512-byte block. If this block device is the third partition (the all disk partition in the Sun disk label) this bootblock starts after the disk label. Under Linux we really can only use 512 bytes of that boot block area, because it's possible for the filesystem superblock to show up as early as the very next 512 byte block. The firmware lets you put in the block some sparc executable image (tried by the firmware as 64-bit ELF, then 32-bit ELF, and finally as A.OUT) or tokenized forth. Since 1) we only have 512 bytes and 2) there are no fully GPL'd forth tokenizer implementations (the openbios folks use something that is BSD and MIT licensed) we'll need to go the sparc image route. The task of this 512 byte sequence of code is to load the next stage of the bootloader. For GRUB I've choosen a multi-tiered scheme similar to how the x86 stuff works. The first stage bootloader loads a single block from the disk and jumps to it. This block we load is actually a header block of the main boot loader binary, a second stage loader, which loads the rest of the image. This first stage loader therefore needs a few parameters. It needs to know the OF device path where the second stage header block resides. It needs to know the block to read, and finally it needs to know where to load that block and thus where to jump to it for execution. We'd also like to print some status messages to the screen while this happens and have at least some minimal error handling. Not a small feat in 512 bytes. We put everything in the text section, and the first thing we do is jump over our embedded data bits: .text .align4 .globl_start _start: /* OF CIF entry point arrives in %o4 */ pic_base: callboot_continue mov%o4, CIF_REG The CIF is the client interface to openfirmware. Calls are made by initializing an array of cells (64-bits on sparc64) in memory which describe the call to be made, the input arguments, and the return values (if any). This value provided in %o4 is the OF entry point we jump to when making calls. The only register argument goes in %o0 and is the base of the aforementioned array of cells. The offsets into the bits coming up are defined in a GRUB boot.h header file so that tools can patch in values during bootblock installation. . = _start + GRUB_BOOT_MACHINE_VER_MAJ boot_version:.byteGRUB_BOOT_VERSION_MAJOR, GRUB_BOOT_VERSION_MINOR boot_path: . = _start + GRUB_BOOT_MACHINE_KERNEL_ADDRESS kernel_sector:.xword 2 kernel_address:.word GRUB_BOOT_MACHINE_KERNEL_ADDR The boot_version is just a version blob that various tools and sub-bootloaders could validate for compatibility if they wanted to. It is unused currently. The boot_path will be filled in by the boot block installation tools with
Re: GRUB device names wrt. ieee1275
From: phcoder phco...@gmail.com Date: Sun, 22 Mar 2009 01:41:52 +0100 Device name in boot block will anyway be written in it's complete raw OFW form, no matter how the rest of the grub2 accessing the disks. Using UUIDs in this place would be nice. On IRC you said that we have 120 bytes for the name. UUID is 16 or 32 bytes depending on FS. Is it possible to fit something like read first sector of every disk, compare data at given offset? This is possible, but I know that Solaris folks would like to use the Sparc GRUB support I'm writing and I'm not so sure whether they have FS UUIDs or not. I don't agree that all devices should be accessed exclusively by UUID. It makes things difficult to maintain because of internal naming. IMO quoting and escaping offers the best universal solution. I don't see why sth like (/p...@1e\,60/p...@0/p...@9/p...@0/s...@1/d...@0,1) is a problem. Anyway you don't type such a thing manually and probably use tab-completition instead We could use escaping, sure. Actually most of the time users use device aliases, however: 1) GRUB should work when a device lacks a alias. 2) GRUB should keep working even if the user deletes one of the aliases. While convenient I'm not so sure that OF device aliases are a good basis for the names GRUB should use because they are by their very nature transient. It does take quite a bit of effort to translate between different OS device naming formats into OF native ones. So whatever universal naming convention is choosen, it should be such that it can be mechanically and statelessly converted to OF. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB device names wrt. ieee1275
From: phcoder phco...@gmail.com Date: Sun, 22 Mar 2009 01:48:14 +0100 phcoder wrote: Device name in boot block will anyway be written in it's complete raw OFW form, no matter how the rest of the grub2 accessing the disks. Using UUIDs in this place would be nice. On IRC you said that we have 120 bytes for the name. UUID is 16 or 32 bytes depending on FS. Is it possible to fit something like read first sector of every disk, compare data at given offset? Could we use label checksum for finding right disk? And if I reconfigure or add a partition I have to rerun grub-install ? I don't think that's a friendly usage model. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
Don't know, rechecked it here and it sees all the usb partitions whichever way its booted, maybe something wrong with your grub.efi build preloaded modules. Check the latest svn. On Sun, Mar 22, 2009 at 8:30 AM, Grant Edwards gra...@visi.com wrote: On 2009-03-14, Peter Cros pxwp...@gmail.com wrote: On Sat, Mar 14, 2009 at 1:26 AM, Grant Edwards gra...@visi.com wrote: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. I got curious and rechecked this - Here is grub.efi booting from usb msdos drive with hfsplus partition - When I try that, I get one of two things: 1) When it boots directly into grub, grub can only see hd0 (which appears to be the USB drive), but it can't see any of the paritions on hd0. Needless to say, it can't find it's config file. 2) Holding down the Option key and selecting grub allows it to see both disks -- it can see partitions on the GPT-partitioned hard drive but not on the MS-DOS partitioned USB drive. I can manually load a config-file from the hard drive, none of the menu entries work -- I see stuff like error: unknown command `initrd' or error: unkown command `search' Here's the info on the USB drive: bash-3.2# diskutil list /dev/disk1 /dev/disk1 #: TYPE NAMESIZE IDENTIFIER 0: FDisk_partition_scheme*3.7 Gi disk1 1: DOS_FAT_32 minimyth1.9 Gi disk1s1 2: Apple_HFS mmhfs 1.9 Gi disk1s2 bash-3.2# bless --info /Volumes/mmhfs finderinfo[0]: 2 = Blessed System Folder is /Volumes/mmhfs/ finderinfo[1]:120 = Blessed System File is /Volumes/mmhfs/efi/grub/grub.efi finderinfo[2]: 0 = Open-folder linked list empty finderinfo[3]: 0 = No OS 9 + X blessed 9 folder finderinfo[4]: 0 = Unused field unset finderinfo[5]: 2 = OS X blessed folder is /Volumes/mmhfs/ 64-bit VSDB volume id: 0xA3FBF66150DE9BB1 --setBoot gives deafult fast boot to grub menu, but when booted that way, grub can only see its own disk (hd0) Same here, and it can't see any of the partitions on that disk. End result: still no luck booting from USB drive, just a larger variety of failure modes. -- Grant ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
