udisksd reports tons of errors about failure to determine whether loop devices seem to be encrypted (#17351) · Issues · tails / tails

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

Originally created by @intrigeri on #17351 (Redmine)

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 (#17294 (closed)) and help desk (#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 0c048250 to go back to the loop.max_loop=8 default value ⇒ 4 times less such “error” lines. With #15281 (closed) 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 #15281 (closed)).
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.

Related issues

Related to #17294 (closed)
Related to #17230

_Originally created by @intrigeri on [#17351 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/17351)_

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 (tails/tails#17294) and help desk
(tails/tails#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 0c048250f33c548313bc7fee25276bd036c7be01 to go back to
    the `loop.max_loop=8` default value ⇒ 4 times less such “error”
    lines. With tails/tails#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
    tails/tails#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.

### Related issues

- **Related to** tails/tails#17294
  - **Related to** tails/tails#17230

Edited May 15, 2020 by intrigeri

Discussion
Designs

The one place for your designs

To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.