Fri, 23 Feb 2024 16:53:37 + Mate Kukri :
> some UEFI envrionments
Please spell them out explicitly.
Olaf
pgpdV7W68_hjp.pgp
Description: Digitale Signatur von OpenPGP
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/li
Wed, 24 Jan 2024 06:26:37 + Alec Brown :
> +static bool cli_disabled = false;
Are there any other values than zero for "false"?
If not, the initialization can be removed.
Olaf
pgpyCy0AM4E27.pgp
Description: Digitale Signatur von OpenPGP
___
Grub
Thu, 21 Dec 2023 02:42:46 -0800 Oliver Steffen :
> Although its name suggests that it is a generated file (.lst ending!),
> extra_deps.lst is actually tracked in git and is not generated by the
> build system.
I think a simple "echo 'content' > extra_deps.lst" in a Makefile would do.
Olaf
pgp
Thu, 21 Dec 2023 01:17:35 -0600 Oskari Pirhonen :
> Fixes build failure due to the extra_deps.lst file not existing in the
> tarball.
Maybe maybe maybe this is another slight hint that this file needs to be
generated at build time, like all the other similar files?
Olaf
pgpZAPrAL29FG.pgp
De
Wed, 6 Dec 2023 16:24:53 +0100 Daniel Kiper :
> Could you provide us exact steps to reproduce the problem?
Something like this?
mkdir .b
cd $_
../grub-src-dir/configure [options]
A brief look at the sources indicates the new file could be generated during
build, with "echo content > $@".
Ola
Thu, 16 Nov 2023 16:37:38 +0100 Oliver Steffen :
> +syminfo.lst: gensyminfo.sh kernel_syms.lst extra_deps.lst $(MODULE_FILES)
> + cat kernel_syms.lst extra_deps.lst > $@.new
There are rules to create gensyminfo.sh and kernel_syms.lst, but there is no
rule to create extra_deps.lst.
As a resul
Sun, 10 Sep 2023 09:30:24 + darkpenguin :
> Specifying the boot device by its label rather than its UUID can be
> pretty useful in various situations (e.g. multiple test VMs).
Yes, this is very true.
It is up to the local admin to decide how the various block devices
are supposed to be mount
Tue, 29 Aug 2023 16:43:39 +0200 Daniel Kiper :
> Olaf, may I add "Tested-by" on your behalf?
Yes, please. Thanks.
Olaf
pgpgNd6pOsUjs.pgp
Description: Digitale Signatur von OpenPGP
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/m
Tue, 22 Aug 2023 13:26:27 -0500 Glenn Washburn :
> Olaf, would you see if this updated patch series fixes your issues?
Yes, this fixes building the documentation in SLE12SP5. Thanks.
Olaf
pgpRh8NPATmjJ.pgp
Description: Digitale Signatur von OpenPGP
Thu, 17 Aug 2023 15:21:44 -0500 Glenn Washburn :
> On Thu, 17 Aug 2023 11:00:44 +0200
> Olaf Hering wrote:
> > It is the result of my attempt to build just the required binaries, without
> > docs.
> > I came up with this:
> > git clean -dffx
> > bash
Thu, 17 Aug 2023 15:31:52 -0500 Glenn Washburn :
> Would you like to send a proper patch to the list or should I?
Please go ahead and propose a proper patch/fix.
Thanks,
Olaf
pgpbJ0wr5ypJ4.pgp
Description: Digitale Signatur von OpenPGP
___
Grub-deve
Wed, 16 Aug 2023 12:53:48 -0500 Glenn Washburn :
> I specifically wanted these two sections to be subsections of
> x86_64-efi and not at the same level as i386-pc, hence why I have them
> as subsections. I suspect that the issue could be fixed by adding a
> @menu in the x86_64-efi section with the
Wed, 16 Aug 2023 14:33:43 -0500 Glenn Washburn :
> There's an extra 'd' in read in the subject line.
Perhaps there is a better phrase to describe the act of adding something back?
> I don't see this error when building any of the targets that I test.
It is the result of my attempt to build just
Prior commit 3cf2e848bc03 ("disk/cryptodisk: Allows UUIDs to be compared
in a dash-insensitive manner") the grub.cfg below worked as expected:
create a menu, which if selected tries to open the specified partition
and does further processing. In case the passphrase was wrong, it would
just return a
:129:10:
fatal error: rs_decoder.h: No such file or directory
129 | #include
| ^~
compilation terminated.
make: *** [Makefile:34654: boot/i386/pc/lzma_decompress_image-startup_raw.o]
Error 1
Fixes cc2841129652 ("Fix make dist on non-pc.")
Signed-off-by: O
Wed, 16 Aug 2023 00:29:28 -0500 Glenn Washburn :
> Anyway, since you're the first and *so far* only person seeing this,
> could you submit a patch that fixes this for you? It would be great to
> support older makeinfos (if that is indeed the issue) in the upcoming
> release.
The change below fixe
Tue, 15 Aug 2023 12:31:29 -0500 Glenn Washburn :
> I'm not seeing this issue when building on Debian 11. I'm successfully
> building the info, html, and pdf documentation from the texi files
> using debians texinfo package at version 6.7.0.dfsg.2-6. Are you sure
> you are building from clean sourc
Thu, 15 Jun 2023 13:06:09 +0200 Daniel Kiper :
> Right now patch is in the git repo. If you want to improve that part of
> doc please send a fix to grub-devel and CC interested folks.
Yeah, that is very unfortunate, because it breaks the build:
https://lists.gnu.org/archive/html/bug-grub/2023-06/
Mon, 10 Jul 2023 18:35:50 +0200 Daniel Kiper :
> Please test this release candidate. If we do not spot major issues we are
> going
> to release 2.12 in a month or so.
A regression in building the documentation was introduced between
e67a551a4..857af0e17:
https://lists.gnu.org/archive/html/bug-
Fri, 21 Oct 2022 20:53:36 -0700 Denton Liu :
> Thanks for the feedback, it should be an absolute path. I can submit a
> new version of the patch later. However, before I do so, are you still
> a NAK on the general idea?
It is not clear to me how useful it will be in practice.
In the end I have no
Tue, 18 Oct 2022 21:53:32 -0700 Denton Liu :
> On Tue, Oct 18, 2022 at 04:18:21PM +0200, Olaf Hering wrote:
> > Maybe the patch description lacks a specific example how the proposed
> > change is supposed to be used in your environment.
> My patch description says:
>
Tue, 18 Oct 2022 06:57:36 -0700 Denton Liu :
> If I'm understanding correctly, what you're proposing is a mechanism for
> setting the default entry. If I'm not mistaken, this seems like an
> orthogonal discussion to me. My patch proposes a method of setting the
> top-level menu entry while this me
Mon, 17 Oct 2022 03:35:32 -0700 Denton Liu :
> A user may wish to use an image that is not sorted as the "latest"
> version as the top-level entry.
Correct.
What is really required is some form of file pattern matching and to use --id=
in "menuentry title" commands.
That way one can have the
On Mon, Sep 06, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 6 sept. 2021 à 12:49, Olaf Hering a écrit :
> For some reason global variables are not seen in a submenu {} section.
> Does anyone happen to know why this behavior is useful?
> You need to export varia
For some reason global variables are not seen in a submenu {} section.
Does anyone happen to know why this behavior is useful?
Pseudocode:
set var=val
menuentry "me" {
set
echo "var ${var}"
sleep 3
}
submenu "sm" {
set
echo "var ${var}"
sleep 3
}
Seen with grub 2.02 and 2.04.
Thanks,
Ol
Am Fri, 3 Apr 2020 17:55:41 +0200
schrieb Daniel Kiper :
> Could you send me your config file with proxy DHCP?
I do not have it anymore, the proxy DHCP host is gone, the main DHCP host does
now also TFTP.
Olaf
pgpCAoMXRwXUk.pgp
Description: Digitale Signatur von OpenPGP
__
Am Thu, 26 Mar 2020 20:36:47 +0100
schrieb Daniel Kiper :
> May I ask you to do the change for 404 and test it too? If it works
> please post a new patch.
I think "http" needs more surgery. It happens to work despite the (apparently)
bogus error handling. But I do not have time to work on this n
Am Sat, 4 Apr 2020 13:31:40 +0800
schrieb Michael Chang :
> 7 files changed, 229 insertions(+), 2 deletions(-)
A lot of churn. It is called 'verbatim', yet it inserts extra characters in the
output buffer.
I'm still stunned why there is an argument about the obvious bugfix.
Good luck.
Olaf
Am Thu, 2 Apr 2020 19:39:49 +0200
schrieb Daniel Kiper :
> I use such configuration an UEFI platform and it works without any
> issue. However, pxelinux.0 above suggests that you are playing with
> legacy BIOS PC platform.
This may depend on the firmware.
With two BIOS systems grub does not load
Am Tue, 31 Mar 2020 15:33:54 +0200
schrieb Daniel Kiper :
> the patch cannot change the default
Come on, this is obvious data corruption.
Noone would want to opt-in into data corruption.
Noone has shown a usecase for that odd commit from 2011.
Apply the patch and be done with it.
Olaf
pgpwgNE
According to dnsmasq(8) one host can act as a plain DHCP server, while another
one supplies TFTP. Apparently this is called "proxy-DHCP", and happens to work
just fine with the ordinary 'pxelinux.0' bootfile from syslinux.
With grub2 it fails because all the relevant variables for TFTP point to
Am Wed, 25 Mar 2020 19:55:47 +0100
schrieb Daniel Kiper :
> Should not we do the same for 404, file not found, a few lines above?
Maybe. For some reason a 404 returns quickly, while a 400 will request the file
4 times. With this patch there is still some delay, but the request is sent
just once
Am Thu, 19 Mar 2020 15:48:28 +0800
schrieb Michael Chang :
> compatibilty issue.
There can not possibly be any compat issue.
Please go ahead and fix this bug.
Olaf
pgp_HXWiYCbGr.pgp
Description: Digitale Signatur von OpenPGP
___
Grub-devel mailing l
Am Fri, 13 Mar 2020 15:26:33 +0100
schrieb Daniel Kiper :
> Adding Vladimir. There is a chance that he knows why it was added...
In the end this knowledge does not matter much I think.
I sent a patch to fix the bug.
Olaf
pgpfisLVNYarp.pgp
Description: Digitale Signatur von OpenPGP
' var=\"v1 v2\" var=\\\"v1 v2\\\" x
var=val var=val var='v1 v2' var="v1 v2" var=\"v1 v2\" x
Fixes commit 25953e10553dad2e378541a68686fc094603ec54
Signed-off-by: Olaf Hering
---
grub-core/lib/cmdline.c | 58 -
A http transfer will hang if an unhandled error is returned.
The error branch returns the value zero, which is not expected by the caller.
Signed-off-by: Olaf Hering
---
grub-core/net/http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/net/http.c b/grub-core/net
Am Fri, 13 Mar 2020 15:26:33 +0100
schrieb Daniel Kiper :
> Adding Vladimir. There is a chance that he knows why it was added...
I just checked why this did not show up earlier.
With 20190718T143316.4e75b2ae3 and command "linux ($root)/file var='str'"
nothing is escaped.
The command "linux ($ro
Am Fri, 13 Mar 2020 15:07:57 +0100
schrieb Daniel Kiper :
> Anyway, could you check what is going on and prepare a patch if needed?
Sure I can wipe the offending lines from grub_create_loader_cmdline().
The question is rather what the purpose of the new code added in
25953e10553dad2e378541a686
Am Fri, 13 Mar 2020 12:59:32 +0100
schrieb Daniel Kiper :
> Both var="\"str\"" and var="'str'" should work. Does not they? Do you
> still get backslashes in ${cmdline}?
Yes. I think the issue might be the "final expansion" in the menuentry and/or
linux command?
# grub.cfg
insmod part_msdos
ins
With code like this, the resulting kernel cmdline has backslashes before either
' or ".
I think var="\"str\"" or var="'str'" has to be used to place either " or ' into
the variable.
How can I avoid the backslash in the kernel cmdline?
udev_rule="udev.rule=\"mac=${net_default_mac},name=uplink\""
Am Thu, 12 Mar 2020 19:01:26 +0100
schrieb Daniel Kiper :
> Olaf, could you try the patch in the attachment?
Yes, this fixes the compile errors. Thanks.
Olaf
pgp6863eYsU4p.pgp
Description: Digitale Signatur von OpenPGP
___
Grub-devel mailing list
Gr
Am Wed, 11 Mar 2020 12:30:01 +0100
schrieb Javier Martinez Canillas :
> +#if !(defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L))
This does not help. I have seen similar code in one of the zstd headers.
Whatever the outcome will be, it should get a 'Fixes commit d5a32255d' tag.
Olaf
Am Wed, 11 Mar 2020 11:56:27 +0100
schrieb John Paul Adrian Glaubitz :
> Which version of SUSE Linux is that, in case I want to reproduce that?
SLE_12 and Leap 42.3, everything with gcc-4.8. I may be able to work around it
by using a newer compiler.
Olaf
pgpyMboyE0v9G.pgp
Description: Digital
Am Wed, 11 Mar 2020 11:39:08 +0100
schrieb Daniel Kiper :
> Nothing suspicious pooped out. I expect that the issues you are
> hitting are related to set of configure flags which you are using.
It turned out --disable-mm-debug does for some reason fix the build with gcc7.
But building with gcc48
I understand that grub.git#master does (most likely) compile for everyone else:
[ 135s] + env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall ../grub2-src/configure
--target=i386-suse-linux --with-platform=pc
--prefix=/usr/lib64/grub2-chainloader --disable-boot-time --disable-cache-stats
--disable-de
On Tue, Mar 03, Paul Menzel wrote:
> Please bisect the problem to found out the commit introducing the build
> regression in your environment.
git bisect start
# bad: [d5a32255de0e073881980fca0262000c865b30dd] misc: Make grub_strtol()
"end" pointers have safer const qualifiers
git bisect bad d
After upgrade from
4e75b2ae313b13b5bfb54cc5e5c53368d6eb2a08..d5a32255de0e073881980fca0262000c865b30dd
I get this compile error:
env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall ../grub2-src/configure
--target=i386-suse-linux --with-platform=pc
--prefix=/usr/lib64/grub2-chainloader --disable-boot-t
Am Tue, 21 May 2019 11:49:32 +0200
schrieb Olaf Hering :
> Maybe gnulib has just no concept of --disable-nls in the project it serves?
Even if I disable the gettext checks, there is no check to enforce a new enough
autoconf.
For short, the toolchain must be updated for the upcoming grub2. B
Am Tue, 21 May 2019 11:32:18 +0200
schrieb Olaf Hering :
> Does gettext matter at all with --disable-nls?
It does probably not matter at all, but due to this weird code in
build-aux/bootstrap it is enforced:
grep '^[ ]*AM_GNU_GETTEXT_VERSION(' configure.ac >/dev/
Am Tue, 21 May 2019 11:23:17 +0200
schrieb Daniel Kiper :
> Could you tell us more? OS version, etc...
Well, SLES11. But most importantly, the old gettext. Does gettext matter at all
with --disable-nls?
Olaf
pgpsx1zJgQ2lU.pgp
Description: Digitale Signatur von OpenPGP
Since the upgrade of gnulib grub.git#master fails to compile if gettext is "too
old". This also happens with configure --disable-nls:
+ bash bootstrap --gnulib-srcdir=./grub-core/lib/gnulib --skip-po --no-git
--no-bootstrap-sync
bootstrap: Error: 'gettext' version == 0.17 is too old
bootstrap:
.
Fix memleak by freeing dstf.
Convert tabs to spaces in moved code.
Signed-off-by: Olaf Hering
---
util/grub-install-common.c | 108 +
1 file changed, 59 insertions(+), 49 deletions(-)
diff --git a/util/grub-install-common.c b/util/grub-install
On Thu, Mar 29, Hans de Goede wrote:
> I don't think there is much value in it and I don't feel
> like spending time on this to come up with another solution.
Not sure what you are trying to fix. At least for me the version is
shown all the time at the top. And the buildtime does not add any valu
On Wed, Mar 28, Hans de Goede wrote:
> + grub_printf ("%s, build %s %s\n", PACKAGE_STRING, __DATE__, __TIME__);
NACK.
Debian sells something what they call "reproducible build". Check their
website why usage of __DATE__ and __TIME__ is a bad thing.
SUSE does not want to republish an otherwise u
Am Wed, 7 Mar 2018 22:30:53 +0100
schrieb Daniel Kiper :
> Sorry, I do not like it. Please use "__attribute__ ((unused))" for the
> function
> arguments and put #if/#endif around its whole body.
It is not just this function body, many more parts will be unneeded.
Really polluted the entire file
.
Fix memleak by freeing dstf.
Convert tabs to spaces in moved code.
Signed-off-by: Olaf Hering
---
util/grub-install-common.c | 107 -
1 file changed, 58 insertions(+), 49 deletions(-)
diff --git a/util/grub-install-common.c b/util/grub-install
Am Mon, 5 Mar 2018 17:23:12 +0100
schrieb Daniel Kiper :
> On Tue, Feb 27, 2018 at 09:39:20AM +0100, Olaf Hering wrote:
> > +grub_install_copy_nls(const char *src, const char *dst)
> Does not compiler complain that arguments are unused if ENABLE_NLS is not
> defined?
There a
With --disable-nls no locales exist.
Avoid runtime error by wrapping install logic inside ENABLE_NLS.
Signed-off-by: Olaf Hering
---
util/grub-install-common.c | 108 +
1 file changed, 59 insertions(+), 49 deletions(-)
--- a/util/grub-install
Who is the consumer of the tar archive generated in util/grub-mkstandalone.c?
Why would that consumer need the current mtime of the added file?
It breaks what Debian sells as "reproducible builds".
I think the call to grub_util_get_mtime in add_tar_file should be removed.
Olaf
signature.asc
Desc
On Fri, Mar 11, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 9, 2016, Olaf Hering wrote:
> On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
> > I would like to come up with a complete list of 2.02 blockers in one
> week
> &g
On Thu, Mar 31, Andrei Borzenkov wrote:
> On Thu, Mar 31, 2016 at 11:28 AM, Olaf Hering wrote:
> > Is this supposed to work?
> >
> > function f() {
>
> This gives syntax error to me. But
>
> function f {
> echo $1
> }
>
> works.
It does. Not s
Is this supposed to work?
function f() {
set x="$1"
set y="$2"
echo "${x} ${y}"
}
f "a" "b"
f "c" "d"
In my testing the positional arguments are not provided to f().
At least when the code above is loaded via 'configfile "${var}"'.
Olaf
___
Gr
While trying to enable a german keymap in grub2 I run into some grub2 or
BIOS bug on my Esprimo M9400. After 'terminal_input at_keyboard' reboot
just hangs, in grub2, Linux and Xen. Poweroff still works. In Linux the
cursor stops blinking when the reboot is supposed to happen. In grub2
the cursor d
On Wed, Mar 02, Vladimir 'phcoder' Serbinenko wrote:
> I would like to come up with a complete list of 2.02 blockers in one week
> time,
> so that we can have a reasonable timeline
Did anyone took the time to fix btrfs support (convert it from handling
btrfs as filesystem into that what it reall
Between 15dfea8 and b00e4c2 a compile error was introduced:
[ 384s] ../../grub2-src/grub-core/disk/efi/efidisk.c:551:80: error: macro "N_"
passed 2 arguments, but takes just 1
[ 384s] ../../grub2-src/grub-core/disk/efi/efidisk.c: In function
'grub_efidisk_read':
[ 384s] ../../grub2-src/grub-c
On Fri, Jan 29, Andrei Borzenkov wrote:
> On Fri, Jan 29, 2016 at 11:54 AM, Olaf Hering wrote:
> > Am 28.01.2016 um 17:46 schrieb Andrei Borzenkov:
> >> This still respects user settings GRUB_DISABLE_LINUX_UUID. Not sure what we
> >> should do in this case.
> >
Am 28.01.2016 um 17:46 schrieb Andrei Borzenkov:
> This still respects user settings GRUB_DISABLE_LINUX_UUID. Not sure what we
> should do in this case.
grub cant possibly know what the device name of the target OS is. This
is especially true if it tries to guess what the OS on partitions other
th
Last night I finally got around to update my grub1 chainloader to grub2.
During install of the bootloader I ran into this issue:
grub-install: warning: Embedding is not possible. GRUB can only be installed
in this setup by using blocklists. However, blocklists are UNRELIABLE and
their use is d
On Fri, Aug 14, Andrei Borzenkov wrote:
> And the question is?
The question was graylisted, and then forced to fail. Or whatever...
Olaf
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Fri, Aug 14, Olaf Hering wrote:
> /usr/lib64/grub2-chainloader/sbin/grub-install: error: will not proceed with
> blocklists.
Forgot to post also remaining output with --do-it-anyway:
/usr/lib64/grub2-chainloader/sbin/grub-install: info: will leave the core image
on the filesystem
On Wed, May 13, Olaf Hering wrote:
> On Mon, May 11, Olaf Hering wrote:
> > Looking at configure I see also TARGET_CPPFLAGS and HOST_CPPFLAGS.
> > Perhaps the former should be used for grub, I will try that.
> Setting TARGET_CPPFLAGS works.
And after poking further at this,
On Mon, May 11, Olaf Hering wrote:
> 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 c
On Tue, May 12, Vladimir 'phcoder' Serbinenko wrote:
>
> On May 12, 2015 10:06 AM, "Olaf Hering" wrote:
> >
> > On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> >
> > > On May 11, 2015 7:08 PM, "Olaf Hering" wrot
On Mon, May 11, Vladimir 'phcoder' Serbinenko wrote:
> On May 11, 2015 7:08 PM, "Olaf Hering" wrote:
> > And regarding $debug itself, with my change its set very early before
> > any script runs. Perhaps that is useful to debug early issues.
> >
> Eve
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 b
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 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 propos
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, 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
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 spea
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
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
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
e cppflags have to point to POSIX, otherwise
stdint.h will not be found. Previously it was loaded unconditionally
from /usr/include.
Signed-off-by: Olaf Hering
---
conf/Makefile.common| 3 ---
grub-core/Makefile.core.def | 15 ++-
2 files changed, 6 insertions(+), 12 deletion
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 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.
&
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 o
ch modules are included.
Signed-off-by: Olaf Hering
---
grub-core/kern/xen/init.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 0559c03..1dbc01f 100644
--- a/grub-core/kern/xen/in
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
te
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
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 th
On Fri, May 08, Olaf Hering wrote:
> In my testing with a PV guest I notice that the cursor during input
> remains at the 24th row. The actual output of the help command for
> example lists all possible commands and causes scrolling. If I enter
> something the input does not appear a
In my testing with a PV guest I notice that the cursor during input
remains at the 24th row. The actual output of the help command for
example lists all possible commands and causes scrolling. If I enter
something the input does not appear at the bottom but at the 24 row.
Where is the code which
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 o
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 in domU. This I.a.
> allows easier upgrade of bootloader for distros as they don't have to worry
> about dom0
On Fri, May 08, Andrei Borzenkov wrote:
> that's fine but you need to be able to confgure at least disk on which
> guest grub is located, even if path to binary is fixed. How do you do
> it wihout passing some information to dom0 grub?
If a domU starts to be able to modify its "firmware" in dom0
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 Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> > Sigh..
> > There are likely ways to find out where grub was loaded from even on a
> > PC, and use that as initial root=. In a PV guest no such thing exists
> > because itself grub is the firmware.
> grub-install already takes this
1 - 100 of 115 matches
Mail list logo
