> I suspect its the same on KVM and TCG because the machine definition is
> the same and doesn't container either an RTC nor a CMOS. What confusing
> to me is, don't these machines have clocks?
They do have clocks! Sadly I know very little about the clocks. `date`
works fine in Linux, so I suspect
The current qemu firmware paths for arm-efi and arm64-efi are not available
on Ubuntu/Debian but are hardcoded. Switch to first looking for firmware
files in the source directory and if not found, look for them in locations
where Debian installs them. Prefer to use the firmware file usable with the
This allows turning on shell tracing when its not practical or not possible
to use commandline arguments. Turn on tracing when the envvar is an integer
greater than 1, since these can log a lot of messages.
Signed-off-by: Glenn Washburn
---
tests/util/grub-fs-tester.in | 2 ++
tests/util/grub-sh
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index 3e07b5679..3df74cbe2 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -119,7 +119,7 @@ ca
There are several levels of debug and more may be added. But the qemu head
should be one of the highest debug levels. Set debug to a high value of 10
to turn on the head. We do not want to accidentally turn it on when adding
a new debug level to the testing system.
Signed-off-by: Glenn Washburn
-
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index 48c7fde48..fdabc6171 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -74,7 +74,7
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index a1c7b9265..fe1cf768d 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -404,7 +404,9 @@
Now it becomes trivial to re-run a test from the output in its working
directory. This also makes it easy to send a reproducible failing test to
the mailing list. This has allowed a a refactor so that the duplicated
code to call QEMU has be condensed (eg. the use of timeout and file
descriptor redi
This keeps the generated files to aid in diagnosing the source of the
failure.
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index 3ba539c70..96869184c
This allows seeing full qemu output of grub-shell, which can be invaluable
when debugging failing tests.
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index 9d8c417da..e80471126 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -211,7 +211,7 @@ ca
When running tests there are many invocations of grub-shell, and because the
output files are all random names in the same tmp directory, it becomes more
work to figure out which files went with which grub-shell invocations. So
all generated files from one invocation of grub-shell are put into a
ra
The previous behavior ignored an error and the output from grub-mkrescue.
This made it a pain to discover that grub-mkrescue was the reason that tests
which rely on grub-shell were failing. Even after discovering grub-mkrescue
was the culprit, there was no output to indicate why it was failing. I
When turning on shell tracing the trim line will be output before we
actually want to start the trim. However, in this case the trim line never
starts from the beginning of the line. So start trimming from the correct
line by matching from the beginning of the line.
Signed-off-by: Glenn Washburn
This allows us to test if unexpected output in test scripts is because of a
bug in grub, because there was an error in qemu, or qemu was killed due to a
timeout.
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 21 +
1 file changed, 17 insertions(+), 4 deletions(-
This will be useful for tests that have unwanted output from setup. This is
not documented because its only intended to be internal at the moment. Also,
--no-trim is allowed to explicitly turn off trim.
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 14 +-
1 file change
Updates since v2:
* Remove the QEMU output log if not running in debug mode
* The change in v1 to use firmware files had a crucial bug in that the pflash
devine was missing a unit number, which I believe was being defaulted to 0.
This was causing the VARS pflash devices to be used instead of (a
On Thu, Feb 10, 2022 at 12:29 PM Lennart Sorensen
wrote:
>
> On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote:
> > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
> > wrote:
> > >
> > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > > > One idea I've heard floated
On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote:
> On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
> wrote:
> >
> > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > > One idea I've heard floated is, having GRUB alter efivars such that
> > > BootNext is changed to do
On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
wrote:
>
> On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > One idea I've heard floated is, having GRUB alter efivars such that
> > BootNext is changed to do a one time boot of Windows, instead of using
> > chainloader. If BIOS, us
Hello all,
Please don't top post. I am not going to rearrange the text below and
just reply to each chunk if it seems relevant.
On Thu, 10 Feb 2022 at 14:02, Alexander Graf wrote:
>
>
> On 09.02.22 18:20, Renaud Métrich wrote:
> > Hi,
> >
> > I observed no slowdown at all with the new code.
> >
On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> One idea I've heard floated is, having GRUB alter efivars such that
> BootNext is changed to do a one time boot of Windows, instead of using
> chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext
> efi variable? This has
On 09.02.22 18:20, Renaud Métrich wrote:
Hi,
I observed no slowdown at all with the new code.
I was thinking of the same, i.e. trying to find the device and perform
a discovery if not found but there is some sort of caching mechanism
inside Grub regarding devices which prevents Grub from wor
23 matches
Mail list logo
