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=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.
Related issues
- Related to #17294 (closed)
- Related to #17230
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information