summaryrefslogtreecommitdiff
path: root/jffsX-utils/device_table.txt
diff options
context:
space:
mode:
authorChristian Eggers <ceggers@arri.de>2024-07-10 13:29:04 +0200
committerDavid Oberhollenzer <david.oberhollenzer@sigma-star.at>2024-09-25 07:35:06 +0200
commit481b459304ff461b3e93addadc246949791172bd (patch)
tree49d2f23b5f4c1f22f2f41f1f8b320a8a7e1a92b0 /jffsX-utils/device_table.txt
parentcc7af09ae09ae20565e61f7d33b5ec0329797647 (diff)
libubi: ubi_update_start: slightly improve documentation
Calling ubi_update_start() may fail if exclusive access to the UBI volume cannot be established by the kernel. This is likely to happen if an UBI volume is updated directly after creation, because current versions of (systemd-)udevd run their internal 'blkid' also for UBI volumes as soon as they appear (trying to read the UBIFS UUID). There are mainly to options for this case: 1. Don't allow udevd to read UBI volumes at all (means loosing functionatlity) 2. Wait until udevd has finished accessing a new volume (requires cooperation with udevd) 3. Simply retry after short time in case of EBUSY For using option 3, the documentation should state that the concrete error code can be read via errno (this has always been the case since libubi has been introduced). Link: https://groups.google.com/g/swupdate/c/8NVooKjD9oo Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Diffstat (limited to 'jffsX-utils/device_table.txt')
0 files changed, 0 insertions, 0 deletions