<div dir="ltr">OK, thanks.<div><br></div><div>Any insights to the first issue described in commit message? That we know that is an Actual Problem, but hard to reproduce it.</div><div><br></div><div>I'm rebuilding one component over and over again and with pseudo 1.8.1 I got this issue in 5 rebuilds from 1000, now in the same build with latest pseudo 1.8.2 backported from oe-core/master I got this issue only 2 times in 1000 iterations.</div><div><br></div><div>Hopefully this insane check will help discover similar issues even without triggering the QA host-user-contamination check, so that we can detect such issues even without really trying (it's now included in my regular "bitbake world" builds which quite often trigger this QA host-user-contamination issue in glibc-locale. And now we can correlate that with pseudo.log more easily.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 14, 2017 at 12:08 AM, Seebs <span dir="ltr"><<a href="mailto:seebs@seebs.net" target="_blank">seebs@seebs.net</a>></span> wrote:<br><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.<br>
<div class="HOEnZb"><div class="h5"><br>
-s<br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div><br></div>