Re: [GRUB PARTUUID PATCH V10 4/4] Update grub script template files
On Mon, Apr 16, 2018 at 10:36:26PM -0700, Nicholas Vinson wrote:
> Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
> partuuid target. Update grub.texi documentation. The following table
> shows how GRUB_DISABLE_LINUX_UUID, GRUB_DISABLE_LINUX_PARTUUID, and
> initramfs detection interact:
>
> Initramfs GRUB_DISABLE_LINUX_PARTUUID GRUB_DISABLE_LINUX_UUID Linux Root
> detected Set Set ID Method
>
> false falsefalsepart UUID
> false falsetrue part UUID
> false true falsedev name
> false true true dev name
> true falsefalsefs UUID
> true falsetrue part UUID
> true true falsefs UUID
> true true true dev name
>
> Note: GRUB_DISABLE_LINUX_PARTUUID and GRUB_DISABLE_LINUX_UUID equate to
> 'false' when unset or set to any value other than 'true'.
> GRUB_DISABLE_LINUX_PARTUUID defaults to 'true'.
> Signed-off-by: Nicholas Vinson
> ---
> docs/grub.texi | 67 ++---
> util/grub-mkconfig.in | 3 ++
> util/grub.d/10_linux.in | 22 ++--
> util/grub.d/20_linux_xen.in | 22 ++--
> 4 files changed, 104 insertions(+), 10 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 0f2ab91fc..6aa65552f 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -1214,10 +1214,11 @@ GRUB is configured using @file{grub.cfg}, usually
> located under
> need to write the whole thing by hand.
>
> @menu
> -* Simple configuration::Recommended for most users
> -* Shell-like scripting::For power users and developers
> -* Multi-boot manual config::For non-standard multi-OS scenarios
> -* Embedded configuration:: Embedding a configuration file into GRUB
> +* Simple configuration::Recommended for most users
> +* Root Identifcation Heuristics:: Summary on how the root file system is
> identified.
> +* Shell-like scripting::For power users and developers
> +* Multi-boot manual config::For non-standard multi-OS scenarios
> +* Embedded configuration:: Embedding a configuration file into GRUB
> @end menu
>
>
> @@ -1425,6 +1426,17 @@ the Linux kernel, using a @samp{root=UUID=...} kernel
> parameter. This is
> usually more reliable, but in some cases it may not be appropriate. To
> disable the use of UUIDs, set this option to @samp{true}.
>
> +@item GRUB_DISABLE_LINUX_PARTUUID
> +If @command{grub-mkconfig} cannot identify the root filesystem via its
> +universally-unique indentifier (UUID), @command{grub-mkconfig} can use the
> UUID
> +of the partition containing the filesystem to identify the root filesystem to
> +the Linux kernel via a @samp{root=PARTUUID=...} kernel parameter. This is
> not
> +as reliable as using the filesystem UUID, but is more reliable than using the
> +Linux device names. When @samp{GRUB_DISABLE_LINUX_PARTUUID} is set to
> +@samp{false}, the Linux kernel version must be 2.6.37 (3.10 for systems using
> +the MSDOS partition scheme) or newer. This option defaults to @samp{true}.
> To
> +enable the use of partition UUIDs, set this option to @samp{false}.
> +
> @item GRUB_DISABLE_RECOVERY
> If this option is set to @samp{true}, disable the generation of recovery
> mode menu entries.
> @@ -1556,6 +1568,53 @@ edit the scripts in @file{/etc/grub.d} directly.
> menu entries; simply type the menu entries you want to add at the end of
> that file, making sure to leave at least the first two lines intact.
>
> +@node Root Identifcation Heuristics
> +@section Root Identifcation Heuristics
> +If the target operating system uses the Linux kernel, @command{grub-mkconfig}
> +attempts to identify the root file system via a heuristic algoirthm. This
> +algorithm selects the identification method of the root file system by
> +considering three factors. The first is if an initrd for the target
> operating
> +system is also present. The second is @samp{GRUB_DISABLE_LINUX_UUID} and if
> set
> +to @samp{true}, prevents @command{grub-mkconfig} from identifying the root
> file
> +system by its UUID. The third is @samp{GRUB_DISABLE_LINUX_PARTUUID} and if
> set
> +to @samp{true}, prevents @command{grub-mkconfig} from identifying the root
> file
> +system via the UUID of its enclosing partition. If the variables are
> assigned
> +any other value, that value is considered equivalent to @samp{false}. The
> +variables are also considered to be set to @samp{false} if they are not set.
> +
> +When booting, the Linux kernel will delegate the task of mounting the root
> +filesystem to the initrd. Most initrd i
Re: [GRUB PARTUUID PATCH V10 4/4] Update grub script template files
On 04/17/2018 06:36 AM, Daniel Kiper wrote:
> On Mon, Apr 16, 2018 at 10:36:26PM -0700, Nicholas Vinson wrote:
>> Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
>> partuuid target. Update grub.texi documentation. The following table
>> shows how GRUB_DISABLE_LINUX_UUID, GRUB_DISABLE_LINUX_PARTUUID, and
>> initramfs detection interact:
>>
>> Initramfs GRUB_DISABLE_LINUX_PARTUUID GRUB_DISABLE_LINUX_UUID Linux Root
>> detected Set Set ID Method
>>
>> false falsefalsepart UUID
>> false falsetrue part UUID
>> false true falsedev name
>> false true true dev name
>> true falsefalsefs UUID
>> true falsetrue part UUID
>> true true falsefs UUID
>> true true true dev name
>>
>> Note: GRUB_DISABLE_LINUX_PARTUUID and GRUB_DISABLE_LINUX_UUID equate to
>> 'false' when unset or set to any value other than 'true'.
>> GRUB_DISABLE_LINUX_PARTUUID defaults to 'true'.
>> Signed-off-by: Nicholas Vinson
>> ---
>> docs/grub.texi | 67 ++---
>> util/grub-mkconfig.in | 3 ++
>> util/grub.d/10_linux.in | 22 ++--
>> util/grub.d/20_linux_xen.in | 22 ++--
>> 4 files changed, 104 insertions(+), 10 deletions(-)
>>
>> diff --git a/docs/grub.texi b/docs/grub.texi
>> index 0f2ab91fc..6aa65552f 100644
>> --- a/docs/grub.texi
>> +++ b/docs/grub.texi
>> @@ -1214,10 +1214,11 @@ GRUB is configured using @file{grub.cfg}, usually
>> located under
>> need to write the whole thing by hand.
>>
>> @menu
>> -* Simple configuration::Recommended for most users
>> -* Shell-like scripting::For power users and developers
>> -* Multi-boot manual config::For non-standard multi-OS scenarios
>> -* Embedded configuration:: Embedding a configuration file into GRUB
>> +* Simple configuration::Recommended for most users
>> +* Root Identifcation Heuristics:: Summary on how the root file system is
>> identified.
>> +* Shell-like scripting::For power users and developers
>> +* Multi-boot manual config::For non-standard multi-OS scenarios
>> +* Embedded configuration:: Embedding a configuration file into GRUB
>> @end menu
>>
>>
>> @@ -1425,6 +1426,17 @@ the Linux kernel, using a @samp{root=UUID=...} kernel
>> parameter. This is
>> usually more reliable, but in some cases it may not be appropriate. To
>> disable the use of UUIDs, set this option to @samp{true}.
>>
>> +@item GRUB_DISABLE_LINUX_PARTUUID
>> +If @command{grub-mkconfig} cannot identify the root filesystem via its
>> +universally-unique indentifier (UUID), @command{grub-mkconfig} can use the
>> UUID
>> +of the partition containing the filesystem to identify the root filesystem
>> to
>> +the Linux kernel via a @samp{root=PARTUUID=...} kernel parameter. This is
>> not
>> +as reliable as using the filesystem UUID, but is more reliable than using
>> the
>> +Linux device names. When @samp{GRUB_DISABLE_LINUX_PARTUUID} is set to
>> +@samp{false}, the Linux kernel version must be 2.6.37 (3.10 for systems
>> using
>> +the MSDOS partition scheme) or newer. This option defaults to @samp{true}.
>> To
>> +enable the use of partition UUIDs, set this option to @samp{false}.
>> +
>> @item GRUB_DISABLE_RECOVERY
>> If this option is set to @samp{true}, disable the generation of recovery
>> mode menu entries.
>> @@ -1556,6 +1568,53 @@ edit the scripts in @file{/etc/grub.d} directly.
>> menu entries; simply type the menu entries you want to add at the end of
>> that file, making sure to leave at least the first two lines intact.
>>
>> +@node Root Identifcation Heuristics
>> +@section Root Identifcation Heuristics
>> +If the target operating system uses the Linux kernel,
>> @command{grub-mkconfig}
>> +attempts to identify the root file system via a heuristic algoirthm. This
>> +algorithm selects the identification method of the root file system by
>> +considering three factors. The first is if an initrd for the target
>> operating
>> +system is also present. The second is @samp{GRUB_DISABLE_LINUX_UUID} and
>> if set
>> +to @samp{true}, prevents @command{grub-mkconfig} from identifying the root
>> file
>> +system by its UUID. The third is @samp{GRUB_DISABLE_LINUX_PARTUUID} and if
>> set
>> +to @samp{true}, prevents @command{grub-mkconfig} from identifying the root
>> file
>> +system via the UUID of its enclosing partition. If the variables are
>> assigned
>> +any other value, that value is considered equivalent to @samp{false}. The
>> +variables are also considered to be set to @s
Re: [PATCH] pass kernel command line as verbatim
On Wed, Apr 11, 2018 at 05:17:03PM +0800, Michael Chang wrote: > And this bug report seems relevant .. > > https://savannah.gnu.org/bugs/?49937 > > On Wed, Apr 11, 2018 at 04:58:54PM +0800, Michael Chang wrote: > > The command line has been processed by grub shell, then the result is > > expected > > to be passed to kernel command line as verbatim according to the grub manual > > [1][2]. > > > > This patch removes extra escape character added as it helps nothing but only > > creates trouble as you want them to be literal. Besides the surrounding > > double-quotes added is kept as it used to protect space. CC-ing Vladmir. Hmmm... Have you tested this patch on all platforms supported by GRUB2? I understand that current behavior is not accepted on some but I have a feeling that somebody make it work in that way due to some reason. Sadly I cannot find anything about that in git log. So, I have to think how to cope with that. Or... Vladmir, do you know why command line is processed in that way? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bufio: fix the next_buf calculation
CC-ing Vladimir. On Mon, Apr 16, 2018 at 06:05:04PM +0800, Michael Chang wrote: > The next_buf is the offset to the next cached block rounded to the size of > bufio->block_size. However the calculation needs the block_size to be in power > of 2 is not always valid. As an example, files with smaller size than > block_size will have the block_size leveled to the size of file which can be > set arbitrary value. > > This patch fixes the next_buf calculation to accept any integers. > > Signed-off-by: Michael Chang > --- > grub-core/io/bufio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/grub-core/io/bufio.c b/grub-core/io/bufio.c > index 22438277d..d0b0f71b6 100644 > --- a/grub-core/io/bufio.c > +++ b/grub-core/io/bufio.c > @@ -132,7 +132,7 @@ grub_bufio_read (grub_file_t file, char *buf, grub_size_t > len) > return res; > >/* Need to read some more. */ > - next_buf = (file->offset + res + len - 1) & ~((grub_off_t) > bufio->block_size - 1); > + next_buf = (grub_divmod64 (file->offset + res + len - 1, > bufio->block_size, NULL)) * bufio->block_size; Should not you fix this in grub_bufio_open()? I think that you should look for closest power of 2 in it. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GRUB PARTUUID PATCH V10 4/4] Update grub script template files
On Tue, Apr 17, 2018 at 08:20:45AM -0700, Nick Vinson wrote:
> On 04/17/2018 06:36 AM, Daniel Kiper wrote:
> > On Mon, Apr 16, 2018 at 10:36:26PM -0700, Nicholas Vinson wrote:
> >> Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
> >> partuuid target. Update grub.texi documentation. The following table
> >> shows how GRUB_DISABLE_LINUX_UUID, GRUB_DISABLE_LINUX_PARTUUID, and
> >> initramfs detection interact:
> >>
> >> Initramfs GRUB_DISABLE_LINUX_PARTUUID GRUB_DISABLE_LINUX_UUID Linux Root
> >> detected Set Set ID Method
> >>
> >> false falsefalsepart UUID
> >> false falsetrue part UUID
> >> false true falsedev name
> >> false true true dev name
> >> true falsefalsefs UUID
> >> true falsetrue part UUID
> >> true true falsefs UUID
> >> true true true dev name
> >>
> >> Note: GRUB_DISABLE_LINUX_PARTUUID and GRUB_DISABLE_LINUX_UUID equate to
> >> 'false' when unset or set to any value other than 'true'.
> >> GRUB_DISABLE_LINUX_PARTUUID defaults to 'true'.
> >> Signed-off-by: Nicholas Vinson
> >> ---
> >> docs/grub.texi | 67 ++---
> >> util/grub-mkconfig.in | 3 ++
> >> util/grub.d/10_linux.in | 22 ++--
> >> util/grub.d/20_linux_xen.in | 22 ++--
> >> 4 files changed, 104 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/docs/grub.texi b/docs/grub.texi
> >> index 0f2ab91fc..6aa65552f 100644
> >> --- a/docs/grub.texi
> >> +++ b/docs/grub.texi
> >> @@ -1214,10 +1214,11 @@ GRUB is configured using @file{grub.cfg}, usually
> >> located under
> >> need to write the whole thing by hand.
> >>
> >> @menu
> >> -* Simple configuration::Recommended for most users
> >> -* Shell-like scripting::For power users and developers
> >> -* Multi-boot manual config::For non-standard multi-OS scenarios
> >> -* Embedded configuration:: Embedding a configuration file into GRUB
> >> +* Simple configuration::Recommended for most users
> >> +* Root Identifcation Heuristics:: Summary on how the root file system
> >> is identified.
> >> +* Shell-like scripting::For power users and developers
> >> +* Multi-boot manual config::For non-standard multi-OS scenarios
> >> +* Embedded configuration:: Embedding a configuration file into
> >> GRUB
> >> @end menu
> >>
> >>
> >> @@ -1425,6 +1426,17 @@ the Linux kernel, using a @samp{root=UUID=...}
> >> kernel parameter. This is
> >> usually more reliable, but in some cases it may not be appropriate. To
> >> disable the use of UUIDs, set this option to @samp{true}.
> >>
> >> +@item GRUB_DISABLE_LINUX_PARTUUID
> >> +If @command{grub-mkconfig} cannot identify the root filesystem via its
> >> +universally-unique indentifier (UUID), @command{grub-mkconfig} can use
> >> the UUID
> >> +of the partition containing the filesystem to identify the root
> >> filesystem to
> >> +the Linux kernel via a @samp{root=PARTUUID=...} kernel parameter. This
> >> is not
> >> +as reliable as using the filesystem UUID, but is more reliable than using
> >> the
> >> +Linux device names. When @samp{GRUB_DISABLE_LINUX_PARTUUID} is set to
> >> +@samp{false}, the Linux kernel version must be 2.6.37 (3.10 for systems
> >> using
> >> +the MSDOS partition scheme) or newer. This option defaults to
> >> @samp{true}. To
> >> +enable the use of partition UUIDs, set this option to @samp{false}.
> >> +
> >> @item GRUB_DISABLE_RECOVERY
> >> If this option is set to @samp{true}, disable the generation of recovery
> >> mode menu entries.
> >> @@ -1556,6 +1568,53 @@ edit the scripts in @file{/etc/grub.d} directly.
> >> menu entries; simply type the menu entries you want to add at the end of
> >> that file, making sure to leave at least the first two lines intact.
> >>
> >> +@node Root Identifcation Heuristics
> >> +@section Root Identifcation Heuristics
> >> +If the target operating system uses the Linux kernel,
> >> @command{grub-mkconfig}
> >> +attempts to identify the root file system via a heuristic algoirthm. This
> >> +algorithm selects the identification method of the root file system by
> >> +considering three factors. The first is if an initrd for the target
> >> operating
> >> +system is also present. The second is @samp{GRUB_DISABLE_LINUX_UUID} and
> >> if set
> >> +to @samp{true}, prevents @command{grub-mkconfig} from identifying the
> >> root file
> >> +system by its UUID. The third is @samp{GRUB_DISABLE_LINUX_PARTUUID} and
> >> if set
> >> +to @samp{true}, prevents @command{grub-m
Re: [PATCH v3] grub-install: locale depends on nls
On Fri, Apr 13, 2018 at 11:36:49PM +0200, Olaf Hering wrote: > With --disable-nls no locales exist. > > Avoid runtime error by moving code that copies locales into its own > function. Return early in case nls was disabled. That way the compiler > will throw away unreachable code, no need to put preprocessor > conditionals everywhere to avoid warnings about unused code. > > Fix memleak by freeing dstf. s/dstf/srcf and dstf/? > Convert tabs to spaces in moved code. > > Signed-off-by: Olaf Hering Otherwise LGTM. If there are no objections I will commit this patch in a week or so. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH RFC] Proposition of a --auto-nvram option for grub-install
On Thu, Apr 12, 2018 at 07:09:58PM +0200, Lukasz Zemczak wrote:
> Hello everyone,
>
> I'm writing to this list since I would like to get some feedback on an
> additional option to the grub-install tool we would find very
> convenient to have. The diff is attached to the e-mail (also available
> as a pastebin [1]).
>
> The idea of the --auto-nvram (the name is just a proposition) flag is
> a bit similar to what --no-nvram does. After providing the option
> during grub-install, the tool will attempt to guess if there is access
> to NVRAM variables for EFI and/or IEEE1275 and, if yes, perform the
> usual variable updates. If no access to the NVRAM is available the
> whole thing is handled somewhat similar to --no-nvram + a warning
Make sense for me but I am not sure about "a warning". Hmmm...
Is it really needed?
> message displayed. Rationale:
>
> We would like to use this in Ubuntu for cases of dual BIOS/EFI
> bootloaders installed (at the same time), helpful for the situation of
> calling grub-install --target=x86_64-efi from the shim-efi package on
> a BIOS legacy-mode booted machine. For this legacy-mode case when
> running on a EFI-enabled device, currently this causes grub-install to
> fail as obviously there is no access to the NVRAM and no --no-nvram is
> given. We don't want to unconditionally append --no-nvram as this is
> not what we want to happen for the case of a system that is actually
> booted in EFI-mode. With this flag, we would be simply performing a
> grub-install --target=x86_64-efi --auto-nvram unconditionally which
> would do the right thing in both cases, allowing for a much simpler
> handling of this dual-bootloader case in Ubuntu. Having it being done
> inside grub-installer makes everything much cleaner.
>
> This is of course just a proposition about which I wanted to get some
> feedback from people that know the codebase the most. It's my first
> time working on the grub project so apologies for any flukes or
> silliness in the code or the idea itself.
>
> Thank you!
>
> Best regards,
>
> [1] http://paste.ubuntu.com/p/cWR3k3NZgF/
Next time please use git format-patch/send-email to send the patches.
> diff --git a/grub-core/osdep/basic/no_platform.c
> b/grub-core/osdep/basic/no_platform.c
> index d76c34c14..b39e97f48 100644
> --- a/grub-core/osdep/basic/no_platform.c
> +++ b/grub-core/osdep/basic/no_platform.c
> @@ -25,7 +25,7 @@
>
> void
> grub_install_register_ieee1275 (int is_prep, const char *install_device,
> - int partno, const char *relpath)
> + int partno, const char *relpath, int
> detect_nvram)
> {
>grub_util_error ("%s", _("no IEEE1275 routines are available for your
> platform"));
> }
> @@ -33,7 +33,8 @@ grub_install_register_ieee1275 (int is_prep, const char
> *install_device,
> void
> grub_install_register_efi (grub_device_t efidir_grub_dev,
> const char *efifile_path,
> -const char *efi_distributor)
> +const char *efi_distributor,
> +int detect_nvram)
> {
>grub_util_error ("%s", _("no EFI routines are available for your
> platform"));
> }
> diff --git a/grub-core/osdep/unix/platform.c b/grub-core/osdep/unix/platform.c
> index ca448bc11..4eb2c11c9 100644
> --- a/grub-core/osdep/unix/platform.c
> +++ b/grub-core/osdep/unix/platform.c
> @@ -134,7 +134,8 @@ grub_install_remove_efi_entries_by_distributor (const
> char *efi_distributor)
> int
> grub_install_register_efi (grub_device_t efidir_grub_dev,
> const char *efifile_path,
> -const char *efi_distributor)
> +const char *efi_distributor,
> +int detect_nvram)
> {
>const char * efidir_disk;
>int efidir_part;
> @@ -153,6 +154,21 @@ grub_install_register_efi (grub_device_t efidir_grub_dev,
> #ifdef __linux__
>grub_util_exec ((const char * []){ "modprobe", "-q", "efivars", NULL });
> #endif
> +
> + /* If requested, we try to detect if NVRAM access is available and if not,
> + warn the user and resume normal operation. */
> + if (detect_nvram)
> +{
> + error = grub_util_exec_redirect_null ((const char * []){ "efibootmgr",
> NULL });
> + if (error == 2)
> + {
> + grub_util_warn ("%s", _("Auto-NVRAM selected and no EFI variable
> support detected on the system."));
Wait, I have a feeling that you should fail hard here. In general
I think that if somebody passed --auto-nvram on platforms with NVRAM
and something fails then everything should fail. If somebody passed
--auto-nvram on platforms without NVRAM then any attempt to access
NVRAM should be skipped (silently?). Does it make sense?
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot ELF segment handling patch
Hi Alexander,
On Sat, Apr 14, 2018 at 12:07:29AM +0200, Alexander Boettcher wrote:
> Hello,
>
> On 06.04.2018 14:28, Daniel Kiper wrote:
> > On Thu, Mar 29, 2018 at 11:20:37AM +0200, Alexander Boettcher wrote:
> >
> >> Can you please have a look and check regarding what should/could be
> >> changed to get it upstream? We did not test the dynamic relocation part,
> >
> > Sure thing, please take a look below...
> >
> >> since we have no such (kernel) setup. Thanks in advance.
> >
> > You can use Xen (git://xenbits.xen.org/xen.git) for tests.
> > Just compile hypervisor without any tools and use xen.gz.
> > It produces nice output and you can see it is relocated or not.
> > Of course you have to use Multiboot2 protocol.
>
> Thanks, I managed to setup it. Based on your comments and on the Xen
> test case I had to re-work the patch, so that it now works for
> relocation and non-relocation kernels.
>
> Please review again.
> > However, this does not mean that I will not take this patch. Though
> > it requires some tweaking.
> >
> > First of all, lack of SOB.
>
> What is a SOB ?
Signed-off-by: Alexander Boettcher
Next time please use git format-patch/send-email to send the patches.
> From c37727840be8aeb81ea4bbc95ac09a1b1e3d3658 Mon Sep 17 00:00:00 2001
> From: Alexander Boettcher
> Date: Fri, 13 Apr 2018 23:37:01 +0200
> Subject: [PATCH] mbi: use per segment a separate relocator chunk
>
> if elf is non relocatable.
>
> If the segments are not dense packed, the original code set up a huge
> relocator chunk comprising all segments.
>
> During the final relocation in grub_relocator_prepare_relocs, the chunk
> is moved to its desired place and overrides memory which are actually not
> covered/touched by the specified segments.
>
> The overriden memory may contain device memory (vga text mode e.g.), which
> leads to strange boot behaviour.
Have you been able to take a look at memory allocator/relocator code why
this happened?
> ---
> grub-core/loader/multiboot_elfxx.c | 56
> --
> 1 file changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/grub-core/loader/multiboot_elfxx.c
> b/grub-core/loader/multiboot_elfxx.c
> index 67daf59..d936223 100644
> --- a/grub-core/loader/multiboot_elfxx.c
> +++ b/grub-core/loader/multiboot_elfxx.c
> @@ -57,9 +57,9 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
>char *phdr_base;
>grub_err_t err;
>grub_relocator_chunk_t ch;
> - grub_uint32_t load_offset, load_size;
> + grub_uint32_t load_offset = 0, load_size;
>int i;
> - void *source;
> + void *source = NULL;
>
>if (ehdr->e_ident[EI_MAG0] != ELFMAG0
>|| ehdr->e_ident[EI_MAG1] != ELFMAG1
> @@ -83,6 +83,7 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
> #define phdr(i) ((Elf_Phdr *) (phdr_base + (i) *
> ehdr->e_phentsize))
>
>mld->link_base_addr = ~0;
> + mld->load_base_addr = ~0;
>
>/* Calculate lowest and highest load address. */
>for (i = 0; i < ehdr->e_phnum; i++)
> @@ -108,27 +109,19 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t
> *mld)
> mld->min_addr, mld->max_addr -
> load_size,
> load_size, mld->align ?
> mld->align : 1,
> mld->preference,
> mld->avoid_efi_boot_services);
> -}
> - else
> -err = grub_relocator_alloc_chunk_addr (GRUB_MULTIBOOT (relocator), &ch,
> -mld->link_base_addr, load_size);
>
> - if (err)
> -{
> - grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS
> image\n");
> - return err;
> -}
> + if (err)
> +{
> + grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS
> image\n");
> + return err;
> +}
>
> - mld->load_base_addr = get_physical_target_address (ch);
> - source = get_virtual_current_address (ch);
> + mld->load_base_addr = get_physical_target_address (ch);
> + source = get_virtual_current_address (ch);
>
> - grub_dprintf ("multiboot_loader", "link_base_addr=0x%x,
> load_base_addr=0x%x, "
> - "load_size=0x%x, relocatable=%d\n", mld->link_base_addr,
> - mld->load_base_addr, load_size, mld->relocatable);
I would not drop it completely from ~here. I think that you can display
link_base_addr and relocatable just before current line 102. And you can
put "load_size = highest_load - mld->link_base_addr;" just before current
line 104. Additionally, load_size does not have a real meaning for non
relocatable images right now. Hence, I think that it should not be displayed
for them. Especially if there are more than one PT_LOAD segment.
> - if (mld->relocatable)
> -grub_dprintf ("multiboot_loader", "align=0x%lx, preference=0x%x,
> avoid_efi_boot_services=%d\n",
> - (long) mld->align, mld->preference,
> mld->avoid_efi_boot_services);
> +
Re: Multiboot ELF segment handling patch
On April 17, 2018 3:40:11 PM EDT, Daniel Kiper wrote:
>Hi Alexander,
>
>On Sat, Apr 14, 2018 at 12:07:29AM +0200, Alexander Boettcher wrote:
>> Hello,
>>
>> On 06.04.2018 14:28, Daniel Kiper wrote:
>> > On Thu, Mar 29, 2018 at 11:20:37AM +0200, Alexander Boettcher
>wrote:
>> >
>> >> Can you please have a look and check regarding what should/could
>be
>> >> changed to get it upstream? We did not test the dynamic relocation
>part,
>> >
>> > Sure thing, please take a look below...
>> >
>> >> since we have no such (kernel) setup. Thanks in advance.
>> >
>> > You can use Xen (git://xenbits.xen.org/xen.git) for tests.
>> > Just compile hypervisor without any tools and use xen.gz.
>> > It produces nice output and you can see it is relocated or not.
>> > Of course you have to use Multiboot2 protocol.
>>
>> Thanks, I managed to setup it. Based on your comments and on the Xen
>> test case I had to re-work the patch, so that it now works for
>> relocation and non-relocation kernels.
>>
>> Please review again.
>> > However, this does not mean that I will not take this patch. Though
>> > it requires some tweaking.
>> >
>> > First of all, lack of SOB.
>>
>> What is a SOB ?
>
>Signed-off-by: Alexander Boettcher
>
There is more to it then that. Doing an SoB means you abide by the developer
certificate.
See https://developercertificate.org/
>
>Next time please use git format-patch/send-email to send the patches.
>
>> From c37727840be8aeb81ea4bbc95ac09a1b1e3d3658 Mon Sep 17 00:00:00
>2001
>> From: Alexander Boettcher
>> Date: Fri, 13 Apr 2018 23:37:01 +0200
>> Subject: [PATCH] mbi: use per segment a separate relocator chunk
>>
>> if elf is non relocatable.
>>
>> If the segments are not dense packed, the original code set up a huge
>> relocator chunk comprising all segments.
>>
>> During the final relocation in grub_relocator_prepare_relocs, the
>chunk
>> is moved to its desired place and overrides memory which are actually
>not
>> covered/touched by the specified segments.
>>
>> The overriden memory may contain device memory (vga text mode e.g.),
>which
>> leads to strange boot behaviour.
>
>Have you been able to take a look at memory allocator/relocator code
>why
>this happened?
>
>> ---
>> grub-core/loader/multiboot_elfxx.c | 56
>--
>> 1 file changed, 35 insertions(+), 21 deletions(-)
>>
>> diff --git a/grub-core/loader/multiboot_elfxx.c
>b/grub-core/loader/multiboot_elfxx.c
>> index 67daf59..d936223 100644
>> --- a/grub-core/loader/multiboot_elfxx.c
>> +++ b/grub-core/loader/multiboot_elfxx.c
>> @@ -57,9 +57,9 @@ CONCAT(grub_multiboot_load_elf, XX)
>(mbi_load_data_t *mld)
>>char *phdr_base;
>>grub_err_t err;
>>grub_relocator_chunk_t ch;
>> - grub_uint32_t load_offset, load_size;
>> + grub_uint32_t load_offset = 0, load_size;
>>int i;
>> - void *source;
>> + void *source = NULL;
>>
>>if (ehdr->e_ident[EI_MAG0] != ELFMAG0
>>|| ehdr->e_ident[EI_MAG1] != ELFMAG1
>> @@ -83,6 +83,7 @@ CONCAT(grub_multiboot_load_elf, XX)
>(mbi_load_data_t *mld)
>> #define phdr(i) ((Elf_Phdr *) (phdr_base + (i) *
>ehdr->e_phentsize))
>>
>>mld->link_base_addr = ~0;
>> + mld->load_base_addr = ~0;
>>
>>/* Calculate lowest and highest load address. */
>>for (i = 0; i < ehdr->e_phnum; i++)
>> @@ -108,27 +109,19 @@ CONCAT(grub_multiboot_load_elf, XX)
>(mbi_load_data_t *mld)
>>mld->min_addr, mld->max_addr -
>> load_size,
>>load_size, mld->align ?
>> mld->align : 1,
>>mld->preference,
>> mld->avoid_efi_boot_services);
>> -}
>> - else
>> -err = grub_relocator_alloc_chunk_addr (GRUB_MULTIBOOT
>(relocator), &ch,
>> - mld->link_base_addr, load_size);
>>
>> - if (err)
>> -{
>> - grub_dprintf ("multiboot_loader", "Cannot allocate memory for
>OS image\n");
>> - return err;
>> -}
>> + if (err)
>> +{
>> + grub_dprintf ("multiboot_loader", "Cannot allocate memory
>for OS image\n");
>> + return err;
>> +}
>>
>> - mld->load_base_addr = get_physical_target_address (ch);
>> - source = get_virtual_current_address (ch);
>> + mld->load_base_addr = get_physical_target_address (ch);
>> + source = get_virtual_current_address (ch);
>>
>> - grub_dprintf ("multiboot_loader", "link_base_addr=0x%x,
>load_base_addr=0x%x, "
>> -"load_size=0x%x, relocatable=%d\n", mld->link_base_addr,
>> -mld->load_base_addr, load_size, mld->relocatable);
>
>I would not drop it completely from ~here. I think that you can display
>link_base_addr and relocatable just before current line 102. And you
>can
>put "load_size = highest_load - mld->link_base_addr;" just before
>current
>line 104. Additionally, load_size does not have a real meaning for non
>relocatable images right now. Hence, I think that it should not be
>di
[RFC] Add support for BTRFS raid5/6 to GRUB
Hi All,
Below you can find a patch to add support for accessing files from grub in a
RAID5/6 btrfs filesystem. This is a RFC because it is missing the support for
recovery (i.e. if some devices are missed). In the next days (weeks ?) I will
extend this patch to support also this case.
Comments are welcome.
BR
G.Baroncelli
---
commit 8c80a1b7c913faf50f95c5c76b4666ed17685666
Author: Goffredo Baroncelli
Date: Tue Apr 17 21:40:31 2018 +0200
Add initial support for btrfs raid5/6 chunk
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index be195448d..4c5632acb 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -119,6 +119,8 @@ struct grub_btrfs_chunk_item
#define GRUB_BTRFS_CHUNK_TYPE_RAID1 0x10
#define GRUB_BTRFS_CHUNK_TYPE_DUPLICATED0x20
#define GRUB_BTRFS_CHUNK_TYPE_RAID100x40
+#define GRUB_BTRFS_CHUNK_TYPE_RAID5 0x80
+#define GRUB_BTRFS_CHUNK_TYPE_RAID60x100
grub_uint8_t dummy2[0xc];
grub_uint16_t nstripes;
grub_uint16_t nsubstripes;
@@ -764,6 +766,39 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data,
grub_disk_addr_t addr,
stripe_offset = low + chunk_stripe_length
* high;
csize = chunk_stripe_length - low;
+ break;
+ }
+ case GRUB_BTRFS_CHUNK_TYPE_RAID5:
+ case GRUB_BTRFS_CHUNK_TYPE_RAID6:
+ {
+ grub_uint64_t nparities;
+ grub_uint64_t parity_pos;
+ grub_uint64_t stripe_nr, high;
+ grub_uint64_t low;
+
+ redundancy = 1; /* no redundancy for now */
+
+ if (grub_le_to_cpu64 (chunk->type) & GRUB_BTRFS_CHUNK_TYPE_RAID5)
+ {
+ grub_dprintf ("btrfs", "RAID5\n");
+ nparities = 1;
+ }
+ else
+ {
+ grub_dprintf ("btrfs", "RAID6\n");
+ nparities = 2;
+ }
+
+ stripe_nr = grub_divmod64 (off, chunk_stripe_length, &low);
+
+ high = grub_divmod64 (stripe_nr, nstripes - nparities, &stripen);
+ grub_divmod64 (high+nstripes-nparities, nstripes, &parity_pos);
+ grub_divmod64 (parity_pos+nparities+stripen, nstripes, &stripen);
+
+ stripe_offset = low + chunk_stripe_length * high;
+ csize = chunk_stripe_length - low;
+
break;
}
default:
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
