Re: The submenu command shows a text-based menu when using a GFX theme.
On 26.02.2012 03:18, Towheed Mohammed wrote:
Also consider this. As in the case of the image component, it's file property
allows for a fully qualified filename:
+ image {
file = /usr/share/grub/themes/demo/images/gnu.jpg
This possibility is kept for backward compatibility but shouldn't be
used in new themes and is unreliable. Consider e.g. a case of separate
/boot. Perhaps we should remove this possibility altogether.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: The submenu command shows a text-based menu when using a GFX theme.
I have tested this on separate distros, including but not limited to:
ArchLinux, Debian (and Debian-based distros), Slackware, Fedora, VectorLinux
and openSUSE (some others I can't recall ATM), all with and without separate
/boot partitions and all with GRUB 1.99 installed.. Actually, my demo theme is
located in /usr/share/grub and not in /boot/grub. As it is, the fully
qualified filename works as intended. Placing the themes in /usr/share/grub
removes the incompatibility of having a separate /boot partition and also
removes any incompatibility from some distro that use /boot/grub2 instead of
/boot/grub.
If the unreliability is because of separate /boot partitions and/or other
distros using /boot/grub2 instead of /boot/grub then please consider placing
themes in /usr/share/grub instead of /boot/grub. This removes the
unreliability and ensures the theme will display properly across all distros
and all partitioning schemes.
I don't think users should place files in /boot/grub. Files there should only
be those necessary for the bootloader to function properly. Although it's a
protected directory, it's all to easy for 'inexperienced' users to simply 'su'
and delete critical files (unintentionally while working on themes) thus
preventing their system from booting.
Please keep this feature and consider placing themes in /usr/share/grub.
Thanks.
Towheed Mohammed
- Original Message -
From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com
To: grub-devel@gnu.org
Cc:
Sent: Sunday, February 26, 2012 5:27 AM
Subject: Re: The submenu command shows a text-based menu when using a GFX theme.
On 26.02.2012 03:18, Towheed Mohammed wrote:
Also consider this. As in the case of the image component, it's file
property allows for a fully qualified filename:
+ image {
file = /usr/share/grub/themes/demo/images/gnu.jpg
This possibility is kept for backward compatibility but shouldn't be used in
new themes and is unreliable. Consider e.g. a case of separate /boot. Perhaps
we should remove this possibility altogether.
-- Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
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: The submenu command shows a text-based menu when using a GFX theme.
Towheed Mohammed wrote: I have tested this on separate distros, including but not limited to: ArchLinux, Debian (and Debian-based distros), Slackware, Fedora, VectorLinux and openSUSE (some others I can't recall ATM), all with and without separate /boot partitions and all with GRUB 1.99 installed.. Actually, my demo theme is located in /usr/share/grub and not in /boot/grub. As it is, the fully qualified filename works as intended. Placing the themes in /usr/share/grub removes the incompatibility of having a separate /boot partition and also removes any incompatibility from some distro that use /boot/grub2 instead of /boot/grub. If the unreliability is because of separate /boot partitions and/or other distros using /boot/grub2 instead of /boot/grub then please consider placing themes in /usr/share/grub instead of /boot/grub. This removes the unreliability and ensures the theme will display properly across all distros and all partitioning schemes. I don't think users should place files in /boot/grub. Files there should only be those necessary for the bootloader to function properly. Although it's a protected directory, it's all to easy for 'inexperienced' users to simply 'su' and delete critical files (unintentionally while working on themes) thus preventing their system from booting. Please keep this feature and consider placing themes in /usr/share/grub. This is not a good suggestion. I have several instances of /usr/share on my system in different root filesystem partitions. Which one would grub use? All the files for the boot process need to be in a single partition. /boot/grub2 is a distro specific issue and distros that use it need to maintain it. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: The submenu command shows a text-based menu when using a GFX theme.
On 26.02.2012 17:20, Towheed Mohammed wrote: I have tested this on separate distros, including but not limited to: ArchLinux, Debian (and Debian-based distros), Slackware, Fedora, VectorLinux and openSUSE (some others I can't recall ATM), all with and without separate /boot partitions and all with GRUB 1.99 installed.. Actually, my demo theme is located in /usr/share/grub and not in /boot/grub. As it is, the fully qualified filename works as intended. Placing the themes in /usr/share/grub removes the incompatibility of having a separate /boot partition and also removes any incompatibility from some distro that use /boot/grub2 instead of /boot/grub. Then think about a separate /usr. theme files are static and have no way of knowing about adjusted for some reason directories. Moreover / and /usr may be unavailable to GRUB, e.g. it may be on NFS or encrypted. We can assume only that the $prefix with subdirectories and files needed to boot OS (in case of GNU/Linux it's Linux and initrd in /boot, other OS may have files outside /boot which may assume readable e.g. /mach_kernel for xnu). That's the reason I've adjusted grub-install to copy theme and fonts to $prefix/themes resp $prefix/fonts. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: The submenu command shows a text-based menu when using a GFX theme.
Makes much sense, thanks for the clarification. Towheed Mohammed - Original Message - From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com To: The development of GNU GRUB grub-devel@gnu.org Cc: Sent: Sunday, February 26, 2012 1:02 PM Subject: Re: The submenu command shows a text-based menu when using a GFX theme. On 26.02.2012 17:20, Towheed Mohammed wrote: I have tested this on separate distros, including but not limited to: ArchLinux, Debian (and Debian-based distros), Slackware, Fedora, VectorLinux and openSUSE (some others I can't recall ATM), all with and without separate /boot partitions and all with GRUB 1.99 installed.. Actually, my demo theme is located in /usr/share/grub and not in /boot/grub. As it is, the fully qualified filename works as intended. Placing the themes in /usr/share/grub removes the incompatibility of having a separate /boot partition and also removes any incompatibility from some distro that use /boot/grub2 instead of /boot/grub. Then think about a separate /usr. theme files are static and have no way of knowing about adjusted for some reason directories. Moreover / and /usr may be unavailable to GRUB, e.g. it may be on NFS or encrypted. We can assume only that the $prefix with subdirectories and files needed to boot OS (in case of GNU/Linux it's Linux and initrd in /boot, other OS may have files outside /boot which may assume readable e.g. /mach_kernel for xnu). That's the reason I've adjusted grub-install to copy theme and fonts to $prefix/themes resp $prefix/fonts. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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: Fix for pkgdatadir grub-mkconfig_lib in all util scripts and grub.d scripts
On 21.02.2012 00:57, Grégoire Sutre wrote: On 02/20/2012 06:47 PM, Keshav P R wrote: Hi, Attached patch fixes runtime error due to sed transform used in pkgdatadir Maybe we should apply the sed transform to grub-mkconfig_lib's installation directory, i.e., install grub-mkconfig_lib alongside unicode.pf2 and friends? It seems that the guys on autoconf ML use another convention for pkgdatadir/pkglibdir. So I made GRUB to behave more like what autoconf guys told me. I didn't use any of supplied patches since sed is faster than checking a patch by hand. Grégoire # /_grub_/grub_uefi_x86_64/bin/grub_uefi_x86_64-mkstandalone -h /_grub_/grub_uefi_x86_64/bin/grub_uefi_x86_64-mkstandalone: line 46: /_grub_/grub_uefi_x86_64/share/grub_uefi_x86_64/grub-mkconfig_lib: No such file or directory File is at /_grub_/grub_uefi_x86_64/share/grub/grub-mkconfig_lib (in my case). Please apply this. Thanks in advance. Regards. Keshav ___ 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 -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Infinite loop in __argp_get_display_len
Running grub-mkimage --help triggers an infinite loop in
__argp_get_display_len. Backtrace attached.
The following change seems to resolve it; I wonder if it should be
applied to the other functions in argp-fmtstream.c?
=== modified file 'grub-core/gnulib/argp-fmtstream.c'
--- grub-core/gnulib/argp-fmtstream.c 2012-02-26 18:07:59 +
+++ grub-core/gnulib/argp-fmtstream.c 2012-02-26 19:04:10 +
@@ -133,7 +133,7 @@
size_t s;
s = mbrtowc (wc, ptr, end - ptr, ps);
- if (s == (size_t) -1)
+ if (s == 0 || s == (size_t) -1 || s == (size_t) -2)
break;
r += wcwidth (wc);
ptr += s;
Starting program: /home/floppym/src/grub/build1/grub-mkimage --help
[Thread debugging using libthread_db enabled]
Program received signal SIGINT, Interrupt.
0x0041e4d9 in __argp_get_display_len (beg=0x62c4b0 , end=0x62c518 1)
at ../../../branch1/grub-core/gnulib/argp-fmtstream.c:130
130 for (ptr = beg; ptr end; )
#0 0x0041e4d9 in __argp_get_display_len (beg=0x62c4b0 , end=0x62c518
1)
at ../../../branch1/grub-core/gnulib/argp-fmtstream.c:130
ptr = 0x62c4b0
r = 0
ps = {__count = 0, __value = {__wch = 0, __wchb = \000\000\000}}
#1 0x0041eac4 in _argp_fmtstream_update (fs=0x62c400)
at ../../../branch1/grub-core/gnulib/argp-fmtstream.c:335
p = 0x62c486 R [default=/usr/local/lib/grub/platform]
nextline = 0x62c488 [default=/usr/local/lib/grub/platform]
i = 0
r = 78
buf = 0x62c45f use images and modules under DIR
[default=/usr/local/lib/grub/platform]
nl = 0x62c487 [default=/usr/local/lib/grub/platform]
len = 81
#2 0x0041f2b5 in argp_fmtstream_set_lmargin (__fs=0x62c400,
__lmargin=0)
at ../../../branch1/grub-core/gnulib/argp-fmtstream.h:299
__old = 140737339663948
#3 0x0041ae1b in hol_entry_help (entry=0x62cc20, state=0x7fffd820,
stream=0x62c400,
hhstate=0x7fffd470) at
../../../branch1/grub-core/gnulib/argp-help.c:1219
tstr = 0x421ec8 use images and modules under DIR
[default=%s/platform]
fstr = 0x62c9d0
num = 0
real = 0x628d40
opt = 0x628d70
so = 0x62c781 pmcnoOCv?V
have_long_opt = 1
old_lm = 0
old_wm = 0
pest = {entry = 0x62cc20, stream = 0x62c400, hhstate = 0x7fffd470,
first = 0,
state = 0x7fffd820}
#4 0x0041aecb in hol_help (hol=0x62c520, state=0x7fffd820,
stream=0x62c400)
at ../../../branch1/grub-core/gnulib/argp-help.c:1240
num = 12
entry = 0x62cc20
hhstate = {prev_entry = 0x62cbe8, sep_groups = 0, suppressed_dup_arg =
1}
#5 0x0041be95 in _help (argp=0x7fffd690, state=0x7fffd820,
stream=0x7753d7c0,
flags=634, name=0x7fffde31 grub-mkimage)
at ../../../branch1/grub-core/gnulib/argp-help.c:1694
anything = 1
hol = 0x62c520
fs = 0x62c400
#6 0x0041c060 in argp_state_help (state=0x7fffd820,
stream=0x7753d7c0, flags=634)
at ../../../branch1/grub-core/gnulib/argp-help.c:1765
No locals.
#7 0x0041c524 in argp_default_parser (key=63, arg=0x0,
state=0x7fffd820)
at ../../../branch1/grub-core/gnulib/argp-parse.c:95
No locals.
#8 0x0041c7c0 in group_parse (group=0x62c0f8, state=0x7fffd820,
key=63, arg=0x0)
at ../../../branch1/grub-core/gnulib/argp-parse.c:232
err = 0
#9 0x0041d7e9 in parser_parse_opt (parser=0x7fffd7b0,
opt=33554495, val=0x0)
at ../../../branch1/grub-core/gnulib/argp-parse.c:743
group_key = 2
err = 7
#10 0x0041db3c in parser_parse_next (parser=0x7fffd7b0,
arg_ebadkey=0x7fffd7ac)
at ../../../branch1/grub-core/gnulib/argp-parse.c:855
opt = 33554495
err = 0
#11 0x0041de6c in argp_parse (argp=0x7fffd690, argc=2,
argv=0x7fffda68, flags=0,
end_index=0x0, input=0x7fffd8e0) at
../../../branch1/grub-core/gnulib/argp-parse.c:923
err = 0
parser = {argp = 0x7fffd690, short_opts = 0x62c3c8
d:p:m:c:no:O:C:v?V,
long_opts = 0x62c1e8, opt_data = {rpl_optind = 2, rpl_opterr = 1,
rpl_optopt = -1,
rpl_optarg = 0x0, __initialized = 1, __nextchar = 0x7fffde44
,
__ordering = PERMUTE, __posixly_correct = 0, __first_nonopt = 1,
__last_nonopt = 1},
groups = 0x62c0b0, egroup = 0x62c188, child_inputs = 0x62c1d0,
try_getopt = 1, state = {
root_argp = 0x7fffd690, argc = 2, argv = 0x7fffda68, next =
2, flags = 0,
arg_num = 0, quoted = 0, input = 0x0, child_inputs = 0x0, hook =
0x0,
name = 0x7fffde31 grub-mkimage, err_stream = 0x7753d6e0,
out_stream = 0x7753d7c0, pstate = 0x7fffd7b0}, storage =
0x62c0b0}
arg_ebadkey = 0
#12 0x00409e04 in main (argc=2, argv=0x7fffda68) at
Re: Infinite loop in __argp_get_display_len
On 26.02.2012 20:12, Mike Gilbert wrote: Running grub-mkimage --help triggers an infinite loop in __argp_get_display_len. Backtrace attached. Yes, I've just noticed it. I have a fix, just testing it. The following change seems to resolve it; I wonder if it should be applied to the other functions in argp-fmtstream.c? === modified file 'grub-core/gnulib/argp-fmtstream.c' --- grub-core/gnulib/argp-fmtstream.c 2012-02-26 18:07:59 + +++ grub-core/gnulib/argp-fmtstream.c 2012-02-26 19:04:10 + @@ -133,7 +133,7 @@ size_t s; s = mbrtowc (wc, ptr, end - ptr,ps); - if (s == (size_t) -1) + if (s == 0 || s == (size_t) -1 || s == (size_t) -2) break; r += wcwidth (wc); ptr += s; ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fix for pkgdatadir grub-mkconfig_lib in all util scripts and grub.d scripts
2012/2/26 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: On 21.02.2012 00:57, Grégoire Sutre wrote: On 02/20/2012 06:47 PM, Keshav P R wrote: Hi, Attached patch fixes runtime error due to sed transform used in pkgdatadir Maybe we should apply the sed transform to grub-mkconfig_lib's installation directory, i.e., install grub-mkconfig_lib alongside unicode.pf2 and friends? It seems that the guys on autoconf ML use another convention for pkgdatadir/pkglibdir. So I made GRUB to behave more like what autoconf guys told me. I didn't use any of supplied patches since sed is faster than checking a patch by hand. Ok, so now I get the following error from grub2-install: floppym@naomi /boot % sudo grub2-install /dev/sda cp: cannot stat `/lib64/grub/i386-pc/*.mod': No such file or directory The modules are actually installed in /lib64/grub2/i386-pc. This happens with --libdir=/lib64 and --program-transform-name=s,grub,grub2, ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
Status of this patch in grub2 v2.00 code freeze?
- Keshav
On 09/02/2012, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote:
Go ahead.
On 08.02.2012 17:55, Matthew Garrett wrote:
The Linux boot header includes information on the kernel's desired load
address and alignment. Add support for that.
---
ChangeLog |6 ++
include/grub/i386/linux.h | 28 +++-
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ede7f8e..2bdb3a0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-02-08 Matthew Garrettm...@redhat.com
+
+* include/grub/i386/linux.h (linux_kernel_header): Update to
+boot protocol 2.10.
+(linux_kernel_params): Likewise
+
2012-02-07 Vladimir Serbinenkophco...@gmail.com
* grub-core/lib/i386/relocator16.S: Revert moving A20 code into PM
diff --git a/include/grub/i386/linux.h b/include/grub/i386/linux.h
index 6aa2391..8e27b93 100644
--- a/include/grub/i386/linux.h
+++ b/include/grub/i386/linux.h
@@ -86,7 +86,7 @@ enum
GRUB_VIDEO_LINUX_TYPE_SIMPLE = 0x70/* Linear framebuffer without
any additional functions. */
};
-/* For the Linux/i386 boot protocol version 2.03. */
+/* For the Linux/i386 boot protocol version 2.10. */
struct linux_kernel_header
{
grub_uint8_t code1[0x0020];
@@ -131,8 +131,16 @@ struct linux_kernel_header
grub_uint32_t initrd_addr_max;/* Highest address for initrd */
grub_uint32_t kernel_alignment;
grub_uint8_t relocatable;
- grub_uint8_t pad[3];
+ grub_uint8_t min_alignment;
+ grub_uint8_t pad[2];
grub_uint32_t cmdline_size;
+ grub_uint32_t hardware_subarch;
+ grub_uint64_t hardware_subarch_data;
+ grub_uint32_t payload_offset;
+ grub_uint32_t payload_length;
+ grub_uint64_t setup_data;
+ grub_uint64_t pref_address;
+ grub_uint64_t init_size;
} __attribute__ ((packed));
/* Boot parameters for Linux based on 2.6.12. This is used by the setup
@@ -276,10 +284,20 @@ struct linux_kernel_params
grub_uint32_t ramdisk_size; /* initrd size */
grub_uint32_t bootsect_kludge; /* obsolete */
grub_uint16_t heap_end_ptr; /* Free memory after setup end
*/
- grub_uint16_t pad1; /* Unused */
+ grub_uint8_t ext_loader_ver; /* Extended loader version */
+ grub_uint8_t ext_loader_type; /* Extended loader type */
grub_uint32_t cmd_line_ptr; /* Points to the kernel command
line */
-
- grub_uint8_t pad2[164]; /* 22c */
+ grub_uint32_t initrd_addr_max;/* Maximum initrd address */
+ grub_uint32_t kernel_alignment; /* Alignment of the kernel */
+ grub_uint8_t relocatable_kernel; /* Is the kernel relocatable */
+ grub_uint8_t pad1[3];
+ grub_uint32_t cmdline_size; /* Size of the kernel command
line */
+ grub_uint32_t hardware_subarch;
+ grub_uint64_t hardware_subarch_data;
+ grub_uint32_t payload_offset;
+ grub_uint32_t payload_length;
+ grub_uint64_t setup_data;
+ grub_uint8_t pad2[120]; /* 258 */
struct grub_e820_mmap e820_map[GRUB_E820_MAX_ENTRY]; /* 2d0 */
} __attribute__ ((packed));
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
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: grub-install revamp
Status of mactel bless in grub2 v2.00 code freeze? - Keshav On 02/02/2012, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 30.01.2012 03:37, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. It was a Robert's idea of having grub-install to install all available (as in: the ones which were make install'ed) ports in a single grub-install w/o having to keep and run one grub-install per port. I've tried to write such a thing. I have met some problems in practice: - I wanted also to integrate mactelbless in the same time. Unfortunately Apple uses the same pointer for both i386 and x86_64 efi. So hfs(+) partitions can hold only either 32-bit or 64-bit EFI binary. We could use FAT Binary to workaround this but not all macs support this. - If one of platform specific installs fail the script doesn't install other platforms. - When modifying nvram on EFI where to point it to? ESP or HFS? This is easy: HFS if it's a mac and ESP otherwise. Or just always ESP. - The same problem for ieee1275. While distinguishing between mac and non-mac is easy (check vendor string), I don't know how to distinguish the ones using PreP partition and the ones using a file on a FAT fs. I would appreciate any input both on these specific problems and the idea in general. Perhaps it's better to abandon it and have something easier like auto-detect firmware and use it as default and specify it manually if you need a different install. The attached patch is just a small illustration to discuss about. It doesn't work This has an advantage of making the disk bootable in various ways including ability to move it from one computer to another. The first problem is the files collision. To resolve this the modification will be to load modules from $prefix/$cpu-$platform/$modname.mod. Also 2 new script constants will be defined: $cpu and $platform. The problem then is that different firmwares require different kind of arrangements in order to be bootable. i386-pc requires 55AA signature, some code in MBR and embedding zone. A dummy msdos active partition is required on some systems. *-efi require files on ESP and some nvram entries i386-qemu, i386-coreboot, i386-qemu_mips and loongsoon-firmware are firmware ports and we don't use grub-install for those but grub-mkstandalone. i386-multiboot just has to be readable by whatever is a coreboot payload. mipsel-loongson has to be on ext2 msdos partition. sparc64 requires SUN partition map and the code in sector 1 Powerpc (Apple) requires a file on HFS and nvram modification PowerPC (IBM) uses PreP partition ARC uses a special entry in the dvh partition table I have no idea what i386-ieee1275 requires but I guess it's a fat partition with special file + nvram modification. So I propose following strategy: grub-install does the following platform-specific installations: - if /boot/efi is on fat, copy grub to /boot/efi/efi/$boot_id/grub[ia32|x64|ia64].efi (replace $boot_id and grub with boot if --removable is specified) and update nvram if no --removable is specified and currently running EFI version matches the installed one. - if /boot/mac is on HFS or HFS+, create there a structure recognized by both PPC and Intel macs and update nvram if architecture matches - If /boot/ext2 is on ext*, put mipsel-loongson and i386-multiboot there. - If /boot/olpc is on fat, install i386-ieee1275 there and update nvram if architecture matches. - For every argument that is an msdos or gpt disk, install i386-pc bootsector. - For every argument that is a sun disk, install sun bootsector. - For every argument that is a dvh disk, install mips-arc. - For every argument that is a prep partition install powerpc-ieee1275 While the copying to partitions is harmless and updating nvram is done only if architecture and platform matches, the disk operations may be harmful. While none of the current 4 configuration usually come in contradictory combinations, it's possible to purposedly create a disk of multiple types and it will confuse this logic. Also if we throw e.g. hppa into the mix which requires just a signature on bytes 0-1 and some info in 0xf4-0xff then we can't know if msdos disk is for BIOS or hppa install. So we need a way to specify them more precisely. PreP and ARC came in only after 1.99 so we can make them accept only the new way whatever it will be. In case of old way we can easily distinguish sparc64-ieee1275 and i386-pc with e.g. uname -i. I propose either of: --device-bios=/dev/xyz --device-sun=/dev/xyz --device-arc=/dev/xyz --device-prep=/dev/xyz Or: bios:/dev/xyz sun:/dev/xyz arc:/dev/xyz prep:/dev/xyz Also it may happen that installation of some port is undesirable. So we need options --install-only=... --exclude=... Any further ideas? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org
Re: [PATCH V3 1/3] Update the Linux boot protocol
On 26.02.2012 22:01, Keshav P R wrote: Status of this patch in grub2 v2.00 code freeze? I have written what have to be fixed first. And one thing: your idea to put into distro a patch which has known serious issues that have to be resolved was a very bad one. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
I am asking about 'this' patch (patch 1/3) alone. Not the other two ones. And the distro package was never updated, it was just a test build with a bzr snapshot and these patches, given to users willing to test the code. - Keshav On 27/02/2012, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 26.02.2012 22:01, Keshav P R wrote: Status of this patch in grub2 v2.00 code freeze? I have written what have to be fixed first. And one thing: your idea to put into distro a patch which has known serious issues that have to be resolved was a very bad one. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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 V3 1/3] Update the Linux boot protocol
Coming to the issue of distro package, has the uefi relocator hang (seen in many asus laptops) been fixed in bzr mainline? On 27/02/2012, Keshav P R the.ridikulus@gmail.com wrote: I am asking about 'this' patch (patch 1/3) alone. Not the other two ones. And the distro package was never updated, it was just a test build with a bzr snapshot and these patches, given to users willing to test the code. - Keshav On 27/02/2012, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 26.02.2012 22:01, Keshav P R wrote: Status of this patch in grub2 v2.00 code freeze? I have written what have to be fixed first. And one thing: your idea to put into distro a patch which has known serious issues that have to be resolved was a very bad one. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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 V3 1/3] Update the Linux boot protocol
On 26.02.2012 22:22, Keshav P R wrote: Coming to the issue of distro package, has the uefi relocator hang (seen in many asus laptops) been fixed in bzr mainline? The reports feature one bug that debug=all caused relocator to hang. I don't know what happens in case when no debug is set and whether it's relocator's (or GRUB's at all for that matter) fault. On 27/02/2012, Keshav P Rthe.ridikulus@gmail.com wrote: I am asking about 'this' patch (patch 1/3) alone. Not the other two ones. And the distro package was never updated, it was just a test build with a bzr snapshot and these patches, given to users willing to test the code. - Keshav On 27/02/2012, Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com wrote: On 26.02.2012 22:01, Keshav P R wrote: Status of this patch in grub2 v2.00 code freeze? I have written what have to be fixed first. And one thing: your idea to put into distro a patch which has known serious issues that have to be resolved was a very bad one. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ 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 -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V3 1/3] Update the Linux boot protocol
On 26.02.2012 22:18, Keshav P R wrote: I am asking about 'this' patch (patch 1/3) alone. 'This' patch by itself has no effect. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Support for different hotkey action than execute
Attached patch introduces a new environment variable hotkey_action. It
can be set to select or execute, whereas the latter is the default. So
the default behaviour doesn't change. With select set instead a menu
entry is just selected and not executed/booted on hotkey press.
This is for example useful for long menus to directly jump to some
initial and afterwards select the desired entry without going through
the whole menu. One still has to explicitly mark the menu entry to jump
to with the hotkey attribute. This patch only allows to change the
action to take on hotkey press.
Not much code and most is inspired from grub_menu_get_timeout. Applies
and works with r3991.
Add support to the menu for changing the action on hotkey press:
execute (default), select
* grub-core/normal/menu.c (DEFAULT_HOTKEY_ACTION): New define.
(run_menu): Handle hotkey_action.
(grub_menu_get_hotkey_action): New function.
* include/grub/menu.h (grub_menu_get_hotkey_action): New prototype.
(grub_hotkey_action_type_t): New enum.
=== modified file 'grub-core/normal/menu.c'
--- grub-core/normal/menu.c 2012-02-18 18:59:01 +
+++ grub-core/normal/menu.c 2012-02-26 22:31:49 +
@@ -37,6 +37,10 @@
entry failing to boot. */
#define DEFAULT_ENTRY_ERROR_DELAY_MS 2500
+/* The default action to choose for hotkeys when nothing is explicitly
+ specified. */
+#define DEFAULT_HOTKEY_ACTION GRUB_HOTKEY_ACTION_TYPE_EXECUTE
+
grub_err_t (*grub_gfxmenu_try_hook) (int entry, grub_menu_t menu,
int nested) = NULL;
@@ -70,6 +74,35 @@
return e;
}
+/* Return the hotkey action. If the variable hotkey_action is not set
+ or invalid, return DEFAULT_HOTKEY_ACTION. */
+grub_hotkey_action_type_t
+grub_menu_get_hotkey_action (void)
+{
+ const char *val;
+
+ val = grub_env_get (hotkey_action);
+
+ if (val)
+ {
+if (grub_strcasecmp (val, execute) == 0)
+ {
+return GRUB_HOTKEY_ACTION_TYPE_EXECUTE;
+ }
+else if (grub_strcasecmp (val, select) == 0)
+ {
+return GRUB_HOTKEY_ACTION_TYPE_SELECT;
+ }
+/* If the value is invalid, unset the variable. */
+else
+ {
+grub_env_unset (hotkey_action);
+ }
+ }
+
+ return DEFAULT_HOTKEY_ACTION;
+}
+
/* Return the current timeout. If the variable timeout is not set or
invalid, return -1. */
int
@@ -496,6 +529,7 @@
grub_uint64_t saved_time;
int default_entry, current_entry;
int timeout;
+ grub_hotkey_action_type_t hotkey_action;
default_entry = get_entry_number (menu, default);
@@ -519,6 +553,7 @@
refresh:
menu_init (current_entry, menu, nested);
+ hotkey_action = grub_menu_get_hotkey_action ();
timeout = grub_menu_get_timeout ();
if (timeout 0)
@@ -653,10 +688,21 @@
i++, entry = entry-next)
if (entry-hotkey == c)
{
- menu_fini ();
- *auto_boot = 0;
- return i;
- }
+ switch (hotkey_action)
+ {
+ case GRUB_HOTKEY_ACTION_TYPE_SELECT:
+ current_entry = i;
+ menu_set_chosen_entry (current_entry);
+ break;
+ case GRUB_HOTKEY_ACTION_TYPE_EXECUTE:
+ menu_fini ();
+ *auto_boot = 0;
+ return i;
+ default:
+ /* Never reach here */
+ break;
+ }
+ }
}
break;
}
=== modified file 'include/grub/menu.h'
--- include/grub/menu.h 2011-01-10 22:27:58 +
+++ include/grub/menu.h 2012-02-26 22:31:49 +
@@ -91,11 +91,20 @@
}
*grub_menu_execute_callback_t;
+/* Possible actions to perform when a hotkey is pressed */
+typedef enum
+{
+ GRUB_HOTKEY_ACTION_TYPE_EXECUTE,
+ GRUB_HOTKEY_ACTION_TYPE_SELECT
+} grub_hotkey_action_type_t;
+
+
grub_menu_entry_t grub_menu_get_entry (grub_menu_t menu, int no);
int grub_menu_get_timeout (void);
void grub_menu_set_timeout (int timeout);
void grub_menu_entry_run (grub_menu_entry_t entry);
int grub_menu_get_default_entry_index (grub_menu_t menu);
+grub_hotkey_action_type_t grub_menu_get_hotkey_action (void);
void grub_menu_init (void);
void grub_menu_fini (void);
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 and Xen menu entries
On 03.04.2011 13:36, Alexey Shvetsov wrote: Hi all! I'm using xen on gentoo with grub2 and seems there is and issue with default xen detection mechanism because it also adds menu entries for all xen symlinks in boot and for xen-syms [see grub.cfg.unpatched] that shouldn't happen. Contents of my boot directory is Just for record: this patch wasn't accepted because it's not POSIX-compatible. Please fix this. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub + FreeBSD's loader(8) + ZFS root
On 07.04.2010 22:21, Navdeep Parhar wrote:
2010/4/7 Vladimir 'φ-coder/phcoder' Serbinenkophco...@gmail.com:
Navdeep Parhar wrote:
Hello grub-devel,
Right now it's not possible to boot using FreeBSD's loader(8) from a ZFS
root filesystem. Grub doesn't indicate to the loader that there is a
ZFS root involved and consequently the loader fails to find the kernel.
The attached patch fixes this. It does not affect those that boot the
kernel directly. This is only for users that want to boot using
FreeBSD's loader.
Why would you want to? IMHO it is much simpler to boot indirectly using
the loader because in that case grub does not have to deal with
device.hints, kernel modules, kFreeBSD.xxx style variables,
/boot/zfs/zpool.cache, etc. As a FreeBSD user, I'm used to putting this
information in the normal config files (/boot/loader.conf, device.hints,
etc.) and not in a grub.cfg file. Grub only needs to know where the loader
is, nothing else:
menuentry FreeBSD 8 {
search -s -l fbsd8
kfreebsd -D /@/boot/zfsloader
}
(fbsd8 is the name of the ZFS root pool)
Eternal chainloading isn't the way to go. It limits grub usefullness and
scope and is to be used only when no alternative exists. In this case
the right direction would be to make a small C module to parse boot(8)
config or a shell script for 30_osprober.in to do the same job
Sure, chainloading doesn't have to be the preferred way of booting an
OS, but it shouldn't fail without a good reason either. Right now
FreeBSD can be chainloaded from a UFS root but not from ZFS root.
That's all that I'm trying to fix here. This patch doesn't imply that
chainloading is *the* way to load FreeBSD - just that it is a usable
alternate to direct loading, even from a ZFS root.
I've added this patch but only because since we support aout
/boot/loader it makes little sense not to support zfsloader but it's not
a recommended way to boot in either case.
Regards,
Navdeep
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub-install: add search-file option for load.cfg
I had to rewrite it because of several problems involving lack of
fallback if UUID is unavailable, lack of documentation and so on.
Committed my version
On 14.01.2012 03:59, Jon Ringle wrote:
Signed-off-by: Jon Ringlej...@ringle.org
---
util/grub-install.in | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/util/grub-install.in b/util/grub-install.in
index ff8bea8..20a3b7d 100644
--- a/util/grub-install.in
+++ b/util/grub-install.in
@@ -245,6 +245,9 @@ do
--debug-image=*)
debug_image=`echo $option | sed 's/--debug-image=//'` ;;
+--search-file)
+ set_search_file=yes ;;
+
-f | --force)
setup_force=--force ;;
@@ -534,12 +537,25 @@ if [ x${devabstraction_module} = x ] ; then
echo UUID needed with cross-disk installs, but the filesystem containing
${grubdir} does not support UUIDs. 12
fi
- exit 1
+ set_search_file=yes
+fi
+
+if [ x${set_search_file} = xyes ]; then
+ search_file=$(mktemp ${grubdir}/X.uuid)
+ search_file=$(${grub_mkrelpath} ${search_file})
+fi
+
+if [ x${search_file} = x ] ; then
+ echo search.fs_uuid ${uuid} root ${grubdir}/load.cfg
+ echo 'set prefix=($root)'${relative_grubdir}
${grubdir}/load.cfg
+ config_opt=-c ${grubdir}/load.cfg
+ modules=$modules search_fs_uuid
+else
+ echo search.file ${search_file} root ${grubdir}/load.cfg
+ echo 'set prefix=($root)'${relative_grubdir}
${grubdir}/load.cfg
+ config_opt=-c ${grubdir}/load.cfg
+ modules=$modules search_fs_file
fi
-echo search.fs_uuid ${uuid} root ${grubdir}/load.cfg
- echo 'set prefix=($root)'${relative_grubdir} ${grubdir}/load.cfg
- config_opt=-c ${grubdir}/load.cfg
-modules=$modules search_fs_uuid
elif [ x$platform = xefi ] || [ x$platform = xpc ]; then
# we need to hardcode the partition number in the core image's prefix.
if [ x$grub_partition = x ]; then
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub RAID heuristics (how can we avoid superfluous RAID member (2 found))
On Sat, 25 Feb 2012 16:49:00 -0500, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On Thu, 23 Feb 2012 06:43:23 +0100, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: [dkg wrote:] Select the smallest known block device that can completely enclose the RAID member. The larger block device(s) should not be considered to be exporting that RAID. I just built the latest (r4008) bzr head, which i believe includes the proposed changes, and installed it on a machine with two disks in RAID1: 0 root@trash:/home/dkg/src/grub/grub# cat /proc/partitions major minor #blocks name 80 19531250 sda 816266913 sda1 82 13256178 sda2 8 16 13260240 sdb 8 17 13258192 sdb1 90 13256064 md0 25303145728 dm-0 0 root@trash:/home/dkg/src/grub/grub# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[0] sda2[1] 13256064 blocks [2/2] [UU] unused devices: none 0 root@trash:/home/dkg/src/grub/grub# pvs PV VGFmt Attr PSize PFree /dev/md0 vg_trash0 lvm2 a-- 12.64g 9.64g 0 root@trash:/home/dkg/src/grub/grub# vgs VG#PV #LV #SN Attr VSize VFree vg_trash0 1 1 0 wz--n- 12.64g 9.64g 0 root@trash:/home/dkg/src/grub/grub# lvs LV VGAttr LSize Origin Snap% Move Log Copy% Convert root vg_trash0 -wi-ao 3.00g 0 root@trash:/home/dkg/src/grub/grub# it boots correctly on this setup, yay! booting to the grub command line, however, i do see some weirdness: grub ls (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (lvm/vg_trash0-root) grub insmod mdraid09 grub ls (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (md/md0) (md/md0,msdos2) (md/md0,msdos1) (lvm/vg_trash0-root) grub rmmod mdraid09 grub ls (md/md0) (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (md/md0) grub insmod mdraid09 grub ls (md/md0) (lvm/vg_trash0-root) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) (fd0) (md/md0) --dkg pgp7TMzghOykF.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Freeze on 27 February
On Thu, 2012-02-23 at 07:34 +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: zfs-poolname-spaces.patch ... @@ -420,6 +419,9 @@ if (sscanf (sep, %s %s, entry.fstype, entry.device) != 2) continue; + unescape (entry.fstype); + unescape (entry.device); + You need to increase the size of storage for these fields. On second look... why? The unescape() function modifies the string in place, and it changes multi-character escape sequences into single unescaped characters. I don't understand how this would change the size requirement. -- Richard signature.asc Description: This is a digitally signed message part ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Freeze on 27 February
On Thu, 2012-02-23 at 07:34 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
Index: grub/util/getroot.c
===
--- grub.orig/util/getroot.c2012-02-03 05:22:36.227364000 -0600
+++ grub/util/getroot.c 2012-02-03 05:22:41.255135000 -0600
@@ -301,7 +301,10 @@
devices = xrealloc (devices, sizeof (devices[0])
* devices_allocated);
}
- devices[ndevices++] = xasprintf (/dev/%s, name);
+ if (name[0] == '/')
+ devices[ndevices++] = xstrdup (name);
+ else
+ devices[ndevices++] = xasprintf (/dev/%s, name);
}
break;
}
This one is ok other than the missing ChangeLog.
Updated zfs-devices.patch attached
@@ -478,7 +558,8 @@
if (!*entries[i].device)
continue;
- if (grub_strcmp (entries[i].fstype, fuse.zfs) == 0)
+ if (grub_strcmp (entries[i].fstype, fuse.zfs) == 0 ||
+ grub_strcmp (entries[i].fstype, zfs) == 0)
{
char *slash;
slash = strchr (entries[i].device, '/');
This should go as a separate patch
Attached as zfs-fstype.patch.
--
Richard
Index: grub/util/getroot.c
===
--- grub.orig/util/getroot.c 2012-02-27 01:09:58.142614829 -0600
+++ grub/util/getroot.c 2012-02-27 01:10:07.237344000 -0600
@@ -302,7 +302,10 @@ find_root_devices_from_poolname (char *p
devices = xrealloc (devices, sizeof (devices[0])
* devices_allocated);
}
- devices[ndevices++] = xasprintf (/dev/%s, name);
+ if (name[0] == '/')
+ devices[ndevices++] = xstrdup (name);
+ else
+ devices[ndevices++] = xasprintf (/dev/%s, name);
}
break;
}
Index: grub/ChangeLog.zfs-devices
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ grub/ChangeLog.zfs-devices 2012-02-27 01:20:10.839892000 -0600
@@ -0,0 +1,5 @@
+2012-02-27 Richard Laager rlaa...@wiktel.com
+
+ * util/getroot.c (find_root_devices_from_poolname): Handle ZFS vdevs
+ with full paths.
+
Support native ZFS on Linux.
Index: grub/util/getroot.c
===
--- grub.orig/util/getroot.c 2012-02-27 01:10:07.237344000 -0600
+++ grub/util/getroot.c 2012-02-27 01:24:13.693145000 -0600
@@ -479,7 +479,8 @@ grub_find_root_devices_from_mountinfo (c
if (!*entries[i].device)
continue;
- if (grub_strcmp (entries[i].fstype, fuse.zfs) == 0)
+ if (grub_strcmp (entries[i].fstype, fuse.zfs) == 0 ||
+ grub_strcmp (entries[i].fstype, zfs) == 0)
{
char *slash;
slash = strchr (entries[i].device, '/');
Index: grub/ChangeLog.zfs-fstype
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ grub/ChangeLog.zfs-fstype 2012-02-27 01:26:20.548958000 -0600
@@ -0,0 +1,5 @@
+2012-02-27 Richard Laager rlaa...@wiktel.com
+
+ * util/getroot.c (grub_find_root_devices_from_mountinfo): Support
+ the native ZFS on Linux fstype (zfs).
+
signature.asc
Description: This is a digitally signed message part
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
