<div dir="ltr">On 13 September 2017 at 23:08, Seebs <span dir="ltr"><<a href="mailto:seebs@seebs.net" target="_blank">seebs@seebs.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 13 Sep 2017 22:50:32 +0200<br>
Martin Jansa <<a href="mailto:martin.jansa@gmail.com">martin.jansa@gmail.com</a>> wrote:<br>
<br>
> inode mismatch:<br>
> '/OE/build/oe-core/tmp-glibc/<wbr>work/core2-64-oe-linux/<wbr>systemd/1_234-r0/recipe-<wbr>sysroot/etc/group'<br>
> ino 29361846 in db, 29361904 in request.<br>
<br>
</span>Just to be clear about this:<br>
<br>
This is at least potentially an Actual Problem. It's probably not a<br>
good idea to habitually ignore these. A thing like this happening means<br>
that, at some point:<br>
<br>
1. Something created etc/group, and it got inode 29361846 recorded in<br>
the database.<br>
2. Something deleted etc/group, and did NOT record this to the database.<br>
3. Something created etc/group, with inode 29361904.<br>
<br>
It's possible that the thing creating etc/group didn't record it to the<br>
database, and something else just referred to it later (like a stat<br>
call), or that this was generated by the request creating the entry.<br>
<br>
Either way, it means changes were made to a pseudo-managed hunk of<br>
filesystem without pseudo knowing about it, and that is generally bad.</blockquote><div><br></div><div>I just applied this patch and got an identical hit in systemd, which makes me think that the useradd class (maze of code that it is) is causing this instance.</div><div><br></div><div>Ross</div></div></div></div>