> Also removing the redundant check against mft_end as the
> next_attribute() should handle that now.
> A pointer to the end of the buffer is stored in at->end, which is
> initialized the same way as mft_end was.
>
> Fixes: https://savannah.gnu.org/bugs/index.php?66855
>
> Re
7;t understand half of what that code actually does,
so I can't vouch for correctness (not sending it as a patch).
Also filed here https://savannah.gnu.org/bugs/index.php?66855
and here
https://gitlab.archlinux.org/archlinux/packaging/packages/grub/-/issues/12
Kind regards,
Andreas Klauer
On 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
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
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
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
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 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
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
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,
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
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
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
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
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
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
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."
_
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
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
+ | 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
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
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
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
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
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
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
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
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
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
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 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
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,
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
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
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
_
- Ursprüngliche Mitteilung -
> Sorry,
> the source code examples I've sent are from grub.cfg and not from
> 00_header - in 00_header a $ needs to be escaped with \
>
> Greetings
> Joachim
>
> Am 02.05.2012 15:12, schrieb Joachim Mammele:
> > Hi everybody,
> >
> > I'd like to add a valu
e 121 is:
121: err = grub_usb_get_string (dev, idx, 0x0409, &name);
gcc does not seem to understand that name is only set if
grub_usb_get_string returns without an error.
Here's the obvious patch to fix this,
Andreas
Index: grub-1.99
s linker flags to gcc, we should use -Wl,-melf_x86_64
Here's the obvious patch against 1.99 that should still apply to current
head,
Andreas
Index: grub-1.99/conf/Makefile.common
===
--- grub-1.99.orig/conf/Makefile.common
+++ gr
Am 11.03.2012 15:20, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 15:17, Andreas Born wrote:
>> Yes, that would be fine with me too. I thought about that too, but
>> actually I didn't quite see the difference between this and
>> grub_version
Am 11.03.2012 13:52, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 11.03.2012 12:52, Andreas Born wrote:
>> Apart from that I guess it would be nice to have such a variable to
>> display the version someplace or to check it. Yes, I know it is
>> already disp
Am 11.03.2012 15:07, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 11.03.2012 14:55, Andreas Born wrote:
In 1.98 there was that export issue, I already mentioned. When opening
a new context with configfile e.g. variables were exported to the new
context, but not marked anymore fo
Am 11.03.2012 13:47, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
Why not define "feature_bugXYZ_fixed" for bugs?
Which ones are missing in 2.00~beta1?
In 1.98 there was that export issue, I already mentioned. When opening a
new context with configfile e.g. variables were exported to the new
Am 11.03.2012 03:51, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 11.03.2012 03:40, Andreas Born wrote:
Hi,
it would be great to have a variable like version or grub_version in
the shell. Sorry, if there is already such an option and I didn't find
it. But I only saw cpu
ainf**k parser at least. :D
For completeness two-line patch attached. (Untested)
Andreas Born
=== modified file 'grub-core/normal/main.c'
--- grub-core/normal/main.c 2012-03-04 23:41:37 +
+++ grub-core/normal/main.c 2012-03-11 02:29:53 +
@@ -552,6 +552,8 @@
g
Am 11.03.2012 02:01, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> It hurts that you think that I don't follow basic rules of communication
>> and cooperation.
> That's the expression I've got. My position shifted somewhat but yours
> remains unchanged. You look stubborn from this angle.
Then I
analyse a problem, see what is wrong and how it should be.
Then I'm thinking about what can be done and what is acceptable and what
are the consequences. Finally it's time for acting. So for me it's
really strange that for you it's irrelevant how it should b
NU in GRUB either, we don't write
>>> an OS but a bootloader. In particular having -xfoo for isn't
>>> necessarry and moreover it will conflict with
>>> search -su
>> So a 'short' option that looks like a 'long' option?
>>
>> Or
Am 08.03.2012 16:25, schrieb Lennart Sorensen:
> On Thu, Mar 08, 2012 at 04:03:17PM +0100, Andreas Vogel wrote:
>> I just used Reply-All in my mail program, so please excuse me and I
>> really hope that i didn't offend anyone, it was not by purpose.
> And that is how you hij
Am 08.03.2012 16:18, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 08.03.2012 16:03, Andreas Vogel wrote:
>> Am 08.03.2012 15:32, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>> On 08.03.2012 15:15, Vladimir 'φ-coder/phcoder' Serbinenko wrot
Am 08.03.2012 15:11, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 05.03.2012 16:43, Andreas Vogel wrote:
>> Am 05.03.2012 13:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>>>> option with an optional argument. By this we would have had what you
Am 08.03.2012 15:32, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 08.03.2012 15:15, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 08.03.2012 14:12, Andreas Vogel wrote:
>>> Hi all,
>>>
>>> I start a new thread with this ma
options is
present but without value).
So for both, short and long options taking an optional value, no
whitespace between option and its value (if the value is present) is
allowed.
IMHO the option parsing code in GRUB2 should be fixed as soon as
possible. The later it will be done the more we
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
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
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
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
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
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
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 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
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 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
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 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
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 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 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
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 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
> 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
>>>
> 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
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
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
: 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
> + 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
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 +
> @
>> 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
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
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
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
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
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
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
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
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
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
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
* 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
* 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 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: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 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) [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.
* 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
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
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
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
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
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
1 - 100 of 122 matches
Mail list logo