Skip to content

Move encrypted update mount to its own task

Unlocking encrypted update can take a long time, preventing other DBus method to respond in time, e.g. MarkUpdateSuccessful with logs like:

Nov 17 15:41:30 apertispro apertis-update-[236]: mount added : /media/1AB7-E289
Nov 17 15:41:31 apertispro application[159]: DEBUG [SystemInit.cpp:135] [operator()]: UpdateMgr is ready.
Nov 17 15:41:31 apertispro application[159]: DEBUG [SystemInit.cpp:207] [operator()]: Boot count before MarkUpdateSuccessful() is: 1
Nov 17 15:41:56 apertispro application[159]: ERROR [UpdateMgr.cpp:205] [OnMarkUpdateSuccessful]: Error while MarkUpdateSuccessful : Timeout was reached
Nov 17 15:41:57 apertispro application[159]: DEBUG [SystemInit.cpp:220] [operator()]: Boot count after MarkUpdateSuccessful() is: 1
Nov 17 15:41:57 apertispro application[159]: ERROR [SystemInit.cpp:223] [operator()]: Boot count reset failed!
Nov 17 15:44:29 apertispro apertis-update-[236]: Marked update as successful
Nov 17 15:44:32 apertispro apertis-update-[236]: mount added : /media/update
Nov 17 15:44:32 apertispro apertis-update-[236]: Ostree static delta starting

Mount event for the encrypted filesystem can occur before return of udisks_filesystem_call_mount_sync() call in the task unlock_and_mount_encrypted_thread. In this case aum->encrypted_bundle_path can not be set correctly. This is managed by adding a point of sync.

Signed-off-by: Frédéric Danis frederic.danis@collabora.com

Merge request reports