Hi Adrian,
On 2023.07.22 11:25, John Paul Adrian Glaubitz wrote:
OK, seems like this was just related to mawk vs. gawk. Builds fine with gawk.
Yes, this is what I also reported in an earlier post to this list:
https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00047.html
Regards,
/Pete
Hi Daniel,
Thanks for the long awaited 2.12~rc1.
As I have mentioned in the past, and I feel need to mention again on
account that it continues causes real-life grievances for downstream
GRUB end users and especially people trying to install Linux, the formal
GRUB 2.12 release cannot come soo
Hi,
I finally got a chance to test this proposal (mostly in the context of
Rufus and for BIOS boot), and everything looks good to me.
Thanks a lot for adding an option to disable the warning when invoking
configure!
I also second the idea that we want a unique identifier added to the
versi
On 2022.12.25 07:57, Zhang Boyang wrote:
This commit add vermagic string to GRUB modules. Specifically, a unique
but shared vermagic string is embedded in .modver section of each
module, and it is checked at module loading time. The vermagic string is
uniquely generated by configure script in eac
On 2022.12.23 07:18, Zhang Boyang wrote:
This feature is implemented in kern/dl.c in core.img, which is UNDER
YOUR CONTROL.
Let me analyze the worst case from your perspective:
1) Every distro is enforcing version check, even in BIOS mode.
2) Because this check is in kern/dl.c, there is no su
I'm sorry but that's NO_GO for me.
This is a major step back from v2, where the check was never applicable
for BIOS and I believe I explained why a module check that can be
enforced for BIOS is going to create a major headache for end-users.
It seems pretty obvious that, if distro maintainers
Hi again Zhang,
I hadn't had a chance to properly look at your v2 before replying
earlier, and it looks like it addresses the elements I had an issue with.
On 2022.12.21 12:11, Zhang Boyang wrote:
This patch add version information to GRUB modules. Specifically,
PACKAGE_VERSION is embedded as
Hi Zhang,
On 2022.12.21 11:38, Zhang Boyang wrote:
Hi,
On 2022/12/21 17:43, Thomas Schmitt wrote:
Hi,
Pete Batard wrote:
unlike what is the case for UEFI, one can not expect
to be able to pick all the GRUB core files needed to convert a GRUB
based ISO bootable media to a GRUB based USB boota
Hello all,
On 2022.12.20 22:58, Robbie Harwood wrote:
Zhang Boyang writes:
This patch add version information to GRUB modules. Specifically,
PACKAGE_VERSION is embedded as null-terminated string in .modver
section. This string is checked at module loading time. That module will
be rejected if
Just noticed that there's a typo in the title ("file UUID file") so
please make sure to remove one of the "file" from the commit title if
this patch does get validated for integration.
Thanks,
/Pete
On 2022.11.25 17:22, Pete Batard wrote:
The final piece needed to add UEFI file system trans
Changes from v1:
- Rebased against latest GRUB
- Validated patches against coding guidelines
- Clarified comments
Note: If you are interested in testing this series, I have jolted down some
guidelines at:
https://gist.github.com/pbatard/0deddbd71eefc35a3ed0b08e12a9e7e3
--
In order to add file system transposition support for UEFI, i.e. the ability
to copy the content of an ISO9660 grub-mkrescue ISO image onto user-formatted
media, and have that boot on UEFI systems, the first thing we need to do is
add support for the file systems that are natively handled by UEFI.
The final piece needed to add UEFI file system transposition support is to
ensure the boot media can be located regardless of how the boot partition
was instantiated. Especially, we do not want to be reliant on brittle
partition UUIDs, as these only work if a boot media is duplicated at the
block l
To enable file system transposition support for UEFI, we also must ensure that
there exists a copy of the EFI bootloaders, that are currently embedded in the
efi.img for xorriso, at their expected UEFI location on the ISO9660 file system.
This is accomplished by removing the use of a temporary dir
Hi Daniel,
On 2022.11.03 17:59, Daniel Kiper wrote:
Thank you for detailed explanation. I can consider your patches as more
than "nice to have" but it may mean we will have to delay code freeze
and maybe release date. To reduce impact on dates please be ready to
reply to my comments as quickly a
Hi Daniel,
Thanks for keeping us updated on your the release progress and release
plans.
On 2022.10.26 15:52, Daniel Kiper wrote:
We are getting closer to the 2.12 release. Sadly we still do not have
many of important patch sets in the tree. So, I am going to spend more
time on reviews in the
16 matches
Mail list logo
