[PATCH requesting feedback] resuce: allow disabling of the grub resuce shell
From: Andreas Rammhold
Kindly requesting your feedback on the below diff.
In some setups it might be desirable to disable access to the grub
rescue shell. One of those environments is when your all your
filesystems - besides a small EFI partition - are encrypted and you are
using secure boot to restrict the payloads that UEFI accepts.
The current implementation adds a new variable to the embedded
configuration sections. If the variable is present and starts with a
'y'-character the option is considered to be active. Upon entering the
rescue shell it will just spin in circles (while(1);) if the said option
is active. If the option is not set or set to a value that does not
start with a 'y' the old behaviour is unchanged.
I hacked this together very quickly and do not consider it fit for
merging yet. I would at least want a way to tell grub-install to toggle
the new environment variable. And it probably requires some kind of
documentation.
---
grub-core/kern/rescue_reader.c | 34 +++---
util/grub-install.c| 1 +
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/grub-core/kern/rescue_reader.c b/grub-core/kern/rescue_reader.c
index dcd7d4439..03a4e2852 100644
--- a/grub-core/kern/rescue_reader.c
+++ b/grub-core/kern/rescue_reader.c
@@ -78,21 +78,33 @@ grub_rescue_read_line (char **line, int cont,
void __attribute__ ((noreturn))
grub_rescue_run (void)
{
- grub_printf ("Entering rescue mode...\n");
+ const char *disable_rescue_mode;
- while (1)
+ disable_rescue_mode = grub_env_get ("disable_rescue_mode");
+
+ if (!disable_rescue_mode || disable_rescue_mode[0] != 'y')
{
- char *line;
+ grub_printf ("Entering rescue mode...\n");
+
+ while (1)
+{
+ char *line;
- /* Print an error, if any. */
- grub_print_error ();
- grub_errno = GRUB_ERR_NONE;
+ /* Print an error, if any. */
+ grub_print_error ();
+ grub_errno = GRUB_ERR_NONE;
- grub_rescue_read_line (&line, 0, NULL);
- if (! line || line[0] == '\0')
- continue;
+ grub_rescue_read_line (&line, 0, NULL);
+ if (! line || line[0] == '\0')
+continue;
- grub_rescue_parse_line (line, grub_rescue_read_line, NULL);
- grub_free (line);
+ grub_rescue_parse_line (line, grub_rescue_read_line, NULL);
+ grub_free (line);
+}
+}
+ else
+{
+ grub_printf ("Not entering rescue mode.\n");
+ while (1);
}
}
diff --git a/util/grub-install.c b/util/grub-install.c
index 4a0a66168..16eda74c3 100644
--- a/util/grub-install.c
+++ b/util/grub-install.c
@@ -530,6 +530,7 @@ probe_cryptodisk_uuid (grub_disk_t disk)
load_cfg_f = grub_util_fopen (load_cfg, "wb");
have_load_cfg = 1;
+ fprintf (load_cfg_f, "set disable_rescue_mode=yes\n");
fprintf (load_cfg_f, "cryptomount -u %s\n",
uuid);
}
--
2.21.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH requesting feedback] resuce: allow disabling of the grub resuce shell
On 13:30 10.05.19, Daniel Kiper wrote: > I am OK with the idea but the patch requires polishing and maybe splitting > into two or more. And certainly it is not a release material. Thanks for the feedback. Do you have some specific points that you would like to see addressed? I certainly want the mentioned command line switches to opt-in to the feature and write the documentation pieces. Andi ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Warnings when building svn2137
BandiPat schrieb: Pavel Roskin wrote: Quoting BandiPat : Pavel Roskin wrote: The manuals are generated from the output of the corresponding commands. I believe your version of help2man is not working. I'm going to fix the makefile to prevent generation of empty manuals in that case. --- Thanks Pavel. Turns out I didn't know about help2man, so did not have it installed. I didn't realize we would create empty manual pages in that case! Still, my patch will fix it. - Yep, creates very nice empty manuals! ;-) Anyway, if someone hasn't already, it might be a good idea to mention the help2man in your Wiki and/or the Readme within the source. Maybe something in the Wiki about the programs needed to compile Grub2 the most efficiently? It works a treat though and now Zenwalk mirrors have it available! Thanks again. Oh, has anyone experienced any problems with grub-mkdevicemap when installing Grub2 or updating? I had one user complain about it segfaulting on his machine, but I've not seen any problems. This is with svn2137. I'm experiencing also problems using it, but it's not segfaulting. Using a svn2130 build grub-mkdevicemap --no-floppy create a device.map with proper content like this: (hd0) /dev/sda But a svn2137 build (exactly the same BandiPat uses) creates this content, which might not be wrong, but at least the most important part my HDD is missing: (fd0) (null) Probably this problem was introduced by revision 2133 and obviously wasn't fixed in rev 2134 - 2137 and in 2138 - 2140 I can see nothing which might fix this. It would be great if somebody could have a look what could cause this problem. Maybe davem as the author of that revision. If you need any additional information give me a yell and I'll try my best to provide it. Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Faulty grub-mkdevicemap file
Thanks a lot, this fixed it.
David Miller schrieb:
From: BandiPat
Date: Sat, 25 Apr 2009 15:29:11 -0400
Here is the error when running grub-install:
I just checked in the following patch which will fix this
bug.
2009-04-26 David S. Miller
* util/grub-mkdevicemap.c (make_device_map): Add missing
NESTED_FUNC_ATTR to process_device().
diff --git a/util/grub-mkdevicemap.c b/util/grub-mkdevicemap.c
index 4f544f8..ac8a390 100644
--- a/util/grub-mkdevicemap.c
+++ b/util/grub-mkdevicemap.c
@@ -42,9 +42,9 @@ make_device_map (const char *device_map, int floppy_disks)
int num_fd = 0;
FILE *fp;
- auto int process_device (const char *name, int is_floppy);
+ auto int NESTED_FUNC_ATTR process_device (const char *name, int is_floppy);
- int process_device (const char *name, int is_floppy)
+ int NESTED_FUNC_ATTR process_device (const char *name, int is_floppy)
{
grub_util_emit_devicemap_entry (fp, (char *) name,
is_floppy, &num_fd, &num_hd);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] prevent duplicated entries due to symlinks
Pavel Roskin schrieb:
On Fri, 2009-05-01 at 22:51 +0200, Andreas Born wrote:
If there's both a symlink and a kernel at which the symlink is pointing
in the list of detected kernels of 10_linux, two entries are created for
actually the same kernel. This patch checks for this condition and only
uses the symlink (usually the wanted behaviour), in case the target of
the symlink doesn't exist, it uses neither.
Furthermore there may be kernel images named e.g. /boot/vmlinuz, so to
detect those the patch doesn't require a hyphen in the kernel name.
In this case the sed used to determine the kernel version, won't return
as expected an empty string. Therefore I replaced it by another one with
the wanted behaviour.
If the kernel version can be empty we don't want to have a "GNU/Linux,
linux " menuentry. Accordingly this patch adds a check for empty kernel
version, so that only "GNU/Linux" will be displayed.
The result will be that we would have an entry without version instead
of an entry with a version. That's hardly an improvement. Can you give
an example where it would be useful?
You have a symlink named /boot/vmlinuz which points at the current
kernel version. Now you could of course find out which kernel version
it's pointing at but that version could change anytime. /boot/vmlinu[zx]
and /vmlinu[zx] (there should only exist one of them) are the only cases
I can think of which have no version in their name. So you always know
that the version-free entry always boots the kernel pointed at by
/boot/vmlinuz, which is always the current kernel if your distro
maintains the symlink. I see no regression there.
This is for example my Zenwalk boot entry:
'menuentry "Zenwalk GNU/Linux" {
set root=(hd0,3)
search --fs-uuid --set 408e3e53-d766-4592-bb12-31233bd415c0
linux16/boot/vmlinuz root=/dev/sda3 ro splash=silent
resume=/dev/sda7 vga=794
initrd16/boot/initrd.splash
}'
That's the symlink: /boot/vmlinuz -> vmlinuz-2.6.29.2
Finally there's quite a bunch of other names for initrds. This patch
adds support for initrd.gz and initrd.splash. Both initrd.img and
initrd.gz become or were yet supported with two different version
positions and without version at all. For initrd.splash this isn't
needed because it's not kernel version dependent.
Please specify where those names are used. Can you give the
distribution name and version where such names are used?
Zenwalk, Slackware for example. I think more Slackware derivates are
using it too.
What is initrd.splash? Why does it need to be handled like initrd and
why is it always version independent? Again, where is it used?
initrd.splash is used by Zenwalk (others too) it contains only the data
of one or multiple bootsplashes as returned by the "splash" command.
It's used by bootsplash and doesn't contain any files, modules, etc.
The version independence is quite self-explaining now, I think. Unless
bootsplash support was removed it works for any kernel version. And even
if bootsplash support is removed it does no harm to load it.
Is it understandable now?
Andreas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] prevent duplicated entries due to symlinks
ping?
any problems still?
Andreas
Andreas Born schrieb:
Pavel Roskin schrieb:
Suppose I have Linux 2.6.29 and 2.6.28. Your script makes entries for
"Linux default" and "Linux 2.6.28". Then I install Linux 2.6.30 and
don't run grub-mkconfig. Then I can boot Linux 2.6.30 and 2.6.28 form
the menu, but not 2.6.29.
Even if I run grub-mkconfig, there is still something I lose. By
selecting "Linux default" I still don't know it it's Linux 2.6.30 or
something else.
For me, the convenience of not having to rerun grub-mkconfig doesn't
outweigh the convenience of knowing what I'm loading.
I know, it's have to argue about preferences, but if you want you
changes to be accepted, you need to present a good case.
It's also that kind of discussion which eventually separates the wheat
from the chaff. Thus I welcome it.
I would consider placing the kernel pointed to by the vmlinuz link to
the first position of the Linux kernels. Another approach would be to
have an entry for the link without suppressing any versioned entries.
Ok, I understand and if it is a preference why don't make it a
preference. :)
You can find attached a new version of the patch, which per default
will read the symlink and create an entry for the target, not the
symlink. You can change this behaviour with
"GRUB_USE_LINUX_SYMLINK=yes". If you define this environment variable
with that value, it will use the behaviour I implemented before. This
means it uses the symlink and ignores the kernel the symlink is
currently pointing at.
I think this is the best solution, because it prevents duplicated
entries (only one entry for symlink or symlink target) and it gives
the user the choice which behaviour he wants (rerun of grub-mkconfig
needed or not needed).
Is that solution all right?
Please specify where those names are used. Can you give the
distribution name and version where such names are used?
Zenwalk, Slackware for example. I think more Slackware derivates are
using it too.
Let's add support for more versioned names first. That should be rather
non-controversial.
I see no more versioned names which could be added for the existing
extension(s). There is initrd-. and
initrd.-. Whereas can either be $version or
$alt_version and can be "img" or "gz" ("gz" is new) and at the
very end as a last resort initrd.img initrd.gz and initrd.splash are
tried in that order (that's also new). Roughly speaking only new
fallback options.
Do you see a problem there or do you have a concrete versioned name to
add?
Andreas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add apple_set_os command
Am 2014-01-07 14:38, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 30.12.2013 17:04, Andreas Heider wrote:
+static const grub_efi_char8_t apple_os_version[] = "Mac OS X 10.9";
+static const grub_efi_char8_t apple_os_vendor[] = "Apple Inc.";
+
Can those be optionally supplied on command line?
E.g.
apple_set_os [[VENDOR] VERSION]
On the other hand we should probably start collecting whitelist of macs
who need this and do it on them automatically. Idk if there is EFI
variable to identify mac model from EFI but it's possible from SMBIOS.
I'll try to find the time to implement the command line arguments
tonight, and I am pretty sure that there is a way to get the model from
EFI. I just hope that Apple implemented this correctly.
One thing I'm still wondering about is how this could integrate better
with EFISTUB. Do you know how for example the broadcom fix is applied in
that scenario? Is the same fix just duplicated in the Linux kernel?
Because if we implement a whitelist in grub and then suddenly Linux boot
properly with grub but not directly with EFISTUB things become quite
ugly.
+static grub_err_t
+grub_cmd_apple_set_os (grub_command_t cmd __attribute__ ((unused)),
+ int argc __attribute__ ((unused)),
+ char **args __attribute__ ((unused)))
+{
+ grub_efi_guid_t apple_set_os_guid =
GRUB_EFI_APPLE_SET_OS_PROTOCOL_GUID;
___
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] Add apple_set_os command
Am 2014-01-03 19:38, schrieb SevenBits: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2014 01:46 AM, Vladimir '?-coder/phcoder' Serbinenko wrote: On 31.12.2013 00:11, SevenBits wrote: On Monday, December 30, 2013, Andreas Heider wrote: The EFI on current macbooks configures hardware differently depending on wether it is booting Mac OS X or a different os, for example disabling the internal GPU completely on some models. Mac OS X identifies itself using a custom EFI protocol. This adds a command that fakes the os identification, making all hardware accessible. Just a question: I do a lot of booting Linux on MacBooks, and I frequently suffer from this issue. How do we know that this code actually works? Run on a mac with this code and without and compare results. The ship of "works by sane design" has long since sailed away. For most manufacturers it's somewhere in Moon orbit but for apple it has long since left solar system. So, Andreas, I tried your patch, and... no dice. The Mac behaves exactly as before. I'm afraid it didn't appear to do anything for me. Hi, thanks for testing! I suspect that your MacBook Pro is simply too old. I don't know exactly when this protocol was introduced, I found references to it on Hackintosh-Forums from a while ago and in the Mac OS X internals book which is also a bit older. What effect exactly were you looking for? Your MBP doesn't have a second GPU to disable. Also, AFAIK the older models disable less hardware when you boot via EFI than the newer ones, since Bootcamp with EFI wasn't supported. Furthermore, your patch didn't print any output. There wasn't any error message returned (i.e your "Could not locate the apple set os protocol." message on line 52-53). When I invoked your command from the GRUB normal prompt, it DID print the message however. Perhaps it doesn't fail if called from within a grub.cfg, or maybe it simply doesn't print. If it prints something on the promt I'd say it's working as intended, although I'm pretty sure that I see output from it when I boot a grub.cfg entry. The Mac that I tested on was a MacBook Pro from early 2008. Clearly, this function isn't present on all models. I can try it on others and seeing if it works on them, however. If you have the time, please do. I'd be interested in what exactly changes. Also, why the if statements on lines 59 and 65, which indicate whether the OS version and/or vendor was set. What is the point of them? Why not just call the functions directly? It's just some output so you know that the command did something. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSxwOMAAoJEFbRvtGxmFPELWoH+QGu7aLuDam0vY+xW8h4TdFw ckY51K8vgEGlpUNvK2fwQnnAt57W3jH14HBIRY1IaC+c9XA3mooqp748xh0jfoV/ D95lZJuYu3XP4iFYtCehcCVOiz+x4DNXMnT6WA6hd5FjPT9xqbBqf/9RxSpN9O+i ZGbSe/ZQkOvTyLXJ11L3SeTlNi9jqA03mLaMrMi7Ehb7AU3hBkiSMpiiIcUjnP3o ZskQrSkguqt9Kt+FlHheTJkpAitqqJR/GpHkegg3bNGLrflacVGITMFFw0EsJP4R h0fsEocfYnvSVPrw07SJVFvt2TzPGB69p5QXy11cU1ZBYUhILcG7rDTAmVctZig= =wKye -END PGP SIGNATURE- ___ 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: Recent removal of a.out and COFF support for sparc
On Aug 08 2018, John Paul Adrian Glaubitz wrote: > What about elfutils for these purposes? I have been told by gcc people > that elfutils was supposed to replace binutils in this regard. BFD is also used by GAS and GPROF. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 09/10] RISC-V: Add to build system
On Nov 14 2018, Bin Meng wrote: > - use riscv32-* toolchain to build riscv64 target (-m64 required) > - use riscv64-* toolchain to build riscv32 target (-m32 required) riscv does not use -m64/-m32. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 10/10] fdt: Add device tree file type
On Nov 14 2018, Alexander Graf wrote: > diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c > index a4c6e8036..d8ebe648e 100644 > --- a/grub-core/loader/efi/fdt.c > +++ b/grub-core/loader/efi/fdt.c > @@ -123,7 +123,7 @@ grub_cmd_devicetree (grub_command_t cmd __attribute__ > ((unused)), >return GRUB_ERR_NONE; > } > > - dtb = grub_file_open (argv[0]); > + dtb = grub_file_open (argv[0], GRUB_FILE_TYPE_DEVICE_TREE); >if (!dtb) > goto out; > Looks like this has been obsoleted by commit dfb1742aab? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 07/10] RISC-V: Add awareness for RISC-V reloations
On Nov 21 2018, Daniel Kiper wrote:
>> +case R_RISCV_BRANCH:
>> + {
>> +grub_uint32_t *abs_place = place;
>> +grub_ssize_t off = sym_addr - (grub_addr_t) place;
>> +grub_uint32_t imm12 = (off & 0x1000) << (31 - 12);
>> +grub_uint32_t imm11 = (off & 0x800) >> (11 - 7);
>> +grub_uint32_t imm10_5 = (off & 0x7e0) << (30 - 10);
>> +grub_uint32_t imm4_1 = (off & 0x1e) << (11 - 4);
>> +*abs_place = (*abs_place & 0x1fff07f)
>> + | imm12 | imm11 | imm10_5 | imm4_1;
>
> Could not we use some constants instead of numbers here?
These are just where the insn encoding puts the bits.
> If this does not make sense than please name the source of this numbers.
https://github.com/riscv/riscv-isa-manual/blob/master/release/riscv-spec-v2.2.pdf
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 09/10] RISC-V: Add to build system
On Nov 21 2018, Daniel Kiper wrote: > s/__riscv/__riscv__/? and s/__riscv_xlen/__riscv_xlen__/? The latter aren't defined. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 09/10] RISC-V: Add to build system
On Nov 21 2018, Daniel Kiper wrote: > On Wed, Nov 21, 2018 at 05:26:25PM +0100, Andreas Schwab wrote: >> On Nov 21 2018, Daniel Kiper wrote: >> >> > s/__riscv/__riscv__/? and s/__riscv_xlen/__riscv_xlen__/? >> >> The latter aren't defined. > > Both __riscv__ and __riscv_xlen__ are not defined? Yes. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v6 00/11] Add RISC-V support
On Feb 12 2019, Alexander Graf wrote: > As part of the plan for total world domination, we would like to make sure > that booting on RISC-V is in a sane state before anyone goes and does quick > hacks "just because". > > For that reason, U-Boot supports UEFI booting on RISC-V for a while now. > This patch set is the second part of the puzzle, with grub learning how to > deal with a UEFI enabled RISC-V target. > > The third bit (still missing) is to actually make a working Linux UEFI port. > But that will come, I'm sure :). > > Looking forward to review feedback and testing, Successfully tested on the HiFive Unleashed. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] riscv: fix computation of pc-relative relocation offset
The offset calculation was missing the relocation addend.
Signed-off-by: Andreas Schwab
---
util/grub-mkimagexx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
index bc087c2b5..d16ec63a1 100644
--- a/util/grub-mkimagexx.c
+++ b/util/grub-mkimagexx.c
@@ -1232,8 +1232,7 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct
section_metadata *smd,
grub_uint32_t *t32 = (grub_uint32_t *) target;
grub_uint16_t *t16 = (grub_uint16_t *) target;
grub_uint8_t *t8 = (grub_uint8_t *) target;
-grub_int64_t off = (long)sym_addr - target_section_addr -
offset
- - image_target->vaddr_offset;
+grub_int64_t off;
/*
* Instructions and instruction encoding are documented in the
RISC-V
@@ -1243,6 +1242,7 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct
section_metadata *smd,
*/
sym_addr += addend;
+off = sym_addr - target_section_addr - offset -
image_target->vaddr_offset;
switch (ELF_R_TYPE (info))
{
--
2.22.0
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] grub-install: Define default platform for RISC-V
Signed-off-by: Andreas Schwab --- util/grub-install.c | 8 1 file changed, 8 insertions(+) diff --git a/util/grub-install.c b/util/grub-install.c index 8a55ad4b8..8970b73aa 100644 --- a/util/grub-install.c +++ b/util/grub-install.c @@ -324,6 +324,14 @@ get_default_platform (void) return "arm64-efi"; #elif defined (__amd64__) || defined (__x86_64__) || defined (__i386__) return grub_install_get_default_x86_platform (); +#elif defined (__riscv) +#if __riscv_xlen == 32 + return "riscv32-efi"; +#elif __riscv_xlen == 64 + return "riscv64-efi"; +#else + return NULL; +#endif #else return NULL; #endif -- 2.22.1 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] riscv64-emu: add __clzdi2 symbol
This is needed for the zstd module. Signed-off-by: Andreas Schwab --- configure.ac | 2 +- include/grub/compiler-rt-emu.h | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index e07ba4b56..7d74eba66 100644 --- a/configure.ac +++ b/configure.ac @@ -1370,7 +1370,7 @@ fi # Check for libgcc symbols if test x"$platform" = xemu; then -AC_CHECK_FUNCS(__udivsi3 __umodsi3 __divsi3 __modsi3 __divdi3 __moddi3 __udivdi3 __umoddi3 __ctzdi2 __ctzsi2 __aeabi_uidiv __aeabi_uidivmod __aeabi_idiv __aeabi_idivmod __aeabi_ulcmp __muldi3 __aeabi_lmul __aeabi_memcpy __aeabi_memcpy4 __aeabi_memcpy8 __aeabi_memclr __aeabi_memclr4 __aeabi_memclr8 __aeabi_memset __aeabi_lasr __aeabi_llsl __aeabi_llsr _restgpr_14_x __ucmpdi2 __ashldi3 __ashrdi3 __lshrdi3 __bswapsi2 __bswapdi2 __bzero __register_frame_info __deregister_frame_info ___chkstk_ms __chkstk_ms) +AC_CHECK_FUNCS(__udivsi3 __umodsi3 __divsi3 __modsi3 __divdi3 __moddi3 __udivdi3 __umoddi3 __ctzdi2 __ctzsi2 __clzdi2 __aeabi_uidiv __aeabi_uidivmod __aeabi_idiv __aeabi_idivmod __aeabi_ulcmp __muldi3 __aeabi_lmul __aeabi_memcpy __aeabi_memcpy4 __aeabi_memcpy8 __aeabi_memclr __aeabi_memclr4 __aeabi_memclr8 __aeabi_memset __aeabi_lasr __aeabi_llsl __aeabi_llsr _restgpr_14_x __ucmpdi2 __ashldi3 __ashrdi3 __lshrdi3 __bswapsi2 __bswapdi2 __bzero __register_frame_info __deregister_frame_info ___chkstk_ms __chkstk_ms) fi if test "x$TARGET_APPLE_LINKER" = x1 ; then diff --git a/include/grub/compiler-rt-emu.h b/include/grub/compiler-rt-emu.h index b21425d9e..661f9876f 100644 --- a/include/grub/compiler-rt-emu.h +++ b/include/grub/compiler-rt-emu.h @@ -74,6 +74,11 @@ unsigned EXPORT_FUNC (__ctzsi2) (grub_uint32_t x); #endif +#ifdef HAVE___CLZDI2 +unsigned +EXPORT_FUNC (__clzdi2) (grub_uint64_t x); +#endif + #ifdef HAVE___AEABI_UIDIV grub_uint32_t EXPORT_FUNC (__aeabi_uidiv) (grub_uint32_t a, grub_uint32_t b); -- 2.23.0 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] riscv64-emu: add __clzdi2 symbol
This is needed for the zstd module. Signed-off-by: Andreas Schwab --- configure.ac | 2 +- include/grub/compiler-rt-emu.h | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index e07ba4b56..7d74eba66 100644 --- a/configure.ac +++ b/configure.ac @@ -1370,7 +1370,7 @@ fi # Check for libgcc symbols if test x"$platform" = xemu; then -AC_CHECK_FUNCS(__udivsi3 __umodsi3 __divsi3 __modsi3 __divdi3 __moddi3 __udivdi3 __umoddi3 __ctzdi2 __ctzsi2 __aeabi_uidiv __aeabi_uidivmod __aeabi_idiv __aeabi_idivmod __aeabi_ulcmp __muldi3 __aeabi_lmul __aeabi_memcpy __aeabi_memcpy4 __aeabi_memcpy8 __aeabi_memclr __aeabi_memclr4 __aeabi_memclr8 __aeabi_memset __aeabi_lasr __aeabi_llsl __aeabi_llsr _restgpr_14_x __ucmpdi2 __ashldi3 __ashrdi3 __lshrdi3 __bswapsi2 __bswapdi2 __bzero __register_frame_info __deregister_frame_info ___chkstk_ms __chkstk_ms) +AC_CHECK_FUNCS(__udivsi3 __umodsi3 __divsi3 __modsi3 __divdi3 __moddi3 __udivdi3 __umoddi3 __ctzdi2 __ctzsi2 __clzdi2 __aeabi_uidiv __aeabi_uidivmod __aeabi_idiv __aeabi_idivmod __aeabi_ulcmp __muldi3 __aeabi_lmul __aeabi_memcpy __aeabi_memcpy4 __aeabi_memcpy8 __aeabi_memclr __aeabi_memclr4 __aeabi_memclr8 __aeabi_memset __aeabi_lasr __aeabi_llsl __aeabi_llsr _restgpr_14_x __ucmpdi2 __ashldi3 __ashrdi3 __lshrdi3 __bswapsi2 __bswapdi2 __bzero __register_frame_info __deregister_frame_info ___chkstk_ms __chkstk_ms) fi if test "x$TARGET_APPLE_LINKER" = x1 ; then diff --git a/include/grub/compiler-rt-emu.h b/include/grub/compiler-rt-emu.h index b21425d9e..fde620ac1 100644 --- a/include/grub/compiler-rt-emu.h +++ b/include/grub/compiler-rt-emu.h @@ -74,6 +74,11 @@ unsigned EXPORT_FUNC (__ctzsi2) (grub_uint32_t x); #endif +#ifdef HAVE___CLZDI2 +int +EXPORT_FUNC (__clzdi2) (grub_uint64_t x); +#endif + #ifdef HAVE___AEABI_UIDIV grub_uint32_t EXPORT_FUNC (__aeabi_uidiv) (grub_uint32_t a, grub_uint32_t b); -- 2.23.0 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] riscv64-emu: add __clzdi2 symbol
On Sep 18 2019, Daniel Kiper wrote: > Hmmm... Is __clzdi2() declaration correct? It doesn't really matter, since nobody is using the prototype. It's only used for generating the symbol list. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] RISC-V: Restore the typcast to 64bit type
On Mär 28 2021, Khem Raj wrote: > this makes the type promotions clear and explicit > It was already typecasted to long but was accidentally dropped in [1] Note that long is 32-bit on riscv32, so the title is misleading (there was no cast to 64-bit type before). The cast really was a no-op, as it didn't change the resulting type. The issue is that the types of sym_addr, target_section_addr and offset are Elf_Addr (aka Elf32_Addr), which is an unsigned type (image_target->vaddr_offset is signed, but not wider than Elf32_Addr, so it doesn't change the overall type). Thus when the result of the expression is extended to grub_int64_t it is always a positive value instead of the desired sign-extended one. > which stated to cause failures on riscv32 as reported in [2] Most likely the missing addend masked the error. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
On Jun 03 2021, Nikita Ermakov wrote: > This series contains patches to add support for LoadFile2 protocol to load > initrd on EFI systems. Also it contains patches to load Linux kernel with EFI > stub on riscv platforms and unites arm and riscv codes together into common > loader code for EFI systems. That doesn't work with a CD image. When I try to run http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso with qemu, the initrd fails to load. $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m 8g -kernel u-boot.bin -drive format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso OpenSBI v0.9 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : riscv-virtio,qemu Platform Features : timer,mfdeleg Platform HART Count : 4 Firmware Base : 0x8000 Firmware Size : 124 KB Runtime SBI Version : 0.2 Domain0 Name : root Domain0 Boot HART : 1 Domain0 HARTs : 0*,1*,2*,3* Domain0 Region00 : 0x8000-0x8001 () Domain0 Region01 : 0x-0x (R,W,X) Domain0 Next Address : 0x8020 Domain0 Next Arg1 : 0xbf00 Domain0 Next Mode : S-mode Domain0 SysReset : yes Boot HART ID : 1 Boot HART Domain : root Boot HART ISA : rv64imafdcsu Boot HART Features: scounteren,mcounteren,time Boot HART PMP Count : 16 Boot HART PMP Granularity : 4 Boot HART PMP Address Bits: 54 Boot HART MHPM Count : 0 Boot HART MHPM Count : 0 Boot HART MIDELEG : 0x0222 Boot HART MEDELEG : 0xb109 U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +) CPU: rv64imafdcsu Model: riscv-virtio,qemu DRAM: 8 GiB In:uart@1000 Out: uart@1000 Err: uart@1000 Net: No ethernet found. Hit any key to stop autoboot: 0 Device 0: 1af4 VirtIO Block Device Type: Hard Disk Capacity: 225.7 MB = 0.2 GB (462376 x 512) ... is now current device ** Invalid partition 3 ** ** Invalid partition 4 ** ** Invalid partition 2 ** Scanning virtio 0:1... ** Unable to read file / ** Failed to load '/' libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk virtio-blk#8... Found 2 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootriscv64.efi 2584576 bytes read in 3 ms (821.6 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootriscv64.efi Welcome to GRUB! Please press 't' to show the boot menu on this console error: ../../grub-core/video/video.c:761:no suitable video mode found. openSUSE Tumbleweed ┌┐ │ Boot from Hard Disk│ │*Installation │ │ Upgrade│ │ More ... │ ││ ││ ││ ││ ││ ││ ││ ││ ││ └┘ Use the ▲ and ▼ keys to select which entry is highlighted. Press enter to boot the selected OS, `e' to edit the commands before booting or `c' for a command-line. Loading kernel ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: ERROR: Failed to load initrd! EFI stub: Exiting boot services and installing virtual address map... -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel
Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
On Jun 27 2021, Heinrich Schuchardt wrote: > On 6/26/21 8:07 PM, Andreas Schwab wrote: >> On Jun 03 2021, Nikita Ermakov wrote: >> >>> This series contains patches to add support for LoadFile2 protocol to load >>> initrd on EFI systems. Also it contains patches to load Linux kernel with >>> EFI >>> stub on riscv platforms and unites arm and riscv codes together into common >>> loader code for EFI systems. >> >> That doesn't work with a CD image. When I try to run >> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso >> with qemu, the initrd fails to load. > > Please, indicate how you built u-boot.bin. With qemu-riscv64_smode_defconfig. >> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m 8g >> -kernel u-boot.bin -drive >> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso > > This command results in an error > > qemu-system-riscv64: warning: > No -bios option specified. Not loading a firmware. Looks like you use an old qemu. Nowadays it automatically loads opensbi as firmware. > Please, provide a repo with the GRUB code you have been compiling. https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/grub2 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
That appears to have issues with loading the initrd over network. I can see the RRQ packet for the initrd arriving at the tftp server, the first DATA packet sent out by the sever, which is acknowleged by the client. But all subsequent DATA packages are never acknowleged by the client, which just times out. The kernel is loaded without problem. Loading kernel ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table error: ../../grub-core/net/drivers/efi/efinet.c:81:couldn't send network packet. EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path EFI stub: Exiting boot services and installing virtual address map... Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
On Okt 05 2021, Heinrich Schuchardt wrote: > Do you think this problem is RISC-V specific No, I don't think so. > and related to the series? Since network download of the kernel works, this seems to be related to the use of the LoadFile2 protocol. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
On Okt 05 2021, Heinrich Schuchardt wrote: > Which firmware did you use? U-Boot or EDK II? Which version? U-Boot. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
On Okt 05 2021, Heinrich Schuchardt wrote: > Before the 'boot' command the communication via TFTP seems to work fine. > The init command can identify which file exists on the TFTP server. > > The boot command calls ShutDown() and Stop() on the SNP protocol and > closes it. And then tries to open it again for the LOAD_FILE2 protocol. > > The question remains why the protocol cannot be reopened. It is unclear > if this is a GRUB or a U-Boot issue. The strange thing is that the first two packets+ACK still get through. Maybe related to the size of the following DATA packet? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] efinet: correct closing of SNP protocol
On Okt 06 2021, Heinrich Schuchardt wrote: > In the context of the implementation of the EFI_LOAD_FILE2_PROTOCOL for > the initial ramdisk it was observed that opening the SNP protocol failed > (https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00020.html). > This is due to an incorrect call to CloseProtocol(). > > This is corrected in the first patch. > > The second patch provides a new function grub_efi_close_protocol() to > simplify the coding. Sucessfully tested with https://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso on the Hifive Unmatched. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
CMOS_ADDRESS of ThinkVantage
Hi, i just wonted to contribute the correct CMOS address for the ThinkVantage-Button for: LENOVO ThinkPad T410s (2912W1C) it is: GRUB_BUTTON_CMOS_ADDRESS=101:3 Regards -- Andreas Freimuth signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Savannah-users] Anonymous commit (empty Author and Committer)
Kaz Kylheku writes: > Nope. They will have a git in which that commit looks like their own > local work. *Someone* will inadvertently do a "git push" to blast out > their changes based on that deleted commit, thereby causing it to > reappear. Not if another one pushes something different in the mean time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub
On 2016-01-22 13:56, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 22.09.2015 10:53, Ian Campbell wrote: >> Hi Vladimir & grub-devel, >> >> Do you have any thoughts on this issue with i386 pv-grub2? >> > Is it still an issue? If so I'll try to replicate it. From stack dump I > see that it has jumped to NULL. GRUB has no threads so it's not a race > condition with itself but may be one with some Xen part. An altrnative > possibility is that grub forgets to flush cache at some point in boot > process. I can still reproduce the issue. I don't think much has changed in my setup since the report. I run the current version of Xen and GRUB from Debian stable. /Andreas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Test for files with ls
Hi, I have there a small patch to commands/ls.c, whichs makes the ls-command return an error for non existing fils (as the bash ls command). With this patch, one can have in the grub.cfg files statements like: if ls /boot/grub/grub.cfg.gfx ; then source /boot/grub/grub.cfg.gfx fi I would be glad if you accept the patch or give me comments to improve the patch. Andreas lsreturnserr Description: lsreturnserr --- Registergericht: Traunstein / Registry Court: HRB 275 – Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Rainer Hagl, Matthias Fauser E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
RE: [PATCH] Test for files with ls
Hello Robert, My experience showed me that a 'source' - command is not allowed to fail. In my grub.cfg is a 'source'-command which includes a grub.cfg.gfx. If I delete the grub.cfg.gfx also the grub.cfg is rejected and grub boot's as if there were no grub.cfg at all. I tested this with GRUB 1.96 By Anreas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Millan Sent: Saturday, July 12, 2008 4:27 PM To: The development of GRUB 2 Subject: Re: [PATCH] Test for files with ls On Mon, Jul 07, 2008 at 09:46:58AM +0200, Lampersperger Andreas wrote: > Hi, > > I have there a small patch to commands/ls.c, whichs makes the > ls-command return an error for non existing fils (as the bash ls > command). > > With this patch, one can have in the grub.cfg files statements like: > > if ls /boot/grub/grub.cfg.gfx ; then > source /boot/grub/grub.cfg.gfx > fi You don't need this kind of protection. Your script is equivalent to: source /boot/grub/grub.cfg.gfx because commands are (intentionaly) allowed to fail. Is there another use case for your proposed change? (if not, I think it's better not to add it; we don't need to implement every feature in coreutils/bash). -- Robert Millan I know my rights; I want my phone call! What good is a phone call... if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel --- Registergericht: Traunstein / Registry Court: HRB 275 – Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Rainer Hagl, Matthias Fauser E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 svn2059
BandiPat wrote: phcoder wrote: Have you re-run grub-setup? -- No, I've never run grub-setup after an install, only grub-install & grub-mkconfig. What will that program do? I tried to read the man page, but it gave me an error. It's invoked by grub-install to do the actual installation of the bootloader. Basically it installs an image generated by grub-mkimage. grub-install just tries to automate all this stuff. So in fact you run grub-setup. Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 svn2059
BandiPat schrieb: Thanks Andreas, I just figured that out as well when testing on another machine just now. If you still have the file I sent you for svn2059, would you mind testing it on your machine as well. I'm tempted to send you the svn2059 or 2065 to compile on your current machine, to see if it behaves differently than the one I built. Be prepared though, as I'm sure you'll need to re-install svn2031 back after 2059 fails to boot. Keep your LiveCD available to reboot! :-) I tested the svn2059-60.1 build on my current Zenwalk installation. It would boot here, but I have it installed to superblock of my ext3 partition, so that might be the difference. Therefore I installed grub2 to the MBR, but like that it would work too. But I noticed two other problems: * If I drop to console with 'c' from the menu and then reload the menu with 'configfile (hd0,3)/boot/grub/grub.cfg', 'prefix' is unset and I can't boot. If I drop then back to console I can set 'prefix' properly to '(hd0,3)/boot/grub' and boot from console, but configfile won't work. * With the 'linux' loader as opposed to the 'linux16' loader, I would always get a verbose splash, although I force a silent one with 'splash=silent'. My assumption was that the kernel parameters are ignored at all, but passing a wrong root resulted in a error. So either only 'splash=silent' is ignored or its something completely different. I think the problem is related to the one described in "New linux loader doesn't like vga=1". Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] prevent duplicated entries due to symlinks
If there's both a symlink and a kernel at which the symlink is pointing
in the list of detected kernels of 10_linux, two entries are created for
actually the same kernel. This patch checks for this condition and only
uses the symlink (usually the wanted behaviour), in case the target of
the symlink doesn't exist, it uses neither.
Furthermore there may be kernel images named e.g. /boot/vmlinuz, so to
detect those the patch doesn't require a hyphen in the kernel name.
In this case the sed used to determine the kernel version, won't return
as expected an empty string. Therefore I replaced it by another one with
the wanted behaviour.
If the kernel version can be empty we don't want to have a "GNU/Linux,
linux " menuentry. Accordingly this patch adds a check for empty kernel
version, so that only "GNU/Linux" will be displayed.
Finally there's quite a bunch of other names for initrds. This patch
adds support for initrd.gz and initrd.splash. Both initrd.img and
initrd.gz become or were yet supported with two different version
positions and without version at all. For initrd.splash this isn't
needed because it's not kernel version dependent.
This is my first contribution and although I tried to inform myself as
good as possible and double-checked everything, I could have missed
something to you probably obvious. If there are any such problems, let
me know, I'll do my best to get it sorted out.
Andreas
diff --git a/ChangeLog b/ChangeLog
index 9097f25..ddf1c3e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-05-01 Andreas Born
+
+* util/grub.d/10_linux.in: Prevent duplicated entries because both
+ symlink and symlinked kernel are detected, only use the symlink
+ then. Detect also kernels without a hyphen in a name and use an
+ empty version for those kernels. Don't display linux in
+ the menuentry title if version is empty. Detect more initrds e.g.
+ initrd.gz.
+
2009-04-30 David S. Miller
* util/hostdisk.c (device_is_wholedisk): New function.
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index c2da413..66768eb 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -112,9 +112,18 @@ EOF
EOF
}
-list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
+list=`for i in /boot/vmlinu[xz]* /vmlinu[xz]* ; do
if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
done`
+for i in $list ; do
+ if test -h $i ; then
+target="`readlink -f $i`"
+list=`echo $list | tr ' ' '\n' | grep -vx $target | tr '\n' ' '`
+if test ! -f $target ; then
+ list=`echo $list | tr ' ' '\n' | grep -vx $i | tr '\n' ' '`
+fi
+ fi
+done
while [ "x$list" != "x" ] ; do
linux=`find_latest $list`
@@ -122,13 +131,16 @@ while [ "x$list" != "x" ] ; do
basename=`basename $linux`
dirname=`dirname $linux`
rel_dirname=`make_system_path_relative_to_its_root $dirname`
- version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
+ version=`echo $basename | sed -e "s,^[^\-]*-*,,"`
alt_version=`echo $version | sed -e "s,\.old$,,g"`
linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
initrd=
for i in "initrd.img-${version}" "initrd-${version}.img" \
- "initrd.img-${alt_version}" "initrd-${alt_version}.img"; do
+ "initrd.img-${alt_version}" "initrd-${alt_version}.img" \
+ "initrd.gz-${version}" "initrd-${version}.gz" \
+ "initrd.gz-${alt_version}" "initrd-${alt_version}.gz" \
+ "initrd.img" "initrd.gz" "initrd.splash"; do
if test -e "${dirname}/${i}" ; then
initrd="$i"
break
@@ -140,10 +152,16 @@ while [ "x$list" != "x" ] ; do
# "UUID=" magic is parsed by initrds. Since there's no initrd, it can't
work here.
linux_root_device_thisversion=${GRUB_DEVICE}
fi
+
+ if test -n "${version}" ; then
+title="${OS}, linux ${version}"
+ else
+title="${OS}"
+ fi
- linux_entry "${OS}, linux ${version}" \
+ linux_entry "${title}" \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
- linux_entry "${OS}, linux ${version} (recovery mode)" \
+ linux_entry "${title} (recovery mode)" \
"single ${GRUB_CMDLINE_LINUX}"
list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] prevent duplicated entries due to symlinks
Pavel Roskin schrieb:
Suppose I have Linux 2.6.29 and 2.6.28. Your script makes entries for
"Linux default" and "Linux 2.6.28". Then I install Linux 2.6.30 and
don't run grub-mkconfig. Then I can boot Linux 2.6.30 and 2.6.28 form
the menu, but not 2.6.29.
Even if I run grub-mkconfig, there is still something I lose. By
selecting "Linux default" I still don't know it it's Linux 2.6.30 or
something else.
For me, the convenience of not having to rerun grub-mkconfig doesn't
outweigh the convenience of knowing what I'm loading.
I know, it's have to argue about preferences, but if you want you
changes to be accepted, you need to present a good case.
It's also that kind of discussion which eventually separates the wheat
from the chaff. Thus I welcome it.
I would consider placing the kernel pointed to by the vmlinuz link to
the first position of the Linux kernels. Another approach would be to
have an entry for the link without suppressing any versioned entries.
Ok, I understand and if it is a preference why don't make it a
preference. :)
You can find attached a new version of the patch, which per default will
read the symlink and create an entry for the target, not the symlink.
You can change this behaviour with "GRUB_USE_LINUX_SYMLINK=yes". If you
define this environment variable with that value, it will use the
behaviour I implemented before. This means it uses the symlink and
ignores the kernel the symlink is currently pointing at.
I think this is the best solution, because it prevents duplicated
entries (only one entry for symlink or symlink target) and it gives the
user the choice which behaviour he wants (rerun of grub-mkconfig needed
or not needed).
Is that solution all right?
Please specify where those names are used. Can you give the
distribution name and version where such names are used?
Zenwalk, Slackware for example. I think more Slackware derivates are
using it too.
Let's add support for more versioned names first. That should be rather
non-controversial.
I see no more versioned names which could be added for the existing
extension(s). There is initrd-. and
initrd.-. Whereas can either be $version or
$alt_version and can be "img" or "gz" ("gz" is new) and at the
very end as a last resort initrd.img initrd.gz and initrd.splash are
tried in that order (that's also new). Roughly speaking only new
fallback options.
Do you see a problem there or do you have a concrete versioned name to add?
Andreas
diff --git a/ChangeLog b/ChangeLog
index 2203b68..f1606ba 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -0,0 +1,12 @@
+2009-05-05 Andreas Born
+
+* util/grub.d/10_linux.in: Prevent duplicated entries because both
+symlink and symlinked kernel are detected.
+Default: use only target of the symlink
+GRUB_USE_LINUX_SYMLINK=yes: use only the symlink
+Detect also kernels without a hyphen in a name and use an
+empty version for those kernels.
+Don't display ', linux ' in the menuentry title if
+version is empty.
+Detect more initrds e.g. initrd.gz.
+
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index c2da413..f2649be 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -112,9 +112,32 @@ EOF
EOF
}
-list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
+list=`for i in /boot/vmlinu[xz]* /vmlinu[xz]* ; do
if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
done`
+
+for i in $list ; do
+ if ! test -h $i ; then
+continue # no symlink
+ fi
+ target="`readlink -f $i`"
+ if test ! -f $target ; then
+# inexistent target
+list=`echo $list | tr ' ' '\n' | grep -vx $i | grep -vx $target \
+ | tr '\n' ' '`
+continue
+ fi
+
+ # default: use the target, not the symlink
+ if [ "${GRUB_USE_LINUX_SYMLINK}" = "yes" ] ; then
+list=`echo $list | tr ' ' '\n' | grep -vx $target | tr '\n' ' '`
+ else
+list=`echo $list | tr ' ' '\n' | grep -vx $i | tr '\n' ' '`
+if ! echo $list | grep -qw $target ; then
+ list="$list $target"
+fi
+ fi
+done
while [ "x$list" != "x" ] ; do
linux=`find_latest $list`
@@ -122,13 +145,16 @@ while [ "x$list" != "x" ] ; do
basename=`basename $linux`
dirname=`dirname $linux`
rel_dirname=`make_system_path_relative_to_its_root $dirname`
- version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
+ version=`echo $basename | sed -e "s,^[^\-]*-*,,"`
alt_version=`echo $version | sed -e "s,\.old$,,g"`
linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
initrd=
for i in "initrd.img-${vers
[PATCH] create variables when exporting them
This patch changes grub_env_export to create variables with empty value,
if necessary.
This makes it possible to export variables before actually assigning
them any value and is the way bash behaves.
Thanks
Andreas
ChangeLog:
2009-10-15 Andreas Born
* kern/env.c (grub_env_export): Create inexistent variables
before exporting.
Index: kern/env.c
===
--- kern/env.c (Revision 2631)
+++ kern/env.c (Arbeitskopie)
@@ -170,8 +171,13 @@
struct grub_env_var *var;
var = grub_env_find (name);
- if (var)
-var->type = GRUB_ENV_VAR_GLOBAL;
+ if (! var)
+ {
+if (grub_env_set (name, "") != GRUB_ERR_NONE)
+return grub_errno;
+var = grub_env_find (name);
+ }
+ var->type = GRUB_ENV_VAR_GLOBAL;
return GRUB_ERR_NONE;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] create variables when exporting them
Here you go:
ChangeLog:
2009-10-15 Andreas Born
* kern/env.c (grub_env_export): Create nonexistent variables
before exporting.
The mixed indentation (tabs and spaces) in kern/env.c was a bit confusing.
Andreas
Colin Watson schrieb:
On Thu, Oct 15, 2009 at 08:40:37PM +0200, Andreas Born wrote:
This patch changes grub_env_export to create variables with empty value,
if necessary.
This makes it possible to export variables before actually assigning
them any value and is the way bash behaves.
This makes sense to me (although bash is "too big and too slow" and
we'll never implement anything close to all of it, this is a pretty
cheap way to reduce confusion due to differences), although probably for
post-1.97. A couple of nits:
* kern/env.c (grub_env_export): Create inexistent variables
before exporting.
"nonexistent"
+ if (! var)
+ {
+if (grub_env_set (name, "") != GRUB_ERR_NONE)
+return grub_errno;
+var = grub_env_find (name);
+ }
GNU brace style involves indenting the braces as well, thus:
if (! var)
{
if (grub_env_set (name, "") != GRUB_ERR_NONE)
return grub_errno;
var = grub_env_find (name);
}
Index: kern/env.c
===
--- kern/env.c (Revision 2631)
+++ kern/env.c (Arbeitskopie)
@@ -170,8 +171,13 @@
struct grub_env_var *var;
var = grub_env_find (name);
- if (var)
-var->type = GRUB_ENV_VAR_GLOBAL;
+ if (! var)
+{
+ if (grub_env_set (name, "") != GRUB_ERR_NONE)
+ return grub_errno;
+ var = grub_env_find (name);
+}
+ var->type = GRUB_ENV_VAR_GLOBAL;
return GRUB_ERR_NONE;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug #27710] variable type not exported into new context
As of r1917 grub_env_context_open still doesn't mark exported variables as global in the new context. Attached patch exports them with grub_env_export in the new context. Andreas Born schrieb: URL: <http://savannah.gnu.org/bugs/?27710> Summary: variable type not exported into new context Project: GNU GRUB Submitted by: shador Submitted on: Do 15 Okt 2009 15:38:48 GMT Category: Terminal Severity: Major Priority: 5 - Normal Item Group: Software Error Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: Release: SVN Reproducibility: Every Time Planned Release: None ___ Details: A variable created and exported afterwards, isn't marked 'export' after a new context was created by issuing configfile. Thus if you issue another time configfile the variable is unset. This means recursive menus deeper than 2 menus are not possible by loading another configfile. Example: set blub=blob export blub configfile configfile echo $blub => nothing, blub was unset after the second configfile (prefix also so everything fails). Workaround: In every new context (-> every .cfg file) (re)export the variable (and prefix, root). Attached is a patch which marks variables copied into the new context again 'export' preventing breakage of prefix and root. ___ File Attachments: --- Date: Do 15 Okt 2009 15:38:48 GMT Name: export-context.diff Size: 359B By: shador <http://savannah.gnu.org/bugs/download.php?file_id=18886> ___ Reply to this item at: <http://savannah.gnu.org/bugs/?27710> ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug #27695] parser.sh ignores the closing quote when preceeded by a variable
Problem exists still as of r1917. I've attached a rediffed version of
Vladimir's patch.
The behaviour without the patch changed (it's even more confusing), but
it's basically still the same:
grub> echo "$root"
grub>"
hd0,1
Vladimir 'phcoder' Serbinenko schrieb:
Andreas Born wrote:
URL:
<http://savannah.gnu.org/bugs/?27695>
Summary: parser.sh ignores the closing quote when preceeded
by a variable
Attached patch should fix this bug
Project: GNU GRUB
Submitted by: shador
Submitted on: Di 13 Okt 2009 21:11:16 GMT
Category: Terminal
Severity: Major
Priority: 5 - Normal
Item Group: Software Error
Status: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release:
Release: SVN
Reproducibility: Every Time
Planned Release: None
___
Details:
The problem is reproducible with this example:
set blub=blob
echo $blub
blob
echo "${blub}"
blob
echo "$blub"
=> fails, the closing quote is ignored
echo "$blub""
blob
=> works as workaround
The real trouble starts with strings containing spaces. But it can be fixed,
as shown, by adding another quote at the end or using ${...}.
This was tested with beta~4.
___
Reply to this item at:
<http://savannah.gnu.org/bugs/?27695>
___
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
___
Bug-grub mailing list
bug-g...@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub
=== modified file 'script/lexer.c'
--- script/lexer.c 2009-11-23 15:37:33 +
+++ script/lexer.c 2009-11-29 00:16:30 +
@@ -350,9 +350,11 @@
if (! (check_varstate (newstate)))
{
if (state->state == GRUB_PARSER_STATE_VARNAME2
- || state->state == GRUB_PARSER_STATE_QVARNAME2)
- nextchar (state);
- state->state = newstate;
+ || state->state == GRUB_PARSER_STATE_QVARNAME2)
+ {
+ nextchar (state);
+ state->state = newstate;
+ }
break;
}
@@ -378,7 +380,6 @@
buffer[bufpos++] = 0;
- state->state = newstate;
yylval->arg = grub_script_arg_add (parsestate, yylval->arg,
GRUB_SCRIPT_ARG_TYPE_VAR, buffer);
grub_dprintf ("scripting", "vartoken=`%s'\n", buffer);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] create variables when exporting them
Same here. Nothing changed as of r1917 and I didn't get any further
feedback either.
I've attached a rediffed version, too.
Andreas Born schrieb:
Here you go:
ChangeLog:
2009-10-15 Andreas Born
* kern/env.c (grub_env_export): Create nonexistent variables
before exporting.
The mixed indentation (tabs and spaces) in kern/env.c was a bit
confusing.
Andreas
Colin Watson schrieb:
On Thu, Oct 15, 2009 at 08:40:37PM +0200, Andreas Born wrote:
This patch changes grub_env_export to create variables with empty
value, if necessary.
This makes it possible to export variables before actually
assigning them any value and is the way bash behaves.
This makes sense to me (although bash is "too big and too slow" and
we'll never implement anything close to all of it, this is a pretty
cheap way to reduce confusion due to differences), although probably for
post-1.97. A couple of nits:
* kern/env.c (grub_env_export): Create inexistent variables
before exporting.
"nonexistent"
+ if (! var)
+ {
+if (grub_env_set (name, "") != GRUB_ERR_NONE)
+return grub_errno;
+var = grub_env_find (name);
+ }
GNU brace style involves indenting the braces as well, thus:
if (! var)
{
if (grub_env_set (name, "") != GRUB_ERR_NONE)
return grub_errno;
var = grub_env_find (name);
}
@@ -170,8 +171,13 @@
struct grub_env_var *var;
var = grub_env_find (name);
- if (var)
-var->type = GRUB_ENV_VAR_GLOBAL;
+ if (! var)
+{
+ if (grub_env_set (name, "") != GRUB_ERR_NONE)
+ return grub_errno;
+ var = grub_env_find (name);
+}
+ var->type = GRUB_ENV_VAR_GLOBAL;
return GRUB_ERR_NONE;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] create variables when exporting them
I just noticed that I forgot the header line of the diff. Sorry for that.
New double checked version attached.
The Changelog is still:
2009-12-15 Andreas Born
* kern/env.c (grub_env_export): Create nonexistent variables
before exporting.
Andreas Born schrieb:
Same here. Nothing changed as of r1917 and I didn't get any further
feedback either.
I've attached a rediffed version, too.
Andreas Born schrieb:
Here you go:
ChangeLog:
2009-10-15 Andreas Born
* kern/env.c (grub_env_export): Create nonexistent variables
before exporting.
The mixed indentation (tabs and spaces) in kern/env.c was a bit
confusing.
Andreas
Colin Watson schrieb:
On Thu, Oct 15, 2009 at 08:40:37PM +0200, Andreas Born wrote:
This patch changes grub_env_export to create variables with empty
value, if necessary.
This makes it possible to export variables before actually
assigning them any value and is the way bash behaves.
This makes sense to me (although bash is "too big and too slow" and
we'll never implement anything close to all of it, this is a pretty
cheap way to reduce confusion due to differences), although probably
for
post-1.97. A couple of nits:
* kern/env.c (grub_env_export): Create inexistent variables
before exporting.
"nonexistent"
+ if (! var)
+ {
+if (grub_env_set (name, "") != GRUB_ERR_NONE)
+return grub_errno;
+var = grub_env_find (name);
+ }
GNU brace style involves indenting the braces as well, thus:
if (! var)
{
if (grub_env_set (name, "") != GRUB_ERR_NONE)
return grub_errno;
var = grub_env_find (name);
}
=== modified file 'kern/env.c'
--- kern/env.c 2009-07-16 22:14:09 +
+++ kern/env.c 2009-11-29 00:15:05 +
@@ -170,8 +171,13 @@
struct grub_env_var *var;
var = grub_env_find (name);
- if (var)
-var->type = GRUB_ENV_VAR_GLOBAL;
+ if (! var)
+{
+ if (grub_env_set (name, "") != GRUB_ERR_NONE)
+ return grub_errno;
+ var = grub_env_find (name);
+}
+ var->type = GRUB_ENV_VAR_GLOBAL;
return GRUB_ERR_NONE;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug #27710] variable type not exported into new context
Seems like I completely forgot the diff here. Sorry, this time it is attached. Changelog: 2009-12-15 Andreas Born * kern/env.c (grub_env_context_open): Reapply global flag for variables exported to the new context. This behaviour can be really annoying. If one boots to the grub menu, chooses the shell with 'c', loads the menu again and drops to shell again (i.e. created 2 new contexts), prefix and root are gone. Although they are still exported into the first new context, they aren't marked again global in that context. Therefore creating another new context (from within the first context) doesn't export prefix and root from the 1st context to the second context. Of course, that has to happen as the global flag is not set in the first context. I created the new contexts by loading a grub.cfg which doesn't touch prefix and root with the configfile command. The patch changes the behaviour to not only export variables to the new context instead they are exported to the new context and then marked as global again with grub_env_export. Hope the issue is understandable like that. Otherwise please ask. Regards Andreas Andreas Born schrieb: As of r1917 grub_env_context_open still doesn't mark exported variables as global in the new context. Attached patch exports them with grub_env_export in the new context. Andreas Born schrieb: URL: <http://savannah.gnu.org/bugs/?27710> Summary: variable type not exported into new context Project: GNU GRUB Submitted by: shador Submitted on: Do 15 Okt 2009 15:38:48 GMT Category: Terminal Severity: Major Priority: 5 - Normal Item Group: Software Error Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: Release: SVN Reproducibility: Every Time Planned Release: None ___ Details: A variable created and exported afterwards, isn't marked 'export' after a new context was created by issuing configfile. Thus if you issue another time configfile the variable is unset. This means recursive menus deeper than 2 menus are not possible by loading another configfile. Example: set blub=blob export blub configfile configfile echo $blub => nothing, blub was unset after the second configfile (prefix also so everything fails). Workaround: In every new context (-> every .cfg file) (re)export the variable (and prefix, root). Attached is a patch which marks variables copied into the new context again 'export' preventing breakage of prefix and root. ___ File Attachments: --- Date: Do 15 Okt 2009 15:38:48 GMT Name: export-context.diff Size: 359B By: shador <http://savannah.gnu.org/bugs/download.php?file_id=18886> ___ Reply to this item at: <http://savannah.gnu.org/bugs/?27710> ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ === modified file 'kern/env.c' --- kern/env.c 2009-07-16 22:14:09 + +++ kern/env.c 2009-11-29 00:15:05 + @@ -101,6 +101,7 @@ grub_env_context_close (); return grub_errno; } + grub_env_export (var->name); grub_register_variable_hook (var->name, var->read_hook, var->write_hook); } } ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
Am 10.07.2012 00:38, schrieb Graham Cunnington: The above is incomprehensible to most users who are not developers. Why not just say: "You can password-protect Grub. This will secure it against malware and anybody taking over your computer." This is in no way comparable to Secure Boot or TPM measure in general. A password just prevents THIS instance of grub and THIS grub configuration from being used to boot systems in an unintended manner by unauthorized individuals. It can be easily circumvented by e.g. booting from a CDROM or USB drive (hardware access is the key here). Password-based menus are inherently insecure when used with physical access. It's commonly described as security by obscurity. Just locking the one most obvious entry in a secure manner doesn't make the whole building safe if there are other slightly hidden, unlocked entries. Security AND obscurity combined can offer additional security (e.g. all doors locked and hidden). Furthermore password-based menus don't prevent that installation of grub to be replaced by a malicious modified instance of grub which could e.g. log your password and could load a maliciously modified kernel. That's because unlike other measure like Secure Boot it does not verify the code executed. Instead you're just trusting the code to correctly verify the password and it does not even check the kernel. To be protected against malicious code there needs to be a secure component that checks every code executed by the computer at any point for trustworthiness. That's simply put and sort of an optimal scenario. In reality you won't be able to check more than a sensible selection for administrative reasons (except for clearly defined use cases like some embedded devices) and it's somewhat more complicated. So we have two completely different use cases here: - passwords: verification of the user i.e. the human individual trying to use that bootloader instance (not anything else), could be ineffective with malicious code which is not checked here - TPM or Secure Boot: verification of the actual code executed i.e. no malicious software is executed if everything is verified (practically impossible) and if nobody is able to get his malicious code trusted due to human or administrative mistakes e.g. AFAIK as with Secure Boot almost nothing is verified the glamorously advertised, all-encompassing, magic protection is actually a fallacy and just very limited. If it weren't for the seemingly obvious true concerns of global companies, it could actually be quite an interesting technology. Andreas Born ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
Am 10.07.2012 03:23, schrieb richardvo...@gmail.com: I'll decloak to offer my response, but please remember that I'm not one of the developers so my opinion is of limited value. By the same token, I've been recognized by Microsoft for community contributions, but I do not work for them and do not speak for them. First, putting things in simple language is very positive and necessary. Did anybody comment on or deny it? However, your short easy-to-understand summary is incorrect. The bootloader password doesn't protect against malware, and it offers only a little protection against "anybody taking over your computer". In fact, if some malware rewrote the grub configuration file, it could be quite annoying to recover. No, you're incorrect. The password is stored IN the grub configuration file. So if that person can rewrite the grub configuration file it can rewrite the password too (or fully disable it or ...). Thus that protection becomes fully INEFFECTIVE. Even if the password were stored in a separate file that file could be changed just as well. Also, the bootloader password solves a very different problem from the secure boot initiative. The grub password check doesn't verify integrity of system files. Yes, that's the point. As they are not related one can't do the job of the other one unlike what you suggest in your initial mail. Finally, the secure boot initiative isn't a threat to open source operating systems. The computer administrator has to install a signed OS and then enable signature verification in the firmware. All systems ship with verification disabled, and all the major motherboard manufacturers have indicated that secure boot will always stay an opt-in mechanism. And even then, the firmware setup utility can be used to once again disable verification, so it isn't even a hindrance to resale of used equipment, as long as the sale is authorized and the configuration is changed. It might create some barrier to use of stolen equipment, but even then it is likely that clearing the NVRAM by removing the backup battery will gain access. Nobody's saying that the basic technology which is not exactly new either is a threat. But the implementation SecureBoot is. You're misinformed. While on x86 systems there's a switch required to disable SecureBoot that same switch is NOT ALLOWED for ARM systems (https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/restricted-boot-comic-contest-defend-user-freedom-on-tablets-and-smartphones). Please get your facts straight. Apart from that even if there is a switch the question remains how easily accessible it is going to be? How obvious the need to use it is going to be? You're the guy asking for stuff to be simple so that point should be clear to you. Full-disk encryption is still the best safeguard in case physical security is compromised. There's still some code loaded and executed before opening the volume. That code is responsible for initially decrypting the volume and loading something else from within it. Now I say "decrypt" so that means that code needs to get credentials from somewhere and if that code were malicious it would be given the credentials (as it would appear no different to the user) and could use them for anything. No way getting around verification of the code unless you have a firmware that supports booting from that volume directly but then again the firmware needs to be verified by some means too. Imagine you're giving a party and want some sort of entry control. As long as you don't verify somebody (code) to be trusted to execute the entry control by checking everybody's invite (credentials), there's no way to have it invites-only. If you're lacking credentials it won't work and if the doorman are untrusted they could not be checking the invites/credentials properly. You can't get rid of either one of them completely. So definitely, this sort of thing needs to be summarized and then explained in detail using plain English that can be understood by those who aren't so technically astute. But lets not sacrifice accuracy in the desire to use simpler words. Ben Voigt On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington wrote: Subject: Secure Boot. Why don't you take the wind out of their sails? (1) Now is the time to move quickly. The development needs to be short and clear so that even a beginner can use it immediately. (2) The Problem: Microsoft and allied companies have an idea to force a Microsoft (Verisign) key on to hardware manufacturers which may be an attempt once again to bring in anti-competitive practices and may decrease the uptake of Linux systems. The "Secure boot key" proposed could in fact limit consumer choice and drag Grub2 into a fight none of its making. (3) The Problem of Verbosity: Grub2 already has the solution to protect Grub and therefore the kernels that Grub boots, but that solution is currently unavailable because Grub developers have no idea how to
grub2: Patch to correct hidden timeout behavior
Hi,
I'm using Debian with grub version 2.00-20.
My /etc/default/grub configuration contains the following lines:
GRUB_TIMEOUT=-1
GRUB_HIDDEN_TIMEOUT=3
Expected behavior: When booting, grub should display a three second
countdown and if no key is pressed, boot the default grub entry, after
the countdown finishes.
Current behavior: When booting, grub displays a three second countdown
and if no key is pressed, the grub menu is shown, after the countdown
finishes.
The problem lies in the 00_header.in script [1], specifically:
if sleep$verbose --interruptible ${1} ; then
set timeout=${2}
fi
This just always sets the countdown to GRUB_TIMEOUT, even if the sleep
is not interrupted. I think it should be something like:
if sleep$verbose --interruptible ${1} ; then
set timeout=0
else
set timeout=${2}
fi
I created a patch to fix this (see attachment). Please include the patch.
Best regards,
Andreas
1: http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/00_header.in
diff -rup grub2-2.00.orig/util/grub.d/00_header.in grub2-2.00/util/grub.d/00_header.in
--- grub2-2.00.orig/util/grub.d/00_header.in 2013-11-21 19:01:07.0 +0100
+++ grub2-2.00/util/grub.d/00_header.in 2013-11-22 19:23:22.208203853 +0100
@@ -315,6 +315,8 @@ EOF
fi
cat << EOF
if sleep$verbose --interruptible ${1} ; then
+ set timeout=0
+else
set timeout=${2}
fi
EOF
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Add apple_set_os command
The EFI on current macbooks configures hardware differently depending
on wether it is booting Mac OS X or a different os, for example
disabling the internal GPU completely on some models.
Mac OS X identifies itself using a custom EFI protocol.
This adds a command that fakes the os identification, making all
hardware accessible.
---
grub-core/Makefile.core.def | 6 +++
grub-core/commands/efi/applesetos.c | 82 +
2 files changed, 88 insertions(+)
create mode 100644 grub-core/commands/efi/applesetos.c
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 42443bc..dc9c4de 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -742,6 +742,12 @@ module = {
};
module = {
+ name = applesetos;
+ common = commands/efi/applesetos.c;
+ enable = efi;
+};
+
+module = {
name = blocklist;
common = commands/blocklist.c;
};
diff --git a/grub-core/commands/efi/applesetos.c
b/grub-core/commands/efi/applesetos.c
new file mode 100644
index 000..9464307
--- /dev/null
+++ b/grub-core/commands/efi/applesetos.c
@@ -0,0 +1,82 @@
+/* applesetos.c - Pretend to be Mac OS X. */
+/*
+ * 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
Re: [PATCH] Add apple_set_os command
Am 31.12.2013 um 00:11 schrieb SevenBits :
> On Monday, December 30, 2013, Andreas Heider wrote:
> The EFI on current macbooks configures hardware differently depending
> on wether it is booting Mac OS X or a different os, for example
> disabling the internal GPU completely on some models.
>
> Mac OS X identifies itself using a custom EFI protocol.
>
> This adds a command that fakes the os identification, making all
> hardware accessible.
>
> Just a question: I do a lot of booting Linux on MacBooks, and I frequently
> suffer from this issue. How do we know that this code actually works? I'm not
> criticizing your code or anything, but how can you verify that identifying as
> Apple fixes these issues, or even that this patch works correctly. I'm only
> asking because I'm very interested in this if it works.
This depends, it just notifies all interested EFI drivers that they’re booting
Mac OS X, so there’s no general answer. On my laptop this stops the integrated
gnu from being disabled, so you could see it in lspci. But I guess you should
see some difference in dmesg before and after.
There might be side effects of other things breaking in osx-mode due to the
different configuration, so I implemented this as a optional command and not
the default.
Also, this is just one of the ways Apple detects osx vs other operating
systems, for example this does not help with acpi_osi=Darwin.
If you want to test it I’m interested if apple_set_os changes anything
noteworthy on older models. They only started to support bootcamp via EFI this
year, so I suspect that the hardware disabling took place in the BIOS/CSM
before.
>
> ---
> grub-core/Makefile.core.def | 6 +++
> grub-core/commands/efi/applesetos.c | 82
> +
> 2 files changed, 88 insertions(+)
> create mode 100644 grub-core/commands/efi/applesetos.c
>
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 42443bc..dc9c4de 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -742,6 +742,12 @@ module = {
> };
>
> module = {
> + name = applesetos;
> + common = commands/efi/applesetos.c;
> + enable = efi;
> +};
> +
> +module = {
>name = blocklist;
>common = commands/blocklist.c;
> };
> diff --git a/grub-core/commands/efi/applesetos.c
> b/grub-core/commands/efi/applesetos.c
> new file mode 100644
> index 000..9464307
> --- /dev/null
> +++ b/grub-core/commands/efi/applesetos.c
> @@ -0,0 +1,82 @@
> +/* applesetos.c - Pretend to be Mac OS X. */
> +/*
> + * 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
> +#include
> +#include
> +/* For NULL. */
> +#include
> +
> +GRUB_MOD_LICENSE ("GPLv3+");
> +
> +#define GRUB_EFI_APPLE_SET_OS_PROTOCOL_GUID \
> + { 0xc5c5da95, 0x7d5c, 0x45e6, \
> +{ 0xb2, 0xf1, 0x3f, 0xd5, 0x2b, 0xb1, 0x00, 0x77 } \
> + }
> +
> +struct grub_efi_apple_set_os_interface
> +{
> + grub_efi_uint64_t version;
> + void (*set_os_version) (const grub_efi_char8_t *os_version);
> + void (*set_os_vendor) (const grub_efi_char8_t *os_vendor);
> +};
> +typedef struct grub_efi_apple_set_os_interface
> grub_efi_apple_set_os_interface_t;
>
> Out of curiosity: how did you find these?
>
> +
> +static const grub_efi_char8_t apple_os_version[] = "Mac OS X 10.9";
> +static const grub_efi_char8_t apple_os_vendor[] = "Apple Inc.";
>
> Why are you making OS X 10.9 the default? Not every Mac can run 10.9. Ideally
> it would be very cool if you could figure out which version the user is
> running and identify as that.
AFAIK the os_version is never even read by the Apple EFI, so I just kept it as
simple as possible. We could also just put GRUB as the version.
>
> Secondly, you should include fallbacks in case this is run on a machine that
> isn't a Mac, as then that GUID and protocol won't be defined. It should exit
> g
Probing misjudges ext2 partition as fat.
Hello, grub developers, my problem summary (lots of details follow below): My /boot file system lives on partition /dev/sda1. This was an ext2 or ext4 file system (not entirely sure). When doing some grub-install work, this was wrongly recognized as fat. This resulted in a system that could no longer boot from hard drive. What helped in the end: Copying the files of /boot, umounting, overwriting the start of /dev/sda1 with zeros, mke2fs -t ext2 /dev/sda1, mounting, copying the files back to /boot and running grub-install again. Now the file system type was correctly determined, and my problem was solved. This problem happened in the wild. I did nothing particular to trigger it. It caught me by surprise. So far the summary. Now details follow that I feel might be relevant. If any questions remain I can answer, kindly do ask. This system is a "Sandy Bridge" CPU 64 bit notebook. Booting is via good ol' BIOS, no EFI here. The only OS I have on hard drive is a single 64 bit (X)Ubuntu installation. The trouble occurred when I upgraded that yesterday from Ubuntu 12.04 to Ubuntu 14.04. The grub version I've had problems with is 2.02~beta2-9ubuntu1, according to dpkg -s grub2-common. There is only one hard drive in the system, /dev/sda. It has two partitions: /dev/sda1 and /dev/sda2. I use /dev/sda1 as /boot. I tend to be conservative with /boot, so I think I had used ext2 for that before the reformat, with a remote chance of ext4 (not absolutely sure). What I do with /dev/sda2 is probably less relevant, but for the record, here is that story: That device is luks-encrypted. The decrypted version of /dev/sda2 is the only physical volume of some LVM volume group. That group provides several logical volumes: /root, /var, /home, swap and one /muell, this last one unused during all that follows. There is no fat partition anywhere on this hard drive. So far the invariants, which did not change while the following story unfolds. I had done an upgrade Ubuntu 12.04 -> 14.04. As the final step of that, the system rebooted. Or, rather, tried to. All it reached was a grub-rescue prompt complaining "/grub/i386-pc/normal.mod not found". I tried different ways to run grub-install to get me out of this problem. My first attempt was to boot from an Ubuntu 14.04 USB stick and chroot into my hard drive installation. I remember bind mounts of file systems such as /dev and /sys and I also provided /proc and a hand-crafted /etc/mtab. The grub-install found nothing to complain about. However, rebooting resulted in the same grub-rescue complaint. Trying things at the grub-rescue prompt, I found that grub thought the /dev/sda1 partition to be fat. If I remember correctly, I tried accessing this as (hd0,1) or (hd0,msdos1), it made no difference. However grub-rescue's ls could not find any files on that "fat" partition. Now the live Ubuntu USB stick does have a (v)fat partition. But boot attempts with it being disconnected gave the same result. I tried grub-install straight from the USB stick's Ubuntu. Same result. At some proint I tried "grub-install -v /dev/sda", after duly mounting /boot, and somewhere in the midst of the verbose output I spotted (originally all in one line): > grub-install: Info: grub-mkimage --directory '/usr/lib/grub/i386-pc' > --prefix '(,msdos1)/grub' --output '/boot/grub/i386-pc/core.img' > --format 'i386-pc' --compression 'auto' 'fat' 'part_msdos' > 'biosdisk' That 'fat' did not look right. At that point, I still thought the USB stick's partitions might confuse grub-install's probings. To boot without any fat, I went to another computer, which is running 64 bit Debian Wheezy, installed grub-rescue-pc (Version 1.99-27+deb7u2) on that, and pushed grub-rescue-usb.img onto the USB stick. With a little persuation, that allowed me to boot into my upgraded Ubuntu 14.04 (for the first time). With that running, I removed the USB stick. But repeating grub-install -v /dev/sda still resulted in the bad grub-mkimage line with fat, as quoted above. I include the entire output at the end of this mail. So I copied the content of /boot elsewhere, umounted /dev/sda1, wrote zeros to the first so many kilobytes of that block device, re-formated with mke2fs -t ext2 /dev/sda1 and copied the content back. That helped! > grub-install: Info: grub-mkimage --directory '/usr/lib/grub/i386-pc' > --prefix '(,msdos1)/grub' --output '/boot/grub/i386-pc/core.img' > --format 'i386-pc' --compression 'auto' 'ext2' 'part_msdos' > 'biosdisk' And I could boot into the system. :-) Too bad I did not make a backup of the entire /dev/sda1 image... I tried to reproduce the problem by creating a vfat on /dev/sda1 and then reformatted to
Re: Probing misjudges ext2 partition as fat.
> Unfortunately you destroyed any possibility to investigate it further. > You should at least have saved beginning of partition. I should have, yes. Please kindly accept my apologies! On the other hand, I did nothing to destroy the grub source code. So I hope it is still possible to investigate grub's fs-probing code for weaknesses. (My personal guess and speculation is, if legitimate grub developers don't do this analysis, less well-intentioned people will happily do the job.) Am 21.09.2014 um 16:41 schrieb Andrei Borzenkov: > В Sun, 21 Sep 2014 13:03:37 +0200 > Andreas Krüger пишет: > >> Hello, grub developers, >> >> my problem summary (lots of details follow below): >> >> My /boot file system lives on partition /dev/sda1. This was an ext2 >> or ext4 file system (not entirely sure). When doing some grub-install >> work, this was wrongly recognized as fat. >> >> This resulted in a system that could no longer boot from hard drive. >> >> What helped in the end: Copying the files of /boot, umounting, >> overwriting the start of /dev/sda1 with zeros, mke2fs -t ext2 >> /dev/sda1, mounting, copying the files back to /boot and running >> grub-install again. >> > Unfortunately you destroyed any possibility to investigate it further. > You should at least have saved beginning of partition. > > ___ > 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: LiveCD bootloader
Hi, we're building our LiveCD with Grub2. You can have a look at the config files we use/generate here: http://salix.svn.sourceforge.net/viewvc/salix/salix-live/trunk/livegrub2/ The other live stuff in general is here: http://salix.svn.sourceforge.net/viewvc/salix/salix-live/trunk/ For the buildscript look here (scroll towards the end for the grub2 related stuff): http://salix.svn.sourceforge.net/viewvc/salix/salix-live/trunk/build-salixlive.sh?revision=1638 There are some issues though: - Black border displayed around the initial splash screen (maybe fixed in trunk, haven't read so on the maillist) - Starting Grub2 fails on my pretty new desktop (the only such report as far as I'm concerned) - Graphics are pretty slow Andreas Am 08.09.2010 04:42, schrieb Teresa e Junior: Hello, GRUB developers! I'm fighting to replace isolinux with GRUB2 in the Live System I'm about to release. I already got the CD to boot with GRUB2, generating the ISO with grub-mkrescue. I think there must be some smarter way to do this, but I can't find out. But due to some features I need (not the eyecandy), I noticed the CD only boots without gfx support (which is the most important for me). I already tried using --modules="linux ext2 fshelp ls boot pc coreui vbe png jpeg gettext gfxmode" without any success. Tried some burg-mkisofs and xorriso commands, but I believe I miss something. Typing `configfile /grub.cfg' won't help either. Your help will be very appreciated, for we've been struggling for not a few hours! Teresa e Junior ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB2 fails when booting from CD
Am 08.09.2010 17:46, schrieb Colin Watson: On Wed, Sep 08, 2010 at 05:28:07PM +0200, Andreas Born wrote: - Starting Grub2 fails on my pretty new desktop (the only such report as far as I'm concerned) Fails how? After selecting to boot from cdrom in the bios it outputs the following: Welcome to GRUB! error: hd111 cannot get C/H/S values. Enetering rescue mode... grub rescue> Then I'm at the rescue prompt. The problem is reproducible with SalixLive or a minimal image I've created for testing purpose, but so far only on that one machine of mine. You can acquire the latter here: http://gaia.homelinux.org/misc/grub-test.iso (4.3M) I've experimented a bit with ls on the rescue prompt here's the output: > ls (hd0) > ls (hd0) error: unknown filesystem If you need anything else, just let me know and I'll try to do my best to help you. Regards, Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 fails when booting from CD
ping Am 08.09.2010 18:31, schrieb Andreas Born: Am 08.09.2010 17:46, schrieb Colin Watson: On Wed, Sep 08, 2010 at 05:28:07PM +0200, Andreas Born wrote: - Starting Grub2 fails on my pretty new desktop (the only such report as far as I'm concerned) Fails how? After selecting to boot from cdrom in the bios it outputs the following: Welcome to GRUB! error: hd111 cannot get C/H/S values. Enetering rescue mode... grub rescue> Then I'm at the rescue prompt. The problem is reproducible with SalixLive or a minimal image I've created for testing purpose, but so far only on that one machine of mine. You can acquire the latter here: http://gaia.homelinux.org/misc/grub-test.iso (4.3M) I've experimented a bit with ls on the rescue prompt here's the output: > ls (hd0) > ls (hd0) error: unknown filesystem If you need anything else, just let me know and I'll try to do my best to help you. Regards, Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 fails when booting from CD
Am 28.09.2010 20:11, schrieb Phillip Susi: On 9/28/2010 12:37 PM, Andreas Born wrote: If I understood that part about hd emulation right, that would mean the image wouldn't work on any machine? Or is it possible to switch dynamically with one single image between hd emulation and native el-torito? That's true, if that were the problem the image would not work on any machine. If it works on other machines, then it seems to be a problem with the bios. Output: grub rescue> set prefix=(hd111)/boot/grub/i386-pc/ root=hd111 The odd ( 111 ) hd number is a hint that the bios is broken. Does ls report any available drives? Maybe it is there, but the bios did not pass the correct number. Yes, as I wrote in my first mail: grub rescue> ls (hd0) grub rescue> ls (hd0) error: unknown filesystem Is there any way to clearly identify the BIOS as the culprit? Or maybe even a chance to implement a workardound at some point if it really is a problem with the BIOS? I guess the fact that I don't have such problems with isolinux can be explained with different use of BIOS functionality? I'm not asking because it were a serious problem for me. I'd just like to lower the probability that other users face unlike me a real problem. At least if it's possible with considerable effort. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 fails when booting from CD
Ok, here you go. I created the same iso image I referred to earlier in this thread with grub 1.98 and cdfailinf/cdfailwa patch applied. cdfailinf (broken machine): 0 0 0 cdfailinf (working machine): 0 0 9f cdfailwa brings up the menu on the broken machine and on another working machine, where I tested it too. Hope that helps. Regards, Andreas Am 25.12.2010 21:45, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: On 09/08/2010 06:31 PM, Andreas Born wrote: Am 08.09.2010 17:46, schrieb Colin Watson: On Wed, Sep 08, 2010 at 05:28:07PM +0200, Andreas Born wrote: - Starting Grub2 fails on my pretty new desktop (the only such report as far as I'm concerned) Fails how? After selecting to boot from cdrom in the bios it outputs the following: Welcome to GRUB! error: hd111 cannot get C/H/S values. Enetering rescue mode... grub rescue> Then I'm at the rescue prompt. Looks like your BIOS has problems with cd drive. I attach 2 patches. One to try to gather more info for better workaround and another one to basically ignore cdinfo altogether. Could you test them? The problem is reproducible with SalixLive or a minimal image I've created for testing purpose, but so far only on that one machine of mine. You can acquire the latter here: http://gaia.homelinux.org/misc/grub-test.iso (4.3M) I've experimented a bit with ls on the rescue prompt here's the output: ls (hd0) ls (hd0) error: unknown filesystem If you need anything else, just let me know and I'll try to do my best to help you. Regards, Andreas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Regarding ENV variable
I just quickly tested this behaviour with bash (and busybox). With neither of them I needed to use eval. Although eval could be a nice feature, it may be better to consider adapting to this seemingly common behaviour. Here's the output from bash: $ blub="blub1 blub2" $ touch $blub $ ls $blub blub1 blub2 $ Regards, Andreas - Ursprüngliche Mitteilung - > On Mon, Jan 03, 2011 at 07:08:51PM +0530, Gnanasekar Loganathan wrote: > > i'm setting environment variable by set mycmd="knetbsd netbsd.g" > > > > if call my own command, end up with no argument error. > > grub> myboot $mycmd > > myboot: usage knetbsd > > > > if do echo $mycmd, getting the correct string > > grub> echo $mycmd > > knetbsd netbsd.g > > > > if i directly run, throw unknown command > > grub>$mycmd > > error: unknown command `knetbsd netbsd.g'. > > > > How do i pass 2 arguments from single env variable or how to run the > > env as command? > > I don't think this is possible right now. We would need to have some > equivalent of the shell 'eval' builtin. The underlying pieces are > present (e.g. grub_script_execute_sourcecode) but aren't exposed in the > GRUB scripting interface. > > If you aren't able to add this extension to GRUB script yourself and > propose a patch, I suggest reworking your code in some other form. > > -- > Colin Watson > [cjwat...@ubuntu.com] > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Error: prefix not set
Hi, I think this is the issue described here: http://www.mail-archive.com/grub-devel@gnu.org/msg16839.html Regards, Andreas Am 20.06.2011 09:28, schrieb Yves Blusseau: Hi all, I see a message "prefix not set" when the grub kernel try to load the grub.cfg file and that the normal module is already include in core.img. I explain: the "normal" module is include in core.img by grub-mkimage because i add the "ls" module as module to add in core.img. When i start my PC the grub kernel is load normaly but when it switch to normal mode the error "prefix not set" is displayed on the screen. I have check and the prefix is good in the rescue shell and in normal mode. This message is only display if the normal module is include in core.img Regards, Yves Blusseau ___ 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: Loongson 2E boot failure
* Robert Millan (r...@gnu.org) [110811 19:10]:
> 2011/7/26 Colin Watson :
> >> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
> >> 8100-8200
> >
> > Sorry, I've not had to mess with this before. Can you point me to what
> > I'd need to change to hardcode a specific heap region?
>
> Try replacing grub_machine_mmap_iterate() with something like:
>
> grub_err_t
> grub_machine_mmap_iterate (grub_memory_hook_t hook)
> {
> hook (0x8100, 8200, GRUB_MEMORY_AVAILABLE);
> return GRUB_ERR_NONE;
> }
done so, but the failure is still the same. (I'm happy to try
different variants, but please tell me how I should produce them.)
Andi
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loongson 2E boot failure
* Vladimir 'φ-coder/phcoder' Serbinenko (phco...@gmail.com) [110812 15:15]:
> On 03.08.2011 13:21, Robert Millan wrote:
> > 2011/7/26 Colin Watson :
> >>> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
> >>> 8100-8200
> >> Sorry, I've not had to mess with this before. Can you point me to what
> >> I'd need to change to hardcode a specific heap region?
> > Try replacing grub_machine_mmap_iterate() with something like:
> >
> > grub_err_t
> > grub_machine_mmap_iterate (grub_memory_hook_t hook)
> > {
> > hook (0x8100, 8200, GRUB_MEMORY_AVAILABLE);
> > return GRUB_ERR_NONE;
> > }
> >
> This code is wrong for at least 4 reasons:
> 1) 0x8 is just to access kseg0, it's not part of physical address
> 2) second argument is a size, not end
> 3) and it's lacking 0x
> 4) on yeeloong memory init doesn't use mmap.
> Correct way is to replace:
> grub_mm_init_region ((void *) modend, (grub_arch_memsize << 20)
>- (modend - GRUB_ARCH_LOWMEMVSTART));
> with:
> grub_mm_init_region (0x8100, 16 << 20);
No real behaviour change - still fails within grub_font_init (using
the for(;;);-method).
Only change compared with
http://lists.gnu.org/archive/html/grub-devel/2011-07/msg00085.html is
that the last line on the vga console is now
80211ebc 7091181e .word 7091181e # ...p
Andi
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug] Wrong machtype argument passed for fuloong-2f
* David Kuehling (dvdkh...@gmx.de) [111029 11:37]: > according to my /proc/cmdline grub passes > machtype=lemote-fuloong-2f-unknown as first argument to the linux > kernel. Did you see any issues because of that in Linux? Fallback within linux is MACH_LEMOTE_FL2F which is the one used with the argument "lemote-fuloong-2f-box" (not saying this bug shouldn't be fixed, but ...). Also I think grub should just forward the parameters added by pmon, but not adding them itself (except for the parameters via the grub configuration, e.g. root=...). Andi ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug] Wrong machtype argument passed for fuloong-2f
* Vladimir 'φ-coder/phcoder' Serbinenko (phco...@gmail.com) [111029 12:42]: > On 29.10.2011 12:37, Andreas Barth wrote: > > * David Kuehling (dvdkh...@gmx.de) [111029 11:37]: > >> according to my /proc/cmdline grub passes > >> machtype=lemote-fuloong-2f-unknown as first argument to the linux > >> kernel. > > Did you see any issues because of that in Linux? Fallback within linux > > is MACH_LEMOTE_FL2F which is the one used with the argument > > "lemote-fuloong-2f-box" (not saying this bug shouldn't be fixed, but > > ...). Also I think grub should just forward the parameters added by > > pmon, but not adding them itself (except for the parameters via the > > grub configuration, e.g. root=...). > GRUB isn't restricted ot pmon environments so this argument makes little > sense to me. Isn't there a way to detect pmon environments in run time? Basically that's more like "is there a pmon configuration, and if so, just forward parameters"? I personally don't see how we could correctly find out the different variants the linux kernel detects without using the information the kernel uses, i.e. the command line. And if we use the command line, we could as well just forward it. (The optimal case would be device trees everywhere, but well. We are today.) Andi ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug] Wrong machtype argument passed for fuloong-2f
* David Kuehling (dvdkh...@gmx.de) [111029 13:43]: > I didn't find a method to make linux report the actual mach type that it > is running with, so I don't know what it fell back to, and I just went > the safe route of patching my version of grub. It's displayed as part of /proc/cpuinfo. Andi ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug] Wrong machtype argument passed for fuloong-2f
* Vladimir 'φ-coder/phcoder' Serbinenko (phco...@gmail.com) [111029 12:55]: > On 29.10.2011 12:45, Andreas Barth wrote: > > I personally don't see how we could correctly > > find out the different variants the linux kernel detects without using > > the information the kernel uses, i.e. the command line. And if we use > > the command line, we could as well just forward it. > Which creates a separate codepath uselessly. If GRUB is firmware it uses > the information available on mkimage time, if loaded by pmon or another > GRUB, use command line. I don't think we disagree here. Sorry if I wrote that wrong. Andi ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [bug] Wrong machtype argument passed for fuloong-2f
* David Kuehling (dvdkh...@gmx.de) [111029 22:46]: > BTW it looks like it is impossible to override machtype= parameter from > the kernel command line configured in boot/grub/grub.cfg, since linux > code in loongson/common/machtype.c uses the first occurence of > "machtype=" in arcs_cmdline[]. Is this behaviour by design or by > accident? Is this linux' fault or grub's fault? One could change grub > to append machtype= rather than prepend it to the command line... I would consider it more appropriate to add a flag "suppress pmon command line" to the grub configuration - if you want to overwrite it, it should fully disappear, and not just be not parsed because there is another one first. Andi ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Build failure: Error: attempt to move .org backwards
Hello, having trouble building the latest bzr 3757. This happens with gcc 4.5.2 on Salix/Slackware 13.37 x86_64 system, but doesn't happen with gcc 4.6.2 on Arch Linux x86_64. I also checked recent other reports of such problems, but wasn't able to find a solution. Here's some output: gcc -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3 -fno-builtin -m32 -Wl,--build-id=none -nostdlib -Wl,-N,-S -Wl,-N -Wl,-Ttext,0x6000 -o lnxboot.image boot/i386/pc/lnxboot_image-lnxboot.o gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -DGRUB_TARGET_CPU_I386=1 -m32 -nostdinc -isystem /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include -DGRUB_FILE=\"boot/i386/pc/startup_raw.S\" -I. -I. -I.. -I.. -I../include -I../include -g -m32 -DASM_FILE=1 -MT boot/i386/pc/lzma_decompress_image-startup_raw.o -MD -MP -MF boot/i386/pc/.deps-core/lzma_decompress_image-startup_raw.Tpo -c -o boot/i386/pc/lzma_decompress_image-startup_raw.o `test -f 'boot/i386/pc/startup_raw.S' || echo './'`boot/i386/pc/startup_raw.S reed_solomon.c: Assembler messages: reed_solomon.c:651: Warning: ignoring changed section attributes for .text boot/i386/pc/startup_raw.S:119: Error: attempt to move .org backwards make[3]: *** [boot/i386/pc/lzma_decompress_image-startup_raw.o] Fehler 1 make[3]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build/grub-core' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build/grub-core' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build' make: *** [all] Fehler 2 Regards, Andreas Born ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build failure: Error: attempt to move .org backwards
Yes, that's exactly what I tried, but apparently it doesn't work. The lowest working value is 0x800 here. So gcc 4.5 seems to be worse than 4.4 and 4.6 better than both. Andreas Am 18.01.2012 23:53, schrieb Seth Goldberg: Hi, Yes, I'm seeing that also. I guess version 4.5.2 of the compiler just isn't as efficient as the most-recent GCC. I edited include/grub/offsets.h: And changed: #define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x7e0 To: #define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x7f0 And that was enough. phcoder posted to this list not-too-long-ago with that suggestion for another person as well. He said you can increase it as long as you don't do it too much and as long as the value is divisible by 8. --S Quoting Andreas Born, who wrote the following on Wed, 18 Jan 2012: Hello, having trouble building the latest bzr 3757. This happens with gcc 4.5.2 on Salix/Slackware 13.37 x86_64 system, but doesn't happen with gcc 4.6.2 on Arch Linux x86_64. I also checked recent other reports of such problems, but wasn't able to find a solution. Here's some output: gcc -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3 -fno-builtin -m32 -Wl,--build-id=none -nostdlib -Wl,-N,-S -Wl,-N -Wl,-Ttext,0x6000 -o lnxboot.image boot/i386/pc/lnxboot_image-lnxboot.o gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -DGRUB_TARGET_CPU_I386=1 -m32 -nostdinc -isystem /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include -DGRUB_FILE=\"boot/i386/pc/startup_raw.S\" -I. -I. -I.. -I.. -I../include -I../include -g -m32 -DASM_FILE=1 -MT boot/i386/pc/lzma_decompress_image-startup_raw.o -MD -MP -MF boot/i386/pc/.deps-core/lzma_decompress_image-startup_raw.Tpo -c -o boot/i386/pc/lzma_decompress_image-startup_raw.o `test -f 'boot/i386/pc/startup_raw.S' || echo './'`boot/i386/pc/startup_raw.S reed_solomon.c: Assembler messages: reed_solomon.c:651: Warning: ignoring changed section attributes for .text boot/i386/pc/startup_raw.S:119: Error: attempt to move .org backwards make[3]: *** [boot/i386/pc/lzma_decompress_image-startup_raw.o] Fehler 1 make[3]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build/grub-core' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build/grub-core' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build' make: *** [all] Fehler 2 Regards, Andreas Born ___ 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build failure: Error: attempt to move .org backwards
Yes, I'm going to try that. Just test booted an iso image with qemu and with 0x800 and that fails printing garbage to the screen. So probably that's too big. Andreas Am 19.01.2012 00:47, schrieb Seth Goldberg: Hi, I should also mention that I ifdef'ed out the reed-solomon add redundancy stuff in grub-setup (since it was causing me problems I haven't had time to identify). You may want to try that also -- make sure you ifdef out the code that sets the redundancy size also, otherwise, you're going to crash. --S Quoting Andreas Born, who wrote the following on Thu, 19 Jan 2012: Yes, that's exactly what I tried, but apparently it doesn't work. The lowest working value is 0x800 here. So gcc 4.5 seems to be worse than 4.4 and 4.6 better than both. Andreas Am 18.01.2012 23:53, schrieb Seth Goldberg: Hi, Yes, I'm seeing that also. I guess version 4.5.2 of the compiler just isn't as efficient as the most-recent GCC. I edited include/grub/offsets.h: And changed: #define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x7e0 To: #define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x7f0 And that was enough. phcoder posted to this list not-too-long-ago with that suggestion for another person as well. He said you can increase it as long as you don't do it too much and as long as the value is divisible by 8. --S Quoting Andreas Born, who wrote the following on Wed, 18 Jan 2012: Hello, having trouble building the latest bzr 3757. This happens with gcc 4.5.2 on Salix/Slackware 13.37 x86_64 system, but doesn't happen with gcc 4.6.2 on Arch Linux x86_64. I also checked recent other reports of such problems, but wasn't able to find a solution. Here's some output: gcc -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3 -fno-builtin -m32 -Wl,--build-id=none -nostdlib -Wl,-N,-S -Wl,-N -Wl,-Ttext,0x6000 -o lnxboot.image boot/i386/pc/lnxboot_image-lnxboot.o gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -DGRUB_TARGET_CPU_I386=1 -m32 -nostdinc -isystem /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include -DGRUB_FILE=\"boot/i386/pc/startup_raw.S\" -I. -I. -I.. -I.. -I../include -I../include -g -m32 -DASM_FILE=1 -MT boot/i386/pc/lzma_decompress_image-startup_raw.o -MD -MP -MF boot/i386/pc/.deps-core/lzma_decompress_image-startup_raw.Tpo -c -o boot/i386/pc/lzma_decompress_image-startup_raw.o `test -f 'boot/i386/pc/startup_raw.S' || echo './'`boot/i386/pc/startup_raw.S reed_solomon.c: Assembler messages: reed_solomon.c:651: Warning: ignoring changed section attributes for .text boot/i386/pc/startup_raw.S:119: Error: attempt to move .org backwards make[3]: *** [boot/i386/pc/lzma_decompress_image-startup_raw.o] Fehler 1 make[3]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build/grub-core' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build/grub-core' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/shador/projects/checkouts/grub/branches/build' make: *** [all] Fehler 2 Regards, Andreas Born ___ 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 ___ 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext in scripts
Hi, this is a great feature! Our LiveCD project (Salix Live) uses grub as bootloader and we offer a localized boot menu, which is - at least last time I checked - roughly implemented like SGD's localization. So not only SGD could benefit from such an infrastructure and this is something we've been looking for since the very beginning. Am 10.02.2012 23:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: Hello, all. It was requested to have a way to gettextize Super GRUB disk. Original request was to extend gettext with -s options but it may result in a mess to temporary variables. So I'd propose to rather use $"..." syntax with the exception that we don't expand it after translation to avoid some pitfalls. Sharing syntax with bash will allow to use normal xgettext --language=Shell. The real problem is as to how to include SGD strings in grub.pot. I see following solutions: 1) Merge projects and put SGD inside GRUB2. It's possible if its authors want it but many more questions would need to be discussed. 2) Import sgd.pot into grub.pot regularly. This creates an administrative overhead and requires GRUB and scripts to have matching versions. I don't know if it's easy to merge .pot files 3) Just have a few strings for usage by external projects. This would heavily limit the extent of internationalisation and would result in a lot of feature requests one after another for this or that string. Those solutions would only allow SGD to offer localization. Except maybe 3, but I'd say that one is of very limited use and irrealistic especially regarding the maintenance for grub. 4) Have some way to load .mo from another directory. Perhaps something like locale_dirs=$dir1:$dir2:$dir3. This creates some problems as to how and when to load files and how to store them. The easiest way consisting of having multiple opened gettext files and try each of it in turn. Trouble is that then when adding a single directory we need to either reload all files or compare the previous list with current to reload only changed directories. That sounds like a much better idea as other projects could also use localization without increasing the workload for grub. Actually this looks like my favorite now. What do you think would be the perfomance/speed penalty regarding loading of the directories and accessing a translation? I think for common use cases it would be enough to add additionally to the already implemented locale_dir=$dir1 a second environment variable like additional_locale_dir=$dir2. That would overcome the problem of reloading all directories/ comparing lists. It offers less flexibility, but a too long list of files to search would probably have a negative performance penalty anyway. Any other ideas? Similarly to 2, but the other way round: 5) Import grub.pot to sgd.pot (or whatever other project). This is probably the easiest solution for grub with no additional workload. Regarding projects building on grub this is not a perfect solution and makes it harder to use such functionality. But it would be already a great step forward and the maintenance burden for other projects is by far not irrealistic. Given an easy-to-use, suitable and efficient tool (maybe already existent?) this solution is more than acceptable. Still solution 4 seems way cleaner to me as it separates the strings of grub and other projects, which I imagine could be better in the one or other situation. Specifically there could be problems when a user runs grub-install or equivalent and thus overwrites the .mo files with a different version. Or multiple projects each with its own translation could use the same grub installation. Andreas ___ 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
[Q] Indentation rules for GRUB source code
I tried to find all relevant docs and read what I've found (e.g. grub-dev.texi), so please excuse me if this questions has been already answered somewhere. I would like to change and submit code for GRUB and from what i see right now indentation of the code doesn't seem to follow any rules. Most of the time the visible indentation is 2 spaces which is either achieved by using a TAB (which needs that the editor is configured to show TABs as 2 spaces) or it's done by just using 2 spaces. Regarding to what code I've seen until now, the indentation of quite a lot of code is messed up and makes reading more difficult. What are the preferred rules to follow when submitting changes or new code regarding indentation? BTW, it might be a good idea to propose the TAB setting configurations for the most popular editors, e.g. I'm using vim right now. Andreas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Q] Indentation rules for GRUB source code
Thanks for clarification and the pointer to GCS. Just for reference: the appropriate indentation setting for VIM is set tabstop=8 softtabstop=2 shiftwidth=2 noexpandtab so that indentation is 2 spaces and each bunch of 8 spaces will be converted into a TAB char. Andreas Am 01.03.2012 13:25, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > On 01.03.2012 13:09, Andreas Vogel wrote: >> I tried to find all relevant docs and read what I've found (e.g. >> grub-dev.texi), so please excuse me if this questions has been already >> answered somewhere. >> >> I would like to change and submit code for GRUB and from what i see >> right now indentation of the code doesn't seem to follow any rules. Most >> of the time the visible indentation is 2 spaces which is either achieved >> by using a TAB (which needs that the editor is configured to show TABs >> as 2 spaces) or it's done by just using 2 spaces. > We use GNU identation as described in GCS > (http://www.gnu.org/prep/standards/) > and as is the default in emacs and "indent" except some imported code > which may follow other modes for practical reasons >> >> Regarding to what code I've seen until now, the indentation of quite a >> lot of code is messed up and makes reading more difficult. > Displays fine here in emacs >> What are the preferred rules to follow when submitting changes or new >> code regarding indentation? > Run indent on all new code. >> >> BTW, it might be a good idea to propose the TAB setting configurations >> for the most popular editors, e.g. I'm using vim right now. > it's the standard GNU one. >> Andreas >> >> ___ >> 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: Device instability, gettext and default
Vladimir, this enhancement is part of my patches which i sent some days ago. I introduced an option "--label STRING" which will be used for display if it's set and which can also have environment variables (another part of my patches). It's just a matter of taste though if to use a new option --id for an invariant menu id or to use the actual menuentry title as the invariant id and to have a new option --label for the display string. Both ways provide backward compatibility. BTW, I just wonder a little that you refused my enhancements due to code freeze but are now enhancing anyway ;-) Andreas Am 03.03.2012 14:37, schrieb Vladimir '?-coder/phcoder' Serbinenko: > Hello, all. Currently we use and recommend using the title for default > variable. It has however following problems: > 1) When device names change the title changes (because of the "(on > $device)" part) > 2) If user changes locale the part ", with" gets translated and again > the title changes > Attached patch changes it to the use of IDs specified by --id but > keeps title possiblity for backward compatibility. Any comments? > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel -- Andreas Vogel Dipl.-Inform. Hellerweg 60 73728 Esslingen Germany E-Mail: andreas.vo...@anvo-it.de Office: +49 (711) 937 1742 FAX: +49 (711) 937 1745 Mobile: +49 (172) 730 7440 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: default menuentry matching similar entries is broken
> Hi,
>
> This code in menu.c::menuentry_eq() looks wrong:
>
> {
> const char *ptr1, *ptr2;
> ptr1 = title;
> ptr2 = spec;
> while (1)
> {
> if (*ptr2 == '>' && ptr2[1] != '>' && *ptr1 == 0)
> return 1;
> if (*ptr2 == '>' && ptr2[1] != '>')
> return 0;
> if (*ptr2 == '>')
> ptr2++;
> if (*ptr1 != *ptr2)
> return 0;
> if (*ptr1 == 0) <
> return 1;
> ptr1++;
> ptr2++;
> }
> }
>
>
> Specifically, if there are two menuentries that differ by adding
> characters, this function will match the wrong one, i.e.:
>
> set default='entry a with more words'
>
> menuentry "entry a" {
> }
>
> menuentry "entry a with more words" {
> }
As far as I understand the code, using submenu references in the default
variable for automatic booting is not working at all.
This is due to the dynamic loading of submenus. When a menu is opened
and run, only the direct menu entries are known. Searching for menu
entries deeper in the menu tree is not done.
Let's consider this scenario:
set default="b>c>c1"
menuentry a { ... }
submenu b {
submenu c {
menuentry c1 { ... }
}
}
When the toplevel menu is run, the code just knows about entries a and b
(entries c and c1 are not know at this moment).
Searching and booting the menu entry according to the default variable
doesn't work. Actually I didn't try this, that's just from code reading
so i might be wrong.
IMHO, right now the menuentry_eq() function is overkill as a normal
strcmp() would be sufficient.
Furthermore it's strange that calling
menuentry_eq ("a>b", "a>b")
returns 0. I didn't expect this result.
Andreas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: default menuentry matching similar entries is broken
Am 03.03.2012 19:20, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 03.03.2012 19:10, Andreas Vogel wrote:
>>> Hi,
>>>
>>>This code in menu.c::menuentry_eq() looks wrong:
>>>
>>> {
>>>const char *ptr1, *ptr2;
>>>ptr1 = title;
>>>ptr2 = spec;
>>>while (1)
>>> {
>>>if (*ptr2 == '>'&& ptr2[1] != '>'&& *ptr1 == 0)
>>> return 1;
>>>if (*ptr2 == '>'&& ptr2[1] != '>')
>>> return 0;
>>>if (*ptr2 == '>')
>>> ptr2++;
>>>if (*ptr1 != *ptr2)
>>> return 0;
>>>if (*ptr1 == 0)<
>>> return 1;
>>>ptr1++;
>>>ptr2++;
>>> }
>>> }
>>>
>>>
>>>Specifically, if there are two menuentries that differ by adding
>>> characters, this function will match the wrong one, i.e.:
>>>
>>> set default='entry a with more words'
>>>
>>> menuentry "entry a" {
>>> }
>>>
>>> menuentry "entry a with more words" {
>>> }
>> As far as I understand the code, using submenu references in the default
>> variable for automatic booting is not working at all.
>> This is due to the dynamic loading of submenus. When a menu is opened
>> and run, only the direct menu entries are known. Searching for menu
>> entries deeper in the menu tree is not done.
> No need. When timeout is reached the submenu is executed and first
> element is discarded and the rest is searched for again.
>
I'm sorry... and you're right! Actually the code was too obfuscated for
me...
BTW, one of the features which are missing and about what i read in
different forums is that it's not possible to reference entries in the
menu tree by number, e.g. "0>2>4>2". By reading the code i would say
it's not possible, but after my failure right now, I better ask :-)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: default menuentry matching similar entries is broken
>> BTW, one of the features which are missing and about what i read in >> different forums is that it's not possible to reference entries in the >> menu tree by number, e.g. "0>2>4>2". > > This should work but isn't recommended if it doesn't please supply a > testcase or a fix. > > Just to let you know: I created a quite complicated testcase with 4 submenus and it works! ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Device instability, gettext and default
I was thinking about your proposal again and I think your idea introducing a --id option is better than my idea having a --label option. > === modified file 'include/grub/menu.h' > --- include/grub/menu.h 2011-01-10 22:27:58 + > +++ include/grub/menu.h 2012-03-03 12:11:30 + > @@ -32,6 +32,9 @@ >/* The title name. */ >const char *title; > > + /* The identifier. */ > + const char *id; > + >/* If set means not everybody is allowed to boot this entry. */ >int restricted; > Why are all the string variables declared as "const char *"? In my opinion the const qualifier is not useful/needed. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Device instability, gettext and default
> + menu_id = grub_strdup (id ? : menu_title); I don't know about the policy for grub code regarding GNU compiler extensions... at least you don't need in this place. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Enhanced hotkey handling for menuentry
Here is a small patch which enhances the hotkey handling for menu entries.
- new static function parse_key()
- hotkey aliases are now case insensitive
- additional hotkey aliases
- handling now and modifiers for hotkeys
Any chance that this is included (Vladimir: taking into account that
might do some work in these area anyway)? Any comments?
Andreas
revno: 4098
committer: Andreas Vogel
branch nick: 01-menuentry_enhanced_hotkeys
timestamp: Thu 2012-03-01 22:38:32 +0100
message:
* grub-core/commands/menuentry.c: enhanced hotkey handling:
- new static function parse_key()
- hotkey aliases are now case insensitive
- additional hotkey aliases
- handling now and modifiers for hotkeys
diff:
=== modified file 'grub-core/commands/menuentry.c'
--- grub-core/commands/menuentry.c 2012-02-26 16:28:05 +
+++ grub-core/commands/menuentry.c 2012-03-01 21:38:32 +
@@ -45,24 +45,110 @@
int key;
} hotkey_aliases[] =
{
-{"backspace", '\b'},
-{"tab", '\t'},
-{"delete", GRUB_TERM_KEY_DC},
-{"insert", GRUB_TERM_KEY_INSERT},
-{"f1", GRUB_TERM_KEY_F1},
-{"f2", GRUB_TERM_KEY_F2},
-{"f3", GRUB_TERM_KEY_F3},
-{"f4", GRUB_TERM_KEY_F4},
-{"f5", GRUB_TERM_KEY_F5},
-{"f6", GRUB_TERM_KEY_F6},
-{"f7", GRUB_TERM_KEY_F7},
-{"f8", GRUB_TERM_KEY_F8},
-{"f9", GRUB_TERM_KEY_F9},
-{"f10", GRUB_TERM_KEY_F10},
-{"f11", GRUB_TERM_KEY_F11},
-{"f12", GRUB_TERM_KEY_F12},
+{ "backspace", '\b'},
+{ "tab", '\t'},
+{ "delete",GRUB_TERM_KEY_DC },
+{ "insert",GRUB_TERM_KEY_INSERT },
+{ "up",GRUB_TERM_KEY_UP },
+{ "down", GRUB_TERM_KEY_DOWN },
+{ "left", GRUB_TERM_KEY_LEFT },
+{ "right", GRUB_TERM_KEY_RIGHT },
+{ "prev", GRUB_TERM_KEY_PPAGE },
+{ "next", GRUB_TERM_KEY_NPAGE },
+{ "home", GRUB_TERM_KEY_HOME },
+{ "end", GRUB_TERM_KEY_END },
+{ "f1",GRUB_TERM_KEY_F1 },
+{ "f2",GRUB_TERM_KEY_F2 },
+{ "f3",GRUB_TERM_KEY_F3 },
+{ "f4",GRUB_TERM_KEY_F4 },
+{ "f5",GRUB_TERM_KEY_F5 },
+{ "f6",GRUB_TERM_KEY_F6 },
+{ "f7",GRUB_TERM_KEY_F7 },
+{ "f8",GRUB_TERM_KEY_F8 },
+{ "f9",GRUB_TERM_KEY_F9 },
+{ "f10", GRUB_TERM_KEY_F10 },
+{ "f11", GRUB_TERM_KEY_F11 },
+{ "f12", GRUB_TERM_KEY_F12 },
};
+
+/* Parse the given string and return a GRUB_TERM key.
+ The given string can be one of the predefined key names (aliases),
+ otherwise the first character of the given str is taken as key.
+ Modifiers like "" or "" are handled. They may appear
+ in any order but need to be in front of the alias or key.
+ Spaces between the modifiers and key are silently ignored.
+ Comparison with alias names is case independent. */
+
+static int
+parse_key (const char *string)
+{
+ char *str, *ptr, *keystr;
+ int key = 0;
+ int i;
+
+ if (string == 0 || *string == 0)
+return 0;
+
+ str = grub_strdup (string);
+ if (!str)
+return 0;
+
+#define STRING_CTRL ""
+#define STRING_SHIFT ""
+
+ /* check for CTRL modifier */
+ ptr = grub_strstr (str, STRING_CTRL);
+ if (ptr)
+ {
+/* replace modifier string with spaces */
+for (i = 0; i < grub_strlen (STRING_CTRL); i++)
+ *(ptr + i) = ' ';
+key |= GRUB_TERM_CTRL;
+ }
+
+ /* check for SHIFT modifier */
+ ptr = grub_strstr (str, STRING_SHIFT);
+ if (ptr)
+ {
+/* replace modifier string with spaces */
+for (i = 0; i < grub_strlen (STRING_SHIFT); i++)
+ *(ptr + i) = ' ';
+key |= GRUB_TERM_SHIFT;
+ }
+
+ /* remove/zero trailing spaces */
+ for (ptr = str + grub_strlen (str) - 1; ptr >= str && *ptr == ' '; ptr--)
+ *ptr = 0;
+
+ /* skip leading spaces */
+ for (ptr = str; *ptr == ' '; ptr++) /*NOTHING*/;
+
+ /* the remaining chars are the real key string */
+ keystr = ptr;
+
+ /* check if the key string is an alias name */
+ for (i = 0; i < ARRAY_SIZE (hotkey_aliases); i++)
+ {
+/* case is not significant for key aliases */
+if (grub_strcasecmp (keystr, hotkey_aliases[i].name) == 0)
+{
+ key |= hotkey_aliases[i].key;
+ break;
+}
+ }
+
+ if (i == ARRAY_SIZE (hotkey_aliases))
+ {
+/* no alias matched, so use the first char in
[PATCH] Using enum symbols as indices into menuentry options
Here is another tiny patch which uses a enum to reference the options
array when dealing with command line options for a menuentry.
This method is already used by some other modules. I have some more
patches which are adding more options for the menuentry command so
finally readabilty will be improved using these symbols.
Any comments?
Andreas
revno: 4099
committer: Andreas Vogel
branch nick: 02-menuentry_options_enum
timestamp: Thu 2012-03-01 22:40:25 +0100
message:
* grub-core/commands/menuentry.c: use enum symbols for indexing
the options array in order to improve readability
diff:
=== modified file 'grub-core/commands/menuentry.c'
--- grub-core/commands/menuentry.c 2012-03-01 21:38:32 +
+++ grub-core/commands/menuentry.c 2012-03-01 21:40:25 +
@@ -25,6 +25,14 @@
#include
#include
+enum options
+ {
+O_CLASS = 0,
+O_USERS,
+O_HOTKEY,
+O_SOURCE,
+ };
+
static const struct grub_arg_option options[] =
{
{"class", 1, GRUB_ARG_OPTION_REPEATABLE,
@@ -324,18 +332,18 @@
if (! argc)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "missing arguments");
- if (ctxt->state[3].set && ctxt->script)
+ if (ctxt->state[O_SOURCE].set && ctxt->script)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "multiple menuentry
definitions");
- if (! ctxt->state[3].set && ! ctxt->script)
+ if (! ctxt->state[O_SOURCE].set && ! ctxt->script)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "no menuentry definition");
if (! ctxt->script)
return grub_normal_add_menu_entry (argc, (const char **) args,
- (ctxt->state[0].set ? ctxt->state[0].args
- : NULL), ctxt->state[1].arg,
- ctxt->state[2].arg, 0,
- ctxt->state[3].arg,
+ (ctxt->state[O_CLASS].set ?
ctxt->state[O_CLASS].args
+ : NULL), ctxt->state[O_USERS].arg,
+ ctxt->state[O_HOTKEY].arg, 0,
+ ctxt->state[O_SOURCE].arg,
ctxt->extcmd->cmd->name[0] == 's');
src = args[argc - 1];
@@ -350,8 +358,8 @@
return grub_errno;
r = grub_normal_add_menu_entry (argc - 1, (const char **) args,
- ctxt->state[0].args, ctxt->state[1].arg,
- ctxt->state[2].arg, prefix, src + 1,
+ ctxt->state[O_CLASS].args,
ctxt->state[O_USERS].arg,
+ ctxt->state[O_HOTKEY].arg, prefix, src + 1,
ctxt->extcmd->cmd->name[0] == 's');
src[len - 1] = ch;
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Enabling short options for menuentry command
This tiny patch enables short command line options for the
menuentry/submenu command.
Any comments?
Andreas
revno: 4100
committer: Andreas Vogel
branch nick: 03-menuentry_short_options
timestamp: Thu 2012-03-01 22:42:05 +0100
message:
* grub-core/commands/menuentry.c: also provide short options
for menuentry/submenu command
diff:
=== modified file 'grub-core/commands/menuentry.c'
--- grub-core/commands/menuentry.c 2012-03-01 21:40:25 +
+++ grub-core/commands/menuentry.c 2012-03-01 21:42:05 +
@@ -35,14 +35,14 @@
static const struct grub_arg_option options[] =
{
-{"class", 1, GRUB_ARG_OPTION_REPEATABLE,
+{"class", 'c', GRUB_ARG_OPTION_REPEATABLE,
N_("Menu entry type."), N_("STRING"), ARG_TYPE_STRING},
-{"users", 2, 0,
+{"users", 'u', 0,
N_("List of users allowed to boot this entry."),
N_("USERNAME[,USERNAME]"),
ARG_TYPE_STRING},
-{"hotkey", 3, 0,
+{"hotkey", 'h', 0,
N_("Keyboard key to quickly boot this entry."), N_("KEYBOARD_KEY"),
ARG_TYPE_STRING},
-{"source", 4, 0,
+{"source", 's', 0,
N_("Use STRING as menu entry body."), N_("STRING"), ARG_TYPE_STRING},
{0, 0, 0, 0, 0, 0}
};
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Enhanced hotkey handling for menuentry
> On 03.03.2012 21:43, Andreas Vogel wrote: >> Here is a small patch which enhances the hotkey handling for menu >> entries. > Could you use GNU style? You miss the spaces before braces. Sure. Missed by accident. > Comments have to be full sentences, start with uppercase and end with > a dot followed by 2 spaces. Wow... ok. > Comment /*NOTHING*/ is not useful. I disagree, because it's more clear that this is an intentionally left empty body. But it's a matter of taste and I obey. >> - new static function parse_key() >> - hotkey aliases are now case insensitive >> - additional hotkey aliases > All added aliases conflict with normal function of these keys (arrows > and pages) Yes, I know. But it doesn't harm anyway and it might be useful to have the code already in case the use of the keys change in the future. Anyway, if you insist of leaving them out i'll obey. >> - handling now and modifiers for hotkeys > Could you change to the emacs notation? What is the emacs notation? I have no idea. > Shift flag isn't valid with alphanumeric keys. Ah, ok. Am I right that it's enough just not to set the SHIFT mask in case isalnum() is true? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Using enum symbols as indices into menuentry options
> Keep list CC'ed.
> On 03.03.2012 22:13, Andreas Vogel wrote:
>>> On 03.03.2012 21:50, Andreas Vogel wrote:
>>>> +enum options
>>>> + {
>>> Please don't define a type here, especially that a type "options" can
>>> easily conflict with something else.
>>>
>> I reused that idea from commands/search_wrap.c and basically i liked
>> that idea.
> Just use an anonymous enum.
>
Please find attached the corrected patch using an anonymous enum.
=== modified file 'grub-core/commands/menuentry.c'
--- grub-core/commands/menuentry.c 2012-03-01 21:38:32 +
+++ grub-core/commands/menuentry.c 2012-03-02 21:46:55 +
@@ -25,6 +25,14 @@
#include
#include
+enum
+ {
+O_CLASS = 0,
+O_USERS,
+O_HOTKEY,
+O_SOURCE,
+ };
+
static const struct grub_arg_option options[] =
{
{"class", 1, GRUB_ARG_OPTION_REPEATABLE,
@@ -324,18 +332,18 @@
if (! argc)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "missing arguments");
- if (ctxt->state[3].set && ctxt->script)
+ if (ctxt->state[O_SOURCE].set && ctxt->script)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "multiple menuentry
definitions");
- if (! ctxt->state[3].set && ! ctxt->script)
+ if (! ctxt->state[O_SOURCE].set && ! ctxt->script)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "no menuentry definition");
if (! ctxt->script)
return grub_normal_add_menu_entry (argc, (const char **) args,
- (ctxt->state[0].set ? ctxt->state[0].args
- : NULL), ctxt->state[1].arg,
- ctxt->state[2].arg, 0,
- ctxt->state[3].arg,
+ (ctxt->state[O_CLASS].set ?
ctxt->state[O_CLASS].args
+ : NULL), ctxt->state[O_USERS].arg,
+ ctxt->state[O_HOTKEY].arg, 0,
+ ctxt->state[O_SOURCE].arg,
ctxt->extcmd->cmd->name[0] == 's');
src = args[argc - 1];
@@ -350,8 +358,8 @@
return grub_errno;
r = grub_normal_add_menu_entry (argc - 1, (const char **) args,
- ctxt->state[0].args, ctxt->state[1].arg,
- ctxt->state[2].arg, prefix, src + 1,
+ ctxt->state[O_CLASS].args,
ctxt->state[O_USERS].arg,
+ ctxt->state[O_HOTKEY].arg, prefix, src + 1,
ctxt->extcmd->cmd->name[0] == 's');
src[len - 1] = ch;
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Enhanced hotkey handling for menuentry
Am 03.03.2012 22:30, schrieb Andreas Vogel: >>> - new static function parse_key() >>> - hotkey aliases are now case insensitive >>> - additional hotkey aliases >> All added aliases conflict with normal function of these keys (arrows >> and pages) > Yes, I know. But it doesn't harm anyway and it might be useful to have > the code already in case the use of the keys change in the future. > Anyway, if you insist of leaving them out i'll obey. Thought about it again: when being now able to use modifiers ALT, CTRL and SHIFT, using the keys which have a already defined function (like arrows and pages) doesn't conflict. Even though e.g. KEY_UP is already used in menu I would like to be able to use SHIFT-UP as a hotkey. So in my opinion the hotkey parse function should handle all possible keys. >>> - handling now and modifiers for hotkeys >> Could you change to the emacs notation? > What is the emacs notation? I have no idea. I did a search and from what I've seen I assume you mean to use the following: - "C-" for CTRL - "A-" for ALT (even though emacs seems to use "M-" for ALT on most system) - "S-" for SHIFT (emacs doesn't seem to have any notion for SHIFT, but here we would need it) Using this notion valid hotkeys could be e.g. "C-F1", "C-S-F1" and "C-A-S-F1". The order of the modifiers are not significant so "C-A-S-F1" == "S-A-C-F1". Any comments? Please advise. >> Shift flag isn't valid with alphanumeric keys. > Ah, ok. Am I right that it's enough just not to set the SHIFT mask in > case isalnum() is true? Right now I don't fully understand the way GRUB key handling works in detail regarding modifiers. Form what I've learned until now it seems to be like this: - all alphanumeric keys never have the SHIFT modifier set - all keys having a #define GRUB_TERM_KEY_* all modifiers (CTRL, ALT, SHIFT) are possible - I'm not sure about GRUB_TER_BACKSPACE, GRUB_TERM_TAB and GRUB_TERM_ESC. What modifiers are allowed for them? BTW about using isalnum(): couldn't find any GRUB replacement. Is it save to include and use those functions? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Making exported variables really global
Hi all,
This tiny patch makes exported variables really global. Right now
exported variables are set in the context of a submenu when running it.
But any changes to those vars are lost when leaving the submenu. This
patch sets and exports all vars in the calling context for the submenu
which are exported in the context of the submenu.
This feature is needed in order to have submenus implementing something
like setting boot options like boot params, language setttings and the
like using environment variables.
Any comments? If it's OK any chance to be included?
Andreas
=== modified file 'grub-core/normal/context.c'
--- grub-core/normal/context.c 2012-03-01 21:43:03 +
+++ grub-core/normal/context.c 2012-03-04 13:51:28 +
@@ -126,6 +126,20 @@
for (p = grub_current_context->vars[i]; p; p = q)
{
+ if (p->global)
+ {
+ /* Set and export all global variables inside
+the calling/previous context. */
+ struct grub_env_context *tmp_context = grub_current_context;
+ grub_current_context = grub_current_context->prev;
+ if (grub_env_set (p->name, p->value) == GRUB_ERR_NONE)
+ {
+ grub_env_export (p->name);
+ grub_register_variable_hook (p->name, p->read_hook,
p->write_hook);
+ }
+ grub_current_context = tmp_context;
+ }
+
q = p->next;
grub_free (p->name);
grub_free (p->value);
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Making exported variables really global
Am 04.03.2012 14:18, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > On 04.03.2012 14:08, Andreas Vogel wrote: >> Hi all, >> >> This tiny patch makes exported variables really global. Right now >> exported variables are set in the context of a submenu when running it. >> But any changes to those vars are lost when leaving the submenu. This >> patch sets and exports all vars in the calling context for the submenu >> which are exported in the context of the submenu. > We follow the bash behaviour. And the bash behaviour is exactly what > GRUB does: > phcoder@debian.x201.phnet:14:15:11:~/grub2/bzr/mainline$ bash > phcoder@debian.x201.phnet:14:15:15:~/grub2/bzr/mainline$ export XYZ=x > phcoder@debian.x201.phnet:14:15:19:~/grub2/bzr/mainline$ exit > phcoder@debian.x201.phnet:14:15:20:~/grub2/bzr/mainline$ echo $XYZ > > phcoder@debian.x201.phnet:14:15:24:~/grub2/bzr/mainline$ > I understand your point, but IMHO we do need to be able to set global vars in submenus, that's my patch about. Otherwise how can you use a "Settings..." submenu to configure environment variables which are used by other menu entries for booting? The analogy with bash is not useful here. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Making exported variables really global
Am 04.03.2012 15:10, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > On 04.03.2012 14:47, Andreas Vogel wrote: >> Am 04.03.2012 14:18, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >>> On 04.03.2012 14:08, Andreas Vogel wrote: >>>> Hi all, >>>> >>>> This tiny patch makes exported variables really global. Right now >>>> exported variables are set in the context of a submenu when running >>>> it. >>>> But any changes to those vars are lost when leaving the submenu. This >>>> patch sets and exports all vars in the calling context for the submenu >>>> which are exported in the context of the submenu. >>> We follow the bash behaviour. And the bash behaviour is exactly what >>> GRUB does: >>> phcoder@debian.x201.phnet:14:15:11:~/grub2/bzr/mainline$ bash >>> phcoder@debian.x201.phnet:14:15:15:~/grub2/bzr/mainline$ export XYZ=x >>> phcoder@debian.x201.phnet:14:15:19:~/grub2/bzr/mainline$ exit >>> phcoder@debian.x201.phnet:14:15:20:~/grub2/bzr/mainline$ echo $XYZ >>> >>> phcoder@debian.x201.phnet:14:15:24:~/grub2/bzr/mainline$ >>> >> I understand your point, but IMHO we do need to be able to set global >> vars in submenus, that's my patch about. >> >> Otherwise how can you use a "Settings..." submenu to configure >> environment variables which are used by other menu entries for booting? >> The analogy with bash is not useful here. > We can add a command with traits of both "menuentry" (same context, > same menu) and "submenu" (new context, new menu), sth like > submemu_source (same context, new menu) Yes, that's one possible solution. Why establishing a new command instead of using an option for submenu, let's say "--export 0|1"? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Making exported variables really global
Am 04.03.2012 17:16, schrieb Andreas Vogel: > Am 04.03.2012 15:10, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >> On 04.03.2012 14:47, Andreas Vogel wrote: >>> Am 04.03.2012 14:18, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >>>> On 04.03.2012 14:08, Andreas Vogel wrote: >>>>> Hi all, >>>>> >>>>> This tiny patch makes exported variables really global. Right now >>>>> exported variables are set in the context of a submenu when running >>>>> it. >>>>> But any changes to those vars are lost when leaving the submenu. This >>>>> patch sets and exports all vars in the calling context for the submenu >>>>> which are exported in the context of the submenu. >>>> We follow the bash behaviour. And the bash behaviour is exactly what >>>> GRUB does: >>>> phcoder@debian.x201.phnet:14:15:11:~/grub2/bzr/mainline$ bash >>>> phcoder@debian.x201.phnet:14:15:15:~/grub2/bzr/mainline$ export XYZ=x >>>> phcoder@debian.x201.phnet:14:15:19:~/grub2/bzr/mainline$ exit >>>> phcoder@debian.x201.phnet:14:15:20:~/grub2/bzr/mainline$ echo $XYZ >>>> >>>> phcoder@debian.x201.phnet:14:15:24:~/grub2/bzr/mainline$ >>>> >>> I understand your point, but IMHO we do need to be able to set global >>> vars in submenus, that's my patch about. >>> >>> Otherwise how can you use a "Settings..." submenu to configure >>> environment variables which are used by other menu entries for booting? >>> The analogy with bash is not useful here. >> We can add a command with traits of both "menuentry" (same context, >> same menu) and "submenu" (new context, new menu), sth like >> submemu_source (same context, new menu) > Yes, that's one possible solution. > > Why establishing a new command instead of using an option for submenu, > let's say "--export 0|1"? Please let me summarize this issue after thinking about it again: Right now the submenu command opens a new context. All exported vars in the parent context are also exported to the new context of the submenu. This is the same behaviour like for Unix shells. The menuentry command doesn't open a new context, it runs in the context of the caller. For submenus there are 3 possibilities for how to behave: 1) Create a new context and run the submenu in the new context. After exiting the submenu, all variables in the submenu context are lost (this is the current behavior). 2) Don't create a new context and run the submenu in the same context as the caller. This would be the same behavior as for menuentry commands. This can be implemented by having a separate submenu command (e.g. submenu_source, or submenu_shared) or introducing a new submenu option (e.g. --shared 0| 1). 3) Create a new context for the submenu. On exit all exported environment variables in the submenu context are exported to the context of the caller. By this you have the advantage that all local (unexported) variables in the submenu context are really local, even for further submenu entries in the submenu, but all exported variables are global for the whole menu tree. Like for option 2) this can be achieved by establishing a new command or using an new option for the submenu command. But this behavior can also be the default behavior for submenus without the need to be able to enable/disable it. As I'm quite unfamiliar with the internal design of GRUB, I'm not sure what option is most adequate, even though I'd vote for option 3). I cannot see the point why it's so important to run a submenu in its own shell (= context) and why menuentries of a submenu shouldn't be able to access the same environment variables like the menuentries of a parent menu. In my opinion the analogy to shells and sub-shells in Unix isn't really adequate because for me a menu tree is an entity on its own, regardless of being implemented as commands (like in GRUB) or using some kind of configuration file defining the menu tree. On the other side i see some advantages for submenus having their own context, e.g. to have local environment variables which don't 'pollute' the calling context. That's the reason why I vote for option 3) with the addition that it's not Please excuse my lengthy exploration about this issue, but it's a very important point for GRUB. Not being able to set globally defined environment variables (= exported toplevel context vars) in submenus prevented until now having customization submenus and doing a search in I-Net about this issue, I've found a lot of posts desperately asking for this feature. As you can see from my patch in the OP, the modification is quite simple and from what i can see the implementation of the other options presented above are not much more complicated. I'm willing to implement and supply whatever will be decided in the hope that we can get it into the upcoming version. We just need to get a final decision. So any comments are, as always, highly welcomed. Andreas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Making exported variables really global
Am 04.03.2012 18:55, schrieb Andreas Vogel: Please let me summarize this issue after thinking about it again: Right now the submenu command opens a new context. All exported vars in the parent context are also exported to the new context of the submenu. This is the same behaviour like for Unix shells. The menuentry command doesn't open a new context, it runs in the context of the caller. For submenus there are 3 possibilities for how to behave: 1) Create a new context and run the submenu in the new context. After exiting the submenu, all variables in the submenu context are lost (this is the current behavior). Personally, I like that solution best. What's the problem? Currently there's no way and absolutely no way to reliably get data from a submenu to a parent menu. This makes it impossible to use submenus e.g. for settings menus. By sharing the context this would not only be consistent with menuentries but while significantly improving the situation it can't cause any major harm. In case somebody relies on variables being local, I'm pretty sure there's always a solution to achieve similar behaviour by multiple variables. So making the context shared wouldn't create any real troubles. But the way it is now - separate context for submenu - does create problems. For example no settings menus and there's no solution for that need at all! As in my opinion this is a major applications for submenus something should be done about it. 2) Don't create a new context and run the submenu in the same context as the caller. This would be the same behavior as for menuentry commands. This can be implemented by having a separate submenu command (e.g. submenu_source, or submenu_shared) or introducing a new submenu option (e.g. --shared 0| 1). While I could live with such a solution, it seems just flawed to me. Such a construct introduces unecessary complexity and inconsistency. If there's such a switch for submenus why shouldn't there be one for source, menuentry, ...? As pointed out previously a separated context offers pretty much nothing that's not possible with a shared one, so in most cases --shared 1 would be fine. But having to write every time --shared 1 after a submenu or submenu_shared is quite cluttered. The use of such constructs doesn't create the impression of a well designed language for my part either. 3) Create a new context for the submenu. On exit all exported environment variables in the submenu context are exported to the context of the caller. By this you have the advantage that all local (unexported) variables in the submenu context are really local, even for further submenu entries in the submenu, but all exported variables are global for the whole menu tree. Like for option 2) this can be achieved by establishing a new command or using an new option for the submenu command. But this behavior can also be the default behavior for submenus without the need to be able to enable/disable it. I don't really like this one. It introduces a completely new and complicated behaviour, which is not commonly found among other software, especially not with bash. I see the risk that even with very good documentation, this implementation leads to unexpected results. And I think it could happen that users won't be able to understand what's causing the problems because shared and local variables are mixed. Such unintuitive solutions should be avoided wherever possible and there are two other possibilities which are in my view much better. Anyway, just some thoughts from a user. Andreas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for different hotkey action than execute
Any problem with this patch? Or why is there no comment? I know, it's really long. ;) In fact, if possible, I'd be very happy if we can still get this into 2.00. Am 27.02.2012 00:08, schrieb Andreas Born: 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. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Frozen
Am 04.03.2012 13:17, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: You forget the case line_start = 0. Please try: -for (i = k - 1; i > (signed) line_start - 1 && i >= 0; +for (i = k - 1; i >= 0 && (unsigned) i >= line_start; Fixes it here with gcc 4.5.2. But now getting: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W -I../include -I../include -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -DGRUB_TARGET_CPU_I386=1 -m32 -nostdinc -isystem /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/include -DGRUB_FILE=\"video/bitmap_scale.c\" -I. -I. -I.. -I.. -I../include -I../include -Os -Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-parameter-type -Wnested-externs -Wstrict-prototypes -Wpointer-sign -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3 -ffreestanding -MT video/bitmap_scale_module-bitmap_scale.o -MD -MP -MF video/.deps-core/bitmap_scale_module-bitmap_scale.Tpo -c -o video/bitmap_scale_module-bitmap_scale.o `test -f 'video/bitmap_scale.c' || echo './'`video/bitmap_scale.c distcc[1015] ERROR: compile /home/shador/.ccache/tmp/linux.tmp.nyx.927.i on localhost failed cc1: warnings being treated as errors loader/i386/linux.c: In function 'grub_cmd_linux': loader/i386/linux.c:292:13: error: cannot optimize possibly infinite loops make[3]: *** [loader/i386/linux_module-linux.o] Error 1 Suggestion: -for (; err && *align >= min_align; (*align)--) +for (; err && *align + 1 > min_align; (*align)--) That's the last one I get with my version of gcc. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Making exported variables really global
First of all thanks for your detailed comment. Am 04.03.2012 22:03, schrieb Andreas Born: > Am 04.03.2012 18:55, schrieb Andreas Vogel: >> Please let me summarize this issue after thinking about it again: >> >> Right now the submenu command opens a new context. All exported vars in >> the parent context are also exported to the new context of the submenu. >> This is the same behaviour like for Unix shells. The menuentry command >> doesn't open a new context, it runs in the context of the caller. >> >> For submenus there are 3 possibilities for how to behave: >> >> 1) Create a new context and run the submenu in the new context. After >> exiting the submenu, all variables in the submenu context are lost (this >> is the current behavior). > Personally, I like that solution best. > What's the problem? Currently there's no way and absolutely no way to > reliably get data from a submenu to a parent menu. This makes it > impossible to use submenus e.g. for settings menus. > By sharing the context this would not only be consistent with > menuentries but while significantly improving the situation it can't > cause any major harm. In case somebody relies on variables being > local, I'm pretty sure there's always a solution to achieve similar > behaviour by multiple variables. So making the context shared wouldn't > create any real troubles. But the way it is now - separate context for > submenu - does create problems. For example no settings menus and > there's no solution for that need at all! As in my opinion this is a > major applications for submenus something should be done about it. It seems you are missing the point here. Option 1) describes the situation like it is right now and means not to change the code and not being able to have submenus which are able to set variables in the callers context. As far as I understood Vladimirs first answer, there is already some kind of common understanding that this is something what should be changed in the future. >> 2) Don't create a new context and run the submenu in the same context as >> the caller. This would be the same behavior as for menuentry commands. >> This can be implemented by having a separate submenu command (e.g. >> submenu_source, or submenu_shared) or introducing a new submenu option >> (e.g. --shared 0| 1). > While I could live with such a solution, it seems just flawed to me. > Such a construct introduces unecessary complexity and inconsistency. > If there's such a switch for submenus why shouldn't there be one for > source, menuentry, ...? > As pointed out previously a separated context offers pretty much > nothing that's not possible with a shared one, so in most cases > --shared 1 would be fine. But having to write every time --shared 1 > after a submenu or submenu_shared is quite cluttered. The use of such > constructs doesn't create the impression of a well designed language > for my part either. As far as I understood your comment, you're voting for option 2) but without needing to specify that the context should be shared with the calling context. In other words sharing the context should be enabled by default. Right? >> 3) Create a new context for the submenu. On exit all exported >> environment variables in the submenu context are exported to the context >> of the caller. By this you have the advantage that all local >> (unexported) variables in the submenu context are really local, even for >> further submenu entries in the submenu, but all exported variables are >> global for the whole menu tree. Like for option 2) this can be achieved >> by establishing a new command or using an new option for the submenu >> command. But this behavior can also be the default behavior for submenus >> without the need to be able to enable/disable it. > I don't really like this one. It introduces a completely new and > complicated behaviour, which is not commonly found among other > software, especially not with bash. > I see the risk that even with very good documentation, this > implementation leads to unexpected results. And I think it could > happen that users won't be able to understand what's causing the > problems because shared and local variables are mixed. Such > unintuitive solutions should be avoided wherever possible and there > are two other possibilities which are in my view much better. The rule for this option is very simple and can be expressed in one sentence: "Regarding the menu system, all exported variables have a global scope." BTW, right now GRUB makes a difference between local (unexported) and global (exported) vars: global vars are "handed over" to the context of subme
Re: [PATCH] Making exported variables really global
Am 04.03.2012 23:48, schrieb Andreas Vogel: First of all thanks for your detailed comment. Am 04.03.2012 22:03, schrieb Andreas Born: Am 04.03.2012 18:55, schrieb Andreas Vogel: Please let me summarize this issue after thinking about it again: Right now the submenu command opens a new context. All exported vars in the parent context are also exported to the new context of the submenu. This is the same behaviour like for Unix shells. The menuentry command doesn't open a new context, it runs in the context of the caller. For submenus there are 3 possibilities for how to behave: 1) Create a new context and run the submenu in the new context. After exiting the submenu, all variables in the submenu context are lost (this is the current behavior). Personally, I like that solution best. What's the problem? Currently there's no way and absolutely no way to reliably get data from a submenu to a parent menu. This makes it impossible to use submenus e.g. for settings menus. By sharing the context this would not only be consistent with menuentries but while significantly improving the situation it can't cause any major harm. In case somebody relies on variables being local, I'm pretty sure there's always a solution to achieve similar behaviour by multiple variables. So making the context shared wouldn't create any real troubles. But the way it is now - separate context for submenu - does create problems. For example no settings menus and there's no solution for that need at all! As in my opinion this is a major applications for submenus something should be done about it. It seems you are missing the point here. Option 1) describes the situation like it is right now and means not to change the code and not being able to have submenus which are able to set variables in the callers context. As far as I understood Vladimirs first answer, there is already some kind of common understanding that this is something what should be changed in the future. 2) Don't create a new context and run the submenu in the same context as the caller. This would be the same behavior as for menuentry commands. This can be implemented by having a separate submenu command (e.g. submenu_source, or submenu_shared) or introducing a new submenu option (e.g. --shared 0| 1). While I could live with such a solution, it seems just flawed to me. Such a construct introduces unecessary complexity and inconsistency. If there's such a switch for submenus why shouldn't there be one for source, menuentry, ...? As pointed out previously a separated context offers pretty much nothing that's not possible with a shared one, so in most cases --shared 1 would be fine. But having to write every time --shared 1 after a submenu or submenu_shared is quite cluttered. The use of such constructs doesn't create the impression of a well designed language for my part either. As far as I understood your comment, you're voting for option 2) but without needing to specify that the context should be shared with the calling context. In other words sharing the context should be enabled by default. Right? Yes. Somehow missed that 1) wasn't about this. Sorry. Let's call it 4), which would be: no new context is created with submenus. 3) Create a new context for the submenu. On exit all exported environment variables in the submenu context are exported to the context of the caller. By this you have the advantage that all local (unexported) variables in the submenu context are really local, even for further submenu entries in the submenu, but all exported variables are global for the whole menu tree. Like for option 2) this can be achieved by establishing a new command or using an new option for the submenu command. But this behavior can also be the default behavior for submenus without the need to be able to enable/disable it. I don't really like this one. It introduces a completely new and complicated behaviour, which is not commonly found among other software, especially not with bash. I see the risk that even with very good documentation, this implementation leads to unexpected results. And I think it could happen that users won't be able to understand what's causing the problems because shared and local variables are mixed. Such unintuitive solutions should be avoided wherever possible and there are two other possibilities which are in my view much better. The rule for this option is very simple and can be expressed in one sentence: "Regarding the menu system, all exported variables have a global scope." Yes, but no matter where and how prominent you put it who reads this? And not introducing the complexity of contexts with subshells, which offer little benefit here, makes it even easier. BTW, right now GRUB makes a difference between local (unexported) and global (exported) vars: global vars are "handed over" to the context of submenus, loca
Re: Device instability, gettext and default
Am 03.03.2012 14:37, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> === modified file 'grub-core/commands/menuentry.c'
> --- grub-core/commands/menuentry.c2012-02-26 16:28:05 +
> +++ grub-core/commands/menuentry.c2012-03-03 12:11:30 +
> @@ -36,6 +36,8 @@
> N_("Keyboard key to quickly boot this entry."), N_("KEYBOARD_KEY"),
> ARG_TYPE_STRING},
> {"source", 4, 0,
> N_("Use STRING as menu entry body."), N_("STRING"), ARG_TYPE_STRING},
> +{"id", 1, GRUB_ARG_OPTION_REPEATABLE,
> + N_("Menu entry identifier."), N_("STRING"), ARG_TYPE_STRING},
> {0, 0, 0, 0, 0, 0}
>};
1) After bzr-pulling your latest changes and reviewing that source
again, i noticed that you are using GRUB_ARG_OPTION_REPEATABLE for the
new id option but you are not handling multiple ids (as far as i can see).
2) Why do you refuse to allow short options for all of the menuentry
options? Any special reason?
3) Wouldn't it be a good chance to use my patch which uses an anonymous
enum for indexing the options array?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Device instability, gettext and default
Am 05.03.2012 01:03, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >> options? Any special reason? > 2) Why do you refuse to allow short options for all of the menuentry > Because it shares the space with options to menuentry. Don't understand what you mean. What is shared? >> 3) Wouldn't it be a good chance to use my patch which uses an anonymous >> enum for indexing the options array? > No. Thinking like this is a slippery slope. Such patches may also > contain bugs (if you confuse 2 numbers). > Your patch could be committed into experimental but not trunk. > Life doesn't end at 2.00. Nice joke that code right now is a slippery slope... with all those obfuscated numbers. Just my 2 cents... ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Ideas for the future
I took the last few nights to divide my previously submitted huge patch
into logical parts (around 10 patches now). Some of them I've submitted
already.
So right now it seems to me that it's useless to waste your time (and my
time too) to submit more patches or even to discuss them due to code
freeze and because all time is needed now to prepare release 2.0.
Even though I fully understand this situation it's really sad that some
of the most wanted features for GRUB will still not be available in the
upcoming release (especially the possibility to have a settings menu).
Personally i can live with that coz I'm using my private patches for my
projects which do need those features.
Anyway, I don't want that those ideas are lost so let me summarize the
enhancements I have patches for and what i think would be great to have
in the future:
1) Environment variable substitution in menus. For normal menu entries
this works already. For submenus this doesn't work as the submenu
entries are not re-evaluated after execution of it's menuentries.
Example:
set lang=us
menuentry 'Boot with lang=$lang' { ... ; linux lang=$lang ; boot }
submenu Settings {
submenu 'Language... (current lang = $lang)' {
menuentry --silent=1 'Set lang US' { set lang=us }
menuentry --silent=1 'Set lang DE' { set lang=de }
}
}
2) Environment variable substitutions in theme labels. Theme labels
should be able to reference environment variables for display. It
would/could be even great to use environment variables for different
things in themes (fonts, pictures, etc...). By this it would be possible
to use a quite generic theme.txt file for different resolutions, etc.
3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers.
4) menuentry/submenu --hidden 0|1
Hidden menuentries behave the same like normal menu entries but they are
not visible on the screen. They can only be activated using a hotkey. By
this you can define a help screen using hotkey F1 but no visible menu
entry is needed.
5) menuentry --silent 0|1
When using menuentries which just sets some variables or do some other
(non booting tasks), it's really bothering to see a flickering empty
terminal box just for nothing. When this flag is set, the terminal box
will not be shown by default when the entry is executed. Execution of
submenus should be always silent.
6) menuentry --enabled 0|1
It's a good practice to show menuentries even if they are not applicable
in different situations (that's common for all major menu systems). If a
menu entry is disabled, it is shown but it is not operable. E.g. one
might have a general grub config file which supports booting a bunch of
ISO images. When an ISO image is not found and instead of not showing a
menuentry for that, those menuentry could be shown as disabled.
As I said before, I have patches which implements all those features and
I'm using these features in projects right now.
Vladimir, it seems that GRUB is a one man show and it's really your
baby. Don't get me wrong please, I really appreciate your hard work and
from our conversation I can feel that you're really a genius. Whenever
you have time again for new ideas, new patches and new discussions, let
me know. It's just the wrong time right now for that.
Andreas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Ideas for the future
er hotkey, e.g. -h.
I don't really see the point against having hidden menuentries,
especially when taking into account that i provided a real life example.
>> 5) menuentry --silent 0|1
>> When using menuentries which just sets some variables or do some other
>> (non booting tasks), it's really bothering to see a flickering empty
>> terminal box just for nothing. When this flag is set, the terminal box
>> will not be shown by default when the entry is executed. Execution of
>> submenus should be always silent.
> Rather than removing messages better move them to some status bar in
> the theme.
You didn't get the point. Why should any terminal box open when there is
nothing to display? When there are errors, the terminal box will open
anyway.
What bothers me (and btw. a quite some others) is that when you have
such a menu entry
menuentry 'Set language to US' { set lang=us }
and when executing this entry an empty terminal box will be shown for a
very short time (opened and closed). It's just flickering, totally
useless and bothering, not nice.
>> 6) menuentry --enabled 0|1
>> It's a good practice to show menuentries even if they are not applicable
>> in different situations (that's common for all major menu systems). If a
>> menu entry is disabled, it is shown but it is not operable. E.g. one
>> might have a general grub config file which supports booting a bunch of
>> ISO images. When an ISO image is not found and instead of not showing a
>> menuentry for that, those menuentry could be shown as disabled.
> This seems like just cluttering the view. Remember that in some
> applications (e.g. braille) menu has to be very concise. We support
> even the tiny (40x1) terminal geometries.
Not at all. Every decent menu system supports disabled menu entries and
serious design guides suggest better to have disabled menu entries than
not to show them at all. If you have a look in Firefox, Thunderbird
(just to mention 2 programs), you'll see that they all use disabled
menu entries.
Btw, I don't really understand your point about braille displays: a
disabled menu entry would look almost the same like an enabled one.
Andreas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Device instability, gettext and default
Am 05.03.2012 01:34, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 05.03.2012 01:20, Andreas Vogel wrote:
>> Am 05.03.2012 01:03, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>> options? Any special reason?
>>> 2) Why do you refuse to allow short options for all of the menuentry
>>> Because it shares the space with options to menuentry.
>> Don't understand what you mean. What is shared?
> menuentry "title" hello {
>echo $1; sleep 10
> }
I'm really sorry, but i still don't understand and I'd really like
to understand it.
Why is it OK for the menuentry command to accept long options but not OK
to accept short options? What is the difference here handling long
options opposed to handling short options?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Ideas for the future
Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >> option with an optional argument. By this we would have had what you >> preference and my way too. Regarding optional arguments the option >> handling in GRUB is actually broken by design, so this is, >> unfortunately, not an option. > When i implemented my patches, i wanted to use both ways: a command line > Again it's unfortunate that noone noticed it when it was committed and > now we're stuck with it. You should think about that again. GRUB is broken regarding that and it should be fixed anyway. Right now it seems that there is only one command which uses GRUB_ARG_OPTION_OPTIONAL so maybe it's one of the last chances to have a cheap fix. The (only!?) place where an optional option is used is the --set option for the search command. The manual entry for search states: search [--file|--label|--fs-uuid] [--set [var]] [--no-floppy] name The description is wrong. For --set it's only possible to omit "var" iff another option is following the --set option. OK: search --file --set --nofloppy /boot/grub/grub.cfg OK: search --file --set -- /boot/grub/grub.cfg ERROR: search --file --set /boot/grub/grub.cfg It's either needed to correct the manual or to fix the code. If it's decided that the code cannot be fixed (for whatever reasons) the use of optional option arguments should be strongly discouraged or even forbidden then. Andreas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Ideas for the future
Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >>>> 5) menuentry --silent 0|1 >>>> When using menuentries which just sets some variables or do some other >>>> (non booting tasks), it's really bothering to see a flickering empty >>>> terminal box just for nothing. When this flag is set, the terminal box >>>> will not be shown by default when the entry is executed. Execution of >>>> submenus should be always silent. >>> Rather than removing messages better move them to some status bar in >>> the theme. >> You didn't get the point. Why should any terminal box open when there is >> nothing to display? > I think you don't get mine: if this message goes to status bar it > doesn't go to the terminal and so it doesn't open. There are *no* messages at all when executing such entries. No need for any terminal box or status bar. No messages are removed or need to be directed to anywhere, because there are no messages, not even one single character of output. A menuentry flagged as --silent will not produce any output, never ever. It might produce errors and in this case the terminal box is opened and the error is shown as it is the case in the current version. Anyway, I tried to check out your proposal at least... where can i find the code handling a status bar? Andreas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
