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&#x
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
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 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 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
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
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
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
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 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
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 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: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: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
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
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
- 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
> 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
Hi,
first, congratulations to the 1.97-release!
I vainly tried to run the latest grub2 (Revision: 2663) as payload to
coreboot (Revision: 4852) following the wikipage:
http://grub.enbug.org/CoreBoot
Is this page still up to date and does anybody use grub2 as payload
successfully? How
Hi Robert,
>Is that coreboot v2 or v3?
coreboot v2, v3 seems to be kind of depreciated and merged into v2.
>Which module selection?
I chose the modules as given in the wiki
( http://grub.enbug.org/CoreBoot ), topic "Building Coreboot with
GRUB2 payload" near the bottom of the page.
First I tr
Hi,
Vladimir 'Ï-coder/phcoder' Serbinenko wrote:
> Is your coreboot compiled with multiboot support?
I guess so, from the serial log:
ACPI: done.
ACPI tables: 4677 bytes.
Multiboot Information structure has been written.
^
Adding CBMEM entry as n
101 - 122 of 122 matches
Mail list logo
