Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 553594 - sys-libs/efivar-0.20 fails make test (FEATURES=test)
Summary: sys-libs/efivar-0.20 fails make test (FEATURES=test)
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mike Gilbert
Depends on:
Reported: 2015-06-29 20:55 UTC by Brant Gurganus
Modified: 2015-08-19 03:27 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Brant Gurganus 2015-06-29 20:55:44 UTC
sys-libs/efivar-0.20 fails in 'make test' both inside and outside of portage with or without sandboxing and user privilege.

In the most permissive build as root without sandboxing or userpriv, it fails at

testing efi_set_variable() with too many arguments
FAIL: "one"(line 169) (-1) set test failed: Invalid argument

As a non-root user, the same area fails with a permission issue. If it were just the permission issue, I wouldn't be as concerned, but it does appear to be failing even if the permission issue is worked around.
Comment 1 Mike Gilbert gentoo-dev 2015-06-29 22:17:58 UTC
I wonder if we should just set RESTRICT=test. It seems like a bad idea for an ebuild to be setting EFI variables on a live system.
Comment 2 Brant Gurganus 2015-06-29 23:26:30 UTC
(In reply to Mike Gilbert from comment #1)
> I wonder if we should just set RESTRICT=test. It seems like a bad idea for
> an ebuild to be setting EFI variables on a live system.

On the other hand, if such a feature were not working properly, I'd want to know before it were permanently in place.

Having looked at the tests it does, it appears the unique key for an EFI variable consists of a GUID and a name. The GUID should be unused by anything else if generated correctly. So all tests happen with different names, but they all happen in the namespace of a GUID.

Before testing, variables names under that GUID are cleared.

After testing when successful, those names are cleared.
After testing when not successful, those names are cleared.

So as long as that testing arrangement remains the same, I'd want it to fail while testing instead of while 'live' manipulating non-test data.

Only if the cleanup method isn't working would it leave something behind and so long as that failure is in efivar code and no in the actual EFI hardware, it can be cleaned up and indicates a problem with that efivar version before it got written to EFI and if it's a problem with the cleanup at the EFI level becomes something non-recoverable. Even then, it's under a test GUID namespace, so as long as nothing reads it in for another purpose, then I don't see these tests causing a problem.