On Thu, Jun 22, 2023 at 3:00 PM Tobias Powalowski via Grub-devel
wrote:
>
> Hi,
> just curious since the patchset from 25.05.2023, I cannot use Secure Boot on
> my project anymore. The kernel hash cannot be validated anymore and shim
> bails out with bad shim signature.
> Any help would be appre
On Wed, Jun 14, 2023 at 5:17 PM Daniel Kiper wrote:
>
> On Mon, Jun 12, 2023 at 10:53:09PM +0200, Robin Candau wrote:
> > Le 12/06/2023 à 21:05, Daniel Kiper a écrit :
> > > On Mon, Jun 12, 2023 at 07:19:53PM +0200, Christian Hesse wrote:
> > > > Ard Biesheuvel on Tue, 2023/05/23 17:31:
> > > > >
On Sat, Mar 20, 2021 at 1:22 AM Colin Watson wrote:
>
> This function is only used by gfxmenu. Moving it there is unfortunately
> a bit messy, but it frees up a fairly substantial amount (in relative
> terms) of precious core image space on i386-pc.
>
> DOWN: obj/i386-pc/grub-core/kernel.img (3
On Mon, Mar 8, 2021 at 5:59 AM Michael Chang via Grub-devel
wrote:
>
> On Fri, Mar 05, 2021 at 01:49:00PM +, Dimitri John Ledkov wrote:
> > On Fri, Mar 5, 2021 at 1:34 PM Michael Chang wrote:
> > >
> > > On Fri, Mar 05, 2021 at 12:21:49PM +, Dimitri John Ledkov wrote:
> > > > This is not
On Fri, Mar 5, 2021 at 1:12 PM Michael Chang via Grub-devel
wrote:
>
> While attempting to dual boot Microsoft Windows with efi chainloader, it
> failed with below error when secure boot was enabled.
>
> error ../../grub-core/kern/verifiers.c:119:verification requested but
> nobody cares: /EFI/Mic
Hi Jan,
I noticed that the code will not handle XHCI controllers with multiple
USB 3 port ranges.
This is no problem with USB 3.0 controllers, but the USB 3.1 and USB
3.2 specs brought additional speeds.
At my workplace we have a Ryzen mainboard with an XHCI controller
where 2 ports support up to
On Fri, Jun 5, 2020 at 4:16 AM Michael Chang wrote:
>
> You're probably right if the data type for `station_ip` is
> `grub_efi_pxe_ip_address_t`, but here it is `grub_efi_ip_address_t` declared
> as:
>
> typedef grub_uint8_t grub_efi_ip_address_t[8] __attribute__ ((aligned(4)));
>
> So the compi
Hi,
You replace the 'unused[52]' field before dhcp_discover with 51 bytes.
While the UEFI spec also defines the EFI_PXE_BASE_CODE_MODE struct in
this way it also specifies that an EFI_IP_ADDRESS is 16-byte buffer
aligned on a 4-byte boundary.
So there should probably be a grub_efi_uint8_t between
On Thu, Apr 2, 2020 at 7:39 PM Daniel Kiper wrote:
>
> On Wed, Apr 01, 2020 at 11:08:07PM +0200, Thomas Frauendorfer wrote:
> > Hi Olaf,
> >
> > Current Grub does not handle proxy DHCP correctly.
> > There is a patch to add support for proxy DHCP in the mailing list
Hi Olaf,
Current Grub does not handle proxy DHCP correctly.
There is a patch to add support for proxy DHCP in the mailing list
archives, but it was never merged.
I did some adjustments to make it apply to 2.04 for work which I could
share if you are interested.
On Mon, Mar 30, 2020 at 1:55 PM Ola
On Wed, Apr 25, 2012 at 5:01 AM, Bean wrote:
> Thanks for the info, I don't have any 4K drive to test. You can check
> if ntfs fs driver is working properly since I don't remember if I have
> made the 1024 MFT assumption elsewhere.
I don't know yet when I will have the time to test it because the
On Mon, Apr 23, 2012 at 6:03 PM, Bean wrote:
> Hi,
>
> 2, Previous version doesn't return blocklist information for small
> files embed in MFT, this patch fixes it. For example, create a
> 512-byte file test in ntfs and try this command:
>
> grub-fstest /ntfs.img blocklist /tes
Hi,
On some boards, like the AsRock K7S41GX, Grub fails to boot from
superfloppy fat32 formated usb sticks.
The reason for the boot failure is that the bios of the mentioned
board replaces byte 0x24 of the bpb with the value 0x00 when it's read
through the bios function.
In fat16 this byt
On Wed, Sep 22, 2010 at 7:45 PM, Lennart Sorensen
wrote:
> On Wed, Sep 22, 2010 at 06:52:46PM +0200, Thomas Frauendorfer wrote:
>> Well, I think I didn't state the problem clearly enough:
>> The bios doesn't write to the disk, it just changes the value on the
>> fly
On Wed, Sep 22, 2010 at 6:14 PM, Lennart Sorensen
wrote:
> Wouldn't that be a bug in the BIOS? Don't go writing to a drive you
> don't know what contains. It could be something other tahn fat16 after
> all (what if it was a linux kernel with a bootheader on it and not a
> filesystem at all?)
>
Hi,
On some boards, like the AsRock K7S41GX, Grub fails to boot from
superfloppy fat32 formated usb sticks.
The reason for the boot failure is that the bios of the mentioned
board replaces byte 0x24 of the bpb with the value 0x00 when it's read
through the bios function.
In fat16 this byt
16 matches
Mail list logo
