Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Hi, Florian Pelz wrote: > This is not an install ISO but a USB install medium. The USB drive > was written by the Windows Media Creation Tool. Copying instead a > Windows ISO created by the Windows Media Creation Tool to a USB drive > does *not* yield a bootable USB drive; it does not even boot on other > computers. This would bring the MS-World back in sync with my understanding of UEFI specs and other info sources. But there are substantial rumors that the ISO boots from USB stick. Microsoft is said to advertise it for DVD+R DL and USB stick. (I could not get my hands on ISO or advertising yet ...) Whatever, if your USB stick has an EFI partition, then you could try to spoil it for your Macbook by writing the partition slot or the whole partition table. The byte offsets like 446 or 454 are counted from the start of the EFI partition. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
On Fri, May 10, 2019 at 03:46:56PM +0200, Thomas Schmitt wrote: > Hi, > > Florian Pelz wrote: > > I would like to test but on this bootable German Windows 10 > > 32-bit+64-bit USB install medium, the content is different. How would > > I find the offset in the USB image (you call it offset 454) which I > > should zero out to break Windows? > > That would be offset 454 in the EFI boot image: Start LBA field of MBR > partition 1. > > You may learn the block address of the image from xorriso: > > xorriso -indev "$ISO" -report_el_torito plain 2>/dev/null \ > | grep 'El Torito boot img : .* UEFI' > > should say something like > > El Torito boot img : 2 UEFI y none 0x 0x00 1 515 > This is not an install ISO but a USB install medium. The USB drive was written by the Windows Media Creation Tool. Copying instead a Windows ISO created by the Windows Media Creation Tool to a USB drive does *not* yield a bootable USB drive; it does not even boot on other computers. So mine is a USB drive already, not an ISO image. I do: $ sudo xorriso -indev "stdio:/dev/sdb" -report_el_torito plain GNU xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 libisoburn: WARNING : No ISO 9660 image at LBA 0. Creating blank image. Drive current: -indev 'stdio:/dev/sdb' Media current: stdio file, overwriteable Media status : is written , is closed Media summary: 1 session, 3932160 data blocks, 7680m data, 0 free Volume id: 'ISOIMAGE' xorriso : NOTE : No El Torito information was loaded Apparently it is wrong to look at such Windows 10 USB media and I should rather look at older Windows installation media. I will try to procure a Windows 7 install ISO. I will report back tomorrow. Regards, Florian ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Hi, Florian Pelz wrote: > I would like to test but on this bootable German Windows 10 > 32-bit+64-bit USB install medium, the content is different. How would > I find the offset in the USB image (you call it offset 454) which I > should zero out to break Windows? That would be offset 454 in the EFI boot image: Start LBA field of MBR partition 1. You may learn the block address of the image from xorriso: xorriso -indev "$ISO" -report_el_torito plain 2>/dev/null \ | grep 'El Torito boot img : .* UEFI' should say something like El Torito boot img : 2 UEFI y none 0x 0x00 1 515 The last number 515 is the 2048-byte block address of the EFI image. (That's from the japanese ISO mentioned at debian-user.) If you write four zero bytes at byte 515 * 2048 + 454 = 1055174, then there is start LBA 0 in the slot of partition 1. This should trigger the stalled boot process of the Macbook. But maybe the other bytes from 446 to 461 hamper recognition as partition table entry. So more similar to the mformat image would be to zeroize bytes 446 to 509 to clear the partition table, and then to write to bytes 446 to 461 what we see as partition slot 1 in the grub-mkrescue EFI partition: 80 00 01 00 01 01 12 4f 00 00 00 00 40 0b 00 00 - If you are at it, i'd like to see a confirmation that the ISO indeed boots via El Torito from USB stick. (Interesting for GRUB as background info.) Please in the end spoil El Torito by zeroizing the address of the Boot Catalog in the Boot Record at 2048-byte block 17 (decimal). Byte offset 71 to 74, little endian. The ISO hexdumped by Chris Murphy has 0x0016 = 22 : 8840 00 00 00 00 00 00 00 16 00 00 00 00 00 00 00 00 So dd if=/dev/zero bs=1 count=4 seek=34887 conv=notrunc of="$ISO" You will probably see error messages when inspecting by software. Like $ xorriso -indev "$ISO" -report_el_torito plain ... libisofs: WARNING : Wrong or damaged El-Torito Catalog. El-Torito info will be ignored. Or a clueless assessment without checking the catalog signature: $ isoinfo -d -i "$ISO" ... El Torito VD version 1 found, boot catalog is in sector 0 ... Eltorito validation header: Hid 0 Arch 0 (x86) ID '' Key 0 0 Eltorito defaultboot header: Bootid 0 (not bootable) Boot media 0 (No Emulation Boot) Load segment 0 Sys type 0 Nsect 0 Bootoff 0 0 This is still less intrusive than trying to remove the Boot Record or to camouflage it as something else. If my theory is right, then EFI should not recognize the USB stick as a device with EFI partition any more. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] video: skip 'text' gfxpayload if not supported, to fallback to default
On 10/05/2019 15:24, Mathieu Trudel-Lapierre wrote: > On Fri, May 10, 2019 at 7:52 AM Didier Spaier wrote: >> >> On 10/05/2019 13:38, Daniel Kiper wrote: >>> On Mon, Apr 29, 2019 at 01:57:02PM -0400, Mathieu Trudel-Lapierre wrote: On UEFI, 'text' gfxpayload is not supported, but we still reach parse_modespec with it, which will obviously fail. Fortunately, whatever gfxpayload is set, we still still have the 'auto' default to fall back to. Allow getting to this fallback by not trying to parse 'text' as a modespec. This is because 'text' correctly doesn't parse as a modespec, and ought to have been ignored before we got to that point, just like it is immediately picked if we're running on a system where 'text' is a supported video mode. >> >> As an aside, in a grub.cfg intended for both legacy and UEFI booting, can I >> condition setting either 'vga=normal' or 'gfxpayload=text' depending on the >> context detected by grub? If yes, how? >> > > In grub.cfg; you can check if you're on the right platform by checking > > $grub_platform > > On UEFI, it will read "efi". Thanks! ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] video: skip 'text' gfxpayload if not supported, to fallback to default
On Fri, May 10, 2019 at 7:52 AM Didier Spaier wrote: > > On 10/05/2019 13:38, Daniel Kiper wrote: > > On Mon, Apr 29, 2019 at 01:57:02PM -0400, Mathieu Trudel-Lapierre wrote: > >> On UEFI, 'text' gfxpayload is not supported, but we still reach > >> parse_modespec > >> with it, which will obviously fail. Fortunately, whatever gfxpayload is > >> set, > >> we still still have the 'auto' default to fall back to. Allow getting to > >> this > >> fallback by not trying to parse 'text' as a modespec. > >> > >> This is because 'text' correctly doesn't parse as a modespec, and ought to > >> have > >> been ignored before we got to that point, just like it is immediately > >> picked if > >> we're running on a system where 'text' is a supported video mode. > > As an aside, in a grub.cfg intended for both legacy and UEFI booting, can I > condition setting either 'vga=normal' or 'gfxpayload=text' depending on the > context detected by grub? If yes, how? > In grub.cfg; you can check if you're on the right platform by checking $grub_platform On UEFI, it will read "efi". -- Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
On Fri, May 10, 2019 at 09:09:25AM +0200, Thomas Schmitt wrote: > The firmware of the affected Macbook probably tolerates everything > except four zeros at byte offset 454 (here: 0x1039c6), where Microsoft > has 20 61 6e 64. I would like to test but on this bootable German Windows 10 32-bit+64-bit USB install medium, the content is different. How would I find the offset in the USB image (you call it offset 454) which I should zero out to break Windows? Regards, Florian ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v3] probe: Support probing for GPT partition UUID with -q
Linux supports root=PARTUUID= boot argument, so add
support for probing it. Compared to the fs UUID, the partition
UUID does not change when reformatting a partition.
Signed-off-by: Jacob Kroon
---
grub-core/commands/probe.c | 35 +++
1 file changed, 35 insertions(+)
Changes since v2:
* Add a proper commit message
* Handle endianess in the same way as is currently done in
util/grub-probe.c:print_gpt_guid ()
diff --git a/grub-core/commands/probe.c b/grub-core/commands/probe.c
index 95d272287..24742c181 100644
--- a/grub-core/commands/probe.c
+++ b/grub-core/commands/probe.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,7 @@ static const struct grub_arg_option options[] =
{"fs", 'f', 0, N_("Determine filesystem type."), 0, 0},
{"fs-uuid",'u', 0, N_("Determine filesystem UUID."), 0, 0},
{"label", 'l', 0, N_("Determine filesystem label."), 0, 0},
+{"partuuid", 'q', 0, N_("Determine GPT partition uuid."), 0, 0},
{0, 0, 0, 0, 0, 0}
};
@@ -98,6 +100,39 @@ grub_cmd_probe (grub_extcmd_context_t ctxt, int argc, char
**args)
grub_device_close (dev);
return GRUB_ERR_NONE;
}
+ if (state[6].set)
+{
+ /* ---- + null terminator */
+ char val[37] = "none";
+ if (dev->disk && dev->disk->partition &&
+ grub_strcmp(dev->disk->partition->partmap->name, "gpt") == 0)
+ {
+ struct grub_gpt_partentry entry;
+ struct grub_partition *p = dev->disk->partition;
+ grub_disk_t disk = grub_disk_open(dev->disk->name);
+ if (!disk)
+ return grub_errno;
+ if (grub_disk_read(disk, p->offset, p->index, sizeof(entry), ))
+ return grub_errno;
+ grub_disk_close(disk);
+ grub_gpt_part_guid_t *guid =
+ guid->data1 = grub_le_to_cpu32 (guid->data1);
+ guid->data2 = grub_le_to_cpu16 (guid->data2);
+ guid->data3 = grub_le_to_cpu16 (guid->data3);
+ grub_snprintf (val, sizeof(val),
+"%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
+guid->data1, guid->data2, guid->data3, guid->data4[0],
+guid->data4[1], guid->data4[2], guid->data4[3],
+guid->data4[4], guid->data4[5], guid->data4[6],
+guid->data4[7]);
+ }
+ if (state[0].set)
+ grub_env_set (state[0].arg, val);
+ else
+ grub_printf ("%s", val);
+ grub_device_close (dev);
+ return GRUB_ERR_NONE;
+}
fs = grub_fs_probe (dev);
if (! fs)
return grub_errno;
--
2.20.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] video: skip 'text' gfxpayload if not supported, to fallback to default
On 10/05/2019 13:38, Daniel Kiper wrote: > On Mon, Apr 29, 2019 at 01:57:02PM -0400, Mathieu Trudel-Lapierre wrote: >> On UEFI, 'text' gfxpayload is not supported, but we still reach >> parse_modespec >> with it, which will obviously fail. Fortunately, whatever gfxpayload is set, >> we still still have the 'auto' default to fall back to. Allow getting to this >> fallback by not trying to parse 'text' as a modespec. >> >> This is because 'text' correctly doesn't parse as a modespec, and ought to >> have >> been ignored before we got to that point, just like it is immediately picked >> if >> we're running on a system where 'text' is a supported video mode. As an aside, in a grub.cfg intended for both legacy and UEFI booting, can I condition setting either 'vga=normal' or 'gfxpayload=text' depending on the context detected by grub? If yes, how? Best, Didier ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] probe: Support probing for GPT partition uuid with -q
On Fri, May 10, 2019 at 12:33 PM Daniel Kiper wrote: > > On Wed, May 08, 2019 at 08:51:40AM +0200, Jacob Kroon wrote: > > Signed-off-by: Jacob Kroon > > --- > > grub-core/commands/probe.c | 32 > > 1 file changed, 32 insertions(+) > > Could you explain in the commit message why this patch is needed? > Will do, I think I also need to fix endianess handling, so I'll send a v3. /Jacob ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix error message about the wrong command having failed: mformat instead of mcopy
Hello, > May I add your SOB? If yes then Reviewed-by: Daniel Kiper > Yes, and sorry to have forgotten to add it -- Vincent Legoll ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix error message about the wrong command having failed: mformat instead of mcopy
On Sun, Apr 28, 2019 at 01:21:49AM +0200, Vincent Legoll wrote:
> ---
> util/grub-mkrescue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
> index 21e5ce4e4..ce2cbc4f1 100644
> --- a/util/grub-mkrescue.c
> +++ b/util/grub-mkrescue.c
> @@ -815,7 +815,7 @@ main (int argc, char *argv[])
> grub_util_error ("`%s` invocation failed\n", "mformat");
>rv = grub_util_exec ((const char * []) { "mcopy", "-s", "-i",
> efiimgfat, efidir_efi, "::/", NULL });
>if (rv != 0)
> - grub_util_error ("`%s` invocation failed\n", "mformat");
> + grub_util_error ("`%s` invocation failed\n", "mcopy");
>xorriso_push ("--efi-boot");
>xorriso_push ("efi.img");
>xorriso_push ("-efi-boot-part");
May I add your SOB? If yes then Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] video: skip 'text' gfxpayload if not supported, to fallback to default
On Mon, Apr 29, 2019 at 01:57:02PM -0400, Mathieu Trudel-Lapierre wrote: > On UEFI, 'text' gfxpayload is not supported, but we still reach parse_modespec > with it, which will obviously fail. Fortunately, whatever gfxpayload is set, > we still still have the 'auto' default to fall back to. Allow getting to this > fallback by not trying to parse 'text' as a modespec. > > This is because 'text' correctly doesn't parse as a modespec, and ought to > have > been ignored before we got to that point, just like it is immediately picked > if > we're running on a system where 'text' is a supported video mode. > > Bug: https://savannah.gnu.org/bugs/index.php?56217 > > Signed-off-by: Mathieu Trudel-Lapierre Reviewed-by: Daniel Kiper If there are no objections I will push it next week. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH requesting feedback] resuce: allow disabling of the grub resuce shell
On Thu, May 02, 2019 at 12:06:56AM +0200, andr...@rammhold.de wrote: > From: Andreas Rammhold > > Kindly requesting your feedback on the below diff. > > In some setups it might be desirable to disable access to the grub > rescue shell. One of those environments is when your all your > filesystems - besides a small EFI partition - are encrypted and you are > using secure boot to restrict the payloads that UEFI accepts. I am OK with the idea but the patch requires polishing and maybe splitting into two or more. And certainly it is not a release material. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
On 5/10/19 12:22 PM, Daniel Kiper wrote: > How long it will take? I do not want to hold release any longer. If you actually want to release within the next days now, I'm okay with postponing this for the next release or an upcoming fix release. I have not performed enough tests to know whether ofpathname's different behavior here is specific to PowerMacs or PowerPC in general, i.e. I will have to test that on the IBM CHRP machines we have in Debian. Maybe the tool has only been tested on SPARC ever. > And I would like to hear Eric's opinion here. Sure. 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 0/8] Travis fixes
On Thu, May 02, 2019 at 08:55:29AM +0200, Alexander Graf wrote: > This patch set collects a few fixes for Travis CI since the initial > commit was applied: > > - catch up with the tree > - fix targets that need a board specified > - make mkimage loop more robust > - add QEMU tests for ARM and AArch64 EFI targets > - add ARM Thumb mode tests > - verify that on demand module and config loading from TFTP works > > That way we should hopefully catch even more problems going forward. > > v1 -> v2: > > - add ARM Thumb mode tests > - verify that on demand module and config loading from TFTP works > - use local gnulib (saves ~3m git checkout time) > > Alexander Graf (8): > travis: Run bootstrap instead of autogen.sh > travis: Fix sparc64 test > travis: Fix mips QEMU target > travis: Fix arm coreboot test and make loop more robus > arm coreboot: Use common directory path > travis: Add smoke tests for arm and aarch64 > travis: Add ARM thumb target to tests > travis: Test module loading from tftp as well > > .travis.yml| 45 + > util/mkimage.c | 4 ++-- > 2 files changed, 39 insertions(+), 10 deletions(-) Except two patches you can add Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 8/8] travis: Test module loading from tftp as well
On Thu, May 02, 2019 at 08:55:37AM +0200, Alexander Graf wrote: > The travis test today only uses modules that are delivered with the > grub.efi binary. Let's drop echo and reboot and see if grub can load > them dynamically. > > For this, we need to ensure that all modules required to load additional > modules are included in the grub binary. Some of these are target > specific (like efinet), so only include them conditionally. > > Furthermore, the iPXE option rom included in Ubuntu Xenial seems to be > broken, so we need to ensure that we only use the OVMF built-in network > driver and not pass in an option rom. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - new patch > --- > .travis.yml | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/.travis.yml b/.travis.yml > index d8f6170e6..9bed42ac5 100644 > --- a/.travis.yml > +++ b/.travis.yml > @@ -67,15 +67,27 @@ script: > done > ># Our test canary. > - - echo -e "insmod echo\\ninsmod reboot\\necho hello world\\nreboot" > > grub.cfg > + - echo -e "insmod echo\\ninsmod reboot\\necho hello world\\nreboot" > > /tmp/grub/lib/grub/grub.cfg > ># Assemble images and possibly run them. > - - ( for target in $GRUB_TARGETS; do grub-mkimage -c grub.cfg -p / -O > $target -o grub-$target echo reboot normal || exit; done ) > + - ( for target in $GRUB_TARGETS; do > +pushd /tmp/grub/lib/grub/; > +if [ -f $target/efinet.mod ]; then > + EXTMODULES="efinet"; > +else > + EXTMODULES=""; > +fi; > +grub-mkimage -p / -O $target -o grub-$target normal tftp $EXTMODULES > || exit; > +popd; > + done ) > ># Run images we know how to run. > - - if [[ "$GRUB_TARGETS" == *"x86_64-efi"* ]]; then qemu-system-x86_64 > -bios /usr/share/ovmf/OVMF.fd -m 512 -no-reboot > -nographic -net nic -net user,tftp=.,bootfile=grub-x86_64-efi | tee grub.log > && grep "hello world" grub.log; fi > - - if [[ "$GRUB_TARGETS" == *"arm64-efi"* ]]; then qemu-system-aarch64 -M > virt -cpu cortex-a57 -bios QEMU_EFI.aarch64.fd -m 512 -no-reboot > -nographic -net nic -net user,tftp=.,bootfile=grub-arm64-efi | tee grub.log > && grep "hello world" grub.log; fi > - - if [[ "$GRUB_TARGETS" == *"arm-efi"* ]];then qemu-system-arm -M > virt -cpu cortex-a15 -bios QEMU_EFI.arm.fd -m 512 -no-reboot > -nographic -net nic -net user,tftp=.,bootfile=grub-arm-efi| tee grub.log > && grep "hello world" grub.log; fi > + - if [[ "$GRUB_TARGETS" == *"x86_64-efi"* ]]; then qemu-system-x86_64 > -bios /usr/share/ovmf/OVMF.fd > + -m 512 -no-reboot -nographic -net none -netdev > user,id=nd,tftp=/tmp/grub/lib/grub/,bootfile=grub-x86_64-efi -device > virtio-net-pci,netdev=nd,romfile="" | tee grub.log && grep "hello world" > grub.log; fi > + - if [[ "$GRUB_TARGETS" == *"arm64-efi"* ]]; then qemu-system-aarch64 -M > virt -cpu cortex-a57 -bios QEMU_EFI.aarch64.fd > + -m 512 -no-reboot -nographic -net none -netdev > user,id=nd,tftp=/tmp/grub/lib/grub/,bootfile=grub-arm64-efi -device > virtio-net-pci,netdev=nd,romfile="" | tee grub.log && grep "hello world" > grub.log; fi > + - if [[ "$GRUB_TARGETS" == *"arm-efi"* ]];then qemu-system-arm -M > virt -cpu cortex-a15 -bios QEMU_EFI.arm.fd > + -m 512 -no-reboot -nographic -net none -netdev > user,id=nd,tftp=/tmp/grub/lib/grub/,bootfile=grub-arm-efi-device > virtio-net-pci,netdev=nd,romfile="" | tee grub.log && grep "hello world" > grub.log; fi I am not sure why you do not use grep directly on the output. Could you drop tee? If yes please drop it from all commands. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: gcc9.1 and f2fs
CC-ing Michael. On Wed, May 08, 2019 at 02:09:17AM +0100, Neil MacLeod wrote: > Sorry, wrong patch in previous email - this is the one for grub! > > Neil > > On Wed, 8 May 2019 at 01:51, Neil MacLeod wrote: > > > > Adrian > > > > I used the attached patch and grub is now building for me with gcc-9.1. > > > > I've no idea if this is the right solution, but it does at least work > > (ie. builds) which is all I require for now as I'm not personally > > using grub in the distribution I'm building (LibreELEC) and can't > > actually say if it works at run-time. > > > > Many thanks > > Neil > > > > > > On Mon, 6 May 2019 at 20:58, Neil MacLeod wrote: > > > > > > Hi Adrian > > > > > > With your patch, grub now fails to build as follows: > > > > > > fs/f2fs.c: In function 'grub_f2fs_get_block': > > > fs/f2fs.c:864:43: error: 'offset' may be used uninitialized in this > > > function [-Werror=maybe-uninitialized] > > > 864 | return grub_le_to_cpu32 (inode->i_addr[offset[0]]); > > > | ^ > > > cc1: all warnings being treated as errors > > > make[4]: *** [Makefile:33773: fs/f2fs_module-f2fs.o] Error 1 > > > > > > This is the last 1000 lines of the build log with your patch applied: > > > http://ix.io/1IfE > > > > > > And this is the f2fs.c used for the compilation (it includes your > > > patch): http://ix.io/1IfC > > > > > > Many thanks > > > Neil > > > > > > On Mon, 6 May 2019 at 19:19, Neil MacLeod wrote: > > > > > > > > Thanks Adrian - testing with your patch now, will be another hour or > > > > so until the build is complete (cross-compiling environment with own > > > > toolchain etc.) > > > > > > > > Just a correction, I'm testing with > > > > 4dd4ceec023111a4ccf69f8de6fa0885c6847a35 (current HEAD) - looks like I > > > > cut & pasted a rev from a different repo in my original post! > > > > > > > > Regards > > > > Neil > > > > > > > > On Mon, 6 May 2019 at 18:59, John Paul Adrian Glaubitz > > > > wrote: > > > > > > > > > > On 5/6/19 7:15 PM, Neil MacLeod wrote: > > > > > > Does anyone have a patch? > > > > > > > > > > Try the attached patch. I am afraid that we have two issues here. May I ask one of you to reinvestigate them and post proper fix(es)? And this is clearly release material. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/8] travis: Run bootstrap instead of autogen.sh
On Thu, May 02, 2019 at 08:55:30AM +0200, Alexander Graf wrote:
> Commit 35b909062e7b3 ("gnulib: Upgrade Gnulib and switch to bootstrap tool")
> changed the build flow from running ./autogen.sh to running ./bootstrap
> but missed to update .travis.yml. Adapt it accordingly.
>
> Fixes: 35b909062e7b3 ("gnulib: Upgrade Gnulib and switch to bootstrap tool")
> Signed-off-by: Alexander Graf
>
> ---
>
> v1 -> v2:
>
> - use local gnulib copy (saves ~3m git checkout time)
> ---
> .travis.yml | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 81de20fa3..6b8f97830 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -18,6 +18,7 @@ addons:
> - python
> - qemu-system
> - unifont
> +- gnulib
>
> env:
>global:
> @@ -35,7 +36,11 @@ before_script:
> script:
># Comments must be outside the command strings below, or the Travis parser
># will get confused.
> - - ./autogen.sh
> +
> + # The Ubuntu gnulib does not compile with gcc8, so only use it with the
> system compiler
> + - if [ ! "$CROSS_TARGETS" ]; then rm -rf gnulib; ln -s /usr/share/gnulib;
> fi
I would not depend on it at all. Could you drop this and gnulib package
addition above?
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] probe: Support probing for GPT partition uuid with -q
On Wed, May 08, 2019 at 08:51:40AM +0200, Jacob Kroon wrote: > Signed-off-by: Jacob Kroon > --- > grub-core/commands/probe.c | 32 > 1 file changed, 32 insertions(+) Could you explain in the commit message why this patch is needed? Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Extend grub-ofpathname to behaves like yaboot/ofpath on PowerPC system
CC-ing Eric. On Wed, May 08, 2019 at 10:10:35PM +0200, John Paul Adrian Glaubitz wrote: > On 5/3/19 9:57 AM, John Paul Adrian Glaubitz wrote: > >> We also do understand that name can be safely omitted as the device is > >> actually getting located by > >> its address. Therefore, these two paths refer to the same device: > >> > >> /pci@f400/ata-6@d/disk@0:b > >> > >> /@f400/@d/@0:b > >> > >> However for the PowerMac we tested it on, only the second form has > >> been found to be accepted. > > > > Thanks for the detailed explanation and for investigating this! Much > > appreciated. > > > >> How best should we provide you with a patch (the current one is kind > >> of a hack)? Should we extend grub-ofpathname to take a new parameter > >> (eg. `--omit-names`) and decide to print or not the name, would that > >> be acceptable ? > > > > This sounds like a very reasonable approach. Let's use either that or > > maybe query OpenFirmware whether we're running on a PowerMac, if that's > > somehow possible. > > Any comments from Daniel or Vladimir? Would be great to get this fixed > before the 2.04 release comes out. GRUB itself works perfectly fine on > PowerMacs but due to the grub-ofpathname tool being unreliable, we currently > need to rely on external tools to determine the proper open firmware device > path. How long it will take? I do not want to hold release any longer. And I would like to hear Eric's opinion here. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Hi, iwrote: > What do you get as hex dump of byte 1,062,912 to 1,063,423 ? I found the answer in the hex dump: 00103800 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 01 01 00 |.<.MSDOS5.0.| 00103810 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |...@| 00103820 00 00 00 00 00 00 29 c0 56 ef 00 45 46 49 53 45 |..).V..EFISE| 00103830 43 54 4f 52 20 20 46 41 54 31 32 20 20 20 fa 33 |CTOR FAT12 .3| 00103840 c0 8e d0 bc 00 7c 16 07 bb 78 00 36 c5 37 1e 56 |.|...x.6.7.V| 00103850 16 53 bf 3e 7c b9 0b 00 fc f3 a4 06 1f c6 45 fe |.S.>|.E.| 00103860 0f 8b 0e 18 7c 88 4d f9 89 47 02 c7 07 3e 7c fb ||.M..G...>|.| 00103870 cd 13 72 79 33 c0 39 06 13 7c 74 08 8b 0e 13 7c |..ry3.9..|t|| 00103880 89 0e 20 7c a0 10 7c f7 26 16 7c 03 06 1c 7c 13 |.. |..|.&.|...|.| 00103890 16 1e 7c 03 06 0e 7c 83 d2 00 a3 50 7c 89 16 52 |..|...|P|..R| 001038a0 7c a3 49 7c 89 16 4b 7c b8 20 00 f7 26 11 7c 8b ||.I|..K|. ..&.|.| 001038b0 1e 0b 7c 03 c3 48 f7 f3 01 06 49 7c 83 16 4b 7c |..|..HI|..K|| 001038c0 00 bb 00 05 8b 16 52 7c a1 50 7c e8 92 00 72 1d |..R|.P|...r.| 001038d0 b0 01 e8 ac 00 72 16 8b fb b9 0b 00 be e6 7d f3 |.r}.| 001038e0 a6 75 0a 8d 7f 20 b9 0b 00 f3 a6 74 18 be 9e 7d |.u... .t...}| 001038f0 e8 5f 00 33 c0 cd 16 5e 1f 8f 04 8f 44 02 cd 19 |._.3...^D...| 00103900 58 58 58 eb e8 8b 47 1a 48 48 8a 1e 0d 7c 32 ff |XXX...G.HH...|2.| 00103910 f7 e3 03 06 49 7c 13 16 4b 7c bb 00 07 b9 03 00 |I|..K|..| 00103920 50 52 51 e8 3a 00 72 d8 b0 01 e8 54 00 59 5a 58 |PRQ.:.rT.YZX| 00103930 72 bb 05 01 00 83 d2 00 03 1e 0b 7c e2 e2 8a 2e |r..|| 00103940 15 7c 8a 16 24 7c 8b 1e 49 7c a1 4b 7c ea 00 00 |.|..$|..I|.K|...| 00103950 70 00 ac 0a c0 74 29 b4 0e bb 07 00 cd 10 eb f2 |pt).| 00103960 3b 16 18 7c 73 19 f7 36 18 7c fe c2 88 16 4f 7c |;..|s..6.|O|| 00103970 33 d2 f7 36 1a 7c 88 16 25 7c a3 4d 7c f8 c3 f9 |3..6.|..%|.M|...| 00103980 c3 b4 02 8b 16 4d 7c b1 06 d2 e6 0a 36 4f 7c 8b |.M|.6O|.| 00103990 ca 86 e9 8a 16 24 7c 8a 36 25 7c cd 13 c3 0d 0a |.$|.6%|.| 001039a0 4e 6f 6e 2d 53 79 73 74 65 6d 20 64 69 73 6b 20 |Non-System disk | 001039b0 6f 72 20 64 69 73 6b 20 65 72 72 6f 72 0d 0a 52 |or disk error..R| 001039c0 65 70 6c 61 63 65 20 61 6e 64 20 70 72 65 73 73 |eplace and press| 001039d0 20 61 6e 79 20 6b 65 79 20 77 68 65 6e 20 72 65 | any key when re| 001039e0 61 64 79 0d 0a 00 49 4f 20 20 20 20 20 20 53 59 |ady...IO SY| 001039f0 53 4d 53 44 4f 53 20 20 20 53 59 53 00 00 55 aa |SMSDOS SYS..U.| An MBR signature 55 aa. But cleartext where the partition table should be. If Microsoft ISOs shall really be considered standard, then any kind of garbage is ok in a potential partition table at the start of the EFI partition. The firmware of the affected Macbook probably tolerates everything except four zeros at byte offset 454 (here: 0x1039c6), where Microsoft has 20 61 6e 64. (It feels like two cars speeding on a salt lake. Probability for collision is low. Just close your eyes and trust in your luck.) Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Hi, Chris Murphy wrote: > [Microsoft image CCCOMA_X64FRE_JA-JP_DV9] > b040 91 ef 01 00 00 00 00 00 00 00 00 00 00 00 00 00 | > b050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > b060 88 00 00 00 00 00 01 00 07 02 00 00 00 00 00 00 | It comes to me that i forgot to ask for a look into the EFI partition at 2048-bye block address 0x0207 = 519. What do you get as hex dump of byte 1,062,912 to 1,063,423 ? Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
