[RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Heinrich Schuchardt]

Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
boundary") grubarm.efi crashes. Let's revert it.

a51f953f4ee8 ("mkimage: Align efi sections on 4k boundary")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
As Alexander Graf pointed out in a private mail without his patch
Qcom ARM notebooks did not work. So I am sending this as an RFC.
---
 include/grub/efi/pe32.h | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/include/grub/efi/pe32.h b/include/grub/efi/pe32.h
index 0ed8781f0..d1359eb66 100644
--- a/include/grub/efi/pe32.h
+++ b/include/grub/efi/pe32.h
@@ -20,7 +20,6 @@
 #define GRUB_EFI_PE32_HEADER	1

 #include <grub/types.h>
-#include <grub/efi/memory.h>

 /* The MSDOS compatibility stub. This was copied from the output of
    objcopy, and it is not necessary to care about what this means.  */
@@ -51,14 +50,8 @@
 /* According to the spec, the minimal alignment is 512 bytes...
    But some examples (such as EFI drivers in the Intel
    Sample Implementation) use 32 bytes (0x20) instead, and it seems
-   to be working.
-
-   However, there is firmware showing up in the field now with
-   page alignment constraints to guarantee that page protection
-   bits take effect. Because currently existing GRUB code can not
-   properly distinguish between in-memory and in-file layout, let's
-   bump all alignment to GRUB_EFI_PAGE_SIZE. */
-#define GRUB_PE32_SECTION_ALIGNMENT	GRUB_EFI_PAGE_SIZE
+   to be working. For now, GRUB uses 512 bytes for safety.  */
+#define GRUB_PE32_SECTION_ALIGNMENT	0x200
 #define GRUB_PE32_FILE_ALIGNMENT	GRUB_PE32_SECTION_ALIGNMENT

 struct grub_pe32_coff_header
--
2.20.1

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Colin Watson]

On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
> Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
> boundary") grubarm.efi crashes. Let's revert it.
> 
> a51f953f4ee8 ("mkimage: Align efi sections on 4k boundary")
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> As Alexander Graf pointed out in a private mail without his patch
> Qcom ARM notebooks did not work. So I am sending this as an RFC.

In that case it doesn't seem terribly productive to propose reverting
it, RFC or not.  If we can't figure out a better approach, making the
value architecture-specific using #ifdef or similar would be more
constructive.

(However, hopefully somebody with more domain expertise than me can
actually track down the problem properly.)

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Daniel Kiper]

On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
> Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
> boundary") grubarm.efi crashes. Let's revert it.

Everywhere or on a specific machines?

Daniel

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Heinrich Schuchardt]

On 4/18/19 12:41 PM, Daniel Kiper wrote:
> On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
>> Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
>> boundary") grubarm.efi crashes. Let's revert it.
>
> Everywhere or on a specific machines?

I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
qemu-arm-system -machine virt with the current Debian Buster GRUB.

Best regards

Heinrich

>
> Daniel
>

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Julien ROBIN]

[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]

Hi, I don't know if others folks are easily able to test and reproduce 
the issue and test suggested patch, so I did some builds, and tests 
based on the EFI file produced by grub-mkstandalone using -O arm-efi : 
it's a trivial way to test what code version is working or not with 
qemu-system-arm for example.

Unfortunately, with or without applying the RFC suggested reverting 
patch, and even with the Grub 2.02 version, using qemu-system-arm and an 
efi firmware for it, *I can't get any efi version of grub working fine 
on qemu and arm (32 bits) :*
https://image.noelshack.com/fichiers/2019/16/4/1555617325-screenshot-from-2019-04-18-21-51-22.png

I did the comparison by building for

  * --target=arm-linux-gnueabihf, grub-mkstandalone using -O arm-efi
    (naming the resulting file bootarm.efi)
    and
  * --target=aarch64-linux-gnu, grub-mkstandalone using -O arm64-efi
    (naming the resulting file bootaa64.efi). I also did make sure that
    I wasn't mixing wrong files during the process.

I placed more details here  : https://sorel.pixconfig.fr/GRUB/ (commands 
for having everything build and started, qemu EFI firmwares, resulting 
files with current grub and 2.02 of 32 and 64 bits) for those who 
quickly want to do their own tests.

Heinrich, did you succeeded to get an arm-efi version of grub booting on 
some qemu-system-arm machine ? Are you using another qemu arm efi 
firmware ? I'm using this one : https://efi.akeo.ie/QEMU_EFI/


Also, debian-9.8.0-armhf-netinst.iso and even 
debian-10-2019-04-18-JR-armhf-NETINST-1.iso (created using easy-build 
and a local updated mirror), does not seem to contain any EFI boot 
loader (Debian for armhf isn't using efi) so I wasn't able to confront 
any debian armhf efi thing.


Finally, I can confirm the qemu efi arm firmware is working at least 
enough for having this efi file running : 
https://github.com/pbatard/uefi-simple but it's probably because the 
qemu efi arm firmware comes from here ;) so it's not very surprising if 
it work with it.

If I can help with my time for testing things, feel free to ask me!
Best regards,
Julien ROBIN


On 4/18/19 5:14 PM, Heinrich Schuchardt wrote:
> On 4/18/19 12:41 PM, Daniel Kiper wrote:
>> On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
>>> Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
>>> boundary") grubarm.efi crashes. Let's revert it.
>>
>> Everywhere or on a specific machines?
>
> I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
> qemu-arm-system -machine virt with the current Debian Buster GRUB.
>
> Best regards
>
> Heinrich
>
>>
>> Daniel
>>
>

[-- Attachment #2: Type: text/html, Size: 4197 bytes --]

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Heinrich Schuchardt]

On 4/19/19 12:02 AM, Julien ROBIN wrote:
> Hi, I don't know if others folks are easily able to test and reproduce
> the issue and test suggested patch, so I did some builds, and tests
> based on the EFI file produced by grub-mkstandalone using -O arm-efi :
> it's a trivial way to test what code version is working or not with
> qemu-system-arm for example.
>
> Unfortunately, with or without applying the RFC suggested reverting
> patch, and even with the Grub 2.02 version, using qemu-system-arm and an
> efi firmware for it, *I can't get any efi version of grub working fine
> on qemu and arm (32 bits) :*
> https://image.noelshack.com/fichiers/2019/16/4/1555617325-screenshot-from-2019-04-18-21-51-22.png
>
> I did the comparison by building for
>
>   * --target=arm-linux-gnueabihf, grub-mkstandalone using -O arm-efi
>     (naming the resulting file bootarm.efi)
>     and
>   * --target=aarch64-linux-gnu, grub-mkstandalone using -O arm64-efi
>     (naming the resulting file bootaa64.efi). I also did make sure that
>     I wasn't mixing wrong files during the process.
>
> I placed more details here  : https://sorel.pixconfig.fr/GRUB/ (commands
> for having everything build and started, qemu EFI firmwares, resulting
> files with current grub and 2.02 of 32 and 64 bits) for those who
> quickly want to do their own tests.
>
> Heinrich, did you succeeded to get an arm-efi version of grub booting on
> some qemu-system-arm machine ? Are you using another qemu arm efi
> firmware ? I'm using this one : https://efi.akeo.ie/QEMU_EFI/

The firmware I am using is U-Boot which is available as

git clone git://git.denx.de/u-boot-efi.git
cd u-boot
make qemu_arm_defconfig
make

To use it with QEMU:

qemu-system-arm -bios u-boot.bin -machine virt -cpu cortex-a15 ...

>
>
> Also, debian-9.8.0-armhf-netinst.iso and even
> debian-10-2019-04-18-JR-armhf-NETINST-1.iso (created using easy-build
> and a local updated mirror), does not seem to contain any EFI boot
> loader (Debian for armhf isn't using efi) so I wasn't able to confront
> any debian armhf efi thing.
You will need a FAT formatted partition mounted at /boot/efi

sudo -s
apt-get install qemu-arm-efi
grub-install --target=arm-efi
update grub

To boot with GRUB you can use these commands on the U-Boot console:

load mmc 0:2 ${fdt_addr_r} dtb
load mmc 0:1 ${kernel_addr_r} EFI/debian/grubarm.efi
bootefi ${kernel_addr_r} ${fdt_addr_r}

If you want to build the Debian packages yourself on your 32bit ARM system:

wget
http://deb.debian.org/debian/pool/main/g/grub2/grub2_2.02+dfsg1.orig.tar.xz
wget
http://deb.debian.org/debian/pool/main/g/grub2/grub2_2.02+dfsg1-16.debian.tar.xz
tar -xJf grub2_2.02+dfsg1.orig.tar.xz
tar -xJf grub2_2.02+dfsg1-16.debian.tar.xz
cp -R debian grub-2.02+dfsg1/
cd grub-2.02+dfsg1/
sudo apt-get install \
debhelper patchutils python flex bison po-debconf help2man texinfo \
gcc-8 xfonts-unifont libfreetype6-dev gettext libdevmapper-dev \
libsdl1.2-dev xorriso cpio parted libfuse-dev ttf-dejavu-core \
liblzma-dev wamerican pkg-config bash-completion
dpgk-buildpackage
cd ..
ls *.deb

You can install the built packages with
sudo dpkg -i \
grub2-common_2.02+dfsg1-16_armhf.deb \
grub-common_2.02+dfsg1-16_armhf.deb \
grub-efi-arm_2.02+dfsg1-16_armhf.deb \
grub-efi-arm-bin_2.02+dfsg1-16_armhf.deb

Best regards

Heinrich

>
>
> Finally, I can confirm the qemu efi arm firmware is working at least
> enough for having this efi file running :
> https://github.com/pbatard/uefi-simple but it's probably because the
> qemu efi arm firmware comes from here ;) so it's not very surprising if
> it work with it.
>
> If I can help with my time for testing things, feel free to ask me!
> Best regards,
> Julien ROBIN
>
>
> On 4/18/19 5:14 PM, Heinrich Schuchardt wrote:
>> On 4/18/19 12:41 PM, Daniel Kiper wrote:
>>> On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
>>>> Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
>>>> boundary") grubarm.efi crashes. Let's revert it.
>>>
>>> Everywhere or on a specific machines?
>>
>> I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
>> qemu-arm-system -machine virt with the current Debian Buster GRUB.
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Daniel
>>>
>>

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Daniel Kiper]

On Thu, Apr 18, 2019 at 05:14:58PM +0200, Heinrich Schuchardt wrote:
> On 4/18/19 12:41 PM, Daniel Kiper wrote:
> > On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
> > > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
> > > boundary") grubarm.efi crashes. Let's revert it.
> >
> > Everywhere or on a specific machines?
>
> I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
> qemu-arm-system -machine virt with the current Debian Buster GRUB.

Leif, Alex, could you take closer look at this thread? I would like to
know what to do with reported issues in it and in particular we should
get or not the patch itself.

Daniel

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Steve McIntyre]

On Thu, Apr 18, 2019 at 05:14:58PM +0200, Heinrich Schuchardt wrote:
>On 4/18/19 12:41 PM, Daniel Kiper wrote:
>> On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
>> > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
>> > boundary") grubarm.efi crashes. Let's revert it.
>> 
>> Everywhere or on a specific machines?
>
>I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
>qemu-arm-system -machine virt with the current Debian Buster GRUB.

Nod. I've seen similar in a qemu VM and on a Beaglebone Black. Leif's
aware and promised me he'd look when he's back from his travels.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"This dress doesn't reverse." -- Alden Spiess

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Julien ROBIN]

[-- Attachment #1: Type: text/plain, Size: 5947 bytes --]

Thanks Heinrich, so I tested with your approach and u-boot.bin.

The reason why I had no version of arm-efi grub working was because I 
had to add _/--with-platform=efi/_ while playing "./configure [...]"
On arm64-efi it's fine to forgot it but not in arm-efi builds.

Now I can confirm the same problem and confirm also that the suggested 
RFC about _/grub/include/grub/efi/pe32.h/_ makes it start on arm-efi 
(with the u-boot method but also with various QEMU-EFI-ARM firmwares I 
recently found).
Unfortunately, the suggested RFC about _/grub/include/grub/efi/pe32.h/_ 
also breaks compatibility with the Asus NovaGo TP370QL I have here, at 
least (Qualcomm Snapdragon 835, arm64-efi)

I updated my summary file so anyone can easily drive the arm-efi tests 
on future modifications, with a simple x86_64 computer, qemu, and some 
minutes of work. https://sorel.pixconfig.fr/GRUB/commands.txt.

Have a nice week end
Julien


/PS : may be making a summary of all architectures/configurations tests 
tutorials would be useful ? Even if it's just QEMU (it would even be a 
lot of work), and used on new releases or wide changes, or just from 
time to time to see if no accident happened in any recent changes. It 
would also be an awesome tutorial for people starting to deal with grub/

/
/

On 4/19/19 5:29 AM, Heinrich Schuchardt wrote:
> On 4/19/19 12:02 AM, Julien ROBIN wrote:
>> Hi, I don't know if others folks are easily able to test and reproduce
>> the issue and test suggested patch, so I did some builds, and tests
>> based on the EFI file produced by grub-mkstandalone using -O arm-efi :
>> it's a trivial way to test what code version is working or not with
>> qemu-system-arm for example.
>>
>> Unfortunately, with or without applying the RFC suggested reverting
>> patch, and even with the Grub 2.02 version, using qemu-system-arm and an
>> efi firmware for it, *I can't get any efi version of grub working fine
>> on qemu and arm (32 bits) :*
>> https://image.noelshack.com/fichiers/2019/16/4/1555617325-screenshot-from-2019-04-18-21-51-22.png 
>>
>>
>> I did the comparison by building for
>>
>>   * --target=arm-linux-gnueabihf, grub-mkstandalone using -O arm-efi
>>     (naming the resulting file bootarm.efi)
>>     and
>>   * --target=aarch64-linux-gnu, grub-mkstandalone using -O arm64-efi
>>     (naming the resulting file bootaa64.efi). I also did make sure that
>>     I wasn't mixing wrong files during the process.
>>
>> I placed more details here  : https://sorel.pixconfig.fr/GRUB/ (commands
>> for having everything build and started, qemu EFI firmwares, resulting
>> files with current grub and 2.02 of 32 and 64 bits) for those who
>> quickly want to do their own tests.
>>
>> Heinrich, did you succeeded to get an arm-efi version of grub booting on
>> some qemu-system-arm machine ? Are you using another qemu arm efi
>> firmware ? I'm using this one : https://efi.akeo.ie/QEMU_EFI/
>
> The firmware I am using is U-Boot which is available as
>
> git clone git://git.denx.de/u-boot-efi.git
> cd u-boot
> make qemu_arm_defconfig
> make
>
> To use it with QEMU:
>
> qemu-system-arm -bios u-boot.bin -machine virt -cpu cortex-a15 ...
>
>>
>>
>> Also, debian-9.8.0-armhf-netinst.iso and even
>> debian-10-2019-04-18-JR-armhf-NETINST-1.iso (created using easy-build
>> and a local updated mirror), does not seem to contain any EFI boot
>> loader (Debian for armhf isn't using efi) so I wasn't able to confront
>> any debian armhf efi thing.
> You will need a FAT formatted partition mounted at /boot/efi
>
> sudo -s
> apt-get install qemu-arm-efi
> grub-install --target=arm-efi
> update grub
>
> To boot with GRUB you can use these commands on the U-Boot console:
>
> load mmc 0:2 ${fdt_addr_r} dtb
> load mmc 0:1 ${kernel_addr_r} EFI/debian/grubarm.efi
> bootefi ${kernel_addr_r} ${fdt_addr_r}
>
> If you want to build the Debian packages yourself on your 32bit ARM 
> system:
>
> wget
> http://deb.debian.org/debian/pool/main/g/grub2/grub2_2.02+dfsg1.orig.tar.xz 
>
> wget
> http://deb.debian.org/debian/pool/main/g/grub2/grub2_2.02+dfsg1-16.debian.tar.xz 
>
> tar -xJf grub2_2.02+dfsg1.orig.tar.xz
> tar -xJf grub2_2.02+dfsg1-16.debian.tar.xz
> cp -R debian grub-2.02+dfsg1/
> cd grub-2.02+dfsg1/
> sudo apt-get install \
> debhelper patchutils python flex bison po-debconf help2man texinfo \
> gcc-8 xfonts-unifont libfreetype6-dev gettext libdevmapper-dev \
> libsdl1.2-dev xorriso cpio parted libfuse-dev ttf-dejavu-core \
> liblzma-dev wamerican pkg-config bash-completion
> dpgk-buildpackage
> cd ..
> ls *.deb
>
> You can install the built packages with
> sudo dpkg -i \
> grub2-common_2.02+dfsg1-16_armhf.deb \
> grub-common_2.02+dfsg1-16_armhf.deb \
> grub-efi-arm_2.02+dfsg1-16_armhf.deb \
> grub-efi-arm-bin_2.02+dfsg1-16_armhf.deb
>
> Best regards
>
> Heinrich
>
>>
>>
>> Finally, I can confirm the qemu efi arm firmware is working at least
>> enough for having this efi file running :
>> https://github.com/pbatard/uefi-simple but it's probably because the
>> qemu efi arm firmware comes from here ;) so it's not very surprising if
>> it work with it.
>>
>> If I can help with my time for testing things, feel free to ask me!
>> Best regards,
>> Julien ROBIN
>>
>>
>> On 4/18/19 5:14 PM, Heinrich Schuchardt wrote:
>>> On 4/18/19 12:41 PM, Daniel Kiper wrote:
>>>> On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
>>>>> Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
>>>>> boundary") grubarm.efi crashes. Let's revert it.
>>>>
>>>> Everywhere or on a specific machines?
>>>
>>> I observed the issue on a TinkerBoard (Rockchip RK3288 CPU) and on
>>> qemu-arm-system -machine virt with the current Debian Buster GRUB.
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>>>
>>>> Daniel
>>>>
>>>
>

[-- Attachment #2: Type: text/html, Size: 9851 bytes --]

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Jesús Diéguez Fernández]

El 19/4/19 a las 17:32, Julien ROBIN escribió:
> Thanks Heinrich, so I tested with your approach and u-boot.bin.
> 

[...]

> 
> 
> /PS : may be making a summary of all architectures/configurations tests
> tutorials would be useful ? Even if it's just QEMU (it would even be a
> lot of work), and used on new releases or wide changes, or just from
> time to time to see if no accident happened in any recent changes. It
> would also be an awesome tutorial for people starting to deal with grub/
> 

As a complete newbie, I can confirm that this is a real need. I recently
contributed a small modification and didn't know exactly which
compilation options I should enable. I finally used a configuration I
found elsewhere, but that's inconsistent if the official way ignores
some warnings or the other way around, treats all warnings as errors.

I know that recently a travis configuration file was added to test that
GRUB builds fine on different platforms. I think that improving it has
more value than just creating a plain text documentation.

The travis integration requires that the code must be hosted on github
(or setup something like this https://stackoverflow.com/a/49019950 ).
Would it be possible to set a remote copy of GRUB's repository on
github? I mean, not my personal copy, but an official mirror, something
like the linux kernel has.
That would allow anyone to make trivial forks on their github account
that can be tested with travis. To deal with the PR submissions on
github, the kernel has a bot that automatically replies to people (see
this example
https://github.com/torvalds/linux/pull/663#issuecomment-474615610 ).

This way around, the only documentation that should be added to
grub-dev.texi would be this workflow:

Fork from github -> make changes -> validate travis build -> send patch.

Jesus

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[John Paul Adrian Glaubitz]

On 4/19/19 9:11 PM, Jesús Diéguez Fernández wrote:
>> /PS : may be making a summary of all architectures/configurations tests
>> tutorials would be useful ? Even if it's just QEMU (it would even be a
>> lot of work), and used on new releases or wide changes, or just from
>> time to time to see if no accident happened in any recent changes. It
>> would also be an awesome tutorial for people starting to deal with grub/
>>
> 
> As a complete newbie, I can confirm that this is a real need. I recently
> contributed a small modification and didn't know exactly which
> compilation options I should enable. I finally used a configuration I
> found elsewhere, but that's inconsistent if the official way ignores
> some warnings or the other way around, treats all warnings as errors.

Well, since it's open source, anyone is invited to make something like
that happen. If you think it would be great to have a detailed set
of documentation which explains how to build GRUB for the various
configurations, you are welcome to send in a patch or set up a wiki.

> I know that recently a travis configuration file was added to test that
> GRUB builds fine on different platforms. I think that improving it has
> more value than just creating a plain text documentation.

If you really want to make thorough testing, you would also need to cross-
compile the various targets and architectures which is certainly quite
an involved task. An alternative would be to regularly create snapshots
on Debian, e.g. for a Debian package called "grub-git". Or compile
pseudo-natively with the help of QEMU which supports all GRUB targets
except for IA64.

> The travis integration requires that the code must be hosted on github
> (or setup something like this https://stackoverflow.com/a/49019950 ).
> Would it be possible to set a remote copy of GRUB's repository on
> github? I mean, not my personal copy, but an official mirror, something
> like the linux kernel has.

Alex has already set up a Travis environment for GRUB, see:

> https://travis-ci.org/agraf/grub/

> That would allow anyone to make trivial forks on their github account
> that can be tested with travis. To deal with the PR submissions on
> github, the kernel has a bot that automatically replies to people (see
> this example
> https://github.com/torvalds/linux/pull/663#issuecomment-474615610 ).

To be fair, I think proper testing of GRUB can only be done when
deployed on an actual target. It's also not really a beginner's
project anyway, so I think people who send in patches should also
be responsible for testing their changes thoroughly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [RFC 1/1] mkimage: revert "Align efi sections on 4k boundary"

[Daniel Kiper]

On Fri, Apr 19, 2019 at 09:11:50PM +0200, Jesús Diéguez Fernández wrote:
> El 19/4/19 a las 17:32, Julien ROBIN escribió:
> > Thanks Heinrich, so I tested with your approach and u-boot.bin.
> >
>
> [...]
>
> >
> >
> > /PS : may be making a summary of all architectures/configurations tests
> > tutorials would be useful ? Even if it's just QEMU (it would even be a
> > lot of work), and used on new releases or wide changes, or just from
> > time to time to see if no accident happened in any recent changes. It
> > would also be an awesome tutorial for people starting to deal with grub/
> >
>
> As a complete newbie, I can confirm that this is a real need. I recently
> contributed a small modification and didn't know exactly which
> compilation options I should enable. I finally used a configuration I
> found elsewhere, but that's inconsistent if the official way ignores
> some warnings or the other way around, treats all warnings as errors.
>
> I know that recently a travis configuration file was added to test that
> GRUB builds fine on different platforms. I think that improving it has
> more value than just creating a plain text documentation.
>
> The travis integration requires that the code must be hosted on github
> (or setup something like this https://stackoverflow.com/a/49019950 ).
> Would it be possible to set a remote copy of GRUB's repository on
> github? I mean, not my personal copy, but an official mirror, something
> like the linux kernel has.
> That would allow anyone to make trivial forks on their github account
> that can be tested with travis. To deal with the PR submissions on
> github, the kernel has a bot that automatically replies to people (see
> this example
> https://github.com/torvalds/linux/pull/663#issuecomment-474615610 ).
>
> This way around, the only documentation that should be added to
> grub-dev.texi would be this workflow:
>
> Fork from github -> make changes -> validate travis build -> send patch.

Thank you for the input. Right now we are focusing on the release.
However, after that we are going to change various things in the GRUB
project. We will be looking at GRUB code test automation, etc. too.
So, I hope that at some point we will have something similar to the
thing used by Linux kernel folks.

Daniel