Bug #17351

udisksd reports tons of errors about failure to determine whether loop devices seem to be encrypted

Added by intrigeri 2019-12-15 10:14:19 . Updated 2019-12-17 11:48:39 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

In the Journal I see tons of errors like this:

udisksd[3029]: Error determining whether device '/dev/loop1' seems to be encrypted: Failed to read device (g-bd-crypto-error-quark, 0)

I see this at least 3 times in WhisperBack reports for each /dev/loopN with N in the 0..31 range. That’s lots of noise and this causes trouble for release managers and manual testers (Bug #17294) and help desk (Bug #17230).

FTR, on my sid system with loop.max_loop=8, when udisksd starts it immediately raises this error 3 times in a row for each of my 8 loop devices.

I see 3 possible ways to improve on this, that are not all mutually exclusive:

  • Revert commit:0c048250f33c548313bc7fee25276bd036c7be01 to go back to the loop.max_loop=8 default value ⇒ 4 times less such “error” lines. With Feature #15281 we won’t need more than 2 loop devices so this should be safe. I think we should do this no matter what (blocked by Feature #15281).
  • Have this udisksd “error” downgraded to a warning or even debug level message.
  • Have udisksd do this check only once on startup, instead of 3 times.
  • Teach udisksd that loop devices are special and that unless they’re actually in use, it’s expected that one can’t read from them. Ideally it would only try to read from loop devices that are in use; but just not displaying such a message at all for loop devices could be good enough.

Subtasks

Related issues

Related to Tails - Bug #17294: Double-check journalctl output in 4.1 Resolved
Related to Tails - Bug #17230: "input/output error" warning messages in Tails 4.0 logs Confirmed
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2019-12-15 10:14:33

  • related to Bug #17294: Double-check journalctl output in 4.1 added

#2 Updated by intrigeri 2019-12-15 10:14:37

  • related to Bug #17230: "input/output error" warning messages in Tails 4.0 logs added

#3 Updated by intrigeri 2019-12-15 10:14:57

#4 Updated by segfault 2019-12-15 21:10:39

> Revert 0c048250f33c548313bc7fee25276bd036c7be01 to go back to the loop.max_loop=8 default value ⇒ 4 times less such “error” lines. With Feature #15281 we won’t need more than 2 loop devices so this should be safe. I think we should do this no matter what (blocked by Feature #15281).

That would by far be the cheapest option, because it doesn’t require patching udisks and upstreaming the patch.

> Have this udisksd “error” downgraded to a warning or even debug level message.

This would be an easy patch. Writing that patch and creating a merge request is cheap, but there could be discussions with upstream. And at least for me, patching, building and uploading a new udisks package is still a lot of work. And there is the possibility that we would have to port that patch to a newer udisks version.

> Have udisksd do this check only once on startup, instead of 3 times.

I don’t know why it even does that. I could look into that.

> Teach udisksd that loop devices are special and that unless they’re actually in use, it’s expected that one can’t read from them. Ideally it would only try to read from loop devices that are in use; but just not displaying such a message at all for loop devices could be good enough.

IMO that would be the best solution. If we decide to make the effort of creating and upstreaming a patch, I would look into whether this is feasible.

#5 Updated by intrigeri 2019-12-17 11:48:39

hi,

thanks for the quick feedback!

>> Revert 0c048250f33c548313bc7fee25276bd036c7be01 to go back to the loop.max_loop=8 default value ⇒ 4 times less such “error” lines. With Feature #15281 we won’t need more than 2 loop devices so this should be safe. I think we should do this no matter what (blocked by Feature #15281).

> That would by far be the cheapest option, because it doesn’t require patching udisks and upstreaming the patch.

Yeah. I think we should do this no matter what (as FT work), to mitigate the problem until we know what else we can do and when.

>> Have this udisksd “error” downgraded to a warning or even debug level message.

> This would be an easy patch. Writing that patch and creating a merge request is cheap, but there could be discussions with upstream. And at least for me, patching, building and uploading a new udisks package is still a lot of work. And there is the possibility that we would have to port that patch to a newer udisks version.

I propose we invest time into preparing this upstream MR but don’t bother carrying this delta in a custom package, and instead wait for Tails 5.0 to collect the benefits.

>> Have udisksd do this check only once on startup, instead of 3 times.

> I don’t know why it even does that. I could look into that.

>> Teach udisksd that loop devices are special and that unless they’re actually in use, it’s expected that one can’t read from them. Ideally it would only try to read from loop devices that are in use; but just not displaying such a message at all for loop devices could be good enough.

> IMO that would be the best solution. If we decide to make the effort of creating and upstreaming a patch, I would look into whether this is feasible.

I agree this would be the best solution. Now, if we do what I’m proposing above, then I think we’ve solved the most important part of the problem already, and can skip this. Makes sense?