On 5/11/19 8:07 AM, John Paul Adrian Glaubitz wrote:
>> If you find some time, I think it would be interesting if we had a
>> grub-boot test image where BootX is using:
>>
>>
>> boot &device;:,\System\Library\CoreServices\grub.elf
>>
>>
>> I suspect Apple users would then be able to "properly" bo
CC-ing GRUB upstream.
The context are the new Debian installation ISOs which are now using GRUB
instead of Yaboot for booting the installer.
The debian-cd script which generates the ISO image with xorriso can be found
here:
> https://salsa.debian.org/images-team/debian-cd/blob/master/tools/boot/
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 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) w
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
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 reac
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 obviousl
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-b
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
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
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 com
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
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-mkres
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 ge
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
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 of
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 a
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 addition
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-
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
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
__
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 re
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
23 matches
Mail list logo
