Re: grub keyfile read errors support
> > If so. Then why does your allow users to remove a removable key? > > I don't understand this, can you rephrase the question? > I have two separate drives: a boot device and a usb flash drive with a key. If I have a usb flash drive attached, grub should automatically unlock the main drive using such a key, if usb flash isn't here - grub should ask for a password for the main drive, not failing loading the whole system to the grub rescue. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub keyfile read errors support
On Mon, 12 Feb 2024 15:36:40 +0300 Alexey Kuznetsov wrote: > Hello John! > > I see your commit 81b2f625f54cb670e36739e3a599daafd34bc44a, about > adding key-file support. This is great! I've been waiting for grub > official support for removable key-file support for a long time. > > I suppose grub key-file meant to keep key files on a separate drive > with fast removal feature (aka USB), not on the same drive? Basically > using USB as removable, cheap, TPM device. Right? Great! I can't speak for John, but my use case wasn't to keep it on a separate drive per se. > > If so. Then why does your allow users to remove a removable key? I don't understand this, can you rephrase the question? > Because your code, strictly requiring for key file to exist and be > available to read, and if grub fails to read the key then cryptomount > function will fail. Yes, this is expected. > As we know grub rescue shell is very limited, and dosn't even have a > 'if' statement. Initial script can only have few commands like 'search' > or 'cryptomount'. Here is no option for user to write a script which > can check if key file exists and readable before calling 'cryptomount' > func. Then if we want to support removable keys, then code should allow > to fail when reading keys. The rescue shell is not meant for what you're wanting to do with it. Use the normal shell and you'll get all those features. > > Here is my patch on top of your work, attached. > Thanks for your interest in improving GRUB. However, I don't think this should be included as there are existing ways to accomplish what you want to do. Glenn ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Skip tests if tool/dependency is not installed
On Wed, 14 Feb 2024 11:13:43 +0530 Krishan Gopal wrote: > Hi Glenn, > > On 02/02/24 2:59 am, Glenn Washburn wrote: > > Hi Krishan, > > > > On Tue, 30 Jan 2024 04:18:13 -0600 > > Krishan Gopal Saraswat wrote: > > > >> Currently many tests ends up in an ERROR state due to the environment not > >> having relevant tools, majorly being due to different file systems. > >> > >> For example before this patch the ntfs test fails with the following error: > >> > >> mkfs.ntfs not installed; cannot test ntfs. > >> ERROR ntfs_test (exit status: 99) > >> > >> This was caused due to it returning 99 exit status, which represents ERROR. > >> If a particular tool is not installed/ dependecies not met, it should go to > >> SKIP state. > > This is working as intended. An exit code of 99 represents a "hard > > error"[1], which is not a normal error and indicates a failure that > > results from an improperly run test. This is to distinguish from errors > > that we actually care about resulting from properly run tests. A > > skipped test, exit code 77, are for tests that should not actually be > > run, as in the case of tests that do not apply to the target being > > used. This matters because those running tests should be notified that > > they are not properly running all the tests (usually due to lack of > > dependencies). Skipping those failing tests obscures this fact. The > > point of the test suite is to have all the tests run, not to only run > > the successful ones and ignore the rest. > > > > What problem does this patch actually solve? > > Thanks for the review, > > My view of SKIP/ERROR is the following. > > Considering the following two conditions for SKIP: What ever not > supported on a particular platform [powerPC]. For example NTFS file > system is for Windows and not supported on Linux - in this case > expecting a SKIP instead of ERROR Linux does indeed support the NTFS filesystem and has for a while. The GRUB tests are intended to be run on a Linux kernel, and I've verified that the NTFS tests work on an x86 build machine. I have no reason to believe they would not work on PPC as well. If a platform does not support a specific test, the test should be skipped, but only for that platform. Do you have an example where a test should be skipped and is not? If so, please send a patch. > Considering the following for ERROR: > Expected tool is available but failed due to some error. This patch will > help in getting the correct output for a test execution that is not > supported. Yes, if an expected tool exists but fails due to a bug, then the test should return a HARD ERROR. The same should happen if the tool does not exist. I do not believe that this patch gives the correct output. Whether or not test execution is supported has to do with if the test can be supported with the state of existing tools. If you do not install the NTFS tools that the NTFS filesystem tests need to function, that does not mean the tests are not supported. It means you have an improper environment for running those tests. Please read the INSTALL for the list of packages needed on a Debian system for running the tests. Glenn > > Thanks, > > Krishan > > > > > Glenn > > > > [1] > > https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html > > > >> After this patch, ntfs test skips if the tool is not available, with the > >> following message: > >> > >> mkfs.ntfs not installed; cannot test ntfs. > >> SKIP ntfs_test (exit status: 77) > >> > >> Many such test cases had similar failures and have been modified to SKIP > >> state. > >> > >> The following test cases also had similar failures and have been modified > >> from > >> ERROR to SKIP state: > >> hfsplus_test, ntfs_test, reiserfs_test, f2fs_test, nilfs2_test, > >> romfs_test, exfat_test, udf_test, hfs_test, jfs_test, btrfs_test, > >> zfs_test, xfs_test > >> > >> Signed-off-by: Krishan Gopal Saraswat > >> --- > >> btrfs_test.in| 2 +- > >> exfat_test.in| 2 +- > >> f2fs_test.in | 2 +- > >> hfs_test.in | 4 ++-- > >> hfsplus_test.in | 2 +- > >> jfs_test.in | 2 +- > >> nilfs2_test.in | 2 +- > >> ntfs_test.in | 4 ++-- > >> reiserfs_test.in | 2 +- > >> romfs_test.in| 2 +- > >> udf_test.in | 2 +- > >> xfs_test.in | 2 +- > >> zfs_test.in | 2 +- > >> 13 files changed, 15 insertions(+), 15 deletions(-) > >> > >> diff --git a/btrfs_test.in b/btrfs_test.in > >> index 0d098c9..a07d2e5 100644 > >> --- a/btrfs_test.in > >> +++ b/btrfs_test.in > >> @@ -12,7 +12,7 @@ fi > >> > >> if ! which mkfs.btrfs >/dev/null 2>&1; then > >> echo "mkfs.btrfs not installed; cannot test btrfs." > >> - exit 99 > >> + exit 77 > >> fi > >> > >> "@builddir@/grub-fs-tester" btrfs > >> diff --git a/exfat_test.in b/exfat_test.in > >> index 7939f25..7acde19 100644 > >> --- a/exfat_test.in > >> +++ b/exfat_test.in > >> @@ -12,7 +12,7 @@ fi > >> > >> if
Re: Need help: alternative module inclusion - duplicate symbols
You can add a dispatcher which switches between 2 modules. E.g.
real_do_stuff (...);
fake_do_stuff(...);
static int (*do_stuff)( ...);
And switch pointer between 2 implementations. See terminal output and
grub_xputs for examples
On Mon, Feb 26, 2024 at 1:51 PM Michael Lawnick via Grub-devel
wrote:
>
> Hi group,
>
> hope you can help me:
> I have modules pci_fpga.c and pci_fpga_emul.c with same functions in
> them but different implementation, one for the real device, the other
> one is just emulating.
>
> What I now want is being able to include one of both versions through
> build command. I started with this:
>
> Makefile.core.def:
> ...
> module = {
> name = pci_fpga;
> common = startlib/board/pci_fpga.c;
> enable = efi;
> };
>
> module = {
> name = pci_fpga_emul;
> common = startlib/board/pci_fpga_emul.c;
> enable = efi;
> };
> ...
>
> but then I get duplicate symbols error even without giving pci_fpga or
> pci_fpga_emul on the build.
>
> For using different packages than 'common' like this
> module = {
> name = pci_fpga;
> pci_fpga = startlib/board/pci_fpga.c;
> enable = efi;
> };
> I could not find means to get pci_fpga included.
>
> Same problem if trying to approach it via different enable flag: How to do?
>
> Can anybody help? In docs I couldn't find usable hints.
>
> --
> KR
> Michael
>
> ___
> 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
Re: Need help: alternative module inclusion - duplicate symbols
Using function pointers solves the duplicate symbol problem.
But still there is a way needed to get the information passed into build.
FPGA is so essential in my use case that the configuration must be
compiled-in. But as the sources are under git a #define is not a good
option.
Am 26.02.2024 um 14:38 schrieb Vladimir 'phcoder' Serbinenko:
> You can add a dispatcher which switches between 2 modules. E.g.
> real_do_stuff (...);
> fake_do_stuff(...);
>
> static int (*do_stuff)( ...);
> And switch pointer between 2 implementations. See terminal output and
> grub_xputs for examples
>
> On Mon, Feb 26, 2024 at 1:51 PM Michael Lawnick via Grub-devel
> wrote:
>>
>> Hi group,
>>
>> hope you can help me:
>> I have modules pci_fpga.c and pci_fpga_emul.c with same functions in
>> them but different implementation, one for the real device, the other
>> one is just emulating.
>>
>> What I now want is being able to include one of both versions through
>> build command. I started with this:
>>
>> Makefile.core.def:
>> ...
>> module = {
>> name = pci_fpga;
>> common = startlib/board/pci_fpga.c;
>> enable = efi;
>> };
>>
>> module = {
>> name = pci_fpga_emul;
>> common = startlib/board/pci_fpga_emul.c;
>> enable = efi;
>> };
>> ...
>>
>> but then I get duplicate symbols error even without giving pci_fpga or
>> pci_fpga_emul on the build.
>>
>> For using different packages than 'common' like this
>> module = {
>> name = pci_fpga;
>> pci_fpga = startlib/board/pci_fpga.c;
>> enable = efi;
>> };
>> I could not find means to get pci_fpga included.
>>
>> Same problem if trying to approach it via different enable flag: How to do?
>>
>> Can anybody help? In docs I couldn't find usable hints.
>>
>> --
>> KR
>> Michael
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Need help: alternative module inclusion - duplicate symbols
Hi group,
hope you can help me:
I have modules pci_fpga.c and pci_fpga_emul.c with same functions in
them but different implementation, one for the real device, the other
one is just emulating.
What I now want is being able to include one of both versions through
build command. I started with this:
Makefile.core.def:
...
module = {
name = pci_fpga;
common = startlib/board/pci_fpga.c;
enable = efi;
};
module = {
name = pci_fpga_emul;
common = startlib/board/pci_fpga_emul.c;
enable = efi;
};
...
but then I get duplicate symbols error even without giving pci_fpga or
pci_fpga_emul on the build.
For using different packages than 'common' like this
module = {
name = pci_fpga;
pci_fpga = startlib/board/pci_fpga.c;
enable = efi;
};
I could not find means to get pci_fpga included.
Same problem if trying to approach it via different enable flag: How to do?
Can anybody help? In docs I couldn't find usable hints.
--
KR
Michael
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
