Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
T
tails
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 952
    • Issues 952
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • tails
  • tails
  • Issues
  • #17351

Closed
Open
Opened Dec 15, 2019 by intrigeri@intrigeriMaintainer

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
Edited May 15, 2020 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tails/tails#17351