[yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption

[Jack.Fewx at dell.com]

> > On Wed, 2018-08-22 at 14:54 +0000, Jack.Fewx at dell.com wrote:
> > > So failure mode is the target filesystem is devoid of SELinux file 
> > > contexts, all files are unlabeled_t, which pretty much breaks 
> > > everything in enforcing mode.  So whatever the corruption 
> > > cause/effect in the Psuedo database, the end result is when 
> > > Mksquashfs runs it can't get labels for the files.
> > > 
> > > There is no obvious differences in the pseudo.log files between good 
> > > and bad runs, so it's nothing Pseudo is screaming about.
> > > 
> > > I just found the Pseudo debug option flags, and how to insert them 
> > > using FAKEROOTENV += "PSEUDO_DEBUG=Dx", so I'm running builds trying 
> > > to get good and bad ones with the debug logs.
> >
> > Its not clear if you already tried this but if not, it'd probably be worth updating pseudo to the latest version too, see if it was some bug we already addressed in pseudo. I know we've had a few challenges supporting xattrs in there...
> >
> > Cheers,
> >
> > Richard
> 
> We have a "bleeding edge" test environment for staging our next upgrades, and I see Poky 2.5.1 just dropped, so I'll set that up and give it a whirl. And pull down the top of the Pseudo git tree as well. The only issue is whatever patch fixes this, I will need to backported into our 2.3 environment. The next release is stabilized on 2.3 for shipment soon, so I can't yank the rug out from under that one. If we just have to limp along it'll be annoying, but not the end of the world as we can get some good builds out.
> 
> Our 2.3 environment is behaving itself again for the moment, so it will take a bit to get debug logs. Sounds like I have some homework to do, I'll keep everyone posted.
> 
> And thanks to all for your quick responses.
> 
> Jack Fewx

Update! After running a number of test builds and seeing passes and failures, I found the root cause of our issue.  This one took a while.

The inode values in our build system get too large.  Meaning they exceed the MAX value of a SIGNED 64-bit integer.  As long as they are under that limit the build is fine, as soon as the signed values become "negative" it all gets screwed up.

Good build (paths redacted): 

get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189]
requested xattr named 'security.selinux' for ino 1573104496
set-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [50/223]
trying to set a value for ino 1573104496: name is 'security.selinux' [16/50 bytes], value is 'system_u:object_r:backup_store_t' [33 bytes]. Existing row -1.

get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189]
requested xattr named 'security.selinux' for ino 1573104496
got 33-byte results: 'system_u:object_r:backup_store_t'
get results: 'system_u:object_r:backup_store_t' (33 bytes)

list-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath '' [-1/172]
got 17 bytes of xattrs to list: security.selinux

Bad build:

get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189]
requested xattr named 'security.selinux' for ino 2983570948
set-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [50/223]
trying to set a value for ino 2983570948: name is 'security.selinux' [16/50 bytes], value is 'system_u:object_r:backup_store_t' [33 bytes]. Existing row -1.	

get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189]
requested xattr named 'security.selinux' for ino 2983570948

list-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath '' [-1/172]
got 0 bytes of xattrs to list:

The inode count is the later example is too great, so every lookup fails, and the xattr is set multiple times in the database, yet can't be read out during mkfs.

SO... any suggestions how to make the inodes in the database an UNSIGNED value?