udisksd reports tons of errors about failure to determine whether loop devices seem to be encrypted
In the Journal I see tons of errors like this:
udisksd: 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
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
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
I see 3 possible ways to improve on this, that are not all mutually exclusive:
- Revert 0c048250 to go back to
loop.max_loop=8default 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.