<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 27, 2023 at 10:30 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On So, 26.11.23 00:39, Richard Weinberger (<a href="mailto:richard.weinberger@gmail.com" target="_blank">richard.weinberger@gmail.com</a>) wrote:<br>
<br>
> Hello!<br>
><br>
> After upgrading my main test worker to a recent distribution, the UBI<br>
> test suite [0] fails at various places with -EBUSY.<br>
> The reason is that these tests create and remove UBI volumes rapidly.<br>
> A typical test sequence is as follows:<br>
> 1. creation of /dev/ubi0_0<br>
> 2. some exclusive operation, such as atomic update or volume resize on<br>
> /dev/ubi0_0<br>
> 3. removal of /dev/ubi0_0<br>
><br>
> Both steps 2 and 3 can fail with -EBUSY because the udev worker still<br>
> holds a file descriptor to /dev/ubi0_0.<br>
<br>
Hmm, I have no experience with UBI, but are you sure we open that? why<br>
would we? are such devices analyzed by blkid? We generally don't open<br>
device nodes unless we have a reason to, such as doing blkid on it or<br>
so.<br></blockquote><div><br></div><div>blkid and 60-persistent-storage indeed analyze ubi devices, it seems.<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>