[PATCH] Speed up test suite by avoiding fsync
Add grub_util_disable_fd_syncs call to turn grub_util_fd_sync calls into
no-ops, and use it in programs that copy files but do not need to take
special care to sync writes (grub-mknetdir, grub-rescue,
grub-mkstandalone).
On my laptop, this reduces partmap_test's runtime from 1236 seconds to
204 seconds.
---
ChangeLog | 7 +++
grub-core/osdep/aros/hostdisk.c| 25 ++---
grub-core/osdep/unix/hostdisk.c| 11 ++-
grub-core/osdep/windows/hostdisk.c | 11 ++-
include/grub/emu/hostfile.h| 2 ++
util/grub-install-common.c | 2 +-
util/grub-mknetdir.c | 1 +
util/grub-mkrescue.c | 3 ++-
util/grub-mkstandalone.c | 1 +
9 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 2e0d96e..4bbec86 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-11-27 Colin Watson
+
+ Add grub_util_disable_fd_syncs call to turn grub_util_fd_sync calls
+ into no-ops, and use it in programs that copy files but do not need
+ to take special care to sync writes (grub-mknetdir, grub-rescue,
+ grub-mkstandalone).
+
2013-11-26 Colin Watson
* tests/util/grub-fs-tester.in: Execute xorriso from $PATH rather
diff --git a/grub-core/osdep/aros/hostdisk.c b/grub-core/osdep/aros/hostdisk.c
index 9c0a6c8..b153907 100644
--- a/grub-core/osdep/aros/hostdisk.c
+++ b/grub-core/osdep/aros/hostdisk.c
@@ -455,6 +455,8 @@ grub_util_fd_close (grub_util_fd_t fd)
}
}
+static int allow_fd_syncs = 1;
+
static void
grub_util_fd_sync_volume (grub_util_fd_t fd)
{
@@ -469,18 +471,27 @@ grub_util_fd_sync_volume (grub_util_fd_t fd)
void
grub_util_fd_sync (grub_util_fd_t fd)
{
- switch (fd->type)
+ if (allow_fd_syncs)
{
-case GRUB_UTIL_FD_FILE:
- fsync (fd->fd);
- return;
-case GRUB_UTIL_FD_DISK:
- grub_util_fd_sync_volume (fd);
- return;
+ switch (fd->type)
+ {
+ case GRUB_UTIL_FD_FILE:
+ fsync (fd->fd);
+ return;
+ case GRUB_UTIL_FD_DISK:
+ grub_util_fd_sync_volume (fd);
+ return;
+ }
}
}
void
+grub_util_disable_fd_syncs (void)
+{
+ allow_fd_syncs = 0;
+}
+
+void
grub_hostdisk_flush_initial_buffer (const char *os_dev __attribute__
((unused)))
{
}
diff --git a/grub-core/osdep/unix/hostdisk.c b/grub-core/osdep/unix/hostdisk.c
index 78d4adb..fc88ed4 100644
--- a/grub-core/osdep/unix/hostdisk.c
+++ b/grub-core/osdep/unix/hostdisk.c
@@ -191,10 +191,19 @@ grub_util_fd_strerror (void)
return strerror (errno);
}
+static int allow_fd_syncs = 1;
+
void
grub_util_fd_sync (grub_util_fd_t fd)
{
- fsync (fd);
+ if (allow_fd_syncs)
+fsync (fd);
+}
+
+void
+grub_util_disable_fd_syncs (void)
+{
+ allow_fd_syncs = 0;
}
void
diff --git a/grub-core/osdep/windows/hostdisk.c
b/grub-core/osdep/windows/hostdisk.c
index 6d7d120..4748a61 100644
--- a/grub-core/osdep/windows/hostdisk.c
+++ b/grub-core/osdep/windows/hostdisk.c
@@ -240,10 +240,19 @@ grub_util_fd_write (grub_util_fd_t fd, const char *buf,
size_t len)
return real_read;
}
+static int allow_fd_syncs = 1;
+
void
grub_util_fd_sync (grub_util_fd_t fd)
{
- FlushFileBuffers (fd);
+ if (allow_fd_syncs)
+FlushFileBuffers (fd);
+}
+
+void
+grub_util_disable_fd_syncs (void)
+{
+ allow_fd_syncs = 0;
}
void
diff --git a/include/grub/emu/hostfile.h b/include/grub/emu/hostfile.h
index ab01fbc..8e37d5a 100644
--- a/include/grub/emu/hostfile.h
+++ b/include/grub/emu/hostfile.h
@@ -50,6 +50,8 @@ EXPORT_FUNC(grub_util_fd_strerror) (void);
void
grub_util_fd_sync (grub_util_fd_t fd);
void
+grub_util_disable_fd_syncs (void);
+void
EXPORT_FUNC(grub_util_fd_close) (grub_util_fd_t fd);
grub_uint64_t
diff --git a/util/grub-install-common.c b/util/grub-install-common.c
index 7ecef3e..fcf994d 100644
--- a/util/grub-install-common.c
+++ b/util/grub-install-common.c
@@ -492,7 +492,7 @@ grub_install_make_image_wrap (const char *dir, const char
*prefix,
memdisk_path, config_path,
mkimage_target, note, comp);
fflush (fp);
- fsync (fileno (fp));
+ grub_util_fd_sync (fileno (fp));
fclose (fp);
}
diff --git a/util/grub-mknetdir.c b/util/grub-mknetdir.c
index 3f91705..40ca724 100644
--- a/util/grub-mknetdir.c
+++ b/util/grub-mknetdir.c
@@ -171,6 +171,7 @@ main (int argc, char *argv[])
const char *pkglibdir;
grub_util_host_init (&argc, &argv);
+ grub_util_disable_fd_syncs ();
rootdir = xstrdup ("/srv/tftp");
pkglibdir = grub_util_get_pkglibdir ();
diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index 7a76bc3..b081b3b 100644
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -369,6 +369,7 @@ main (int argc, char *argv[])
const char *pkgdatadir;
grub_util_host_init (&argc, &argv);
+ grub_util_disable_fd_syncs ();
pkgdatadir = grub_util_get_pkgdatadir ();
Re: [PATCH] Speed up test suite by avoiding fsync
On 27.11.2013 11:13, Colin Watson wrote:
> Add grub_util_disable_fd_syncs call to turn grub_util_fd_sync calls into
> no-ops, and use it in programs that copy files but do not need to take
> special care to sync writes (grub-mknetdir, grub-rescue,
> grub-mkstandalone).
>
Go ahead.
> On my laptop, this reduces partmap_test's runtime from 1236 seconds to
> 204 seconds.
> ---
> ChangeLog | 7 +++
> grub-core/osdep/aros/hostdisk.c| 25 ++---
> grub-core/osdep/unix/hostdisk.c| 11 ++-
> grub-core/osdep/windows/hostdisk.c | 11 ++-
> include/grub/emu/hostfile.h| 2 ++
> util/grub-install-common.c | 2 +-
> util/grub-mknetdir.c | 1 +
> util/grub-mkrescue.c | 3 ++-
> util/grub-mkstandalone.c | 1 +
> 9 files changed, 52 insertions(+), 11 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 2e0d96e..4bbec86 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,10 @@
> +2013-11-27 Colin Watson
> +
> + Add grub_util_disable_fd_syncs call to turn grub_util_fd_sync calls
> + into no-ops, and use it in programs that copy files but do not need
> + to take special care to sync writes (grub-mknetdir, grub-rescue,
> + grub-mkstandalone).
> +
> 2013-11-26 Colin Watson
>
> * tests/util/grub-fs-tester.in: Execute xorriso from $PATH rather
> diff --git a/grub-core/osdep/aros/hostdisk.c b/grub-core/osdep/aros/hostdisk.c
> index 9c0a6c8..b153907 100644
> --- a/grub-core/osdep/aros/hostdisk.c
> +++ b/grub-core/osdep/aros/hostdisk.c
> @@ -455,6 +455,8 @@ grub_util_fd_close (grub_util_fd_t fd)
> }
> }
>
> +static int allow_fd_syncs = 1;
> +
> static void
> grub_util_fd_sync_volume (grub_util_fd_t fd)
> {
> @@ -469,18 +471,27 @@ grub_util_fd_sync_volume (grub_util_fd_t fd)
> void
> grub_util_fd_sync (grub_util_fd_t fd)
> {
> - switch (fd->type)
> + if (allow_fd_syncs)
> {
> -case GRUB_UTIL_FD_FILE:
> - fsync (fd->fd);
> - return;
> -case GRUB_UTIL_FD_DISK:
> - grub_util_fd_sync_volume (fd);
> - return;
> + switch (fd->type)
> + {
> + case GRUB_UTIL_FD_FILE:
> + fsync (fd->fd);
> + return;
> + case GRUB_UTIL_FD_DISK:
> + grub_util_fd_sync_volume (fd);
> + return;
> + }
> }
> }
>
> void
> +grub_util_disable_fd_syncs (void)
> +{
> + allow_fd_syncs = 0;
> +}
> +
> +void
> grub_hostdisk_flush_initial_buffer (const char *os_dev __attribute__
> ((unused)))
> {
> }
> diff --git a/grub-core/osdep/unix/hostdisk.c b/grub-core/osdep/unix/hostdisk.c
> index 78d4adb..fc88ed4 100644
> --- a/grub-core/osdep/unix/hostdisk.c
> +++ b/grub-core/osdep/unix/hostdisk.c
> @@ -191,10 +191,19 @@ grub_util_fd_strerror (void)
>return strerror (errno);
> }
>
> +static int allow_fd_syncs = 1;
> +
> void
> grub_util_fd_sync (grub_util_fd_t fd)
> {
> - fsync (fd);
> + if (allow_fd_syncs)
> +fsync (fd);
> +}
> +
> +void
> +grub_util_disable_fd_syncs (void)
> +{
> + allow_fd_syncs = 0;
> }
>
> void
> diff --git a/grub-core/osdep/windows/hostdisk.c
> b/grub-core/osdep/windows/hostdisk.c
> index 6d7d120..4748a61 100644
> --- a/grub-core/osdep/windows/hostdisk.c
> +++ b/grub-core/osdep/windows/hostdisk.c
> @@ -240,10 +240,19 @@ grub_util_fd_write (grub_util_fd_t fd, const char *buf,
> size_t len)
>return real_read;
> }
>
> +static int allow_fd_syncs = 1;
> +
> void
> grub_util_fd_sync (grub_util_fd_t fd)
> {
> - FlushFileBuffers (fd);
> + if (allow_fd_syncs)
> +FlushFileBuffers (fd);
> +}
> +
> +void
> +grub_util_disable_fd_syncs (void)
> +{
> + allow_fd_syncs = 0;
> }
>
> void
> diff --git a/include/grub/emu/hostfile.h b/include/grub/emu/hostfile.h
> index ab01fbc..8e37d5a 100644
> --- a/include/grub/emu/hostfile.h
> +++ b/include/grub/emu/hostfile.h
> @@ -50,6 +50,8 @@ EXPORT_FUNC(grub_util_fd_strerror) (void);
> void
> grub_util_fd_sync (grub_util_fd_t fd);
> void
> +grub_util_disable_fd_syncs (void);
> +void
> EXPORT_FUNC(grub_util_fd_close) (grub_util_fd_t fd);
>
> grub_uint64_t
> diff --git a/util/grub-install-common.c b/util/grub-install-common.c
> index 7ecef3e..fcf994d 100644
> --- a/util/grub-install-common.c
> +++ b/util/grub-install-common.c
> @@ -492,7 +492,7 @@ grub_install_make_image_wrap (const char *dir, const char
> *prefix,
>memdisk_path, config_path,
>mkimage_target, note, comp);
>fflush (fp);
> - fsync (fileno (fp));
> + grub_util_fd_sync (fileno (fp));
>fclose (fp);
> }
>
> diff --git a/util/grub-mknetdir.c b/util/grub-mknetdir.c
> index 3f91705..40ca724 100644
> --- a/util/grub-mknetdir.c
> +++ b/util/grub-mknetdir.c
> @@ -171,6 +171,7 @@ main (int argc, char *argv[])
>const char *pkglibdir;
>
>grub_util_host_init (&argc, &argv);
> + grub_util_disable_fd_syncs ();
>rootdir = xstrdup ("/srv/tftp");
>pkglibdir = gru
Re: 2.02 Release roadmap
On Tue, Nov 26, 2013 at 10:49:57PM +0400, Andrey Borzenkov wrote: > What is the state of new-autogen branch? That's something I'd > definitely welcome as autogen is not present in all distros which makes > maintaining patches that touch build system rather unpleasant. That's on master now following an ack from Vladimir on IRC. Please let me know of any build regressions resulting from this. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
Il 26/11/2013 19:12, Andrey Borzenkov ha scritto: В Tue, 26 Nov 2013 18:58:47 +0100 Fabio Fantoni пишет: I have also another question: Is possible specify multiple path where search the grub.cfg for support all mainly distributions and add a custom cfg path support taking it from arguments? You can do something like if search --set root --file /boot/grub2/grub.cfg ; then configfile /boot/grub2/grub.cfg elif search --set root --file /boot/grub/grub.cfg ; then configfile /boot/grub/grub.cfg elif ... ... fi I tried with this: cat > boot/grub/grub.cfg
Re: [Xen-devel] pvgrub2 is merged
On 27.11.2013 12:32, Fabio Fantoni wrote: > Il 26/11/2013 19:12, Andrey Borzenkov ha scritto: >> В Tue, 26 Nov 2013 18:58:47 +0100 >> Fabio Fantoni пишет: >> >>> I have also another question: >>> Is possible specify multiple path where search the grub.cfg for support >>> all mainly distributions and add a custom cfg path support taking it >>> from arguments? >>> >> You can do something like >> >> if search --set root --file /boot/grub2/grub.cfg ; then >>configfile /boot/grub2/grub.cfg >> elif search --set root --file /boot/grub/grub.cfg ; then >>configfile /boot/grub/grub.cfg >> elif ... >>... >> fi > > I tried with this: > cat > boot/grub/grub.cfg < insmod lvm > insmod ext2 > insmod part_msdos > insmod part_gpt > if search --set root --file /boot/grub2/grub.cfg ; then > configfile /boot/grub2/grub.cfg > elif search --set root --file /boot/grub/grub.cfg ; then > configfile /boot/grub/grub.cfg > fi > EOF > > But it's not working and it prints this line indefinitely in loop: > error: no such device: /boot/grub2/grub.cfg. > That pretty much explains what happened: you don't have any /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found its own memdisk and fell into recursion. I'm not sure what should be the proper way to solve this recursion. > I also tried with only these lines instead of conditions: > search -s root -f /boot/grub/grub.cfg > configfile /boot/grub/grub.cfg > > But all I get is the line "Welcome to GRUB!" followed by a white screen > on xl console. > > I don't know what else to try :( > > Thanks for any reply. > >> >> If xen provides way to pass arguments to kernel, it sure could be >> implemented as arguments to grub. Actually someone asked for a way to >> pass arguments to grub on EFI, so this could share implementation. > > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 27.11.2013 12:32, Fabio Fantoni wrote: Il 26/11/2013 19:12, Andrey Borzenkov ha scritto: В Tue, 26 Nov 2013 18:58:47 +0100 Fabio Fantoni пишет: I have also another question: Is possible specify multiple path where search the grub.cfg for support all mainly distributions and add a custom cfg path support taking it from arguments? You can do something like if search --set root --file /boot/grub2/grub.cfg ; then configfile /boot/grub2/grub.cfg elif search --set root --file /boot/grub/grub.cfg ; then configfile /boot/grub/grub.cfg elif ... ... fi I tried with this: cat > boot/grub/grub.cfg < That pretty much explains what happened: you don't have any /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found its own memdisk and fell into recursion. I'm not sure what should be the proper way to solve this recursion. Ok, now I understand with this: cat > boot/grub/grub.cfgboot/grub/grub.cfg
Re: [Xen-devel] pvgrub2 is merged
On 27.11.2013 16:59, Fabio Fantoni wrote: > Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: >> On 27.11.2013 12:32, Fabio Fantoni wrote: >>> Il 26/11/2013 19:12, Andrey Borzenkov ha scritto: В Tue, 26 Nov 2013 18:58:47 +0100 Fabio Fantoni пишет: > I have also another question: > Is possible specify multiple path where search the grub.cfg for > support > all mainly distributions and add a custom cfg path support taking it > from arguments? > You can do something like if search --set root --file /boot/grub2/grub.cfg ; then configfile /boot/grub2/grub.cfg elif search --set root --file /boot/grub/grub.cfg ; then configfile /boot/grub/grub.cfg elif ... ... fi >>> I tried with this: >>> cat > boot/grub/grub.cfg <>> insmod lvm >>> insmod ext2 >>> insmod part_msdos >>> insmod part_gpt >>> if search --set root --file /boot/grub2/grub.cfg ; then >>>configfile /boot/grub2/grub.cfg >>> elif search --set root --file /boot/grub/grub.cfg ; then >>>configfile /boot/grub/grub.cfg >>> fi >>> EOF >>> >>> But it's not working and it prints this line indefinitely in loop: >>> error: no such device: /boot/grub2/grub.cfg. >>> >> That pretty much explains what happened: you don't have any >> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found >> its own memdisk and fell into recursion. I'm not sure what should be the >> proper way to solve this recursion. > > Ok, now I understand with this: > cat > boot/grub/grub.cfg < insmod lvm > insmod ext2 > insmod part_msdos > insmod part_gpt > search -s root -f /boot/grub/grub.cfg > configfile /boot/grub/grub.cfg > EOF > > that has the debian grub.cfg path equal to memdisk's grub, and then it > loads the memdisk ones indefinitely. > > Anyone know how to exclude memdisk from the search please? > > With this: > cat > boot/grub/grub.cfg < insmod lvm > insmod ext2 > insmod part_msdos > insmod part_gpt > root='(xen/xvda,msdos1)' > configfile /boot/grub/grub.cfg > EOF > > it loads correctly the Sid grub.cfg but grub fails to load with any > entry I select, that domU stop. > > xl -vvv create -c /etc/xen/sid.cfg > ... > Caricamento Linux 3.11-1-amd64... > error: not xen image. > Caricamento ramdisk iniziale... > xc: debug: hypercall buffer: total allocations:237 total releases:237 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 > xc: debug: hypercall buffer: cache current size:4 > xc: debug: hypercall buffer: cache hits:226 misses:4 toobig:7 > > Maybe that grub is waiting for a dom0 configuration type (with also > xen.gz) but find only kernel and ramdisk? (which is right for a domU) > No, this message indicates problem parsing domU image. Can you give the link to exact image you use? > If you need more tests/informations tell me and I'll post them. > > Thanks for any reply. > >>> I also tried with only these lines instead of conditions: >>> search -s root -f /boot/grub/grub.cfg >>> configfile /boot/grub/grub.cfg >>> >>> But all I get is the line "Welcome to GRUB!" followed by a white screen >>> on xl console. >>> >>> I don't know what else to try :( >>> >>> Thanks for any reply. >>> If xen provides way to pass arguments to kernel, it sure could be implemented as arguments to grub. Actually someone asked for a way to pass arguments to grub on EFI, so this could share implementation. >>> >> > > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
On Wed, 27 Nov 2013, Fabio Fantoni wrote: Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: That pretty much explains what happened: you don't have any /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found its own memdisk and fell into recursion. I'm not sure what should be the proper way to solve this recursion. Ok, now I understand with this: cat > boot/grub/grub.cfg
Re: [Xen-devel] pvgrub2 is merged
Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 27.11.2013 16:59, Fabio Fantoni wrote: Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 27.11.2013 12:32, Fabio Fantoni wrote: Il 26/11/2013 19:12, Andrey Borzenkov ha scritto: В Tue, 26 Nov 2013 18:58:47 +0100 Fabio Fantoni пишет: I have also another question: Is possible specify multiple path where search the grub.cfg for support all mainly distributions and add a custom cfg path support taking it from arguments? You can do something like if search --set root --file /boot/grub2/grub.cfg ; then configfile /boot/grub2/grub.cfg elif search --set root --file /boot/grub/grub.cfg ; then configfile /boot/grub/grub.cfg elif ... ... fi I tried with this: cat > boot/grub/grub.cfg < That pretty much explains what happened: you don't have any /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found its own memdisk and fell into recursion. I'm not sure what should be the proper way to solve this recursion. Ok, now I understand with this: cat > boot/grub/grub.cfg < Is it possible to specify a different default grub.cfg path (different from all other distributions) changing this command: ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O x86_64-xen -d grub-core/ boot/grub/grub.cfg Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set? With this: cat > boot/grub/grub.cfg < No, this message indicates problem parsing domU image. Can you give the link to exact image you use? The standard kernel image installed by debian installer, the package is this: http://packages.debian.org/sid/linux-image-3.11-2-amd64 On domU a previous version is installed but it was working and xen dom0/domU modules are included in this kernel image. If you need more tests/informations tell me and I'll post them. Thanks for any reply. I also tried with only these lines instead of conditions: search -s root -f /boot/grub/grub.cfg configfile /boot/grub/grub.cfg But all I get is the line "Welcome to GRUB!" followed by a white screen on xl console. I don't know what else to try :( Thanks for any reply. If xen provides way to pass arguments to kernel, it sure could be implemented as arguments to grub. Actually someone asked for a way to pass arguments to grub on EFI, so this could share implementation. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
В Wed, 27 Nov 2013 17:24:53 +0100 Fabio Fantoni пишет: > Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: > > On 27.11.2013 16:59, Fabio Fantoni wrote: > >> Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: > >>> That pretty much explains what happened: you don't have any > >>> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found > >>> its own memdisk and fell into recursion. I'm not sure what should be the > >>> proper way to solve this recursion. Yes, it was a bit naive on my side. Recursion in principle can be stopped by using global variable, but search is limited to the first match only anyway, so I guess it is not worth it. > >> > >> Anyone know how to exclude memdisk from the search please? > Please look in grub2 sources at docs/osdetect.cfg. It implements advanced run-time detection of possible bootable files from various operating systems. It boils down to loop across all devices, and of course you can either limit device names (like looking for hd* only) or explicitly exclude known ones (like memdisk). > Is it possible to specify a different default grub.cfg path (different > from all other distributions) changing this command: > ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O > x86_64-xen -d grub-core/ boot/grub/grub.cfg > Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set? > Not really. Currently the situation is - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub - after launch grub unconditionally starts "normal" module if at all possible - normal module always tries to load and execute $prefix/grub.cfg if no explicit configuration file name is given as argument But I think that using osdetect.cfg or something based on this idea won't require changing defaults at all. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading OS/X 10.7 by grub x86_64-efi fails
В Fri, 10 May 2013 14:18:42 +0200 Vladimir 'φ-coder/phcoder' Serbinenko пишет: > On 09.05.2013 20:32, Andrey Borzenkov wrote: > > > I have MacBook (Pro?) 3.1 with OS/X 10.7. I installed as second OS > > openSUSE 12.3 using EFI CD boot (worked just fine) and x86_64-efi > > grub2. I had to manually bless grub on EFI partition to actually boot > > it. os-prober also found installed OS/X and added to boot menu. > > > > The problem is, both 32 and 64 menu options crash during boot. Is it > > supposed to work in the first place? If yes, which diagnostic I can > > collect to debug it further? > > I suppose that the bootargs structure may have changed. I'll look into > it, thank you for reporting. > Any progress on it? This has been reported by multiple users. If this does not have chance to be fixed in reasonable timeframe, I'll rather look at directly chainloading of /System/Library/CoreServices/boot.efi instead of using xnu. signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading OS/X 10.7 by grub x86_64-efi fails
On 27.11.2013 19:26, Andrey Borzenkov wrote: > В Fri, 10 May 2013 14:18:42 +0200 > Vladimir 'φ-coder/phcoder' Serbinenko пишет: > >> On 09.05.2013 20:32, Andrey Borzenkov wrote: >> >>> I have MacBook (Pro?) 3.1 with OS/X 10.7. I installed as second OS >>> openSUSE 12.3 using EFI CD boot (worked just fine) and x86_64-efi >>> grub2. I had to manually bless grub on EFI partition to actually boot >>> it. os-prober also found installed OS/X and added to boot menu. >>> >>> The problem is, both 32 and 64 menu options crash during boot. Is it >>> supposed to work in the first place? If yes, which diagnostic I can >>> collect to debug it further? >> >> I suppose that the bootargs structure may have changed. I'll look into >> it, thank you for reporting. >> > > Any progress on it? What is the exact panic message? signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading OS/X 10.7 by grub x86_64-efi fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2013 01:26 PM, Andrey Borzenkov wrote: > ? Fri, 10 May 2013 14:18:42 +0200 > Vladimir '?-coder/phcoder' Serbinenko ?: > >> On 09.05.2013 20:32, Andrey Borzenkov wrote: >> >>> I have MacBook (Pro?) 3.1 with OS/X 10.7. I installed as second OS >>> openSUSE 12.3 using EFI CD boot (worked just fine) and x86_64-efi >>> grub2. I had to manually bless grub on EFI partition to actually boot >>> it. os-prober also found installed OS/X and added to boot menu. >>> >>> The problem is, both 32 and 64 menu options crash during boot. Is it >>> supposed to work in the first place? If yes, which diagnostic I can >>> collect to debug it further? >> >> I suppose that the bootargs structure may have changed. I'll look into >> it, thank you for reporting. >> > > Any progress on it? This has been reported by multiple users. If this > does not have chance to be fixed in reasonable timeframe, I'll rather > look at directly chainloading of /System/Library/CoreServices/boot.efi > instead of using xnu. That's what I've always done. Apple's EFI implementation is non-standard and sometimes different in each generation of its computers. I just therefore always chainload; it is more foolproof and works better than xnu anyway in my opinion. > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSljxPAAoJEFbRvtGxmFPElFEH/iXPsfZXrCnFJqWRYuZs9oJ+ Kdinirl6CAPAgSGwt/ygQzO9OsPA6+MKG2jaAi/hREDYSp509FG1ZIKLm4R3Zqa7 5WkSMBXELuoaJibSIFaQrNoiJ8C304sH1JBm95OiHQX7Kg/jDrtYGS89mIru2yd6 LQyjIIYR1gZR0RndJ3zg8jc0hOgvJqZecC0ZGtEwNbaI3wak8FFB9bCmI5EFbk6d ovGiBp3BdSYhUFaEIe8FGnsjKKe2zl9vP6G20McramWctgayjMRTNnyRnHzRG6EY J1tdzYQcgI4qf3/mE4bd18I045NIJYr0evllhIYDjKpqP/zvG7Ebr6lmB/PaGWY= =nbH7 -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] ls core command: handle listing of the root directory
What about this patch? Looks correct to me and reflects actual behavior.
В Sun, 02 Jun 2013 16:48:23 +0200
Francesco Lavra пишет:
> On 05/18/2013 12:26 PM, Francesco Lavra wrote:
> > On 05/12/2013 12:56 PM, Francesco Lavra wrote:
> >> Currently, listing of the root directory of a device with the command:
> >> ls (device_name)
> >> requires the underlying filesystem driver to handle an empty path
> >> string as if it was the root directory path "/". This introduces
> >> duplicated code across the different filesystem drivers. If a given
> >> filesystem driver does not implement special handling of the empty
> >> path string, the above command gives "error: invalid file name `'."
> >> This error happens for instance with the ext4 filesystem.
> >> The best place to handle correctly the empty path string and transform
> >> it in "/" is the function grub_core_cmd_ls(), so that handling from
> >> each filesystem driver is not required anymore.
> >
> > After revision 5010, issuing the ls command with a device name as
> > parameter gives a response such as:
> > (device_name): Filesystem is .
> > But grub.texi says:
> > "
> > @deffn Command ls [arg @dots{}]
> > List devices or files.
> >
> > With no arguments, print all devices known to GRUB.
> >
> > If the argument is a device name enclosed in parentheses (@pxref{Device
> > syntax}), then list all files at the root directory of that device.
> >
> > If the argument is a directory given as an absolute file name (@pxref{File
> > name syntax}), then list the contents of that directory.
> > @end deffn
> > "
> >
> > Which is the correct behavior?
>
> Depending on the answer to the above question, you might want to
> consider applying one of the two patches below, as you see fit.
>
> Regards,
> Francesco
>
> 2013-06-02 Francesco Lavra
>
> * docs/grub.texi (ls): Fix command description in case of a device name
> passed as argument.
>
> === modified file 'docs/grub.texi'
> --- docs/grub.texi2013-05-11 05:23:26 +
> +++ docs/grub.texi2013-06-02 14:35:24 +
> @@ -4049,7 +4049,7 @@
> With no arguments, print all devices known to GRUB.
>
> If the argument is a device name enclosed in parentheses (@pxref{Device
> -syntax}), then list all files at the root directory of that device.
> +syntax}), then print the name of the filesystem of that device.
>
> If the argument is a directory given as an absolute file name (@pxref{File
> name syntax}), then list the contents of that directory.
>
>
> 2013-06-02 Francesco Lavra
>
> * grub-core/kern/corecmd.c (grub_core_cmd_ls): Fix listing of root
> directory contents.
>
> === modified file 'grub-core/kern/corecmd.c'
> --- grub-core/kern/corecmd.c 2013-06-02 14:23:14 +
> +++ grub-core/kern/corecmd.c 2013-06-02 14:28:24 +
> @@ -147,13 +147,11 @@
>
>if (! *path)
> {
> - if (grub_errno == GRUB_ERR_UNKNOWN_FS)
> - grub_errno = GRUB_ERR_NONE;
> -
> - grub_printf ("(%s): Filesystem is %s.\n",
> -device_name, fs ? fs->name : "unknown");
> + /* The argument is a device name: list all files at the root directory
> + of the device. */
> + path = (char *) "/";
> }
> - else if (fs)
> + if (fs)
> {
> (fs->dir) (dev, path, grub_mini_print_files, NULL);
> grub_xputs ("\n");
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading OS/X 10.7 by grub x86_64-efi fails
On 27.11.2013 19:39, SevenBits wrote: > > On 11/27/2013 01:26 PM, Andrey Borzenkov wrote: >> ? Fri, 10 May 2013 14:18:42 +0200 >> Vladimir '?-coder/phcoder' Serbinenko ?: > >>> On 09.05.2013 20:32, Andrey Borzenkov wrote: >>> I have MacBook (Pro?) 3.1 with OS/X 10.7. I installed as second OS openSUSE 12.3 using EFI CD boot (worked just fine) and x86_64-efi grub2. I had to manually bless grub on EFI partition to actually boot it. os-prober also found installed OS/X and added to boot menu. The problem is, both 32 and 64 menu options crash during boot. Is it supposed to work in the first place? If yes, which diagnostic I can collect to debug it further? >>> >>> I suppose that the bootargs structure may have changed. I'll look into >>> it, thank you for reporting. >>> > >> Any progress on it? This has been reported by multiple users. If this >> does not have chance to be fixed in reasonable timeframe, I'll rather >> look at directly chainloading of /System/Library/CoreServices/boot.efi >> instead of using xnu. > That's what I've always done. Apple's EFI implementation is non-standard > and sometimes different in each generation of its computers. I just > therefore always chainload; it is more foolproof and works better than > xnu anyway in my opinion. > I stop this debate right here. That's besides the point. > > >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2013 07:22 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 25.11.2013 23:28, SevenBits wrote:
>>
>> On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko
>> wrote:
>>> On 25.11.2013 23:03, SevenBits wrote:
Thanks for your quick reply.
I just have a couple of questions. How do you prefer I allow
the user to specify the vendor UUID? By typing it in via the
keyboard? And secondly, by saying it needs "readable aliases
for known types" do you mean that there should be a function
to set an integer, one to set a boolean, etc?
>>> I meant for UUIDs. E.g. one alias "efi" for shared space,
>>> "apple" for apple and so on.
>> So other than a generic variable UUID and Apple, are there others
>> that you think might be necessary? I can try and put in some
>> common ones but manufacturers may not disclose what their
>> specific UUIDs are.
>>
> I'd include a command to list variables (interactively). We would
> pretty quickly collect most common UUIDs this way.
So, I've got a command written to print out the system's firmware
variables. Trouble is I'm not sure what the best way would be to print
or otherwise display the UUIDs gathered so that we can collect them.
Seeing as how I have an Apple computer as my only (U)EFI-enabled
machine I won't have a large sample set to use anyway... unless of
course you'd want to take the patch before it's feature complete so it
could get the rounds and gather common UUIDs.
Perhaps someone who has been with GRUB for awhile could advise me on
what the best course of action is in situations like this.
>>> But type of variable is also an issue and there should be at
>>> least following available: hex - transform all in hex utf16 -
>>> decode utf16 into utf8 Probably more, didn't really look into
>>> issue
>> I see, okay, I'll add some in.
>>
Regarding the patch format, I'll tidy that up and send a
proper one.
-- SevenBits
On 11/25/2013 04:41 PM, Vladimir 'phcoder' Serbinenko wrote:
> please resend as proper and not as reverse patch. Anotjer
> issie that
>> can be
> seen from description alone is that you don't allow to
> specify vendor
uuid.
> it would be needed and slso it needs readable aliases for
> known types On Nov 25, 2013 10:35 PM, "SevenBits"
> wrote:
>> Hello everyone,
>>
>> This patch adds two GRUB two commands to allow the user
>> to get and set the values of (U)EFI firmware variables.
>> When dealing with (U)EFI firmware with GRUB I decided
>> this would be a useful tool to have for both developers
>> and end-users.
>>
>> The first command, setefivariable, takes two parameters:
>> the name
>> of the
>> variable to set and its value. The second,
>> getefivariable, also takes two parameters: the name of
>> the variable to retrieve and the name
>> of the
>> GRUB environment variable in which you want to store the
>> result. This can then be checked using GRUB's built in
>> 'if' statement and scripting capability to allow unique
>> booting capabilities based on whether, for example,
>> secure boot is enabled or the (U)EFI firmware is in
>> setup
>> mode.
>>
>> Have a look and let me know what you think! The patch
>> follows.
>>
>> -- SevenBits
>>
>> diff --git a/grub/grub-core/Makefile.core.def
>> b/grub-orig/grub-core/Makefile.core.def index
>> 177d6d6..5cd84b1 100644 ---
>> a/grub/grub-core/Makefile.core.def +++
>> b/grub-orig/grub-core/Makefile.core.def @@ -1004,13
>> +1004,6 @@ module = { };
>>
>> module = { - name = setvariable; - common =
>> commands/efi/setvariable.c; - enable = i386_efi; -
>> enable = x86_64_efi; -}; - -module = { name = pcidump;
>> common = commands/pcidump.c; enable = pci; diff --git
>> a/grub/grub-core/commands/efi/setvariable.c
>> b/grub/grub-core/commands/efi/setvariable.c deleted file
>> mode 100644 index b0d0967..000 ---
>> a/grub/grub-core/commands/efi/setvariable.c +++
>> /dev/null @@ -1,96 +0,0 @@ -/* setvariable.c - get and
>> set efi firmware variables */ -/* - * GRUB -- GRand
>> Unified Bootloader - * Copyright (C) 2013 Free Software
>> Foundation, Inc. - * - * GRUB is free software: you can
>> redistribute it and/or modify - * it under the terms of
>> the GNU General Public License as
>> published by
>> - * the Free Software Foundation, either version 3 of
>> the License, or - * (at your option) any later version.
>> - * - * GRUB is distributed in the hope that it will be
>> useful, - * but WITHOUT ANY WARRANTY; without even the
>> implied warranty of - * MERCHANTABILITY or FITNESS FOR A
>> PARTICULAR PURPOSE. See the - * GNU General Public
>> License for more details. - * - * You should have
>> received a
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Wed, 27 Nov 2013 13:44:41 -0500 SevenBits пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/25/2013 07:22 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > On 25.11.2013 23:28, SevenBits wrote: > >> > >> On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko > >> wrote: > >>> On 25.11.2013 23:03, SevenBits wrote: > > Thanks for your quick reply. > > I just have a couple of questions. How do you prefer I allow > the user to specify the vendor UUID? By typing it in via the > keyboard? And secondly, by saying it needs "readable aliases > for known types" do you mean that there should be a function > to set an integer, one to set a boolean, etc? > > >>> I meant for UUIDs. E.g. one alias "efi" for shared space, > >>> "apple" for apple and so on. > >> So other than a generic variable UUID and Apple, are there others > >> that you think might be necessary? I can try and put in some > >> common ones but manufacturers may not disclose what their > >> specific UUIDs are. > >> > > I'd include a command to list variables (interactively). We would > > pretty quickly collect most common UUIDs this way. > > So, I've got a command written to print out the system's firmware > variables. Trouble is I'm not sure what the best way would be to print > or otherwise display the UUIDs gathered so that we can collect them. > I think it is rather premature at this point. What is needed first is sane framework for handling EFI variables, which means - handling GUID, options (during set or as filter in listing variables) and conversion of arbitrary binary data from/to external printable representation. > > >>> But type of variable is also an issue and there should be at > >>> least following available: hex - transform all in hex utf16 - > >>> decode utf16 into utf8 Probably more, didn't really look into > >>> issue > >> I see, okay, I'll add some in. > >> Yes, please. Adding aliases for GUID can always come later and is not really that important. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlKWQLAACgkQR6LMutpd94yMZgCg0vV8YWsgWPSDK+Zco9nZVfqI EbAAoKCo88yPOpD0IlDn/EiXZ1hnT7RY =XUV+ -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading OS/X 10.7 by grub x86_64-efi fails
On Nov 27, 2013, at 11:31 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 27.11.2013 19:26, Andrey Borzenkov wrote: >> >> Any progress on it? > What is the exact panic message? http://savannah.gnu.org/bugs/?39460 Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading OS/X 10.7 by grub x86_64-efi fails
On 27.11.2013 20:38, Chris Murphy wrote: > > On Nov 27, 2013, at 11:31 AM, Vladimir 'φ-coder/phcoder' Serbinenko > wrote: > >> On 27.11.2013 19:26, Andrey Borzenkov wrote: >>> >>> Any progress on it? >> What is the exact panic message? > > http://savannah.gnu.org/bugs/?39460 > Ok, that's helpful. I forgot about it. I'll look into it this weekend. > > Chris Murphy > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
On 27.11.2013 19:57, Andrey Borzenkov wrote: > В Wed, 27 Nov 2013 13:44:41 -0500 > SevenBits пишет: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > >> On 11/25/2013 07:22 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>> On 25.11.2013 23:28, SevenBits wrote: On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: > On 25.11.2013 23:03, SevenBits wrote: >> >> Thanks for your quick reply. >> >> I just have a couple of questions. How do you prefer I allow >> the user to specify the vendor UUID? By typing it in via the >> keyboard? And secondly, by saying it needs "readable aliases >> for known types" do you mean that there should be a function >> to set an integer, one to set a boolean, etc? >> > I meant for UUIDs. E.g. one alias "efi" for shared space, > "apple" for apple and so on. So other than a generic variable UUID and Apple, are there others that you think might be necessary? I can try and put in some common ones but manufacturers may not disclose what their specific UUIDs are. >>> I'd include a command to list variables (interactively). We would >>> pretty quickly collect most common UUIDs this way. > >> So, I've got a command written to print out the system's firmware >> variables. Trouble is I'm not sure what the best way would be to print >> or otherwise display the UUIDs gathered so that we can collect them. > > > I think it is rather premature at this point. Agreed. I wasn't clear enough that I meant that in the first implementation we need to put just few UUIDs we already know about as aliases and expand them with the time. > What is needed first is > sane framework for handling EFI variables, which means - handling GUID, > options (during set or as filter in listing variables) and conversion of > arbitrary binary data from/to external printable representation. > > > But type of variable is also an issue and there should be at > least following available: hex - transform all in hex utf16 - > decode utf16 into utf8 Probably more, didn't really look into > issue I see, okay, I'll add some in. > > > Yes, please. Adding aliases for GUID can always come later and is not > really that important. > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
On Mon, Oct 21, 2013 at 02:45:04PM +0800, Franz Hsieh wrote:
> I don't know if l lose any update from you. Would you give me comments
> about the latest hotkey patch?
Vladimir and I talked about this on IRC today. We share a dislike for
the hardcoded hotkey names. Between us, we came up with a better plan:
* The simplest way to work out what hotkeys to honour is to introspect
the menu structure itself. However, this can only be done after all
the top-level commands in grub.cfg have been executed, so it can't be
done in the "sleep" command.
* There's nothing particular that says that we have to implement the
hidden timeout in a "sleep" command, although we have to take some
care to ensure configuration file compatibility with older modules.
Since the main timeout is implemented in normal.mod, it makes some
sense for the hidden timeout to go there too, where we can get at the
menu structure.
* The simplest way to arrange for configuration file compatibility is
to add a new "hiddentimeout" command that sets a "hidden_timeout"
environment variable; we could also set the environment variable
directly, but having a command allows us to detect the absence of
that command and infer that we need to fall back to the old
mechanism.
Here's a candidate patch. This does duplicate "sleep" a little bit, but
it has the great advantages of not duplicating the list of valid hotkeys
and of only honouring hotkeys that are associated with menu entries.
Add a new "hiddentimeout" command. If this is used, then the
menu will use a hidden timeout much as was previously done with "sleep
--interruptible", except that pressing any hotkeys associated with menu
entries will boot the corresponding menu entry immediately.
---
ChangeLog | 7 ++
docs/grub.texi | 39 ++--
grub-core/Makefile.core.def| 5 ++
grub-core/commands/hiddentimeout.c | 68 ++
grub-core/normal/menu.c| 177 -
util/grub.d/00_header.in | 6 +-
6 files changed, 271 insertions(+), 31 deletions(-)
create mode 100644 grub-core/commands/hiddentimeout.c
diff --git a/ChangeLog b/ChangeLog
index d24f533..cfca08a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-11-27 Colin Watson
+
+ Add a new "hiddentimeout" command. If this is used, then the menu
+ will use a hidden timeout much as was previously done with "sleep
+ --interruptible", except that pressing any hotkeys associated with
+ menu entries will boot the corresponding menu entry immediately.
+
2013-11-27 Vladimir Serbinenko
Eliminate variable length arrays in grub_vsnprintf_real.
diff --git a/docs/grub.texi b/docs/grub.texi
index 6aee292..3b92105 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1299,13 +1299,19 @@ immediately without displaying the menu, or to
@samp{-1} to wait
indefinitely.
@item GRUB_HIDDEN_TIMEOUT
-Wait this many seconds for @key{ESC} to be pressed before displaying the menu.
-If no @key{ESC} is pressed during that time, display the menu for the number of
-seconds specified in GRUB_TIMEOUT before booting the default entry. We expect
-that most people who use GRUB_HIDDEN_TIMEOUT will want to have GRUB_TIMEOUT
set
-to @samp{0} so that the menu is not displayed at all unless @key{ESC} is
-pressed.
-Unset by default.
+Wait this many seconds for @key{ESC} or a hotkey associated with a menu
+entry to be pressed before displaying the menu. If @key{ESC} is pressed,
+display the menu and wait for input according to @samp{GRUB_TIMEOUT}. If a
+hotkey is pressed, boot the associated menu entry immediately. If the
+timeout expires before either of these happens, display the menu for the
+number of seconds specified in @samp{GRUB_TIMEOUT} before booting the
+default entry.
+
+We expect that most people who use @samp{GRUB_HIDDEN_TIMEOUT} will want to
+have @samp{GRUB_TIMEOUT} set to @samp{0} so that the menu is not displayed
+at all unless @key{ESC} is pressed.
+
+This option is unset by default.
@item GRUB_HIDDEN_TIMEOUT_QUIET
In conjunction with @samp{GRUB_HIDDEN_TIMEOUT}, set this to @samp{true} to
@@ -3736,6 +3742,7 @@ you forget a command, you can run the command
@command{help}
* halt::Shut down your computer
* hashsum:: Compute or check hash checksum
* help::Show help messages
+* hiddentimeout:: Configure the hidden menu timeout
* initrd:: Load a Linux initrd
* initrd16::Load a Linux initrd (16-bit mode)
* insmod:: Insert a module
@@ -4243,6 +4250,24 @@ about each of the commands whose names begin with those
@var{patterns}.
@end deffn
+@node hiddentimeout
+@subsection hiddentimeout
+
+@deffn Command hiddentimeout [@option{--visible-timeout} timeout] timeout
+Configure the @samp{normal} module (@
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
Following discussion with Vladimir on IRC, here's another attempt. The
preferred user-facing configuration mechanism is now simpler, although
some unfortunate compatibility code is required to make all this work.
Revamp hidden timeout handling
Add a new timeout_style environment variable and a corresponding
GRUB_TIMEOUT_STYLE configuration key for grub-mkconfig. This
controls hidden-timeout handling more simply than the previous
arrangements, and pressing any hotkeys associated with menu entries
during the hidden timeout will now boot the corresponding menu entry
immediately.
GRUB_HIDDEN_TIMEOUT= + GRUB_TIMEOUT= now
generates a warning, and if it shows the menu it will do so as if
the second timeout were not present. Other combinations are
translated into reasonable equivalents.
---
ChangeLog| 14
docs/grub.texi | 57 ---
grub-core/normal/main.c | 2 +-
grub-core/normal/menu.c | 175 +--
util/grub-mkconfig.in| 1 +
util/grub.d/00_header.in | 35 +-
6 files changed, 251 insertions(+), 33 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d24f533..4cc4562 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2013-11-28 Colin Watson
+
+ Add a new timeout_style environment variable and a corresponding
+ GRUB_TIMEOUT_STYLE configuration key for grub-mkconfig. This
+ controls hidden-timeout handling more simply than the previous
+ arrangements, and pressing any hotkeys associated with menu entries
+ during the hidden timeout will now boot the corresponding menu entry
+ immediately.
+
+ GRUB_HIDDEN_TIMEOUT= + GRUB_TIMEOUT= now
+ generates a warning, and if it shows the menu it will do so as if
+ the second timeout were not present. Other combinations are
+ translated into reasonable equivalents.
+
2013-11-27 Vladimir Serbinenko
Eliminate variable length arrays in grub_vsnprintf_real.
diff --git a/docs/grub.texi b/docs/grub.texi
index 6aee292..f494a3d 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1298,19 +1298,46 @@ a key is pressed. The default is @samp{5}. Set to
@samp{0} to boot
immediately without displaying the menu, or to @samp{-1} to wait
indefinitely.
+If @samp{GRUB_TIMEOUT_STYLE} is set to @samp{countdown} or @samp{hidden},
+the timeout is instead counted before the menu is displayed.
+
+@item GRUB_TIMEOUT_STYLE
+If this option is unset or set to @samp{menu}, then GRUB will display the
+menu and then wait for the timeout set by @samp{GRUB_TIMEOUT} to expire
+before booting the default entry. Pressing a key interrupts the timeout.
+
+If this option is set to @samp{countdown} or @samp{hidden}, then, before
+displaying the menu, GRUB will wait for the timeout set by
+@samp{GRUB_TIMEOUT} to expire. If @key{ESC} is pressed during that time, it
+will display the menu and wait for input according to @samp{GRUB_TIMEOUT}.
+If a hotkey associated with a menu entry is pressed, it will boot the
+associated menu entry immediately. If the timeout expires before either of
+these happens, it will display the menu. In the @samp{countdown} case, it
+will show a one-line indication of the remaining time.
+
@item GRUB_HIDDEN_TIMEOUT
-Wait this many seconds for @key{ESC} to be pressed before displaying the menu.
-If no @key{ESC} is pressed during that time, display the menu for the number of
-seconds specified in GRUB_TIMEOUT before booting the default entry. We expect
-that most people who use GRUB_HIDDEN_TIMEOUT will want to have GRUB_TIMEOUT
set
-to @samp{0} so that the menu is not displayed at all unless @key{ESC} is
-pressed.
-Unset by default.
+Wait this many seconds before displaying the menu. If @key{ESC} is pressed
+during that time, display the menu and wait for input according to
+@samp{GRUB_TIMEOUT}. If a hotkey associated with a menu entry is pressed,
+boot the associated menu entry immediately. If the timeout expires before
+either of these happens, display the menu for the number of seconds
+specified in @samp{GRUB_TIMEOUT} before booting the default entry.
+
+If you set @samp{GRUB_HIDDEN_TIMEOUT}, you should also set
+@samp{GRUB_TIMEOUT=0} so that the menu is not displayed at all unless
+@key{ESC} is pressed.
+
+This option is unset by default, and is deprecated in favour of the less
+confusing @samp{GRUB_TIMEOUT_STYLE=countdown} or
+@samp{GRUB_TIMEOUT_STYLE=hidden}.
@item GRUB_HIDDEN_TIMEOUT_QUIET
In conjunction with @samp{GRUB_HIDDEN_TIMEOUT}, set this to @samp{true} to
suppress the verbose countdown while waiting for a key to be pressed before
-displaying the menu. Unset by default.
+displaying the menu.
+
+This option is unset by default, and is deprecated in favour of the less
+confusing @samp{GRUB_TIMEOUT_STYLE=countdown}.
@item GRUB_DEFAULT_BUTTON
@itemx GRUB_TIMEOUT_BUTTON
@@ -3030,6 +3057,7 @@ These variables have special meaning to GRUB.
* superusers::
* theme::
* ti
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
On Nov 28, 2013 3:31 AM, "Colin Watson" wrote:
>
> Following discussion with Vladimir on IRC, here's another attempt. The
> preferred user-facing configuration mechanism is now simpler, although
> some unfortunate compatibility code is required to make all this work.
>
> Revamp hidden timeout handling
>
> Add a new timeout_style environment variable and a corresponding
> GRUB_TIMEOUT_STYLE configuration key for grub-mkconfig. This
> controls hidden-timeout handling more simply than the previous
> arrangements, and pressing any hotkeys associated with menu entries
> during the hidden timeout will now boot the corresponding menu entry
> immediately.
>
> GRUB_HIDDEN_TIMEOUT= + GRUB_TIMEOUT= now
> generates a warning, and if it shows the menu it will do so as if
> the second timeout were not present. Other combinations are
> translated into reasonable equivalents.
> ---
> ChangeLog| 14
> docs/grub.texi | 57 ---
> grub-core/normal/main.c | 2 +-
> grub-core/normal/menu.c | 175
+--
> util/grub-mkconfig.in| 1 +
> util/grub.d/00_header.in | 35 +-
> 6 files changed, 251 insertions(+), 33 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index d24f533..4cc4562 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,17 @@
> +2013-11-28 Colin Watson
> +
> + Add a new timeout_style environment variable and a corresponding
> + GRUB_TIMEOUT_STYLE configuration key for grub-mkconfig. This
> + controls hidden-timeout handling more simply than the previous
> + arrangements, and pressing any hotkeys associated with menu
entries
> + during the hidden timeout will now boot the corresponding menu
entry
> + immediately.
> +
> + GRUB_HIDDEN_TIMEOUT= + GRUB_TIMEOUT= now
> + generates a warning, and if it shows the menu it will do so as if
> + the second timeout were not present. Other combinations are
> + translated into reasonable equivalents.
> +
> 2013-11-27 Vladimir Serbinenko
>
> Eliminate variable length arrays in grub_vsnprintf_real.
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 6aee292..f494a3d 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -1298,19 +1298,46 @@ a key is pressed. The default is @samp{5}. Set
to @samp{0} to boot
> immediately without displaying the menu, or to @samp{-1} to wait
> indefinitely.
>
> +If @samp{GRUB_TIMEOUT_STYLE} is set to @samp{countdown} or @samp{hidden},
> +the timeout is instead counted before the menu is displayed.
> +
> +@item GRUB_TIMEOUT_STYLE
> +If this option is unset or set to @samp{menu}, then GRUB will display the
> +menu and then wait for the timeout set by @samp{GRUB_TIMEOUT} to expire
> +before booting the default entry. Pressing a key interrupts the timeout.
> +
> +If this option is set to @samp{countdown} or @samp{hidden}, then, before
> +displaying the menu, GRUB will wait for the timeout set by
> +@samp{GRUB_TIMEOUT} to expire. If @key{ESC} is pressed during that
time, it
> +will display the menu and wait for input according to
@samp{GRUB_TIMEOUT}.
> +If a hotkey associated with a menu entry is pressed, it will boot the
> +associated menu entry immediately. If the timeout expires before either
of
> +these happens, it will display the menu.
What you describe here doesn‘t serm what code is doing. Copypaste error?
> In the @samp{countdown} case, it
> +will show a one-line indication of the remaining time.
> +
> @item GRUB_HIDDEN_TIMEOUT
> -Wait this many seconds for @key{ESC} to be pressed before displaying the
menu.
> -If no @key{ESC} is pressed during that time, display the menu for the
number of
> -seconds specified in GRUB_TIMEOUT before booting the default entry. We
expect
> -that most people who use GRUB_HIDDEN_TIMEOUT will want to have
GRUB_TIMEOUT set
> -to @samp{0} so that the menu is not displayed at all unless @key{ESC} is
> -pressed.
> -Unset by default.
> +Wait this many seconds before displaying the menu. If @key{ESC} is
pressed
> +during that time, display the menu and wait for input according to
> +@samp{GRUB_TIMEOUT}. If a hotkey associated with a menu entry is
pressed,
> +boot the associated menu entry immediately. If the timeout expires
before
> +either of these happens, display the menu for the number of seconds
> +specified in @samp{GRUB_TIMEOUT} before booting the default entry.
> +
> +If you set @samp{GRUB_HIDDEN_TIMEOUT}, you should also set
> +@samp{GRUB_TIMEOUT=0} so that the menu is not displayed at all unless
> +@key{ESC} is pressed.
> +
> +This option is unset by default, and is deprecated in favour of the less
> +confusing @samp{GRUB_TIMEOUT_STYLE=countdown} or
> +@samp{GRUB_TIMEOUT_STYLE=hidden}.
>
> @item GRUB_HIDDEN_TIMEOUT_QUIET
> In conjunction with @samp{GRUB_HIDDEN_TIMEOUT}, set this to @samp{true}
to
> suppress the verbose countdown while waiting for a key to be pressed
before
> -displaying the menu. Unset by d
Re: [PATCH 2/2] ls core command: handle listing of the root directory
this very confusing with 2 opposite patches in same mail. I don't have my
keys here. Feel free to commit documentation patch. If you commit on
Francesco's behalf don't forget --author
On Nov 27, 2013 7:42 PM, "Andrey Borzenkov" wrote:
> What about this patch? Looks correct to me and reflects actual behavior.
>
>
> В Sun, 02 Jun 2013 16:48:23 +0200
> Francesco Lavra пишет:
>
> > On 05/18/2013 12:26 PM, Francesco Lavra wrote:
> > > On 05/12/2013 12:56 PM, Francesco Lavra wrote:
> > >> Currently, listing of the root directory of a device with the command:
> > >> ls (device_name)
> > >> requires the underlying filesystem driver to handle an empty path
> > >> string as if it was the root directory path "/". This introduces
> > >> duplicated code across the different filesystem drivers. If a given
> > >> filesystem driver does not implement special handling of the empty
> > >> path string, the above command gives "error: invalid file name `'."
> > >> This error happens for instance with the ext4 filesystem.
> > >> The best place to handle correctly the empty path string and transform
> > >> it in "/" is the function grub_core_cmd_ls(), so that handling from
> > >> each filesystem driver is not required anymore.
> > >
> > > After revision 5010, issuing the ls command with a device name as
> > > parameter gives a response such as:
> > > (device_name): Filesystem is .
> > > But grub.texi says:
> > > "
> > > @deffn Command ls [arg @dots{}]
> > > List devices or files.
> > >
> > > With no arguments, print all devices known to GRUB.
> > >
> > > If the argument is a device name enclosed in parentheses (@pxref{Device
> > > syntax}), then list all files at the root directory of that device.
> > >
> > > If the argument is a directory given as an absolute file name
> (@pxref{File
> > > name syntax}), then list the contents of that directory.
> > > @end deffn
> > > "
> > >
> > > Which is the correct behavior?
> >
> > Depending on the answer to the above question, you might want to
> > consider applying one of the two patches below, as you see fit.
> >
> > Regards,
> > Francesco
> >
> > 2013-06-02 Francesco Lavra
> >
> > * docs/grub.texi (ls): Fix command description in case of a device
> name
> > passed as argument.
> >
> > === modified file 'docs/grub.texi'
> > --- docs/grub.texi2013-05-11 05:23:26 +
> > +++ docs/grub.texi2013-06-02 14:35:24 +
> > @@ -4049,7 +4049,7 @@
> > With no arguments, print all devices known to GRUB.
> >
> > If the argument is a device name enclosed in parentheses (@pxref{Device
> > -syntax}), then list all files at the root directory of that device.
> > +syntax}), then print the name of the filesystem of that device.
> >
> > If the argument is a directory given as an absolute file name
> (@pxref{File
> > name syntax}), then list the contents of that directory.
> >
> >
> > 2013-06-02 Francesco Lavra
> >
> > * grub-core/kern/corecmd.c (grub_core_cmd_ls): Fix listing of root
> > directory contents.
> >
> > === modified file 'grub-core/kern/corecmd.c'
> > --- grub-core/kern/corecmd.c 2013-06-02 14:23:14 +
> > +++ grub-core/kern/corecmd.c 2013-06-02 14:28:24 +
> > @@ -147,13 +147,11 @@
> >
> >if (! *path)
> > {
> > - if (grub_errno == GRUB_ERR_UNKNOWN_FS)
> > - grub_errno = GRUB_ERR_NONE;
> > -
> > - grub_printf ("(%s): Filesystem is %s.\n",
> > -device_name, fs ? fs->name : "unknown");
> > + /* The argument is a device name: list all files at the root
> directory
> > + of the device. */
> > + path = (char *) "/";
> > }
> > - else if (fs)
> > + if (fs)
> > {
> > (fs->dir) (dev, path, grub_mini_print_files, NULL);
> > grub_xputs ("\n");
> >
> > ___
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkimage and other utils documentation
Main user tools are install mknetdir mkrescue mkstandalone editenv mkconfig mkfont mklayout. Skip setup it's useful to have around for devs but has no interface stability and generally better be left alone. Thank you very much for taking care of this On Nov 26, 2013 5:41 PM, "Andrey Borzenkov" wrote: > I started to clean --pubkey in docs, hit grub-mkimage reference, hit > "grub-install is just a shell script" ... it really needs cleanup. Is > grub-install terse description intentional? If not, I'm going to > actually document all utilities and all options not defined as hidden. > We probably need to mention common options between various utilities > as well. > > Or should some tools be skipped? I'm fine to document them in > grub-devel though, but I'd like to have them documented /somewhere/. > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v0] Require human interaction to go to normal shell if grub.cfg has a problem
Just a wild idea perhaps we should embed osdetect.cfg in normal.mod in some
form. It would be pretty much the easy solution for many cases.
On Nov 26, 2013 12:47 AM, "Jon McCune" wrote:
> The rescue prompt is very useful for human operators, but not so
> useful in unattended environments. Add a facility for rebooting
> after a delay, so that, e.g., the system can still PXE boot if
> there is no console attached.
>
> Signed-off-by: Jon McCune
> ---
> grub-core/normal/main.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
> index ad36273..f8953d5 100644
> --- a/grub-core/normal/main.c
> +++ b/grub-core/normal/main.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> GRUB_MOD_LICENSE ("GPLv3+");
>
> @@ -333,6 +334,21 @@ grub_normal_execute (const char *config, int nested,
> int batch)
> }
> }
>
> +/* Copied from grub-core/commands/sleep.c. */
> +static int
> +grub_interruptible_millisleep (grub_uint32_t ms)
> +{
> + grub_uint64_t start;
> +
> + start = grub_get_time_ms ();
> +
> + while (grub_get_time_ms () - start < ms)
> +if (grub_getkey_noblock () == GRUB_TERM_ESC)
> + return 1;
> +
> + return 0;
> +}
> +
> /* This starts the normal mode. */
> void
> grub_enter_normal_mode (const char *config)
> @@ -340,6 +356,15 @@ grub_enter_normal_mode (const char *config)
>grub_boot_time ("Entering normal mode");
>nested_level++;
>grub_normal_execute (config, 0, 0);
> + /* Control only returns from grub_normal_execute() if there is some
> kind of
> + * problem with grub.cfg, like it does not exist. Reboot by default
> unless
> + * ESC is pressed within 5 seconds. */
> + grub_printf ("Press ESC in 5 seconds for a rescue shell.\n");
> + if (!grub_interruptible_millisleep (5000))
> +{
> + grub_printf ("Rebooting instead of going to rescue shell.\n");
> + grub_reboot ();
> +}
>grub_boot_time ("Entering shell");
>grub_cmdline_run (0);
>nested_level--;
> --
> 1.8.4.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GIT workflow
I don't like the idea of double work to essentially have 2 commit messages. But it's possible to remove Changelog file. I'd like to know if any other major gnu projects made the move. On Nov 25, 2013 7:27 PM, "Andrey Borzenkov" wrote: > В Thu, 14 Nov 2013 15:20:10 +0200 > Mikko Rantalainen пишет: > > > Vladimir 'φ-coder/phcoder' Serbinenko, 2013-11-10 19:01 > (Europe/Helsinki): > > > Hello, all. We've switched to git some time ago, now we should have > some > > > kind of workflow documents. In particular I think of following points: > > > - Developpers with commit access can create branches as they see fit as > > > long as it's prefixed by their name and they don't do sth nasty like > > > storing binary or unrelated files. > > > - When committing bigger work should we merge or squash? I think that > > > squash should be possible if developper desires. Is there any reason to > > > use merges? > > > > Squashed merge is identical to rebase && merge --no-ff except for the > > detail that squashing loses any meaningful history for the patch series. > > I'd seriously suggest rebase followed by merge --no-ff over squashed > > merges. The only exception is the case where commits in the original > > work are not logical patches but instead random snapshots of the > > directory tree during development of the patch. In that case, squashing > > the patch series loses no valuable information. > > > > The reason to keep patch series: git bisect > > > > Also squash is losing individual contribution. > > I think it really depends. For simple patches that are self-contained > squash is actually better; that is basically what TopGIT does to > maintain patches. For anything developed over long time history should > be preserved (a.k.a. merge). > > > > - Which commits should we sign? All? Some? Official releases? > > > > Depends on what you mean by "sign". If you mean > > > >Signed-off-by: A U Thor > > > > that's the "Developer Certificate Of Origin": > > http://elinux.org/Developer_Certificate_Of_Origin > > > > Other projects (e.g Grub) can decide their own policy for such metadata. > > Additional info is available at > > > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for > > > > If you mean digitally signed, the correct method is to use signed tags > > for all the releases meant for non-developers. See "git help tag" and > > look for "--sign". > > > > Release tags should better be signed; is there official key to be used > in this case? > > I have additional topic > > - format of commit message > > Established GIT commit message is single summary line followed by more > extensive description if necessary. Quite a number of git commands and > wrappers around git assume that the summary line is present. Currently > commit message format is near to useless. Half of the first line is > lost for file name; the second half is partial sentence, often > meaningless. > > Could we break with tradition "commit message" == "ChangeLog entry"? > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
