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
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 m
formation 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
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
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 conditio
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
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
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 configure
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 finge
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 BAD
d __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?
An
+ | 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-is
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 somethi
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.
>
> Bo
rward 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."
_
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
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
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
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
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 1
hus
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,
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...@l
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 t
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
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, s
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 d
t. 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 t
v64-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
Gru
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
thing 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-dev
ce 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
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
ested 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, La
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.g
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
ma
e 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
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/Cha
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
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
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 n
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
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 exporti
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
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
thing 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
_
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 no
e 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/g
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,
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
k'
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 ext2. But the result was duly recognized as
ext2, as it should.
So I can offer nothing as far a
ble 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 +02
x27;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 L
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 output
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
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 nati
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
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
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
* 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 he
* 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.
* 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 arg
* 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-u
* 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
_
* 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 informati
* 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 t
eaving 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
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 versi
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
quivalent 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
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
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 usin
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
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 (becaus
ut 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 over
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 *pt
>> 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
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 +
> @
> + 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/listinf
: 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
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
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
> 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
> 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
>>>
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
&g
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
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 ru
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,
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 0
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
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
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
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
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
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 t
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
ave 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
try 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
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 refu
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 option
r. 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
1 - 100 of 122 matches
Mail list logo
