Re: [PATCH] osdep/hurd/getroot: Fix 64bit build
On Sat, 2024-01-20 at 19:35 +0100, Samuel Thibault wrote: > file_get_fs_options takes a mach_msg_type_number_t (32bit), not a size_t > (64bit on 64bit platforms). Nitpick: I think it should be "32 bit", "64 bit" and "64-bit", the former two referring two a word size while the latter refers to the target type. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v7 00/10] ppc64: Restrict memory allocations for kernel and initrd
Hello Stefan! On Mon, 2023-11-27 at 06:58 -0500, Stefan Berger wrote: > This series of patches converts the PowerPC ieee1275 memory allocator > for kernel and initrd to use the (PowerPC) regions_claim memory allocator > that takes into account memory regions that are not allowed to be used, > such as the gap between 640MB and 768MB as well as memory regions beyond > an address in case an fadump is present. Otherwise those two could be > loaded into restricted memory regions and either cause a crash or > corruption of the fadump. Is this regions_claims memory allocator available on all PowerPC targets or only on newer POWER machines? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 4/4] gpt: Add compile time asserts for guid and gpt_partentry sizes
On Tue, 2023-10-31 at 20:35 +0100, Vladimir 'phcoder' Serbinenko wrote:
> With new alignment specification it's easy to screw up. Fortunately if it
> happens the size will be bigger than intended. Compile time assert will catch
> this.
>
> Signed-off-by: Vladimir Serbinenko
> ---
> grub-core/partmap/gpt.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/grub-core/partmap/gpt.c b/grub-core/partmap/gpt.c
> index 877ceefc3..426f616ae 100644
> --- a/grub-core/partmap/gpt.c
> +++ b/grub-core/partmap/gpt.c
> @@ -229,6 +229,9 @@ static struct grub_partition_map grub_gpt_partition_map =
>
> GRUB_MOD_INIT(part_gpt)
> {
> + COMPILE_TIME_ASSERT(sizeof(grub_guid_t) == 16);
> + COMPILE_TIME_ASSERT(sizeof(grub_packed_guid_t) == 16);
> + COMPILE_TIME_ASSERT(sizeof(struct grub_gpt_partentry) == 128);
>grub_partition_map_register (_gpt_partition_map);
> }
>
> --
> 2.39.2
>
Tested-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/4] types: Split aligned and packed guids
ice_path_t header;
> - grub_guid_t guid;
> + grub_packed_guid_t guid;
> } GRUB_PACKED;
> typedef struct grub_efi_piwg_device_path grub_efi_piwg_device_path_t;
>
> @@ -1287,7 +1287,7 @@ struct grub_efi_boot_services
>
>grub_efi_status_t
>(__grub_efi_api *protocols_per_handle) (grub_efi_handle_t handle,
> - grub_guid_t ***protocol_buffer,
> + grub_packed_guid_t ***protocol_buffer,
> grub_efi_uintn_t
> *protocol_buffer_count);
>
>grub_efi_status_t
> @@ -1386,7 +1386,7 @@ typedef struct grub_efi_runtime_services
> grub_efi_runtime_services_t;
>
> struct grub_efi_configuration_table
> {
> - grub_guid_t vendor_guid;
> + grub_packed_guid_t vendor_guid;
>void *vendor_table;
> } GRUB_PACKED;
> typedef struct grub_efi_configuration_table grub_efi_configuration_table_t;
> diff --git a/include/grub/efiemu/efiemu.h b/include/grub/efiemu/efiemu.h
> index caf0b505f..d6a868e94 100644
> --- a/include/grub/efiemu/efiemu.h
> +++ b/include/grub/efiemu/efiemu.h
> @@ -183,13 +183,13 @@ struct grub_efiemu_configuration_table
> };
> struct grub_efiemu_configuration_table32
> {
> - grub_guid_t vendor_guid;
> + grub_packed_guid_t vendor_guid;
>grub_efi_uint32_t vendor_table;
> } GRUB_PACKED;
> typedef struct grub_efiemu_configuration_table32
> grub_efiemu_configuration_table32_t;
> struct grub_efiemu_configuration_table64
> {
> - grub_guid_t vendor_guid;
> + grub_packed_guid_t vendor_guid;
>grub_efi_uint64_t vendor_table;
> } GRUB_PACKED;
> typedef struct grub_efiemu_configuration_table64
> grub_efiemu_configuration_table64_t;
> diff --git a/include/grub/efiemu/runtime.h b/include/grub/efiemu/runtime.h
> index c9ad9fdfa..2ff429845 100644
> --- a/include/grub/efiemu/runtime.h
> +++ b/include/grub/efiemu/runtime.h
> @@ -29,7 +29,7 @@ struct grub_efiemu_ptv_rel
>
> struct efi_variable
> {
> - grub_guid_t guid;
> + grub_packed_guid_t guid;
>grub_uint32_t namelen;
>grub_uint32_t size;
>grub_efi_uint32_t attributes;
> diff --git a/include/grub/types.h b/include/grub/types.h
> index 45536a661..064066e2e 100644
> --- a/include/grub/types.h
> +++ b/include/grub/types.h
> @@ -376,7 +376,16 @@ struct grub_guid
>grub_uint16_t data2;
>grub_uint16_t data3;
>grub_uint8_t data4[8];
> -} GRUB_PACKED;
> +} __attribute__ ((aligned(4)));
> typedef struct grub_guid grub_guid_t;
>
> +struct grub_packed_guid
> +{
> + grub_uint32_t data1;
> + grub_uint16_t data2;
> + grub_uint16_t data3;
> + grub_uint8_t data4[8];
> +} GRUB_PACKED;
> +typedef struct grub_packed_guid grub_packed_guid_t;
> +
> #endif /* ! GRUB_TYPES_HEADER */
> --
> 2.39.2
>
Tested-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/4] gpt_partition: Mark grub_gpt_partentry as having natural alignment
On Tue, 2023-10-31 at 20:23 +0100, Vladimir 'phcoder' Serbinenko wrote: > gpt_partition contains grub_guid. We need to decide whether the whole > structure is unaligned and then we need to use packed_guid. But we never > have unaligned part entries as we read them in an aligned buffer from disk. > Hence just make it all aligned. > > Signed-off-by: Vladimir Serbinenko > --- > include/grub/gpt_partition.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/grub/gpt_partition.h b/include/grub/gpt_partition.h > index 020e71920..292ea03f1 100644 > --- a/include/grub/gpt_partition.h > +++ b/include/grub/gpt_partition.h > @@ -67,7 +67,7 @@ struct grub_gpt_partentry >grub_uint64_t end; >grub_uint64_t attrib; >char name[72]; > -} GRUB_PACKED; > +}; > > grub_err_t > grub_gpt_partition_map_iterate (grub_disk_t disk, > -- > 2.39.2 > Tested-by: John Paul Adrian Glaubitz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/4] efi: Deduplicate configuration table search function
- grub_guid_t *guid =
> - _efi_system_table->configuration_table[i].vendor_guid;
> -
> - if (! grub_memcmp (guid, _guid, sizeof (grub_guid_t)))
> - return (struct grub_smbios_eps *)
> - grub_efi_system_table->configuration_table[i].vendor_table;
> -}
> -
> - return 0;
> + return (struct grub_smbios_eps *) grub_efi_find_configuration_table
> (_guid);
> }
>
> struct grub_smbios_eps3 *
> grub_machine_smbios_get_eps3 (void)
> {
> - unsigned i;
>static grub_guid_t smbios3_guid = GRUB_EFI_SMBIOS3_TABLE_GUID;
>
> - for (i = 0; i < grub_efi_system_table->num_table_entries; i++)
> -{
> - grub_guid_t *guid =
> - _efi_system_table->configuration_table[i].vendor_guid;
> -
> - if (! grub_memcmp (guid, _guid, sizeof (grub_guid_t)))
> - return (struct grub_smbios_eps3 *)
> - grub_efi_system_table->configuration_table[i].vendor_table;
> -}
> -
> - return 0;
> + return (struct grub_smbios_eps3 *) grub_efi_find_configuration_table
> (_guid);
> }
> diff --git a/grub-core/kern/efi/acpi.c b/grub-core/kern/efi/acpi.c
> index 461c77c33..828e6dbb2 100644
> --- a/grub-core/kern/efi/acpi.c
> +++ b/grub-core/kern/efi/acpi.c
> @@ -18,42 +18,20 @@
> */
>
> #include
> -#include
> #include
> -#include
>
> struct grub_acpi_rsdp_v10 *
> grub_machine_acpi_get_rsdpv1 (void)
> {
> - unsigned i;
>static grub_guid_t acpi_guid = GRUB_EFI_ACPI_TABLE_GUID;
>
> - for (i = 0; i < grub_efi_system_table->num_table_entries; i++)
> -{
> - grub_guid_t *guid =
> - _efi_system_table->configuration_table[i].vendor_guid;
> -
> - if (! grub_memcmp (guid, _guid, sizeof (grub_guid_t)))
> - return (struct grub_acpi_rsdp_v10 *)
> - grub_efi_system_table->configuration_table[i].vendor_table;
> -}
> - return 0;
> + return (struct grub_acpi_rsdp_v10 *) grub_efi_find_configuration_table
> (_guid);
> }
>
> struct grub_acpi_rsdp_v20 *
> grub_machine_acpi_get_rsdpv2 (void)
> {
> - unsigned i;
>static grub_guid_t acpi20_guid = GRUB_EFI_ACPI_20_TABLE_GUID;
>
> - for (i = 0; i < grub_efi_system_table->num_table_entries; i++)
> -{
> - grub_guid_t *guid =
> - _efi_system_table->configuration_table[i].vendor_guid;
> -
> - if (! grub_memcmp (guid, _guid, sizeof (grub_guid_t)))
> - return (struct grub_acpi_rsdp_v20 *)
> - grub_efi_system_table->configuration_table[i].vendor_table;
> -}
> - return 0;
> + return (struct grub_acpi_rsdp_v20 *) grub_efi_find_configuration_table
> (_guid);
> }
> diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
> index a2afd8de9..e53808307 100644
> --- a/grub-core/kern/efi/efi.c
> +++ b/grub-core/kern/efi/efi.c
> @@ -1031,3 +1031,21 @@ grub_efi_compare_device_paths (const
> grub_efi_device_path_t *dp1,
>
>return 0;
> }
> +
> +void *
> +grub_efi_find_configuration_table (const grub_guid_t *target_guid)
> +{
> + unsigned i;
> +
> + for (i = 0; i < grub_efi_system_table->num_table_entries; i++)
> +{
> + grub_guid_t *guid =
> + _efi_system_table->configuration_table[i].vendor_guid;
> +
> + if (! grub_memcmp (guid, target_guid, sizeof (grub_guid_t)))
> + return (void *)
> + grub_efi_system_table->configuration_table[i].vendor_table;
> +}
> +
> + return 0;
> +}
> diff --git a/grub-core/kern/efi/fdt.c b/grub-core/kern/efi/fdt.c
> index 8fcf43f1b..15a495a34 100644
> --- a/grub-core/kern/efi/fdt.c
> +++ b/grub-core/kern/efi/fdt.c
> @@ -23,21 +23,13 @@
> void *
> grub_efi_get_firmware_fdt (void)
> {
> - grub_efi_configuration_table_t *tables;
>static grub_guid_t fdt_guid = GRUB_EFI_DEVICE_TREE_GUID;
> - void *firmware_fdt = NULL;
> - unsigned int i;
> -
> - /* Look for FDT in UEFI config tables. */
> - tables = grub_efi_system_table->configuration_table;
> -
> - for (i = 0; i < grub_efi_system_table->num_table_entries; i++)
> -if (grub_memcmp ([i].vendor_guid, _guid, sizeof (fdt_guid))
> == 0)
> - {
> - firmware_fdt = tables[i].vendor_table;
> - grub_dprintf ("linux", "found registered FDT @ %p\n", firmware_fdt);
> - break;
> - }
> + void *firmware_fdt = grub_efi_find_configuration_table (_guid);
>
> + if (firmware_fdt) {
> +grub_dprintf ("linux", "found registered FDT @ %p\n", firmware_fdt);
> + } else {
> +grub_dprintf ("linux", "not found registered FDT\n");
> + }
>return firmware_fdt;
> }
> diff --git a/include/grub/efi/efi.h b/include/grub/efi/efi.h
> index 572f7135f..a5cd99e5a 100644
> --- a/include/grub/efi/efi.h
> +++ b/include/grub/efi/efi.h
> @@ -119,6 +119,9 @@ extern void (*EXPORT_VAR(grub_efi_net_config))
> (grub_efi_handle_t hnd,
> char **device,
> char **path);
>
> +void *
> +EXPORT_FUNC (grub_efi_find_configuration_table) (const grub_guid_t
> *target_guid);
> +
> #if defined(__arm__) || defined(__aarch64__) || defined(__riscv) ||
> defined(__loongarch__)
> void *EXPORT_FUNC(grub_efi_get_firmware_fdt)(void);
> grub_err_t EXPORT_FUNC(grub_efi_get_ram_base)(grub_addr_t *);
> --
> 2.39.2
Tested-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/4] Fix GUID alignment on ia64
Hello Vladimir! On Tue, 2023-10-31 at 20:37 +0100, Vladimir 'phcoder' Serbinenko wrote: > Fix GUID alignment problems encountered on ia64. Tested on zx2000 workstation I can confirm that this series applied on top of git master (3f79e3b15) unbreaks GRUB on my HP Integrity rx2660 and I can boot Linux normally again. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
Hi Vladimir! On Mon, 2023-08-14 at 13:56 +0200, Vladimir 'phcoder' Serbinenko wrote: > I uploaded the entire branch (patches) to my GitHub copy: > https://github.com/phcoder/GRUB/tree/rb1 Any chance this could be reworked and merged before the 2.12 release? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
Hi Oliver! On Wed, 2023-09-13 at 12:14 +0200, Oliver Steffen wrote: > On Wed, Sep 13, 2023 at 6:10 AM Pedro Miguel Justo wrote: > > > > > > I can confirm that, taking [1][2] and making [3] on top of it, my > > Montvale-based rx2660 machine still boots fine. > > Wonderful! Thanks for testing! Are you going to submit a patch to fix the issue with the new information? Would be great if the bug could be fixed before the 2.12 release. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
Hi Pedro! On Fri, 2023-09-08 at 03:24 +, Pedro Miguel Justo wrote: > > > On Sep 7, 2023, at 13:02, Daniel Kiper wrote: > > > > Pedro, Adrian, ping? > > Just to be overzealous and incredibly dense, here is my full understanding of > what is being asked to test: > > 1) Take the payload that was tested before in [1][2] > 2) Replace the 2 `__attribute__ ((aligned(8)))` that were added commits [3] > and [4] with `__attribute__ ((aligned(4)))` > 3) See if it still works > > Correct? I would very much appreciate if you could test this particular change so that I don't have to hook up my RX2600 which is currently stored under my sofa ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
On Thu, 2023-09-07 at 22:02 +0200, Daniel Kiper wrote: > On Wed, Aug 30, 2023 at 10:53:47PM +, Pedro Miguel Justo wrote: > > > On Aug 30, 2023, at 09:20, John Paul Adrian Glaubitz > > > wrote: > > > On Wed, 2023-08-30 at 16:16 +0200, Daniel Kiper wrote: > > > > On Fri, Aug 25, 2023 at 05:50:58AM -0700, Oliver Steffen wrote: > > > > > > > > Yes, that would be perfect. If Itanium works then I suggest to align > > > > GUIDs to 4 bytes. This alignment is used in the kernel for more than > > > > 4 years and it looks nobody complains... > > > > > > > > Pedro, Adrian, could you change GUIDs alignment in Vladimir's patches to > > > > 4 and test them on Itanium? > > > > > > If I find the time tomorrow, I will test that change. > > > > > > Adrian > > > > If Adrian can’t make it this week. I most certainly can next week. > > Pedro, Adrian, ping? I should have some time tomorrow to perform the tests. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
On Wed, 2023-08-30 at 16:16 +0200, Daniel Kiper wrote: > On Fri, Aug 25, 2023 at 05:50:58AM -0700, Oliver Steffen wrote: > > Quoting Vladimir 'phcoder' Serbinenko (2023-08-15 18:14:11) > > [...] > > > I am not sure what the best way forward is now, but we at least have the > > patches from Vladimir (thanks!). > > > > Pedro, Adrian, could you - if you get a chance - try them with a 4 byte > > alignment too? > > Yes, that would be perfect. If Itanium works then I suggest to align > GUIDs to 4 bytes. This alignment is used in the kernel for more than > 4 years and it looks nobody complains... > > Pedro, Adrian, could you change GUIDs alignment in Vladimir's patches to > 4 and test them on Itanium? If I find the time tomorrow, I will test that change. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
Hi Pedro! On Mon, 2023-08-14 at 14:33 +, Pedro Miguel Justo wrote: > en I try to build from your branch, I eventually get this error: > > ``` > done > mv syminfo.lst.new syminfo.lst > cat syminfo.lst | sort | mawk -f ./genmoddep.awk > moddep.lst || (rm -f > moddep.lst; exit 1) > mawk: ./genmoddep.awk: line 106: function asorti never defined > make[3]: *** [Makefile:51272: moddep.lst] Error 1 > make[3]: Leaving directory '/home/pmsjt/grub_github/grub-core' > make[2]: *** [Makefile:28852: all] Error 2 > make[2]: Leaving directory '/home/pmsjt/grub_github/grub-core' > make[1]: *** [Makefile:12126: all-recursive] Error 1 > make[1]: Leaving directory '/home/pmsjt/grub_github' > make: *** [Makefile:3953: all] Error 2 > ``` > > Is this something you know about? This is a known generic problem with GRUB. You must install gawk instead of mawk. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
Hi Daniel! On Fri, 2023-08-11 at 17:31 +0200, Daniel Kiper wrote: > On Fri, Aug 11, 2023 at 04:10:14AM -0700, Oliver Steffen wrote: > > Quoting John Paul Adrian Glaubitz (2023-08-11 10:32:17) > > > Hi Oliver! > > > > > > On Fri, 2023-05-26 at 13:35 +0200, Oliver Steffen wrote: > > > > There are 3 implementations of a GUID in Grub. Replace them with a > > > > common one, placed in types.h. > > > > > > > > It uses the "packed" flavor of the GUID structs, the alignment attribute > > > > is dropped, since it is not required. > > > > > > > > Signed-off-by: Oliver Steffen > > > > Reviewed-by: Daniel Kiper > > [...] > > > > According to [1], this change broke GRUB on ia64: > > > > > > Welcome to GRUB! > > > > > > 7 0 0x6B 0x001E unexpected trap > > > 7 0 0x66 0x001E trap taken, number in ext PE > > > 7 0 0x3C 0x5A00 trap taken, offset in ext PE > > > > > > I assume this is because of the strict alignment requirements on ia64. > > > > > > Could you have a look? > > > > I am very sorry for this mistake. > > My goal was to unify the two GUID types we had in grub but I missed the > > fact that in my "solution" the alignments are not correct in all cases. > > > > The quickest way out could be to revert the GUID unification and printf > > format specifier commits: > > > > 6ad116e5f guid: Make use of GUID printf format specifier > > f82dbf2bd kern/misc: Add a format specifier GUIDs > > 06edd40db guid: Unify GUID types > > > > And use the explicit, long-winded format string for printing the GUID > > in the bli module instead (added in the commits following those). > > > > I am open to suggestions / comments. > > Adrian, could you check what will happen when you add alignment to the > grub_guid_t as it was suggested by Frank here [2]? > > Personally I would avoid adding another GUID type with just alignment > requirement as the difference. Making one GUID type with always enforced > alignment should not cost us a lot. Or we can enforce alignment on EFI > platforms only. My Itanium hardware is not available for bootloader tests at the moment, so I would like to ask Pedro Miguel Justo or Frank Scheiner to test the proposed fix. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v9 02/11] Unify GUID types
; +grub_guid_t *protocol,
> grub_efi_uint32_t attributes);
> grub_efi_status_t
> -EXPORT_FUNC(grub_efi_close_protocol) (grub_efi_handle_t handle,
> grub_efi_guid_t *protocol);
> +EXPORT_FUNC(grub_efi_close_protocol) (grub_efi_handle_t handle, grub_guid_t
> *protocol);
> int EXPORT_FUNC(grub_efi_set_text_mode) (int on);
> void EXPORT_FUNC(grub_efi_stall) (grub_efi_uintn_t microseconds);
> void *
> @@ -89,23 +89,23 @@ grub_err_t EXPORT_FUNC (grub_efi_set_virtual_address_map)
> (grub_efi_uintn_t memo
> grub_efi_uint32_t
> descriptor_version,
>
> grub_efi_memory_descriptor_t *virtual_map);
> grub_efi_status_t EXPORT_FUNC (grub_efi_get_variable_with_attributes) (const
> char *variable,
> -const
> grub_efi_guid_t *guid,
> +const
> grub_guid_t *guid,
>
> grub_size_t *datasize_out,
> void
> **data_out,
>
> grub_efi_uint32_t *attributes);
> grub_efi_status_t EXPORT_FUNC (grub_efi_get_variable) (const char *variable,
> -const grub_efi_guid_t
> *guid,
> +const grub_guid_t *guid,
> grub_size_t
> *datasize_out,
> void **data_out);
> grub_err_t
> EXPORT_FUNC (grub_efi_set_variable_with_attributes) (const char *var,
> - const grub_efi_guid_t *guid,
> + const grub_guid_t *guid,
>void *data,
>grub_size_t datasize,
>grub_efi_uint32_t attributes);
> grub_err_t
> EXPORT_FUNC (grub_efi_set_variable) (const char *var,
> - const grub_efi_guid_t *guid,
> + const grub_guid_t *guid,
>void *data,
>grub_size_t datasize);
> int
> diff --git a/include/grub/efiemu/efiemu.h b/include/grub/efiemu/efiemu.h
> index 5325e5839..caf0b505f 100644
> --- a/include/grub/efiemu/efiemu.h
> +++ b/include/grub/efiemu/efiemu.h
> @@ -176,26 +176,26 @@ grub_err_t grub_efiemu_loadcore_load (void);
> struct grub_efiemu_configuration_table
> {
>struct grub_efiemu_configuration_table *next;
> - grub_efi_guid_t guid;
> + grub_guid_t guid;
>void * (*get_table) (void *data);
>void (*unload) (void *data);
>void *data;
> };
> struct grub_efiemu_configuration_table32
> {
> - grub_efi_packed_guid_t vendor_guid;
> + grub_guid_t vendor_guid;
>grub_efi_uint32_t vendor_table;
> } GRUB_PACKED;
> typedef struct grub_efiemu_configuration_table32
> grub_efiemu_configuration_table32_t;
> struct grub_efiemu_configuration_table64
> {
> - grub_efi_packed_guid_t vendor_guid;
> + grub_guid_t vendor_guid;
>grub_efi_uint64_t vendor_table;
> } GRUB_PACKED;
> typedef struct grub_efiemu_configuration_table64
> grub_efiemu_configuration_table64_t;
> -grub_err_t grub_efiemu_unregister_configuration_table (grub_efi_guid_t guid);
> +grub_err_t grub_efiemu_unregister_configuration_table (grub_guid_t guid);
> grub_err_t
> -grub_efiemu_register_configuration_table (grub_efi_guid_t guid,
> +grub_efiemu_register_configuration_table (grub_guid_t guid,
> void * (*get_table) (void *data)
Re: GRUB unexpected trap in Itanium
Hello Pedro! On Fri, 2023-08-11 at 00:11 +, Pedro Miguel Justo wrote: > It seems as a recent change has caused a regression on Itanium (ia64), > rendering the platform unbootable. GRUB will crash very early with: > > > ``` > Welcome to GRUB! > > 7 0 0x6B 0x001E unexpected trap > 7 0 0x66 0x001E trap taken, number in ext PE > 7 0 0x3C 0x5A00 trap taken, offset in ext PE > ``` > > I have bisected the issue and it resulted into the following change: > > ``` > 06edd40db76bb78457ac26156ed5f7b62381bbe8 is the first bad commit > commit 06edd40db76bb78457ac26156ed5f7b62381bbe8 > Author: Oliver Steffen > Date: Fri May 26 13:35:43 2023 +0200 > > guid: Unify GUID types > > There are 3 implementations of a GUID in GRUB. Replace them with > a common one, placed in types.h. > > It uses the "packed" flavor of the GUID structs, the alignment attribute > is dropped, since it is not required. > > Signed-off-by: Oliver Steffen > Reviewed-by: Daniel Kiper > ``` Thanks for bisecting this. Please always make sure to CC the original author of the patch so he becomes aware of the breakage that was introduced by his patch. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub FTBFS on ia64: awk: ./genmoddep.awk: line 106: function asorti never defined
Hi! On Sat, 2023-07-22 at 12:25 +0200, John Paul Adrian Glaubitz wrote: > On Sat, 2023-07-22 at 12:16 +0200, John Paul Adrian Glaubitz wrote: > > Hi! > > > > The current build of grub fails on ia64 with: > > (...) > > Any idea? > > OK, seems like this was just related to mawk vs. gawk. Builds fine with gawk. While GRUB builds fine on ia64, the bootloader itself does not work: HP Smart Array P400 Controller (version 7.24) 1 Logical Drive 1794-Drive Array - Array Accelerator Battery Charge Low Array Accelerator Posted-Write Cache is temporarily disabled. Array Accelerator batteries have failed to charge and should be replaced Loading.: grub Starting: grub 7 0 0x6B 0x001E unexpected trap 7 0 0x66 0x001E trap taken, number in ext PE 7 0 0x3C 0x5A00 trap taken, offset in ext PE Stops right there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub FTBFS on ia64: awk: ./genmoddep.awk: line 106: function asorti never defined
Hi! On Sat, 2023-07-22 at 12:16 +0200, John Paul Adrian Glaubitz wrote: > Hi! > > The current build of grub fails on ia64 with: > (...) > Any idea? OK, seems like this was just related to mawk vs. gawk. Builds fine with gawk. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub FTBFS on ia64: awk: ./genmoddep.awk: line 106: function asorti never defined
karg.module xzio.module lzopio.module testload.module priority_queue.module time.module adler32.module crc64.module mpi.module all_video.module testspeed.module tpm.module tr.module progress.module file.module bli.module gcry_arcfour.module gcry_blowfish.module gcry_camellia.module gcry_cast5.module gcry_crc.module gcry_des.module gcry_dsa.module gcry_idea.module gcry_md4.module gcry_md5.module gcry_rfc2268.module gcry_rijndael.module gcry_rmd160.module gcry_rsa.module gcry_seed.module gcry_serpent.module gcry_sha1.module gcry_sha256.module gcry_sha512.module gcry_tiger.module gcry_twofish.module gcry_whirlpool.module; do \ sh gensyminfo.sh $m >> syminfo.lst.new || exit 1; \ done mv syminfo.lst.new syminfo.lst cat syminfo.lst | sort | mawk -f ./genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1) mawk: ./genmoddep.awk: line 106: function asorti never defined make[3]: *** [Makefile:51272: moddep.lst] Error 1 make[3]: Leaving directory '/root/grub/grub-core' make[2]: *** [Makefile:28852: all] Error 2 make[2]: Leaving directory '/root/grub/grub-core' make[1]: *** [Makefile:12126: all-recursive] Error 1 make[1]: Leaving directory '/root/grub' make: *** [Makefile:3953: all] Error 2 root@electron:~/grub# make make all-recursive make[1]: Entering directory '/root/grub' Making all in grub-core/lib/gnulib make[2]: Entering directory '/root/grub/grub-core/lib/gnulib' make all-recursive make[3]: Entering directory '/root/grub/grub-core/lib/gnulib' make[4]: Entering directory '/root/grub/grub-core/lib/gnulib' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/root/grub/grub-core/lib/gnulib' make[3]: Leaving directory '/root/grub/grub-core/lib/gnulib' make[2]: Leaving directory '/root/grub/grub-core/lib/gnulib' Making all in . make[2]: Entering directory '/root/grub' make[2]: Leaving directory '/root/grub' Making all in grub-core make[2]: Entering directory '/root/grub/grub-core' make all-am make[3]: Entering directory '/root/grub/grub-core' cat syminfo.lst | sort | mawk -f ./genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1) mawk: ./genmoddep.awk: line 106: function asorti never defined make[3]: *** [Makefile:51272: moddep.lst] Error 1 make[3]: Leaving directory '/root/grub/grub-core' make[2]: *** [Makefile:28852: all] Error 2 make[2]: Leaving directory '/root/grub/grub-core' make[1]: *** [Makefile:12126: all-recursive] Error 1 make[1]: Leaving directory '/root/grub' make: *** [Makefile:3953: all] Error 2 root@electron:~/grub# Any idea? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
grub-macbless does not create a bootable system
Hello! I have been toying around with grub-macbless in order to switch the GRUB partition for PowerMacs running Debian from HFS to HFS+. Currently, I we're stuck to HFS because the available »hattrib« tool for blessing a bootloader for NewWorld Macs supports HFS only. »hatttrib« is part of the hfsutils package [1]. In order to boot GRUB on an Apple PowerMac, it's first necessary to create an HFS filesystem, then run »grub-install« and then bless the bootloader directory [2]: # mkfs.hfs /dev/sda2 # mkdir /boot/grub # mount -thfs /dev/sda2 /boot/grub # grub-install --macppc-directory=/boot/grub # umount /dev/sda2 # hmount /dev/sda2 # hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX # hattrib -b :System:Library:CoreServices # humount Supposedly, »grub-macbless« should be able to bless a boot directory as well, but the following command will not create a bootable system: # grub-macbless --ppc /boot/grub/System/Library/CoreServices However, an HFS boot partition treated like this with »grub-macbless« does not create a bootable system, even when running the »hattrib« command to set the »tbxi« attribute on the »BootX« flag. So, it's currently not possible to create a bootable GRUB partition on Apple PowerMac using just »grub-macbless«. Also, in order to be able to replace »hattrib« from »hfsutils«, »grub-macbless« should support both blessing a system directory as well as setting the »tbxi« attribute on the stage1 bootloader »BootX«. Adrian > [1] https://www.mars.org/home/rob/proj/hfs/ > [2] > https://salsa.debian.org/installer-team/grub-installer/-/blob/a8b85210dfa37b894714e269ae323c2af2f23858/grub-installer#L1030 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fix for grub-switch-to-blscfg
Hello Konstantin! On Wed, 2023-05-24 at 23:54 +0300, Konstantin Vlasov via Grub-devel wrote: > We've discovered that there are some inconsistencies in the > grub-switch-to-blscfg tool, that lead to generating invalid BLS configs, when > /boot is not a separate partition. > > The attached patch fixes it. Please send patches in-line using the git-send-email feature. Also, I would suggest splitting up the patch into two as they fix two logically independent issues. »Fixed grub-switch-to-blscfg« is also not a very good title for a commit message. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB support for Loongson MIPS64 boards
Hello! Now that Loongson support has been merged upstream in GRUB, I was wondering whether there is a chance that the patches to support the Loongson MIPS64 hardware could be upstreamed as well? Loongson has a repository with the patches on Github [1], a rebased version from 2021 can be found here [2]. Currently, all users of Loongson MIPS64 hardware will have to use a patched version of GRUB to be able to boot their boards. Thanks, Adrian > [1] https://github.com/loongson-community/grub > [2] https://github.com/AOSC-Dev/grub-loongson3 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
Hello Ard! On Thu, 2023-05-11 at 16:29 +0200, Ard Biesheuvel wrote: > > > Feel free to keep using it, but please stop demanding that our people > > > keep wasting their time on it. If you want to support it in Debian, > > > you can carry it as a downstream patch and shoulder the maintenance > > > burden. > > > > Who is "our people"? Do you think that you are part of the community and > > I am not? I don't think this kind of hostility is justified. Neither you > > nor I own this project. > > > > Apologies - I had meant to type 'other people' not 'our people'. I > rarely contribute to GRUB myself, so I wouldn't consider myself more a > part of this community than anyone else. > > But my point remains: I have inferred from your response (and your > involvement in similar discussions around the Linux kernel) that you > would prefer Itanium support to be retained, right? Not necessarily. I am generally not opposed to removing ia64 support, but it should happen in a coordinated form where downstreams and users are involved. Just dropping support from random projects without prior coordination seems like the wrong approach to me. I would suggest posting your plans to the distributions mailing list [1], Debian's ia64 mailing list [2], the Gentoo developer mailing list [3], the Linux ia64 mailing list [4] and maybe the NetBSD ia64 mailing list [5]. If you don't get any objections there, I am not going to object either. I just want this to happen in an ordered manner. > So could you explain who you think should carry the maintenance > burden? IA64 will be the only EFI architecture in GRUB that does not > boot via an EFI stub in Linux, and this deviation means that retaining > support for it is going to take actual developer and maintainer > bandwidth. GRUB gets very little of that as it is, which means that > keeping IA64 support alive comes at the cost of worse support for > other architectures and platforms. (The series that this patch is part > of breaks the ia64 build, and i i struggle to see why i should care > about that) > > Very few of those people have access to such systems to begin with > (probably none), and the companies that manufactured them stopped > supporting them in the open source years ago, so testing these changes > is not straight-forward, making it unreasonable to demand this from > contributors. Also, it is unclear to me why the needs of the few > people that do still run such a system are not served by a build based > on today's GRUB tree, and why ia64 support needs to be retained going > forward. Well, that's why I am suggesting to coordinate this properly and ask potential users of the code whether they are okay with the removal. Thanks, Adrian > [1] https://lists.freedesktop.org/mailman/listinfo/distributions > [2] https://lists.debian.org/debian-ia64/ > [3] https://archives.gentoo.org/gentoo-dev/ > [4] https://marc.info/?l=linux-ia64=1=1 > [5] https://mail-index.netbsd.org/port-ia64/tindex.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote: > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz > wrote: > > > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > > > boot that deviates from other architectures. Given that IA64 is unused > > > and unmaintained, it makes no sense to pretend that the EFI changes we > > > are making are tested or supported on IA64, so let's just get rid of it. > > > > But I just recently tested GRUB from git on IA64 and it worked without > > any problems. We're using GRUB to boot Debian on IA64. > > > > IA-64 is a dead platform, and a waste of electricity. I was just making a statement regarding the testability of the code. That's all. > Feel free to keep using it, but please stop demanding that our people > keep wasting their time on it. If you want to support it in Debian, > you can carry it as a downstream patch and shoulder the maintenance > burden. Who is "our people"? Do you think that you are part of the community and I am not? I don't think this kind of hostility is justified. Neither you nor I own this project. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/6] ia64: Remove support
On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote: > Itanium IA-64 support is obsolete, and implements its own flavor of EFI > boot that deviates from other architectures. Given that IA64 is unused > and unmaintained, it makes no sense to pretend that the EFI changes we > are making are tested or supported on IA64, so let's just get rid of it. But I just recently tested GRUB from git on IA64 and it worked without any problems. We're using GRUB to boot Debian on IA64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Compile and testsuite runs for various Debian targets
Hi Glenn! I have test-built GRUB from git at f7564844f on all Debian targets which support GRUB. Builds worked fine on all targets except for hurd-i386 for which I will send a separate mail. For the Linux-based targets, I have uploaded the testsuite results to [1]. Adrian > [1] https://people.debian.org/~glaubitz/grub-tests-20230221/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2] osdep/hurd/getroot: Remove unused variables in grub_util_find_hurd_root_device()
Found during a test build on Debian/hurd-i386 with --disable-werror enabled:
In file included from grub-core/osdep/getroot.c:12:
grub-core/osdep/hurd/getroot.c: In function ‘grub_util_find_hurd_root_device’:
grub-core/osdep/hurd/getroot.c:126:13: error: unused variable ‘next’
[-Werror=unused-variable]
126 | char *next;
| ^~~~
grub-core/osdep/hurd/getroot.c:125:14: error: unused variable ‘size’
[-Werror=unused-variable]
125 | size_t size;
| ^~~~
Fixes: e981b0a24 (osdep/hurd/getroot: Use "part:" qualifier)
Signed-off-by: John Paul Adrian Glaubitz
---
v2:
- Add missing Fixes tag
---
grub-core/osdep/hurd/getroot.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/grub-core/osdep/hurd/getroot.c b/grub-core/osdep/hurd/getroot.c
index af31f2c47..0efefdab4 100644
--- a/grub-core/osdep/hurd/getroot.c
+++ b/grub-core/osdep/hurd/getroot.c
@@ -122,8 +122,6 @@ grub_util_find_hurd_root_device (const char *path)
if (strncmp (name, "device:", sizeof ("device:") - 1) == 0)
{
char *dev_name = name + sizeof ("device:") - 1;
- size_t size;
- char *next;
if (dev_name[0] == '@')
{
--
2.39.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] osdep/hurd/getroot: Remove unused variables in grub_util_find_hurd_root_device()
Found during a test build on Debian/hurd-i386 with --disable-werror enabled:
In file included from grub-core/osdep/getroot.c:12:
grub-core/osdep/hurd/getroot.c: In function ‘grub_util_find_hurd_root_device’:
grub-core/osdep/hurd/getroot.c:126:13: error: unused variable ‘next’
[-Werror=unused-variable]
126 | char *next;
| ^~~~
grub-core/osdep/hurd/getroot.c:125:14: error: unused variable ‘size’
[-Werror=unused-variable]
125 | size_t size;
| ^~~~
Signed-off-by: John Paul Adrian Glaubitz
---
grub-core/osdep/hurd/getroot.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/grub-core/osdep/hurd/getroot.c b/grub-core/osdep/hurd/getroot.c
index af31f2c47..0efefdab4 100644
--- a/grub-core/osdep/hurd/getroot.c
+++ b/grub-core/osdep/hurd/getroot.c
@@ -122,8 +122,6 @@ grub_util_find_hurd_root_device (const char *path)
if (strncmp (name, "device:", sizeof ("device:") - 1) == 0)
{
char *dev_name = name + sizeof ("device:") - 1;
- size_t size;
- char *next;
if (dev_name[0] == '@')
{
--
2.39.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Running bootstrap script fails on Debian unstable
Hi Glenn! On Tue, 2023-02-21 at 10:58 +0100, John Paul Adrian Glaubitz wrote: > > Do you have installed all the packages that are installed in that build > > log? Are you applying all the patches or just building from 2.06 git? > > Building from git, no patches applied. Will try openSUSE Tumbelweed later > today. Installing the pkg-config package fixes the problem. Will be testing now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Running bootstrap script fails on Debian unstable
Hi Glenn! On Mon, 2023-02-20 at 21:29 -0600, Glenn Washburn wrote: > It looks like the debian build log[1] for sid has the same messages, up > to here. The package goes on to build successfully. Yes, but the Debian build does not seem to run the bootstrap script which is probably why the problem doesn't show there. > > configure.ac:423: error: possibly undefined macro: AC_CHECK_HEADERS > > If this token and others are legitimate, please use > > m4_pattern_allow. See the Autoconf documentation. > > configure.ac:514: error: possibly undefined macro: AC_LINK_IFELSE > > configure.ac:1608: error: possibly undefined macro: AC_LANG_CALL > > autoreconf: error: /usr/bin/autoconf failed with exit status: 1 > > ./bootstrap: autoreconf failed > > Do you have installed all the packages that are installed in that build > log? Are you applying all the patches or just building from 2.06 git? Building from git, no patches applied. Will try openSUSE Tumbelweed later today. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Running bootstrap script fails on Debian unstable
Hi Glenn! On Mon, 2023-02-20 at 11:34 -0600, Glenn Washburn wrote: > Does the 2.06 release build with the new autoconf? It looks like sid is > using 2.06, I don't see any special patches for configure.ac, and I > presume that the sid grub binary is built with the new autoconf. If > this all is true, then I'd guess some of the recent configure.ac > changes may have something to do with it. Very good point. I checked out grub-2.06 to verify that theory, but it actually shows the same problem: autoreconf: export WARNINGS= autoreconf: Entering directory '.' autoreconf: running: true --force autoreconf: running: aclocal -I m4 --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: configure.ac: not using Intltool autoreconf: configure.ac: not using Gtkdoc autoreconf: running: /usr/bin/autoconf --include=m4 --force configure.ac:54: warning: The macro `AC_CONFIG_HEADER' is obsolete. configure.ac:54: You should run autoupdate. ./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from... configure.ac:54: the top level configure.ac:336: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete ./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from... ./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from... configure.ac:336: the top level configure.ac:361: warning: The macro `AC_GNU_SOURCE' is obsolete. configure.ac:361: You should run autoupdate. ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from... m4/gnulib-comp.m4:34: gl_EARLY is expanded from... configure.ac:361: the top level configure.ac:361: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from... m4/gnulib-comp.m4:34: gl_EARLY is expanded from... configure.ac:361: the top level configure.ac:361: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:361: You should run autoupdate. ./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from... m4/threadlib.m4:38: gl_THREADLIB_EARLY_BODY is expanded from... m4/threadlib.m4:31: gl_THREADLIB_EARLY is expanded from... m4/gnulib-comp.m4:34: gl_EARLY is expanded from... configure.ac:361: the top level configure.ac:372: warning: The macro `AC_GNU_SOURCE' is obsolete. configure.ac:372: You should run autoupdate. ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from... configure.ac:372: the top level configure.ac:423: error: possibly undefined macro: AC_CHECK_HEADERS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:514: error: possibly undefined macro: AC_LINK_IFELSE configure.ac:1608: error: possibly undefined macro: AC_LANG_CALL autoreconf: error: /usr/bin/autoconf failed with exit status: 1 ./bootstrap: autoreconf failed Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Running bootstrap script fails on Debian unstable
Hi Mihai! On Mon, 2023-02-20 at 15:01 +0100, Mihai Moldovan wrote: > * On 2/20/23 10:28, John Paul Adrian Glaubitz wrote: > > I wanted to start the current GRUB master branch on various architectures > > and it > > turns out that the bootstrap script currently fails on Debian unstable due > > to > > the autoconf syntax changes: > > > > running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install > > --force -I m4 --no-recursive > > [...] > > autoreconf: running: /usr/bin/autoconf --include=m4 --force > > configure.ac:429: error: possibly undefined macro: AC_CHECK_HEADERS > > If this token and others are legitimate, please use m4_pattern_allow. > > See the Autoconf documentation. > > configure.ac:520: error: possibly undefined macro: AC_LINK_IFELSE > > configure.ac:1631: error: possibly undefined macro: AC_LANG_CALL > > autoreconf: error: /usr/bin/autoconf failed with exit status: 1 > > ./bootstrap: autoreconf failed > > > > Does anyone know how to address this issue? > > Nothing that would immediately stick out. How is this invoked? Are you using > sbuild to build the package in an automatic fashion, maybe even via buildd? No. I am using a clean Debian unstable environment created with schroot with the necessary build dependencies installed to perform a manual build. > Can you reproduce it locally (but still in a clean chroot, like via passing > --anything-failed-commands='%SBUILD_SHELL' to the sbuild call and having an > interactive shell) to easily debug this? I'm performing a manual, local build. > AC_CHECK_HEADERS should be defined in /usr/share/autoconf/autoconf/headers.m4 > (and additionally in the frozen m4 file at > /usr/share/autoconf/autoconf/autoconf.m4f , but I've never really grasped the > concept of frozen m4 files) and AC_LINK_IFELSE in > /usr/share/autoconf/autoconf/lang.m4 . > > These are standard macros, so if autoconf cannot find them, something really > weird must be going on. You'll probably have to strace autoreconf to figure > out > what it's reading. Unfortunately, debugging autotools is a nightmare. Well, autoconf was changed in incompatible ways with version 2.70 and I assume that this is the problem. See for example [1]. Adrian > [1] https://lwn.net/Articles/839395/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Running bootstrap script fails on Debian unstable
Hello! I wanted to start the current GRUB master branch on various architectures and it turns out that the bootstrap script currently fails on Debian unstable due to the autoconf syntax changes: running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install --force -I m4 --no-recursive autoreconf: export WARNINGS= autoreconf: Entering directory '.' autoreconf: running: true --force autoreconf: running: aclocal -I m4 --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: configure.ac: not using Intltool autoreconf: configure.ac: not using Gtkdoc autoreconf: running: /usr/bin/autoconf --include=m4 --force configure.ac:429: error: possibly undefined macro: AC_CHECK_HEADERS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:520: error: possibly undefined macro: AC_LINK_IFELSE configure.ac:1631: error: possibly undefined macro: AC_LANG_CALL autoreconf: error: /usr/bin/autoconf failed with exit status: 1 ./bootstrap: autoreconf failed Does anyone know how to address this issue? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 2/6] ieee1275: drop len -= 1 quirk in heap_init
On 12/1/22 22:11, Stefan Berger wrote:
From: Daniel Axtens
This was apparently 'required by some firmware': commit dc9468500919
("2007-02-12 Hollis Blanchard ").
It's not clear what firmware that was, and what platform from 14 years ago
which exhibited the bug then is still both in use and buggy now.
It doesn't cause issues on qemu (mac99 or pseries) or under PFW for Power8.
I don't have access to old Mac hardware, but if anyone feels especially
strongly we can put it under some feature flag. I really want to disable
it under pseries because it will mess with region merging.
I can test this on my iBook G4 but not this week as I am currently not at home.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/30/22 18:37, Robbie Harwood wrote: As the person currently responsible for the Red Hat tree: I am also not happy about this state of affairs. I don't want to sound rude, but GRUB isn't a RedHat-only project, it's a community project. So, while I understand RH's point of view, I would also like to ask you to see other people's perspectives. If a use case is to be supported, someone needs to actually do the leg work to support it. Bug reports are all well and good, but if no one's actually able to fix them, they're just making a pile that's in the way. Vladimir has asked multiple times for bug reports on the issues and he said, he would fix them. I also offered that we do a crowd-funding campaign to fund the development. I would be happy to throw in some money as well. So, if we could get some report on what needs to be addressed, that would be great. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Hi Vladimir! On 8/19/22 21:01, Vladimir 'phcoder' Serbinenko wrote: But booting old machines is still desirable for GRUB. Is there a reason why HFS is actively bad for modern machines? Especially if it's disabled in case of lockdown. Can I have more details about your security concerns? I may consider rewriting parts of HFS code to improve it. FWIW, in case you would be really interested on improving the HFS code, it should be no problem to collect some funds in the PowerPC community to financially support that task, e.g. through a Bountysource campaign. We have done this in the past to support similar projects in GCC and LLVM. What do you think? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/26/22 15:31, Daniel Axtens wrote: I want _all_ grub code to reach a minimum standard of not crashing or corrupting memory in the presence of malicious input. HFS does not reach that standard. I surely understand that although it sounds a little academic to me. Whether or not the HFS module could be omitted from a signed binary doesn't really bear on the fact that there are bugs in the code, the presence of bugs has been publicly known for over 18 months (see commit 1c15848838d9) and no-one has shown any intention of fixing the bugs. Well, I wasn't fully aware of the situation. I am not doing GRUB work professionally, it's just one of the many projects I sometimes touch. If you or someone else (someone from Gentoo, perhaps?) want make it fuzz clean, then that'd be great. If no-one is able to bring it up to what is *not* an especially high standard, then it should be considered abandoned by developers and therefore removed. Sometimes code just works as-is that's why people don't complain. (And as I said in another email, HFS has in fact been built in to a signed binary recently. Module-based protection is great in theory but this example demonstrates that it falls down in practice.) Isn't it up to the distributions what they support and what not? Have you checked that you can't boot them with HFS+? Because HFS+ came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So I'd be really surprised if the firmware didn't support booting from HFS+. I'd be very keen to hear. I have not tested that due to lack of time. The problem is that some early firmware versions might have issues with HFS+ that we haven't verified yet. Any approach that says 'we must wait for test results for very old macs' puts the grub community in a bind. I'm not aware of anyone else stepping up to contribute test results on old macs, and I can't go across to an apple store and buy one. So in order to test this, the entire grub upstream stalls on (AFAICT) you personally. This not the first time we find ourselves in this situation either. For example, RH is carrying the 'powerpc-ieee1275: support larger core.elf images' series out of tree because they need it to boot on modern Power boxes. It broke on your machine in a way no-one else has reproduced, and I last emailled you asking for more information to debug the failure in May. Well, I have tested the things you asked me to test. And besides that it didn't work, I don't that we agreed on something else. I am not the only one using it on old Macs, it's just me who is on this mailing list. It's not like everyone using any software in the Linux world is subscribed to any project's mailing list. I don't understand why some people assume that. People will just at some point complain that it no longer works when they upgrade their software running their distributions. For me, this is not a desirable, sustainable, or acceptable situation. For the project to sustainably support 24 year old macs, we need more than the tests you do in your free time. Well, GRUB is supposed to be a universal bootloader, isn't it? Finally and in conclusion: What's wrong with retrocomputing? Debian's popcon currently reports more machines running the 32-bit big-endian Debian port than the 64-bit little endian port, see [1]. I have no complaint with running _old_ software on old hardware. That's a cool hobby and an important part of preserving the history of computing. My complaint about running _new_ grub on very old hardware is that the inaccessibility of said hardware and the lack of a well-resourced I don't think PowerMacs are really that inaccessible, are they? They are usually easy to buy off eBay and other used hardware platforms. The problem with removing hardware support is that you are continuously making it harder to run software on these machines which would otherwise run fine up to a point where it breaks rendering all the work that people have poured into keeping these ports working useless. POWER hardware is usually rather expensive, so PowerMacs are usually the only kind of PowerPC hardware that most people can afford. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/20/22 15:53, Daniel Axtens wrote: Really, plain HFS, not HFS+? Wowsers! Yes, we're currently using HFS. Just to be clear, by PowerMacs you mean Macs with PowerPC chips, so machines last produced around 2006? Yes. Have you checked that you can't boot them with HFS+? Because HFS+ came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So I'd be really surprised if the firmware didn't support booting from HFS+. I'd be very keen to hear. I have not tested that due to lack of time. The problem is that some early firmware versions might have issues with HFS+ that we haven't verified yet. Anyway, if I've understood correctly, the _most recent_ PowerMacs date from around 16 years ago, and potentially the machines broken by this would be even older. I still think that's in the domain of retrocomputing and I don't understand the use case for running modern software on something where the performance per watt is worse than a recent raspberry pi. What's wrong with retrocomputing? Debian's popcon currently reports more machines running the 32-bit big-endian Debian port than the 64-bit little endian port, see [1]. I understand the need to sometimes get rid of old code, but since the HFS module can be blacklisted as Vladimir explains, I don't really understand the reasoning in this particular case. FWIW, Gentoo also still uses HFS for booting PowerMacs [2]. Adrian [1] https://popcon.debian.org/ [2] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC) -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Hi Vladimir! On 8/19/22 21:45, Vladimir 'phcoder' Serbinenko wrote: This kind of consideration was taken into account when designing security system and even when GRUB2 itself was designed. The solution is modules whitelist. There are many modules that can be dropped from signed build not just filesystems but also commands or loaders. There is no need to cut old systems from new grub if existing infrastructure can handle it. Thank you! I don't understand why maintainers concerned with security can't just do that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Hello! On 8/19/22 21:04, Dimitri John Ledkov wrote: There is no need for that code on any signed grubs or upstream. Ports that want to support this patch can have it conditionally compiled / enabled only on that arch, but not other. That's not how open source works. Individual projects do not get to determine what upstream software supports and what not. And that goes both ways. For example, in Ubuntu we already use separate builds for signed & unsigned bootloaders. Or one may keep grub-2.06 as separate source package. It's not like those old platforms need any new features in the bootloader ever again. That's not the point. Packages are constantly rebuild in Debian for various reasons and having to maintain the package manually in Debian is quite annoying. Forcing older ports to use forks of upstream projects is an "elegant" way to kill of these ports as the maintenance burn gets too high. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/19/22 20:09, Steve McIntyre wrote: On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote: On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote: If I do not hear any major objections in the following weeks I will merge this patch or a variant of it in the second half of September. We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs using HFS, so this change would be a breaking change for us. So, that would be a no from Debian’s side. Not so fast please, Adrian. At the risk of sounding harsh, non-release old ports like powerpc *really* don't get to dictate things in Debian terms. Add "Ports" to this. As Daniel Axtens has been finding out, the HFS code is terrible in terms of security. If you still need it for old/semi-dead machines, maybe you should fork an older grub release and stay with that? I don't know what should be the deal with the security of a boot loader to be honest. If someone has access to your hardware so they can control your bootloader, you have much worse problems anyway. Forking is also a terrible idea as every forked package means having to track it manually. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
> On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote:
>
> On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
>> HFS is so so very old now. According to Wikipedia, HFS was
>> introduced in 1985 and the successor HFS+ came out in January
>> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
>> support for reading HFS in 2019 with macOS 10.15.
>>
>> Grub's support for it doesn't survive contact with a fuzzer, and
>> the issues involve some horrible mess of mutual recursion that
>> would be time-consuming to sort out.
>>
>> HFS has been disabled under lockdown since commit 1c15848838d9
>> ("fs/hfs: Disable under lockdown") which was part of an earlier
>> spin of security fixes.
>>
>> I think it's time to consign HFS to the dustbin of history. It's
>> firmly in the category of retrocomputing at this stage.
>>
>> This should not affect HFS+.
>>
>> There's a little bit of mess remaining: the macbless runtime
>> command and HFS+ need the HFS headers for embedded volume support.
>> I don't think that's really deployed any more, as it would have
>> been part of the HFS->HFS+ transition, but I'm not really game to
>> mess with either, in particular as macbless writes(!) to disk live.
>> (I'm fairly sure the grub-macbless tool invokes code from the
>> macbless module as well.)
>>
>> Signed-off-by: Daniel Axtens
>
> Reviewed-by: Daniel Kiper
>
> Daniel, thank you for preparing this patch!
>
> If I do not hear any major objections in the following weeks I will
> merge this patch or a variant of it in the second half of September.
We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs
using HFS, so this change would be a breaking change for us.
So, that would be a no from Debian’s side.
Adrian
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.12 release, etc.
Hi! On 6/30/22 15:15, Daniel Kiper wrote: > On Tue, Jun 14, 2022 at 07:01:23PM +0200, John Paul Adrian Glaubitz wrote: >> Hello! >> >> On Jun 14, 2022, at 11:52 AM, Xiaotian Wu >> wrote: >> >> I would like to ask, can GRUB-2.12 add a new LoongArch architecture >> support? >> >> It would also be great if the patches that add support for 64-bit MIPS EFI >> could be added as well. > > Did anybody post them on the grub-devel? I do not think so. Any volunteers? According to the people I talked to at Loongson, these patches were written by Rui Wang (CC'ed). Rui, do you think you can post them on the grub-devel mailing list? >> See: https://github.com/AOSC-Dev/grub-loongson3 >> >> I have hardware available for testing these. > > Good to now! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.12 release, etc.
Hello! > On Jun 14, 2022, at 11:52 AM, Xiaotian Wu wrote: > > I would like to ask, can GRUB-2.12 add a new LoongArch architecture support? It would also be great if the patches that add support for 64-bit MIPS EFI could be added as well. See: https://github.com/AOSC-Dev/grub-loongson3 I have hardware available for testing these. Adrian___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix vlan networking on little-endian systems
Hello Chad! On 3/1/22 15:03, Chad Kimes via Grub-devel wrote: > The interface vlantag appears to have never worked on little-endian systems. > This small > initial patch is mostly to get my feet wet in the GRUB dev process. Once this > is accepted, > I intend to submit a few more patches that (a) allow vlan configuration via a > command from > the net module and (b) auto-configure vlan from the UEFI device used for PXE > booting. Could you use git send-email to send in your patches? See this guide, for example. [1] Adrian > [1] https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 0/8] Add support for LoongArch
Hello! On 2/23/22 14:46, Xiaotian Wu wrote: > LoongArch is a new Loongson 3A5000 CPU instruction set, you can read > documents[1] or visit the development community[2] to get more information. Is there any chance the support for mips64el EFI [1] could be upstreamed as well? There is a repository available with a branch rebased against grub master [2]. Currently, GRUB EFI on mips64el is stuck at version 2.02 which is rather old. Adrian > [1] https://github.com/loongson-community/grub > [2] https://github.com/AOSC-Dev/grub-loongson3 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Powerpc grub_func_test never exits
Hi Glenn! On 1/14/22 22:59, Glenn Washburn wrote: > On Fri, 14 Jan 2022 09:48:56 +0100 > > Hi Adrian, thanks for testing this for me. You're welcome! >> On 1/14/22 09:45, John Paul Adrian Glaubitz wrote: >>> I have burnt the ISO to a CD-R now and booted my iBook G4 with it. >>> >>> It boots but gets stuck at "Welcome to GRUB!". I can hear CD-ROM access >>> noises >>> from time to time but no changes on the screen so far. I'll let it running >>> for some time. >> >> OK, so the machine just shut itself off. There was no other output besides >> the >> message "Welcome to GRUB!", but I assume that is as expected and the tests >> run >> silently, then shut the machine off. >> >> So, it seems to work on real hardware. > > I forgot the output gets sent to the serial port, so that's why you > don't see anything. That's good that it works (ie shuts itself down). > That leads me to believe there's a bug in PowerPC Open Firmware. Ah, serial output indeed explains why I didn't see anything. The problem is that this is an iBook G4 which doesn't have a serial output I could use, so output to the framebuffer would be better. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] powerpc-ieee1275: support larger core.elf images
Hi! On 1/14/22 17:54, John Paul Adrian Glaubitz wrote: > Hmm, I must have forgotten that. Let me give it a try after dinner. The laptop > just happens to be sitting next to me. I gave it a try now and made sure to use the proper grub-core directory and that the kernel.img in /usr/local/lib/grub/powerpc-ieee1275/ is up-to-date, so installation went without an error message: root@ibook-g4-14:/home/glaubitz/grub# grub-install -d ./grub-core --macppc-directory=/boot/grub --no-nvram Installing for powerpc-ieee1275 platform. grub-install: warning: cannot open directory `/usr/local/share/locale': No such file or directory. Installation finished. No error reported. root@ibook-g4-14:/home/glaubitz/grub# However, after rebooting the machine, the machine is now unbootable. The firmware is unable to even load GRUB. I'm just getting the question mark sign which indicates that the firmware cannot find the bootloader. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] powerpc-ieee1275: support larger core.elf images
Hi Robbie! On 1/14/22 17:43, Robbie Harwood wrote: > John Paul Adrian Glaubitz writes: > >> On 11/24/21 01:51, Daniel Axtens wrote: >>> Could you humour me and: >>> - check that your kernel.img in /usr is indeed up to date >>> - try grub-install ... -d ./grub-core? >>> >>> Many thanks! >> >> Apologies for the late reply. I will give it a try later today and >> report back. > > Hi Adrian, did you get a chance to try Daniel's suggestion? Hmm, I must have forgotten that. Let me give it a try after dinner. The laptop just happens to be sitting next to me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Powerpc grub_func_test never exits
Hi Glenn! On 1/14/22 09:45, John Paul Adrian Glaubitz wrote: > I have burnt the ISO to a CD-R now and booted my iBook G4 with it. > > It boots but gets stuck at "Welcome to GRUB!". I can hear CD-ROM access noises > from time to time but no changes on the screen so far. I'll let it running > for some time. OK, so the machine just shut itself off. There was no other output besides the message "Welcome to GRUB!", but I assume that is as expected and the tests run silently, then shut the machine off. So, it seems to work on real hardware. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Powerpc grub_func_test never exits
Hi Glenn! On 1/8/22 01:34, Glenn Washburn wrote: > I've attached an iso that will reproduce this issue in Debian's QEMU > 5.2 and 6.1. The QEMU command to run is (not all options may be needed): > > $ qemu-system-ppc -M mac99,via=pmu -m 2048M -nographic -monitor > file:/dev/null -fw_cfg name=etc/sercon-port,string=0 -serial null > -serial file:/dev/stdout -hda grub.iso -boot c > > This issue is not present in other QEMU tests, which could indicate a > GRUB issue. But if so, it doesn't seem to present itself on any other > target that I've been testing. I suspect there's a bug in GRUB that is > PPC specific that corrupts firmware memory such that halt doesn't > happen. > > I'm curious how this would behave on real hardware, does it still hang? > > Getting this resolved will allow my testing to properly see this as a > test failure and not a non-test error. I have burnt the ISO to a CD-R now and booted my iBook G4 with it. It boots but gets stuck at "Welcome to GRUB!". I can hear CD-ROM access noises from time to time but no changes on the screen so far. I'll let it running for some time. Let me know if you want me to try anything else. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Powerpc grub_func_test never exits
Hi Glenn! On 1/8/22 01:34, Glenn Washburn wrote: > I've attached an iso that will reproduce this issue in Debian's QEMU > 5.2 and 6.1. The QEMU command to run is (not all options may be needed): > > $ qemu-system-ppc -M mac99,via=pmu -m 2048M -nographic -monitor > file:/dev/null -fw_cfg name=etc/sercon-port,string=0 -serial null > -serial file:/dev/stdout -hda grub.iso -boot c > > This issue is not present in other QEMU tests, which could indicate a > GRUB issue. But if so, it doesn't seem to present itself on any other > target that I've been testing. I suspect there's a bug in GRUB that is > PPC specific that corrupts firmware memory such that halt doesn't > happen. > > I'm curious how this would behave on real hardware, does it still hang? I'm not at home at the moment, but I will be glad to burn this to a CD-R and run it on my iBook G4 and report the results back. That will most probably happen on Monday. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] powerpc-ieee1275: support larger core.elf images
Hi Daniel! On 11/24/21 01:51, Daniel Axtens wrote: > Could you humour me and: > - check that your kernel.img in /usr is indeed up to date > - try grub-install ... -d ./grub-core? > > Many thanks! Apologies for the late reply. I will give it a try later today and report back. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] powerpc-ieee1275: support larger core.elf images
Hello Daniel! On 11/16/21 04:42, Daniel Axtens wrote: > Daniel Axtens (2): > powerpc-ieee1275: load grub at 8MB, not 2MB > ieee1275: set real-base in the PowerPC IEEE1275 Note to 32MB I have applied these now and tested them on my iBook G4 but that introduced the following regression: root@ibook-g4-14:/home/glaubitz/grub# grub-install --macppc-directory=/boot/grub --no-nvram Installing for powerpc-ieee1275 platform. grub-install: warning: cannot open directory `/usr/local/share/locale': No such file or directory. grub-install: error: `/usr/local/lib/grub/powerpc-ieee1275/kernel.img' is miscompiled: its start address is 0x20 instead of 0x80: ld.gold bug?. root@ibook-g4-14:/home/glaubitz/grub# Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB
Hi! On 11/16/21 16:31, Vladimir 'phcoder' Serbinenko wrote: > Was it tested on powerpc-based Macs? They're still useful for > debugging and developpement despite their age Fired up my iBook G4 now and updating everything the latest package versions in Debian unstable. Will test the patch after that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB
On 11/16/21 17:48, John Paul Adrian Glaubitz wrote: >> But generally, I don't think this is a reasonable requirement. > > I do. And, FWIW, we have quite an active user base for Debian on PowerMacs and I would eventually get all these user reports if something breaks. I work a commercial Linux vendor myself, but I find it a bit frustrating when some people think Linux development should care about commercial use cases only. The charm of Linux and free software is that it works well on old hardware and hacking on these old machines is still very valuable for educational purposes and as a hobby. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB
Hello! On 11/16/21 17:37, Robbie Harwood wrote: > Per Daniel's message: > > The tests with powerpc32 using the OpenBIOS OF implementation seem > to still work. I have no 32-bit Apple hardware to test on. > > But generally, I don't think this is a reasonable requirement. I do. > Not only are powerpc macs very old at this point (discontinued 2006 - 15 > years ago), but there also aren't really distros that supports them > (Debian dropped them in 8, Fedora around 12, Suse in it looks like 7). > Sure, Gentoo might work - but these are by no means fast machines. Debian supports 32-bit PowerPC in Debian Ports. I'm regularly creating updated images: > https://cdimage.debian.org/cdimage/ports/snapshots/ We even support Debian on m68k :-). > To be constructive: I submit that if users/developers want to test on > these machines that they have and use, we should incorporate their > feedback where reasonable. But let's not hold back patches over > hypothetical concerns for a dead architecture. [1] I can test them later this week. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 released
Hi Daniel! On 6/8/21 7:34 PM, Daniel Kiper wrote: > GRUB maintainers are proud to announce GRUB 2.06 that has been just released. > You can find list of new features and major fixes since release 2.04 in the > NEWS file. Congratulations. I'm glad the new release is finally out. > We would like to thank all the people who have contributed to the project. I concur. Thanks a lot to everyone helping to make this happen! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] grub-core: Build fixes for i386
On 5/18/21 4:35 PM, John Paul Adrian Glaubitz wrote: > So I'm not sure what kind of host system we are talking about here? This looks > more like a configuration issue of the distribution in question which > deliberately > builds its 32-bit toolchain without 64-bit support. Hmm, I just noticed that the existing code already does use these crude hacks to be able to build 64-bit code with a 32-bit assembler: > http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/lib/i386/relocator64.S#n57 But still, I find that very odd that the host system's toolchain isn't just built with 64-bit support enabled but maybe I'm missing something obvious. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] grub-core: Build fixes for i386
Hi Daniel! On 5/18/21 4:26 PM, Daniel Kiper wrote: > When I was looking at the issue first time I thought in the same way. > Though after some thinking I realized that it is perfectly valid to > start 64-bit kernel from 32-bit bootloader which was build in 32-bit > environment. So, I think it makes sense to take that patch, which is not > very complicated and does not introduce anything which did not exist > earlier in the relocator64.S, even a such scenario is not very common > today. But this is about the toolchain, isn't it? Shouldn't even a 32-bit x86 toolchain be able to build 64-bit code? I just checked standard binutils on a 32-bit Debian system and both the assembler and the linker support 64-bit targets: (sid_i386-dchroot)glaubitz@barriere:~$ as --help|grep 64 --32/--64/--x32 generate 32bit/64bit/x32 code generic32, generic64, i386, i486, i586, i686, pconfig, waitpkg, cldemote, movdiri, movdir64b, nomovdiri, nomovdir64b, noavx512_bf16, generic32, generic64, i8086, i186, i286, i386, i486, -mamd64 accept only AMD64 ISA [default] -mintel64 accept only Intel64 ISA (sid_i386-dchroot)glaubitz@barriere:~$ (sid_i386-dchroot)glaubitz@barriere:~$ ld --help|grep supported ld: supported targets: elf32-i386 elf32-iamcu pei-i386 elf32-little elf32-big elf64-x86-64 elf32-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big pe-x86-64 pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex binary ihex plugin trad-core ld: supported emulations: elf_i386 elf_iamcu elf_x86_64 elf32_x86_64 elf_l1om elf_k1om i386pep i386pe (sid_i386-dchroot)glaubitz@barriere:~$ So I'm not sure what kind of host system we are talking about here? This looks more like a configuration issue of the distribution in question which deliberately builds its 32-bit toolchain without 64-bit support. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] grub-core: Build fixes for i386
Hello Jan! On 5/18/21 12:47 PM, Jan (janneke) Nieuwenhuizen wrote: > or install an x86 cross-build environment on x86-linux (32bit!) and > configure to cross build and make, e.g., do something like Are we talking about a toolchain which exclusively supports 32-bit builds only? If yes, wouldn't it make sense to exclude the whole file relocator64.S? I think hacking the opcodes into the assembly sources directly to allow assembling the assembly source file with a pure 32-bit assembler seems like a crude workaround that I wouldn't use in an upstream source tree. It seems the issue is more that you are trying to build 64-bit code with a toolchain which exclusively supports 32-bit code which I'm not sure is something that can be officially supported. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: boot/grub2: grub-core-build-fixes-for-i386 (grub-2.04 + binutils-2.35.2 + pseudo-op .code64)
Hello Jan! On 5/18/21 7:05 AM, Jan Nieuwenhuizen wrote: >>> Sure, sent separately to bug-grub. >> >> I cannot find your updated patch. > > It's here: > > https://lists.gnu.org/archive/html/bug-grub/2021-05/msg9.html > >> May I ask you to send it using "git-send-email" to grub-devel@gnu.org? > > (waiting with this for a bit, please ping if needed :) I think you should post the patch to this mailing list so it can be reviewed here. Reviewing the patch when it's located in the archives of a different mailing list is a bit awkward. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Buildroot] boot/grub2: grub-core-build-fixes-for-i386 (grub-2.04 + binutils-2.35.2 + pseudo-op .code64)
Hello Mikhail! On 5/13/21 9:19 AM, Mikhail B. WproxyM wrote: > As expected, they do not want to include fix patch, because "The GRUB 2.04 > release is a few years old." Since GRUB 2.06 will hopefully be released within the next weeks, you should be able to upgrade to the new upstream release, aren't you? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] util/mkimage: Fix wrong PE32+ section sizes for some arches
Hi Daniel! On 4/27/21 5:35 PM, Daniel Kiper wrote: >> Works on my ia64 machine. >> >> Tested-by: John Paul Adrian Glaubitz > > Reviewed-by: Daniel Kiper > > Javier, Adrian, thank you for working patiently on this fix. Sure, no problem :-). Since this fix unbreaks grub on potentially many systems, could you merge the patch with higher priority? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: boot/grub2: grub-core-build-fixes-for-i386 (grub-2.04 + binutils-2.35.2 + pseudo-op .code64)
Hello Mikhail! On 5/5/21 11:39 AM, Mikhail B. WproxyM wrote: > We are using binutils-2.35.2+ (later then 2.29.1), grub-2.04, > cross-compiling on recent buildroot under i386/i686 and getting error: > >> lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64' > > So, the working patch is attached. Please add it to grub2. Please re-send your patch using git-send-email, see [1], for example. Adrian > [1] https://git-send-email.io/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] util/mkimage: Fix wrong PE32+ section sizes for some arches
On 4/27/21 12:25 PM, Javier Martinez Canillas wrote:
> Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper)
> added a helper function to setup PE sections. But it also changed how the
> raw data offsets were calculated since all the section sizes are aligned.
>
> However, for some platforms, i.e ia64-efi and arm64-efi, the kernel image
> size is not aligned using the section alignment.
>
> This leads to the situation in which the mods section offset in its PE
> section header does not match its real placement in the PE file.
> So, finally the GRUB is not able to locate and load built-in modules.
>
> The problem surfaces on ia64-efi and arm64-efi because both platforms
> require additional relocation data which is added behind .bss section.
> So, we have to add some padding behind this extra data to make the
> beginning of mods section properly aligned in the PE file.
>
> Fix it by aligning the kernel_size to the section alignment. That makes
> the sizes and offsets in the PE section headers to match relevant sections
> in the PE32+ binary file.
>
> Reported-by: John Paul Adrian Glaubitz
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes in v3:
> - Drop the RFC prefix since I'm confident now about the solution.
> - Improve commit message (suggested by Daniel Kiper).
> - Don't use virtual memory addresses to calculate the kernel size,
> but instead use the raw data sizes (suggested by Daniel Kiper).
>
> Changes in v2:
> - Align up for any arch in the is_relocatable (image_target) patch and
> not only for MKIMAGE_ELF64 or EM_AARCH64 (suggested by Daniel Kiper).
>
> util/grub-mkimagexx.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
> index 00f49ccaaaf..d78fa3e5330 100644
> --- a/util/grub-mkimagexx.c
> +++ b/util/grub-mkimagexx.c
> @@ -2388,6 +2388,10 @@ SUFFIX (grub_mkimage_load_image) (const char
> *kernel_path,
> layout->kernel_size += ALIGN_UP (layout->got_size, 16);
> }
> #endif
> +
> + if (image_target->id == IMAGE_EFI)
> +layout->kernel_size = ALIGN_UP (layout->kernel_size,
> + GRUB_PE32_FILE_ALIGNMENT);
> }
>else
> {
>
Works on my ia64 machine.
Tested-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH v2] util/mkimage: Fix wrong PE32+ section sizes for some arches
Hi Javier! On 4/26/21 7:18 PM, Daniel Kiper wrote: > (...) > I think this should be: > layout->kernel_size = ALIGN_UP (layout->kernel_size, > GRUB_PE32_FILE_ALIGNMENT); > > Here we care about alignment in the PE file not in the memory. So, > I think we have to use GRUB_PE32_FILE_ALIGNMENT instead. Though > the result is the same... Let me know once you have a new version of the patch ready, I'll test it as quickly as possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH v2] util/mkimage: Fix wrong PE32+ section sizes for some arches
Hi Javier!
On 4/26/21 10:05 AM, Javier Martinez Canillas wrote:
> On 4/26/21 9:52 AM, John Paul Adrian Glaubitz wrote:
>
> [snip]
>
>>> +
>>> + if (image_target->id == IMAGE_EFI)
>>> +layout->kernel_size = ALIGN_UP (layout->kernel_size +
>>> image_target->vaddr_offset,
>>> +image_target->section_align)
>>> + - image_target->vaddr_offset;
>>> }
>>>else
>>> {
>>>
>>
>> Verified to fix the issue on ia64.
>>
>> Tested-by: John Paul Adrian Glaubitz
>>
>
> Thanks again for testing this so quickly! I really appreciate it
> since don't have access to an Itanium system to verify the patch.
You're absolutely welcome. And I also appreciate the great work so many people
have
already delivered to get the next release of GRUB ready. I'm really looking
forward
to version 2.06 and the swath of patches which distributions will be able to
drop
because they have all been merged upstream :-).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC PATCH v2] util/mkimage: Fix wrong PE32+ section sizes for some arches
On 4/26/21 9:21 AM, Javier Martinez Canillas wrote:
> Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper)
> added a helper function to setup PE sections. But it also changed how the
> raw data offsets were calculated since all the section sizes are aligned.
>
> But for some platforms (i.e: ia64 and aa64) the kernel image size wasn't
> aligned using the section alignment, which causes the PE section headers
> to not match the actual section sizes in the PE32+ binary file.
>
> This caused problems on ia64 EFI machines, since the .data section size
> is bigger than the actual section in the PE32+ binary, overlapping with
> part of the mods section. That leads to GRUB not being able to load any
> built-in module.
>
> Fix it by aligning the kernel_size to the section alignment, that makes
> the sizes and offsets in the PE section headers to match the sections
> in the PE32+ binary file.
>
> Reported-by: John Paul Adrian Glaubitz
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes in v2:
> - Align up for any arch in the is_relocatable (image_target) patch and
> not only for MKIMAGE_ELF64 or EM_AARCH64 (suggested by Daniel Kiper).
>
> util/grub-mkimagexx.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
> index 00f49ccaaaf..73646f12f14 100644
> --- a/util/grub-mkimagexx.c
> +++ b/util/grub-mkimagexx.c
> @@ -2388,6 +2388,11 @@ SUFFIX (grub_mkimage_load_image) (const char
> *kernel_path,
> layout->kernel_size += ALIGN_UP (layout->got_size, 16);
> }
> #endif
> +
> + if (image_target->id == IMAGE_EFI)
> +layout->kernel_size = ALIGN_UP (layout->kernel_size +
> image_target->vaddr_offset,
> +image_target->section_align)
> + - image_target->vaddr_offset;
> }
>else
> {
>
Verified to fix the issue on ia64.
Tested-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06
On 4/20/21 10:33 PM, Eli Schwartz wrote: > (Well, I'm given to understand Debian maintainers seem to actively enjoy > having many patches. So I guess I shouldn't be *too* surprised that a > Debian Developer is insisting that people maintain downstream patches.) Why do you think you need to resort to personal attacks. You are reading things into my messages that I never said. Please refrain from doing that and please don't make assumptions about people you don't know. Also, I find it insulting to accuse the whole Debian project of a bad maintenance culture. Debian has probably done more to open source and Linux than Arch ever will. PS: I also happen to be a SUSE employee and openSUSE/SLE maintainer, so your first assumption that I'm somehow subject to Debian culture is flawed. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06
On 4/20/21 7:50 PM, Mike Gilbert wrote: > My 2 cents: > > If a distro starts shipping a new version of GCC, they should really > test their packages first and patch them as needed. > > If an end user installs a new version of GCC manually, I would hope > they are smart enough to know that it might break things. > > If an end user builds GRUB manually, they are also responsible for > applying any patches that are necessary for their toolchain. Fully agree on all points. And while I cannot speak for Gentoo, I know that Fedora, Debian and openSUSE did full archive rebuilds with gcc-10 when it was released. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06
On 4/20/21 7:34 PM, Didier Spaier wrote: > So, it's hard to understand for many end users that: > > 1. The issue appeared after gcc-10 began to be used, well after the release > of grub 2.04. > 2. It has been fixed long ago. > 3. But for the fix to be effective one of these conditions should be met: > a. A new grub version has been released and is provided by the distribution > they use. > b. The distributon they use patches the source of GRUB 2.04 to bring the fix. > c. The distribution they use provides a package build from a source pulled > from with the patch already committed. > > Unfortunately if none of these conditions is met many users tend > to blame GRUB instead of the distributions and go saying in fora "I'll avoid > to use GRUB, it's broken" I think it's reasonable to expect from a distribution that they backport upstream fixes, at least in Debian, openSUSE and Fedora, it isn't a problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06
Hello! On 4/20/21 3:53 PM, Daniel Kiper wrote: > I tried a few times but I am not able to open this link. Sorry... > Could you explain your problem here? The correct link seems to point to this thread: > https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/ But it's not opening for me either although I can see the Slackware forum: > https://www.linuxquestions.org/questions/slackware-14/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
Hi Javier1 On 4/16/21 11:32 PM, Javier Martinez Canillas wrote: >> I can confirm that this fixes the issue and makes GRUB work again on ia64. >> >> Tested-by: John Paul Adrian Glaubitz >> > > Great, thanks a lot for the quick testing! Could you send the patch to the mailing list separately with git send-email or so that it doesn't get overlooked in the longer discussion we had? I want to make sure Daniel picks up the fix for the 2.06 release. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
Hi Javier! On 4/16/21 10:14 PM, Javier Martinez Canillas wrote: > On 4/16/21 6:55 PM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> On 4/16/21 6:43 PM, John Paul Adrian Glaubitz wrote: >>> It seems the patch no longer applies due to the changes introduced by the >>> --sbat >>> option [1]. >> >> I have manually rebased the patch like this. Rebuilding GRUB with that change >> fixes the problem for me. So you'll just have to rebase your patch and we >> should >> be good to go. >> > > Oh, sorry about that. I checked out the problematic commit and then forgot > that was > not in the latest HEAD. > > [snip] > >> - scn_size = pe_size - layout.reloc_size - sbat_size - raw_data; >> + scn_size = ALIGN_UP (pe_size - layout.reloc_size - sbat_size - >> raw_data, GRUB_PE32_FILE_ALIGNMENT); >> section = init_pe_section (image_target, section, "mods", >>, scn_size, >> image_target->section_align, >> - _data, scn_size, >> + _data, pe_size - layout.reloc_size - >> raw_data, > > I think this should to be: > >> + _data, pe_size - layout.reloc_size - >> sbat_size - raw_data, > > but I've forward ported to current master branch now and also made the > patch more clear. I've only tested on x64 so it would be great if can > test it on ia64: > > From 767fdee805ce4bdd19c23c15c1f29a314282eaaf Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas > Date: Fri, 16 Apr 2021 21:37:23 +0200 > Subject: [PATCH] util/mkimage: Some fixes to PE binaries section size > calculation > > Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper) > added a helper function to setup PE sections, but it caused regressions > in some arches where the natural alignment lead to wrong section sizes. > > This patch fixes a few things that were caused the section sizes to be > calculated wrongly. These fixes are: > > * Only align the virtual memory addresses but not the raw data offsets. > * Use aligned sizes for virtual memory sizes but not for raw data sizes. > * Always align the sizes to set the virtual memory sizes. > > These seems to not cause problems for x64 and aa64 EFI platforms but was > a problem for ia64. Because the size of the ".data" and "mods" sections > were wrong and didn't have the correct content. Which lead to GRUB not > being able to load any built-in module. > > Reported-by: John Paul Adrian Glaubitz > Signed-off-by: Javier Martinez Canillas > --- > util/mkimage.c | 21 - > 1 file changed, 12 insertions(+), 9 deletions(-) > > diff --git a/util/mkimage.c b/util/mkimage.c > index a26cf76f72f..b84311f1ffb 100644 > --- a/util/mkimage.c > +++ b/util/mkimage.c > @@ -841,7 +841,7 @@ init_pe_section(const struct > grub_install_image_target_desc *image_target, > >section->raw_data_offset = grub_host_to_target32 (*rda); >section->raw_data_size = grub_host_to_target32 (rsz); > - (*rda) = ALIGN_UP (*rda + rsz, GRUB_PE32_FILE_ALIGNMENT); > + (*rda) = *rda + rsz; > >section->characteristics = grub_host_to_target32 (characteristics); > > @@ -1309,7 +1309,7 @@ grub_install_generate_image (const char *dir, const > char *prefix, > char *pe_img, *pe_sbat, *header; > struct grub_pe32_section_table *section; > size_t n_sections = 4; > - size_t scn_size; > + size_t scn_size, raw_size; > grub_uint32_t vma, raw_data; > size_t pe_size, header_size; > struct grub_pe32_coff_header *c; > @@ -1410,7 +1410,8 @@ grub_install_generate_image (const char *dir, const > char *prefix, > GRUB_PE32_SCN_MEM_EXECUTE | > GRUB_PE32_SCN_MEM_READ); > > - scn_size = ALIGN_UP (layout.kernel_size - layout.exec_size, > GRUB_PE32_FILE_ALIGNMENT); > + raw_size = layout.kernel_size - layout.exec_size; > + scn_size = ALIGN_UP (raw_size, GRUB_PE32_FILE_ALIGNMENT); > /* ALIGN_UP (sbat_size, GRUB_PE32_FILE_ALIGNMENT) is done earlier. */ > PE_OHDR (o32, o64, data_size) = grub_host_to_target32 (scn_size + > sbat_size + > ALIGN_UP > (total_module_size, > @@ -1418,15 +1419,16 @@ grub_install_generate_image (const char *dir, const > char *prefix, > > section = init_pe_section (image_target, section, ".data", > , scn_size, image_target->section_align, > -
Re: GRUB error: unknown filesystem on ia64
Hi Javier! On 4/16/21 5:21 PM, Javier Martinez Canillas wrote: > Thanks for the binaries, as you said the ".data" and "mods" sections had > wrong size and content. Could you please try the following patch [0] ? > > It's an RFC since I'm not really an expert on binary formats, but there > were a few problems with the patch you mentioned as far as I can tell. > > I Cc'ed Daniel and Peter so they can correct me if I got anything wrong. > > Best regards, > Javier > > [0] > From 31c9864ff6543b624d404d8fabc9c517756a470a Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas > Date: Fri, 16 Apr 2021 17:01:44 +0200 > Subject: [RFC PATCH] util/mkimage: Some fixes to PE binaries section size > calculation > > Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper) > added a helper function to setup PE sections, but it caused regressions > in some arches where the natural alignment lead to wrong section sizes. > > This patch fixes a few things that were caused the section sizes to be > calculated wrongly. These fixes are: > > * Only align the virtual memory addresses but not the raw data offsets. > * Use aligned sizes for virtual memory sizes but not for raw data sizes. > * Always align the sizes to set the virtual memory sizes. > > These seems to not cause problems for x64 and aa64 EFI platforms but was > a problem for ia64. Because the size of the ".data" and "mods" sections > were wrong and didn't have the correct content. Which lead to GRUB not > being able to load any built-in module. > > Reported-by: John Paul Adrian Glaubitz > Signed-off-by: Javier Martinez Canillas > --- > util/mkimage.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/util/mkimage.c b/util/mkimage.c > index 8b475a69109..0d33f0e9766 100644 > --- a/util/mkimage.c > +++ b/util/mkimage.c > @@ -841,7 +841,7 @@ init_pe_section(const struct > grub_install_image_target_desc *image_target, > >section->raw_data_offset = grub_host_to_target32 (*rda); >section->raw_data_size = grub_host_to_target32 (rsz); > - (*rda) = ALIGN_UP (*rda + rsz, GRUB_PE32_FILE_ALIGNMENT); > + (*rda) = *rda + rsz; > >section->characteristics = grub_host_to_target32 (characteristics); > > @@ -1389,26 +1389,26 @@ grub_install_generate_image (const char *dir, const > char *prefix, > > section = init_pe_section (image_target, section, ".data", > , scn_size, image_target->section_align, > -_data, scn_size, > +_data, layout.kernel_size - > layout.exec_size, > GRUB_PE32_SCN_CNT_INITIALIZED_DATA | > GRUB_PE32_SCN_MEM_READ | > GRUB_PE32_SCN_MEM_WRITE); > > - scn_size = pe_size - layout.reloc_size - raw_data; > + scn_size = ALIGN_UP (pe_size - layout.reloc_size - raw_data, > GRUB_PE32_FILE_ALIGNMENT); > section = init_pe_section (image_target, section, "mods", > , scn_size, image_target->section_align, > -_data, scn_size, > +_data, pe_size - layout.reloc_size - > raw_data, > GRUB_PE32_SCN_CNT_INITIALIZED_DATA | > GRUB_PE32_SCN_MEM_READ | > GRUB_PE32_SCN_MEM_WRITE); > > - scn_size = layout.reloc_size; > + scn_size = ALIGN_UP (layout.reloc_size, GRUB_PE32_FILE_ALIGNMENT); > PE_OHDR (o32, o64, base_relocation_table.rva) = grub_host_to_target32 > (vma); > PE_OHDR (o32, o64, base_relocation_table.size) = grub_host_to_target32 > (scn_size); > memcpy (pe_img + raw_data, layout.reloc_section, scn_size); > init_pe_section (image_target, section, ".reloc", >, scn_size, image_target->section_align, > - _data, scn_size, > + _data, layout.reloc_size, >GRUB_PE32_SCN_CNT_INITIALIZED_DATA | >GRUB_PE32_SCN_MEM_DISCARDABLE | > GRUB_PE32_SCN_MEM_READ); > It seems the patch no longer applies due to the changes introduced by the --sbat option [1]. Could you rebase your patch? Meanwhile I'm testing it with a manual rebase applied. Adrian > [1] > http://git.savannah.gnu.org/cgit/grub.git/commit/util?id=b11547137703bbc642114a816233a5b6fed61b06 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
Hi!
On 4/16/21 6:43 PM, John Paul Adrian Glaubitz wrote:
> It seems the patch no longer applies due to the changes introduced by the
> --sbat
> option [1].
I have manually rebased the patch like this. Rebuilding GRUB with that change
fixes the problem for me. So you'll just have to rebase your patch and we should
be good to go.
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -841,7 +841,7 @@ init_pe_section(const struct grub_install_image_target_desc
*image_target,
section->raw_data_offset = grub_host_to_target32 (*rda);
section->raw_data_size = grub_host_to_target32 (rsz);
- (*rda) = ALIGN_UP (*rda + rsz, GRUB_PE32_FILE_ALIGNMENT);
+ (*rda) = *rda + rsz;
section->characteristics = grub_host_to_target32 (characteristics);
@@ -1418,15 +1418,15 @@ grub_install_generate_image (const char *dir, const
char *prefix,
section = init_pe_section (image_target, section, ".data",
, scn_size, image_target->section_align,
- _data, scn_size,
+ _data, layout.kernel_size -
layout.exec_size,
GRUB_PE32_SCN_CNT_INITIALIZED_DATA |
GRUB_PE32_SCN_MEM_READ |
GRUB_PE32_SCN_MEM_WRITE);
- scn_size = pe_size - layout.reloc_size - sbat_size - raw_data;
+ scn_size = ALIGN_UP (pe_size - layout.reloc_size - sbat_size -
raw_data, GRUB_PE32_FILE_ALIGNMENT);
section = init_pe_section (image_target, section, "mods",
, scn_size, image_target->section_align,
- _data, scn_size,
+ _data, pe_size - layout.reloc_size -
raw_data,
GRUB_PE32_SCN_CNT_INITIALIZED_DATA |
GRUB_PE32_SCN_MEM_READ |
GRUB_PE32_SCN_MEM_WRITE);
@@ -1444,13 +1444,13 @@ grub_install_generate_image (const char *dir, const
char *prefix,
GRUB_PE32_SCN_MEM_READ);
}
- scn_size = layout.reloc_size;
+ scn_size = ALIGN_UP (layout.reloc_size, GRUB_PE32_FILE_ALIGNMENT);
PE_OHDR (o32, o64, base_relocation_table.rva) = grub_host_to_target32
(vma);
PE_OHDR (o32, o64, base_relocation_table.size) = grub_host_to_target32
(scn_size);
memcpy (pe_img + raw_data, layout.reloc_section, scn_size);
init_pe_section (image_target, section, ".reloc",
, scn_size, image_target->section_align,
-_data, scn_size,
+_data, layout.reloc_size,
GRUB_PE32_SCN_CNT_INITIALIZED_DATA |
GRUB_PE32_SCN_MEM_DISCARDABLE |
GRUB_PE32_SCN_MEM_READ);
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
Hi Javier! On 4/12/21 8:21 AM, Javier Martinez Canillas wrote: > Interesting, thanks for the input. > > Could you please share a both GRUB binary that works and one that > fails to compare ? Here are both the EFI as well as the GRUB directory for the broken and working cases: > https://people.debian.org/~glaubitz/grub-ia64/ If you compare the two core.efi images, you will see the issue immediately: glaubitz@epyc:..glaubitz/grub-ia64> xxd grub-broken/ia64-efi/core.efi > broken.txt glaubitz@epyc:..glaubitz/grub-ia64> xxd grub-working/ia64-efi/core.efi > working.txt glaubitz@epyc:..glaubitz/grub-ia64> diff -u broken.txt working.txt --- broken.txt 2021-04-12 08:57:07.292897158 +0200 +++ working.txt 2021-04-12 08:57:14.38768 +0200 @@ -25,10 +25,10 @@ 0180: 2e74 6578 7400 .text... 0190: 00e0 0100 0010 00e0 0100 0010 01a0: 2000 0060 ..` -01b0: 2e64 6174 6100 00a0 0100 00f0 0100 .data... -01c0: 00a0 0100 00f0 0100 +01b0: 2e64 6174 6100 e094 0100 00f0 0100 .data... +01c0: e094 0100 00f0 0100 01d0: 4000 00c0 6d6f 6473 @...mods -01e0: 0060 0090 0300 0060 0090 0300 .`...`.. +01e0: 206b e084 0300 206b e084 0300 k.. k.. 01f0: 4000 00c0 @... 0200: 2e72 656c 6f63 0010 00f0 0300 .reloc.. 0210: 0010 00f0 0300 glaubitz@epyc:..glaubitz/grub-ia64> Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
On 4/8/21 7:30 PM, John Paul Adrian Glaubitz wrote: > On 4/8/21 7:10 PM, Javier Martinez Canillas wrote: >>> Any news on this? I assume this should be trivial to fix when considering >>> just the >> >> Not yet, sorry. I discussed a little bit with Peter yesterday but it's >> strange >> that only affects ia64 and not x64. I'll try to take a look at this next >> week. > > It's probably caused by different natural alignment which causes the code on > x86_64 > to land at the right position automatically. OK, so I had another discussion with Michael Karcher who analyzed the bug and the problem is apparently that after the change, mkimage adds an alignment to the module address which it did not before the change. And the suspicion why this affects ia64 and not x86_64 could be that the module data is properly aligned as mkimage expects while it's not on ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
On 4/8/21 7:10 PM, Javier Martinez Canillas wrote: >> Any news on this? I assume this should be trivial to fix when considering >> just the > > Not yet, sorry. I discussed a little bit with Peter yesterday but it's strange > that only affects ia64 and not x64. I'll try to take a look at this next week. It's probably caused by different natural alignment which causes the code on x86_64 to land at the right position automatically. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
Hi Daniel! On 3/26/21 7:43 PM, Daniel Kiper wrote: >> The address pointing to the modules within the GRUB core.img no longer >> matches >> the actual position of the modules. Hence, GRUB can't load the built-in >> modules >> anymore. > > Ahhh... OK, great. So, only one bug to fix... :-) Any news on this? I assume this should be trivial to fix when considering just the addresses where the modules get loaded to and the pointer is pointing to needs to be fixed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB error: unknown filesystem on ia64
Hi Daniel! On 3/26/21 7:01 PM, Daniel Kiper wrote: >> I have not bisected the issue yet, but maybe anyone has got any idea? > > May I ask you to do a bisect for us? The issue was introduced by this patch as discussed here [1]: From: Peter Jones Add a init_pe_section() helper function to setup PE sections. This makes the code simpler and easier to read. Signed-off-by: Peter Jones Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Kiper The address pointing to the modules within the GRUB core.img no longer matches the actual position of the modules. Hence, GRUB can't load the built-in modules anymore. Adrian > [1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00244.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 108/117] util/mkimage: Refactor section setup to use a helper
Hi Daniel! On 3/23/21 8:35 PM, Daniel Kiper wrote: >> Any chance someone could have a look at this? As explained in the follow-up >> mails, >> the problem is that the pointer pointing to the modules location in the core >> image >> deviate from the actual modules location as the former was updated but the >> former >> not. > > I chatted about that with Javier yesterday. He told me he will take > a look at the issue... Great, thanks. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 108/117] util/mkimage: Refactor section setup to use a helper
Hello! On 3/18/21 9:38 AM, John Paul Adrian Glaubitz wrote: > On 3/2/21 7:01 PM, Daniel Kiper wrote: >> From: Peter Jones >> >> Add a init_pe_section() helper function to setup PE sections. This makes >> the code simpler and easier to read. >> >> Signed-off-by: Peter Jones >> Signed-off-by: Javier Martinez Canillas >> Reviewed-by: Daniel Kiper > > This change broke GRUB on ia64 for me. It now fails to perform any basic > commands: Any chance someone could have a look at this? As explained in the follow-up mails, the problem is that the pointer pointing to the modules location in the core image deviate from the actual modules location as the former was updated but the former not. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 108/117] util/mkimage: Refactor section setup to use a helper
On 3/20/21 4:05 PM, John Paul Adrian Glaubitz wrote: > However, the modules are still located at the same address in memory which is > why > the module loader can no longer find them. And the new address where the loader is looking for the modules is located at 0x39000 but the modules are still located at 0x384E0. Thus, mkimage should be patched to move the modules to 39000 so that the loader can find them. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 108/117] util/mkimage: Refactor section setup to use a helper
Hello! On 3/18/21 9:38 AM, John Paul Adrian Glaubitz wrote: > This change broke GRUB on ia64 for me. It now fails to perform any basic > commands: > > Loading.: grub > Starting: grub > Welcome to GRUB! > > > > error: unknown filesystem. > Entering rescue mode... > grub rescue> insmod ext2 > error: unknown filesystem. > grub rescue> help > Unknown command `help'. > grub rescue> ? > Unknown command `?'. > grub rescue> linux > Unknown command `linux'. > grub rescue> The problem seems that the module loader tries to load the modules from the address mentioned in the PE header which has changed before this patch was introduced. However, the modules are still located at the same address in memory which is why the module loader can no longer find them. For reference, here is a hex diff of core.efi for the working and non-working builds (without and with the patch): --- grub-working.txt2021-03-20 15:45:43.788950935 +0100 +++ grub-broken.txt 2021-03-20 15:46:05.55451 +0100 @@ -25,10 +25,10 @@ 0180: 2e74 6578 7400 .text... 0190: 00e0 0100 0010 00e0 0100 0010 01a0: 2000 0060 ..` -01b0: 2e64 6174 6100 e094 0100 00f0 0100 .data... -01c0: e094 0100 00f0 0100 +01b0: 2e64 6174 6100 00a0 0100 00f0 0100 .data... +01c0: 00a0 0100 00f0 0100 01d0: 4000 00c0 6d6f 6473 @...mods -01e0: 206b e084 0300 206b e084 0300 k.. k.. +01e0: 0060 0090 0300 0060 0090 0300 .`...`.. 01f0: 4000 00c0 @... 0200: 2e72 656c 6f63 0010 00f0 0300 .reloc.. 0210: 0010 0000 00f0 0300 0000 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 108/117] util/mkimage: Refactor section setup to use a helper
Hi! On 3/2/21 7:01 PM, Daniel Kiper wrote: > From: Peter Jones > > Add a init_pe_section() helper function to setup PE sections. This makes > the code simpler and easier to read. > > Signed-off-by: Peter Jones > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Daniel Kiper This change broke GRUB on ia64 for me. It now fails to perform any basic commands: Loading.: grub Starting: grub Welcome to GRUB! error: unknown filesystem. Entering rescue mode... grub rescue> insmod ext2 error: unknown filesystem. grub rescue> help Unknown command `help'. grub rescue> ? Unknown command `?'. grub rescue> linux Unknown command `linux'. grub rescue> Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB error: unknown filesystem on ia64
Hello! It seems that one of the security patches has caused a regression on ia64 as GRUB is no longer able to load any basic commands: Loading.: grub Starting: grub Welcome to GRUB! error: unknown filesystem. Entering rescue mode... grub rescue> insmod ext2 error: unknown filesystem. grub rescue> help Unknown command `help'. grub rescue> ? Unknown command `?'. grub rescue> linux Unknown command `linux'. grub rescue> I have not bisected the issue yet, but maybe anyone has got any idea? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 116/117] templates: Disable the os-prober by default
Hi Daniel! On 3/3/21 8:38 PM, Daniel Kiper wrote: >> I'm not sure I'm able to follow the motivation to keep the naming scheme >> as is. >> >> If I have an option called "DISABLE_FEATURE_X", then I would expect setting >> it to "true" would mean that the feature is disabled not the other way >> around. > > Huh! I have just realized that we did not drop "if" change from earlier > version > of patch which also changed variable name. Interestingly doc update is > correct. > Anyway, sorry for the confusion. I asked Alex to post a fix for this. I'm glad we were able to resolve this. I was already questioning my sanity :D. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 116/117] templates: Disable the os-prober by default
Hi Daniel! On 3/3/21 2:13 PM, Daniel Kiper wrote: >> This is confusing: now to get boot entries from os-prober one have to >> set: >> GRUB_DISABLE_OS_PROBER=true >> in /etc/default/grub. >> >> Either revert that, or (better, in my opinion) label the variable >> GRUB_ENABLE_OS_PROBER and set it to false by default. > > When we worked on this patch we considered that. However, after some > thinking we stated that renaming to GRUB_ENABLE_OS_PROBER will make > more confusion. So, we decided to stick to existing name even if it > is not the best one. I'm not sure I'm able to follow the motivation to keep the naming scheme as is. If I have an option called "DISABLE_FEATURE_X", then I would expect setting it to "true" would mean that the feature is disabled not the other way around. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round
Hi Daniel! On 3/2/21 7:00 PM, Daniel Kiper wrote: > The BootHole vulnerability [1][2] announced last year encouraged many people > to > take a closer look at the security of boot process in general and the GRUB > bootloader in particular. Due to that, during past few months we were getting > reports of, and also discovering various security flaws in the GRUB ourselves. > You can find the list of most severe ones which got CVEs assigned at the end > of > this message. The patch bundle fixing all these issues in the upstream GRUB > contains 117 patches. Huge thanks and kudos to everyone involved fixing all these vulnerabilities! Given the amount of patches, wouldn't it make sense to push an RC candidate for 2.06 in the near future so that distributions can start shipping the pre- release and avoiding to carry this large amount of patches? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Collecting GRUB 2.06 test results
Hi Glenn! On 2/11/21 12:57 AM, Glenn Washburn wrote: > Ok, I'm glad you're running the tests on native hardware and in that > case I'm not surprised most of the qemu tests aren't running because I > assume that qemu is not on most of the non x86 platforms. Perhaps we > should have the tests show as SKIPPED when the appropriate qemu binary > can not be found. OK. I wasn't aware of that. >>> I'd like to note that it appears that these tests do not perform >>> most of the various filesystem tests. >> >> I ran the tests with "make check" (or "make test"), I did not make >> any modifications. If some tests were not run that's because GRUB does >> not enable them on the target in question. > > That's technically true, but not the whole story. GRUB is not enabling > the filesystem tests because you don't have your target environment > setup such that the tests will be enabled. The filesystem tests require > filesystem tools (eg. e2fsprogs for ext* fs tests). You might try > installing the prerequisites needed by the tests, and then seeing if > they run. I can re-run them with the fsprogs installed. Does that just concern e2fsprogs or other filesystems as well? >>> Also, I believe mips arch is not being tested here. And it appears >>> that none of the qemu tests for mipsle are being run due to not >>> having qemu for that arch installed. >> >> What do you mean by "here"? > > I mean that it appears to me that you don't have tests for the mips > arch, only mipsle. I'm not very familiar with mips, so I may be > confusing. My understanding is that there are big and little endian > variants of the mips architecture, and 32 vs 64 bit variants. I > understand mipsle to indicate the little-endian variant, but GRUB > supports the big endian variant as well. It seems to me that you only > have test logs for the 32 and 64 bit little endian variants. Right. I didn't test big-endian MIPS because it's not part of the Debian unstable distribution anymore (but Debian Buster). I will test big-endian in a second test run, I have access to a big-endian MIPS machine. >> You can see that by looking at the configure.ac. It's basically all >> targets that build more than just the utilities. > > Great, that's what I was thinking. I notice that it appears you're not > testing every supported target, just one target from each architecture. > For instance, you're not testing and i386 build of the ieee1275 or efi > platforms. Well, if ieee1275 or efi should be tested on i386, I think the testsuite should enable these tests by default. Although I'm not sure there is x86 hardware which uses OpenFirmware, is there? > Since you're not using qemu on the non-x86 platforms, I'm not sure if > testing the various platforms of other architectures would be worth > while (eg. arm-coreboot and arm-efi). Perhaps someone more > knowledgeable than I can weight in. I can also test with QEMU installed if desired for certain architectures. Maybe you could make a list of target/architecture combinations you want me to test. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Collecting GRUB 2.06 test results
Hello Glenn! On 2/10/21 8:21 PM, Glenn Washburn wrote: > Thanks for this these tests. Are you running these tests on the > same architecture that you're testing? Or, for instance, running the > tests for all architectures on say x86_64? Those were all tested on native hardware with a few exceptions: - 32-bit PowerPC tests were run on a 64-bit PowerPC machine - 32-bit MIPS tests were run on a 64-bit MIPS machine I do have an iBook G4 and could run the 32-bit PowerPC tests there. (Now I'm actually not sure anymore whether I ran the 32-bit PowerPC tests on the G4, but I can still do that. The machine is next to me, just currently powered off). > I'd like to note that it appears that these tests do not perform most > of the various filesystem tests. I ran the tests with "make check" (or "make test"), I did not make any modifications. If some tests were not run that's because GRUB does not enable them on the target in question. > Also, I believe mips arch is not being tested here. And it appears that > none of the qemu tests for mipsle are being run due to not having qemu > for that arch installed. What do you mean by "here"? > None of the qemu tests are being run for most of the architectures (I > also haven't figured out how to get them to run on most architectures). > But I have gotten the qemu tests to run for arm and arm64, which they > are not running in your tests. What is especially odd, is that for > armhf grub-shell is looking for 'qemu-system-i386' and not finding it. > But it should be looking for the arm qemu variant. > > For completeness, The risc architecture is not being tested either. Yes, > I know most tests fail because of a bug. Are we considering it an > unsupported platform because its unusable, even though it can be built? I currently do not have access to a RISC-V machine yet. I have preordered one and also applied for a developer machine from SiFive, but I haven't gotten any yet. > Where is the list of architectures "supported" by GRUB? Or is it all > the ones allowed to be built by master? You can see that by looking at the configure.ac. It's basically all targets that build more than just the utilities. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: need hostname on menu
On 1/24/21 12:26 PM, Humphrey van Polanen Petel wrote: > Okay, I get it. > > I defer to your decision. I did not make any decisions as I'm not in charge of GRUB, I'm just a contributing developer. I merely stated my opinion and pointed out some problems with your suggestion. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: need hostname on menu
Hello! On 1/24/21 4:32 AM, Humphrey van Polanen Petel wrote: > Whether it is a trivial problem or not I am not qualified to comment on, but > it > nevertheless seems to me that being able to identify at boot a systemby the > name > by which it is know is of obvious benefit simply because mnemonics are most > easily > remembered. I was not arguing this point. I was just talking about the development and maintenance effort. > And if you wish to call this a "rather exotic problem" then I would like to > point out > that it is not up to the developers, but to the users to determine how they > use their > system. No developer is telling you how to use the software, that's not my point but that someone has to implement the feature and maintain it and that person is the developer. So while the developer does not get to tell you how you use the software, he decides what he works on and what not. And if there is a feature that is requested by only a very small amount of users, then it usually makes no sense to put up with the additional development and maintenance burden. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: need hostname on menu
Hello! On 1/24/21 1:52 AM, Humphrey van Polanen Petel wrote: > However, it seems to me that it would be a lot more useful to add a parameter > allowing the user to display the name of the install from /etc/hostname. GRUB is a universal bootloader which supports multiple platforms and operating systems. I'm not sure it would be trivial to implement such a feature for all possible target configurations that GRUB support just to solve this rather exotic problem you are describing here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Collecting GRUB 2.06 test results
Hello! On 1/4/21 4:24 PM, John Paul Adrian Glaubitz wrote: > I have started to collect test results for GRUB 2.06 here: > >> https://people.debian.org/~glaubitz/grub2.06-test-results/ Just as a heads-up: I have collected test results for all architectures supported by GRUB. I have also verified GRUB works correctly on sparc64, I might perform full tests on other architectures later. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Collecting GRUB 2.06 test results
Hi! I have started to collect test results for GRUB 2.06 here: > https://people.debian.org/~glaubitz/grub2.06-test-results/ The results are for 635ef55ed1252f92fe3bf70caefd185dcc507c43. If there is a testsuite result, it also obviously means the build passed without any problems. I have also already successfully installed and boot from this git version on Debian sparc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: failing tests on sparc64-ieee1275 target
Hello! On 12/19/20 7:29 AM, Glenn Washburn wrote: > I'm running the sparc tests and running into some odd failures. Is > anyone running these tests successfully? I've attached the > test-suite.log which shows a bash trace of each failing test. There are > many failing fs tests with hard errors, those can be ignored. The last > 4 tests are the pertinent ones. Also included are the qemu output files. > I'll discuss briefly each failing test below in the order which they > appear in the log file. I don't think we're running the tests on anything besides x86 in Debian, but you can check the build logs here: > https://buildd.debian.org/status/package.php?p=grub2=sid To view a build log, click on any entry in the "Status" column. FWIW, we're deploying GRUB on Debian/sparc64 without any issues both for installation media and hard disks. If you want, you can run the tests on real hardware through the GCC compile farm [1]. Adrian > [1] https://gcc.gnu.org/wiki/CompileFarm -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06 release
Hi Daniel! On 12/14/20 1:39 PM, Daniel Kiper wrote: > Huh... This took longer than I wanted to. Anyway, I am going to cut > 2.06-rc1 by the of this week. So, this is the final call to say what is > missing in current master. I am going to take only critical code fixes > after RC. Documentation, tests, etc. changes still will be welcome. Great! Kudos and thanks to everyone who has contributed to this effort! Let me know when you want me to run some basic tests on all Debian targets. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
