В Mon, 11 May 2015 14:15:48 +0200
Jan Kara пишет:
> On Mon 11-05-15 14:53:57, Andrei Borzenkov wrote:
> > В Mon, 14 Jul 2014 17:21:28 +0200
> > Jan Kara пишет:
> >
> > > Signed-off-by: Jan Kara
> > > ---
> > > grub-core/fs/xfs.c | 17 +++--
> > > 1 file changed, 11 insertions(+),
В Mon, 14 Jul 2014 17:21:31 +0200
Jan Kara пишет:
> Add support for new XFS on disk format. We have to handle optional
> filetype fields in directory entries, additional CRC, LSN, UUID entries
> in some structures, etc.
>
> Signed-off-by: Jan Kara
> ---
> grub-core/fs/xfs.c | 249
> ++
В Mon, 14 Jul 2014 17:21:30 +0200
Jan Kara пишет:
> Currently XFS driver converted inode numbers to native endianity only
> when using them to compute inode position. Although this works, it is
> somewhat confusing. So convert inode numbers when reading them from disk
> structures as every other
В Mon, 11 May 2015 20:01:29 +0800
Michael Chang пишет:
> On Mon, May 11, 2015 at 01:01:43PM +0200, Olaf Hering wrote:
> > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > Do you really own all those installs to be able to speak on behalf of all
> > > of
> > > them?
> >
> > Since
Hello!
I am revisiting an issue that surfaced on or about the beginning of
November of 2008. I found the relevant messages in my Google Mail
store and went over them, I also read the corresponding coreboot
messages from the same period.
The responding individual then mentions that what I was inter
> > and using some of that logic to inspect the Xen to find
> > the MB2 header?
> >
> See grub-file tool. Possibly it's still only in next branch
I see it. Thank you.
I also see 'faf4a65e1e1ce1d822d251c1e4b53d96ec7faec5'
Revert grub-file usage in grub-mkconfig.
but not much of an explana
On May 11, 2015 8:46 PM, "Andrei Borzenkov" wrote:
>
> В Mon, 11 May 2015 19:14:14 +0200
> "Vladimir 'phcoder' Serbinenko" пишет:
>
> > On May 11, 2015 6:52 PM, "Andrei Borzenkov" wrote:
> > >
> > > В Mon, 11 May 2015 14:55:34 +0200
> > > "Vladimir 'phcoder' Serbinenko" пишет:
> > >
> > > > On
В Mon, 11 May 2015 19:14:14 +0200
"Vladimir 'phcoder' Serbinenko" пишет:
> On May 11, 2015 6:52 PM, "Andrei Borzenkov" wrote:
> >
> > В Mon, 11 May 2015 14:55:34 +0200
> > "Vladimir 'phcoder' Serbinenko" пишет:
> >
> > > On May 11, 2015 2:04 PM, "Andrei Borzenkov" wrote:
> > > >
> > > > В Mon,
On May 11, 2015 7:08 PM, "Olaf Hering" wrote:
>
> On Mon, May 11, Andrei Borzenkov wrote:
>
> > В Mon, 11 May 2015 14:15:54 +0200
> > Olaf Hering пишет:
> >
> > > On Mon, May 11, Andrei Borzenkov wrote:
> > >
> > > > Either by allowing ${grub.arg.XXX} (not sure if current grammar
accepts
> > > >
On Mon, May 11, Andrei Borzenkov wrote:
> В Mon, 11 May 2015 14:15:54 +0200
> Olaf Hering пишет:
>
> > On Mon, May 11, Andrei Borzenkov wrote:
> >
> > > Either by allowing ${grub.arg.XXX} (not sure if current grammar accepts
> > > it) or by adding getarg command, something like
> > >
> > > get
В Mon, 11 May 2015 14:55:34 +0200
"Vladimir 'phcoder' Serbinenko" пишет:
> On May 11, 2015 2:04 PM, "Andrei Borzenkov" wrote:
> >
> > В Mon, 11 May 2015 13:51:48 +0200
> > Olaf Hering пишет:
> >
> > > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> > >
> > > >
> > > > On May 11, 2015 1:2
В Mon, 11 May 2015 14:15:54 +0200
Olaf Hering пишет:
> On Mon, May 11, Andrei Borzenkov wrote:
>
> > Either by allowing ${grub.arg.XXX} (not sure if current grammar accepts
> > it) or by adding getarg command, something like
> >
> > getarg --name debug --set debug
>
> What would such format bu
On May 11, 2015 6:26 PM, "Konrad Rzeszutek Wilk"
wrote:
>
> On Mon, Feb 09, 2015 at 06:55:05PM +0100, Daniel Kiper wrote:
> > Hi all,
> >
> > On Fri, Jan 30, 2015 at 06:59:23PM +0100, Daniel Kiper wrote:
> > > Hi,
> > >
> > > This patch series enable EFI boot services usage
> > > in loaded images
On Mon, Feb 09, 2015 at 06:55:05PM +0100, Daniel Kiper wrote:
> Hi all,
>
> On Fri, Jan 30, 2015 at 06:59:23PM +0100, Daniel Kiper wrote:
> > Hi,
> >
> > This patch series enable EFI boot services usage
> > in loaded images by multiboot2 protocol.
>
> Guys, do you have any comments on this patch
On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> most other firmwares like EFI or BIOS look for boot image at hardcoded
> place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble
> with passing this info from dom0 is that it's difficult to discover for
> grub-install
On May 11, 2015 3:34 PM, "Olaf Hering" wrote:
>
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > On May 11, 2015 2:16 PM, "Olaf Hering" wrote:
> > > The use of uninitialized vars has to be caught by the script author
no?
> > It never works this way
>
> So? How does it work then? Becau
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> On May 11, 2015 2:16 PM, "Olaf Hering" wrote:
> > The use of uninitialized vars has to be caught by the script author no?
> It never works this way
So? How does it work then? Because thats what I will propose to my
package maintainer later t
On May 11, 2015 2:04 PM, "Andrei Borzenkov" wrote:
>
> В Mon, 11 May 2015 13:51:48 +0200
> Olaf Hering пишет:
>
> > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> >
> > >
> > > On May 11, 2015 1:23 PM, "Olaf Hering" wrote:
> > > >
> > > > On Mon, May 11, Vladimir 'phcoder' Serbinenko wro
On May 11, 2015 2:16 PM, "Olaf Hering" wrote:
>
> On Mon, May 11, Andrei Borzenkov wrote:
>
> > Either by allowing ${grub.arg.XXX} (not sure if current grammar accepts
> > it) or by adding getarg command, something like
> >
> > getarg --name debug --set debug
>
> What would such format buy us?
>
>
On Mon, May 11, Andrei Borzenkov wrote:
> Either by allowing ${grub.arg.XXX} (not sure if current grammar accepts
> it) or by adding getarg command, something like
>
> getarg --name debug --set debug
What would such format buy us?
> You do not control what arguments grub gets - end use (admin)
On Mon 11-05-15 14:53:57, Andrei Borzenkov wrote:
> В Mon, 14 Jul 2014 17:21:28 +0200
> Jan Kara пишет:
>
> > Signed-off-by: Jan Kara
> > ---
> > grub-core/fs/xfs.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/grub-core/fs/xfs.c b/grub-core/
On Mon, May 11, 2015 at 01:01:43PM +0200, Olaf Hering wrote:
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > Do you really own all those installs to be able to speak on behalf of all of
> > them?
>
> Since there is zero upstream support for anything regarding grub xen
> distros are f
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> Well your argument doesn't say at all why no prefix is better than separating
> namespaces
Who is supposed to parse the prefix?
And at what point in time? Early, later, never?
> > How do you envison a way to select a boot device, or set deb
В Mon, 11 May 2015 13:51:48 +0200
Olaf Hering пишет:
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> >
> > On May 11, 2015 1:23 PM, "Olaf Hering" wrote:
> > >
> > > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> > >
> > > > Do you really own all those installs to be able to
On May 11, 2015 1:52 PM, "Olaf Hering" wrote:
>
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> >
> > On May 11, 2015 1:23 PM, "Olaf Hering" wrote:
> > >
> > > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> > >
> > > > Do you really own all those installs to be able to speak on
В Mon, 14 Jul 2014 17:21:28 +0200
Jan Kara пишет:
> Signed-off-by: Jan Kara
> ---
> grub-core/fs/xfs.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/grub-core/fs/xfs.c b/grub-core/fs/xfs.c
> index 16ffd3f1ebd9..a2fc942707c1 100644
> --- a/grub-core
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> On May 11, 2015 1:23 PM, "Olaf Hering" wrote:
> >
> > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > Do you really own all those installs to be able to speak on behalf of all
> of
> > > them?
> >
> > Since there is zero ups
В Mon, 14 Jul 2014 17:21:29 +0200
Jan Kara пишет:
> Directory iteration used wrong position (sizeof wrong structure) for
> termination of iteration inside a directory block. Luckily the position
> ended up being wrong by just 1 byte and directory entries are larger so
> things worked out fine in
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> GRUB is built with -nostd*. So when we want headers from /usr/include we can't
> omit including them
Likely, but which stdint.h is required for the changed commands? The one
from the system or the one from gnulib?
Looking at configure I see a
GRUB is built with -nostd*. So when we want headers from /usr/include we
can't omit including them
On May 11, 2015 1:30 PM, "Olaf Hering" wrote:
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > What is the problem you're trying to solve? We shouldn't require user to
> pass
> > additio
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> What is the problem you're trying to solve? We shouldn't require user to pass
> additional parameters for common cases of we can avoid it
My xen headers are in /odd/path, so I first tried
env CPPFLAGS_XEN=/odd/path/include ./configure && make
В Mon, 11 May 2015 11:13:18 +
Olaf Hering пишет:
> A grub for xen can be built with CPPFLAGS="-I/path" ./configure, which
CPPFLAGS_XEN is target variable, not host. That (if) CPPFLAGS leaks
into target is a bug, not a feature.
___
Grub-devel mail
On May 11, 2015 1:23 PM, "Olaf Hering" wrote:
>
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > Do you really own all those installs to be able to speak on behalf of
all of
> > them?
>
> Since there is zero upstream support for anything regarding grub xen
> distros are forced to provi
What is the problem you're trying to solve? We shouldn't require user to
pass additional parameters for common cases of we can avoid it
On May 11, 2015 1:13 PM, "Olaf Hering" wrote:
> A grub for xen can be built with CPPFLAGS="-I/path" ./configure, which
> has the benefit that CPPFLAGS gets autom
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> Do you really own all those installs to be able to speak on behalf of all of
> them?
Since there is zero upstream support for anything regarding grub xen
distros are forced to provide their own grub-xen binary for dom0. This
includes at least
It was sent on March 27
On May 11, 2015 1:04 PM, "Olaf Hering" wrote:
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
> > The patch has been reviewed upstream and needs improvement
>
> I see no followup to v2 of the patch.
>
> Olaf
>
> ___
> Gr
A grub for xen can be built with CPPFLAGS="-I/path" ./configure, which
has the benefit that CPPFLAGS gets automatically included in the
Makefiles. There is no need for a private makefile variable, the xen
headers are equal to headers for other optional components.
For some commands the cppflags h
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> The patch has been reviewed upstream and needs improvement
I see no followup to v2 of the patch.
Olaf
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-dev
On May 11, 2015 12:41 PM, "Olaf Hering" wrote:
>
> On Mon, May 11, Andrei Borzenkov wrote:
>
> > On Mon, May 11, 2015 at 12:43 PM, Olaf Hering wrote:
> > > Futhermore what freedom would you like to hand out to those who
> > > implement the scripts? In my testing some variables such as root= and
>
The patch has been reviewed upstream and needs improvement
On May 11, 2015 12:43 PM, "Olaf Hering" wrote:
> On Mon, May 11, Andrei Borzenkov wrote:
>
> > SUSE could be the first :)
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759018 indicates that
> Debian uses the referenced patches. Lo
On Mon, May 11, Andrei Borzenkov wrote:
> SUSE could be the first :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759018 indicates that
Debian uses the referenced patches. Looks like they are ignored
upstream.
Olaf
___
Grub-devel mailing list
Gru
On Mon, May 11, Andrei Borzenkov wrote:
> On Mon, May 11, 2015 at 12:43 PM, Olaf Hering wrote:
> > Futhermore what freedom would you like to hand out to those who
> > implement the scripts? In my testing some variables such as root= and
> > prefix= are overriden anyway.
> You do not know what var
On Mon, May 11, 2015 at 12:43 PM, Olaf Hering wrote:
> On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
>
>> As said previously, allowing setting arbitrary variables from command line
>> will
>> not be an accepted behavior. Also the code should be generic enough to allow
>> handling of other
On Mon, May 11, 2015 at 12:36 PM, Olaf Hering wrote:
> On Fri, May 08, Andrei Borzenkov wrote:
>
>> On Fri, May 8, 2015 at 2:15 PM, Olaf Hering wrote:
>> > On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
>> >
>> >> That's not the plan which is pushed by xen guys. They propose to make grub
>>
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> As said previously, allowing setting arbitrary variables from command line
> will
> not be an accepted behavior. Also the code should be generic enough to allow
> handling of other platforms if need be but surely without including any
> unnec
On Fri, May 08, Andrei Borzenkov wrote:
> On Fri, May 8, 2015 at 2:15 PM, Olaf Hering wrote:
> > On Fri, May 08, Vladimir 'phcoder' Serbinenko wrote:
> >
> >> That's not the plan which is pushed by xen guys. They propose to make grub
> >> stored on dom0 to just load grub from a predefined place i
As said previously, allowing setting arbitrary variables from command line
will not be an accepted behavior. Also the code should be generic enough to
allow handling of other platforms if need be but surely without including
any unnecessary code for platforms that don't need it. Until there is an
a
If grub is used as the kernel in a Xen PV guest there is no way to pass
information into grub. This includes info like which disk should be used
first when searching for files.
Up to now the workaround for the host admin is to rebuild grub-xen every
time with grub-mkimage and include a custom scri
On Mon, May 11, Olaf Hering wrote:
> Does that cmd actually work for you? With 'terminfo -g 200x50'
> grub_cmd_terminfo gets called with argc == 0.
I misunderstodd the cmd syntax, its like:
if [ -n "${rows}" -a -n "${columns}" ];then
terminfo -g ${rows}x${columns} console
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> It's not forced, it's default. Unfortunately there is no way to know terminal
> size on xen, so we assume 80x24 size.
In the environment where grub runs doing a query for the terminal size
should be reliable. I will see if whatever initviocon
It's not forced, it's default. Unfortunately there is no way to know
terminal size on xen, so we assume 80x24 size. You cab specify a different
size with terminfo -g parameter
On May 11, 2015 9:52 AM, "Olaf Hering" wrote:
> On Fri, May 08, Olaf Hering wrote:
>
> > Where is the code which controls
On Fri, May 08, Olaf Hering wrote:
> Where is the code which controls the cursor position?
Looks like the issue is this forced size:
struct grub_terminfo_output_state grub_console_terminfo_output = {
.put = put,
.size = {80, 24}
};
Is grub supposed to do all its scrolling within those margin
52 matches
Mail list logo
