Re: Keyfile Support for GRUBs LUKS
On 11/20/13 07:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote: It's not that easy. Trouble is that you need to also prevent inconsistent rollback and for this you need to have a hash tree. Then since power failure is a possibility you need this tree to be consistent at every moment. Those issues are a bit easier to handle on FS level. ZFS supports HMACs. BtrFS perhaps will one day. Minor terminology nit: ZFS has a MAC not an HMAC. HMAC implies a hash based MAC such as HMAC-SHA256. ZFS uses AES-CCM or AES-GCM modes which are AEAD modes that produce an Auth/MAC tag. You could do an equivalent thing with AES-CBC or AES-XTS plus HMAC-SHA256 (the original ZFS crypto prototype was AES-CBC with HMAC-SHA256 but I switched to AES-CCM/GCM). -- Darren J Moffat ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot root-on-zfs errors
Hello. I have built and installed Grub from trunk (lbeit without docs and efiemu, which I don't need). I have also installed the boot code and have booted from grub. Here are my results: * grub-probe correctly identifies partitions as ZFS. * grub-mkconfig correctly generates a config file and has the correct path, insmod code for zfs-booting. * grub-mkconfig does not detect an ubuntu linux (btrfs) install on separate HDD. * At boot time, grub menu comes up, and starts to boot normally into the ZFS pool. However boot stops at mounting root because no such file system, and BTX (the FreeBSD loader) is very unresponsive. This is probably because I have newcons installed as patch in FreeBSD-current (11). * Modified grub.cfg to include menu item having kfreebsd //@/boot/loader for chain-loading into BTX. Chain-load method successfully boots into zfs-based root and mounts all FS. Difference between direct-boot and chainload seems to be access to zpool.cache, which is actually different and maybe even a little buggy at this date in 11 (I had some problems with automatically bringing up non-root zpools and had to make some modifications in order to get it working) Advise if any other info is required. Thanks and Regards. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot root-on-zfs errors
On 25.11.2013 12:08, Beeblebrox wrote: * At boot time, grub menu comes up, and starts to boot normally into the ZFS pool. However boot stops at mounting root because no such file system, and BTX (the FreeBSD loader) is very unresponsive. What do you mean by BTX? The standard GRUB entries for FReeBSD circumvent BTX altogether. signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[RFT] HFS(+) installs on macs
Hello, I've added support to grub-install for HFS(+) installs in the branch phcoder/mac. I tested it on my PowerPC mac (--macppc-dir). Could someone test it on Intel one? Just use grub-install with --efi-directory pointing to a mountpoint of an empty HFS(+) partition signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configure grub for pxe boot and nfs-mounted root
I tried as suggested, # grub-mknetdir --net-directory=/data/tftp --subdir=boot And no files were plced in /data/tftp/boot I did not see the relevance, but I also tried, # grub-mknetdir --net-directory=/data/tftp --subdir=boot /dev/ada0 grub-mknetdir: Too many arguments Try 'grub-mknetdir --help' or 'grub-mknetdir --usage' for more information. What am I doing wrong? Do I need to start NFS services and set net-directory=192.168.2.1:/data/tftp? I do not understand the meaning of install_device from man page: SYNOPSIS grub-mknetdir [OPTION] install_device ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configure grub for pxe boot and nfs-mounted root
On Nov 25, 2013 4:29 PM, Beeblebrox zap...@berentweb.com wrote: I tried as suggested, # grub-mknetdir --net-directory=/data/tftp --subdir=boot And no files were plced in /data/tftp/boot paste full output with -v I did not see the relevance, but I also tried, # grub-mknetdir --net-directory=/data/tftp --subdir=boot /dev/ada0 grub-mknetdir: Too many arguments Try 'grub-mknetdir --help' or 'grub-mknetdir --usage' for more information. What am I doing wrong? Do I need to start NFS services and set net-directory=192.168.2.1:/data/tftp? I do not understand the meaning of install_device from man page: SYNOPSIS grub-mknetdir [OPTION] install_device it's a leftover ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configure grub for pxe boot and nfs-mounted root
# grub-mknetdir -v = no output dmesg shows nothing ls -la /usr/local/bin/grub-mknetdir -rwxr-xr-x 1 root wheel 444009 Nov 24 17:53 grub-mknetdir* ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot root-on-zfs errors
On Fri, Nov 22, 2013 at 02:30:28PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 22.11.2013 14:16, Colin Watson wrote: This will not be sufficient to build on GNU/Hurd (get_ofpathname isn't directly relevant to that platform, but that function will be compiled there anyway). We need to avoid the use of PATH_MAX entirely, per: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html Sth like diff --git a/grub-core/osdep/unix/platform.c b/grub-core/osdep/unix/platform.c Yes, that looks better to me. Thanks. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 boot root-on-zfs errors
В Mon, 25 Nov 2013 13:08:45 +0200 Beeblebrox zap...@berentweb.com пишет: * grub-mkconfig does not detect an ubuntu linux (btrfs) install on separate HDD. Detection of other systems is implemented outside of grub2; it is done by os-prober. grub-mkconfig will launch os-prober if it is found and interpret its output, that's all. It is done as part of /etc/grub.d framework, so any custom code is possible instead of os-prober. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Explicitly check for linking format to use for efiemu64 module
В Mon, 25 Nov 2013 05:22:58 +0100 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет: + CFLAGS=-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone + LDFLAGS=-m64 -Wl,$format -nostdlib You need -static as otherwise on Apple systems it will try to pull in the dynamic linker which we don't want (scratch comment about other thread, I though of adding -static everywhere but it's no necessarry after all) I used the same flags as in Makefile. If -static is needed here should not it be added to grub-core/Makefile.am as well? diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am index e2da083..e6862b7 100644 --- a/grub-core/Makefile.am +++ b/grub-core/Makefile.am @@ -421,7 +421,7 @@ efiemu64.o: efiemu64_c.o efiemu64_s.o $(TARGET_OBJ2ELEF) $(TARGET_OBJCONV) -felf64 -nu -nd $@.bin $@ || exit 1; \ rm -f $@.bin; \ Here the check for apple linker has to be adjusted as x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64 Mmm ... but I assume apple linker case *did* work before and it broke only for the case !TARGET_APPLE_LINKER. Should $(EFIEMU64_LINK_FORMAT) be added for apple linker case as well? I have no way to test it. signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Explicitly check for linking format to use for efiemu64 module
On 25.11.2013 18:42, Andrey Borzenkov wrote: В Mon, 25 Nov 2013 05:22:58 +0100 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет: + CFLAGS=-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone + LDFLAGS=-m64 -Wl,$format -nostdlib You need -static as otherwise on Apple systems it will try to pull in the dynamic linker which we don't want (scratch comment about other thread, I though of adding -static everywhere but it's no necessarry after all) I used the same flags as in Makefile. If -static is needed here should not it be added to grub-core/Makefile.am as well? diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am index e2da083..e6862b7 100644 --- a/grub-core/Makefile.am +++ b/grub-core/Makefile.am @@ -421,7 +421,7 @@ efiemu64.o: efiemu64_c.o efiemu64_s.o $(TARGET_OBJ2ELEF) $(TARGET_OBJCONV) -felf64 -nu -nd $@.bin $@ || exit 1; \ rm -f $@.bin; \ Here the check for apple linker has to be adjusted as x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64 Mmm ... but I assume apple linker case *did* work before and it broke only for the case !TARGET_APPLE_LINKER. Should $(EFIEMU64_LINK_FORMAT) be added for apple linker case as well? I have no way to test it. What I mean is that TARGET_APPLE_LINKER is conditioned on link_format. And in this case we should check for efiemu64_link_format. As for the exact command, don't worry too much about it, I'll clean it up and unify the two cases after your patch is merged. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
2.02 Release roadmap
Hello, all. It's time to start gearing towards 2.02 release - 2.01 number will be skipped in order to follow odd/even convention for release/git. On 17th December will be the feature freeze, after it only bugfixes and documentation will be committed. Release will be when we're confifent enough in absence of major bugs. Features I expect to go in before freeze: - Leif Lindholm's arm64 port: it's pretty complete from what I saw. - multiboot2 extension to skip teminating boot services - mac HFS+ install - yeeloong 3A support (almost done) - grub-file - truecrypt - Andrey's inline inode patch In case anyone has unreviewed patches please inform me as soon as possible (mail could have been lost or I might have forgotten some of them) signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] Explicitly check for linking format to use for efiemu64 module
Similar to check for target linking format, also check for efiemu64
instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
variants. We cannot easily reuse main target check because platforms
are different (main target is 32 bit and efiemu64 - 64 bit).
This commit adds EFIEMU64_LINK_FORMAT that contains detected
link option and is used in efiemu64.o linking instead of hardcoded
value.
Reported-By: Beeblebrox zap...@berentweb.com
---
configure.ac | 29 +++--
grub-core/Makefile.am | 9 -
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index d1292c9..1989f87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -654,6 +654,30 @@ if test x$efiemu_excuse = x ; then
efiemu_excuse=cannot compile with -m64 -mcmodel=large -mno-red-zone
-nostdlib
fi
fi
+if test x$efiemu_excuse = x ; then
+ AC_CACHE_CHECK([for efiemu64 linking format],
[grub_cv_target_cc_efiemu64_link_format], [
+grub_cv_target_cc_efiemu64_link_format=unknown
+for format in -melf_x86_64 -melf_x86_64_fbsd -melf_x86_64_obsd
-melf_x86_64_haiku -arch,x86_64; do
+ CFLAGS=-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone
+ LDFLAGS=-m64 -Wl,$format -nostdlib -static
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[
+ asm (.globl start; start:);
+ asm (.globl _start; _start:);
+ asm (.globl __start; __start:);
+ void __main (void);
+ void __main (void) {}
+ ]], [[]])], [flag=1], [flag=0])
+ if test x$flag = x1; then
+grub_cv_target_cc_efiemu64_link_format=$format
+ break;
+ fi
+done])
+ if test x$grub_cv_target_cc_efiemu64_link_format = xunknown; then
+efiemu_excuse=no suitable link format for efiemu64 found
+ else
+EFIEMU64_LINK_FORMAT=-Wl,$grub_cv_target_cc_efiemu64_link_format
+ fi
+fi
if test x$enable_efiemu = xyes test x$efiemu_excuse != x ; then
AC_MSG_ERROR([efiemu runtime was explicitly requested but can't be compiled])
fi
@@ -663,11 +687,12 @@ else
enable_efiemu=no
fi
AC_SUBST([enable_efiemu])
+AC_SUBST([EFIEMU64_LINK_FORMAT])
CFLAGS=$TARGET_CFLAGS
if test x$target_cpu = xi386 || test x$target_cpu = xx86_64; then
- AC_CACHE_CHECK([for linking format], [grub_cv_target_cc_link_format], [
+ AC_CACHE_CHECK([for target linking format], [grub_cv_target_cc_link_format],
[
grub_cv_target_cc_link_format=unknown
for format in -melf_${target_cpu} -melf_${target_cpu}_fbsd
-melf_${target_cpu}_obsd -melf_${target_cpu}_haiku -m${target_cpu}pe
-arch,${target_cpu}; do
if test x${target_cpu} != xi386 test x$format = x${target_cpu}pe; then
@@ -681,7 +706,7 @@ if test x$target_cpu = xi386 || test x$target_cpu =
xx86_64; then
asm (.globl __start; __start:);
void __main (void);
void __main (void) {}
- ]], [[]])], [flag=1], [])
+ ]], [[]])], [flag=1], [flag=0])
if test x$flag = x1; then
grub_cv_target_cc_link_format=$format
break;
diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
index e2da083..3ca52ea 100644
--- a/grub-core/Makefile.am
+++ b/grub-core/Makefile.am
@@ -399,7 +399,7 @@ efiemu32.o: efiemu/runtime/efiemu.c $(TARGET_OBJ2ELF)
fi
efiemu64_c.o: efiemu/runtime/efiemu.c
- if test x$(TARGET_APPLE_LINKER) = x1; then \
+ if test x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64; then \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -nostdlib -Wall -Werror -mno-red-zone -c -o $@ $ ||
exit 1; \
else \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -nostdlib -Wall -Werror -O2 -mcmodel=large
-mno-red-zone -c -o $@ $ || exit 1; \
@@ -407,7 +407,7 @@ efiemu64_c.o: efiemu/runtime/efiemu.c
efiemu64_s.o: efiemu/runtime/efiemu.S
-rm -f $@
- if test x$(TARGET_APPLE_LINKER) = x1; then \
+ if test x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64; then \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -Wall -Werror -nostdlib -O2 -mno-red-zone -c -o $@ $
|| exit 1; \
else \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -Wall -Werror -nostdlib -O2 -mcmodel=large
-mno-red-zone -c -o $@ $ || exit 1; \
@@ -415,14 +415,13 @@ efiemu64_s.o: efiemu/runtime/efiemu.S
efiemu64.o: efiemu64_c.o efiemu64_s.o $(TARGET_OBJ2ELEF)
-rm -f $@; \
- if test x$(TARGET_APPLE_LINKER) = x1; then \
+ if test x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64; then \
rm -f $@.bin; \
$(TARGET_CC) -m64 -Wl,-r -nostdlib -o $@.bin $^ || exit 1; \
$(TARGET_OBJCONV) -felf64 -nu -nd $@.bin $@ || exit 1; \
rm -f $@.bin; \
else \
- $(TARGET_CC) -m64 -Wl,-melf_x86_64 -nostdlib -Wl,-r -o $@ $^ || exit
1; \
- if test ! -z $(TARGET_OBJ2ELF); then $(TARGET_OBJ2ELF) $@ || (rm -f
$@; exit 1); fi; \
+ $(TARGET_CC) -m64 $(EFIEMU64_LINK_FORMAT)
Re: 2.02 Release roadmap
It is too late, then, to submit a patch adding a new command to GRUB? I've been meaning to submit it but have been busy... it's already done and everything, just want to see if I can get upstream. :) On Mon, Nov 25, 2013 at 12:58 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: Hello, all. It's time to start gearing towards 2.02 release - 2.01 number will be skipped in order to follow odd/even convention for release/git. On 17th December will be the feature freeze, after it only bugfixes and documentation will be committed. Release will be when we're confifent enough in absence of major bugs. Features I expect to go in before freeze: - Leif Lindholm's arm64 port: it's pretty complete from what I saw. - multiboot2 extension to skip teminating boot services - mac HFS+ install - yeeloong 3A support (almost done) - grub-file - truecrypt - Andrey's inline inode patch In case anyone has unreviewed patches please inform me as soon as possible (mail could have been lost or I might have forgotten some of them) ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configure grub for pxe boot and nfs-mounted root
On 25.11.2013 17:25, Beeblebrox wrote: # grub-mknetdir -v = no output dmesg shows nothing Found the problem. Either use -d or upgrade. ls -la /usr/local/bin/grub-mknetdir -rwxr-xr-x 1 root wheel 444009 Nov 24 17:53 grub-mknetdir* ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: 2.02 Release roadmap
On 25.11.2013 19:14, SevenBits wrote: It is too late, then, to submit a patch adding a new command to GRUB? I've been meaning to submit it but have been busy... it's already done and everything, just want to see if I can get upstream. :) It's not frozen yet (see the date). Then, of course, it depends on how big and intrusive the code is. On Mon, Nov 25, 2013 at 12:58 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: Hello, all. It's time to start gearing towards 2.02 release - 2.01 number will be skipped in order to follow odd/even convention for release/git. On 17th December will be the feature freeze, after it only bugfixes and documentation will be committed. Release will be when we're confifent enough in absence of major bugs. Features I expect to go in before freeze: - Leif Lindholm's arm64 port: it's pretty complete from what I saw. - multiboot2 extension to skip teminating boot services - mac HFS+ install - yeeloong 3A support (almost done) - grub-file - truecrypt - Andrey's inline inode patch In case anyone has unreviewed patches please inform me as soon as possible (mail could have been lost or I might have forgotten some of them) ___ Grub-devel mailing list Grub-devel@gnu.org mailto:Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GIT workflow
В Thu, 14 Nov 2013 15:20:10 +0200 Mikko Rantalainen mikko.rantalai...@peda.net пишет: Vladimir 'φ-coder/phcoder' Serbinenko, 2013-11-10 19:01 (Europe/Helsinki): Hello, all. We've switched to git some time ago, now we should have some kind of workflow documents. In particular I think of following points: - Developpers with commit access can create branches as they see fit as long as it's prefixed by their name and they don't do sth nasty like storing binary or unrelated files. - When committing bigger work should we merge or squash? I think that squash should be possible if developper desires. Is there any reason to use merges? Squashed merge is identical to rebase merge --no-ff except for the detail that squashing loses any meaningful history for the patch series. I'd seriously suggest rebase followed by merge --no-ff over squashed merges. The only exception is the case where commits in the original work are not logical patches but instead random snapshots of the directory tree during development of the patch. In that case, squashing the patch series loses no valuable information. The reason to keep patch series: git bisect Also squash is losing individual contribution. I think it really depends. For simple patches that are self-contained squash is actually better; that is basically what TopGIT does to maintain patches. For anything developed over long time history should be preserved (a.k.a. merge). - Which commits should we sign? All? Some? Official releases? Depends on what you mean by sign. If you mean Signed-off-by: A U Thor a.u.t...@example.com that's the Developer Certificate Of Origin: http://elinux.org/Developer_Certificate_Of_Origin Other projects (e.g Grub) can decide their own policy for such metadata. Additional info is available at http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for If you mean digitally signed, the correct method is to use signed tags for all the releases meant for non-developers. See git help tag and look for --sign. Release tags should better be signed; is there official key to be used in this case? I have additional topic - format of commit message Established GIT commit message is single summary line followed by more extensive description if necessary. Quite a number of git commands and wrappers around git assume that the summary line is present. Currently commit message format is near to useless. Half of the first line is lost for file name; the second half is partial sentence, often meaningless. Could we break with tradition commit message == ChangeLog entry? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Explicitly check for linking format to use for efiemu64 module
В Mon, 25 Nov 2013 19:19:00 +0100
Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет:
On 25.11.2013 19:13, Andrey Borzenkov wrote:
Similar to check for target linking format, also check for efiemu64
instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
variants. We cannot easily reuse main target check because platforms
are different (main target is 32 bit and efiemu64 - 64 bit).
This commit adds EFIEMU64_LINK_FORMAT that contains detected
link option and is used in efiemu64.o linking instead of hardcoded
value.
Go ahead
Committed with additional comment in grub-core/Makefile.am that
-arch,x86_64 == Apple linker
Reported-By: Beeblebrox zap...@berentweb.com
---
configure.ac | 29 +++--
grub-core/Makefile.am | 9 -
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index d1292c9..1989f87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -654,6 +654,30 @@ if test x$efiemu_excuse = x ; then
efiemu_excuse=cannot compile with -m64 -mcmodel=large -mno-red-zone
-nostdlib
fi
fi
+if test x$efiemu_excuse = x ; then
+ AC_CACHE_CHECK([for efiemu64 linking format],
[grub_cv_target_cc_efiemu64_link_format], [
+grub_cv_target_cc_efiemu64_link_format=unknown
+for format in -melf_x86_64 -melf_x86_64_fbsd -melf_x86_64_obsd
-melf_x86_64_haiku -arch,x86_64; do
+ CFLAGS=-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone
+ LDFLAGS=-m64 -Wl,$format -nostdlib -static
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[
+ asm (.globl start; start:);
+ asm (.globl _start; _start:);
+ asm (.globl __start; __start:);
+ void __main (void);
+ void __main (void) {}
+ ]], [[]])], [flag=1], [flag=0])
+ if test x$flag = x1; then
+grub_cv_target_cc_efiemu64_link_format=$format
+ break;
+ fi
+done])
+ if test x$grub_cv_target_cc_efiemu64_link_format = xunknown; then
+efiemu_excuse=no suitable link format for efiemu64 found
+ else
+EFIEMU64_LINK_FORMAT=-Wl,$grub_cv_target_cc_efiemu64_link_format
+ fi
+fi
if test x$enable_efiemu = xyes test x$efiemu_excuse != x ; then
AC_MSG_ERROR([efiemu runtime was explicitly requested but can't be
compiled])
fi
@@ -663,11 +687,12 @@ else
enable_efiemu=no
fi
AC_SUBST([enable_efiemu])
+AC_SUBST([EFIEMU64_LINK_FORMAT])
CFLAGS=$TARGET_CFLAGS
if test x$target_cpu = xi386 || test x$target_cpu = xx86_64; then
- AC_CACHE_CHECK([for linking format], [grub_cv_target_cc_link_format], [
+ AC_CACHE_CHECK([for target linking format],
[grub_cv_target_cc_link_format], [
grub_cv_target_cc_link_format=unknown
for format in -melf_${target_cpu} -melf_${target_cpu}_fbsd
-melf_${target_cpu}_obsd -melf_${target_cpu}_haiku -m${target_cpu}pe
-arch,${target_cpu}; do
if test x${target_cpu} != xi386 test x$format = x${target_cpu}pe;
then
@@ -681,7 +706,7 @@ if test x$target_cpu = xi386 || test x$target_cpu =
xx86_64; then
asm (.globl __start; __start:);
void __main (void);
void __main (void) {}
- ]], [[]])], [flag=1], [])
+ ]], [[]])], [flag=1], [flag=0])
if test x$flag = x1; then
grub_cv_target_cc_link_format=$format
break;
diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
index e2da083..3ca52ea 100644
--- a/grub-core/Makefile.am
+++ b/grub-core/Makefile.am
@@ -399,7 +399,7 @@ efiemu32.o: efiemu/runtime/efiemu.c $(TARGET_OBJ2ELF)
fi
efiemu64_c.o: efiemu/runtime/efiemu.c
- if test x$(TARGET_APPLE_LINKER) = x1; then \
+ if test x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64; then \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -nostdlib -Wall -Werror -mno-red-zone -c -o $@ $
|| exit 1; \
else \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -nostdlib -Wall -Werror -O2 -mcmodel=large
-mno-red-zone -c -o $@ $ || exit 1; \
@@ -407,7 +407,7 @@ efiemu64_c.o: efiemu/runtime/efiemu.c
efiemu64_s.o: efiemu/runtime/efiemu.S
-rm -f $@
- if test x$(TARGET_APPLE_LINKER) = x1; then \
+ if test x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64; then \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -Wall -Werror -nostdlib -O2 -mno-red-zone -c -o $@
$ || exit 1; \
else \
$(TARGET_CC) $(DEFS) $(INCLUDES) $(CPPFLAGS_EFIEMU)
$(CPPFLAGS_DEFAULT) -m64 -Wall -Werror -nostdlib -O2 -mcmodel=large
-mno-red-zone -c -o $@ $ || exit 1; \
@@ -415,14 +415,13 @@ efiemu64_s.o: efiemu/runtime/efiemu.S
efiemu64.o: efiemu64_c.o efiemu64_s.o $(TARGET_OBJ2ELEF)
-rm -f $@; \
- if test x$(TARGET_APPLE_LINKER) = x1; then \
+ if test x$(EFIEMU64_LINK_FORMAT) = x-arch,x86_64; then \
rm -f $@.bin; \
Re: [Xen-devel] pvgrub2 is merged
On Mon, 25 Nov 2013, Fabio Fantoni wrote: I did a test following informations on one of post before: git clone git://git.sv.gnu.org/grub.git # commit 61e1b9a49d48035bde52784abb54c3212b647fc8 ./autogen.sh ./configure --target=x86_64 --with-platform=xen mkdir -p boot/grub/ cat boot/grub/grub.cfg EOF search -s root -f /boot/grub/grub.cfg configfile /boot/grub/grub.cfg EOF You may want to adapt this script to your circumstances. I ended up with cat boot/grub/grub.cfg EOF insmod part_msdos insmod part_gpt search -s root -f /grub2/grub.cfg configfile /grub2/grub.cfg EOF for a Fedora domU. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O x86_64-xen -d grub-core/ boot/grub/grub.cfg I also suggest export pkgdatadir=. before this so it looks in the grub source rather than the installed version. Of course this may not help your current problem, though I can boot a domU guest with grub configured as above via the hvc0 interface with vnc enabled. Michael Young ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
PATCH: added GRUB command to get and set (U)EFI firmware variables
Hello everyone,
This patch adds two GRUB two commands to allow the user to get and set
the values of (U)EFI firmware variables. When dealing with (U)EFI
firmware with GRUB I decided this would be a useful tool to have for
both developers and end-users.
The first command, setefivariable, takes two parameters: the name of the
variable to set and its value. The second, getefivariable, also takes
two parameters: the name of the variable to retrieve and the name of the
GRUB environment variable in which you want to store the result. This
can then be checked using GRUB's built in 'if' statement and scripting
capability to allow unique booting capabilities based on whether, for
example, secure boot is enabled or the (U)EFI firmware is in setup mode.
Have a look and let me know what you think! The patch follows.
-- SevenBits
diff --git a/grub/grub-core/Makefile.core.def
b/grub-orig/grub-core/Makefile.core.def
index 177d6d6..5cd84b1 100644
--- a/grub/grub-core/Makefile.core.def
+++ b/grub-orig/grub-core/Makefile.core.def
@@ -1004,13 +1004,6 @@ module = {
};
module = {
- name = setvariable;
- common = commands/efi/setvariable.c;
- enable = i386_efi;
- enable = x86_64_efi;
-};
-
-module = {
name = pcidump;
common = commands/pcidump.c;
enable = pci;
diff --git a/grub/grub-core/commands/efi/setvariable.c
b/grub/grub-core/commands/efi/setvariable.c
deleted file mode 100644
index b0d0967..000
--- a/grub/grub-core/commands/efi/setvariable.c
+++ /dev/null
@@ -1,96 +0,0 @@
-/* setvariable.c - get and set efi firmware variables */
-/*
- * GRUB -- GRand Unified Bootloader
- * Copyright (C) 2013 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
- * the Free Software Foundation, either version 3 of the License, or
- * (at your option) any later version.
- *
- * GRUB is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with GRUB. If not, see http://www.gnu.org/licenses/.
- */
-
-#include grub/env.h
-#include grub/dl.h
-#include grub/misc.h
-#include grub/file.h
-#include grub/efi/efi.h
-#include grub/pci.h
-#include grub/command.h
-#include grub/i18n.h
-
-GRUB_MOD_LICENSE (GPLv3+);
-
-static grub_err_t
-grub_cmd_setefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
value expected));
-
-grub_err_t status;
-grub_size_t arg_size = (grub_strlen(argv[1]) + 1) * sizeof(char);
-
-status = grub_efi_set_variable (argv[0], global, argv[1], arg_size);
-if (status != GRUB_ERR_NONE)
-{
-grub_printf (couldn't set efi variable);
-return status;
-}
-return 0;
-}
-
-static grub_err_t
-grub_cmd_getefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
value expected));
-
-grub_size_t var_size;
-grub_err_t status;
-char *value = (char*)grub_efi_get_variable (argv[0], global,
var_size);
-status = grub_env_set (argv[1], value);
-if (status != GRUB_ERR_NONE)
-{
-grub_printf (couldn't set environment variable);
-return status;
-}
-return 0;
-}
-
-static grub_command_t cmd_setefivariable, cmd_getefivariable;
-
-GRUB_MOD_INIT(loadbios)
-{
- cmd_setefivariable = grub_register_command (setefivariable,
grub_cmd_setefivariable,
-N_(NAME VALUE),
-N_(Set an EFI firmware variable
- which can be stored and retrieved
- from between sessions.));
-
- cmd_getefivariable = grub_register_command (getefivariable,
grub_cmd_getefivariable,
-N_(NAME ENV_VARIABLE),
-N_(Gets an EFI firmware variable
- and stores it as a GRUB environment
- variable named ENV_VARIABLE.));
-}
-
-GRUB_MOD_FINI(loadbios)
-{
- grub_unregister_command (cmd_setefivariable);
- grub_unregister_command (cmd_getefivariable);
-}
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
please resend as proper and not as reverse patch. Anotjer issie that can be
seen from description alone is that you don't allow to specify vendor uuid.
it would be needed and slso it needs readable aliases for known types
On Nov 25, 2013 10:35 PM, SevenBits sevenbitst...@gmail.com wrote:
Hello everyone,
This patch adds two GRUB two commands to allow the user to get and set
the values of (U)EFI firmware variables. When dealing with (U)EFI
firmware with GRUB I decided this would be a useful tool to have for
both developers and end-users.
The first command, setefivariable, takes two parameters: the name of the
variable to set and its value. The second, getefivariable, also takes
two parameters: the name of the variable to retrieve and the name of the
GRUB environment variable in which you want to store the result. This
can then be checked using GRUB's built in 'if' statement and scripting
capability to allow unique booting capabilities based on whether, for
example, secure boot is enabled or the (U)EFI firmware is in setup mode.
Have a look and let me know what you think! The patch follows.
-- SevenBits
diff --git a/grub/grub-core/Makefile.core.def
b/grub-orig/grub-core/Makefile.core.def
index 177d6d6..5cd84b1 100644
--- a/grub/grub-core/Makefile.core.def
+++ b/grub-orig/grub-core/Makefile.core.def
@@ -1004,13 +1004,6 @@ module = {
};
module = {
- name = setvariable;
- common = commands/efi/setvariable.c;
- enable = i386_efi;
- enable = x86_64_efi;
-};
-
-module = {
name = pcidump;
common = commands/pcidump.c;
enable = pci;
diff --git a/grub/grub-core/commands/efi/setvariable.c
b/grub/grub-core/commands/efi/setvariable.c
deleted file mode 100644
index b0d0967..000
--- a/grub/grub-core/commands/efi/setvariable.c
+++ /dev/null
@@ -1,96 +0,0 @@
-/* setvariable.c - get and set efi firmware variables */
-/*
- * GRUB -- GRand Unified Bootloader
- * Copyright (C) 2013 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
- * the Free Software Foundation, either version 3 of the License, or
- * (at your option) any later version.
- *
- * GRUB is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with GRUB. If not, see http://www.gnu.org/licenses/.
- */
-
-#include grub/env.h
-#include grub/dl.h
-#include grub/misc.h
-#include grub/file.h
-#include grub/efi/efi.h
-#include grub/pci.h
-#include grub/command.h
-#include grub/i18n.h
-
-GRUB_MOD_LICENSE (GPLv3+);
-
-static grub_err_t
-grub_cmd_setefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
value expected));
-
-grub_err_t status;
-grub_size_t arg_size = (grub_strlen(argv[1]) + 1) * sizeof(char);
-
-status = grub_efi_set_variable (argv[0], global, argv[1], arg_size);
-if (status != GRUB_ERR_NONE)
-{
-grub_printf (couldn't set efi variable);
-return status;
-}
-return 0;
-}
-
-static grub_err_t
-grub_cmd_getefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
value expected));
-
-grub_size_t var_size;
-grub_err_t status;
-char *value = (char*)grub_efi_get_variable (argv[0], global,
var_size);
-status = grub_env_set (argv[1], value);
-if (status != GRUB_ERR_NONE)
-{
-grub_printf (couldn't set environment variable);
-return status;
-}
-return 0;
-}
-
-static grub_command_t cmd_setefivariable, cmd_getefivariable;
-
-GRUB_MOD_INIT(loadbios)
-{
- cmd_setefivariable = grub_register_command (setefivariable,
grub_cmd_setefivariable,
-N_(NAME VALUE),
-N_(Set an EFI firmware variable
- which can be stored and retrieved
- from between sessions.));
-
- cmd_getefivariable = grub_register_command (getefivariable,
grub_cmd_getefivariable,
-N_(NAME ENV_VARIABLE),
-N_(Gets an EFI firmware variable
-
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
On 25.11.2013 23:03, SevenBits wrote:
Thanks for your quick reply.
I just have a couple of questions. How do you prefer I allow the user to
specify the vendor UUID? By typing it in via the keyboard? And secondly,
by saying it needs readable aliases for known types do you mean that
there should be a function to set an integer, one to set a boolean, etc?
I meant for UUIDs. E.g. one alias efi for shared space, apple for
apple and so on.
But type of variable is also an issue and there should be at least
following available:
hex - transform all in hex
utf16 - decode utf16 into utf8
Probably more, didn't really look into issue
Regarding the patch format, I'll tidy that up and send a proper one.
-- SevenBits
On 11/25/2013 04:41 PM, Vladimir 'phcoder' Serbinenko wrote:
please resend as proper and not as reverse patch. Anotjer issie that can be
seen from description alone is that you don't allow to specify vendor
uuid.
it would be needed and slso it needs readable aliases for known types
On Nov 25, 2013 10:35 PM, SevenBits sevenbitst...@gmail.com wrote:
Hello everyone,
This patch adds two GRUB two commands to allow the user to get and set
the values of (U)EFI firmware variables. When dealing with (U)EFI
firmware with GRUB I decided this would be a useful tool to have for
both developers and end-users.
The first command, setefivariable, takes two parameters: the name of the
variable to set and its value. The second, getefivariable, also takes
two parameters: the name of the variable to retrieve and the name of the
GRUB environment variable in which you want to store the result. This
can then be checked using GRUB's built in 'if' statement and scripting
capability to allow unique booting capabilities based on whether, for
example, secure boot is enabled or the (U)EFI firmware is in setup mode.
Have a look and let me know what you think! The patch follows.
-- SevenBits
diff --git a/grub/grub-core/Makefile.core.def
b/grub-orig/grub-core/Makefile.core.def
index 177d6d6..5cd84b1 100644
--- a/grub/grub-core/Makefile.core.def
+++ b/grub-orig/grub-core/Makefile.core.def
@@ -1004,13 +1004,6 @@ module = {
};
module = {
- name = setvariable;
- common = commands/efi/setvariable.c;
- enable = i386_efi;
- enable = x86_64_efi;
-};
-
-module = {
name = pcidump;
common = commands/pcidump.c;
enable = pci;
diff --git a/grub/grub-core/commands/efi/setvariable.c
b/grub/grub-core/commands/efi/setvariable.c
deleted file mode 100644
index b0d0967..000
--- a/grub/grub-core/commands/efi/setvariable.c
+++ /dev/null
@@ -1,96 +0,0 @@
-/* setvariable.c - get and set efi firmware variables */
-/*
- * GRUB -- GRand Unified Bootloader
- * Copyright (C) 2013 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
- * the Free Software Foundation, either version 3 of the License, or
- * (at your option) any later version.
- *
- * GRUB is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with GRUB. If not, see http://www.gnu.org/licenses/.
- */
-
-#include grub/env.h
-#include grub/dl.h
-#include grub/misc.h
-#include grub/file.h
-#include grub/efi/efi.h
-#include grub/pci.h
-#include grub/command.h
-#include grub/i18n.h
-
-GRUB_MOD_LICENSE (GPLv3+);
-
-static grub_err_t
-grub_cmd_setefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
value expected));
-
-grub_err_t status;
-grub_size_t arg_size = (grub_strlen(argv[1]) + 1) * sizeof(char);
-
-status = grub_efi_set_variable (argv[0], global, argv[1],
arg_size);
-if (status != GRUB_ERR_NONE)
-{
-grub_printf (couldn't set efi variable);
-return status;
-}
-return 0;
-}
-
-static grub_err_t
-grub_cmd_getefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable name
value expected));
-
-grub_size_t var_size;
-grub_err_t status;
-char *value = (char*)grub_efi_get_variable (argv[0], global,
var_size);
-
Re: grub2 boot root-on-zfs errors
paste your grub.cfg to give context On Nov 25, 2013 12:09 PM, Beeblebrox zap...@berentweb.com wrote: Hello. I have built and installed Grub from trunk (lbeit without docs and efiemu, which I don't need). I have also installed the boot code and have booted from grub. Here are my results: * grub-probe correctly identifies partitions as ZFS. * grub-mkconfig correctly generates a config file and has the correct path, insmod code for zfs-booting. * grub-mkconfig does not detect an ubuntu linux (btrfs) install on separate HDD. * At boot time, grub menu comes up, and starts to boot normally into the ZFS pool. However boot stops at mounting root because no such file system, and BTX (the FreeBSD loader) is very unresponsive. This is probably because I have newcons installed as patch in FreeBSD-current (11). * Modified grub.cfg to include menu item having kfreebsd //@/boot/loader for chain-loading into BTX. Chain-load method successfully boots into zfs-based root and mounts all FS. Difference between direct-boot and chainload seems to be access to zpool.cache, which is actually different and maybe even a little buggy at this date in 11 (I had some problems with automatically bringing up non-root zpools and had to make some modifications in order to get it working) Advise if any other info is required. Thanks and Regards. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko wrote:
On 25.11.2013 23:03, SevenBits wrote:
Thanks for your quick reply.
I just have a couple of questions. How do you prefer I allow the user to
specify the vendor UUID? By typing it in via the keyboard? And secondly,
by saying it needs readable aliases for known types do you mean that
there should be a function to set an integer, one to set a boolean, etc?
I meant for UUIDs. E.g. one alias efi for shared space, apple for
apple and so on.
So other than a generic variable UUID and Apple, are there others that
you think might be necessary? I can try and put in some common ones but
manufacturers may not disclose what their specific UUIDs are.
But type of variable is also an issue and there should be at least
following available:
hex - transform all in hex
utf16 - decode utf16 into utf8
Probably more, didn't really look into issue
I see, okay, I'll add some in.
Regarding the patch format, I'll tidy that up and send a proper one.
-- SevenBits
On 11/25/2013 04:41 PM, Vladimir 'phcoder' Serbinenko wrote:
please resend as proper and not as reverse patch. Anotjer issie that
can be
seen from description alone is that you don't allow to specify vendor
uuid.
it would be needed and slso it needs readable aliases for known types
On Nov 25, 2013 10:35 PM, SevenBits sevenbitst...@gmail.com wrote:
Hello everyone,
This patch adds two GRUB two commands to allow the user to get and set
the values of (U)EFI firmware variables. When dealing with (U)EFI
firmware with GRUB I decided this would be a useful tool to have for
both developers and end-users.
The first command, setefivariable, takes two parameters: the name
of the
variable to set and its value. The second, getefivariable, also takes
two parameters: the name of the variable to retrieve and the name
of the
GRUB environment variable in which you want to store the result. This
can then be checked using GRUB's built in 'if' statement and scripting
capability to allow unique booting capabilities based on whether, for
example, secure boot is enabled or the (U)EFI firmware is in setup
mode.
Have a look and let me know what you think! The patch follows.
-- SevenBits
diff --git a/grub/grub-core/Makefile.core.def
b/grub-orig/grub-core/Makefile.core.def
index 177d6d6..5cd84b1 100644
--- a/grub/grub-core/Makefile.core.def
+++ b/grub-orig/grub-core/Makefile.core.def
@@ -1004,13 +1004,6 @@ module = {
};
module = {
- name = setvariable;
- common = commands/efi/setvariable.c;
- enable = i386_efi;
- enable = x86_64_efi;
-};
-
-module = {
name = pcidump;
common = commands/pcidump.c;
enable = pci;
diff --git a/grub/grub-core/commands/efi/setvariable.c
b/grub/grub-core/commands/efi/setvariable.c
deleted file mode 100644
index b0d0967..000
--- a/grub/grub-core/commands/efi/setvariable.c
+++ /dev/null
@@ -1,96 +0,0 @@
-/* setvariable.c - get and set efi firmware variables */
-/*
- * GRUB -- GRand Unified Bootloader
- * Copyright (C) 2013 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
- * the Free Software Foundation, either version 3 of the License, or
- * (at your option) any later version.
- *
- * GRUB is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with GRUB. If not, see http://www.gnu.org/licenses/.
- */
-
-#include grub/env.h
-#include grub/dl.h
-#include grub/misc.h
-#include grub/file.h
-#include grub/efi/efi.h
-#include grub/pci.h
-#include grub/command.h
-#include grub/i18n.h
-
-GRUB_MOD_LICENSE (GPLv3+);
-
-static grub_err_t
-grub_cmd_setefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if (argc == 0)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable
name
expected));
-else if (argc == 1)
-return grub_error (GRUB_ERR_BAD_ARGUMENT, N_(efi variable
name
value expected));
-
-grub_err_t status;
-grub_size_t arg_size = (grub_strlen(argv[1]) + 1) * sizeof(char);
-
-status = grub_efi_set_variable (argv[0], global, argv[1],
arg_size);
-if (status != GRUB_ERR_NONE)
-{
-grub_printf (couldn't set efi variable);
-return status;
-}
-return 0;
-}
-
-static grub_err_t
-grub_cmd_getefivariable (grub_command_t cmd __attribute__ ((unused)),
- int argc, char *argv[])
-{
-grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-if
Re: [Xen-devel] pvgrub2 is merged
Il 14/11/2013 22:43, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 14.11.2013 22:11, M A Young wrote: On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 14.11.2013 19:48, M A Young wrote: On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 14.11.2013 18:03, M A Young wrote: On Thu, 14 Nov 2013, M A Young wrote: On Wed, 13 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 13.11.2013 20:06, M A Young wrote: It doesn't seem to understand sub-partitions. I can get it to work if the boot files are in /dev/xvda but not in /dev/xvda1 . insmod part_msdos insmod part_gpt Right, if I add those to the embedded grub.cfg file I get to the standard grub menu and the boot starts. However the boot doesn't get very far - it loads the kernel and the initrd file and starts the kernel but the kernel doesn't see the virtual disks so it doesn't get very far. Using xenstore-ls from the dom0 on the guest when the boot stops the local/domain/2/device/vbd/51712 section looks like backend = /local/domain/0/backend/vbd/2/51712 backend-id = 0 state = 6\000 virtual-device = 51712 device-type = disk ring-ref = \000 event-channel = \000 protocol = x86_64-abi\000 As nothing else has null character endings I suspend that is wrong. Good catch. Could you test following: diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c index 3bfd99f..ab74543 100644 --- a/grub-core/kern/xen/init.c +++ b/grub-core/kern/xen/init.c @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const void *buf, grub_size_t len) grub_memset (msg, 0, sizeof (msg)); msg.type = XS_WRITE; - msg.len = dirlen + len + 1; + msg.len = dirlen + len; grub_xen_store_send (msg, sizeof (msg)); grub_xen_store_send (dir, dirlen); grub_xen_store_send (buf, len); - grub_xen_store_send (, 1); grub_xen_store_recv (msg, sizeof (msg)); resp = grub_malloc (msg.len + 1); if (!resp) The section is tidied up, ie. backend = /local/domain/0/backend/vbd/4/51712 backend-id = 0 state = 6 virtual-device = 51712 device-type = disk ring-ref = event-channel = protocol = x86_64-abi but unfortunately it doesn't help as the boot process sticks at the same point. I notice this section is in state 6 which apparently is closed. I wonder if the kernel expecting something else. Possible. I'd try this (on top of previous patch): Sorry, too tired. I meant: diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c index c449848..9b71d3a 100644 --- a/grub-core/disk/xen/xendisk.c +++ b/grub-core/disk/xen/xendisk.c @@ -449,5 +449,10 @@ grub_xendisk_fini (void) grub_xen_free_shared_page (virtdisks[i].shared_page); grub_xen_event_channel_op (EVTCHNOP_close, close_op); + + /* Prepare for handoff. */ + grub_snprintf (fdir, sizeof (fdir), %s/state, +virtdisks[i].frontend_dir); + grub_xenstore_write_file (fdir, 0, 1); } } That doesn't work. However, according to the documentation state 0 is unknown, and the vif interface (while grub is running) is in state 1 (initializing) so I thought I would try it, and if you replace 0 with 1 in the above patch then the kernel does boot. Thanks. http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c7995256e410c5272e2be2f94faf62d3c9d57b61 and http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e1aa5b662088cea329fc968af7c819784b6da068 Michael Young Thanks for all that have worked for xen support on upstream grub2. I did a test following informations on one of post before: git clone git://git.sv.gnu.org/grub.git # commit 61e1b9a49d48035bde52784abb54c3212b647fc8 ./autogen.sh ./configure --target=x86_64 --with-platform=xen mkdir -p boot/grub/ cat boot/grub/grub.cfg EOF search -s root -f /boot/grub/grub.cfg configfile /boot/grub/grub.cfg EOF ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O x86_64-xen -d grub-core/ boot/grub/grub.cfg Latest command give me this warning: ./grub-mkstandalone: warning: cannot open directory `/usr/local/share/locale': File o directory non esistente. I tried to use it on Sid domU adding this line on domU's xl cfg: kernel = /mnt/vm/pvgrub2/grub/pvgrub2.xen But vnc show black screen and xl console white screen with only this line on start before refresh: Welcome to GRUB! I also tried to add this line: extra = (hd0,msdos1)/grub/grub.cfg but the result on vnc and xl console is the same. I did something wrong? Output of xl -vvv create on attachment. If you need more tests and/or details tell me and I'll post them. Thanks for any reply and sorry for my bad english. ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel xl -vvv create /etc/xen/sid.cfg Parsing config from
Re: [PATCH v2] Explicitly check for linking format to use for efiemu64 module
Or just update to current trunk, I committed this patch. Updated to trunk, it all works gets compiled. Still have to manually clean out the docs references in Makefile however. Thanks for the swift work. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configure grub for pxe boot and nfs-mounted root
Found the problem. Either use -d or upgrade. The -d flag did not work (gave error), so I I upgraded. Works now! # grub-mknetdir --net-directory=/data/tftp --subdir=boot Netboot directory for i386-pc created. Configure your DHCP server to point to /data/tftp/boot/i386-pc/core.0 The DHCP message (where to point) is also very helpful and important. A big hank-you to all of you. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Explicitly check for linking format to use for efiemu64 module
On Tue, Nov 26, 2013 at 11:19 AM, Beeblebrox zap...@berentweb.com wrote: Still have to manually clean out the docs references in Makefile however. Did earlier versions grub.texi compiled? In this case you could try to bisect it. Setup build tree outside of git checkout and just copy grub.texi over; it is self contained. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Explicitly check for linking format to use for efiemu64 module
Did earlier versions grub.texi compiled? Yes, earlier versions of grub.texi did compile. Setup build tree outside of git checkout and just copy grub.texi over; it is self contained. It's OK, I don't need it really. Unless you need me to test and get back to you with results. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Explicitly check for linking format to use for efiemu64 module
On Tue, Nov 26, 2013 at 11:31 AM, Beeblebrox zap...@berentweb.com wrote: It's OK, I don't need it really. Unless you need me to test and get back to you with results. Would be nice; as new release is planned in not so distant future, we should try to iron out problems. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Explicitly check for linking format to use for efiemu64 module
OK, I'll try it. But I need clarification: * Should I copy the repo and do a git rollback on the copy? * Easier to copy only grub/docs to another folder, but how do I start the build then? The Makefile in grub/docs will fail just as when run from top-level. just copy grub.texi over From my current repo, or an older ver? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configure grub for pxe boot and nfs-mounted root
On 26.11.2013 08:22, Beeblebrox wrote: Found the problem. Either use -d or upgrade. The -d flag did not work (gave error), so I I upgraded. Works now! -d requires an argument (consult --help) # grub-mknetdir --net-directory=/data/tftp --subdir=boot Netboot directory for i386-pc created. Configure your DHCP server to point to /data/tftp/boot/i386-pc/core.0 The DHCP message (where to point) is also very helpful and important. A big hank-you to all of you. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
