[Fwd: Re: GRUB device names wrt. ieee1275]
-- Regards Vladimir 'phcoder' Serbinenko --- Begin Message --- David Miller wrote: From: phcoder Date: Sun, 22 Mar 2009 23:51:14 +0100 You could do it the way similar to how it's done on i386-pc: jmp use_hardcoded use_hardcoded: And then the grub-setup tool nops out the first jump if stage2 resides on a disk different than where bootblock is Sure we could do that. But I'm trying to figure out why to bother with this if I already have all of the (tested) logic and infrastructure to fill in the device path already? What about booting from removable device? In this case you can't assume that device path during install is still valid at booting It just seems like another case in the matrix which needs to be tested, and can thus go wrong. -- Regards Vladimir 'phcoder' Serbinenko --- End Message --- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
multiboot on EFI
Hello. Here is an initial version of patch for booting multiboot kernels on i386-efi. No Changelog yet because it's not for inclusion yet. -- Regards Vladimir 'phcoder' Serbinenko diff --git a/conf/common.rmk b/conf/common.rmk index 100fae7..e64a1a4 100644 --- a/conf/common.rmk +++ b/conf/common.rmk @@ -507,3 +507,10 @@ gzio_mod_LDFLAGS = $(COMMON_LDFLAGS) bufio_mod_SOURCES = io/bufio.c bufio_mod_CFLAGS = $(COMMON_CFLAGS) bufio_mod_LDFLAGS = $(COMMON_LDFLAGS) + +pkglib_MODULES += lsmmap.mod + +# For lsmmap.mod +lsmmap_mod_SOURCES = commands/lsmmap.c +lsmmap_mod_CFLAGS = $(COMMON_CFLAGS) +lsmmap_mod_LDFLAGS = $(COMMON_LDFLAGS) diff --git a/conf/i386-coreboot.rmk b/conf/i386-coreboot.rmk index 6f4e8f3..1304eb3 100644 --- a/conf/i386-coreboot.rmk +++ b/conf/i386-coreboot.rmk @@ -102,8 +102,7 @@ pkglib_MODULES = _linux.mod linux.mod normal.mod \ _multiboot.mod multiboot.mod aout.mod \ play.mod serial.mod ata.mod \ memdisk.mod pci.mod lspci.mod reboot.mod \ - halt.mod datetime.mod date.mod datehook.mod \ - lsmmap.mod + halt.mod datetime.mod date.mod datehook.mod # For _linux.mod. _linux_mod_SOURCES = loader/i386/linux.c @@ -211,10 +210,5 @@ datehook_mod_SOURCES = hook/datehook.c datehook_mod_CFLAGS = $(COMMON_CFLAGS) datehook_mod_LDFLAGS = $(COMMON_LDFLAGS) -# For lsmmap.mod -lsmmap_mod_SOURCES = commands/lsmmap.c -lsmmap_mod_CFLAGS = $(COMMON_CFLAGS) -lsmmap_mod_LDFLAGS = $(COMMON_LDFLAGS) - include $(srcdir)/conf/i386.mk include $(srcdir)/conf/common.mk diff --git a/conf/i386-efi.rmk b/conf/i386-efi.rmk index a2454d9..4303b1c 100644 --- a/conf/i386-efi.rmk +++ b/conf/i386-efi.rmk @@ -80,7 +80,20 @@ grub_install_SOURCES = util/i386/efi/grub-install.in # Modules. pkglib_MODULES = kernel.mod normal.mod _chain.mod chain.mod appleldr.mod \ _linux.mod linux.mod halt.mod reboot.mod pci.mod lspci.mod \ - datetime.mod date.mod datehook.mod + datetime.mod date.mod datehook.mod _multiboot.mod multiboot.mod + +# For _multiboot.mod. +_multiboot_mod_SOURCES = loader/i386/multiboot.c \ + loader/i386/multiboot_helper.S \ + loader/multiboot_loader.c +_multiboot_mod_CFLAGS = $(COMMON_CFLAGS) +_multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) + +# For multiboot.mod. +multiboot_mod_SOURCES = loader/multiboot_loader_normal.c +multiboot_mod_CFLAGS = $(COMMON_CFLAGS) +multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) # For kernel.mod. kernel_mod_EXPORTS = no @@ -90,14 +103,14 @@ kernel_mod_SOURCES = kern/i386/efi/startup.S kern/main.c kern/device.c \ kern/i386/dl.c kern/i386/efi/init.c kern/parser.c kern/partition.c \ kern/env.c symlist.c kern/efi/efi.c kern/efi/init.c kern/efi/mm.c \ term/efi/console.c disk/efi/efidisk.c \ - kern/time.c kern/list.c kern/handler.c \ + kern/efi/mmap.c kern/time.c kern/list.c kern/handler.c \ kern/i386/tsc.c kern/i386/pit.c \ kern/generic/rtc_get_time_ms.c \ kern/generic/millisleep.c kernel_mod_HEADERS = arg.h boot.h cache.h device.h disk.h dl.h elf.h elfload.h \ env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \ partition.h pc_partition.h rescue.h symbol.h term.h time.h types.h \ - efi/efi.h efi/time.h efi/disk.h list.h handler.h + efi/efi.h efi/time.h efi/disk.h efi/memory.h list.h handler.h kernel_mod_CFLAGS = $(COMMON_CFLAGS) kernel_mod_ASFLAGS = $(COMMON_ASFLAGS) kernel_mod_LDFLAGS = $(COMMON_LDFLAGS) diff --git a/conf/i386-ieee1275.rmk b/conf/i386-ieee1275.rmk index 305b31d..460dfdd 100644 --- a/conf/i386-ieee1275.rmk +++ b/conf/i386-ieee1275.rmk @@ -102,7 +102,7 @@ grub_install_SOURCES = util/ieee1275/grub-install.in pkglib_MODULES = normal.mod halt.mod reboot.mod suspend.mod \ multiboot.mod _multiboot.mod aout.mod serial.mod linux.mod \ _linux.mod nand.mod memdisk.mod pci.mod lspci.mod datetime.mod \ - date.mod datehook.mod lsmmap.mod + date.mod datehook.mod # # Only arch dependant part of normal.mod will be here. Common part for @@ -209,10 +209,5 @@ datehook_mod_SOURCES = hook/datehook.c datehook_mod_CFLAGS = $(COMMON_CFLAGS) datehook_mod_LDFLAGS = $(COMMON_LDFLAGS) -# For lsmmap.mod -lsmmap_mod_SOURCES = commands/lsmmap.c -lsmmap_mod_CFLAGS = $(COMMON_CFLAGS) -lsmmap_mod_LDFLAGS = $(COMMON_LDFLAGS) - include $(srcdir)/conf/i386.mk include $(srcdir)/conf/common.mk diff --git a/conf/i386-pc.rmk b/conf/i386-pc.rmk index e1ed9aa..0be2729 100644 --- a/conf/i386-pc.rmk +++ b/conf/i386-pc.rmk @@ -178,8 +178,8 @@ pkglib_MODULES = biosdisk.mod _chain.mod _linux.mod linux.mod normal.mod \ _multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod \ vbe.mod vbetest.mod vbeinfo.mod play.mod serial.mod \ ata.mod vga.mod memdisk.mod pci.mod lspci.mod \ - aout.mod _bsd.mod bsd.mod pxe.mod pxecmd.mod datetime.mod date.mod \ - datehook.mod lsmmap.mod ata_pthru.mod hdparm.mod \ + pxe.mod pxecmd.mod datetime.mod date.mod \ + datehook.mod ata_pthru.mod hdparm.mod \ usb.mod uhci.mod ohci.mod usbtest.mod usbms.mod usb_keyboard.mod \ efiemu.mod efiemu_acpi.mo
[Patch] Move normal.mod to conf/common.rmk
Hello. I propose to create a symlink normal/cpu. This way normal.mod can be moved to conf/common.rmk. Works fine on i386-pc. Can people having other platforms test? -- Regards Vladimir 'phcoder' Serbinenko diff --git a/Makefile.in b/Makefile.in index 28aa385..c4c641a 100644 --- a/Makefile.in +++ b/Makefile.in @@ -120,7 +120,7 @@ SCRIPTS = $(bin_SCRIPTS) $(sbin_SCRIPTS) $(grub-mkconfig_SCRIPTS) CLEANFILES = MOSTLYCLEANFILES = DISTCLEANFILES = config.status config.cache config.log config.h \ - Makefile stamp-h include/grub/cpu include/grub/machine \ + Makefile stamp-h include/grub/cpu include/grub/machine normal/cpu \ gensymlist.sh genkernsyms.sh build_env.mk MAINTAINER_CLEANFILES = $(srcdir)/configure $(addprefix $(srcdir)/,$(MKFILES)) diff --git a/conf/common.rmk b/conf/common.rmk index 43bc683..72a46bf 100644 --- a/conf/common.rmk +++ b/conf/common.rmk @@ -54,6 +54,21 @@ grub_mkfont_CFLAGS = $(freetype_cflags) grub_mkfont_LDFLAGS = $(freetype_libs) endif +pkglib_MODULES += normal.mod + +normal_mod_SOURCES = normal/cmdline.c normal/command.c \ + normal/completion.c normal/execute.c \ + normal/function.c normal/lexer.c normal/main.c normal/menu.c \ + normal/menu_text.c \ + normal/color.c \ + normal/menu_viewer.c normal/menu_entry.c \ + normal/misc.c grub_script.tab.c \ + normal/script.c \ + normal/cpu/setjmp.S +normal_mod_CFLAGS = $(COMMON_CFLAGS) +normal_mod_ASFLAGS = $(COMMON_ASFLAGS) +normal_mod_LDFLAGS = $(COMMON_LDFLAGS) + # For the parser. grub_script.tab.c grub_script.tab.h: normal/parser.y $(YACC) -d -p grub_script_yy -b grub_script $(srcdir)/normal/parser.y diff --git a/conf/i386-coreboot.rmk b/conf/i386-coreboot.rmk index 53595de..84d21e5 100644 --- a/conf/i386-coreboot.rmk +++ b/conf/i386-coreboot.rmk @@ -96,7 +96,7 @@ sbin_SCRIPTS += grub-install grub_install_SOURCES = util/i386/pc/grub-install.in # Modules. -pkglib_MODULES = linux.mod normal.mod multiboot.mod \ +pkglib_MODULES = linux.mod multiboot.mod \ aout.mod play.mod serial.mod ata.mod \ memdisk.mod pci.mod lspci.mod reboot.mod \ halt.mod datetime.mod date.mod datehook.mod \ @@ -107,27 +107,6 @@ linux_mod_SOURCES = loader/i386/linux.c linux_mod_CFLAGS = $(COMMON_CFLAGS) linux_mod_LDFLAGS = $(COMMON_LDFLAGS) -# -# Only arch dependant part of normal.mod will be here. Common part for -# all architecures of normal.mod is at start and should be kept at sync -# with other makefiles. -# -# Please put arch dependant part of normal.mod at the end of list to -# keep it simpler to update to different architectures. -# -normal_mod_SOURCES = normal/cmdline.c normal/command.c \ - normal/completion.c normal/execute.c \ - normal/function.c normal/lexer.c normal/main.c normal/menu.c \ - normal/menu_text.c \ - normal/color.c \ - normal/menu_viewer.c normal/menu_entry.c \ - normal/misc.c grub_script.tab.c \ - normal/script.c \ - normal/i386/setjmp.S -normal_mod_CFLAGS = $(COMMON_CFLAGS) -normal_mod_ASFLAGS = $(COMMON_ASFLAGS) -normal_mod_LDFLAGS = $(COMMON_LDFLAGS) - # For reboot.mod. reboot_mod_SOURCES = commands/reboot.c kern/i386/reboot.c reboot_mod_CFLAGS = $(COMMON_CFLAGS) diff --git a/conf/i386-efi.rmk b/conf/i386-efi.rmk index 18a99df..6dd569e 100644 --- a/conf/i386-efi.rmk +++ b/conf/i386-efi.rmk @@ -77,7 +77,7 @@ sbin_SCRIPTS = grub-install grub_install_SOURCES = util/i386/efi/grub-install.in # Modules. -pkglib_MODULES = kernel.mod normal.mod chain.mod appleldr.mod \ +pkglib_MODULES = kernel.mod chain.mod appleldr.mod \ linux.mod halt.mod reboot.mod pci.mod lspci.mod \ datetime.mod date.mod datehook.mod @@ -111,27 +111,6 @@ symlist.c: $(addprefix include/grub/,$(kernel_mod_HEADERS)) config.h gensymlist. kernel_syms.lst: $(addprefix include/grub/,$(kernel_mod_HEADERS)) config.h genkernsyms.sh /bin/sh genkernsyms.sh $(filter %.h,$^) > $@ || (rm -f $@; exit 1) -# -# Only arch dependant part of normal.mod will be here. Common part for -# all architecures of normal.mod is at start and should be kept at sync -# with other makefiles. -# -# Please put arch dependant part of normal.mod at the end of list to -# keep it simpler to update to different architectures. -# -normal_mod_SOURCES = normal/cmdline.c normal/command.c \ - normal/completion.c normal/execute.c \ - normal/function.c normal/lexer.c normal/main.c normal/menu.c \ - normal/menu_text.c \ - normal/color.c \ - normal/menu_viewer.c normal/menu_entry.c \ - normal/misc.c grub_script.tab.c \ - normal/script.c \ - normal/i386/setjmp.S -normal_mod_CFLAGS = $(COMMON_CFLAGS) -normal_mod_ASFLAGS = $(COMMON_ASFLAGS) -normal_mod_LDFLAGS = $(COMMON_LDFLAGS) - # For chain.mod. chain_mod_SOURCES = loader/efi/chainloader.c chain_mod_CFLAGS = $(COMMON_CFLAGS) diff --git a/conf/i386-ieee1275.rmk b/conf/i386-ieee1275.rmk index a84b5aa..b285d4f 100644 --- a/conf/i386-ieee1275.rmk +++ b/conf/i386-ieee1275.rmk @@ -99,32 +99,11 @@ sbin_SCRIPTS = grub-install grub_install_SOURCE
Re: [PATCH] Use hfs case ordering - another try
On Mon, 2009-03-23 at 04:23 +0100, Jordi Mallach wrote: > Thanks for rescuing this fix! > > Felix uploaded a new GRUB snapshot which should include this patch. > > However, I'm having the same boot problems as before. Please realize that the hfs fix is just a part of what needs to be done. For GRUB to be a drop-in replacement for yaboot (at least on Fedora), the installation script should be able to understand the layout where only few files are located on the true boot partition (in hfs format, perhaps not mounted), whereas most GRUB files and kernels are placed on a "second boot partition" in ext2 format mounted under /boot. I know not everybody likes this, so the script should keep the ability to support layouts with one boot partition in hfs format. The only machine I have to test it is a very slow G3 PowerMac, and I cannot spend much time on it. I don't want to change partitioning to satisfy the current grub-install. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Move normal.mod to conf/common.rmk
phcoder wrote: > Hello. I propose to create a symlink normal/cpu. This way normal.mod can > be moved to conf/common.rmk. Works fine on i386-pc. Can people having > other platforms test? I do not like the fact that you hardcoded filenames what can be on platform dependant parts. I have also though this issue some times and I think the best option would be: ## common.rmk ## normal.mod: normal_arch.lib ## arch.rmk ## normal_arch.lib: setjmp.S ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Move normal.mod to conf/common.rmk
Actually if it was up to me I would have removed setjmp altogether. IMHO it's a bad programming technique. It's used only to launch rescue mode. I would just call the rescue mode interpreter by function. Perhaps Bean who is working on normal.mod splitting has even better idea. Also IMO normal.mod should have no arch-dependent parts and setjmp.S is an unfortunate example. If some platforms need a special service then it could be provided by drivers and/or commands. I see no reason why additional cpu or platform-dependent would appear in normal.mod setjmp could even be put in a separate module but it's quite a waste because ELF overhead is much bigger then the module itself. Another possibility is ot compile it like ## common.rmk ## normal.mod: setjmp.lib normal_arch.lib: setjmp.S Vesa Jääskeläinen wrote: phcoder wrote: Hello. I propose to create a symlink normal/cpu. This way normal.mod can be moved to conf/common.rmk. Works fine on i386-pc. Can people having other platforms test? I do not like the fact that you hardcoded filenames what can be on platform dependant parts. I have also though this issue some times and I think the best option would be: ## common.rmk ## normal.mod: normal_arch.lib ## arch.rmk ## normal_arch.lib: setjmp.S ___ 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: grub-mkimage
On Sat, 2009-03-21 at 12:26 -0400, Rev. Mr. Gary Meerschaert wrote: > 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. First of all, please specify the version of GRUB. I suggest that you use the current code from Subversion. I cannot reproduce your problem with the current code. Then check if the problem is in grub-mkimage or in diskboot.img. If diskboot.img is 512 bytes long, then grub-mkimage is wrong. If diskboot.img is not 512 bytes long, then the problem is in diskboot.img. In any case, please describe your environment, such as the compiler version, the arguments to the configure script and whatever else may be needed for others to reproduce your problem. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
multiboot2.h includes stdint.h - not good
Hello! The current GRUB reports this on stderr during compilation: In file included from loader/i386/multiboot_helper.S:21: ./include/multiboot2.h:37:20: error: stdint.h: No such file or directory In file included from loader/i386/multiboot_helper.S:21: ./include/multiboot2.h:37:20: error: stdint.h: No such file or directory In file included from loader/i386/multiboot_helper.S:21: ./include/multiboot2.h:37:20: error: stdint.h: No such file or directory There are two problems here. One is that stdint.h cannot be found (apparently, the default includes are not used when compiling for the target). Another problem is that the build succeeds despite such errors. I'm compiling in x86_64 environment (Fedora 10). There are no arguments to configure, so it's compiling for i386-pc. glibc-devel-2.9-3.i386 is installed. /usr/include/stdint.h is present (provided by glibc-headers-2.9-3.x86_64). By the way, I already noticed that the inclusion of stdint.h from multiboot2.h is one of the problems preventing cross-compilation of GRUB without the libc for the target. Perhaps GRUB should provide its replacement for stdint.h when compiling for the target. Alternatively, multiboot2.h should use GRUB types. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Move normal.mod to conf/common.rmk
phcoder wrote: > Actually if it was up to me I would have removed setjmp altogether. IMHO > it's a bad programming technique. It's used only to launch rescue mode. > I would just call the rescue mode interpreter by function. Perhaps Bean > who is working on normal.mod splitting has even better idea. > Also IMO normal.mod should have no arch-dependent parts and setjmp.S is > an unfortunate example. If some platforms need a special service then it > could be provided by drivers and/or commands. I see no reason why > additional cpu or platform-dependent would appear in normal.mod setjmp > could even be put in a separate module but it's quite a waste because > ELF overhead is much bigger then the module itself. Another possibility > is ot compile it like Or.. one could move it to kernel. But that is not as such a kernel component. More like a system library functionality. Actually setjmp might be used in bitmap loaders. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2.h includes stdint.h - not good
Pavel Roskin wrote: > By the way, I already noticed that the inclusion of stdint.h from > multiboot2.h is one of the problems preventing cross-compilation of GRUB > without the libc for the target. Perhaps GRUB should provide its > replacement for stdint.h when compiling for the target. Alternatively, > multiboot2.h should use GRUB types. In grub ecosystem grub_* types should be used to specify arch dependent types. Where as I favor stdint.h types like uint8_t for many things, the idea for grub's own replacement is to easily detect wrong types used on compilation process. So... stdint.h out... grub types in.. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[Design] savedefault
Hello we had a discussion on IRC about implementing savedefault. We've
found 3 possible solutions:
1) just add support for it in grub-mkimage in following way:
load_env
menuentry "menu entry 1" {
default=0
save_env
}
menuentry "menu entry 2" {
default=1
save_env
}
This method has disadvantage of the necessity of counting entries in
grub-mkconfig. This is easily broken OS-specific script count entries
wrong. Also it breaks if user adds entries manually in the middle of the
file
2) Export a variable selected_menu. Then syntax would be sth like
load_env
menuentry "menu entry 1" {
default=$selected_menu
save_env
}
menuentry "menu entry 2" {
default=$selected_menu
save_env
}
3) Add label support syntax would be sth like:
default=ubuntu
menuentry --label ubuntu "Ubuntu" {
}
And for savedefault it would be something like
load_env
menuentry --label linux_ "Linux" {
default=linux_
save_env
}
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot on EFI
Vladimir, First of all I'd like to say thank you for a quick feedback and development. I tried to apply your patches and test it on my Apple Xserve Intel 32 bit. I've done following; # svn co svn://svn.sv.gnu.org/grub/trunk/grub2 # cd ./grub2 # patch -b -p1 < ./uppermem.diff patching file conf/i386.rmk patching file lib/i386/uppermem.c --- it's Ok --- Than # patch -b -p1 < ./efiboot.diff patching file conf/common.rmk Hunk #1 succeeded at 503 (offset -4 lines). patching file conf/i386-coreboot.rmk Hunk #1 succeeded at 99 with fuzz 2 (offset -3 lines). Hunk #2 succeeded at 200 (offset -10 lines). patching file conf/i386-efi.rmk Hunk #1 FAILED at 80. Hunk #2 FAILED at 103. ... etc. I would like to ask you for what revision of grub2 this patches where done? Do I have to checkout any specific branch of grub2? Thank you in advance. 2009/3/23 phcoder : > Hello. Here is an initial version of patch for booting multiboot kernels on > i386-efi. No Changelog yet because it's not for inclusion yet. > -- > > Regards > Vladimir 'phcoder' Serbinenko > > ___ > 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 on EFI
Try with 2030. Actually it's diffed against 2030+some of my posted and unposted patches. If it still doesn't apply please report I'll update and rediff it against HEAD. I'm interested in behaviour of this code on real EFI however doesn't expect this version to be able to work completely. x86_64-efi isn't supported by this patch yet Also if xen uses any bios interrupts it will probably triple fault. On IRC we discussed a possibility of loading seabios and it's probably feasible but will take more time uzer cheg wrote: Vladimir, First of all I'd like to say thank you for a quick feedback and development. I tried to apply your patches and test it on my Apple Xserve Intel 32 bit. I've done following; # svn co svn://svn.sv.gnu.org/grub/trunk/grub2 # cd ./grub2 # patch -b -p1 < ./uppermem.diff patching file conf/i386.rmk patching file lib/i386/uppermem.c --- it's Ok --- Than # patch -b -p1 < ./efiboot.diff patching file conf/common.rmk Hunk #1 succeeded at 503 (offset -4 lines). patching file conf/i386-coreboot.rmk Hunk #1 succeeded at 99 with fuzz 2 (offset -3 lines). Hunk #2 succeeded at 200 (offset -10 lines). patching file conf/i386-efi.rmk Hunk #1 FAILED at 80. Hunk #2 FAILED at 103. ... etc. I would like to ask you for what revision of grub2 this patches where done? Do I have to checkout any specific branch of grub2? Thank you in advance. 2009/3/23 phcoder : Hello. Here is an initial version of patch for booting multiboot kernels on i386-efi. No Changelog yet because it's not for inclusion yet. -- Regards Vladimir 'phcoder' Serbinenko ___ 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: multiboot on EFI
You may also need my elf bugfix patch (was applied as rev 2037) phcoder wrote: Try with 2030. Actually it's diffed against 2030+some of my posted and unposted patches. If it still doesn't apply please report I'll update and rediff it against HEAD. I'm interested in behaviour of this code on real EFI however doesn't expect this version to be able to work completely. x86_64-efi isn't supported by this patch yet Also if xen uses any bios interrupts it will probably triple fault. On IRC we discussed a possibility of loading seabios and it's probably feasible but will take more time uzer cheg wrote: Vladimir, First of all I'd like to say thank you for a quick feedback and development. I tried to apply your patches and test it on my Apple Xserve Intel 32 bit. I've done following; # svn co svn://svn.sv.gnu.org/grub/trunk/grub2 # cd ./grub2 # patch -b -p1 < ./uppermem.diff patching file conf/i386.rmk patching file lib/i386/uppermem.c --- it's Ok --- Than # patch -b -p1 < ./efiboot.diff patching file conf/common.rmk Hunk #1 succeeded at 503 (offset -4 lines). patching file conf/i386-coreboot.rmk Hunk #1 succeeded at 99 with fuzz 2 (offset -3 lines). Hunk #2 succeeded at 200 (offset -10 lines). patching file conf/i386-efi.rmk Hunk #1 FAILED at 80. Hunk #2 FAILED at 103. ... etc. I would like to ask you for what revision of grub2 this patches where done? Do I have to checkout any specific branch of grub2? Thank you in advance. 2009/3/23 phcoder : Hello. Here is an initial version of patch for booting multiboot kernels on i386-efi. No Changelog yet because it's not for inclusion yet. -- Regards Vladimir 'phcoder' Serbinenko ___ 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: [Design] savedefault
On Mon, 2009-03-23 at 21:25 +0100, phcoder wrote:
> Hello we had a discussion on IRC about implementing savedefault. We've
> found 3 possible solutions:
> 1) just add support for it in grub-mkimage in following way:
> load_env
>
> menuentry "menu entry 1" {
> default=0
> save_env
>
> }
> menuentry "menu entry 2" {
> default=1
> save_env
>
> }
>
> This method has disadvantage of the necessity of counting entries in
> grub-mkconfig. This is easily broken OS-specific script count entries
> wrong. Also it breaks if user adds entries manually in the middle of the
> file
I agree. Configuration files should be easily editable.
> 2) Export a variable selected_menu. Then syntax would be sth like
> load_env
>
> menuentry "menu entry 1" {
> default=$selected_menu
> save_env
Maybe we could have an option for save_env to specify the target name so
that it could be done in one operation, e.g.
save_env --as default $selected_menu
Another approach would be to change the "default" variable in the menu
rather than "selected_menu". The original "default" could be saved in
the common part if necessary.
In any case, I think it's better to save the "default" variable only
rather than the whole environment.
> 3) Add label support syntax would be sth like:
> default=ubuntu
> menuentry --label ubuntu "Ubuntu" {
>
> }
> And for savedefault it would be something like
> load_env
> menuentry --label linux_ "Linux" {
> default=linux_
> save_env
>
> }
That's a good idea. Actually, we could export "selected_menu" or
"default" in this case as well to avoid extra statements.
The good thing about textual default is that it won't change if new
entries are added.
I don't think we really need labels. The entry names can be used as
labels. They will be unique most of the time. And if they are not, the
wrong default won't add much to the preexisting confusion.
Here's a far-flung idea. We could use "classes" rather than labels for
advanced configuration. Classes won't be unique. For instance, all
Fedora entries could have class "fedora". Selecting any Fedora kernel
would make the first entry of the "fedora" class load by default. If
another Fedora kernel is installed, the latest kernel would load. But
if an entry of the "ubuntu" class is selected, the first entry of the
"ubuntu" class would be the default.
menuentry --class fedora "Fedora Linux 2.6.28.1-195" {
save_env --as default selected_class
...
}
menuentry --class fedora "Fedora Linux 2.6.28-177" {
save_env --as default selected_class
...
}
menuentry --class ubuntu "Ubuntu Linux 2.6.27-5" {
save_env --as default selected_class
...
}
menuentry --class ubuntu "Ubuntu Linux 2.6.27-2" {
save_env --as default selected_class
...
}
menuentry --class windows "Windows XP" {
save_env --as default selected_class
...
}
menuentry --class windows "Windows XP safe mode" {
save_env --as default selected_class
...
}
menuentry "FreeBSD" {
# classless entry
save_env --as default selected_menu
...
}
menuentry "memtest86" {
# no save_env
...
}
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2.h includes stdint.h - not good
On Mon, 2009-03-23 at 20:43 +0200, Vesa Jääskeläinen wrote:
> Pavel Roskin wrote:
> > By the way, I already noticed that the inclusion of stdint.h from
> > multiboot2.h is one of the problems preventing cross-compilation of GRUB
> > without the libc for the target. Perhaps GRUB should provide its
> > replacement for stdint.h when compiling for the target. Alternatively,
> > multiboot2.h should use GRUB types.
>
> In grub ecosystem grub_* types should be used to specify arch dependent
> types. Where as I favor stdint.h types like uint8_t for many things, the
> idea for grub's own replacement is to easily detect wrong types used on
> compilation process.
>
> So... stdint.h out... grub types in..
OK, let's fix the error messages for now.
It turns out *.lst files for *.S files are generated without ASM_FILE
defined. Real compilation defines ASM_FILE. Several *.S files define
ASM_FILE internally, but loader/i386/multiboot_helper.S is not one of
them.
It's hard to capture errors in the *.lst generation without splitting a
pipe into separate commands and introducing a temporary file, so it's
probably not worth the trouble. Besides, any errors in the list
generation will be caught at the compilation stage if the compiler flags
are the same. But they are not the same, and that's a problem.
ASM_FILE should be consistently defined for the same files in the
compilation rules and in the list generating rules in genmk.rb.
ChangeLog:
* genmk.rb: Define ASM_FILE for *.S files when generating
any lists.
Index: genmk.rb
===
--- genmk.rb(revision 2043)
+++ genmk.rb(working copy)
@@ -159,17 +159,17 @@
#{command}: #{src} $(#{src}_DEPENDENCIES) gencmdlist.sh
set -e; \
- $(TARGET_CC) -I#{dir} -I$(srcdir)/#{dir} $(TARGET_CPPFLAGS)
$(TARGET_#{flag}) $(#{prefix}_#{flag}) -E $< \
+ $(TARGET_CC) -I#{dir} -I$(srcdir)/#{dir} $(TARGET_CPPFLAGS)
#{extra_flags} $(TARGET_#{flag}) $(#{prefix}_#{flag}) -E $< \
| sh $(srcdir)/gencmdlist.sh #{symbolic_name} > $@ || (rm -f $@; exit
1)
#{fs}: #{src} $(#{src}_DEPENDENCIES) genfslist.sh
set -e; \
- $(TARGET_CC) -I#{dir} -I$(srcdir)/#{dir} $(TARGET_CPPFLAGS)
$(TARGET_#{flag}) $(#{prefix}_#{flag}) -E $< \
+ $(TARGET_CC) -I#{dir} -I$(srcdir)/#{dir} $(TARGET_CPPFLAGS)
#{extra_flags} $(TARGET_#{flag}) $(#{prefix}_#{flag}) -E $< \
| sh $(srcdir)/genfslist.sh #{symbolic_name} > $@ || (rm -f $@; exit
1)
#{partmap}: #{src} $(#{src}_DEPENDENCIES) genpartmaplist.sh
set -e; \
- $(TARGET_CC) -I#{dir} -I$(srcdir)/#{dir} $(TARGET_CPPFLAGS)
$(TARGET_#{flag}) $(#{prefix}_#{flag}) -E $< \
+ $(TARGET_CC) -I#{dir} -I$(srcdir)/#{dir} $(TARGET_CPPFLAGS)
#{extra_flags} $(TARGET_#{flag}) $(#{prefix}_#{flag}) -E $< \
| sh $(srcdir)/genpartmaplist.sh #{symbolic_name} > $@ || (rm -f $@;
exit 1)
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 is not working from pendrive
On Sun, 2009-03-15 at 21:06 +0530, J.Bakshi wrote: > Dear list, > > With legacy GRUB I have no problem to install it on a pendrive and boot the > grub legacy from that drive. Presently I am trying to do the same with grub2. > > My pendrive is 8 GB Transcend with 2 partitions. /devsda1 is fat32 (2 GB) > and /dev/sda2 is reiserfs (6 GB). > > My system is debian lenny and grub Version: 1.96+20080724-16 > > I have mounted my pendrive as ( the reiserfs partition) > > ~ > mount /dev/sda2 /mnt/pen > ~~~ > > Then install grub as > > ~ > grub-install --root-directory=/mnt/pen /dev/sda2 > ~ This installs the bootloader to the first sector of the partition /dev/sda2, not to the MBR (the first sector of the whole drive). BIOS loads the code from the MBR. To install GRUB2 to the MBR of the drive, use grub-install --root-directory=/mnt/pen /dev/sda > Grub install reports a success message. Then I copy grub.cfg from my HDD to > the pendrive at the same location i.e /mnt/pen/boot/grub/ > > Now If I try to boot from the pendrive it says found boot record ...OK > and then displays GRUB but nothing further happens :-( Perhaps you have an old GRUB bootloader in the MBR but it fails to find its files. I checked reiserfs support in the current GRUB2 and it appears to be OK. > What might be the wrong I have done here ? You installed the bootloader to a place where BIOS cannot access it. It's not a regression. grub-legacy would have the same problem. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
