Hello Vladimir and Daniel,
Could you please let us know your thoughts on Renaud's investigation
and patches? Thanks a lot for your help.
On 1/8/21 3:00 PM, Renaud Métrich wrote:
> Hello,
>
> It appears that the proposal works fine on all systems I could test
> except one: a HP DL380p Gen 8.
>
Hi all,
first of all, I am new to this group/grub. So please be patient if I
violate some group internal rules, just point it out.
Formerly I worked many years on U-Boot.
I have made a driver and command line tool for accessing SPI NOR flash
via EFI interface which I would like to upstream.
Q:
Please try to build only for the "efi-64" platform. (not "pc")
Dmitry
вт, 19 янв. 2021 г. в 03:08, Petr Vorel :
>
> Hi Patrick,
>
> I know that this patchset needs some changes and is not planned to be included
> in 2.06. But anyway, testing it I found:
>
> ...
> > +++ b/grub-core/lib/argon2/core
Hi,
> Please try to build only for the "efi-64" platform. (not "pc")
right, I'll test it, but we need to support also legacy bios.
BTW as Argon2 is the default PBKDF algorithm in current cryptsetup, Debian
installer (and probably other distros' installers) uses it and it has to be
converted after
On Tue, Jan 19, 2021 at 8:12 AM Petr Vorel wrote:
> Therefore postponing Argon2 to another release means users will have it in 2+
> years after 2.06 release (unless distros backport it).
Maybe we can have more frequent releases? Every two years is a pretty
artificial limitation.
On Tue, Jan 19, 2021 at 02:06:15PM +0100, Petr Vorel wrote:
> Hi,
>
> > Please try to build only for the "efi-64" platform. (not "pc")
> right, I'll test it, but we need to support also legacy bios.
I wasn't aware it wouldn't build on the "pc" platform, but I never even
tried in the first place.
Hi Patrick,
> On Tue, Jan 19, 2021 at 02:06:15PM +0100, Petr Vorel wrote:
> > Hi,
> > > Please try to build only for the "efi-64" platform. (not "pc")
> > right, I'll test it, but we need to support also legacy bios.
> I wasn't aware it wouldn't build on the "pc" platform, but I never even
> tri
Hi,
> The consumer of grub_util_raid_getmembers() expects a NULL terminated list
> of device names. It has no idea about how many devices are registered in
> the array; it only cares about active devices. As a result, there cannot
> be gaps in the list, otherwise the first listed inactive device w
