On Mon, Aug 12, 2024 at 04:13:18PM +0200, Heinrich Schuchardt wrote:
> The cycle register is not guaranteed to count at constant frequency.
> If it is counting at all depends on the state the performance monitoring
> unit.
>
> Use the time register to measure time.
>
> Signed-off-by: Heinrich Schuc
On Wed, Jul 24, 2024 at 06:48:45PM +0200, Thomas Schmitt via Grub-devel wrote:
> If not TMPDIR is set by the user then the test grub_cmd_cryptomount
> creates about 20 directories named *LUKS*_test* in the root directory
> and leaves them there when the test ends.
>
> Initialize in the test script
On Mon, Jul 29, 2024 at 09:07:48PM -0700, Arjun wrote:
> Fixes support for 64-bit badram entries. Previously, whenever the start
> address
> of an mmap region exceeded the maximum address attainable via an addr,mask
> pair,
> GRUB would erroneously attempt to binary-search up to the integer limit
On Fri, Aug 02, 2024 at 11:52:02AM +0100, Mate Kukri wrote:
> Users have no reason to see this without explictily asking for it, and
Users do not have any option to ask for it. Why do not use grub_dprintf("efi",
...)
instead of grub_printf()?
Daniel
> it can break graphical boot.
>
> Signed-off
On Wed, Jul 17, 2024 at 02:46:46PM +0800, Michael Chang via Grub-devel wrote:
> The get_part_uuid() function made an assumption that the target grub
> device is a partition device and accessed device->disk->partition
> without checking for NULL. There are four situations where this
> assumption is
Hi,
i wrote:
> > Further delete each created directory as soon as the command of its
> > test case is finished.
> > [...]
> > mkdir -p "$TMPDIR"
> >
> > output=`"$@" 2>&1` || res=$?
> > +
> > +rmdir "$TMPDIR"
Daniel Kiper wrote:
> s/rmdir/rm -rf/?
This is equivalent to the question
Hi,
thinking more i believe that the currently used mkdir option -p is
inappropriate in tests/grub_cmd_cryptomount.in .
It hampers proper cleanup because the script cannot know how many
directories in the path to TMPDIR were created and need to be removed.
It is unusual because about all other t
In an effort to solve
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061168 for myself,
I implemented basic support for cachevol and integrity volumes in LVM.
This is just an extension of the cachepool support that already
existed, and just like that support, I ignore all of the metadata and
j
This patch isn't necessary by itself, but when combined with the next
patch it enhances readability as ignored_features_lv is then used for
multiple types of extra LV's, not just cache LV's
Signed-off-by: Patrick Plenefisch
---
grub-core/disk/lvm.c | 261 +++--
cache_pool is never read or used, remove it
Signed-off-by: Patrick Plenefisch
---
grub-core/disk/lvm.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
index 3d226fad5..17e225596 100644
--- a/grub-core/disk/lvm.c
+++ b/grub
This patch isn't necessary by itself, but when combined with the next
two patchs it enhances readability as ignored_features_lv is then used
for multiple types of extra LV's, not just cache LV's
Signed-off-by: Patrick Plenefisch
---
grub-core/disk/lvm.c | 176 +---
cache_pool is never read or used, remove it
Signed-off-by: Patrick Plenefisch
---
grub-core/disk/lvm.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
index 442a9fc96..10bc965a4 100644
--- a/grub-core/disk/lvm.c
+++ b/grub
In an effort to solve
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061168 for myself,
I implemented basic support for cachevol and integrity volumes in LVM.
This is just an extension of the cachepool support that already
existed, and just like that support, I ignore all of the metadata and
j
lv matching must be done after processing the ignored feature
indirections, as integrity volumes & caches may have several levels
of indirection that the segments must be shifted through.
pv matching must be completely finished before validating a
volume, otherwise referenced raid stripes may not
14 matches
Mail list logo
