[bug #51188] FPE (division by zero) in grub_ext2_read_inode()

[Andrei Borzenkov]

Update of bug #51188 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for report. Unfortunately, your project is using very old grub
sources; the code in question does not exist in current git.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #51189] Stack buffer underflow in grub_memmove()

[Andrei Borzenkov]

Update of bug #51189 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Your project is using extremely old grub sources, looks like 1.98 or even
earlier. Code has changed significantly since then. If you can reproduce it
with current git master, feel free to reopen. But otherwise we are not able
either to trace it or verify that it is actually fixed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Build fails with flex 2.6.4 and -Werror

[Andrei Borzenkov]

04.06.2017 20:05, Timotej Lazar пишет:
> Hi,
> 
> Building GRUB using the default configuration (-Werror -Wunused-value)
> fails with flex >2.6.3.
> 

flex bug fixed in flex git.

https://github.com/westes/flex/issues/162

> The problem is with the script lexer, which defines fprintf to 0. The
> replacement triggers -Wunused-value in the default flex template for
> yy_fatal_error. In previous versions of the template the fprintf call
> was cast to void, which silenced the warning. However, the cast was
> removed in the latest version of flex.
> 
> I’m attaching a patch to fix this by replacing fprintf with grub_printf
> instead. Alternatively, fprintf could be #defined to ((void)0), but that
> might break if the flex template changes to not ignore the return value.
> Another option would be to add a #pragma in yylex.l to ignore unused
> values. In any case, the lexer overrides yy_fatal_error, so this code is
> never actually executed, only compiled.
> 
> Thanks,
> Timotej Lazar
> 
> 
> 
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50963] "normal" module interprets comments if using grub-mkimage

[Andrei Borzenkov]

Update of bug #50963 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Embedded config is interpreted by rescue parser, not by normal.mod. It is
intended for limited use cases and not for general purpose scripting.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50931] Page Fault Exception when grub loads with an Nvidia cards

[Andrei Borzenkov]

Follow-up Comment #1, bug #50931 (project grub):

Does attached patch help?

(file #40605)
___

Additional Item Attachment:

File name: uga-64bit-fb.patch Size:3 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50954] unaligned pointer 0x8 if initrd before linux is not clear enough message

[Andrei Borzenkov]

Follow-up Comment #2, bug #50954 (project grub):

Are you using Ubuntu grub? Can you reproduce the problem using upstream?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50954] unaligned pointer 0x8 if initrd before linux is not clear enough message

[Andrei Borzenkov]

Follow-up Comment #1, bug #50954 (project grub):

Where have you get this message? GRUB does complain when initrd was used
without corresponding linux command. Please attach your grub.cfg and photo of
error message.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: no keyboard input

[Andrei Borzenkov]

30.04.2017 06:10, Jefferson Carpenter пишет:
> When I have "too many" input devices plugged in, I cannot switch between
> operating systems in the GRUB menu.  By unplugging devices and rebooting
> the computer, I can usually cause my keyboard to be recognized by GRUB so
> that I can switch options in the menu.  However, which devices need to be
> unplugged, if any, is not deterministic.
> 
> Are there any diagnostics I can enable to see what keyboards GRUB detects?
> 

GRUB is using platform firmware to access input, so it sounds more like
a problem of your firmware (BIOS?).

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: co-maintainer for GRUB legacy for GNU GRUB

[Andrei Borzenkov]

28.04.2017 21:23, armando barra пишет:
> Hello, my name is Armando Barra, i'am from Chile, and i'am a computer
> scitist from University of Tarapa, i interesitng in give support to a GNU.
> 
> 

GRUB legacy is not really updated since long time. Do you have any
specific needs to revive it?

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50896] grub-probe zfs bug: failed to get canonical path

[Andrei Borzenkov]

Update of bug #50896 (project grub):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 
 Planned Release:None => 2.03+  

___

Follow-up Comment #1:

Duplicate of https://savannah.gnu.org/bugs/?43653

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50861] saved_entry is read from environment block without GRUB_DEFAULT=saved

[Andrei Borzenkov]

Follow-up Comment #8, bug #50861 (project grub):

grub cannot write to btrfs, so the only solution for now is to reset next_boot
when OS is booted or place /boot/grub on different FS type.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50861] saved_entry is read from environment block without GRUB_DEFAULT=saved

[Andrei Borzenkov]

Follow-up Comment #6, bug #50861 (project grub):

What "grub-probe -t fs /boot/grub/grubenv" says?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50861] saved_entry is read from environment block without GRUB_DEFAULT=saved

[Andrei Borzenkov]

Follow-up Comment #4, bug #50861 (project grub):

Show output of "grub-editenv - list" before grub-reboot, immediately after
grub-reboot before reboot and after reboot.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50861] saved_entry is read from environment block without GRUB_DEFAULT=saved

[Andrei Borzenkov]

Follow-up Comment #2, bug #50861 (project grub):

grub-reboot does not touch saved_entry since quite some time. It is unclear
what your problem actually is. Please explain your problem instead of your
conclusions about what may cause it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50834] GRUB 2/x86_64-efi: no drives visible/accessible

[Andrei Borzenkov]

Update of bug #50834 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Image should contain only modules needed to access $prefix; everything else is
loaded from $prefix. For all supported platforms grub-install figures out
needed modules automatically.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50834] GRUB 2/x86_64-efi: no drives visible/accessible

[Andrei Borzenkov]

Follow-up Comment #1, bug #50834 (project grub):

You should never include modules directly in image except for very special use
cases. Here adding ehci to image disables platform disk driver. Please retest
using 

grub-install --efi-directory=/boot/efi --no-nvram --target=x86_64-efi
--boot-directory=/boot/efi --compress=xz --themes="breeze"

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Kernel fail to find rootfs with 2.02-rc[12]

[Andrei Borzenkov]

13.04.2017 18:08, DUPONCHEEL Sébastien пишет:
> Hi,
> 
> It look like there is a grub regression when using grub2-2.02-rc[12] with a 
> bios in MBR mode and GPT partitioning:
> 
> Grub does not give the boot parameters to the kernel that did not find the 
> root partition although that the partition with the good PARTUUID is listed 
> before the panic
>  and that everything works when the bios is switched to the EFI mode (i 
> haven't this issue with the 2.02-beta2 version).
> 

There are simply too many changes between beta2 and rc2 and none strikes
as particular relevant. rc2 is used by at least openSUSE Tumbleweed and
so far I am not aware of problems on PC BIOS systems.

If you can reliably reproduce the problem I suggest you try to bisect it.

> You can get more details here: 
> https://github.com/lede-project/source/pull/1026
> 
> Tests where made using LEDE and Virtualbox.
> 
> Partitioning :
> 
> sda1: ext4 (4 MB)
> 
> - /boot/vmlinuz
> - /boot/grub/50092577.cfg
> - /boot/grub/grub.cfg
> 
> serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 --rtscts=off
> terminal_input console serial; terminal_output console serial
> 
> set default="0"
> set timeout="5"
> 
> search --file /boot/grub/50092577.cfg --set=root
> 
> menuentry "LEDE" {
> linux /boot/vmlinuz root=PARTUUID=09BBA8CF-313E-420B-B5A8-E6B13DE60002 
> rootfstype=squashfs rootwait console=tty0 console=ttyS0,115200n8 noinitrd
> }
> 
> menuentry "LEDE (failsafe)" {
> linux /boot/vmlinuz failsafe=true 
> root=PARTUUID=09BBA8CF-313E-420B-B5A8-E6B13DE60002 rootfstype=squashfs 
> rootwait console=tty0 console=ttyS0,115200n8 noinitrd
> }
> 
> sda2: EF00 vfat (1 MB)
> 
> - /efi/boot/bootx64.efi (grub)
> - /efi/boot/grub.cfg
> 
> search --file /boot/grub/50092577.cfg --set=root
> configfile /boot/grub/grub.cfg
> 
> sda3: EF02 raw (1MB)
> 
> - grub modules 
> 
> sda4: ext4/squashfs 
> 
> - the rootfs with the GPT PARTUUID : 09BBA8CF-313E-420B-B5A8-E6B13DE60002
> 
> Best regards,
> DUPONCHEEL Sebastien
> 
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Interested in the project - Would like to work

[Andrei Borzenkov]

11.04.2017 02:37, Ritesh Agarwal пишет:
> Hi,
> 
> I am interested in the project. I would like to contribute. Please advise.
> 

Go to https://savannah.gnu.org/projects/grub, checkout sources, find
bits that you are interested in, submit patches to grub-devel. It must
not be C sources, patches to documentation are welcome.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #47639] grub2-2.02: Some Chinese characters are displayed as '?' with a border

[Andrei Borzenkov]

Follow-up Comment #8, bug #47639 (project grub):

Using Leap grub (2.02~beta2) with font from Tumbleweed correctly displays all
symbols. As there are no changes in grub-mkfont this looks indeed like system
library issue. Do you happen to have reference to freetype bug?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #47639] grub2-2.02: Some Chinese characters are displayed as '?' with a border

[Andrei Borzenkov]

Update of bug #47639 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #7:

All characters from FF block I tried are correctly displayed under 2.02~rc2
(openSUSE Tumbleweed). So closing as fixed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #47639] grub2-2.02: Some Chinese characters are displayed as '?' with a border

[Andrei Borzenkov]

Follow-up Comment #3, bug #47639 (project grub):

> add "菜单"("menu") characters in any menu entry

Displayed correctly here on openSUSE Leap 42.2. Please attach full grub.cfg
that shows this problem.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #47639] grub2-2.02: Some Chinese characters are displayed as '?' with a border

[Andrei Borzenkov]

Follow-up Comment #1, bug #47639 (project grub):

What is Unicode code position for this character?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50749] Boot fails due to EFI grub.cfg missing braces around root partition e.g. hd0, gpt4

[Andrei Borzenkov]

Update of bug #50749 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Upstream does not create grub.cfg on ESP. Please open report in Ubuntu bug
tracker.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50715] GRUB stack overwriting PXE stack (or the other way around)

[Andrei Borzenkov]

Follow-up Comment #1, bug #50715 (project grub):

Well, this code is run as the very first thing, before any memory allocator is
active. I guess we could use different, more "safe" stack location until
memory size is detected. But that also means we must restrict max image size,
so we still need to have some safe limit statically. In which case we can
simply move stack lower.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49814] vbe does not reset display start

[Andrei Borzenkov]

Follow-up Comment #5, bug #49814 (project grub):

> The bug happens only if grub works in gfx 
> mode but the boot happens in text mode. 

Good catch. I won't claim to fully understand this code, but as far as I can
tell in grub_video_set_mode()

- if we have "keep" we simply return keeping current adapter
- if we have graphic mode, we reinitialize adapter

in both cases we later reset current page in
grub_video_fb_get_info_and_fini(). But if we have test mode then

- we shut down current video adapter *without* changing current page, and
probably reset it to NULL

it means we are left with whatever was set before.

May be we need wrapper around ->fini() method that resets current page (moving
code from grub_video_fb_get_info_and_fini()).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50598] GCC7: -Werror=implicit-fallthrough

[Andrei Borzenkov]

Update of bug #50598 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:   2.03+ => 2.02   

___

Follow-up Comment #2:

Believed to be fixed by 4bd4a88725604471fdbd86316c91967a7f4dba5a; reopen if
needed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50597] GCC7: may be used uninitialized in this function

[Andrei Borzenkov]

Update of bug #50597 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:   2.03+ => 2.02   

___

Follow-up Comment #2:

Fixed in 6cef7f6079550af3bf91dbff824398eaef08c3c5

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

23.03.2017 14:41, Rodrigo V. G. пишет:
> On 3/23/17, Andrei Borzenkov  wrote:
>> 22.03.2017 22:23, Daniel Kiper пишет:
>>> On Wed, Mar 22, 2017 at 04:43:35PM +0100, Rodrigo Vali??a Guti??rrez
>>> wrote:
>>>>>> They also may not match if virtual address != physical address, but as
>>>>>> we do not establish any address translation when launching image, this
>>>>>> probably is going to fail. Still would be good to have this assumption
>>>>>> explicitly listed in multiboot2 manual.
>>>>>
>>>>> I think that we should state in multiboot2 spec that physical address
>>>>> ==
>>>>> virtual address in ELF.
>>>>
>>>> That may be true (that is going to fail) for entry point address, but
>>>> please note that many kernels have the entry point and bootstrap code
>>>> in a section/segment with virtual == physical, but then setup address
>>>> translation and jump to another sections/segments with virtual !=
>>>> physical addresses.
>>>
>>
>> Do those kernels use actually use ELF envelope for bootstrap part? We do
>> not really care what happens after payload is launched.
>>
>> Can you give links to such kernels?
>>
> 
> Most kernels that I have seen (including hobby os) that use ELF, use
> it also for the bootstrap part, in a single binary. Even in x86_64
> they may use ELF64 with a bootstrap code in 32 bits included in a
> section that enables long mode and jumps to other sections with 64 bit
> code.
> And the multiboot (1 or 2 or both) header may be included in one of
> the first sections for easy detecting it, placed near the beginning of
> the binary file.
> The multiboot info tag structures about ELF may not be needed, though.
> 
> Some links:
> 
> Documentation that shows a linker script that loads at 0x0010
> physical and 0xC010 virtual:
> 
> http://wiki.osdev.org/Higher_Half_x86_Bare_Bones#linker.ld
> https://littleosbook.github.io/#higher-half-linker-script
> 
> Documentation for linker scripts for x86_64 ELF64, where KERNEL_LMA
> may be 0x0010 (1MB) and KERNEL_VMA may be
> 0x8000 (-2GB):
> 
> http://wiki.osdev.org/Creating_a_64-bit_kernel#link.ld_2
> 
> Also Minix3: Its linker script loads at 0x0040 physical and some
> parts with the same virtual and other parts with 0xF040 virtual:
> 
> http://git.minix3.org/index.cgi?p=minix.git;a=blob;f=minix/kernel/arch/i386/kernel.lds;h=24c0c1f90e8ca2c0e0abb89b1c1385522f26e115;hb=HEAD
> 

OK, thanks; all of this just reinforces original report showing that
even without relocatable image sections may have address which is not
equal to physical address:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg
Lk Inf Al
  [ 0]   NULL 00 00 00
0   0  0
  [ 1] .note.gnu.build-i NOTEc010 003000 24 00   A
0   0  4
  [ 2] .text PROGBITSc0100030 001030 000269 00  AX
0   0 16
...
Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x001030 0xc0100030 0x00100030 0x003c0 0x003c0 R E 0x1000
...
 Section to Segment mapping:
  Segment Sections...
   00 .text .eh_frame .eh_frame_hdr


And apart from this ...

1. Documentation says

u16 | num   |
u16 | entsize   |
u16 | shndx |
u16 | reserved  |

While the actual structure (both in multiboot1 and multiboot2) is

  multiboot_uint32_t size;
  multiboot_uint32_t num;
  multiboot_uint32_t entsize;
  multiboot_uint32_t shndx;

Which accommodates for both 32 and 64 but ELF.

2. Documentation says

"They correspond to the @samp{shdr_*} entries(@samp{shdr_num}, etc.) in
the Executable and Linkable Format (@sc{elf}) specification in the
program header".

Program Header has quite precise meaning in ELF, what is meant here is
obviously ELF Header.

3. I do not know what ELF specification was used as basis for this, but
I cannot find "shdr_num" anywhere. In ELF specifications I can reach
fields in ELF header are named

e_shnum;
e_shentsize;
e_shstrndx;

I do not think it is something that can be fixed in code. We only can
document current behavior with something like

"if section size is not 0 and section address in ELF file is 0, section
address will be set to physical address of section in memory. Note that
for loadable and allocatable sections (that are part of program
segments) address is set by linker to virtual address and may not
correspond to physical location in memory."

I still miss the actual use case for this tag which could help to
understand how it was supposed to be used.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

22.03.2017 17:33, Daniel Kiper пишет:

 Yes. @Daniel, note that tags 9, 10 are not even documented.
>>>
>>> Do you mean MULTIBOOT_TAG_TYPE_ELF_SECTIONS and MULTIBOOT_TAG_TYPE_APM?
>>
>> No, I mean
>>
>> #define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
>> #define MULTIBOOT_HEADER_TAG_RELOCATABLE  10
> 
> They are documented in line 563 and 686.
> 

Oops, sorry, I tend to forget that remote tracking branches need to be
checked out to apply updates ...

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

22.03.2017 22:23, Daniel Kiper пишет:
> On Wed, Mar 22, 2017 at 04:43:35PM +0100, Rodrigo Vali??a Guti??rrez wrote:
 They also may not match if virtual address != physical address, but as
 we do not establish any address translation when launching image, this
 probably is going to fail. Still would be good to have this assumption
 explicitly listed in multiboot2 manual.
>>>
>>> I think that we should state in multiboot2 spec that physical address ==
>>> virtual address in ELF.
>>
>> That may be true (that is going to fail) for entry point address, but
>> please note that many kernels have the entry point and bootstrap code
>> in a section/segment with virtual == physical, but then setup address
>> translation and jump to another sections/segments with virtual !=
>> physical addresses.
> 

Do those kernels use actually use ELF envelope for bootstrap part? We do
not really care what happens after payload is launched.

Can you give links to such kernels?

> OK, even if we assume that virtual and physical addresses can be different
> in the ELF header I think that the bootloader should always put into sh_addr
> (maybe others) physical addresses. 

Again - currently documentation says "All sections are loaded, and the
physical address fields of the @sc{elf} section header then refer to
where the sections are in memory".

First, there is no such thing as "physical address field" - there is
only sh_addr and it is virtual address in address space of executed process.

Second as we seem to all agree, for already loaded sections (which are
part of program segments) address can in general be anything.

So as written documentation is wrong. It happens to match reality only
if ELF executable was linked for virtual == physical mapping. Which was
the reason why I suggested to actually document it.

But it obviously breaks for relocatable images, and relocatable images
are new, so not providing this information for relocatable images will
not cause compatibility issues. And if you have use case for relocatable
image requiring access to section table, we need to add additional
information request tag for it and document that not all sections are
guaranteed to have physical address.

I do not think grub should start changing existing header addresses,
because we simply do not have enough information whether it safe to do
it. If it proves to be useful, executable needs to explicitly request it.

> Usually it (the bootloader) does not have
> sufficient knowledge to properly calculate correct kernel virtual addresses.
> However, kernel is sufficiently smart to translate physical addresses to
> virtual ones.
> 

But it needs to know which is which and kernel written according to
current documentation will misbehave.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

On Wed, Mar 22, 2017 at 3:07 PM, Daniel Kiper  wrote:
> Hi,
>
> Sorry for late reply but I am busy.
>
> On Sun, Mar 19, 2017 at 12:02:38PM +0300, Andrei Borzenkov wrote:
>> 17.03.2017 22:53, Ahmed, Safayet (GE Global Research, US) ??:
>> > Hello again,
>> >
>> > I had a question on the function, "grub_multiboot_load_elf(32/64)".
>> > (grub/grub_core/loader/multiboot_elfxx.c: line 54)
>> >
>> > As a part of parsing an ELF image, the above-named function copies
>> > the section header table into memory, and copies "unloaded" sections
>> > into memory (lines 199 - 269). The section table may be passed to an
>> > OS image as the "ELF-Symbols" tag of the multiboot2 information
>> > structure.
>> >
>> > Section 2.6.7 of the specification states that "the physical address
>> > fields of the ELF section header then refer to where the sections are
>> > in memory".
>> >
>> > Sections that are loaded are handled differently in the code from
>> > sections that are not loaded. This distinction is made at line  234.
>> > The loaded sections are ignored.
>> >
>> > The "sh_addr" field of entries in the table for not-loaded sections
>> > are explicitly updated to point to the address where those sections
>> > are copied (line 265).
>> >
>> > For "loaded" sections loaded to a fixed address, the "sh_addr" field
>> > of the section header table entries should be accurate without any
>> > updates. However, if the image is relocated, the "sh_addr" field of
>> > the entries for relocated sections are not necessarily accurate.
>
> I am not sure that I understand this correctly. Do you mean that sh_addr
> for a given section in memory differs from its sh_addr in the image? I think
> that it is OK.

Specification claims that sh_addr is physical section address in
memory. If you agree that sh_addr may not match physical address,
specification must be updated to reflect reality.

> We care more about what is in the mem then in the image here.
>

You seem to misunderstand. Before introduction of relocatable images
ELF image was loaded at (segment) physical address, which presumably
matches (segment) virtual address; sh_addr is virtual section address
which in this case matches physical address memory.

Relocatable image can presumably be loaded everywhere, so its load
address != segment physical address anymore, so sh_addr also do not
match.

They also may not match if virtual address != physical address, but as
we do not establish any address translation when launching image, this
probably is going to fail. Still would be good to have this assumption
explicitly listed in multiboot2 manual.

>> > Is this a legitimate concern?
>>
>> Yes. @Daniel, note that tags 9, 10 are not even documented.
>
> Do you mean MULTIBOOT_TAG_TYPE_ELF_SECTIONS and MULTIBOOT_TAG_TYPE_APM?

No, I mean

#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
#define MULTIBOOT_HEADER_TAG_RELOCATABLE  10

> They are. Please take a look at line 1036 and 1121 in doc/multiboot.texi.
>
>> Unfortunately I suspect updating sh_addr may not be enough - this would
>> require updating every reference to this section address everywhere
>> else; not sure if this is really possible.
>>
>> > Alternatively, should the section
>> > header table be absent from ELF images that contain the "relocatable
>> > tag" in the multiboot2 header? Under normal circumstances, the
>> > section header table isn't really necessary for loading.
>>
>> I guess enforcing it is the more straightforward choice.
>
> You should be aware that multiboot protocols does not require ELF file
> at all. It can be PE file or even anything which does not look like well
> known executable. So, then there is no section headers at all. However,
> if you do not use ELF container then you need provide all data, e.g. entry
> point, in multiboot/multiboot2 header(s) which cannot be established other
> way (I mean from ELF header).
>

I am afraid I miss connection with problem we discuss here, sorry.

> Currently, there is no support for SHT_REL and SHT_RELA sections. OS

The problem is unrelated to symbol relocation.

> image has to take care about relocation itself. It has all data to
> do that. You can take a look how it is done in Xen source
> (xen/arch/x86/boot/head.S). I am attaching relevant patches.
>
> If you have any questions drop me a line.
>
> Daniel

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50598] GCC7: -Werror=implicit-fallthrough

[Andrei Borzenkov]

Update of bug #50598 (project grub):

 Planned Release:None => 2.03+  

___

Follow-up Comment #1:

> - /* Fallthrough in case that lvm-tools are unavailable. */
> + /* Fallthrough- in case that lvm-tools are unavailable. */ 

According to GCC7 documentation, final dash is optional. So it looks more like
GCC problem. The following should match exiting comment:

Fall((s | |-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?

Current xzembed upstream seems to add missing comments; will look at updating
after 2.02.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50597] GCC7: may be used uninitialized in this function

[Andrei Borzenkov]

Update of bug #50597 (project grub):

 Planned Release:None => 2.03+  

___

Follow-up Comment #1:

Yes, this is valid - it *is* used unitialized after the first iteration. Also
we probably should allocate it, to save stack space. Post-2.02 cleanup.
Thanks!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

17.03.2017 22:53, Ahmed, Safayet (GE Global Research, US) пишет:
> Hello again,
> 
> I had a question on the function, "grub_multiboot_load_elf(32/64)".
> (grub/grub_core/loader/multiboot_elfxx.c: line 54)
> 
> As a part of parsing an ELF image, the above-named function copies
> the section header table into memory, and copies "unloaded" sections
> into memory (lines 199 - 269). The section table may be passed to an
> OS image as the "ELF-Symbols" tag of the multiboot2 information
> structure.
> 
> Section 2.6.7 of the specification states that "the physical address
> fields of the ELF section header then refer to where the sections are
> in memory".
> 
> Sections that are loaded are handled differently in the code from
> sections that are not loaded. This distinction is made at line  234.
> The loaded sections are ignored.
> 
> The "sh_addr" field of entries in the table for not-loaded sections
> are explicitly updated to point to the address where those sections
> are copied (line 265).
> 
> For "loaded" sections loaded to a fixed address, the "sh_addr" field
> of the section header table entries should be accurate without any
> updates. However, if the image is relocated, the "sh_addr" field of
> the entries for relocated sections are not necessarily accurate.
> 
> Is this a legitimate concern? 

Yes. @Daniel, note that tags 9, 10 are not even documented.

Unfortunately I suspect updating sh_addr may not be enough - this would
require updating every reference to this section address everywhere
else; not sure if this is really possible.

> Alternatively, should the section
> header table be absent from ELF images that contain the "relocatable
> tag" in the multiboot2 header? Under normal circumstances, the
> section header table isn't really necessary for loading.
> 

I guess enforcing it is the more straightforward choice.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50518] GRUB iPXE UEFI -- sector sizes of 1 bytes aren't supported yet

[Andrei Borzenkov]

Update of bug #50518 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 2.02   

___

Follow-up Comment #11:

Fixed in c42cb97f0881a927b5039d830d1d007f2eaa5b50, should be in 2.02.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50526] UEFI + linux16/initrd16 == system reboot

[Andrei Borzenkov]

Follow-up Comment #4, bug #50526 (project grub):

Attempt to load memtest with linux16 resets system just as well. I do not see
how you can possibly use linux16 on EFI system with anything, and if it works
it is just by luck.

There is version of memtest for EFI.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50526] UEFI + linux16/initrd16 == system reboot

[Andrei Borzenkov]

Update of bug #50526 (project grub):

Category: Booting => Compilation
Severity:   Major => Minor  
  Status: Invalid => None   
 Open/Closed:  Closed => Open   

___

Follow-up Comment #2:

Why is it then built on EFI platform? I turn it into build system bug.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50518] GRUB iPXE UEFI -- sector sizes of 1 bytes aren't supported yet

[Andrei Borzenkov]

Follow-up Comment #10, bug #50518 (project grub):

You are using linux16/initrd16. I would never expect someone to use them on
EFI system.

Anyway this is unrelated problem because I get the same reset even without
iPXE involved, loading from disk. Please open separate bug for it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50518] GRUB iPXE UEFI -- sector sizes of 1 bytes aren't supported yet

[Andrei Borzenkov]

Follow-up Comment #8, bug #50518 (project grub):

I cannot reproduce reset. I can successfully boot after loading linux/initrd
both from local disk or network. This is using qemu 2.6.2 ffea0a2c and iPXE
ROM from current QEMU git.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50518] GRUB iPXE UEFI -- sector sizes of 1 bytes aren't supported yet

[Andrei Borzenkov]

Follow-up Comment #5, bug #50518 (project grub):

Sorry, fixed patch attached.

(file #39975)
___

Additional Item Attachment:

File name: ipxe-block-io.patchSize:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50518] GRUB iPXE UEFI -- sector sizes of 1 bytes aren't supported yet

[Andrei Borzenkov]

Follow-up Comment #4, bug #50518 (project grub):

Please try attached patch that detects iPXE pseudo-block-io and skips it.
Unfortunately older versions of iPXE do not add PXE protocol to network
handle; this was added in

commit 3376fa520b0ce4ba3f0d9bad626617acf88908df
Author: Michael Brown 
Date:   Tue Sep 1 21:23:34 2015 +0100

[efi] Implement the EFI_PXE_BASE_CODE_PROTOCOL

So for example in my case booting still fails because now we are not able to
auto-configure network. So if boot fails for you with something like "root is
not set" - this is iPXE issue, you need to update it.

(file #39974)
___

Additional Item Attachment:

File name: ipxe-block-io.patchSize:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50518] GRUB iPXE UEFI -- sector sizes of 1 bytes aren't supported yet

[Andrei Borzenkov]

Follow-up Comment #3, bug #50518 (project grub):

iXPE option ROM started to bind BlockIO protocol to network handles. This
causes GRUB to enumerate NIC as block device, so it skips network
(auto-)configuration. Later it fails because iPXE BlockIO does not match our
expectations.

In case of QEMU you can work around it by either removing option ROMs entirely
or forcing to not use it:

-net user,tftp=/tmp/net,bootfile=/boot/grub/x86_64-efi/core.efi -device
virtio-net-pci,romfile=,vlan=0

You must use virtio-net-pci, because this is the only device OVMF has built-in
driver for.

For real hardware situation is bad indeed. 

BlockIO protocol is added as side effect of adding simple filesystem
protocol:

commit fc87adb46c1395b09302085e9d15fcd8ab3c31fe
Author: Michael Brown 
Date:   Wed Mar 13 22:36:32 2013 +

[efi] Expose downloaded images via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL

And later

   /* Install the simple file system protocol, block I/O
 * protocol, and disk I/O protocol.  We don't have a block
 * device, but large parts of the EDK2 codebase make the
 * assumption that file systems are normally attached to block
 * devices, and so we create a dummy block device on the same
 * handle just to keep things looking normal.
 */


I do not have immediate ideas how to fix it. Any heuristic to skip  such
devices has potential of breaking later (like skipping iSCSI volumes or
similar).


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Tag-alignment in multiboot2 image headers

[Andrei Borzenkov]

On Thu, Mar 9, 2017 at 1:17 AM, Ahmed, Safayet (GE Global Research,
US)  wrote:
> Hello,
>
> I'm seeing an inconsistency in the multiboot2 specification and the 
> implementation of the multiboot2 loader code in GRUB. It may be my 
> understanding that's incorrect. A clarification would be appreciated.
>
> This concerns the alignment requirements for tags in OS image headers. The 
> specification states 4 bytes, but the code uses 8 bytes.
>
> The specification states (Section 3.1.3) that "Tags constitutes a buffer of 
> structures following each other padded on 'u32' size."
>

This is ambiguous and needs better wording as well (it is not clear
whether "padded" here applies to individual tag or all tags block).

> The "for" loop for parsing tags uses the following "increment" statement 
> (grub/grub_core/loader/multiboot_mbi2.c: line 148):
> tag = (struct multiboot_header_tag *) ((grub_uint32_t *) tag + ALIGN_UP 
> (tag->size, MULTIBOOT_TAG_ALIGN) / 4))
>
> The macro MULTIBOOT_TAG_ALIGN is defined in (include/multiboot2.h) as 8. This 
> alignment value is consistent with the specification for tags in the 
> multiboot2 information structure, but not for tags in an OS image header.
>

Yes, it sure looks wrong. Thanks for making us aware!

@Vladimir, @Daniel - I think this is 2.02 material, we do not want
release with such inconsistency. The question is what needs fixing
though - about half of all tags are not multiple of 8 bytes, so I
expect people to hit it in real life. What is current implementation
in MB2 compliant kernels?

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50364] Can't load kernel or initd from lvm

[Andrei Borzenkov]

Update of bug #50364 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50442] GRUB can not load Ubuntu after grub-istall and update-grub

[Andrei Borzenkov]

Update of bug #50442 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

According to your output kernel and initrd are correctly loaded but can not
find one of required devices. This is outside of grub scope. Please contact
Ubuntu help forums for assistance.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50364] Can't load kernel or initd from lvm

[Andrei Borzenkov]

Follow-up Comment #4, bug #50364 (project grub):

Note that vmlinuz is also missing in "Location of files loaded by Grub"; so it
does not look like grub problem. Any chance there is some hidden character in
file name? What "ls -b /boot" shows?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50364] Can't load kernel or initd from lvm

[Andrei Borzenkov]

Follow-up Comment #3, bug #50364 (project grub):

I can't reproduce it. As you are apparently using legacy BIOS boot, could you
run https://github.com/arvidjaar/bootinfoscript and attach RESULTS.txt?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50420] EFI version loads executable code as EfiLoaderData

[Andrei Borzenkov]

Follow-up Comment #1, bug #50420 (project grub):

How exactly do you load grubaa64.efi?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [PATCH] squash4: fix handling of fragments and sparse files

[Andrei Borzenkov]

23.02.2017 16:52, Vladimir 'phcoder' Serbinenko пишет:
> On Sat, Feb 18, 2017, 10:17 Andrei Borzenkov  wrote:
> 
>> 1. Do not assume block list and fragment are mutually exclusive. Squash
>> can pack file tail as fragment (unless -no-fragments is specified); so
>> check read offset and read either from block list or from fragments as
>> appropriate.
>>
>> 2. Support sparse files with zero blocks.
>>
>> 3. Fix fragment read - frag.offset is absolute fragment position,
>> not offset relative to ino.chunk.
>>
> Go ahead.
> 

Done with cosmetic changes (renamed one variable to better match
surrounding code and removed now superfluous assignment).

>>
>> Reported and tested by Carlo Caione 
>>
>> ---
>>
>> @Vladimir: we need regression tests for both of these cases. We could real
>> small
>> files only by accident - block list was zero, so it appeared to work.
>>
> How do you create those files reliably? Feel free to add any files to
> grub-fs-tester. Feel free to commit without tests, we can add tests later.
> 

I would say, we need to generally create less "nice" test files

1. Generate test files that are not exact multiple of filesystem block.
This would cover squash tail packing and may uncover similar issues in
other drivers as well.

2. Generate sparse files by seeking beyond end of file. We already had
similar problem with indirect ext* blocks that was not caught by tests.
We should produce holes both for direct and indirect blocks (we may pick
common offset or make it fs-specific if necessary).

3. We need to produce really small files also to test inlining. Again we
can pick common size or make it fs-specific.

Assuming we generate files as described, for squash4 just call it with
-always-use-fragments to force tail packing. -nopad may be interesting
as well to stress our driver even more.



___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50364] Can't load kernel or initd from lvm

[Andrei Borzenkov]

Follow-up Comment #1, bug #50364 (project grub):

Please test with current git or at least 2.02~rc1.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[PATCH] squash4: fix handling of fragments and sparse files

[Andrei Borzenkov]

1. Do not assume block list and fragment are mutually exclusive. Squash
can pack file tail as fragment (unless -no-fragments is specified); so
check read offset and read either from block list or from fragments as
appropriate.

2. Support sparse files with zero blocks.

3. Fix fragment read - frag.offset is absolute fragment position,
not offset relative to ino.chunk.

Reported and tested by Carlo Caione 

---

@Vladimir: we need regression tests for both of these cases. We could real small
files only by accident - block list was zero, so it appeared to work.

@Carlo, please test. I'm surprised it worked for you even without fragments as
your file is sparse and grub immediately choked on the first zero block.

 grub-core/fs/squash4.c | 55 +-
 1 file changed, 36 insertions(+), 19 deletions(-)

diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
index b97b344..deee71a 100644
--- a/grub-core/fs/squash4.c
+++ b/grub-core/fs/squash4.c
@@ -823,7 +823,12 @@ direct_read (struct grub_squash_data *data,
   curread = data->blksz - boff;
   if (curread > len)
curread = len;
-  if (!(ino->block_sizes[i]
+  if (!ino->block_sizes[i])
+   {
+ /* Sparse block */
+ grub_memset (buf, '\0', curread);
+   }
+  else if (!(ino->block_sizes[i]
& grub_cpu_to_le32_compile_time (SQUASH_BLOCK_UNCOMPRESSED)))
{
  char *block;
@@ -873,36 +878,57 @@ direct_read (struct grub_squash_data *data,
 
 
 static grub_ssize_t
-grub_squash_read_data (struct grub_squash_data *data, 
-  struct grub_squash_cache_inode *ino,
-  grub_off_t off, char *buf, grub_size_t len)
+grub_squash_read (grub_file_t file, char *buf, grub_size_t len)
 {
+  struct grub_squash_data *data = file->data;
+  struct grub_squash_cache_inode *ino = &data->ino;
+  grub_off_t off = file->offset;
   grub_err_t err;
   grub_uint64_t a = 0, b;
   grub_uint32_t fragment = 0;
   int compressed = 0;
   struct grub_squash_frag_desc frag;
+  grub_off_t blk_len;
+  grub_uint64_t mask = grub_le_to_cpu32 (data->sb.block_size) - 1;
+  grub_size_t orig_len = len;
 
   switch (ino->ino.type)
 {
 case grub_cpu_to_le16_compile_time (SQUASH_TYPE_LONG_REGULAR):
-  a = grub_le_to_cpu64 (ino->ino.long_file.chunk);
   fragment = grub_le_to_cpu32 (ino->ino.long_file.fragment);
   break;
 case grub_cpu_to_le16_compile_time (SQUASH_TYPE_REGULAR):
-  a = grub_le_to_cpu32 (ino->ino.file.chunk);
   fragment = grub_le_to_cpu32 (ino->ino.file.fragment);
   break;
 }
 
-  if (fragment == 0x)
-return direct_read (data, ino, off, buf, len);
+  /* Squash may pack file tail as fragment. So read initial part directly and
+ get tail from fragments */
+  blk_len  = fragment == 0x ? file->size : file->size & ~mask;
+  if (off < blk_len)
+{
+  grub_size_t read_len = blk_len - off;
+  grub_ssize_t res;
+
+  if (read_len > len)
+   read_len = len;
+  res = direct_read (data, ino, off, buf, read_len);
+  if ((grub_size_t) res != read_len)
+   return -1; /* FIXME: is short read possible here? */
+  len -= read_len;
+  if (!len)
+   return read_len;
+  buf += read_len;
+  off = 0;
+}
+  else
+off -= blk_len;
  
   err = read_chunk (data, &frag, sizeof (frag),
data->fragments, sizeof (frag) * fragment);
   if (err)
 return -1;
-  a += grub_le_to_cpu64 (frag.offset);
+  a = grub_le_to_cpu64 (frag.offset);
   compressed = !(frag.size & grub_cpu_to_le32_compile_time 
(SQUASH_BLOCK_UNCOMPRESSED));
   if (ino->ino.type == grub_cpu_to_le16_compile_time 
(SQUASH_TYPE_LONG_REGULAR))
 b = grub_le_to_cpu32 (ino->ino.long_file.offset) + off;
@@ -943,16 +969,7 @@ grub_squash_read_data (struct grub_squash_data *data,
   if (err)
return -1;
 }
-  return len;
-}
-
-static grub_ssize_t
-grub_squash_read (grub_file_t file, char *buf, grub_size_t len)
-{
-  struct grub_squash_data *data = file->data;
-
-  return grub_squash_read_data (data, &data->ino,
-   file->offset, buf, len);
+  return orig_len;
 }
 
 static grub_err_t
-- 
tg: (2fb8cd2..) u/squash-tail-fragment (depends on: master)

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Problem with ISO9660 and files stored on multiple extents

[Andrei Borzenkov]

17.02.2017 21:18, Andrei Borzenkov пишет:
> 
> Not quite. We assume that fragment and block list are mutually
> exclusive, while squashfs can pack file tail that does not fill full
> block as fragment. So we actually need to do direct_read() 

And BTW it does not look like direct_read() copes with sparse files either.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Problem with ISO9660 and files stored on multiple extents

[Andrei Borzenkov]

16.02.2017 20:42, Carlo Caione пишет:
> On Thu, Feb 16, 2017 at 5:52 PM, Andrei Borzenkov  wrote:
>> 16.02.2017 19:04, Vladimir 'phcoder' Serbinenko пишет:
>>> On Thu, Feb 16, 2017, 16:56 Carlo Caione  wrote:
> 
>>> Then it's possible that your patch is correct. I don't know why the format
>>> changes or what the 0 means in this field
>>>
>>
>> Looking at current squash tools git, 0 is valid fragment number. Any
>> chance we hit different file type here? Carlo, could you make your
>> squashfs image available?
> 
> Here the whole non-booting ISO
> https://d1anzknqnc1kmb.cloudfront.net/eos-amd64-amd64/eos3.1/sea/170214-155339/eos-eos3.1-amd64-amd64.170214-155339.sea.iso
> (`endless/endless.squash` is the squash image)
> `qemu-system-x86_64 -m 512 -machine q35,accel=kvm -hda $iso` drops you
> into a GRUB shell (same booting with EFI). For smaller images it boots
> fine.
> 
> We actually solved this problem creating the squashfs passing the
> option `-no-fragments` to `mksquashfs`. So I guess that really the
> squash4 module has some bug when dealing with big images with a number
> of fragments !=0.
> 

Not quite. We assume that fragment and block list are mutually
exclusive, while squashfs can pack file tail that does not fill full
block as fragment. So we actually need to do direct_read() followed by
the rest of grub_squash_read_data() if fragment is not invalid. Your
patch worked by accident (because there was only one fragment with
number 0) and actually made it truncate file.

I need to wrap my head around our code unless Vladimir beats me (I'm
sure he will :) )

For reference, here is what unsquashfs does

for(i = 0; i < inode->blocks; i++) {
... read blocks etc. This is our direct_read
}

if(inode->frag_bytes) {
...
s_ops.read_fragment(inode->fragment, &start, &size);
block->buffer = cache_get(fragment_cache, start, size);
block->offset = inode->offset;
block->size = inode->frag_bytes;
queue_put(to_writer, block);
}

inode->frag_bytes != 0 if fragment != 0x and file size is not
exact multiple of blocks.

i.frag_bytes = inode->fragment ==
SQUASHFS_INVALID_FRAG
?  0 : inode->file_size % sBlk.s.block_size;


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Problem with ISO9660 and files stored on multiple extents

[Andrei Borzenkov]

16.02.2017 19:04, Vladimir 'phcoder' Serbinenko пишет:
> On Thu, Feb 16, 2017, 16:56 Carlo Caione  wrote:
> 
>> On Thu, Feb 16, 2017 at 4:54 PM, Vladimir 'phcoder' Serbinenko
>>  wrote:
>>>
>>>
>>> On Thu, Feb 16, 2017, 14:14 Carlo Caione  wrote:
>>>>
>>>> On Thu, Feb 16, 2017 at 2:09 PM, Vladimir 'phcoder' Serbinenko
>>>>  wrote:
>>>>>
>>>>>
>>>>> On Thu, Feb 16, 2017, 14:04 Carlo Caione  wrote:
>>>>>>
>>>>>> On Thu, Feb 16, 2017 at 12:37 PM, Carlo Caione 
>>>>>> wrote:
>>>>>>> On Thu, Feb 16, 2017 at 12:32 PM, Thomas Schmitt <
>> scdbac...@gmx.net>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Carlo Caione wrote:
>>>>>>>>>> I think that the problem
>>>>>>>>>> here is that endless.squash has been stored in two extents in
>> the
>>>>>>>>>> ISO9660 and GRUB doesn't deal fine with that (also according to
>>>>>>>>>> this
>>>>>>>>>> comment
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960
>>>>>>>>
>>>>>>>> Andrei Borzenkov wrote:
>>>>>>>>> This comment could be stale and misleading.
>>>>>>>>
>>>>>>>> The code of read_node() in iso9660.c looks ready for multi-extent
>>>>>>>> (aka
>>>>>>>> ISO
>>>>>>>> level 3).
>>>>>>>>
>>>>>>>> I have a very densely compressed test ISO for large file support
>>>>>>>>http://scdbackup.webframe.org/large.iso.bz2
>>>>>>>> which bunzip2 inflates from 4.5 KiB to 4+ GiB.
>>>>>>>
>>>>>>> Yeah, I made some more tests and apparently the problem is not in
>> the
>>>>>>> ISO9660 module but in the SQUASH4 module.
>>>>>>> To be perfectly honest I have already a patch that solves my
>> problem
>>>>>>> but I'm having a hard time to understand WHY it solves the issue
>>>>>>> since
>>>>>>> I'm still not really familiar with squashfs (I casually found it
>>>>>>> during my debugging).
>>>>>>> Of course probably it is only masking a problem somewhere else.
>> Still
>>>>>>> digging.
>>>>>>>
>>>>>>> diff --git a/grub-core/fs/squash4.c b/grub-core/fs/squash4.c
>>>>>>> index b97b344..4fef813 100644
>>>>>>> --- a/grub-core/fs/squash4.c
>>>>>>> +++ b/grub-core/fs/squash4.c
>>>>>>> @@ -895,7 +895,7 @@ grub_squash_read_data (struct grub_squash_data
>>>>>>> *data,
>>>>>>>break;
>>>>>>>  }
>>>>>>>
>>>>>>> -  if (fragment == 0x)
>>>>>>> +  if (fragment == 0x || fragment == 0)
>>>>>>>  return direct_read (data, ino, off, buf, len);
>>>>>>>
>>>>>>>err = read_chunk (data, &frag, sizeof (frag),
>>>>>>
>>>>>> Hey Vladimir,
>>>>>> Any idea about this?
>>>>>
>>>>> How big is the file in question? What is the squash tools version?
>>>>
>>>> The squash image is 4564504576
>>>
>>> I mean the size of file you try to access
>>
>> In the squashfs image there is one single file of size 1147128
>>
> Then it's possible that your patch is correct. I don't know why the format
> changes or what the 0 means in this field
> 

Looking at current squash tools git, 0 is valid fragment number. Any
chance we hit different file type here? Carlo, could you make your
squashfs image available?

>>
>> --
>> Carlo Caione  |  +39.340.80.30.096  |  Endless
>>
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Problem with ISO9660 and files stored on multiple extents

[Andrei Borzenkov]

16.02.2017 00:30, Carlo Caione пишет:
> Hi,
> in our ISO images in the ISO9660 partition we ship a squashfs image
> containing the full OS image.
> At boot GRUB does something like this:
> 
> loopback loop_squash ($eosimage)/endless/endless.squash
> loopback loop_img (loop_squash)/endless.img
> set root=(loop_img,gpt3)
> 
> This is working fine for our small images without any problem.
> 
> The problem arises when the size of endless.squash is >4GB. In this
> case accessing (loop_img) just fails with:
> 
> No known filesystem detected
> 
> I spent a bit tracking down this issue and I think that the problem
> here is that endless.squash has been stored in two extents in the
> ISO9660 and GRUB doesn't deal fine with that (also according to this
> comment 
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960).
> 

This comment could be stale and misleading.

> Could be this the cause of the problem? Any suggestion besides
> extending the iso9660 module with the support for files stored on
> multiple extents?
> 

Quick look suggests that it does process multi-extents

while (dirent.flags & FLAG_MORE_EXTENTS)
  {

in grub_iso9660_iterate_dir()

I suggest you try to use gdb on grub-fstest binary that allows stepping
through the code to see where it misbehaves.

> This is briefly how I tracked down the issue. When squash_mount() is
> called it tried to access the squashfs image to retrieve the number of
> the fragments, this is done basically reading at sb.unk1offset in the
> squashfs image. This number for images >4GB is clearly wrong. Being
> the image mounted in loopback what happens is that grub is trying to
> read the squashfs file on the ISO9660 partition at file->offset >4GB
> in grub_iso9660_read(). Inspecting the ISO with isoinfo we have:
> 
> --   000  4294965248 Feb 15 2017 [  13356 
> ENDLESS.SQUASH;1
> --   000   269539328 Feb 15 2017 [2110507 00]
> ENDLESS.SQUASH;1
> 
> That is in grub_iso9660_read() we are trying to access the second
> extent, reading rubbish.
> 
> Is this theory correct?
> 
> Thank you,
> 
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #16, bug #50245 (project grub):

> I'm using v4.60 which is newer that yours 4.52

Oops, sorry, I somehow had 4.50 in mind. Yes, 4.60 is 64 bit only, so I cannot
easily test it (I do not have 64 bit Windows). This could of course be tftp32
regression.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #14, bug #50245 (project grub):

BTW I cannot reproduce it with TFTPD32 v4.52 at all. There is "PXE
compatibility" option which indeed makes TFTPD32 process only tsize option but
even if I enable it, grub still boots just fine and tftpd32 log shows that it
answered with tsize option. I suggest you update your server, there is no
point to use old version really.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #13, bug #50245 (project grub):

> tftpd v4.60 + i386 -> working like a charm

OK, let's finish with this part. Could you please another version of the patch
(please revert previous version first). It continues to send blksize but in
different order. Please attach packet trace for boot to verify this works as
intended.

> tftpd v4.60 + efi -> can not even load grub. ( VMware is restarting after
trying to load boox64.efi )

Again, make sure you are using clean build environment and recreated all grub
files. 

> 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #10, bug #50245 (project grub):

I cannot reproduce it - version with patch boots correctly here. Please try
with clean build out of GIT + patch and make sure to recreate netboot
directory using just built grub:

pkgdatadir=$PWD ./grub-mknetdir --net-directory ... -d grub-core

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Update of bug #50245 (project grub):

 Release:2.00 => 2.02~rc1   

___

Follow-up Comment #8:

OK. Your packet trace shows that server does not respond with OACK for GRUB
request.

Firmware loading boot file:

 21  13.320650   10.48.1.10 -> 10.48.1.1TFTP 67 Read Request, File:
booti386, Transfer type: octet, tsize=0
 22  13.32100710.48.1.1 -> 10.48.1.10   TFTP 56 Option Acknowledgement,
tsize=47819

GRUB loading normal.mod

215  13.519659   10.48.1.10 -> 10.48.1.1TFTP 96 Read Request, File:
/grub/i386-pc/normal.mod, Transfer type: octet, blksize=1024, tsize=0
216  13.52256610.48.1.1 -> 10.48.1.10   TFTP 558 Data Packet, Block: 1

Could you try attached patch to verify it; it does not send blksize option to
match firmware behavior.

(file #39736)
___

Additional Item Attachment:

File name: tftpd32-oack.patch Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #6, bug #50245 (project grub):

Sorry, I do not understand. You report problem with grub on x86_64-efi
platform and attach packet capture for grub on i386-pc platform. How is it
relevant for EFI problem?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #4, bug #50245 (project grub):

So it did configure some address. Is it the correct one? Please run tcpdump or
wireshark on TFTP server and provide packet capture together with IP address
grub was using.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #46014] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andrei Borzenkov]

Follow-up Comment #8, bug #46014 (project grub):

> debianized it 

This is upstream bug tracker. We cannot usually know what patches
distributions add. Please test clean upstream build, without any addon
patches.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: remove spurious lines from grub-install [patch]

[Andrei Borzenkov]

09.02.2017 21:49, 積丹尼 Dan Jacobson пишет:
> All I know is I am using
> # apt-cache policy grub2-common
> grub2-common:
>   Installed: 2.02~beta3-4
>   Candidate: 2.02~beta3-4
>   Version table:
>  *** 2.02~beta3-4 500
> 500 http://free.nchc.org.tw/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
Please report it to Debian unless you can reproduce it with clean
upstream build.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50245] Tftp error while booting via PXE

[Andrei Borzenkov]

Follow-up Comment #2, bug #50245 (project grub):

what is output of

net_ls_cards
net_ls_addr

??

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: remove spurious lines from grub-install [patch]

[Andrei Borzenkov]

08.02.2017 18:00, 積丹尼 Dan Jacobson пишет:
> grub-install --help | grep -n Usage
> 1:Usage: grub-install [OPTION...] [OPTION] [INSTALL_DEVICE]
> 51:  Usage: grub-install [OPTION...] [OPTION] [INSTALL_DEVICE]
> 
>>>>>> "AB" == Andrei Borzenkov  writes:
> AB> On Thu, Dec 22, 2016 at 12:03 PM, 積丹尼 Dan Jacobson  
> wrote:
>>> OK please remove the last two lines with words at:
>>>
>>> -s, --skip-fs-probe
>>> do not probe for filesystems in DEVICE
>>>
>>> Usage: grub-install [OPTION...] [OPTION] [INSTALL_DEVICE]
>>>
>>> Install GRUB on your drive.
>>>
> 
> AB> These two lines are expected to be at the very beginning. Please
> AB> attach full "grub-install --help" output.
> 

What grub version (exact commit) do you use to build it?

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50237] Wrong descsz in Xen ELF note 9 (PAE_MODEL)

[Andrei Borzenkov]

Update of bug #50237 (project grub):

 Planned Release:None => 2.03+  

___

Follow-up Comment #1:

Yes, this looks wrong, but unless you can provide test case where it breaks,
it is post 2.02 cleanup. Looking at note description, it will actually affect
only older Xen versions. Otherwise it should simply get "yes" string.

grub-mkimage was created long before xen headers were imported into grub
tree.

Feel free to submit cleanup patch to grub-devel. Please split it in to commits
(one for "yes,bimodal" and one for using symbolic names.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50244] Scripting fails on greater and less compares

[Andrei Borzenkov]

Update of bug #50244 (project grub):

Category:None => Documentation  
  Status:None => Confirmed  
 Planned Release:None => 2.02   

___

Follow-up Comment #1:

This works if you quote it (if [ a "<" b ]); '<' and '>' are special lexical
tokens. It's really not different from normal shell where you would need to
quote them as well. Not sure whether we really need to make them tokens in
grub though.

Anyway for release we can only clarify documentation.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49012] The all_videos module error in binutils 2.27 for xen platform

[Andrei Borzenkov]

Update of bug #49012 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Should be fixed in 6371e9c10433578bb236a8284ddb9ce9e201eb59. Please reopen if
needed. Thank you!.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50093] Build failure with flex 2.6.3

[Andrei Borzenkov]

Update of bug #50093 (project grub):

 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

This is fixed in current flex git, so closing.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49942] EFI: grub-install may fail if /boot/efi is managed by autofs

[Andrei Borzenkov]

Update of bug #49942 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

Should be fixed in a2932fbe8a602f3abd7c9b97004a31dc1a384639. 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50093] Build failure with flex 2.6.3

[Andrei Borzenkov]

Follow-up Comment #3, bug #50093 (project grub):

Regarding issue itself - it appears bug in flex, introduced in 2.6.3. The
conflicting defines are under %if-not-reentrant, and grub has "%option
reentrant" in its yylex.l. Other projects are affected as well.

https://github.com/westes/flex/issues/162


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50093] Build failure with flex 2.6.3

[Andrei Borzenkov]

Follow-up Comment #2, bug #50093 (project grub):

Thank you, but please, either file separate bugs for separate issues, or use
grub-devel for such reports (even better, send patch to grub-devel).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49942] EFI: grub-install may fail if /boot/efi is managed by autofs

[Andrei Borzenkov]

Update of bug #49942 (project grub):

 Planned Release:None => 2.02   

___

Follow-up Comment #3:

It turned out to be less trivial than I hoped due to the fact that stat() does
not trigger automount with Linux autofs. I think I have found workaround, will
post later patch to list for review.

We need this to be fixed in 2.02 as systemd now defaults to automounting ESP.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: grub-mkconfig can't process unicode file /etc/default/grub

[Andrei Borzenkov]

16.01.2017 19:08, Kim Olsen пишет:
> 
> Hello,
> 
> If "/etc/default/grub" contains the typical unicode identifier
> "" at the beginning of the file the program "grub-mkconfig"
> unfairly reports an error.
> 

This is shell script that is sourced by grub-mkconfig. Does your shell
accept such script when run standalone? If not, there is nothing grub
can do here.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #50036] compilation error... No rule to make target 'de.po'

[Andrei Borzenkov]

Follow-up Comment #1, bug #50036 (project grub):

Translations are not part of grub, they are maintained on
translationproject.org. You are responsible for downloading them and updating
po/LILNGUAS with list of available translations before running configure.

Please describe exact steps starting with downloading grub tarball (or git
checkout) until this error.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: x64 Lubuntu 16.10 installation of grub2 in PBR fails to work

[Andrei Borzenkov]

01.01.2017 23:19, Bernd Dreyer пишет:
> Hello!
> 
> OS: Lubuntu 16.10 x64
> Installation of Grub2 into the MBR is predetermined by the Lubuntu installer 
> during installation.
> However, trying of such an installation results in an error as the Windows 10 
> bootloader resides in the MBR
> PBR installations are also refused by the Lubuntu installer.
> Installation proceeds without installing grub.
> SuperGrub however, manages to boot Lubuntu.
> Installation in the PBR of the Lubuntu partition is only possible by using 
> grub-install with the application of -- force.

What exactly is the grub bug that you report?

> But, booting this partition via an EasyBCD configured bootloader in Windows 
> 10 fails and a grub shell is displayed.
> In a x86 processor laptop an EasyBCD configured Windows bootloader manages to 
> start such a prepared partition.
> 
> Kindest Regards
> 
> Bernd Dreyer
> 
> 
> 
> 
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #48100] Booting in blind mode on macmini-2,1

[Andrei Borzenkov]

Follow-up Comment #3, bug #48100 (project grub):

Just to be sure - your grub is started in text or graphical mode?

Do you have possibility to run git master? Then we could try some debugging
what's going on.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49942] EFI: grub-install may fail if /boot/efi is managed by autofs

[Andrei Borzenkov]

Follow-up Comment #1, bug #49942 (project grub):

Does "realpath /boot/efi" work in such case (i.e. when it is not yet mounted)?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Cannot pass a single backslash in multiboot cmdline

[Andrei Borzenkov]

26.12.2016 21:56, Jakub Jermář пишет:
> On 12/26/2016 07:24 PM, Andrei Borzenkov wrote:
>> 26.12.2016 21:12, Jakub Jermář пишет:
>>>>> I am observing a strange behavior when passing boot arguments with a
>>>>> backslash to the kernel (the multiboot cmd_line via the multiboot
>>>>> command in grub.cfg). I would like to pass foo\bar to the kernel, but to
>>>>> no avail. I tried:
>>>>>
>>>>
>>>> Which kernel? What do you load?
>>>
>>> The kernel is a modified version of HelenOS, but IMHO this issue is
>>> kernel agnostic.
>>
>> Not really. It depends on target program being loaded which is why I
>> asked what you use.
> 
> Ok, I submitted my grub.cfg and stated that HelenOS is
> multiboot-compliant, gets loaded by the multiboot command. We boot from
> an ISO image, which was created like this:
> 
> "The binary files of GRUB boot loader in this directory have been
> created by compiling GRUB for the 'i386-pc' target and then using the
> grub-mkrescue script to create the El Torito boot image."
> 
> Is there anything else I should include in order to answer your question?
> 

Multiboot only passes single "string" as command line. As far as I can
tell this is true for both multiboot1 and multiboot2. Loaded kernel
likely will need to parse this string to split it into individual
parameters. This means that to pass character(s) used to split string
verbatim you need some quoting rules.

So it is up to you to define how your kernel parses string. grub is just
the messenger here.

>>> The cmd_line is already wrong when picked up from the
>>> multiboot info and printed out (so there is no processing on it from the
>>> HelenOS side).
>>
>> Sure, but /if/ your kernel interpreted `\' as quoting character, the
>> result would be correct.
> 
> But instead of the plain actual data there would be escaped data, which
> is a hassle. And also a possible workaround.
> 

Again - how your kernel splits string into multiple parameters? Assuming
your kernel does support multiple parameters of course.

>>> I think I understand why it is eating the single backslash (expected
>>> behavior),
>>
>> You have two levels here. First level is grub command line processing.
>> It is loosely compatible with (Bourne) shell so yes, backslash is
>> treated as escape character. You can still pass backslash using usual
>> shell quoting, e.g. foo\\bar or 'foo\bar'. Second level is
>> grub_create_loader_cmdline() function. This one escapes `\' with second
>> `\'. So in the above case this function receives `foo\bar' as adds
>> second `\'.
> 
> This explains a lot, but does not make much sense for my usecase.
> 

Sure but we need to understand your use case first :)

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Cannot pass a single backslash in multiboot cmdline

[Andrei Borzenkov]

26.12.2016 21:12, Jakub Jermář пишет:
> Hi Andrei,
> 
> On 12/26/2016 06:59 PM, Andrei Borzenkov wrote:
>> 26.12.2016 17:44, Jakub Jermář пишет:
>>> Hi,
>>>
>>> I am observing a strange behavior when passing boot arguments with a
>>> backslash to the kernel (the multiboot cmd_line via the multiboot
>>> command in grub.cfg). I would like to pass foo\bar to the kernel, but to
>>> no avail. I tried:
>>>
>>
>> Which kernel? What do you load?
> 
> The kernel is a modified version of HelenOS, but IMHO this issue is
> kernel agnostic.

Not really. It depends on target program being loaded which is why I
asked what you use.

> The cmd_line is already wrong when picked up from the
> multiboot info and printed out (so there is no processing on it from the
> HelenOS side).

Sure, but /if/ your kernel interpreted `\' as quoting character, the
result would be correct.

> The argument I am trying to pass is actually a HelenOS
> path to the serial console service, something like:
> 
> devices/\hw\pci0\00:01.0\com1\a
> 
> The backslashes are part of the service's name.
> 
>>> foo\bar gets passed as foobar
>>> foo\\bar gets passed as foo\\bar
>>> 'foo\bar' gets passed as foo\\bar
>>> "foo\bar" gets passed as foo\\bar
>>>
>>> Note that the backslash gets doubled when I try to escape it.
>>>
>>> I am using grub 2.02~beta2, revision
>>> bc220962e366b1b46769ed6f9fa5be603ba58ab5.
>>>
>>> How does one pass foo\bar so that the back slash does not get eaten or
>>> doubled?
>>>
>>
>> You can't currently. I do not know what was intended when grub cmdline
>> was written, but the way it quotes string is definitely not compatible
>> with linux kernel (which only recognizes `"' as valid quote character).
> 
> I think I understand why it is eating the single backslash (expected
> behavior),

You have two levels here. First level is grub command line processing.
It is loosely compatible with (Bourne) shell so yes, backslash is
treated as escape character. You can still pass backslash using usual
shell quoting, e.g. foo\\bar or 'foo\bar'. Second level is
grub_create_loader_cmdline() function. This one escapes `\' with second
`\'. So in the above case this function receives `foo\bar' as adds
second `\'.

Now if you pass it to linux kernel as example, it does not treat `\'
specially so result is wrong. Same as in your case. It is just that
linux does not normally need it.

> so the issue mainly is with why is it duplicating the escaped
> (unexpected behavior) backslashes.
> 
>> Could you please open formal bug report on savannah, so we could discuss
>> its priority.
> 
> Ok, will do.
> 
>> And yes, this is not the first report. Actually there could be similar
>> bug already.
> 
> Sorry, I was searching for it, but the bug tracking system on savannah
> is not very user friendly and I simply got no results.
> 

Well, I won't argue here. I believe to have seen something similar, but
it may be on grub-devel.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: Cannot pass a single backslash in multiboot cmdline

[Andrei Borzenkov]

26.12.2016 17:44, Jakub Jermář пишет:
> Hi,
> 
> I am observing a strange behavior when passing boot arguments with a
> backslash to the kernel (the multiboot cmd_line via the multiboot
> command in grub.cfg). I would like to pass foo\bar to the kernel, but to
> no avail. I tried:
> 

Which kernel? What do you load?

> foo\bar gets passed as foobar
> foo\\bar gets passed as foo\\bar
> 'foo\bar' gets passed as foo\\bar
> "foo\bar" gets passed as foo\\bar
> 
> Note that the backslash gets doubled when I try to escape it.
> 
> I am using grub 2.02~beta2, revision
> bc220962e366b1b46769ed6f9fa5be603ba58ab5.
> 
> How does one pass foo\bar so that the back slash does not get eaten or
> doubled?
> 

You can't currently. I do not know what was intended when grub cmdline
was written, but the way it quotes string is definitely not compatible
with linux kernel (which only recognizes `"' as valid quote character).

I wonder *what* supports quoting used by grub (which is effectively
shell quoting).

Could you please open formal bug report on savannah, so we could discuss
its priority.

And yes, this is not the first report. Actually there could be similar
bug already.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49910] grub and bios does not detect a keyboard

[Andrei Borzenkov]

Update of bug #49910 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Closing then.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: remove spurious lines from grub-install [patch]

[Andrei Borzenkov]

On Thu, Dec 22, 2016 at 12:03 PM, 積丹尼 Dan Jacobson  wrote:
> OK please remove the last two lines with words at:
>
>-s, --skip-fs-probe
>   do not probe for filesystems in DEVICE
>
>   Usage: grub-install [OPTION...] [OPTION] [INSTALL_DEVICE]
>
>Install GRUB on your drive.
>

These two lines are expected to be at the very beginning. Please
attach full "grub-install --help" output.

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: remove spurious lines from grub-install [patch]

[Andrei Borzenkov]

On Thu, Dec 22, 2016 at 8:46 AM, 積丹尼 Dan Jacobson  wrote:
> --- grub-install.8  2016-12-22 13:43:11.570414605 +0800
> +++ grub-install.8.NEW  2016-12-22 13:44:27.344510504 +0800

Manual pages are auto-generated from help output using help2man. You
need to fix help output if you think something is wrong.

> @@ -113,10 +113,6 @@
>  .TP
>  \fB\-s\fR, \fB\-\-skip\-fs\-probe\fR
>  do not probe for filesystems in DEVICE
> -.IP
> -Usage: grub\-install [OPTION...] [OPTION] [INSTALL_DEVICE]
> -.PP
> -Install GRUB on your drive.
>  .TP
>  \fB\-\-compress\fR=\fI\,no\/\fR|xz|gz|lzo
>  compress GRUB files [optional]
>
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #48228] grub-mkconfig assumes grub-probe will only produce 1 line of output, breaks with mirrored zfs volumes

[Andrei Borzenkov]

Follow-up Comment #5, bug #48228 (project grub):

Please provide debug information I asked for.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: no end of grub-mkconfig -o

[Andrei Borzenkov]

17.12.2016 12:01, M. Zywek пишет:
> Hello, since more than a Year I have a problem with the command "sudo
> grub-mkconfig -o /boot/grub/grub.cfg". I starts to work, gives out the
> information of 10_linux and then hesitates. It does not come to an end.
> If I take a look into my taskmanager, I see that the process grub-mount
> takes at about 27% of CPU. I kill that process and the command goes on
> to work. Most of the time I get a correct grub.cfg
> Sometimes one of my operating systems is forgotten. It is always
> Antergos XFCE.
> 

grub-mount is not used by any script that is delivered with upstream
grub. It may be used by os-prober which is not part of grub; or your
distribution may ship additional scripts that call it.

Please report it to your distribution. In openSUSE there are patches for
os-prober to address similar issue.

> Boot section is sda; grub.cfg is layed down in sdd2. There are 5 OS on
> my machine. Win 10, LXQt-Manjaro, Antergos XFCE, Mate Manjaro, Linux
> Mint Mate 18.
> If you need more informations, please ask me.
> Sincerely, Michael Zywek
> 
> 
> 
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #48100] Booting in blind mode on macmini-2,1

[Andrei Borzenkov]

Follow-up Comment #1, bug #48100 (project grub):

Could you attach your grub.cfg and dmesg output after Linux is booted?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [PING] Re: Add check for -no-pie if the compiler default to -fPIE

[Andrei Borzenkov]

Committed. Thanks!

09.11.2016 01:01, Magnus Granberg пишет:
> söndag 6 november 2016 kl. 10:05:53 CET skrev du:
>> 21.10.2016 00:26, Magnus Granberg пишет:
>>> lördag 21 maj 2016 kl. 20:53:48 CEST skrev du:
>>>> On Saturday 21 May 2016 19.26.18 you wrote:
>>>>> 21.05.2016 19:02, Magnus Granberg пишет:
>>>>>> On Saturday 21 May 2016 18.55.11 you wrote:
>>>>>>> 21.05.2016 17:47, Magnus Granberg пишет:
>>>>>>>> When Grub is compile with gcc 6.1 that have --enable-defult-pie set.
>>>>>>>> It fail with.
>>>>>>>> -ffreestanding   -m32 -Wl,-melf_i386 -Wl,--build-id=none  -nostdlib
>>>>>>>> -Wl,-N
>>>>>>>> -Wl,-r,-d   - o trig.module  trig_module-trigtables.o
>>>>>>>> grep 'MARKER' gcry_whirlpool.marker.new > gcry_whirlpool.marker; rm
>>>>>>>> -f
>>>>>>>> gcry_whirlpool.marker.new
>>>>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gn
>>>>>>>> u
>>>>>>>> /b
>>>>>>>> in
>>>>>>>> /ld: -r and - shared may not be used together
>>>>>>>> collect2: error: ld returned 1 exit status
>>>>>>>> Makefile:26993: recipe for target 'trig.module' failed
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-05-21  Magnus Granberg  
>>>>>>>>
>>>>>>>>acinclude.m4: Add check for -no-pie.configure.ac: Add 
>>>>>>>> -no-pie to
>>>>>>>>
>>>>>>>> TARGET_LDFLAGS if needed.
>>>>>>>> ...
>>>>>>>
>>>>>>> Please test with current master:
>>>>>>>
>>>>>>> commit f4d35d49e32c29183b3492da18ea480d91716efe
>>>>>>> Author: Andrei Borzenkov 
>>>>>>> Date:   Tue Mar 22 20:12:22 2016 +0300
>>>>>>>
>>>>>>> configure: set -fno-pie together with -fno-PIE
>>>>>>
>>>>>> Still fail the same way
>>>>>
>>>>> Please send full config.log and output of make.
>>>>
>>>> Gcc 6.1 pass -pie to the linker if is configure with --enable-default-pie
>>>> When linking with -r it don't mix well with -pie/-shared
>>>> Gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=583042 with logs
>>>> Patch updated
>>>
>>> Any progres on this?
>>
>> My apologies. Do we really need any explicit check for this? As far as I
>> can tell, options -fpie, -fPIE, -pie appeared in the same GCC release
>> (at least they first mentioned in 3.4 documentation together). Manual
>> also says that -fpie/-fPIE and -pie must be used together.
>>
> https://gcc.gnu.org/gcc-6/changes.html (Other significant improvements)
> gcc 6.x is the only compiler that can enable -fPIE -pie as default
> without passing it on the command line. Debian/Ubuntu are testing to use this 
> as we do in Gentoo hardened. we allready disable -fPIE if needed but not -pie
> 
>> We do use $CC for linker - at least, by default. So it appears we should
>> be able to simply set -no-pie, no?
>>
> Is only gcc 6.X and newer linker that support -no-pie.
>  
>> Does clang support -fpie/-fPIE/-(no-)pie options? I do not see them in
>> help output, but it does not say much.
>>
> Clang support -fPIE/-fpie but i don't know if it support -no-pie
>> Oh, BTW, you have typo in patch
>>
>>> +[AC_MSG_CHECKING([whether linker accepts -no-pie])
>>> +AC_CACHE_VAL(grub_cv_cc_ld_nopie,
>>
>>   ^
>>
>>> +[save_LDFLAGS="$LDFLAGS"
>>> +LDFLAGS="$LDFLAGS -no-pie"
>>> +AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
>>> +  [grub_cv_cc_ld_no_pie=yes],
>>> +  [grub_cv_cc_ld_no_pie=no])
>>
>>   ^^
> Fixed in the updated patch
> 
> 2016-11-08  Magnus Granberg  
> 
>   * acinclude.m4: Add check for -no-pie.
>   * configure.ac: Add -no-pie to TARGET_LDFLAGS if needed.
> 
> 
> 
> ___
> Bug-grub mailing list
> Bug-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-grub
> 


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49814] vbe does not reset display start

[Andrei Borzenkov]

Follow-up Comment #2, bug #49814 (project grub):

> When exiting and setting the old mode, it doesn't 
> reset the display start. 

It should do it in grub_video_fb_get_info_and_fini() which should be called by
at least linux loaders (via grub_video_get_info_and_fini). Please give more
details about your setup and grub.cfg.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49814] vbe does not reset display start

[Andrei Borzenkov]

Follow-up Comment #1, bug #49814 (project grub):

Could you attach proposed patch?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49657] Lenovo x200 grub ls hangs, only with DVD drive installed and empty

[Andrei Borzenkov]

Follow-up Comment #1, bug #49657 (project grub):

What platform - legacy BIOS or EFI? 32 or 64 bit? As usual, testing with
current GIT snapshot would be helpful.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49365] Booting: GNU/Linux: partially incorrect information

[Andrei Borzenkov]

Update of bug #49365 (project grub):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

It simply avoids using device prefix later and does not affect access to
$prefix in any way.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49290] Add commands with cli only documentation to the main documentation

[Andrei Borzenkov]

Update of bug #49290 (project grub):

Severity:   Major => Ordinary   

___

Follow-up Comment #1:

Unless you intend it as tracking bug - patches are welcome. No need to collect
everything, you can submit patches for those commands you are interested in.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #42466] GRUB cannot load symlinks of length 60 on ext4

[Andrei Borzenkov]

Follow-up Comment #4, bug #42466 (project grub):

Well, that appears to work for Linux, and looks straightforward to me. See
fs/ext4/inode.c:ext4_inode_is_fast_symlink().

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49340] Some variables in tex manual are CAPS that should be lowercase

[Andrei Borzenkov]

Update of bug #49340 (project grub):

  Status:None => Confirmed  

___

Follow-up Comment #1:

Yes, it looks wrong in this case. I figure, it should be @samp{chosen}. Please
send a patch. Thank you!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49316] Missing support for ARM64-EFI in grub-mknetdir

[Andrei Borzenkov]

Update of bug #49316 (project grub):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 2.02   

___

Follow-up Comment #1:

Applied. Thanks!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49340] Some variables in tex manual are CAPS that should be lowercase

[Andrei Borzenkov]

Update of bug #49340 (project grub):

 Planned Release:None => 2.02   


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

Re: [PING] Re: Add check for -no-pie if the compiler default to -fPIE

[Andrei Borzenkov]

09.11.2016 01:01, Magnus Granberg пишет:
> söndag 6 november 2016 kl. 10:05:53 CET skrev du:
>> 21.10.2016 00:26, Magnus Granberg пишет:
>>> lördag 21 maj 2016 kl. 20:53:48 CEST skrev du:
>>>> On Saturday 21 May 2016 19.26.18 you wrote:
>>>>> 21.05.2016 19:02, Magnus Granberg пишет:
>>>>>> On Saturday 21 May 2016 18.55.11 you wrote:
>>>>>>> 21.05.2016 17:47, Magnus Granberg пишет:
>>>>>>>> When Grub is compile with gcc 6.1 that have --enable-defult-pie set.
>>>>>>>> It fail with.
>>>>>>>> -ffreestanding   -m32 -Wl,-melf_i386 -Wl,--build-id=none  -nostdlib
>>>>>>>> -Wl,-N
>>>>>>>> -Wl,-r,-d   - o trig.module  trig_module-trigtables.o
>>>>>>>> grep 'MARKER' gcry_whirlpool.marker.new > gcry_whirlpool.marker; rm
>>>>>>>> -f
>>>>>>>> gcry_whirlpool.marker.new
>>>>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gn
>>>>>>>> u
>>>>>>>> /b
>>>>>>>> in
>>>>>>>> /ld: -r and - shared may not be used together
>>>>>>>> collect2: error: ld returned 1 exit status
>>>>>>>> Makefile:26993: recipe for target 'trig.module' failed
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-05-21  Magnus Granberg  
>>>>>>>>
>>>>>>>>acinclude.m4: Add check for -no-pie.configure.ac: Add 
>>>>>>>> -no-pie to
>>>>>>>>
>>>>>>>> TARGET_LDFLAGS if needed.
>>>>>>>> ...
>>>>>>>
>>>>>>> Please test with current master:
>>>>>>>
>>>>>>> commit f4d35d49e32c29183b3492da18ea480d91716efe
>>>>>>> Author: Andrei Borzenkov 
>>>>>>> Date:   Tue Mar 22 20:12:22 2016 +0300
>>>>>>>
>>>>>>> configure: set -fno-pie together with -fno-PIE
>>>>>>
>>>>>> Still fail the same way
>>>>>
>>>>> Please send full config.log and output of make.
>>>>
>>>> Gcc 6.1 pass -pie to the linker if is configure with --enable-default-pie
>>>> When linking with -r it don't mix well with -pie/-shared
>>>> Gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=583042 with logs
>>>> Patch updated
>>>
>>> Any progres on this?
>>
>> My apologies. Do we really need any explicit check for this? As far as I
>> can tell, options -fpie, -fPIE, -pie appeared in the same GCC release
>> (at least they first mentioned in 3.4 documentation together). Manual
>> also says that -fpie/-fPIE and -pie must be used together.
>>
> https://gcc.gnu.org/gcc-6/changes.html (Other significant improvements)
> gcc 6.x is the only compiler that can enable -fPIE -pie as default
> without passing it on the command line. Debian/Ubuntu are testing to use this 

As far as I can tell, it is default on 64 bit in Ubuntu 16.10.

> as we do in Gentoo hardened. we allready disable -fPIE if needed but not -pie
> 
>> We do use $CC for linker - at least, by default. So it appears we should
>> be able to simply set -no-pie, no?
>>
> Is only gcc 6.X and newer linker that support -no-pie.
>  

bor@bor-Latitude-E5450:/tmp$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bor@bor-Latitude-E5450:/tmp$ gcc -o foo -no-pie -fno-pie foo.c
foo.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 main() {}
 ^

>> Does clang support -fpie/-fPIE/-(no-)pie options? I do not see them in
>> help output, but it does not say much.
>>
> Clang support -fPIE/-fpie but i don't know if it support -no-pie

It does not look so.

OK, so to summarize my understanding.

1. GNU ld itself needs explicit -pie option and defaults to equivalent
of -no-pie

2. GCC spec can be changed to enable -pie by default for linker which is
being done now by distributions

3. clang seems to default to -no-pie and require explicit -pie to linker
to enable it

So we need to care only about GCC case, so far clang default is OK for us.

Is my understanding correct?
Which means, so far we only need to care about GCC case

___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #49531] HTTP module does not support HTTP Pipelining

[Andrei Borzenkov]

Update of bug #49531 (project grub):

 Planned Release:None => 2.03+  

___

Follow-up Comment #6:

I think at this point it is better to move discussion to grub-devel, savannah
bug tracker is not really suitable for patch review. Some comments regarding
second patch.

  if (file->device->net->packs.count >= 20)
-   {
- file->device->net->stall = 1;
+   file->device->net->stall = 1;
+
+ if (file->device->net->packs.count >= 100)
  grub_net_tcp_stall (data->sock);
-   }

This changes logic without any explanation why.

+ if (data->size_recv && data->downloaded_size >= file->size)
+   file->device->net->stall = 1;

file size may also be unknown in advance. We also already have code in
parse_line() to set stall and eof. Why is it not kicked in?

As for the original problem, looks OK but I would prefer to delay it for post
2.02; it is not critical and such changes always have potential for
regressions. Thank you for understanding.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-grub mailing list
Bug-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-grub