Regards
Vladimir 'phcoder' Serbinenko
Le jeu. 3 juil. 2025, 09:34, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> a écrit :
> Hello Brian,
>
> On Thu, 2025-07-03 at 03:55 +, Brian Goodwin via Grub-devel wrote:
> > My name is Brian Goodwin. I've
I'm unsure about favouring one distro over the other on this.
Another thing: it misses arm and riscv efis in its package list
Regards
Vladimir 'phcoder' Serbinenko
Le lun. 9 juin 2025, 22:22, Leo Sandoval via Grub-devel
a écrit :
> Containers bring the ability to have ready-t
GRUB kernel doesn't have a stable interface. So it's not supported to mix
kernel and modules from different sources. What I do in your case is that I
use upstream kernel and modules with few patches to add blscfg. Those
patches are currently in review upstream
Regards
Vladimi
gards
Vladimir 'phcoder' Serbinenko
Le jeu. 24 avr. 2025, 05:47, Aaron Rainbolt a écrit :
> The purpose of this patch is to allow the Xen hypervisor to pass extra
> data to GRUB in the form of a kernel command line, allowing the host to
> customize the boot process of the gues
ready for announcement.
Regards
Vladimir 'phcoder' Serbinenko
Le mar. 27 mai 2025, 22:39, Khalid Ali a écrit :
> Hey GRUB community,
>
> This RFC discussion is about proposing a less stable repository alongside
> the current official one.
>
> The issue I'd like to
Why specifying the text as direct argument to menu entry not enough?
menuentry "Title" {
}
Regards
Vladimir 'phcoder' Serbinenko
Le mar. 27 mai 2025, 15:57, Jiří Wolker via Grub-devel
a écrit :
> ---
> grub-core/commands/menuentry.c | 47 ++
Please explain what problem you try to solve. Bash doesn't do anything of
the kind. Why should we? Looks like a solution without a problem
Regards
Vladimir 'phcoder' Serbinenko
Le lun. 26 mai 2025, 20:34, Jiří 'bindiff' Wolker via Grub-devel <
grub-devel@gnu.org
Here is the patch in question:
https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00089.html. It
will need an additional change to Linux calling.
Regards
Vladimir 'phcoder' Serbinenko
Le ven. 23 mai 2025, 19:53, Shreenidhi Shedi a écrit :
> On 20/05/25 19:15, Daniel Kiper
Reviewed-by: Vladimir Serbinenko
Regards
Vladimir 'phcoder' Serbinenko
Le mar. 20 mai 2025, 05:03, Andrew Hamilton a écrit :
> Correct ntfs_test test failures around attempting to validate attribute
> run list values. The calculation was incorrect for the 'curr'
Are those empty lines result of manual editing of envblk? You should not do
this
Regards
Le dim. 18 mai 2025, 11:01, Shreenidhi Shedi a écrit :
> From: Shreenidhi Shedi
>
> Environment files may contain empty lines, which should be
> ignored during parsing. Currently, these lines are not skipp
Another comment: ERR_BAD_FS might be a better fit given how it can be
triggered.
Regards
Le sam. 17 mai 2025, 14:09, Vladimir 'phcoder' Serbinenko
a écrit :
>
> Small comment, otherwise looks good
>
> Le sam. 17 mai 2025, 04:26, Andrew Hamilton a écrit :
>
>> Av
Small comment, otherwise looks good
Le sam. 17 mai 2025, 04:26, Andrew Hamilton a écrit :
> Avoid attempting to defererence a NULL pointer to call read_symlink when
> the given filesystem does not provide a read_symlink function. This could
> be triggered if the calling filesystem had a file mar
Looks good
Reviewed-by: Vladimir Serbinenko phco...@gmail.com
Regards
Vladimir 'phcoder' Serbinenko
Le lun. 12 mai 2025, 14:55, Yair Yarom a écrit :
> Initial testpci module and command used to query if PCI devices are
> present.
>
> ---
> docs/grub.texi
Le lun. 12 mai 2025, 10:37, khaalid cali a écrit :
> From: khaalid
>
> > Vladimir 'phcoder' Serbinenko wrote:
> > Please have a look at how to handle errors with realloc. You need to
> keep a copy of old pointer in case you have to free it. Some places in our
Le dim. 11 mai 2025, 17:11, Yair Yarom a écrit :
>
>
> On Thu, 8 May 2025 at 17:30, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> Le jeu. 8 mai 2025, 15:49, Yair Yarom a écrit :
>>
>>> +#include
>>>
>>
Le dim. 11 mai 2025, 17:36, khaalid cali a écrit :
> From: khaalid
>
> I followed the suggestion and implemented the option parsing using extcmd.
> However, I feel this command is not ideal to have any arguments. Similar
> commands like
> lsefi, lsefimmap, and lsefisystab don’t take arguments—th
>
>
>
> Changes in v3:
> - Command arguments, maybe this command is better if it doesn't have
> any command argument, since we are printing only. Command options is
> just unneccessary. And this is how many grub commands does, so it
> should align.
>
Options are good. Just use extcmd
+
> +static grub_command_t cmd;
> +
> +GRUB_MOD_INIT(lsefivar)
> +{
> + cmd = grub_register_command("lsefivar", grub_cmd_lsefivar, NULL,
> N_("Display UEFI variables."));
> +}
> +GRUB_MOD_FINI(lsefivar)
> +{
> + grub_unregister_command(cmd);
> +}
> --
> 2.49.0
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Small nitpick, otherwise
Reviewed-by: Vladimir Serbinenko phco...@gmail.com
Le jeu. 8 mai 2025, 20:03, Daniel Kiper via Grub-devel
a écrit :
> From: Maxim Suhanov
>
> This allows users to restrict the "search" command's scope to
> encrypted disks only.
>
> Typically, this command is used to "re
Le ven. 9 mai 2025, 13:15, khaalid cali a écrit :
> From: khaalid
>
> This command is intended to print or dump all UEFI runtime services.
> The structure will look like efivar tool, since visually most people are
> familiar with it. If the variable content is string then dump it as
> string, ot
Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel
a écrit :
> From: Maxim Suhanov
>
> When the --cryptodisk-only argument is given, also check the target
> device using the "cryptocheck" command, if available.
>
> This extends the checks to common layouts like LVM-on-LUKS, so the
> --crypto
Can we use extcmd for this?
>
>
>if (disk->dev->id == GRUB_DISK_DEVICE_DISKFILTER_ID)
> {
> + char opt[] = "--quiet";
> + char *args[2];
> +
>cmd = grub_command_find ("cryptocheck");
>if (cmd == NULL) /* No diskfilter module loaded for some reason. */
>
Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel
a écrit :
> From: Maxim Suhanov
>
> This command examines a given diskfilter device, e.g., an LVM disk,
> and checks if underlying disks, physical volumes, are cryptodisks,
> e.g., LUKS disks, this layout is called "LVM-on-LUKS".
>
> The ret
Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel
a écrit :
> From: Maxim Suhanov
>
> This commit adds the grub_cryptodisk_erasesecrets() function to wipe
> master keys from all cryptodisks. This function is EFI-only.
>
> Since there is no easy way to "force unmount" a given encrypted disk,
Reviewed-by: Vladimir Serbinenko phco...@gmail.com
Regards
Vladimir 'phcoder' Serbinenko
Le jeu. 8 mai 2025, 20:04, Daniel Kiper via Grub-devel
a écrit :
> From: Maxim Suhanov
>
> Switching to another EFI boot application while there are secrets in
> RAM is dangerous, be
I believe haphazard ad-hoc approach is not a way to go. I see 2 valid
approaches:
* Have a central EFI to grub error converter that would print error code
and message
* Just print EFI error code in hex and tell that only experts are
interested in those details
Regards
Vladimir 'ph
\"%s\", expected :\n",
> d, devlist.devices[d]);
>
Return an error.
> +}
> + }
> +
> + grub_pci_iterate (grub_testpci_iter, (void*)&devlist);
> +
> + for (int i = 0; i < devlist.n_devices; i++) {
> +grub_free(devlist.devices[i]);
&
Patches should be in logical chunks. In your case squashing is the way to go
Regards
Vladimir 'phcoder' Serbinenko
Le mar. 6 mai 2025, 17:36, Yair Yarom a écrit :
>
> I've made the changes, but I'm inexperienced with git send or the policy
> here. Should I se
reads lines from a file given
> by the --file parameter, and returns true if one or more of those PCI
> devices is present, and false otherwise.
>
> Thanks,
> Yair.
>
>
>
> On Wed, 23 Apr 2025 at 18:13, Vladimir 'phcoder' Serbinenko <
> phco...@
Thanks. Fixed in the new version
Regards
Vladimir 'phcoder' Serbinenko
Le jeu. 24 avr. 2025, 18:43, Mate Kukri a écrit :
> ia32-efi build breaks with these patches, grub-mkimage seems to be
> missing relocation type 8
>
> On Tue, Apr 8, 2025 at 4:16 PM Vladimir Serbinenko
Le mer. 23 avr. 2025, 01:39, Leo Sandoval a écrit :
>
>
> On Tue, Apr 15, 2025 at 9:28 AM Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> What is the code size increase on i386-pc? Did you test it? This is
>> likely to result in a bi
Hello. Such a functionality would be beneficial for GRUB. For more details
I'd have to see at least the proposed interface if not the actual patches
Regards
Vladimir 'phcoder' Serbinenko
Le mer. 23 avr. 2025, 11:56, Yair Yarom a écrit :
> Hi,
>
> We have a netboot e
limits and firmware bugs limit its usefulness
Regards
Le mar. 22 avr. 2025, 23:34, Paymon MARANDI a
écrit :
> earlier version of this didn't count for other archs and actually
> mapping the unmapped memory above 4GB.
>
> this builds on top of the previous patch (by phcoder) in the
This will need fixes. I already have a newer version. Real problem though
is testing it
Regards
Vladimir 'phcoder' Serbinenko
Le mar. 22 avr. 2025, 23:33, Paymon MARANDI a
écrit :
> From: Vladimir Serbinenko
>
> This is a replacement workaround for EFIs that do not map me
ens if mcmodel=medany and we allocate something
> more than 2GiB away, probably relocation overflow.
>
Is there any problem with making mcmodel large mandatory on riscv?
>
> On Mon, 21 Apr 2025 at 20:03, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
&
patch files?
>
Pushed as https://github.com/phcoder/GRUB/tree/mshared
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
I believe the problem you describe is fixed by series of patches '[PATCH
0/3] Use -shared compilation instead of -Wl,-r'. Can you try them?
Regards
Vladimir 'phcoder' Serbinenko
Le lun. 21 avr. 2025, 18:56, Adriano Cordova a écrit :
> The current grub risc-v ELF loader d
> > +module = {
> > + name = blsuki;
> > + common = commands/blsuki.c;
> > + common = lib/vercmp.c;
>
> Probably this should be a part of the kernel.
>
> > + enable = powerpc_ieee1275;
>
> ??? Really? PowerPC? IEEE 1275? I think something is off here...
>
BLS is specified for ieee1275 explicitl
Can you run lsefimmap and lspaging on the system in question? lspaging
patch is in neighboring thread
Regards
Vladimir 'phcoder' Serbinenko
Le ven. 11 avr. 2025, 14:01, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :
> How early is this bug? Do yo
Le sam. 12 avr. 2025, 06:45, Alec Brown a écrit :
> On Tue, Apr 1, 2025 at 6:35 AM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> > Le jeu. 27 mars 2025, 23:44, Alec Brown a
> écrit :
> >
> >> On Wed, Mar 26, 2025 at 5:43
Le jeu. 17 avr. 2025, 00:09, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :
>
>> > If so I see a solution in having a code that would check paging table
>> and
>> > then decide on maximum usable memory
>>
>> any other arch doing
>
>
> > If so I see a solution in having a code that would check paging table and
> > then decide on maximum usable memory
>
> any other arch doing this that i can imitate?
>
None currently. It could look like something along the lines:
* Allocate pages
* Check that they are mapped properly
* If no
This will break systems that have a bug of mapping only 4GiB of RAM. This
code is a workaround for that bug. Which system do you use? Is it an x64?
If so I see a solution in having a code that would check paging table and
then decide on maximum usable memory
Regards
Vladimir 'phcoder'
Le lun. 14 avr. 2025, 05:38, Tony W Wang-oc a
écrit :
> While calling VBIOS to set VESA mode, BIOS/GRUB can indicate VBIOS to clear
> frame buffer, it can also indicate VBIOS to skip this and do the clearing
> itself by access linear frame buffer directly.
>
> Zhaoxin/Glenfly VBIOS is running at
What is the code size increase on i386-pc? Did you test it? This is likely
to result in a big one
Regards
Vladimir 'phcoder' Serbinenko
Le sam. 12 avr. 2025, 01:03, Leo Sandoval via Grub-devel
a écrit :
> Together with the line number, the debug trace with the function name
>
Le ven. 21 juin 2024, 11:21, Renaud Métrich a écrit :
> DDF and IMSM are very similar in handling, especially these should not
> be considered as RAID abstraction.
> This fixes the requirement of having a device map when probing DDF
> containers.
>
Do you mean that DDF is handled by BIOS/UEFI? If
Thank you for bringing this up
Regards
Vladimir 'phcoder' Serbinenko
Le lun. 14 avr. 2025, 12:25, Marta Lewandowska via Grub-devel <
grub-devel@gnu.org> a écrit :
> Hi Daniel, Vladimir,
> Could one of you please provide some feedback for Renaud's patch..?
>
> t
How early is this bug? Do you see "Welcome to GRUB"? Does recompiling with
fPIC help? Do you have memory map dump and paging table dump?
Regards
Vladimir 'phcoder' Serbinenko
Le ven. 11 avr. 2025, 13:39, Tobias Heider a
écrit :
> On arm64 we can't restrict memory
Regards
Vladimir 'phcoder' Serbinenko
Le jeu. 10 avr. 2025, 18:32, Daniel Kiper a écrit :
> On Thu, Apr 10, 2025 at 01:45:37PM +0300, Vladimir Serbinenko wrote:
> > They don't work in ski emulator and we don't really need them
> >
>
Why does it crash? Is it because of MMU or is it because of relocations?
Arm is trickier than x64 add we can't be sure that there is any memory
under 4GiB mark. Entire memory may be married above 4GiB
Le lun. 7 avr. 2025, 21:31, Tobias Heider a
écrit :
> Some Qualcomm Snapdragon X Elite based ma
other than Rust in a different thread.
Le sam. 22 mars 2025, 16:43, Didier Spaier via Grub-devel <
grub-devel@gnu.org> a écrit :
> On 22/03/2025 09:42, Maxim Fomin wrote:
> > On Friday, March 21st, 2025 at 8:51 PM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.co
Le ven. 4 avr. 2025, 00:25, khaliid caliy a écrit :
> Well i apologies the error message were somehow bad on my previous
> patch, and needed some improvement.
>
> diff --git a/grub-core/loader/efi/chainloader.c
> b/grub-core/loader/efi/chainloader.c
> index 869307bf3..4fd46dfda 100644
> --- a/gru
Call results in a nicer stacktrace. And 2 cycles is nothing in the context
of them being executed only once
Le ven. 4 avr. 2025, 16:45, khaliid caliy a écrit :
> Just simple suggestion, i still don't know the reason behind it. So
> please if isn't ideal, i apologies
>
> My suggestion is since th
Le jeu. 3 avr. 2025, 18:06, Daniel Kiper a écrit :
> On Tue, Apr 01, 2025 at 03:58:56PM +0300, Vladimir Serbinenko wrote:
> > Libgcrypt code assumes that on x64 all SSE registers are fair game.
> > While it's true that CPUs in question support it, we disable it in
> > our compilation options. Dis
Le jeu. 3 avr. 2025, 18:19, Daniel Kiper a écrit :
> On Tue, Apr 01, 2025 at 03:58:57PM +0300, Vladimir Serbinenko wrote:
>
> Please split this patch into (probably) three and add CID to each one.
> Good example is in commit 4dc616657 (loader/i386/bsd: Use safe math to
> avoid underflow). Of cour
Le jeu. 3 avr. 2025, 17:59, Daniel Kiper a écrit :
> On Tue, Apr 01, 2025 at 03:58:55PM +0300, Vladimir Serbinenko wrote:
> > This allows us to test purely the integration of the implementation
> > of DSA and RSA from libgcrypt without concerning with additional
> > code.
> >
> > Signed-off-by: V
Le jeu. 3 avr. 2025, 17:51, Daniel Kiper a écrit :
> On Tue, Apr 01, 2025 at 03:58:54PM +0300, Vladimir Serbinenko wrote:
>
> Missing commit message...
>
> Is it possible to split this patch into smaller ones?
>
> And should not these changes go to separate patches in
> grub-core/lib/libgcrypt-pa
Le jeu. 3 avr. 2025, 17:40, Daniel Kiper a écrit :
> On Tue, Apr 01, 2025 at 03:58:52PM +0300, Vladimir Serbinenko wrote:
> > We currently use an old version of libcrypt which
> > results in us having fewer ciphers and missing on many
> > other improvements.
>
> Could you upgrade the libgcrypt to
Reviewed-By : Vladimir Serbinenko phco...@gmail.com
Le mer. 4 déc. 2024, 17:12, Eric Sandeen a écrit :
> When large extent counter / NREXT64 support was added to grub, it missed
> a couple of direct reads of nextents which need to be changed to the new
> NREXT64-aware helper as well. Without thi
Le jeu. 27 mars 2025, 23:44, Alec Brown a écrit :
> On Wed, Mar 26, 2025 at 5:43 AM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> >>
> >>
> >>
> >> +#ifdef GRUB_MACHINE_EFI
> >> +#include
> >> +#inclu
>
>
> + {
> + grub_errno = err;
> + goto fail;
> + }
>
grub_errno is already set. No need to set it again
> initrd_mem = get_virtual_current_address (ch);
> initrd_mem_target = get_physical_target_address (ch);
>}
> --
> 2.34.1
>
>
>
Reviewed-By : Vladimir Serbinenko
Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel
a écrit :
> Fix memory leaks in make_vg() with new helper functions, free_pv()
> and free_lv(). Additionally, correct a check after allocating
> comp->segments->nodes that mistakenly checked lv->segments->n
Reviewed-By : Vladimir Serbinenko
Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel
a écrit :
> In grub_xnu_load_kext_from_dir(), when the call to grub_device_open()
> failed, it simply cleaned up previously allocated memory and returned
> GRUB_ERR_NONE. However, it neglected to free ctx->
Reviewed-By : Vladimir Serbinenko
Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel
a écrit :
> Fix memory leaks in grub_btrfs_extent_read() and
> grub_btrfs_dir().
>
> Fixes: CID 473842
> Fixes: CID 473871
>
> Signed-off-by: Lidong Chen
> ---
> grub-core/fs/btrfs.c | 6 +-
> 1 file
Reviewed-By : Vladimir Serbinenko
Le jeu. 27 mars 2025, 20:57, Lidong Chen via Grub-devel
a écrit :
> Fix memory leaks in grub_relocator_alloc_chunk_align().
>
> Fixes: CID 473844
>
> Signed-off-by: Lidong Chen
> ---
> grub-core/lib/relocator.c | 6 +-
> 1 file changed, 5 insertions(+), 1
>
>
>
> +#ifdef GRUB_MACHINE_EFI
> +#include
> +#include
> +#include
> +#endif
> +
>
Can UKI work without EFI? I think of scenario of putting e.g. EFI disk into
coreboot or BIOS machine.
> GRUB_MOD_LICENSE ("GPLv3+");
>
> #define GRUB_BLS_CONFIG_PATH "/loader/entries/"
> +#define GRUB_UKI_CON
Le mar. 25 mars 2025, 10:15, Alec Brown a écrit :
> Irritatingly, BLS defines paths relatives to the mountpoint of the
> filesystem which contains its snippets, not / or any other fixed
> location. So grub2-emu needs to know whether /boot is a separate
> filesystem from / and conditionally prepen
Is there a risk here of missing the failures? It's common that no one looks
at the output unless it causes a failed build on some CI/CD
Le ven. 21 mars 2025, 11:01, Gary Lin via Grub-devel a
écrit :
> Reset 'ret' to 0 when a test case fails so that the other test cases
> could continue.
>
> Sign
Reviewed-By: Vladimir Serbinenko
Le ven. 21 mars 2025, 02:28, Andrew Hamilton a écrit :
> A regression was introduced recently as a part of the series of
> filesystem related patches to address some CVEs found in GRUB.
>
> This issue may cause either an infinite loop at startup when
> accessing
n what you did, it
> shows a nice starting point for people wanting to take on a module if
> this gains traction like I hope it will.
>
> Thanks!
> Andrew
>
> On Fri, Mar 21, 2025 at 3:53 PM Vladimir 'phcoder' Serbinenko
> wrote:
> >
> > Hello, I was p
Hello, I was playing with adding Rust embedded in GRUB. I’ve pushed results
to 2 repos:
Module goes to https://github.com/phcoder/grub-rust-hello/tree/master
Changes in GRUB are found at https://github.com/phcoder/GRUB/tree/rust
Notes on implementation:
Only i386-pc is implemented right now but
Le ven. 21 mars 2025, 01:54, Andrew Hamilton a écrit :
> A regression was introduced recently as a part of the series of
> filesystem related patches to address some CVEs found in GRUB.
>
> This issue may cause either an infinite loop at startup when
> accessing certain valid NTFS file systems, o
LGTM.
Reviewed-By: Vladimir Serbinenko
Le lun. 10 mars 2025, 19:25, Stuart Hayes a
écrit :
> Without this fix, grub failed to boot linux with "out of memory" after
> trying to run a "search --fs-uuid..." on a system that has 7 ZFS pools
> across about 80 drives.
>
> Signed-off-by: Stuart Hayes
Le mar. 4 mars 2025, 16:25, Daniel Kiper a écrit :
> On Mon, Mar 03, 2025 at 12:04:31AM +0300, Vladimir Serbinenko wrote:
> > FreeBSD loader always passes "elf kernel". -CURRENT kernel accepts only
>
> What is "-CURRENT"?
>
Basically HEAD/master in FreeBSD world.
>
> > "elf kernel", older kernel
Why do you remove boundary check? Maybe it's better to add the second
boundary check from below
Le ven. 28 févr. 2025, 16:11, B Horn a écrit :
> On some NTFS volumes GRUB would enter an infinite loop when
> next_attribute() returned NULL, which can happen in normal cases when
> the end of the at
}
>
> +struct gcry_pk_spec *grub_crypto_pk_dsa;
> +struct gcry_pk_spec *grub_crypto_pk_ecdsa;
> +struct gcry_pk_spec *grub_crypto_pk_rsa;
> +
> void
> grub_crypto_hash (const gcry_md_spec_t *hash, void *out, const void *in,
> g
Y; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/*
> + * Given a hash value 'hval', of hash specification 'hash', perform
> + * the EMSA-PKCS1-v1_5 padding suitable for a key with modulus 'mod'
> + * (See RFC 8017 s 9.2)
> + */
> +gcry_err_code_t
> +grub_crypto_rsa_pad (gcry_mpi_t * hmpi, grub_uint8_t * hval,
> +const gcry_md_spec_t * hash, gcry_mpi_t mod);
> +
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
l_is_persistent (grub_dl_t mod)
> --
> 2.43.5
>
>
> _______
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
ules,
> +or sign them separately.
> +
> +
> @node Platform limitations
> @chapter Platform limitations
>
> --
> 2.43.5
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
>
>{
> diff --git a/util/mkimage.c b/util/mkimage.c
> index b46df2909..f5c59f563 100644
> --- a/util/mkimage.c
> +++ b/util/mkimage.c
> @@ -885,7 +885,7 @@ grub_install_generate_image (const char *dir, const char
> *prefix,
> char *memdisk_pat
ON_OEMTABLECREATORREV].arg,
> 0, 0);
>
>/* Load user tables */
>for (i = 0; i < argc; i++)
> @@ -758,7 +772,7 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int
> argc, char **args)
>acpi_tables = 0;
>
> #if defined (__i386__) || defined (__x86_6
As discussed in another thread, this breaks installing from x86 onto
removable disk for PPC Mac which is a supported workflow
Le ven. 8 nov. 2024, 14:13, Avnish Chouhan a écrit :
> This patch adds a check on install_device while installing grub for
> PowerPC.
> If install_device is not mentioned
Le lun. 14 oct. 2024, 00:13, Samuel Thibault
a écrit :
> Hello,
>
> For the debian installation CD, when using syslinux we can set an
> on-timeout entry which is different from the default entry. This is
> quite important because we want sighted people to be able to just press
> enter to get the
I think the entire series is bad if I understand it correctly. I ask the
same question again: are some files inaccessible with current code but
become accessible with these patches? Aka can I create a file that I can't
read with grub-fstest in the current code?
GRUB2 follows strict design that sam
Le lun. 21 oct. 2024, 06:49, Michael Chang via Grub-devel <
grub-devel@gnu.org> a écrit :
> On Fri, Oct 18, 2024 at 08:39:01PM GMT, Vladimir 'phcoder' Serbinenko
> wrote:
> > Le lun. 14 oct. 2024, 20:10, Leo Sandoval a écrit
> :
> >
> > > From:
Le sam. 19 oct. 2024, 15:51, chench246 a écrit :
> From: chench246
>
> TPCM(Trusted Platform Control Module) is a Chinese standard and is
> compatible with TPM.
>
Before I review the patch: can you explain about compatibility. Of you day
that it's compatible with TPM, why doesn't normal TPM code
Le ven. 18 oct. 2024, 20:42, Neal Gompa a écrit :
> On Fri, Oct 18, 2024 at 1:39 PM Vladimir 'phcoder' Serbinenko
> wrote:
> >
> >
> >
> > Le lun. 14 oct. 2024, 20:10, Leo Sandoval a écrit
> :
> >>
> >> From: Jeff Mahoney
> >
What if I put /boot and /boot/grub in different sub volumes? How do I set
variables then in order to correctly load additional modules from $prefix
and yet load correct kernels? This convoy is needed in order to load
several linuxes from the same btrfs (think installing v1 then making a
clone and u
Le lun. 14 oct. 2024, 20:10, Leo Sandoval a écrit :
> From: Jeff Mahoney
>
> This patch adds the ability to specify a different root on a btrfs
> filesystem too boot from other than the default one.
>
Does it make available some files that are currentl y unavailable? Do you
have an example?
>
>
Reviewed-By: Vladimir Serbinenko phco...@gmail.com
Le mer. 16 oct. 2024, 08:22, Benjamin Herrenschmidt <
b...@kernel.crashing.org> a écrit :
> The calculation of the size of the table was incorrect (copy/pasta from
> grub_acpi_rsdt_find_table() I assume...). The entries are 64-bit long.
>
> This
Le mar. 15 oct. 2024, 08:24, Michael Chang via Grub-devel <
grub-devel@gnu.org> a écrit :
> On Thu, Oct 10, 2024 at 03:43:26PM GMT, Leo Sandoval wrote:
> > From: Paulo Flabiano Smorigo
> >
> > This patch makes grub look for its config file on efi where the app was
> > found. It was originally wri
Thank you for your effort but we already have nvme driver in the review
queue. See my email from 16th of May
Le dim. 13 oct. 2024, 22:38, a écrit :
> From: Mate Kukri
>
> It is based on existing SeaBIOS code, so the license is LGPLv3.
>
> Tested as a coreboot paload on the following targets:
>
Le mar. 8 oct. 2024, 10:23, Michael Chang via Grub-devel
a écrit :
> On Mon, Oct 07, 2024 at 12:20:55PM GMT, Leo Sandoval wrote:
> > From: Michael Chang
> >
> > Implement new net_bootp6 command for IPv6 network auto configuration via
> the
> > DHCPv6 protocol (RFC3315).
>
> This would have marke
Le mar. 8 oct. 2024, 09:53, Michael Chang via Grub-devel
a écrit :
> On Tue, Oct 08, 2024 at 08:07:17AM GMT, Vladimir 'phcoder' Serbinenko
> wrote:
> > Again, what do you try to achieve? Why aren't absolute paths enough?
>
> The absolute path does not align
Can you add a short comment in cmain why it's needed? It should mention
32-bit address truncation. The story in the commit message, on the other
hand, is way too long. It needs to be summarized with a link to full story.
Le lun. 7 oct. 2024, 21:19, Leo Sandoval a écrit :
> From: Paulo Flabiano S
This has a danger of rendering headless systems unbootable while waiting
for user input
Le lun. 7 oct. 2024, 21:19, Leo Sandoval a écrit :
> From: Peter Jones
>
> Signed-off-by: Peter Jones
> ---
> util/grub.d/00_header.in | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/util/grub.d
This increases the core size on i386-pc needlessly. And will increase even
more when we improve backtrace command. This needs to be a hook and loaded
together with normal. Also it needs to be cpu-agnostic
Le lun. 7 oct. 2024, 21:22, Leo Sandoval a écrit :
> From: Peter Jones
>
> ---
> grub-cor
LGTM
Reviewed-by: Vladimir Serbinenko phco...@gmail.com
Le lun. 7 oct. 2024, 21:23, Leo Sandoval a écrit :
> From: Peter Jones
>
> current gcc complains:
>
> grub-core/fs/btrfs.c: In function ‘grub_cmd_btrfs_info’:
> grub-core/fs/btrfs.c:2745:7: error: the comparison will always evaluate
>
Again, what do you try to achieve? Why aren't absolute paths enough?
Le lun. 7 oct. 2024, 21:23, Leo Sandoval a écrit :
> From: Michael Chang
>
> Signed-off-by: Michael Chang
> Signed-off-by: Robbie Harwood
> ---
> grub-core/osdep/linux/getroot.c | 7 +++
> grub-core/osdep/unix/config.c
Upstream uses "grub" for these commands. Rename to "grub2" is
distro-specific
Le lun. 7 oct. 2024, 21:23, Leo Sandoval a écrit :
> From: Peter Jones
>
> This needs to be hooked up to --program-transform=, but I haven't had
> time.
>
> Signed-off-by: Peter Jones
> ---
> docs/grub-dev.texi|
1 - 100 of 4347 matches
Mail list logo
