Grub 2.02
Is there an estimated time frame for the release of the stable 2.02 version of grub? The Linux From Scratch project is planning a new release around March 1st and would really like to update to a grub stable release. -- Bruce Dubbs linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub-install check for errors from efibootmgr
On Thu, Feb 09, 2017 at 09:52:40PM +0300, Andrei Borzenkov wrote: >30.01.2017 22:04, Steve McIntyre пишет: >> Code is currently ignoring errors from efibootmgr, giving users >> clearly bogus output like: >> >> Setting up grub-efi-amd64 (2.02~beta3-4) ... >> Installing for x86_64-efi platform. >> Could not delete variable: No space left on device >> Could not prepare Boot variable: No space left on device >> Installation finished. No error reported. >> >> and then potentially unbootable systems. If efibootmgr fails, >> grub-install should know that and report it! > >This looks more or less cosmetic to me. First, errors are displayed to >user so it is not that user is not aware. Maybe, maybe not - if this occurs in the middle of a set of package installations or upgrades on a system, text like this will get lost. >Second, efibootmgr is more or less optional. This is convenient but >by far not the only one possibility to use newly installed >grub. If you're running on a UEFI system, this is anything *but* optional. >Third, even successful execution of efibootmgr does not mean it will >actually boot grub - there are enough systems out there that will >simply ditch grub entry and replace it with hard coded Windows one. That's not an excuse for not catching errors on systems that *are* working. >So I'm fine with changing "no error reported" to "efibootmgr invocation >failed; check your firmware settings" or similar, but I am not sure we >need to abort grub-install in this case. What exact problem do you solve >by aborting? You pick up an error correctly, and report it upwards so that other programs calling grub-install can reliably check for errors, and maybe deal with those errors. I don't see why it's a problem to actually handle errors properly? In Debian we're seeing quite a few people reporting problems in this area. It would be better to catch and handle errors better here. See https://bugs.debian.org/852513 for an example. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Quation about build grub source code
09.02.2017 19:46, Andre Bigijani пишет: > hi, > I'm develop my own simple os and for boot it i wants to use grub > how can i compile grub source code with cygwin64 in windows for get > loader.o file? > INSTALL lists prerequisite packages and how to build from snaoshot. If you follow INSTALL and get errors during build, post them here. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Quation about build grub source code
hi, I'm develop my own simple os and for boot it i wants to use grub how can i compile grub source code with cygwin64 in windows for get loader.o file? thank you. -- -- Best Regards, Andre Bigijani Email: andx7...@gmail.com ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub-install check for errors from efibootmgr
30.01.2017 22:04, Steve McIntyre пишет:
> Code is currently ignoring errors from efibootmgr, giving users
> clearly bogus output like:
>
> Setting up grub-efi-amd64 (2.02~beta3-4) ...
> Installing for x86_64-efi platform.
> Could not delete variable: No space left on device
> Could not prepare Boot variable: No space left on device
> Installation finished. No error reported.
>
> and then potentially unbootable systems. If efibootmgr fails,
> grub-install should know that and report it!
>
This looks more or less cosmetic to me. First, errors are displayed to
user so it is not that user is not aware. Second, efibootmgr is more or
less optional. This is convenient but by far not the only one
possibility to use newly installed grub. Third, even successful
execution of efibootmgr does not mean it will actually boot grub - there
are enough systems out there that will simply ditch grub entry and
replace it with hard coded Windows one.
So I'm fine with changing "no error reported" to "efibootmgr invocation
failed; check your firmware settings" or similar, but I am not sure we
need to abort grub-install in this case. What exact problem do you solve
by aborting?
> Signed-off-by: Steve McIntyre <93...@debian.org>
> ---
> grub-core/osdep/unix/platform.c | 24 +++-
> include/grub/util/install.h | 2 +-
> util/grub-install.c | 14 +++---
> 3 files changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/grub-core/osdep/unix/platform.c b/grub-core/osdep/unix/platform.c
> index 28cb37e..f9c376c 100644
> --- a/grub-core/osdep/unix/platform.c
> +++ b/grub-core/osdep/unix/platform.c
> @@ -78,19 +78,20 @@ get_ofpathname (const char *dev)
> dev);
> }
>
> -static void
> +static int
> grub_install_remove_efi_entries_by_distributor (const char *efi_distributor)
> {
>int fd;
>pid_t pid = grub_util_exec_pipe ((const char * []){ "efibootmgr", NULL },
> &fd);
>char *line = NULL;
>size_t len = 0;
> + int error = 0;
>
>if (!pid)
> {
>grub_util_warn (_("Unable to open stream from %s: %s"),
> "efibootmgr", strerror (errno));
> - return;
> + return errno;
> }
>
>FILE *fp = fdopen (fd, "r");
> @@ -98,7 +99,7 @@ grub_install_remove_efi_entries_by_distributor (const char
> *efi_distributor)
> {
>grub_util_warn (_("Unable to open stream from %s: %s"),
> "efibootmgr", strerror (errno));
> - return;
> + return errno;
> }
>
>line = xmalloc (80);
> @@ -119,23 +120,25 @@ grub_install_remove_efi_entries_by_distributor (const
> char *efi_distributor)
>bootnum = line + sizeof ("Boot") - 1;
>bootnum[4] = '\0';
>if (!verbosity)
> - grub_util_exec ((const char * []){ "efibootmgr", "-q",
> + error = grub_util_exec ((const char * []){ "efibootmgr", "-q",
> "-b", bootnum, "-B", NULL });
>else
> - grub_util_exec ((const char * []){ "efibootmgr",
> + error = grub_util_exec ((const char * []){ "efibootmgr",
> "-b", bootnum, "-B", NULL });
> }
>
>free (line);
> + return error;
> }
>
> -void
> +int
> grub_install_register_efi (grub_device_t efidir_grub_dev,
> const char *efifile_path,
> const char *efi_distributor)
> {
>const char * efidir_disk;
>int efidir_part;
> + int error = 0;
>efidir_disk = grub_util_biosdisk_get_osdev (efidir_grub_dev->disk);
>efidir_part = efidir_grub_dev->disk->partition ?
> efidir_grub_dev->disk->partition->number + 1 : 1;
>
> @@ -151,23 +154,26 @@ grub_install_register_efi (grub_device_t
> efidir_grub_dev,
>grub_util_exec ((const char * []){ "modprobe", "-q", "efivars", NULL });
> #endif
>/* Delete old entries from the same distributor. */
> - grub_install_remove_efi_entries_by_distributor (efi_distributor);
> + error = grub_install_remove_efi_entries_by_distributor (efi_distributor);
> + if (error)
> +return error;
>
>char *efidir_part_str = xasprintf ("%d", efidir_part);
>
>if (!verbosity)
> -grub_util_exec ((const char * []){ "efibootmgr", "-q",
> +error = grub_util_exec ((const char * []){ "efibootmgr", "-q",
> "-c", "-d", efidir_disk,
> "-p", efidir_part_str, "-w",
> "-L", efi_distributor, "-l",
> efifile_path, NULL });
>else
> -grub_util_exec ((const char * []){ "efibootmgr",
> +error = grub_util_exec ((const char * []){ "efibootmgr",
> "-c", "-d", efidir_disk,
> "-p", efidir_part_str, "-w",
> "-L", efi_distributor, "-l",
> efifile_path, NULL });
>free (efidir_part_str);
> + return error;
> }
>
> void
> diff --git a/include/grub/util/install.h b/include/grub/util/install.h
> index 9f517a1..58648e2 100644
> --- a/include/grub/util/install.h
> +++ b/include/grub/util/install.h
> @@ -209,7 +209,7 @@ grub
Re: explicit refresh?
08.02.2017 11:29, Laszlo Ersek пишет: > Hi, > > this is a dumb question and it's not appropriate for a development > mailing list, but I couldn't find "grub-user" or "grub-users", so I'll > ask here anyway... > there is help-g...@gnu.org > My laptop is connected to my workstation via USB-serial (USB for the > laptop, serial for the workstation). Sometimes, by the time the laptop > comes up and starts "screen", for viewing the serial output from the > workstation, the workstation is already displaying the grub menu. > Occasionally in this case, I can't see anything at all, there's no grub > countdown, the cursor up/down keys do nothing (they certainly don't > refresh the screen), but if I blindly press Enter, then the selected > kernel entry is booted okay (and that kernel does produce serial output, > and takes the LUKS password from serial fine as well). > > So, Q1: what could cause the loss of serial output from grub when I > connect to it "too late"? > > Q2: when that happens, can I press something like C-r to force a full > serial / screen refresh? > There are no hot keys for "refresh everything". May be adding it would be not so bad idea. > I know that USB-serial adaptors are generally wacky, but this is a > Prolific PL2303 adaptor which is (to my knowlede) usually considered > reliable. Plus, my laptop has no physical RS/232 port (shame on you, all > laptop vendors of today!), so this is the best I can do. > > Thanks, > Laszlo > > ___ > 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
