RFC: exclude partitions from efi_selftest
Hi,
in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you.
Shouldn't be the registering of partitions for self test been made dependent on successful basic init? I wouldn't qualify a non-initialized partition as reason to let self test fail. If at all a warning should be sufficient. As far as I understand efi self test is intended more as a functional regression test, not a H/W system test, isn't it? What about the idea to allow to exclude partitions by environment variable?
KR Michael
On 9/14/21 4:56 PM, Michael Lawnick wrote:
Hi,
in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you.
When the UEFI sub-system is intialized we call efi_disk_register(). If it fails, we don't enter the UEFI sub-system.
Are you able to identify where efi_disk_register() fails?
Shouldn't be the registering of partitions for self test been made dependent on successful basic init? I wouldn't qualify a non-initialized partition as reason to let self test fail. If at all a warning should be sufficient. As far as I understand efi self test is intended more as a functional regression test, not a H/W system test, isn't it? What about the idea to allow to exclude partitions by environment variable?
We use efi_selftest in our continuous integration. Patches that make it fail will not be accepted upstream. It is nothing that you need on a deployed production system.
Best regards
Heinrich
KR Michael
Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
On 9/14/21 4:56 PM, Michael Lawnick wrote:
Hi,
in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you.
When the UEFI sub-system is intialized we call efi_disk_register(). If it fails, we don't enter the UEFI sub-system.
Are you able to identify where efi_disk_register() fails?
The system starts up properly. This is what I see: ASIM-CN10KAS> efiload $loadaddr Loaded EFI App image at 0x40080000 with 0x216000 bytes ASIM-CN10KAS> bootefi $loadaddr $fdtaddr Scanning disk sdhci@824000000000.blk... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** Found 8 disks Init Monotonic Count to zero ...
But the efi selftest fails.
Shouldn't be the registering of partitions for self test been made dependent on successful basic init? I wouldn't qualify a non-initialized partition as reason to let self test fail. If at all a warning should be sufficient. As far as I understand efi self test is intended more as a functional regression test, not a H/W system test, isn't it? What about the idea to allow to exclude partitions by environment variable?
We use efi_selftest in our continuous integration. Patches that make it fail will not be accepted upstream. It is nothing that you need on a deployed production system.
Somehow I miss the connection between my question and your answer. We want to integrate the efi_selftest into our CI, too. But if it fails due to one uninitialized partition out of 8 then things become more complicated than they should. Based on this I am asking why this problem exists at all.
-- KR Michael
Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
On 9/14/21 4:56 PM, Michael Lawnick wrote:
Hi,
in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you.
When the UEFI sub-system is intialized we call efi_disk_register(). If it fails, we don't enter the UEFI sub-system.
Are you able to identify where efi_disk_register() fails?
The system starts up properly. This is what I see: ASIM-CN10KAS> efiload $loadaddr Loaded EFI App image at 0x40080000 with 0x216000 bytes ASIM-CN10KAS> bootefi $loadaddr $fdtaddr Scanning disk sdhci@824000000000.blk... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type **
This is not an error. Just an info.
Found 8 disks Init Monotonic Count to zero ...
But the efi selftest fails.
Shouldn't be the registering of partitions for self test been made dependent on successful basic init? I wouldn't qualify a non-initialized partition as reason to let self test fail. If at all a warning should be sufficient. As far as I understand efi self test is intended more as a functional regression test, not a H/W system test, isn't it? What about the idea to allow to exclude partitions by environment variable?
We use efi_selftest in our continuous integration. Patches that make it fail will not be accepted upstream. It is nothing that you need on a deployed production system.
Somehow I miss the connection between my question and your answer. We want to integrate the efi_selftest into our CI, too. But if it fails due to one uninitialized partition out of 8 then things become more complicated than they should. Based on this I am asking why this problem exists at all.
Could you, please send the complete output starting with 'bootefi selftest'.
Best regards
Heinrich
-- KR Michael
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
Could you, please send the complete output starting with 'bootefi selftest'.
ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' ** Unrecognized filesystem type ** lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed
Tearing down 'block device' Tearing down 'block device' succeeded
Boot services terminated
Summary: 1 failures
-- KR Michael
Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
Could you, please send the complete output starting with 'bootefi selftest'.
ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' ** Unrecognized filesystem type **
Is the FAT file system enabled in the configuration?
lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed
Tearing down 'block device' Tearing down 'block device' succeeded
Boot services terminated
Summary: 1 failures
-- KR Michael
Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt:
Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
Could you, please send the complete output starting with 'bootefi selftest'.
ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' ** Unrecognized filesystem type **
Is the FAT file system enabled in the configuration?
No
lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed
Tearing down 'block device' Tearing down 'block device' succeeded
Boot services terminated
Summary: 1 failures
Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt patrick@blueri.se Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible.
-- KR Michael
Am 15.09.2021 um 13:36 schrieb Michael Lawnick:
Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt:
Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
Could you, please send the complete output starting with 'bootefi selftest'.
ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' ** Unrecognized filesystem type **
Is the FAT file system enabled in the configuration?
No
lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed
Tearing down 'block device' Tearing down 'block device' succeeded
Boot services terminated
Summary: 1 failures
Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt patrick@blueri.se Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible.
We have 8 partitions of which no. 5 isn't initialized. I have put a bunch of printf to the code and see that the execute() is done exactly on the partition which is unknown, no other gets touched !?
-- KR Michael
On Wed, Sep 15, 2021 at 05:06:09PM +0200, Michael Lawnick wrote:
Am 15.09.2021 um 13:36 schrieb Michael Lawnick:
Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt:
Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
Could you, please send the complete output starting with 'bootefi selftest'.
ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' ** Unrecognized filesystem type **
Is the FAT file system enabled in the configuration?
No
lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed
Tearing down 'block device' Tearing down 'block device' succeeded
Boot services terminated
Summary: 1 failures
Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt patrick@blueri.se Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible.
We have 8 partitions of which no. 5 isn't initialized. I have put a bunch of printf to the code and see that the execute() is done exactly on the partition which is unknown, no other gets touched !?
Just in case, "block device" selftest doesn't touch you disk at all. Instead, it sets up some memory region as a pseudo block device (i.e. block_io_protocol) with fat filesystem, and utilizes it for the test execution.
Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration.
-Takahiro Akashi
-- KR Michael
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro:
On Wed, Sep 15, 2021 at 05:06:09PM +0200, Michael Lawnick wrote:
Am 15.09.2021 um 13:36 schrieb Michael Lawnick:
Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt:
Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
Could you, please send the complete output starting with 'bootefi selftest'.
ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' ** Unrecognized filesystem type **
Is the FAT file system enabled in the configuration?
No
lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed
Tearing down 'block device' Tearing down 'block device' succeeded
Boot services terminated
Summary: 1 failures
Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt patrick@blueri.se Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible.
We have 8 partitions of which no. 5 isn't initialized. I have put a bunch of printf to the code and see that the execute() is done exactly on the partition which is unknown, no other gets touched !?
Just in case, "block device" selftest doesn't touch you disk at all. Instead, it sets up some memory region as a pseudo block device (i.e. block_io_protocol) with fat filesystem, and utilizes it for the test execution.
Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration.
Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try.
KR Michael
Am 16.09.2021 um 09:15 schrieb Michael Lawnick:
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro:
Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration.
Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try.
Sometimes live is such easy. This fixed my issue, THX.
For the after-math / my understanding: - Do I understand correctly that the problem was that 'efi_selftest block device' requires FAT support? So shouldn't there be a dependency in CONFIG? - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used?
-- KR Michael
On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote:
Am 16.09.2021 um 09:15 schrieb Michael Lawnick:
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro:
Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration.
Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try.
Sometimes live is such easy. This fixed my issue, THX.
For the after-math / my understanding:
- Do I understand correctly that the problem was that 'efi_selftest
block device' requires FAT support? So shouldn't there be a dependency in CONFIG?
Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' instead of 'select'.
- What is the reason/use to iterate through the recognized partitions
even twice (in .setup and .execute) if they aren't needed/used?
What line of code do you exactly mean by 'in .setup' (and in .execute)?
-Takahiro Akashi
-- KR Michael
Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro:
On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote:
Am 16.09.2021 um 09:15 schrieb Michael Lawnick:
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro:
Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration.
Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try.
Sometimes live is such easy. This fixed my issue, THX.
For the after-math / my understanding:
- Do I understand correctly that the problem was that 'efi_selftest
block device' requires FAT support? So shouldn't there be a dependency in CONFIG?
Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' instead of 'select'.
- What is the reason/use to iterate through the recognized partitions
even twice (in .setup and .execute) if they aren't needed/used?
What line of code do you exactly mean by 'in .setup' (and in .execute)?
My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c lib/efi_selftest/efi_selftest_block_device.c
On Thu, Sep 16, 2021 at 11:14:01AM +0200, Michael Lawnick wrote:
Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro:
On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote:
Am 16.09.2021 um 09:15 schrieb Michael Lawnick:
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro:
Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration.
Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try.
Sometimes live is such easy. This fixed my issue, THX.
For the after-math / my understanding:
- Do I understand correctly that the problem was that 'efi_selftest
block device' requires FAT support? So shouldn't there be a dependency in CONFIG?
Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' instead of 'select'.
- What is the reason/use to iterate through the recognized partitions
even twice (in .setup and .execute) if they aren't needed/used?
What line of code do you exactly mean by 'in .setup' (and in .execute)?
My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c
That is exactly what efi_selftest.c does.
lib/efi_selftest/efi_selftest_block_device.c
And this is a test instance for block device test. So what's your question?
-Takahiro Akashi
Am 16.09.2021 um 11:37 schrieb AKASHI Takahiro:
On Thu, Sep 16, 2021 at 11:14:01AM +0200, Michael Lawnick wrote:
Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro:
On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote:
Am 16.09.2021 um 09:15 schrieb Michael Lawnick:
- What is the reason/use to iterate through the recognized partitions
even twice (in .setup and .execute) if they aren't needed/used?
What line of code do you exactly mean by 'in .setup' (and in .execute)?
My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c
That is exactly what efi_selftest.c does.
lib/efi_selftest/efi_selftest_block_device.c
And this is a test instance for block device test. So what's your question?
Hmm, I think the question is really clear, I don't know how to ask differently. But as the original issue is cleared and this is only for background understanding, let's drop it.
THX again to you and Heinrich for fast help.
-- KR Michael
Date: Wed, 15 Sep 2021 12:42:16 +0200 From: Heinrich Schuchardt xypron.glpk@gmx.de
Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
On 9/14/21 4:56 PM, Michael Lawnick wrote:
Hi,
in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you.
When the UEFI sub-system is intialized we call efi_disk_register(). If it fails, we don't enter the UEFI sub-system.
Are you able to identify where efi_disk_register() fails?
The system starts up properly. This is what I see: ASIM-CN10KAS> efiload $loadaddr Loaded EFI App image at 0x40080000 with 0x216000 bytes ASIM-CN10KAS> bootefi $loadaddr $fdtaddr Scanning disk sdhci@824000000000.blk... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type **
This is not an error. Just an info.
It is somewhat annoying though. The way disks are partitioned on the Apple M1 systems, there are several Apple native partition types that need to be retained and that U-Boot doesn't support. So you see a lot of these warnings.
Or maybe we should have a whitelist of partition types not to warn about?
On Wed, Sep 15, 2021 at 02:00:31PM +0200, Mark Kettenis wrote:
Date: Wed, 15 Sep 2021 12:42:16 +0200 From: Heinrich Schuchardt xypron.glpk@gmx.de
Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick ml.lawnick@gmx.de:
Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
On 9/14/21 4:56 PM, Michael Lawnick wrote:
Hi,
in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you.
When the UEFI sub-system is intialized we call efi_disk_register(). If it fails, we don't enter the UEFI sub-system.
Are you able to identify where efi_disk_register() fails?
The system starts up properly. This is what I see: ASIM-CN10KAS> efiload $loadaddr Loaded EFI App image at 0x40080000 with 0x216000 bytes ASIM-CN10KAS> bootefi $loadaddr $fdtaddr Scanning disk sdhci@824000000000.blk... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type **
This is not an error. Just an info.
It is somewhat annoying though. The way disks are partitioned on the Apple M1 systems, there are several Apple native partition types that need to be retained and that U-Boot doesn't support. So you see a lot of these warnings.
Or maybe we should have a whitelist of partition types not to warn about?
This message is not UEFI specific, but generic filesystem code generates it. So you could 1) At fs_probe_unsupported() in fs/fs.c, change log_err() to log_warning() [or log_info()] 2) Set CONFIG_DEFAULT_LOG_LEVEL to 3(error) [or 4(warning)] to suppress the message.
Or you may simply want to modify _log() so as to add a preamble, like "WARN:", in front of the message.
-Takahiro Akashi
participants (4)
-
AKASHI Takahiro -
Heinrich Schuchardt -
Mark Kettenis -
Michael Lawnick